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