From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Christian S. Lima" <christiansantoslima21@gmail.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
~lkcamp/patches@lists.sr.ht, richard120310@gmail.com
Subject: Re: [PATCH v8] rust: transmute: Add methods for FromBytes trait
Date: Mon, 07 Jul 2025 14:14:43 +0900 [thread overview]
Message-ID: <DB5KEWX9EJ2Q.3CX5EGS66OVHH@nvidia.com> (raw)
In-Reply-To: <20250624042802.105623-1-christiansantoslima21@gmail.com>
Hi Christian,
Thanks for this version! (and sorry for being late to come back to it) I
think it looks pretty good and could adapt the nova-core code to use it
without any issue. A few comments inline:
On Tue Jun 24, 2025 at 1:28 PM JST, Christian S. Lima wrote:
> The two methods added take a slice of bytes and return those bytes in a
> specific type. These methods are useful when we need to transform the
> stream of bytes into specific type.
>
> The `FromBytesSized` trait was added to make it easier to implement other
> user defined types within the codebase. With the current implementation,
> there's no way to interact without implementing `from_bytes` and
> `from_mut_bytes`for every new type, and this would end up generating a lot
> of duplicate code. By using FromBytesSized as a proxy trait, we can avoid
> this without generating a direct dependecy. If necessary, the user can
nit: s/dependecy/dependency.
<snip>
> diff --git a/rust/kernel/transmute.rs b/rust/kernel/transmute.rs
> index 1c7d43771a37..832c65a1239c 100644
> --- a/rust/kernel/transmute.rs
> +++ b/rust/kernel/transmute.rs
> @@ -9,27 +9,115 @@
> ///
> /// It's okay for the type to have padding, as initializing those bytes has no effect.
> ///
> +/// # Examples
> +///
> +/// ```
> +/// use kernel::transmute::FromBytes;
> +///
> +/// let foo = [1, 2, 3, 4];
> +///
> +/// let result = u32::from_bytes(&foo)?;
> +///
> +/// #[cfg(target_endian = "little")]
> +/// assert_eq!(*result, 0x4030201);
> +///
> +/// #[cfg(target_endian = "big")]
> +/// assert_eq!(*result, 0x1020304);
> +/// ```
> +///
> /// # Safety
> ///
> /// All bit-patterns must be valid for this type. This type must not have interior mutability.
> -pub unsafe trait FromBytes {}
> +pub unsafe trait FromBytes {
> + /// Converts a slice of bytes to a reference to `Self` when possible.
Let's elaborate on when it is "possible", i.e. the reference is properly
aligned, and the size of the slice is equal to that of `T`. Let's also
clarify that `None` is returned in other cases.
> + fn from_bytes(bytes: &[u8]) -> Option<&Self>;
> +
> + /// Converts a mutable slice of bytes to a reference to `Self` when possible.
Same here.
> + fn from_mut_bytes(bytes: &mut [u8]) -> Option<&mut Self>
`from_bytes_mut` sounds like a more idiomatic name for this method.
> + where
> + Self: AsBytes;
> +}
Note that `samples/rust/rust_dma.rs` will fail to compile due to this
change - you must make it derive `FromBytesSized` instead. There may be
other implementors of `FromBytes` so please make sure to track and
update them to avoid breaking the build.
nova-next also adds new implementations of `FromBytes`, and since they
are not in mainline yet this will make it harder to adapt them... I see
two possible solutions if we want this for the next cycle:
- Take this patch into nova-next and update `FromBytes` implementations
in lockstep,
- Add temporary default implementations for `from_bytes` and
`from_mut_bytes` that simply return `None` so current implementors
keep building.
>
> -macro_rules! impl_frombytes {
> +/// Just a proxy trait for FromBytes, if you need an implementation for your type use this instead.
Let's explain the reason for having this type (provide an
auto-implementation of `FromBytes`'s methods for all sized types),
otherwise it may be confusing.
> +///
> +/// # Safety
> +///
> +/// All bit-patterns must be valid for this type. This type must not have interior mutability.
> +pub unsafe trait FromBytesSized: Sized {}
> +
> +macro_rules! impl_frombytessized {
> ($($({$($generics:tt)*})? $t:ty, )*) => {
> // SAFETY: Safety comments written in the macro invocation.
> - $(unsafe impl$($($generics)*)? FromBytes for $t {})*
> + $(unsafe impl$($($generics)*)? FromBytesSized for $t {})*
> };
> }
>
> -impl_frombytes! {
> +impl_frombytessized! {
> // SAFETY: All bit patterns are acceptable values of the types below.
> u8, u16, u32, u64, usize,
> i8, i16, i32, i64, isize,
>
> // SAFETY: If all bit patterns are acceptable for individual values in an array, then all bit
> // patterns are also acceptable for arrays of that type.
> - {<T: FromBytes>} [T],
> - {<T: FromBytes, const N: usize>} [T; N],
> + {<T: FromBytesSized, const N: usize>} [T; N],
> +}
> +
> +// SAFETY: All bit patterns are acceptable values of the types and in array case if all bit patterns
SAFETY: The `FromBytesSized` implementation guarantees that all bit
patterns ...
> +// are acceptable for individual values in an array, then all bit patterns are also acceptable
> +// for arrays of that type.
I don't think this implementation takes care of arrays?
next prev parent reply other threads:[~2025-07-07 5:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-24 4:28 Christian S. Lima
2025-06-25 2:39 ` kernel test robot
2025-07-07 5:14 ` Alexandre Courbot [this message]
2025-07-14 22:16 ` Christian
2025-07-22 14:06 ` Alexandre Courbot
2025-07-25 18:37 ` Christian
2025-07-26 2:57 ` Alexandre Courbot
2025-07-27 1:37 ` Kane York
2025-07-28 19:39 ` Christian
2025-07-28 21:21 ` K. York
2025-08-01 12:26 ` Alexandre Courbot
2025-08-01 15:35 ` Miguel Ojeda
2025-08-01 17:47 ` Christian
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=DB5KEWX9EJ2Q.3CX5EGS66OVHH@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=christiansantoslima21@gmail.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=richard120310@gmail.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=~lkcamp/patches@lists.sr.ht \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®