Re: [Qemu-devel] [PATCH 3/9] qbus: remove glib_allocated/qom_allocated and use release hook to free memory

[Andreas Färber]

Am 27.08.2012 16:22, schrieb Anthony Liguori:
> Andreas Färber <address@hidden> writes:
> 
>> I wonder how this is gonna work: The device used to be in charge of
>> tearing down its bus children ... now it neither deletes nor finalizes
>> nor unrefs? Is the while loop even still needed?
>>
>> Wouldn't the busses still have the device as parent, referencing it,
>> blocking device_finalize?
> 
> This has never been right..  Just because a controller goes away, it
> doesn't mean that the devices ought to go away too.
> 
> There are different types of "remove" so let's consider each.
> 
> 1) Guest visible eject: if a controller is ejected, then the guest will
>    obviously see everything behind it get removed too.  This is an
>    emulation detail, not a QOM thing.
> 
> 2) Final deletion: this only happens when all references go away.  If
>    you eject a controller but there are still children that reference
>    it, the controller won't go away.  You actually need to delete each
>    individual disk (or whatever is behind it) in order to break the
>    reference counting.
> 
> The eject notifier could walk the full bus and attempt to break the
> connections but honestly, I'd much prefer that we deprecate the current
> device_del interface and just do everything through QOM properties.
> That would mean manually deleting all of the devices behind the bus if
> that's really what you wanted to do.

I think we're talking about different scenarios here...

I was thinking

PCIHostState has-a PCIBus

(not PCIBus has-a PCIDevice) and final deletion.

In that case I would expect that it must be guaranteed that the device
that created the bus has access to the bus until it destroys it. But
IIUC the PCIHostState, once unparented from its SysBus (bad example!),
has a refcount of 1 (its PCIBus) thereby not being finalized?

I do understand your concept of refcounting matches what Java, .NET,
etc. do for objects but combined with the new QBus I feel this is
blurring the encapsulations and expected semantics of the device-centric
functions we have. To me the uninitfn means "the whole object goes away"
and is incompatible with "part of its children may stay behind if there
are still stray references to them"... we can no longer properly access
them then, only devices have canonical paths, so we'd risk piling up
garbage at runtime.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg