On Mon, 17 Mar 2003, David Brownell wrote: > You know, in all this email I think one of the key issues > has somehow not gotten brought out: the need to let the > I/O requests get canceled when the task gets signaled. > Or at least having an option to do that.
Good point. > >>>If you mean that nobody has ever needed to cancel just a single > >>>synchronous message except as part of cancelling all of them for a > >>>disconnect, I agree. > >> > >>Yes. Same is true when the driver uses asynchronous models too. > > > > > > Surely you don't mean to say that drivers call usb_unlink_urb() with > > the URB_ASYNC_UNLINK flag set only during disconnect()? > > No. But when would it be appropriate to unlink one request > from the middle of an endpoint's queue? At best that's an > esoteric and very error-prone case. And a good rule of thumb > for designs is to get rid of all such models. I see. You mean that whenever an unlink occurs, whether synchronous or not, the driver really wants to unlink all the urbs queued for that endpoint. But remember that, unlikely though it may be, it is possible for more than one driver to have requests queued for ep 0 at the same time. If one needs to cancel its request, you're still stuck with all the problems of unlinking a request from the middle of an output queue. > >>>How does your patch know which interface a request is intended for? > >> > >>Looks at the endpoint addressing information. > > > > > > Again, what about requests for endpoint 0? > > Again, see above. In the rare cases that matters, we > have a simple solution that'll work in most cases. How will your simple solution work in the situation where two drivers are bound to different interfaces on the same device and one of the drivers is rmmod'ed? How does your patch prevent the core from accepting urbs for ep 0 from the driver being unloaded while still allowing submissions from the other driver? Or is this something that has never yet come up and will be dealt with when it really matters? Alan Stern ------------------------------------------------------- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
