On Sun, Aug 26, 2012 at 11:51 PM, Anthony Liguori <[email protected]> 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. > >
