|
From: | Paolo Bonzini |
Subject: | Re: [PATCH 00/18] qapi/qom: QAPIfy object-add |
Date: | Thu, 3 Dec 2020 12:11:40 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 |
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->completeSo 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
[Prev in Thread] | Current Thread | [Next in Thread] |