On Mon, 7 Feb 2011, Hans de Goede wrote: > Hi All, > > I'm currently working on usb-redirection over the network, > iow tunneling usb transfers over a network connection. > > The most significant use case for this is taking a usb device attached to > some machine "a" which acts as a client / viewer to a virtual machine "v" > hosted on another machine "b", and make the usb device show up inside the > virtual machine as if it were attached directly to the virtual machine "v". > > Under Linux I'm using libusb/usbfs to access the real usb device > on the client machine (currently using kernel 2.6.35.6). > > When ever the guest os does a usb reset, and I forward this to the > real device, the usbfs driver gets detached from all the interfaces, and > after the reset the normal linux drivers attach to the device again. > > So what I currently do / what currently happens is: > > 1: > -start the usb-host process which takes over the real usb device and > "connects" it to the guest (over a tcp socket) > -the guest os sees a a new device > -the guest os resets it > > 2: > -the linux kernel detaches all the usbfs driver from all interfaces > -the linux kernel does the reset > -the linux kernel attaches the regular linux driver to all interfaces > -the regular driver likely does some stuff with the device > > 3: > -My code needs to redo, for all interfaces: > -the linux driver gets detached > -the interface gets claimed > > After reading the kernel code I've found out that it would be > a good idea to claim the hub port, this should stop the native > linux drivers from re-attaching to the device after the reset. Yes; this is one of the things that mechanism was intended for. > Changing 2 and 3 into: > > 2: > -the linux kernel detaches all the usbfs driver from all interfaces > -the linux kernel does the reset > > 3: > -My code needs to redo, for all interfaces: > -the interface gets claimed > > Which is much better. But I was wondering if it wouldn't be even > better to add a .pre_reset and .post_reset code to the usbfs > driver, so that 2 changes into just: > > 2: > -the linux kernel does the reset > > IOW the usbfs driver does not get detached for a reset. > > So what do others think. Would it be a good idea to change things > this way, or is the usbfs driver detaching intended / expected > behavior? It is intended/expected, because in general there is no way for usbfs to inform its users that a reset has occurred. The only safe thing it can do is release the interfaces it owns. The situation is the same for kernel drivers that don't have pre_reset and post_reset methods; the core has no way to inform them about resets so instead it unbinds them. 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
