mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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?


  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®