From: Boqun Feng <boqun.feng@gmail.com>
To: Dirk Behme <dirk.behme@de.bosch.com>
Cc: rust-for-linux@vger.kernel.org, ojeda@kernel.org,
daniel.almeida@collabora.com, Gary Guo <gary@garyguo.net>,
Andreas Hindborg <a.hindborg@kernel.org>,
Alice Ryhl <aliceryhl@google.com>,
Trevor Gross <tmgross@umich.edu>
Subject: Re: [PATCH v3 2/2] rust: types: `Opaque` doc: Add some destructor description
Date: Wed, 5 Mar 2025 07:25:10 -0800 [thread overview]
Message-ID: <Z8hs1s5Mf1TMedIv@tardis> (raw)
In-Reply-To: <20250305053438.1532397-2-dirk.behme@de.bosch.com>
On Wed, Mar 05, 2025 at 06:34:38AM +0100, Dirk Behme wrote:
> In the discussion [1] some `Opaque` documentation updates have
> been proposed. In that discussion it was clarified that `Opaque`
> is intended to be used for (partial) uninitialized or changing C
> structs. And which consequences this has for using raw pointers
> or the destruction. Improve the `Opaque` documentation by adding
> these conclusions from that discussion.
>
> Suggested-by: Daniel Almeida <daniel.almeida@collabora.com>
> Link: https://lore.kernel.org/rust-for-linux/F8AB1160-F8CF-412F-8B88-4C79D65B53A1@collabora.com/ [1]
> Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
>
> ---
> Changes in v3:
> * Add the "terse" proposals.
> * Move the non-linkage artifact from patch 1/2 to here.
>
> rust/kernel/types.rs | 26 +++++++++++++++++++++-----
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/rust/kernel/types.rs b/rust/kernel/types.rs
> index af30e9c0ebccb..f370cdb48a648 100644
> --- a/rust/kernel/types.rs
> +++ b/rust/kernel/types.rs
> @@ -271,17 +271,33 @@ fn drop(&mut self) {
>
> /// Stores an opaque value.
> ///
> -/// [`Opaque<T>`] is meant to be used with FFI objects that are never interpreted by Rust code.
> +/// [`Opaque<T>`] opts out of the following Rust language invariants for the contained `T`
> +/// by using [`UnsafeCell`]:
> ///
> -/// It is used to wrap structs from the C side, like for example `Opaque<bindings::mutex>`.
> -/// It gets rid of all the usual assumptions that Rust has for a value:
> +/// * Initialization invariant - the contained value is allowed to be uninitialized and
> +/// contain invalid bit patterns.
> +/// * Immutability invariant - [`Opaque<T>`] allows interior mutability.
> +/// * Uniqueness invariant - [`Opaque<T>`] allows aliasing of shared references.
> +///
> +/// Further, [`Opaque<T>`] is `!Unpin` and will not run the drop method of the contained `T`
> +/// when dropped.
I would move "will not run the drop method of contained `T` when
dropped" to the "Initialization invariant" above because they are
logically related.
Regards,
Boqun
> ///
> -/// * The value is allowed to be uninitialized (for example have invalid bit patterns: `3` for a
> -/// [`bool`]).
> +/// [`Opaque<T>`] is meant to be used with FFI objects that are never interpreted by Rust code.
> +/// It is used to wrap structs from the C side, like for example `Opaque<bindings::mutex>`.
> +/// This is useful for C structs that are not fully initialized (yet) or might change their
> +/// content from C side at runtime. [`Opaque<T>`] gets rid of all the usual assumptions that
> +/// Rust has for a value of type `T`:
> +///
> +/// * The value is allowed to be uninitialized or invalid (for example have invalid bit patterns:
> +/// `3` for a [`bool`]).
> +/// * By dereferencing a raw pointer to the value you are unsafely asserting that the value is
> +/// valid *right now*.
> /// * The value is allowed to be mutated, when a `&Opaque<T>` exists on the Rust side.
> /// * No uniqueness for mutable references: it is fine to have multiple `&mut Opaque<T>` point to
> /// the same value.
> /// * The value is not allowed to be shared with other threads (i.e. it is `!Sync`).
> +/// * The destructor of [`Opaque<T>`] does *not* run the destructor of `T`, as `T` may
> +/// be uninitialized, as described above.
> ///
> /// This has to be used for all values that the C side has access to, because it can't be ensured
> /// that the C side is adhering to the usual constraints that Rust needs.
> --
> 2.48.0
>
next prev parent reply other threads:[~2025-03-05 15:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Qag_hE1Uvj0nZB8Bf_MPl4UUT5v6CzPHCzseIqIvESgDKvayvNPlhVBSSS-HVW_ubhQh1GJrGH3eU-8Fy84YOQ==@protonmail.internalid>
2025-03-05 5:34 ` [PATCH v3 1/2] rust: types: `Opaque` doc: Add some intra doc linkage Dirk Behme
2025-03-05 5:34 ` [PATCH v3 2/2] rust: types: `Opaque` doc: Add some destructor description Dirk Behme
2025-03-05 7:47 ` Andreas Hindborg
2025-03-05 15:39 ` Boqun Feng
2025-03-05 17:32 ` Andreas Hindborg
2025-03-05 18:49 ` Boqun Feng
2025-03-05 21:07 ` Andreas Hindborg
2025-03-06 6:01 ` Boqun Feng
2025-03-06 9:42 ` Andreas Hindborg
2025-03-06 10:45 ` Benno Lossin
2025-03-07 0:00 ` Boqun Feng
2025-03-06 9:48 ` Alice Ryhl
2025-03-07 8:22 ` Andreas Hindborg
2025-03-10 16:20 ` Miguel Ojeda
2025-03-05 15:25 ` Boqun Feng [this message]
2025-03-05 7:41 ` [PATCH v3 1/2] rust: types: `Opaque` doc: Add some intra doc linkage Andreas Hindborg
2025-03-05 8:12 ` Alice Ryhl
2025-03-05 8:40 ` Fiona Behrens
2025-03-10 14:25 ` Miguel Ojeda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z8hs1s5Mf1TMedIv@tardis \
--to=boqun.feng@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=daniel.almeida@collabora.com \
--cc=dirk.behme@de.bosch.com \
--cc=gary@garyguo.net \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.