François Revol wrote: > > usbip I don't know how good this is.
For another implementation of USB-over-IP you could look at Sun's work with the SunRay thin clients. I believe some of it may be in the OpenUSB codebase. (They forked libusb to make it work the way they wanted.) I don't know how good that is, either. > > On the client side using libusb looks alot more sensible than > > requiring kernel modules. .. > It's just one implementation of it, it should be possible to > implement a subset of the features at least with libusb which > should be enough for most devices (scanners/printers/mass storage). Keep in mind that libusb can be used only with USB interfaces which have the usbfs driver bound to them. (Or no driver at all, in which case usbfs is transparently bound at libusb_claim_interface() time.) This means that any kernel driver (like usb-storage) must be moved out of the way. This can be done with libusb, but not portably. Given sufficient permissions it works nicely and on the fly in Linux, but Mac OS X needs manual work and a reboot, and Windows needs to create a restore point. On Windows the libwdi library can be used to switch drivers for USB interfaces. http://libusb.org/wiki/libwdi I have been mulling over if libusb should actually take on the significant task of USB kernel driver management, offering a portable API also for that. In principle I would very much prefer not to do this within libusb, but it is relevant because libusb does require that special kernel driver. Unfortunately it is so painful outside Linux. > And it's better to use the same protocol anyway when possible. > This way the untunnelled version could be used from QEMU or a host > using a stub driver connecting to a server using either the kernel > driver or the libusb version regardless. I doubt USB-over-IP is a good enough USB transport for QEMU. I think QEMU will want lower level access to the bus. One way is to leverage libusb, but even that might not be good enough in the long run. //Peter
