Thomas Sailer wrote:
>
> David Brownell wrote:
>
> > Requiring write access isn't sufficient, in the case of
> > multiple writers.
You don't seem to have responded to that general "multiple
writers" (i.e. GET_* issuers) issue. Putting it differently:
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.
I've not heard of such a thing. But if it does happen, the
reason will either be bad serialization of control messages
(fixable, e.g. with a mutex) or a truly broken device (can
be worked around with a mutex that's never dropped) like the
ones you said talked about.
Strikes me that devices with multiple interfaces claimed by
different drivers could see a version of that problem too.
> You can either trust a piece of driver software (and give
> it write permission), or not, but still allow it to
> find out what devices are on the bus, by giving it
> only read permission.
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,
a privileged daemon I authenticate to, etc) are best avoided.
Also, note that it's just _partial_ read permission; reads
such as GET_DESCRIPTOR of the product string aren't allowed.
(OOG say parsing "devices" file bad!)
> > APIs for that), I do expect to be able to write user mode
> > code that works with power management policies, and so
> > must be able to talk to hubs ... without clobbering what
> > the kernel hub driver may be doing.
>
> In that case it will become necessary to add ioctl's
> that talk to the hub driver instead of directly accessing
> the hub...
Actually, no -- the control message API is plenty, in
conjunction with the specs for those messages. It works
today; no new API (ioctl) needs designing or documenting.
But I agree on the notion of ioctls to talk to individual
drivers -- should we add a "struct usb_driver" hook in 2.4
to support it?
Something I think should be done that way: I need see what
device is hooked to what port. An ioctl can take an port (int)
and return the device # (int). I don't see how to get that
data otherwise. (Remembering that parsing the devices file
is not to be an option ...)
> > Setting permissions, OK -- but my observation is that
> > the current "read" permission doesn't match what "read"
> > permission normally matches.
>
> Depends on how you look at it. On the wire every transaction
> is bidirectional, even though user data may be flowing
> only in one direction.
Same goes for any low level hardware, including accessing the
memory for the cached device descriptor. Perhaps you should
just demand "rw" consistently, and disallow that access too!
Or, maybe use the request type field to distinguish a "read"
(TO_HOST) from a "write" (TO_DEVICE). That'd cover the GET_*
cases I pointed out.
- Dave
p.s. You never addressed the "patch to move the devfs #include
file into <linux/usbdevfs.h>" issue. Should I assume
you don't think usbdevfs is ready for that yet? I don't
like knowing that _two_ userspace tools have their own
copies of that, or including "/usr/src/linux/..." in my
own code either.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
