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
al...@redhat.com alexander.lars...@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!
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
