[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