But if usbcore were to get changed, why not change it
to have a usb_urb_begone() call that MUST (eventually)
be used for all synchronous unlinks? That's a better long-term approach IMO.
I like that idea. In fact, why not make usb_unlink_urb() be purely async?
Eventually, yes -- getting rid of that async unlink flag would be a good deed, but it'd need to be done carefully. I'd not rush that into the 2.6 series.
Drivers that want to wait for the URB to finish completely could then call
usb_urb_begone() after unlinking it. (The implementation could perhaps be
spruced up a little. Something like my usage_count field should be used;
there's already a FIXME about improving the URB state in hcd.c. And it wouldn't hurt to use a blocking primitive rather than polling every 1/100th second. There could even be an interruptible version, although I don't know that there's any need for such a thing.)
I'll be shocked if that name survives too ... ;) Maybe "usb_stop_urb()" would be better.
Re implementation, I'll continue to lobby for simplicity. Polling doesn't bother me much, since it should only be called once. Drivers can implement interruptible waits themselves, on top of async unlink. And the usage count thing seems to be designed to facilitate something that I think usbcore should avoid.
Another important area where better synchronization is needed in the core is submission/unlinking. An URB should be either:
idle (not used at all or just beginning the submission process but not yet linked by the HCD), in progress (linked by the HCD, no errors encountered yet, not unlinked, not completed), or finishing up (error, unlink, or in completion handler).
Why should the model visible to drivers be any more complex than the simple two-state model I thought we had today?
- URB is inactive. Device driver handles any nuances like
never-used, just-completed, etc. Device driver may submit
it, if it's properly initialized. - URB is submitted. HCD controls it, and manages nuances like
whether the hardware sees it, whether it's being canceled,
whether completion status is known, etc. HCD will give it
back (state becomes inactive). Device driver may unlink,
but otherwise may not access that URB.That is, your "finishing up" is just some HCD-internal variant of "linked" -- except for "in completion handler", which is the first not-linked state on today's return path.
These state changes should be protected by urb->lock. But they aren't, and we currently can't distinguish between idle and finishing up.
I don't follow. Today, state transitions are made by only two function calls -- usb_submit_urb, usb_hcd_giveback_urb -- since there are only two transitions. And urb->lock is used to make the usbcore/hcd boundary handle unlinking -- no more.
- 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
