On Sun, 11 Jul 2004, David Brownell wrote: > Alan Stern wrote: > > >>(*) A known annoyance in the usbfs API is that synchronous > >>calls hold the device lock until the request completes. > > > > > > Surely that can easily be fixed. usbfs doesn't need to hold the lock > > during a synchronous transfer. > > Maybe Duncan can comment. I don't think any other code would > hold that (new) readlock for arbitrarily long amounts of time. > The usb_bulk_msg() paths could always be changed to submit_urb(), > drop_lock(), wait for completion, grab_lock().
Duncan, I noticed in a proposed patch you posted recently that you had copied the timeout code from message.c (used to support usb_bulk/control_message()) into devio.c. One of the things on my todo list is to remove that code entirely and replace it with more general timeout support in urb.c, something that could apply to any URB. Would something like that be worth doing soon, and would it make things easier for you? > > The real problem here is that nothing should be allowed to hold a shared > > lock for weeks at a time. Fixing (*) will help address this issue. > > Frankly, even seconds at a time is worth avoiding. > > But it should be fine to have a read() blocking in the > kernel for weeks at a time. Agreed. Alan Stern ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
