On Mon, May 29, 2000, David Brownell <[EMAIL PROTECTED]> wrote:
> 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).
That is a problem, but I think 2 drivers (or driver and process) won't
be controlling the same part of a device.
Take the HID driver. It sets up some simple stuff at the beginning
(configuration, alternate setting, hid specific stuff, etc) and the only
does HID control messages to turn on leds, set hid specific parametes,
etc.
Then we have some userspace client which does a control transfer to
request some descriptors or something (string, device, etc).
If it wants to do HID specific control messages, it can do it through
the HID module which keeps everything in sync. I'd like to see whatever
driver or system keep all of this in sync.
> 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.
Careful, anything more than queuing will likely signifcantly complicate
asynchronous control messages. Think HID trying to set LED's on a keyboard.
I'd hate to have to queue control messages internally if usb_submit_urb
returns -ENXIO.
> 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.)
Looks good. Sounds similar to sockets when getting all of the interfaces
on a system.
> 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.
I'll go through the rest of the core and see if there's anything else
that might be desirable.
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
