Re control queuing, I think that's likely the wrong model.
Scenario: driver1 sees some state, issues a control request
based on it. Concurrently, driver2 does the same. One of
them "wins" the race, and the state when its request completes
makes the other driver's request into something undesired (an
error, corrupts state, etc).
The model I've got is some sort of exclusive lock, which could
be implemented using a variety of primitives including of course
semaphores. There was some previous discussion on this.
I'll rough out a proposal and post it next week.
Re how to expose topology info, I'd prefer to see something
like one ioctl to return an array of device addresses than
need to use a bunch of ioctls to get one address per port.
They'd both work, and both need care with respect to state
changes concurrent to the ioctl, but I prefer APIs to pass
bulk data where possible. (Input is an appropriately sized
array, kernel copies the port numbers into it.)
A device-reset ioctl is likely good to have from user mode;
in general, facilities available to kernel drivers should also
be available to user mode software.
- Dave
----- Original Message -----
From: Johannes Erdfelt <[EMAIL PROTECTED]>
To: David Brownell <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, May 26, 2000 8:16 PM
Subject: Re: [linux-usb] [patch] new minor features
> 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]
