On Wed, May 6, 2009 at 11:21 AM, Oliver Neukum <oliver@xxxxxxxxxx> wrote: > 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. Can you please expand a bit more on that? My virtualization usecase doesn't really need the ability to connect hubs to grabbed ports. Would it be easier to just disallow plugging in hubs? 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
