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.
take care,
Gerd
