[PATCH 00/18] qapi/qom: QAPIfy object-add
Paolo Bonzini
pbonzini at redhat.com
Mon Nov 30 14:58:23 UTC 2020
On 30/11/20 13:25, Kevin Wolf wrote:
> This series adds a QAPI type for the properties of all user creatable
> QOM types and finally makes QMP object-add use the new ObjectOptions
> union so that QAPI introspection can be used for user creatable objects.
>
> After this series, there is least one obvious next step that needs to be
> done: Change HMP and all of the command line parser to use
> ObjectOptions, too, so that the QAPI schema is consistently enforced in
> all external interfaces. I am planning to send another series to address
> this.
>
> In a third step, we can try to start deduplicating and integrating things
> better between QAPI and the QOM implementation, e.g. by generating parts
> of the QOM boilerplate from the QAPI schema.
With this series it's basically pointless to have QOM properties at all.
Instead, you are basically having half of QEMU's backend data model
into a single struct.
So the question is, are we okay with shoveling half of QEMU's backend
data model into a single struct? If so, there are important consequences.
1) QOM basically does not need properties anymore except for devices and
machines (accelerators could be converted to QAPI as well). All
user-creatable objects can be changed to something like chardev's "get a
struct and use it fill in the fields", and only leave properties to
devices and machines.
2) User-creatable objects can have a much more flexible schema. This
means there's no reason to have block device creation as its own command
and struct for example.
The problem with this series is that you are fine with deduplicating
things as a third step, but you cannot be sure that such deduplication
is possible at all. So while I don't have any problems in principle
with the ObjectOptions concept, I don't think it should be committed
without a clear idea of how to do the third step.
In the meanwhile, of course I have no problem with deprecating the
opened and loaded properties.
Paolo
More information about the libvir-list
mailing list