[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] What's our ABI promise for externally visible QOM?
From: |
Markus Armbruster |
Subject: |
[Qemu-devel] What's our ABI promise for externally visible QOM? |
Date: |
Fri, 30 Nov 2018 07:59:59 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
QOM types and the QOM graph are externally visible:
* qom-list-types returns QOM type names and parents.
Fine print: the result is limited to concrete types by default.
Aside: that's the only way to figure out whether a type is abstract.
Interface design fail. The result can optionally be limited to
sub-types of a certain type.
* qom-list-properties returns a named type's static properties.
* qom-list returns an object's properties. This lets clients traverse
the QOM graph.
* qom-get returns a property's value.
* qom-set changes a property's value.
* -object and object-add create a QOM object of a certain type with
certain property values. The type must be a sub-type of
"user-creatable".
* Types are identified by name.
* Objects and properties are identified by QOM path. An absolute QOM
paths is the path within the composition tree starting at the root.
Partial paths are a convenience you don't want to understand.
What promises do we make regarding the stability / backward
compatibility of these externally visible entities?
The QMP command documentation is silent on it. A user could reasonably
assume that the general QMP stability promise extends to all of QOM.
Does it?
Was that the intent when we created qom-list, qom-set, qom-get?
Andreas, do you remember?
Is it practical given the current state of affairs?
Is it a good idea?
- [Qemu-devel] What's our ABI promise for externally visible QOM?,
Markus Armbruster <=