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