To check this I'll have to compile the vdi_port driver, since back
porting the spice_vmc.c file from qemu-kvm-rhel6 would be too much
work (there is not virtio-serial in current qemu used in upstrea
spice). But I'll try to do it and send the patch over.
qemu on freedesktop.org has both vdi-port and spice-vmc drivers. With
vdi-port not being intented to be submitted upstream, but it is useful
to have for the time being as the spice-vmc windows bits are not ready yet.
Actually, the movement of write to the plug doesn't look right - the
interface is basically a table that is filled by the user, in this
case qemu.
Which plug?
Data structures we have (for all interface types):
(1) Implementation -- static data for the (qemu) implementation of
the interface (the function pointers).
(2) Instance -- data for the actual instance of the interface.
The whole idea is best explained with qxl where you can actually have
multiple instances: There is a single qxl implementation, and there is
one instance per qxl device (i.e. for the multihead case you have
multiple instances).
The instance is used everythere to refer to the interface: libspice
passes it when calling the interface callbacks. qemu passes it when
calling spice_server_$interface_$action() functions. It holds a pointer
to the implementation, a pointer to the private libspice data and
anything else needed (qxl id for example).
Oh, and I think the current wakeup + read/write callback scheme has it
advantages. Especially spice-server can call read() whenever it is
ready to accept data. With the data rates we have today spice-server
will grab the data instantly after wakeup, but that will change once we
xfer bulky clipboard data.
cheers,
Gerd
_______________________________________________
Spice-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/spice-devel
