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
next prev parent 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).