On Thu, Dec 03, 2020 at 07:46:29AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > 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.
>
> Well, in some places we already have separate config structs. We have
> NICConf for example, which is typically used like this:
>
> struct USBNetState {
> USBDevice dev;
> [ ... ]
> NICConf conf;
> [ ... ]
> };
>
> and
>
> static Property net_properties[] = {
> DEFINE_NIC_PROPERTIES(USBNetState, conf),
> DEFINE_PROP_END_OF_LIST(),
> };
>
> So I think we could:
>
> (1) move *all* properties into structs.
> (2) generate those structs from qapi schemas.
> (3) generate Property lists (or functions with
> object_class_property_add_*() calls) from qapi
> schema.
>
> We could then convert devices one-by-one without breaking anything
> or needing two code paths essentially doing the same thing in two
> different ways.
Sounds great to me.
This can also work the other way around for devices that weren't
converted yet: we should be able to generate a QAPI schema from
the property lists.
--
Eduardo
