Oliver Neukum wrote:
That tells us the there is a multitude of operations that need locking. Not that these operations are common. Maybe except usbfs. Wouldn't usbfs be happy with down_read()?
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. 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 ...
-------------------------------------------------------
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
