On Thu, 17 Jul 2003, David Brownell wrote: > Oliver responded: > > > Right, it holds information about the status of the io operation the URB > > describes. It doesn't hold information about the status of the URB itself, > > such as unlinkable, ununlinkable, running completion handler, unlinked > > These are not identical. We just have a loose connection of EINPROGRESS > > meaning unlinkable, which is not a clean way to do this. > > So long as the urb hasn't been returned to the driver, it may be > definition be unlinked until it starts a completion cycle. > > Such a cycle starts by changing urb->status from EINPROGRESS, then > either usbcore (in the unlink case) or the HCD (typical case) starts > to push the URB through one of the paths ending in an urb giveback(). > > From that point on, unlinks must fail since the urb's status has > been determined, and the URB is being returned; it's already being > unlinked, and that can't be done twice for one submission. It's not > a "loose" connection ... it's a tight one, reducing the number of > ways that errors/bugs can appear. > > If the completion handler is running, then unlink processing shouldn't > even be able to start, since the urb will no longer be owned by either > usbcore or the HCD.
I would like to add that Oliver's "running completion handler" isn't really a separate state in the current setup. Trying to make that a separate detectable condition would run up against all sorts of problems when the completion handler resubmits the URB. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
