[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 02/10] rust: qom: add reference counting functionality
From: |
Zhao Liu |
Subject: |
Re: [PATCH 02/10] rust: qom: add reference counting functionality |
Date: |
Sun, 26 Jan 2025 23:15:41 +0800 |
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
- [RFC PATCH 00/10] rust: remaining part of qdev bindings, Paolo Bonzini, 2025/01/17
- [PATCH 01/10] rust: qemu-api: add sub-subclass to the integration tests, Paolo Bonzini, 2025/01/17
- [PATCH 02/10] rust: qom: add reference counting functionality, Paolo Bonzini, 2025/01/17
- [PATCH 03/10] rust: qom: add object creation functionality, Paolo Bonzini, 2025/01/17
- [PATCH 04/10] rust: callbacks: allow passing optional callbacks as (), Paolo Bonzini, 2025/01/17
- [PATCH 06/10] rust: qom: allow initializing interface vtables, Paolo Bonzini, 2025/01/17
- [PATCH 07/10] rust: qdev: make ObjectImpl a supertrait of DeviceImpl, Paolo Bonzini, 2025/01/17