>> You've talked a lot about this resubmission stuff, and I've neverunderstood why you think this should matter to anyone except the device driver. Maybe you should explain that to me ... :)
Simply stated, things that matter to a device driver can thereby be of interest to the core. If by providing a simple -- though not strictly necessary -- service the core can make device drivers easier to write and more obviously error-free, then the core should provide it.
In case that wasn't clear enough, consider this rhetorical question: Why does the core contain usb_ifnum_to_if()? It's a simple routine; any driver that needs it could easily include its own version.
I don't think the urb lifecycle is a simple thing though; adding additional states to that model won't simplify it...
In fact I think it was never thought through, and that's a big part of why we're having this discussion. Another part is that two parts of the API -- core async facilities, and layered synchronous ones -- don't play together that well for unlinks.
Answer: It performs a useful task that would otherwise require duplicating code. It avoids a common mistaken assumption (that interfaces are stored in numerical order starting from 0). It makes it easier for drivers to do something useful and do it correctly.
Hmm, that usbfs patch I sent yesterday showed a downside: it's easier for drivers to do things incorrectly, too!
The specific issue was that usbfs was using it with insuffient locking. The kerneldoc for that routine should say that the caller guarantees that the config will be stable. Device drivers bound with probe() won't have that issue, since they'll see disconnect() before the config goes away; but usbfs can't always work that way.
It's for exactly these same reasons that I think the core should facilitate waiting for URBs to be idle.
So your real issue is that the URB model doesn't have a notion of "idle" that suits you.
How about the usb_sg_request model? That's closer to the three state model you'd suggested, in terms of goals. Those requests may be submitted exactly once, then they need re-initialization. That re-init requirement is not part of the URB model at all.
Part of the problem is that I don't remember what precise definition you were using for what it means for an URB to be linked. Here's my definition, an operational one:
An URB is linked when the low-level HC driver thinks it is.
Whereas I've been using "URB is linked when it's on the list maintained by usbcore".
This can be made a little clearer through the following considerations. In any HC driver there must be two points in the code, one on the submit path, the other on the dequeue path, presumably protected by the same spinlock. Let's call them point A and point B. In a race between submit_urb and unlink_urb, the result is decided by which point is reached first. If the submit thread reaches A before the unlink thread reaches B, then the URB will get linked and then unlinked. If the unlink thread reaches B before the submit thread reaches A, then the unlink will fail (because the URB wasn't linked to begin with) and the link will succeed -- so the URB will end up being linked.
Those points are supposed to be in hcd_submit_urb() and hcd_unlink_urb(). Some cleanup is needed (splice and more), but that's basically true using your definitions.
Note the usb_sg_request() handles that a bit differently. If the thread
doing the cancel ("unlink") wins, it succeeds and prevents the other
thread from starting to process the request.- Dave
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
