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

[Igor Mammedov <imammedo@redhat.com>]

On Tue, 6 Feb 2018 18:18:25 +0000
Peter Maydell <peter.maydell@linaro.org> 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.)
[...] 

> 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.
hw/arm/aspeed_soc.c looks rather clean and readable.

This types would be used only by boards and won't
be visible outside of QEMU, aren't they?
If so why would be large number of QOM types of a concern here?

> 
> thanks
> -- PMM
>