[I've cc'd a fairly random selection of people who I thought might be interested or have an opinion.]
It's fairly common to have a setup where we have a QOM container object (like an SoC) which in turn instantiates a lot of child objects (for all the devices). The neat way of doing this looks like hw/arm/xlnx-zynqmp.c -- in the container's init function, we use object_initialize() to init all the child objects. If the container exposes some properties that are really just being forwarded to one of its children it can set those up in init with object_property_add_alias(). Finally, in realize the container realizes all its children. Unfortunately, this pattern interacts badly with the idea that you might want to use a QOM property to determine aspects of the container that affect what child objects it creates. (Examples would include wanting a "which CPU is this" property on an SoC object, or if the SoC has a couple of variants which maybe have extra devices.) One current approach to that is that instead of init'ing those child objects in the container init, we postpone that to container realize. This looks pretty ugly, and it also means that you can't do "forward this property" using add_alias if the target is the late-inited child (instead you have to have a real property on the container and set the property on the child manually after it's inited). You can see an example of this kind of thing in hw/arm/armv7m.c. Another approach is that instead of having a "what CPU" or "what SoC variant" property on the container, we create one container type per variation. Then instead of "create container, set QOM property to specify variant" the user creates the correct container type for the variant. hw/arm/aspeed_soc.c has an example of this. That looks pretty nice code-wise, but if there are a lot of possible options for the variants it could result in a large number of QOM types. The other popular approach to this is "don't let the container be as configurable as it ideally ought to be"... So, does anybody have a view on what the best way to structure this kind of container object is? I feel like I'm running into the annoyances of the approach that armv7m.c is currently taking, so if there's a better way I'd like to do that instead. thanks -- PMM