[PATCH 00/18] qapi/qom: QAPIfy object-add
Paolo Bonzini
pbonzini at redhat.com
Thu Dec 3 11:11:40 UTC 2020
On 02/12/20 18:35, Kevin Wolf wrote:
>> Could we have an intermediate state that doesn't require any
>> duplication and thus have no separate code paths that could
>> diverge?
>
> The one requirement we have for an intermediate state is that it
> supports both interfaces: The well-know create/set properties/realize
> dance, and a new DeviceClass method, say .create(), that takes the
> configuration in parameters instead of relying on previously set
> properties.
>
> I assumed two separate implementations of transferring the configuration
> into the internal state. On second thought, this assumption is maybe
> wrong.
>
> You can implement the new method as wrapper around the old way: It could
> just set all the properties and call realize. Of course, you don't win
> much in terms of improving the class implementation this way, but just
> support the new interface, but I guess it can be a reasonable
> intermediate step to resolve complicated dependencies etc.
I sketched something at https://wiki.qemu.org/Features/QOM-QAPI_integration.
The main difference with what we discussed so far is that it doesn't
subsume the complete/realize step, only the setting of properties. The
idea is that user_creatable_add_type does the following:
- calls an oc->configure method on every superclass of the object
- takes what's left of the input visitor and uses it to set properties
- then calls ucc->complete
So in the end the only new step is the first. If the first two steps
are bundled in a new function object_configure, they can be reused for
devices, machines and accelerators.
The QAPI code generator can also easily wrap them into a C API for QOM
object creation.
I glossed completely over the generation of properties within the QAPI
code generator. Making properties read-only (or, in the
field-properties world, having a default allow_set of "return false") is
already a nice improvement over
> It would be much nicer to do the wrapper the other way round, i.e.
> setting properties before the device is realized would update a
> configuration struct and realize would then call .create() with that
> struct. To me, this sounds much harder, though also a more useful state.
This sounds much harder. However, based on the RngEgd sample, going
from a basic QAPI struct to a full conversion is not too hard and makes
code shorter. So it's win-win even though it's human work.
Paolo
More information about the libvir-list
mailing list