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