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.
