Re: [Qemu-devel] [RFC PATCH 0/9] qom: improve reference counting and hotplug

[liu ping fan]

On Sun, Aug 26, 2012 at 11:51 PM, Anthony Liguori <address@hidden> wrote:
> Right now, you need to pair up object_new with object_delete.  This is
> impractical when using reference counting because we would like to ensure that
> object_unref() also frees memory when needed.
>
> The first few patches fix this problem by introducing a release callback so
> that objects that need special release behavior (i.e. g_free) can do that.
>
> Since link and child properties all hold references, in order to actually free
> an object, we need to break those links.  User created devices end up as
> children of a container.  But child properties cannot be removed which means
> there's no obvious way to remove the reference and ultimately free the object.
>
Why? Since we call _add_child() in qdev_device_add(), why can not we
call object_property_del_child() for qmp_device_del(). Could you
explain it more detail?

> We introduce the concept of "nullable child" properties to solve this.  This 
> is
> a child property that can be broken by writing NULL to the child link.  Today
> we set all /peripheral* children to be nullable so that they can be deleted by
> management tools.
>
> In terms of modeling hotplug, we represent unplug by removing the object from
> the parent bus.  We need to register a notifier for when this happens so that
> we can also remove the parent's child property to ultimately release the 
> object.
>
> Putting it all together, we have:
>
> 1) qmp_device_del will issue a callback to a device.  The default callback 
> will
>    do a forced eject (which means writing NULL to the parent_bus link).
>
> 2) PCI hotplug is a bit more sophisticated in that it waits for the guest to
>    do the ejection.
>
> 3) qmp_device_del will register an eject notifier such that the device gets
>    completely removed.
>
> There's a slightly change in behavior here.  A device is not automatically
> destroyed based on a guest initiated eject.  A management tool must explicitly
> break the parent's link to the child in order for the device to disappear
> completely.  device_del behaves exactly as it does today though.
>
> This is an RFC.  I've tested the series quite a lot (it was hard to get the
> reference counting right) but not enough to apply.  I also don't think the
> series is quite split right and may not bisect cleanly.
>
> I also want to write up a document describing object life cycle since 
> admittedly
> the above is probably not that easy to follow.
>
> I wanted to share this now though because it works and I think the concepts 
> are
> right.
>
>