On Mon, 8 Dec 2003, David Brownell wrote: > I'll be shocked if that name survives too ... ;) > Maybe "usb_stop_urb()" would be better.
Or usb_wait_for_urb(). > Re implementation, I'll continue to lobby for simplicity. > Polling doesn't bother me much, since it should only be > called once. It's true that HC drivers ought to be able to unlink and giveback an URB in only a few hundredths of a second. > Drivers can implement interruptible waits > themselves, on top of async unlink. If any of them even need it. > And the usage count thing seems to be designed to facilitate something > that I think usbcore should avoid. I'm not sure what you're referring to. The particular reason I introduced it was to handle the case of reentrant calls to giveback_urb. I don't see how the core can avoid them if the proper conditions come up. > > 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. The problem with this simple two-state model is that it does not facilitate an implementation of synchronous unlinking that waits until the URB is idle. Of course, for anyone who believes that synchronous unlink only means waiting until the completion handler returns, this doesn't matter. But for device drivers that want to reuse an URB it does matter. Anyway, the existing code doesn't follow this model exactly: usb_unlink_urb checks whether urb->status is -EINPROGRESS before calling the HC driver. According to the model it shouldn't do that; instead it should check whether the URB is submitted (active). But we currently have no way of doing this, since still-linked URBs can have status other than -EINPROGRESS and non-linked URBs can have status equal to -EINPROGRESS. > > 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. Exactly -- no more. It doesn't protect the submission transition. Alan Stern ------------------------------------------------------- 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
