Thomas Sailer wrote:
>
> David Brownell wrote:
>
> > If issuing GET_* messages causes troubles as you said, then
> > "cat devices" should be able to trigger them sometimes when
> > it causes string descriptor requests.
>
> Yes; it was however not my decision to put the strings
> into devices, I was never too happy with it, as it gave
> oopses in the past.
Well, it can be done correctly, and IMHO should be, but
an "Oops" doesn't fall into that category. Removing strings
from "devices" would be a workaround, not a solution.
> > I've not heard of such a thing. But if it does happen, the
> > reason will either be bad serialization of control messages
>
> As far as I know this is still not solved, i.e. control
> msgs aren't serialized so far. I think this should happen
> either in the HCD or the usbcore sync->async wrappers...
I have a hard time seeing it be automated. I think that some
lock will need to be exposed, and used correctly.
> > Strikes me that devices with multiple interfaces claimed by
> > different drivers could see a version of that problem too.
>
> Yes; but there we have to assume that the drivers know what
> they're doing...
Going back full circle to my original point: it does no good
to assume that, when they have no tools to implement a safe
policy. Today, such API tools are lacking.
There's another category of software to consider, too. It's
what one might call "management" or "troubleshooting" or
"system monitoring" applications. Userspace tools, ideally,
that talk to devices to handle things that are outside the
scope of what a kernel driver does (or another userspace tool).
I mentioned power management before (user needs to say _which_
configuration is desired, when there's a choice).
> > You're saying that a chunk of library code in my applications
> > can be given access rights that I didn't originally have when I
> > started them? The mechanisms I know to do that (e.g. set-uid,
>
> The original idea was to have a daemon that monitors
> plug events and then adjusts the usbdevfs file permissions
> according to some configuration files. So no need
> to play permission games in your code...
Again, my point was that the "permission games" sure look like
they're attempting to paper over locking problems, and that's
a losing game. (I never wanted to play any such games!)
Two classes of locking problems come to mind. There's the one
above ("is it safe to talk to the device now, when I'm one of
several components that needs to do so"), and there are races
in the file system naming that can't be solved so long as names
get reused.
I had the thought the other day that if usbdevfs were to use
names that started with the product and vendor IDs (32 bits hex)
with a counter, those file naming problems would stay away.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
