Matthew Dharm wrote:
>
> I always assumed (albeit with much ignorance) that usbdevfs cached the
> strings which described the device in it's own personal copy. Is that not
> the case?
Not by my observation, though I'm not sure why it doesn't. But those are
not the only descriptors that are worth accessing.
FYI I have a device where the product string is allegedly settable!
> If not, then we can have a real problem that definately requires a global
> lock, rather than a serialization issue.
Locks support lots of serialization policies, including long-term
mutual exclusion. You may mean other things by "serialize" than I do.
I suspect you meant "per-device" ("device-global"?) rather than "global".
> Consider usb-storage, which
> conducts multi-stage transactions with a device. With just serialization
> in place, if I send the control message to a CBI device to initiate the
> transaction, and then get interrupted by someone doing a 'cat devices',
> we're dead. I don't even want to think of what will happen to usbdevfs or
> to the data on the storage device.
If it's correctly serialized, the second transaction (get string) would
wait till the first transaction permitted it ... maybe by completing,
maybe something sooner than that.
Re "don't even want to think" ... too bad, since there may be a really fine
example in there of why it's important to get the concurrency right! ;-)
> The only ways I see to solve this is:
>
> (a) Only the device which claims the interface can actually issue
> commands (this means hands-off to usbdevfs), or
If it's a single-interface device, that could work: "device ownership".
Seems like the most common case I've seen. The usbdevfs code would
claim the interface before sending control messages. It could never
look at most currently supported devices, only stuff without kernel
drivers.
But also there's that "two interfaces, two drivers" problem. I don't
happen to have devices which would tweak it, but I assume they're real
or the kernel would have "device claiming" not "interface claiming".
Such devices will need some sort of mutex solution. Off to Plan B ...
> (b) a global lock, which means possibly non-trivial code changes to most
> (if not all) drivers
A device-global (?) lock, surely. If the policy in effect when drivers
start up were "I own the lock", only those drivers that wanted to cooperate
with other code would write any code to release and reclaim the mutex.
> I think the question comes down to this: Is this a usbdevfs-specific
> problem, or not?
I think it happens without usbdevfs too. A device with two interfaces
claimed by different drivers has the same contention issue for control
messages. Changing device configuration also affects device-global state,
so doing it without proper coordination could break things.
> Are there other cases where we can have multiple drivers
> (kernelspace or userspace) fighting for control of a device?
There's also the model of drivers split into parts, with some of
the support in userspace. I prefer to think of it as letting modules
collaborate when appropriate. Not all modules will be written to be
cooperative, but others will do so to be fully functional. (Dmitri
just posted a nice list of examples; thanks!)
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
