Am Dienstag, 5. Mai 2009 19:01:09 schrieb Alan Stern: > On Tue, 5 May 2009, Oliver Neukum wrote: > > This is not quite so simple. If you hand over a port, you cause problems. > > That doesn't mean you shouldn't do it, but you have to solve the > > problems. Immediately I can think of: > > > > - overcurrent events > > - the power budget > > - how to reset a hub > > - how to suspend/resume a hub > > - how to react to the hub whose port you've claimed being unplugged > > > > Note that these problems (except for the power budget) must be handled > > in kernel space or we can deadlock due to the storage driver. > > Thus you must write a real "device level" usb driver and implement > > the necessary methods. Or possibly even several "device level" > > drivers. > > These aren't issues, at least no more than they are now. The hub > driver will continue to control the port as usual. The only difference > is that the generic driver won't automatically configure a new device > plugged into the port, no other process will be allowed to access the > usbfs device file, write access to the bConfigurationValue attribute > will be denied, and all interfaces in the device will automatically be > bound to usbfs. If you just want to support exotic modes of configuration, that's enough. If you really want to operate the device (or devices, what happens if you plug in a hub?) you'll need fuller support. It seems to that if you wish to use this for the purpose of virtualisation, you need fuller support. Regards Oliver -- 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
