On Fri, May 26, 2000, David Brownell <[EMAIL PROTECTED]> wrote:
> I think I'll like this patch ... :-)
>
> One more thing: the topology information in /proc/bus/usb/devices
> doesn't seem to be exposed through reasonable APIs.
Yeah. This is something I wanted to expose as well, but it was less than
trivial so I didn't do it in this patch.
> I'm wondering what you (and others) would think of adding a new mechanism
> to devfs, facilitating exposure of that and other things: device-specific
> ioctls. A hub device would use these to expose which devices connect to
> which ports. Other devices might expose other information.
>
> A general mechanism there would involve a new driver method (not just
> {,un}link_urb, probe/disconnect, also the ioctl) triggered somehow via
> the devfs calls.
Sure. This doesn't seem too complicated.
> Such a mechanism might also help address the locking issue that got
> some discussion earlier (where there's an impedence mismatch between
> the "interface claiming" mechanism and the need prevent arbitrary control
> requests going to devices that can't deal with them ... including the case
> of devices supporting multiple concurrent drivers (one per interface).
Well, this may be difficult to do. I had always envisioned doing this with
semaphores or something similar. Although that won't work for asynchronous
control requests (like HID). Sounds like we need a control queuing, which
is similar to the new bulk queuing option. This would sufficiently solve
this problem at the minimum of complexity.
> I've not yet drafted such an API proposal; I wanted some feedback on
> the notions there first.
I haven't spent much time determining how to expose topology information.
This would be required for one of the features I wanted to add to the
USB device manager.
One other thing I'd like to expose is an ioctl to reset a device via
usb_reset_device. This should be relatively easy.
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
