On 03/13/2012 09:40 AM, Gerd Hoffmann wrote:
Hi,
It is not easy when you have 2 components, and it is much less easy when
you have 3 or 4 components. So why make it more complicated if you can
avoid it. Especially since there is no functional reason for making the
qemu/client capabilities/versions dependent on the server internal data.
qemu has ways to handle compatibility in the vmstate format. We can use
those capabilities. That of course requires exposing the structs to be
saved to qemu and adds some complexity to the qemu<-> spice interface.
What session state is needed by the target?
What of this can be negotiated between client and target host without
bothering the source?
What needs be transfered from source to target, either directly or via
client?
If this is a hard requirement then using the vmstate channel isn't going
to work. The vmstate is a one-way channel, no way to negotiate anything
between source and target.
We can do this via the client.
Then you can send the actual state via client too.
Out-of-band negotiation for the blob send via vmstate scares me.
Can we please start with a look at which state we actually have to send
over?
Ok, I can take the display and sound channels.
Alon, can you take the smartcard?
Hans, spicevmc?
Arnon, the main channel, mainly the agent stuff?
Thanks,
Yonit.
cheers,
Gerd
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
