We've talked about this before on the mailing lists... we've never come up with a good solution.
It seems to me that the problem screams for a semaphore. The question is just which semaphore.
That, and coming up with reasonable semantics to impose on every driver.
Let's see what usage fits well with dev->serialize. There should be no reason to want another semaphore with that scope. In fact, Duncan had a patch to replace the usbfs devsem with dev->serialize ... and suggested making it a shared-or-exclusive lock (rwsem), which could useful in this case.
For most devices, endpoints (including ep0) are independent of each other, so I/O could get a readlock and concurrent requests could be posted. But with this quirk, they need to be single-threaded ... so I/O could writelock, instead.
And this question: Do devices with multiple interfaces (and different drivers attached to those different interfaces) need to interlock on that semaphore?
As such devices are a minority, maybe we should concentrate on usbfs first. Secondly control transfers are often encapsulated in helper function which could be modified.
Concentrating on usbfs for now is good, but whatever we come up with should easily scale to all drivers (as necessary).
Drivers that issue control requests from non-task contexts might have some difficulty using an rwsem, but that would be OK and shouldn't make any problems making sure usbfs and usb-storage don't stomp on each other.
- Dave
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
