David Brownell wrote:
Wouldn't a plain old atomic "BUSY" bitflag work better? If it's set,
usbcore would reject urbs with -EAGAIN ... from all contexts,
including the many that can't acquire semaphores!
Going back a bit--what context were you thinking of that wouldn't be able to grab the semaphore--are you talking about a userspace program that talks to a USB device URB-by-URB, instead of using a driver like usb-storage?
I'm basically asking how the thing would work. Since the device is broken, and doesn't support concurrency that the USB spec requires, AND usbcore wasn't designed around that bug, I see two basic choices:
- Try to fix it generally, for all contexts usbcore handles, on devices known to have this flaw.
- Fix only a handful of special cases, only those contexts and devices.
The latter might make more sense. In that case, flag/semaphore/etc doesn't matter so much ... you might be concerned only with making sure that usbfs and usb-storage can collaborate enough to keep the device from locking up.
I'd not be keen on hybrid solutions that affect devices that work correctly, and that's what it seemed to me was in the air.
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
