Re: [Qemu-devel] [PATCH v8 18/23] RISC-V VirtIO Machine

[Peter Maydell <peter.maydell@linaro.org>]

On 30 April 2018 at 01:18, Michael Clark <mjc@sifive.com> wrote:
> Quite a bit of our initialization code in several QOM classes allocate
> memory that is not freed. e.g. the PLIC. Usually these functions are only
> run once, but ideally all of the code should be memory clean. i.e. exit
> without leaks. Many programs don't bother with this but I think it is a good
> practice.
>
> Should we use dc->unrealize to point to an unrelalize function that calls
> g_free? Is unrealize the QOM destructor?

unrealize is the destructor, yes, but we currently only use it for
devices that are hot-pluggable (and thus unpluggable). For non-pluggable
devices we currently generally don't worry about giving the objects
a destructor, since it can never be called.

This is a bit weird though, and I think there's a thread on-list
somewhere where there's a proposal that we should (a) document
better the best way to divide tasks between init/realize and
(b) perhaps suggest that devices should init unrealize too.

Board model code is also rather prone to "allocate and never free",
because historically boards didn't have a QOM object to own the
memory they allocated. This is why board code often does
g_new0(MemoryRegion, 1) to allocate MemoryRegions, where device
code would just have a MemoryRegion field in its device struct.
Now that boards have real MachineState objects associated with
them, it is possible to write them the way you write a device --
hw/arm/mps2.c has an example of this. Since again it doesn't have
a destructor there's not much difference in practice, though:
we still rely on the memory being freed on program exit.

thanks
-- PMM