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

[Eduardo Habkost <ehabkost@redhat.com>]

On Tue, Feb 06, 2018 at 06:18:25PM +0000, Peter Maydell wrote:
> [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.

My rule of thumb is: if something is configurable (even if it's
just slightly), it belongs to realize.  instance_init is reserved
for stuff that don't take any external input.  If your container
contents are not static, creating the contents is not a task for
instance_init.

But I would like to understand the drawbacks of this approach
better.  So, if the object didn't have any "forward this
property" aliases, would you see other problems with this
approach?

Why exactly those boards need the aliases?  Who sets those alias
properties?  Can we provide helpers that make this task easier?


> 
> 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.

Yeah, this may be reasonable in some cases (e.g. some CPU types),
but it won't always work.

> 
> The other popular approach to this is "don't let the container
> be as configurable as it ideally ought to be"...

I like this approach.  :)

> 
> 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.

-- 
Eduardo