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 not. 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.