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

[Gerd Hoffmann]

On 08/27/10 19:42, Alexander Larsson wrote:
> On Fri, 2010-08-27 at 17:28 +0200, Gerd Hoffmann wrote:
>> Hi,
>>
>>> 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.
>>
>> Point.
>>
>>> I'll note that this switch is really only about migration compatibility.
>>
>> Any reason to add this now?  We could delay it until we actually hit a
>> migration compatibility issue.
>
> Don't we have any migration incompatibilities with 0.4? Anyway, its
> probably ok to delay this until we need to call it from qemu.

Well.  On one hand there are quite a few compatibility issues.  On the 
other hand there is no 0.4 spice server library with the current library 
API.  Thus an API to handle compatibility doesn't buy us anything for 
0.4 compatibility.  Except in case we want the upstream spice server 
speak the 0.4 wire protocol, then we'll need some way to flip the switch 
of course.

When thinking about compatibility for the future:  Different changes 
have different compatibility implications.  Picking a few examples:

(1) WAN support.  Wire protocol changes.  Spice server and spice client 
are affected.  Compatibility will be handled with a new minor number for 
the display channel (well, would have been in case the wire protocol had 
been declared stable before adding wan support).  In case both server 
and client support the new minor wan compression can be used.  Also 
there are a few new functions to configure wan support.  Those can be 
handled either via " 0x000503 in the code or by requiring a recent 
enough spice library in via pkgconfig.

(2) New raster op, say for better Render support.  That one is tricky. 
It affects the guest drivers and the spice client (also spice server for 
local rendering).  We don't have feature negotiation between guest and 
client though.  Also the client capabilities can change at runtime in 
case different client versions are used to connect to the spice server. 
  QXL most likely isn't affected at all as it just passes the commands 
as-is from the guest to the server.  Also there is no need to save 
additional state for migration.

Nevertheless QXL might need a way to signal to the guest whenever the 
new op can be used or not, so the admin can enable/disable the feature 
depending on whenever all installed spice clients can handle the new op 
or not.

Another way to handle compatibility might be to handle ops the client 
doesn't know about on the server side.  Problem is that you'll have to 
xfer the resulting image instead of the op to the client (needs 
bandwidh).  Which might be ok for relatively simple ops.  For more 
complex stuff (think 3D) it probably isn't.

(3) New interfaces.  Easy.  Needs new code on the qemu side anyway.  For 
compatibility it can be wrapped into "#if SPICE_SERVER_VERSION >= $number".

(4) Optional stuff.  We already have one optional (although 
experimental) feature:  The tunnel, enabled/disabled at server compile 
time.  There might come more.  Smart card support maybe?  Depends that 
on external libraries which we might want to make a compile time option?

For these a feature bitmask would make sense IMHO, although that of 
course isn't the only way to deal with it.  For tunnel support trying to 
register a tunnel interface will simply fail.  Workable, although 
knowing in advance without having to try+fail would be nice to have. 
For the smartcard bits Alon has a "return the supported chardevs" 
functions which can handle it.  Works fine, although for chardevs only. 
  With a feature bitmap we would have one api for everything.

cheers,
   Gerd