As you are talking about "set of features" already ...
I think we should use a feature bitmask instead of a version number in
the API.
How would you use this in qemu though? Say you link to spice 0.10.0,
which has a set of new features not in 0.8.0. Why would you want to make
a spice instance that doesn't use all features in 0.10.0, yet is not
compatible with 0.8.0, so you can't migrate between them.
I would only enable features qemu knows about, i.e. something like
features = spice_get_features()
features &= qemu_supported_features;
spice_server_enable_features(features);
Where qemu_supported_features is the set of features the qemu qxl code
knows about and can handle. Have options to turn off specific features.
In case a new release adds multiple new features users / admins might
want to selectively enable/disable them depending on how they affect
compatibility. qemu live migration compatibility is only affected in
case the new feature requires additional state to be saved. client
compatibility is only affected in case the wire protocol changes. So it
might make sense to enable a subset of the new features, although that
most likely isn't the common case.
Right now we don't do any compat with 0.4, but the plan is that
eventually we want to add a qemu mode where it doesn't use offscreen
surfaces, nor the new qxl pci device, and allows migration to/from spice
0.4.0 instances.
It's there. The new qxl device handles old guest drivers just fine.
With the spice.v17 branch even live migration should work. At least new
qxl parses old qxl state just fine when switched into compatibility
mode. Not fully tested yet though due to some non-spice-related
migration issues.
cheers,
Gerd
_______________________________________________
Spice-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/spice-devel
