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
_______________________________________________
Spice-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/spice-devel
