Re: qdev instance_init vs realize split

[Damien Hedde <damien.hedde@greensocs.com>]

On 2/15/22 12:32, Peter Maydell wrote:
> On Tue, 15 Feb 2022 at 10:32, Damien Hedde <damien.hedde@greensocs.com> wrote:
>> I'm wondering if there are rules or convention about what we put in the
>> instance_init() vs realize() for simple devices ? (For complex ones we
>> generally have no choice to put everything in realize())
>>
>> For example we can declare irqs and mmios in instance_init() or
>> realize() if they do not depend on some property.
> 
> We don't, unfortunately, have a clear set of conventions for this.
> We really ideally ought to write some up, because the question
> keeps coming up. There are a few absolute rules:
>   * things that can fail must be done in realize
>   * things that depend on property values must be done in realize
>   * things that affect the simulation must be done in realize
>   * if you do something that needs a corresponding manual deinit
>     step in instance_init then you must provide an instance_finalize
>     even if the device would otherwise be "create once, lasts for
>     entire simulation" as many of our devices are
> 
> But in many cases actions can be done in either method, and we
> end up with devices being inconsistent and people wondering whether
> there's a reason for it.
> 
> I vaguely think it would be good to get into the habit of writing
> all our devices to have the full lifecycle code including supporting
> init-realize-unrealize-finalize, but on the other hand that implies
> a bunch of code (unrealize) which is never executed or tested...
> I also suspect we have a bunch of buggy code in realize methods
> which isn't correctly undoing things it has done already in the
> error-exit-from-realize case.

Are you saying that: if an operation like a mmio/irq definition is done 
in realize(), in theory, we should have the unrealize() counterpart ?

Thanks,
--
Damien