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