[Spice-devel] [PATCH 1/1] Add API to turn on backwards compatibility mode

[Alexander Larsson]

On Fri, 2010-08-27 at 15:08 +0200, Gerd Hoffmann wrote:
> >> 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.

I don't think the onus should be on the sysadmin to know what features
is compatible with what version of spice. Thus, in my mind you'll
specify "compat with 0.6" which in 0.8 will enable all the features in
0.8 that are possible to migrate to/from 0.6 (including some that may
not be in 0.6). 

Having a more fine-grained command line feature selection just causes
complexity and risk that sysadmins get things wrong. I don't see any
gain in it.

I'll note that this switch is really only about migration compatibility.
For the client side i think in the future we should either:

* Add a similar switch for client compat
or
* Make sure that we always support connecting with old clients in
  future releases.

I was expecting to do the second. But maybe thats not always possible?

> > 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.

Cool.


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's an immortal native American gangster whom everyone believes is mad. She's 
a wealthy green-skinned fairy princess from Mars. They fight crime!