mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Christian" <christiansantoslima21@gmail.com>
Cc: "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 v7] rust: transmute: Add methods for FromBytes trait
Date: Tue, 17 Jun 2025 10:15:37 +0900	[thread overview]
Message-ID: <DAOESYD6F287.3U3M64X0S1WN5@nvidia.com> (raw)
In-Reply-To: <CABm2a9cs+pTT49GW28QViwaK-VT3=Y+sV209-Lk5S_YxEnXv+Q@mail.gmail.com>

On Tue Jun 17, 2025 at 4:57 AM JST, Christian wrote:
>> We can, however, use a proxy trait that provides an implementation of
>> `FromBytes` for any type that is `Sized`:
>>
>>     pub unsafe trait FromBytesSized: Sized {}
>>
>>     unsafe impl<T> FromBytes for T
>>     where
>>         T: FromBytesSized,
>>     {
>>         fn from_bytes(bytes: &[u8]) -> Option<&Self> {
>>             if bytes.len() == core::mem::size_of::<Self>()
>>                 && (bytes.as_ptr() as usize) % core::mem::align_of::<Self>() == 0
>>             {
>>                 let slice_ptr = bytes.as_ptr().cast::<Self>();
>>                 unsafe { Some(&*slice_ptr) }
>>             } else {
>>                 None
>>             }
>>         }
>>
>>         fn from_mut_bytes(bytes: &mut [u8]) -> Option<&mut Self>
>>         where
>>             Self: AsBytes,
>>         {
>>             if bytes.len() == core::mem::size_of::<Self>()
>>                 && (bytes.as_mut_ptr() as usize) % core::mem::align_of::<Self>() == 0
>>             {
>>                 let slice_ptr = bytes.as_mut_ptr().cast::<Self>();
>>                 unsafe { Some(&mut *slice_ptr) }
>>             } else {
>>                 None
>>             }
>>         }
>>     }
>>
>> You can then implement `FromBytesSized` for all the types given to
>> `impl_frombytes!`.
>>
>> The main benefit over the `impl_frombytes!` macro is that `FromBytesSized` is
>> public, and external users can just implement it on their types without having
>> to provide implementations for `from_bytes` and `from_mut_bytes` which would in
>> all likelihood be identical to the ones of `impl_frombytes!` anyway. And if
>> they need something different, they can always implement `FromBytes` directly.
>>
>> For instance, the failing tests in `dma.rs` that I mentioned above can be fixed
>> by making them implement `FromBytesSized` instead of `FromBytes`.
>
> Hmm... I can change the implementation for this, but I think the idea
> behind `FromBytes` and `AsBytes` is that they are the default
> implementation and other parts adapt to them. Also, in the case of
> Slices, since we'll use only `Sized` types, do we just abort the
> conversion for them? If the maintainers are ok, I don't mind tho.

No, for slices you just keep the implementation you currently have,
which works just fine. The idea of `FromBytesSized` is to provide a
sensible default implementation for most users who just want to morph a
stream of bytes into a given struct type.

Or if that is still unclear, consider the following doctest in `dma.rs`
that fails with this patch:

    struct MyStruct { field: u32, }

    // SAFETY: All bit patterns are acceptable values for `MyStruct`.
    unsafe impl kernel::transmute::FromBytes for MyStruct{};
    // SAFETY: Instances of `MyStruct` have no uninitialized portions.
    unsafe impl kernel::transmute::AsBytes for MyStruct{};

It fails because the `FromBytes` implementation for `MyStruct` does not provide
a definition for `from_bytes` and `from_mut_bytes`. Fixing this is just a
matter of changing the `impl FromBytes` into `impl FromBytesSized`. But without
the latter, how do you make this example build without providing a definition
of `from_bytes` and `from_bytes_mut`?

  reply	other threads:[~2025-06-17  1:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-15  7:20 Every2
2025-06-15  9:34 ` Miguel Ojeda
2025-06-16 20:07   ` Christian
2025-06-16 20:42     ` Miguel Ojeda
2025-06-16 21:11       ` Christian
2025-06-16 21:23         ` Miguel Ojeda
2025-06-18 19:29           ` Benno Lossin
2025-06-19 19:31             ` Miguel Ojeda
2025-06-15 17:12 ` kernel test robot
2025-06-16  8:09 ` Alexandre Courbot
2025-06-16 19:57   ` Christian
2025-06-17  1:15     ` Alexandre Courbot [this message]
2025-06-17  1:55       ` Christian
2025-06-17  7:39         ` Alexandre Courbot

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=DAOESYD6F287.3U3M64X0S1WN5@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®