Re: [PATCH 00/18] qapi/qom: QAPIfy object-add
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