[Qemu-devel] how to handle QOM 'container' objects whose contents depend on QOM properties?

[Peter Maydell <peter.maydell@linaro.org>]

[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