Re: [Qemu-devel] [PATCH 00/39] Delay destruction of memory regions to instance_finalize

[Anthony Liguori <anthony@codemonkey.ws>]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Wed, Jun 05, 2013 at 07:53:05AM -0500, Anthony Liguori wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> writes:
>> 
>> > On Wed, Jun 05, 2013 at 11:50:52AM +0200, Andreas Färber wrote:
>> >> Am 04.06.2013 20:51, schrieb Paolo Bonzini:
>> >> > This series changes all PCI devices (the sole to support hotplug
>> >> > _and_ use MemoryRegions) to do memory_region_del_subregion at
>> >> > unrealize time, and memory_region_destroy at instance_finalize
>> >> > time.
>> >> 
>> >> The general idea looks good.
>> >> 
>> >> Could you please follow-up with a patch that switches from exit to
>> >> unrealize?
>> >
>> > What do you guys think about changing the name to something
>> > else e.g. "free" or "destroy"?
>> 
>> exit/unrealize != free/destroy.
>> 
>> You don't actually free anything.  See 00/39 in this series for a
>> precise description.
>
> That's where I got this. It says:
> "instance_finalize will reclaim the memory"

I'm not sure what you're talking about.

There are two callbacks: exit and instance_finalize.

exit() is called to disconnect the device to the guest.  Andreas is
proposing renaming it to unrealize.

Ideally, reset() would be implemented as a combination of calls to
unrealize() + realize() (or exit() + init() as they are named today).

Nothing should be freed in exit.

instance_finalize is only called once, before the object is freed().  It
should be used to release resources associated with the object.

Paolo is using this to destroy memory regions.  Normally this callback
is never used because child objects are automatically handled by QOM.

"finalize" is the standard name of the hook that gets called before
garbage collection as Andreas previously pointed out.  It's this way in
Java, Python, C#, etc.

Regards,

Anthony Liguori

>
>> > http://dictionary.cambridge.org/spellcheck/american-english/?q=unrealize
>> 
>> English is a fluid language.  I wouldn't worry too much about that.
>> 
>> Regards,
>> 
>> Anthony Liguori
>
> Well I am not worried about English at all.
> I'm just confused by the function naming, and
> I think it can be improved.
>
> Can we have names actually say what a function is
> doing? There's no need to use ambiguous terms and then
> document what they mean.
>
>
>> > I can do it easily if people agree.
>> >
>> >> use BUS(), PCI_DEVICE() etc. to hide this.
>> >> 
>> >> Andreas
>> >> 
>> >> -- 
>> >> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>> >> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg