>>> The idea here is that a usb device connected to machine a, will be >>> available for use by the guest os running on host b (machine b). >>> >>> I'm working on this because it is something which we want / need >>> for spice. I'm wondering if there is interest in this outside >>> of spice ? >>> I'm asking because at this moment in time the redirection support >>> can probably be written in a way which abstracts the transport channel >>> quite easily, allowing use outside of spice. [...] >> Not me at the moment, but unless you tunnel it inside another >> protocol, you'd really want to look at the existing USB-over-IP >> protocols instead of reinventing the wheel: >> http://usbip.sourceforge.net/ (some support in Linux already IIRC) >> (and there are others which I don't recall) > > Doesn't look very useful on a quick glance. > > First: Yes, we wanna embed this into other protocol(s). > > Second, seems usbip is implemented using special drivers in kernel space for > both sides. We will not need special drivers on the qemu side (we just hook > up the devices to the emulated hci). On the client side using libusb looks > alot more sensible than requiring kernel modules.
I recall seeing discussions about it on the libusb-devel list (CCing). http://search.gmane.org/?query=usbip&group=gmane.comp.lib.libusb.devel.general 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). 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. François.