On Tue, Feb 19, 2013 at 4:12 AM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 8 February 2013 04:03, Peter Crosthwaite > <peter.crosthwa...@xilinx.com> wrote: >> The DeviceState *mptimer var in a9mp_priv_state was only used by the init >> function and had no reason for persistence. Made a local variable and removed >> from state struct. > > Nope. We're a container object, we can't just forget about our > children. Granted (like many QEMU devices) we don't actually have > any implementation of device destruction, but in principle we > need to keep hold of a pointer to the things we create. >
Shouldn't this be handled on the QOM level? Rather than every device needing to explicitly track its children and propagate destructor calls, QOM should just do this for me. Then as the container, when my destructor is called my childrens is automatically called for me. Keeping these pointers for the sake of heirachy strikes me as replication of the QOM canonical path and its data structures. Plan B is container devices such as this could call object_property_add_child() when they create their children. Then they can get that pointer back later with object_property_get_link(). This is more robust, but more verbose as devices still need to manage their childrens destruction. However that may be needed as whether or nor parent destruction implies child destruction is not clear to me. I think either solution is preferrable to adding pointers to DeviceState for children, as that linkage is already made by QOM. CC Andreas, as his comment on patch 6 ties in. Regards, Peter > -- PMM >
