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.
> 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...
> 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...
> 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...
> 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!
No, stores are usually unidirectional. But this is nitpicking,
I think you know what I meant.
> p.s. You never addressed the "patch to move the devfs #include
> file into <linux/usbdevfs.h>" issue. Should I assume
Fine for me.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
