> > 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. _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
