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