[Spice-devel] [spice-gtk v4 00/13] CD sharing feature
Frediano Ziglio
fziglio at redhat.com
Thu Sep 20 11:14:18 UTC 2018
> Hi,
>
> > During my talk at KVM forum, I mentionned that an interesting project
> > idea/heack would be to try to reuse emulated USB devices in qemu, and
> > abstract them so they could speech usbredir. I think that would be
> > really neat, because not only we could share USB emulation code from
> > qemu with spice client, but we could also run qemu USB devices
> > out of process. It may not be easy, or it may, in all cases I hope we
> > won't duplicate too much of qemu code in spice client. Perhaps qemu
> > USB devices code could be in a shared library?
>
> Not that easy, most usb devices are notstandalone. Easiest target for
> trying that approach is smartcard (ccid) I guess. usb-storage has
> dependencies to the qemu scsi and block layer. usb-hid has dependencies
> to the UI code (for getting events). usb-serial depends on a chardev
> backend (maybe not that difficuilt either).
>
As far as I can see it seems we agree that this (having a library to
share this part of the code) is not a viable/easy solution.
> > Could the discussion be opened on the spice-devel & qemu-devel mailing
> > list? A summary mail of the 2 approaches could bring interesting point
> > of view to help make a decision. Especially from block devices & usb
> > maintainers."
>
> Seems that happens now, after coding up things, instead of discussing
> approaches beforehand ...
>
> cheers,
> Gerd
>
If we consider the nbd PoC and the solution Daynix sent (spice-gtk and
emulation) I personally prefer the Daynix solution and as Yuri said already
the glue code required for the nbd is bigger than the emulation code.
I also think is better from the client prospective, updating the host
to fix possible problems is much harder than just update the client.
Being also the client less a security issue the client solution reduces
the surface attack.
Frediano
More information about the Spice-devel
mailing list