On Tue, Nov 30, 2010 at 12:26:56PM +0100, Hans de Goede wrote: > Hi, > > On 11/29/2010 06:49 PM, Anthony Liguori wrote: > >On 11/29/2010 11:37 AM, Attila Sukosd wrote: > >>Hi, > >> > >>I guess it should be abstract enough to support multiple back-ends, be it a > >>kernel driver or through libusb? > > > >Is this something that should just live in libusb? > > > >If what libusb presented QEMU was actually implemented as USB-over-IP, QEMU > >wouldn't know the difference at all. I think it would also be very useful > >to be able for libusb-based applications to work with remote devices. > > > > Well currently qemu is not using libusb but instead talking to usbfs directly > when it comes > to usb pass through. This is something worth looking into fixing (as doing > the usbfs stuff > ourselves is not nice), but looking at the smartcard support discussion I was > left with the > impression that using external libraries was deemed undesirable. > > Even if qemu's usb pass through code were to use libusb though, I don't think > that putting > network direction into libusb is a good idea though. This clearly falls > outside libusb's > original design goals, and would require some major work on libusb. And > although libusb > upstream is not entirely dead, it also is not the most alive upstream either. > > >What is unclear to me is what role QEMU would play in setting up remove > >USB-over-IP devices. > > That would depend on the scenario, The way I see this is we get a > usb-net-redir.c which > sends packets through / from a real usb device like usb-linux.c does, but > then over > some reliable ordered transport channel. > > Then there would be multiple ways to add a virtual usb device using > usb-net-redir.c to > the virtual machine. One way of adding such a device could be starting a > tcp/ip server > on a machine with an interesting usb device, say 192.168.1.100:2222 and then > in > the monitor type: > usb_add net:192.168.1.100:2222:[vid]:[pid] > or: > usb_add net:192.168.1.100:2222:[busnr]:[addr]
Wouldn't you want to add a usb_add net:host:port that would just export anything it has decided to export? or is this just the next step? > > Another way would be for a spice client (viewer) to indicate through the > spice main > channel that it has a usb device which it wants to plug into the virtual > machine, and > the qemu spice code then adding this device to the vm, using a spice channel > as the > transport > > Another way would be using a vnc client and somehow one of the sides > indicating > they want / are providing a usb device on the vnc client machine to show up > inside > the vm > > > Pushing it down to the libusb layer completely takes QEMU out the picture > > which creates a clean separation layer. There are emulated devices in QEMU > > which we create and control and then there are passthrough devices that > > QEMU doesn't have any role in creating. > > IMHO the above 3 scenarios clearly indicates that when it comes to the device > management (adding / removing) qemu needs to be involved. > > I plan to write and submit a RFC for the protocol over the reliable ordered > transport > channel today + tomorrow, and once that is in place I'll start with focussing > on > making it possible to do: > usb_add net:192.168.1.100:2222:[vid]:[pid] > > Assuming that a usb device sharing server is running and ready > to accept connections on 192.168.1.100:2222 > > Regards, > > Hans > _______________________________________________ > Spice-devel mailing list > spice-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel