On Tue, May 5, 2009 at 5:37 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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. FWIW, the above was related to solving the usb-passthrough problem which is different from the one we are discussing here. I was replying to greg's comment about usp/ip's "stub driver" but it was out-of-topic for the general thread. > > 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. We are in 100% agreement regarding where the problems are :) > > 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. Exactly. Being in-kernel does not make the backend "stub drivers" of existing solutions immune to these problems, since these drivers still bind per-interface. > > 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. Well, the fact that this is clear for at least the 3 of us (you, Greg and me) and perhaps Oliver too is a very good start. It means we can move beyond the overview now :) > > 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. Yep, we don't want a buggy program taking our ports with it to its doom :) So, it seems to me that we are all on the same page about what needs to be done and also agree about the overview of how (new driver probed before generic, some sort of file-based grabbing, etc). Great :) Pantelis -- 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
