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.
More importantly, usb_sg_request doesn't have completion handlers. It's not really asynchronous, in the sense that drivers eventually have to wait for a request to complete.
It's always been an explicitly synchronous model -- no completion handler for app code, just whatever happens after usb_sg_wait(). It resembles usb_bulk_msg() except that there's actually a way to cancel the request: an async unlink.
Usbcore can't add an exactly corresponding usb_urb_wait() since it doesn't have a way to cancel urbs before they're submitted (to prevent submit from succeeding in some exotic races).
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 is an important difference and it's worth spending some time on it. Consider what happens when the two definitions disagree. Suppose an URB
is on the submit path on CPU-1 and has reached a point where it's on the
usbcore list but the HC driver hasn't yet accepted it. What happens now
if CPU-2 calls usb_unlink_urb for that URB?
Not what you outline:
Answer: usbcore removes it from the list and tells the HC driver to
dequeue it. The HC driver refuses to do so (because it hasn't been queued
yet). Regardless, the core returns from the unlink call with the URB
removed from its list.
Actually, no ... usbcore marks the URB as pending-completion by urb->status != -EINPROGRESS (a point you intentionally skipped over yesterday), and then kicks the HCD. It's still linked. Even if the HCD ignored kicks given before requests are linked to the hardware, the failure you describe wouldn't happen.
ALL completions are triggered from the bottom up, by the HCD. URBs are removed first from hardware data structures, and then from usbcore data structures ... always in that order.
- 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
