On Wed, 12 Apr 2000, David Brownell wrote:
> Matthew Dharm wrote:
> >
> > 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 was generally referring to the 'serialize' to mean working out the
submission of multiple URBs to a particular endpoint with the requirement
that each URB to an endpoint complete before the next one is submitted.
I think we have this for bulk endpoints, but I'm not sure about the
others.
> I suspect you meant "per-device" ("device-global"?) rather than "global".
I meant device-global. Sorry, the drugs are still working their way out
of my system. Actually, this is an important tip for those of you who
might have surgery soon -- getting off the pain meds can be worse than the
pain itself.
> > 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 ...
Well, I don't know of any multiple interface (with multiple drivers)
yet... but I have heard of devices with multiple mass storage interfaces
that are in the design stages. I've also heard of a device (which I can't
really discuss the details of) which is a ACM modem and a storage device.
I've written usb-storage so that it will only need the one interface, but
I can't be sure without testing one of these devices, and I don't think
that they actually exist yet. From what I've heard, the devices I'm
hearing about are specifically being designed so that drivers which work
on a per-interface basis will be fine.
So, from where I sit, a per-interface lock would be sufficient.
> > (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.
This seems like an excellent idea, as long as it's coupled with one other
feature: If a driver is de-registered, all locks that it holds need to be
automatically released.
> > 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.
Hrm... what is sent along the control pipe? Do separate interfaces have
separate control pipes? I never really thought about it. I know the
control pipe is a special case for a few things -- is there only one
device-global control pipe, or is there one per-interface?
If there is one per interface, then the control pipe for the first
interface does have special properties (ability to get strings, etc) I
presume. If there is one per device, then all control messages must go
through that pipe.
My instincts tell me that there is always one control pipe per interface.
I don't have the spec in front of me, but the mass storage spec seems to
imply that.
If there is one per device, then really this is a problem specific to
accessing the particular control endpoint on the first interface. This
seems like a pretty specific problem, and perhaps a specific solution
(rather than a per-interface lock) would be in order.
> > 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!)
Ugh. This doesn't coujure up pretty images in my mind, but I can see the
possibilities. However, is a fully-generalized solution appropriate?
This still seems like a very specific sort of problem with usbdevfs to
me... tho I can see the possibilities for other drivers.
I guess the short summary of this message is this: I like the automatic
per-interface lock idea, given the provision that the lock is released
automatically when the driver is unloaded.
Matt Dharm
--
Matthew Dharm Home: [EMAIL PROTECTED]
Engineer, Qualcomm, Inc. Work: [EMAIL PROTECTED]
E: You run this ship with Windows?! YOU IDIOT!
L: Give me a break, it came bundled with the computer!
-- ESR and Lan Solaris
User Friendly, 12/8/1998
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
