Re: instance_init() and the realize() functions

[Peter Maydell]

On Sat, 18 Jul 2020 at 09:27, Liviu Ionescu <ilg@livius.net> wrote:
> For me it was difficult to draw a line of what initialisations should be done 
> in .instance_init and what in .realize, but given that .realise is called 
> when the whole hierarchy is ready, it might do links between objects, which 
> are not available when .instance_init is called.

Yeah, we have not been able as a project to come up with a nice
rule for how to do this split. There are a few definite rules:
 * anything that can fail and return an error must go in realize
   (because instance_init has no failure-return mechanism)
 * anything you need to do to set up a QOM property on the
   object must go in instance_init (so that the property can
   be set by the user of the device object before realizing it)
 * anything that changes the state of the simulation must go in
   realize (some QMP monitor commands to introspect objects
   will do instance_init/look at object/delete)
but a lot of things could validly go in either method, and we
haven't set a convention for those cases. (There's a bunch
of inconclusive discussions in the mailing list archives.)

> A simple rule would be for .instance_init to ensure that all members have 
> default values and properties associated with them, and defer all functional 
> initialisations to .realize.

Yeah, this is a reasonable default rule. Note that for a lot
of device state struct members (where they correspond to guest
registers state), you want to set their values in the
device's reset method, not in instance_init or realize.
That's because the guest-visible register state needs to
be set back to its initial value on a system reset anyway,
and QEMU guarantees that we will reset a device before
first use.

thanks
-- PMM