On 6 February 2018 at 19:04, Eduardo Habkost <ehabk...@redhat.com> 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
