On Tue, 5 May 2009, Pantelis Koukousoulas wrote:
> I 'm more of the opinion that we need a generic "vhci" driver that everyone
> interested (Xen PvUSB, Virtio usb, usb-ip) can use.
>
> Then, we have various "transports" (one for each of the above) and finally
> we drop the backend "stub drivers" alltogether.
>
> Instead, we have a small generic driver that arbitrates ports between
> kernel and userspace and use usbfs for the rest. If usbfs is broken
> in any way, it should be fixed since it is useful for several people,
> not just qemu/usbip/xen/whoever.
>
> That would probably be good even for usbip, since its components
> can be reviewed / merged independently without being blocked
> by the current file descriptor leaking and protocol-needs-a-rewrite
> issues.
I'm not sure whether this is the best approach or not. Let's go back
to basics. The real problems to be solved are these:
1. Some devices shouldn't be configured by the kernel's generic
driver. For one reason or another, they need to be put in a
specific config, or they can't handle having the config
changed once it has been set.
2. A userspace program that wants a high degree of control over
a device finds changing configs rather difficult. First it
has to release all the interfaces, then do the actual
Set-Config, then claim all the new interfaces. This is
failure prone and doesn't prevent kernel drivers from
binding to and messing up the new interfaces. If any of the
old interfaces were in an altsetting higher than 0, the
kernel will put them back in altsetting 0 when the interface
is released -- not what we want to happen.
3. Userspace programs that want a high degree of control over
a device always have to worry about the possibility that
a different program might interfere via usbfs or sysfs.
Note that 1 also applies to certain kernel drivers. It's related to
the long discussions we had some time ago about "USB mode switching".
With modular kernel drivers the problem is even more difficult, because
the driver may not be loaded in memory when the device is plugged in.
But let's not worry about this now.
Giving a program full control over a device solves 2 and 3. Doing this
before the generic driver binds solves 1. (Although this may not be
the best way of thinking about it -- it may be more productive to allow
the generic driver to bind but prevent it from automatically
configuring the device. It's interesting to note that in the generic.c
source file, most of the code is devoted to choosing an initial
configuration.)
Either way, it seems clear that we need a way to give programs full
control over specific devices. And we need a way to do it before the
device is plugged in, which does seem to imply that the program should
specify a particular port rather than a particular device.
The API for claiming and releasing ports needs to be determined;
everything else seems fairly straightforward. I'm open to suggestions;
the biggest requirement is that when a program ends, all its ports have
to be released automatically. This suggests using some sort of control
file for the API.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
