On Sat, 10 Jul 2004, David Brownell wrote: > The issue was whether providing one "global" mutex could do the > whole job, I thought. > > Consider: one userspace program would be able to issue a read > (or write) on an endpoint that's NAKing. That can take weeks to > complete. It would then make khubd wait for weeks (*) ... to > notice that you plugged in a keyboard to help kill that read! > > Loosen that to a single global rwsem. Now one problem is that > it would take those weeks before some other application could > register+use a new driver module (not a usbfs issue). Hmm ... (**) > > I don't think it'll be fair to take usbfs out of the equation > even some time after a "usbfs2" ships. And that's not started. > > - Dave > > (*) 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. > So drivers using those calls are limited to half duplex. > And yes, this can block khubd; but it's not very common. > > (**) Alan, I this is an issue the current patches have ... Yes, of course. I don't see any way around it. Consider a device with two interfaces, one of which is in use by usbfs (or anything else). If usbfs (or anything else) locks the device, and a new driver is modprobed which wants to bind to the other interface, clearly it has no choice but to wait for the lock to be released. That's true no matter what locking mechanism gets used. 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. 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
