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

[Peter Maydell]

On 6 February 2018 at 19:04, Eduardo Habkost <address@hidden> wrote:
> On Tue, Feb 06, 2018 at 06:18:25PM +0000, Peter Maydell wrote:
>> 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?

The "forwarding properties" bit is the one I'm hitting at the
moment. armv7m creates the CPU object, but it's really the
SoC which creates armv7m that wants to set various properties
on the CPU. (The CPU properties being set are things like
"initial vector address" which in real hardware are set by
the SoC hard-wiring various config signals on the core to 1 or 0.)
So I'd end up needing to manually forward a lot of properties
which are implemented in the cpu object but exposed to the
rest of the system via the armv7m wrapper.

It's also a bit weird because in the limit case you end up
doing nothing in init and postponing it all to realize,
at which point we're back to single-phase init. I don't
much like the "needed to configure this thing" design looking
different from the "simple nonconfigurable thing" design.
If nothing else, it makes it harder to convert from one to
the other when we add a new SoC or whatever.

thanks
-- PMM