qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Spice-devel] [Qemu-devel] RFC: usb redirection over the network, in


From: Frédéric Grelot
Subject: Re: [Spice-devel] [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice?
Date: Mon, 29 Nov 2010 16:10:17 +0100 (CET)

> > 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.
> 

I'm note sure about what I will say, but will a kernel approach handle specific 
disconnection/reconnection of devices, that libusb cannot?

I'm thinking in particular of what happens when one updates an iP* (*=hone, ad, 
odTouch, od) device, where it gets connected and disconnected several times 
during the process. 
During the updates, the device reboots, generating a disconnection event, and 
at reboot the guest OS (and iTunes) has to  to catch the reconnection event 
directly (before iOS loads) to upload the new firmware.
I'm not sure about it, but I think Virtualbox (non-ose) took care of this 
issue, and updates are now possible in a vm (TbC).

I don't think that an approach at libusb level would work, while I could 
understand that a kernel module would be able to catch the "connection" event 
directly, and pipe it through the network to the guest.

I don't know for sure if this use case affects only those devices, nor if it is 
an objective for spice to allow Apple device updates, but I think it has to be 
handled at pretty low level, so is worth mentioning before any implementation 
choices.
Still, if such thing were to work, I think it would be a huge step for all the 
people in the iP* community that maintain a double boot only because they 
bought a closed phone once :-)

However, the guest side could be handled at qemu-level, since it would 
certainly provide an OS-independent implementation without the need for 
linux-/windows-/other-specific driver.

Frederic.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]