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 13:35:17 +0000	[thread overview]
Message-ID: <CAFEAcA-b=7t3-0Hxam+Sfhmv9AFdZ_=qFZXjOxdnqxFkfqwvcg@mail.gmail.com> (raw)
In-Reply-To: <cfca692c-db64-aeaf-73da-3d36655a44d7@greensocs.com>

On Tue, 15 Feb 2022 at 13:21, Damien Hedde <damien.hedde@greensocs.com> wrote:
> Are you saying that: if an operation like a mmio/irq definition is done
> in realize(), in theory, we should have the unrealize() counterpart ?

I'm saying that at the moment we have two categories of device:
 * ones which are intended to be pluggable and so might be
   destroyed at runtime: these have to support the full
   instance_init->realize->unrealize->finalize cycle
 * ones which are only created in machine models and then exist
   for the lifetime of the QEMU process: these have to support
   instance_init->finalize (for the benefit of monitor introspection
   which can create and delete devices in that way) but otherwise
   only need to support the instance_init->realize and don't
   need to handle the unrealize->finalize part

and maybe we should consider whether it would be better to write
all our devices in the same way to handle the full set of
state transitions.

But if we do decide that then we'd need to have a testing framework
that actually exercised the whole lifecycle for all devices, and
it would probably be a lot of work, so maybe it's not worthwhile.

We'd also want where we can to have APIs that arrange to do
the handling of destruction for you. I think the GPIO line
APIs are like this, for instance. That's much less prone to
"forgot to clean it up" bugs.

-- PMM


  reply	other threads:[~2022-02-15 13:44 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
2022-02-15 13:21   ` Damien Hedde
2022-02-15 13:35     ` Peter Maydell [this message]
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='CAFEAcA-b=7t3-0Hxam+Sfhmv9AFdZ_=qFZXjOxdnqxFkfqwvcg@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).