Re: [PATCH 00/18] qapi/qom: QAPIfy object-add

[Eduardo Habkost]

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