qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Damien Hedde <damien.hedde@greensocs.com>
Cc: "Eduardo Habkost" <eduardo@habkost.net>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>
Subject: Re: qdev instance_init vs realize split
Date: Tue, 15 Feb 2022 11:32:36 +0000	[thread overview]
Message-ID: <CAFEAcA9P7DyYqBCLeTMRSTiw2jYMfQ97vs_u+55nCdov7LDdrw@mail.gmail.com> (raw)
In-Reply-To: <e9bae713-1051-1bf0-5f3a-d9bb61aade8a@greensocs.com>

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.

> This is not a big deal, but given how works the help message generation
> in the monitor, there are difference if the device is user-creatable.
>
> If we leave irqs and mmios declaration in the instance_init(). They
> appear in the help message.
>  > (qemu) device_add ibex-timer,help
>  > ibex-timer options:
>  >   ibex-timer[0]=<child<memory-region>>
>  >   sysbus-irq[0]=<link<irq>>
>  >   timebase-freq=<uint32> -  (default: 10000)
>
> If we delay the declaration in realize(), we only have the declared
> qdev-properties (which is maybe more what we expect at this point):
>
>  > (qemu) device_add ibex-timer,help
>  > ibex-timer options:
>  >   timebase-freq=<uint32> -  (default: 10000)

This seems to me to be a problem with the help message generation.
IRQ and MMIO properties shouldn't be being presented to the user
whether we set them up in instance-init or realize: there is nothing
the user can usefully do with them.

thanks
-- PMM


  parent reply	other threads:[~2022-02-15 11:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15 10:19 qdev instance_init vs realize split Damien Hedde
2022-02-15 11:15 ` Philippe Mathieu-Daudé via
2022-02-15 11:32 ` Peter Maydell [this message]
2022-02-15 13:21   ` Damien Hedde
2022-02-15 13:35     ` Peter Maydell
2022-02-15 16:42       ` Damien Hedde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFEAcA9P7DyYqBCLeTMRSTiw2jYMfQ97vs_u+55nCdov7LDdrw@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=berrange@redhat.com \
    --cc=damien.hedde@greensocs.com \
    --cc=eduardo@habkost.net \
    --cc=f4bug@amsat.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).