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

[Alexander Larsson]

On Fri, 2010-08-27 at 09:16 +0200, Gerd Hoffmann wrote:
> Hi,
> 
> > This API allows qemu to limit the set of features that spice uses to
> > those compatible with an older version, in order to do an upgrade like
> > this. Right now it doesn't really do much, since we don't keep compat
> > with 0.4.0 atm (although that may be added later).
> 
> 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 don't see the point really.

> > +__visible__ spice_compat_version_t spice_get_current_compat_version(void)
> 
> uint64_t spice_get_supported_features();
> 
> > +__visible__ int spice_server_set_compat_version(SpiceServer *s,
> > +                                                spice_compat_version_t version)
> 
> spice_server_enable_features(SpiceServer *s, uint64_t features);
> 
> > +/* Don't use features incompatible with a specific spice
> > +   version, so that migration to/from that version works. */
> > +typedef enum {
> > +    SPICE_COMPAT_VERSION_0_4 = 0,
> > +    SPICE_COMPAT_VERSION_0_6 = 1,
> > +} spice_compat_version_t;
> 
> /* 0.6 */
> #define SPICE_FEATURE_PROTOCOL_MAJOR2  (1<<0)
> #define SPICE_FEATURE_SURFACES         (1<<1)
> 
> /* 0.8 */
> #define SPICE_FEATURE_MULTIMONITOR     (1<<2)
> 
> /* for convinience */
> #define SPICE_FEATURES_MASK_V06 \
>      (SPICE_FEATURE_PROTOCOL_MAJOR2 | SPICE_FEATURE_SURFACES)
> #define SPICE_FEATURES_MASK_V08 \
>      (SPICE_FEATURES_MASK_V06 | SPICE_FEATURE_MULTIMONITOR)
> 
> Another question is whenever we want prepare for 0.4 compatibility.
> I think the only use case would be to allow 0.4 clients connect to the 
> 0.6 spice server.  Wasn't the plan to upgrade the clients instead?

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 will still produce a major 2 protocol stream though, so clients must
be >= 0.6.0. I don't think this is a big problem, as clients can be
upgraded before a cluster in an upgrade situation anyway.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's a suicidal shark-wrestling househusband fleeing from a secret government 
programme. She's a plucky tomboy lawyer on the trail of a serial killer. They 
fight crime!