qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-2.5 0/4] Expose ErrorClass through introspec


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH for-2.5 0/4] Expose ErrorClass through introspection
Date: Thu, 12 Nov 2015 11:48:21 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Eric Blake <address@hidden> writes:

> I noticed that introspection was not documenting either
> qmp_capabilities nor the ErrorClass enum.  I think this is worth
> fixing for 2.5 when introspection is brand new, so that if we later
> extend the ErrorClass enum or add future capability negotiation (and
> in particular if such additions get backported in downstream builds),
> a client will be able to use introspection to learn whether the new
> features are supported, regardless of the qemu version.
>
> Note that this also adds qmp_capabilities to 'query-commands'.
>
> Yes, this is borderline, and you may decide that it doesn't deserve
> to be called a bug and should wait for 2.6.

Two entirely separate issues: introspecting qmp_capabilities and
introspecting error classes.  This reply is about the former.  I'll
discuss the latter in a separate message.

Introspecting qmp_capabilities with query-qmp-schema is kind of
academic, because by the time you can query-qmp-schema, you're already
done using qmp_capabilities.  That's why docs/qmp-spec.txt nails down
qmp_capabilities, unlike other commands.  Unfortunately, it's a bit
screwy.  Let's have a closer look.

Right after connect, the server sends a greeting that includes a list of
available capabilities (docs/qmp-spec.txt section 2.2 Server Greeting),
currently none.

The only valid command then is qmp_capabilities (section 4. Capabilities
Negotiation).  The command is meant to let clients enable capabilities
from the greeting, but we've neglected to specify how.  Fortunately, QMP
rejects all arguments, so we can still fix that by adding optional
arguments, either a list of capabilities to enable, or a (boolean)
argument for each capability.

My point is: unlike other commands, qmp_capabilities is baked into the
protocol.  Introspection is useful to examine *variable* aspects.  With
the hole in the protocol specification plugged, the only variable aspect
of qmp_capabilities are the capabilities, and the practical way to
introspect those is the server greeting.

Qapifying qmp_capabilities can make sense regardless.  But why does it
need to be rushed into 2.5 then?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]