Am 03.12.2020 um 12:11 hat Paolo Bonzini geschrieben:
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
I don't think this is an intermediate state like Eduardo wants to have. Creating the object, then setting properties, then realize [1] will fail after your change. But keeping it working was the whole point of the exercise. I'm also not really sure why you go from RngEgdOptions to QObject to a visitor, only to reconstruct RngEgdOptions at the end. I think the class implementations should have a normal C interface without visitors and we should be able to just pass the existing RngEgdOptions object (or the individual values for its fields for 'boxed': false). Kevin [1] Or complete for ucc, but the number of these is small enough that we don't really need any intermediate state, except maybe as a proof of concept for the later qdev conversion.