Yes, I was going to respond to Randy's "2.3.99 jobs"
message with this ... particularly since I just noticed
an explicit statement in the USB spec that the USB Driver
Interface (USBDI) must support "sharing" of the default
(control) pipe. It seems not to be a Linux-specific issue.
> I'm forwarding a message I got from someone who was testing the
> usb-storage driver. They've been able to reproduce (reliably) a problem
> we discussed a while back on this list -- that usbdevfs will race with
> other drivers.
>
> ...
>
> When we first talked about this problem (IIRC), there were two basic
> solutions that were proposed:
>
> (o) usbdevfs should cache the data so it doesn't need to access the device
This is a workaround only for those device strings. I'd support
a short term patch to cache those strings (it's embarrasing as
it stands :-), but I think a fix to the real issue is necessary:
> (o) a per-device (or per-interface?) lock which would start in the locked
> state for compatibility
I think something like this needs doing. There were several
usage cases demonstrating the need to let more than one "driver"
module talk to the device. The user mode examples were very
interesting, but the issue comes up with just kernel code, for
multi-interface multi-driver devices.
Note that "compatibility" is perhaps a misnomer; it'd need to
prevent a lot of accesses via usbdevfs that work today, but
that's sort of the point ... :-)
> Comments? I think this should be on the high-priority TODO list.
Agreed, as above.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
