On Tue, 8 Mar 2005, David Brownell wrote: > All true. Seems like if there were an interruptible version of > usb_bulk_msg(), that's what this driver should use ... and lacking > that, it's pretty much re-inventing that logic. Wouldn't a better > fix just be a new usb_bulk_msg_interruptible(), which uses one of > the interruptible variants of wait_for_completion() ? After all, > one of the longstanding API glitches in usb_bulk_msg() has been > exactly that it's not interruptible ... hence inappropriate for > use from syscalls including read() and write().
That has been a sore point for a long time. In this case the URB has already been allocated, though. I don't how tight the timing constraints are in this driver; you might not want to rely on usb_bulk_msg_interruptible allocating its own URB. There's also the problem of how to interrupt the routine. An interruption doesn't need to be anything more than a call to usb_unlink_urb, but there are some nasty races involved in storing a pointer to the URB where the caller can get at it. And don't confuse the separate questions of being interruptible by a signal and being interruptible by a timeout. Didn't we discuss adding timeouts for general URBs to usbcore some months ago and end up rejecting the idea? Alan Stern ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
