Re: [PATCH 02/10] rust: qom: add reference counting functionality

[Zhao Liu <zhao1.liu@intel.com>]

Hi Paolo,

On Fri, Jan 17, 2025 at 08:39:55PM +0100, Paolo Bonzini wrote:
> Date: Fri, 17 Jan 2025 20:39:55 +0100
> From: Paolo Bonzini <pbonzini@redhat.com>
> Subject: [PATCH 02/10] rust: qom: add reference counting functionality
> X-Mailer: git-send-email 2.47.1
> 
> Add a smart pointer that allows to add and remove references from
> QOM objects.  It's important to note that while all QOM objects have a
> reference count, in practice not all of them have their lifetime guarded
> by it.

About the background, I have a maybe common question...why Rust needs
extra reference count guarding?

For C side, I notice for child objects, which may be totally embedded in
parent object, or may be pointed to by a pointer member in parent object
(like pl011's clock), they usually become the Child<> property of their
parents by object_initialize_child() (for embedded child) or
object_property_add_child() (for child pointer).

And both these 2 interfaces will increase the ref count in
object_property_try_add_child(). With ref count increasing, it seems
that the Child<> property also express the meaning like "the child
object is 'owned' by its parent".

So, what are the benefits of `Owned` when we also creates Child<>
relationship?

Additionally, I felt that the ref count may be a bit confusing. After
creating Child<> property, the child object's ref count is sometimes 1,
and other times it's 2:

 * With object_initialize_child(), child's ref count is 1.

 * With object_property_add_child() (usually after a object_new() to
   create child first):

   - sometimes user will call object_unref(), and then the ref count is 1.
     E.g., x86_cpu_apic_create() in target/i386/cpu-apic.c.

   - sometimes no object_unref(), then ref count is 2.
     E.g., exynos4210_realize() in hw/arm/exynos4210.c, creats "cortex-a9".

> Embedded objects, specifically, are confined to the lifetime of
> the owner.
> 
> When writing Rust bindings this is important, because embedded objects are
> *never* used through the "Owned<>" smart pointer that is introduced here.

From this description, I understand your goal is:

 * For embedded child object, its lifetimer is managed by its parent
   object, through Child<> for the most cases.

 * For non-embedded child - a pointer/reference in parent object, its
   lifetimer is managed by `Owned<>` (and with Child<>).

Am I right?

Thanks,
Zhao