qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] What's our ABI promise for externally visible QOM?


From: Andreas Färber
Subject: Re: [Qemu-devel] What's our ABI promise for externally visible QOM?
Date: Fri, 30 Nov 2018 12:59:17 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0

Am 30.11.18 um 07:59 schrieb Markus Armbruster:
> 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?

Mainly we agreed on not changing the type of an existing property for
backwards compatibility (e.g., don't switch between int and string,
change the property name then). More difficult will be structs in that
regard - does adding a field count as changing the type? Adding and
removing properties should be okay, as it can be discovered or results
in a detectable error. Don't recall we made any other promises, but I
might've forgotten something in this ad-hoc list.

Regards,
Andreas

> 
> 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?
> 


-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)



reply via email to

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