Re: [Qemu-devel] [PATCH 06/22] char: add a /chardevs container

[Paolo Bonzini]

On 10/02/2017 13:59, Marc-André Lureau wrote:
>     > But if you unparent with the last ref, you remove the burden of knowing
>     > if the object has been parented from the user. I don't see why that
>     > would conflict with object_unparent(), you could still unparent(), and
>     > keep the object referenced somewhere else.
> 
>     Isn't that exactly why you want them to be different?  unparent can do
>     much more than unref, for example in the case of a device it will also
>     unrealize it and destroy all buses underneath it.  Because the device
> 
> Shouldn't the last unref also unrealize/destroy everything?

How could someone say they have the "last unref"?  They didn't get that
reference from anywhere, the reference is owned by the parent object's
child property.

>     and bus have a circular reference, you cannot trigger the magic unparent
>     behavior just by unref'ing the device.
> 
> Whoo, we have circular references on purposes? Is this lifecycle
> documented somewhere? I wonder the rationale behind it.

The same as Libreoffice: we had a model with no reference counting (just
"qdev_free") and we tried to adapt it to QOM's reference counting model,
in our case by exploiting the object tree.

>     There are just two cases:
> 
>     - destruction immediately after creation, e.g. on error: new/unref
> 
>     - successful creation: new/add_child/unref, unparent when deleting
> 
>     and it's simpler to remember these two than to add magic behavior.
> 
> That doesn't change the problem, the user may not know if the object is
> parented.

If the user got a reference for himself via object_ref or object_new, it
must use object_unref.

If the user wants to remove public knowledge of an object, then they
must use object_unparent.  If the object is not parented, there's a
violation of QOM rules somewhere.

Paolo