Alberto Garcia <be...@igalia.com> writes:
> On Tue 11 Oct 2016 06:32:39 PM CEST, Markus Armbruster wrote:
>>>> 3) QEMU could advertise that feature to the client. This is probably
>>>> simpler than trying to figure it out from the API. I guess that's
>>>> the idea of 'qmp_capabilities'?
>>> I think that was the idea, though it was never used. If we had used
>>> it, I'm not sure how long the capabilities list would be today. :-)
>> QMP capabilities are for changes in the QMP protocol, not for changes
>> in commands, events and types. The protocol has been good enough so
>> far, thus no capabilities.
> I see. Wouldn't it make sense in general to have a way to ask QEMU
> whether some certain feature is supported?
Feature bits work fine for interfaces that see relatively little change.
Some QEMU interfaces are like that, for instance the QMP protocol
itself. Other interfaces, however, change at a rapid pace. If we tried
to provide a feature bit for every change there, we'd end up with a huge
number of them, almost certainly underdocumented, and most of them not
used by any client. We'd probably fail to provide feature bits for some
of the interface changes, and have "feature X" bits followed some time
later by "feature X, except now it actually works" bits.
Instead, we opted for making external interfaces introspectable, so that
clients can detect stuff whether we thought of the need to detect it or
The first interface with decent introspection is QMP: there's
query-qmp-schema. Changes are easy to detect there as long as they're
*syntactic*: new commands or events, type extensions and so forth. QMP
introspection is blind to purely *semantic* changes, say a string
argument that can now denote a node-name in addition to a filename.
Such changes should be avoided.