From: John Hubbard <jhubbard@nvidia.com>
To: "Alexandre Courbot" <acourbot@nvidia.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" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>
Cc: Alistair Popple <apopple@nvidia.com>,
Joel Fernandes <joelagnelf@nvidia.com>,
Timur Tabi <ttabi@nvidia.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 1/8] rust: transmute: add `from_bytes_copy` method to `FromBytes` trait
Date: Tue, 26 Aug 2025 17:51:20 -0700 [thread overview]
Message-ID: <a33aff7e-c260-4d7e-ad18-e919706cdbda@nvidia.com> (raw)
In-Reply-To: <20250826-nova_firmware-v2-1-93566252fe3a@nvidia.com>
On 8/25/25 9:07 PM, Alexandre Courbot wrote:
> `FromBytes::from_bytes` comes with a few practical limitations:
>
> - It requires the bytes slice to have the same alignment as the returned
> type, which might not be guaranteed in the case of a byte stream,
> - It returns a reference, requiring the returned type to implement
> `Clone` if one wants to keep the value for longer than the lifetime of
> the slice.
>
> To overcome these when needed, add a `from_bytes_copy` with a default
> implementation in the trait. `from_bytes_copy` returns an owned value
> that is populated using an unaligned read, removing the lifetime
> constraint and making it usable even on non-aligned byte slices.
>
> Reviewed-by: Alice Ryhl <aliceryhl@google.com>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> rust/kernel/transmute.rs | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/rust/kernel/transmute.rs b/rust/kernel/transmute.rs
> index 494bb3b1d059337520efef694fc8952972d44fbf..721dd8254dcedd71ed7c1fc0ee9292950c16c89e 100644
> --- a/rust/kernel/transmute.rs
> +++ b/rust/kernel/transmute.rs
> @@ -78,6 +78,23 @@ fn from_bytes_mut(bytes: &mut [u8]) -> Option<&mut Self>
> None
> }
> }
> +
> + /// Creates an owned instance of `Self` by copying `bytes`.
> + ///
> + /// As the data is copied into a properly-aligned location, this method can be used even if
> + /// [`FromBytes::from_bytes`] would return `None` due to incompatible alignment.
Some very minor suggestions:
This wording less precise than it could be: "as the data is copied" can mean
either "while it is being copied", or "because it is copied". Also, there
should not be a hyphen in "properly aligned".
I'd suggest something like this instead:
/// Unlike [`FromBytes::from_bytes`], which requires aligned input, this
/// method can be used on non-aligned data.
> + fn from_bytes_copy(bytes: &[u8]) -> Option<Self>
> + where
> + Self: Sized,
> + {
> + if bytes.len() == size_of::<Self>() {
> + // SAFETY: `bytes` has the same size as `Self`, and per the invariants of `FromBytes`,
> + // any byte sequence is a valid value for `Self`.
More wording suggestions. How about this:
// SAFETY: we just verified that `bytes` has the same size as `Self`, and per the
// invariants of `FromBytes`, any byte sequence of the correct length is a valid value
// for `Self`.
> + Some(unsafe { core::ptr::read_unaligned(bytes.as_ptr().cast::<Self>()) })
> + } else {
> + None
> + }
> + }
> }
>
> macro_rules! impl_frombytes {
>
I'm unable to find anything wrong with the code itself, and the above are just
tiny nits, so whether or not you apply either or both of the above suggestions,
please feel free to add:
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
thanks,
--
John Hubbard
next prev parent reply other threads:[~2025-08-27 0:51 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-26 4:07 [PATCH v2 0/8] gpu: nova-core: process and prepare more firmwares to boot GSP Alexandre Courbot
2025-08-26 4:07 ` [PATCH v2 1/8] rust: transmute: add `from_bytes_copy` method to `FromBytes` trait Alexandre Courbot
2025-08-26 6:50 ` Benno Lossin
2025-08-27 0:51 ` John Hubbard [this message]
2025-08-28 7:05 ` Alexandre Courbot
2025-08-28 11:26 ` Alexandre Courbot
2025-08-28 11:45 ` Miguel Ojeda
2025-08-29 1:51 ` Alexandre Courbot
2025-08-26 4:07 ` [PATCH v2 2/8] gpu: nova-core: firmware: add support for common firmware header Alexandre Courbot
2025-08-27 1:34 ` John Hubbard
2025-08-27 8:47 ` Alexandre Courbot
2025-08-27 21:50 ` John Hubbard
2025-08-28 7:08 ` Alexandre Courbot
2025-08-29 0:21 ` John Hubbard
2025-08-28 11:26 ` Miguel Ojeda
2025-09-10 5:44 ` Implicit panics (was: [PATCH v2 2/8] gpu: nova-core: firmware: add support for common firmware header) Alexandre Courbot
2025-09-10 10:00 ` Miguel Ojeda
2025-09-10 13:54 ` Alexandre Courbot
2025-09-10 20:57 ` Miguel Ojeda
2025-09-10 21:36 ` Implicit panics John Hubbard
2025-08-26 4:07 ` [PATCH v2 3/8] gpu: nova-core: firmware: process Booter and patch its signature Alexandre Courbot
2025-08-27 2:29 ` John Hubbard
2025-08-28 7:19 ` Alexandre Courbot
2025-08-29 0:26 ` John Hubbard
2025-08-28 20:58 ` Timur Tabi
2025-08-26 4:07 ` [PATCH v2 4/8] gpu: nova-core: firmware: process the GSP bootloader Alexandre Courbot
2025-08-28 3:09 ` John Hubbard
2025-08-26 4:07 ` [PATCH v2 5/8] gpu: nova-core: firmware: process and prepare the GSP firmware Alexandre Courbot
2025-08-28 4:01 ` John Hubbard
2025-08-28 11:13 ` Alexandre Courbot
2025-08-29 0:27 ` John Hubbard
2025-08-28 11:27 ` Danilo Krummrich
2025-08-29 11:16 ` Alexandre Courbot
2025-08-30 12:56 ` Danilo Krummrich
2025-09-01 7:11 ` Alexandre Courbot
2025-08-26 4:07 ` [PATCH v2 6/8] gpu: nova-core: firmware: use 570.144 firmware Alexandre Courbot
2025-08-28 4:07 ` John Hubbard
2025-08-26 4:07 ` [PATCH v2 7/8] gpu: nova-core: Add base files for r570.144 firmware bindings Alexandre Courbot
2025-08-28 4:08 ` John Hubbard
2025-08-26 4:07 ` [PATCH v2 8/8] gpu: nova-core: compute layout of more framebuffer regions required for GSP Alexandre Courbot
2025-08-29 23:30 ` John Hubbard
2025-08-30 0:59 ` Alexandre Courbot
2025-08-30 5:46 ` John Hubbard
2025-08-27 0:29 ` [PATCH v2 0/8] gpu: nova-core: process and prepare more firmwares to boot GSP John Hubbard
2025-08-27 8:39 ` Alexandre Courbot
2025-08-27 21:56 ` John Hubbard
2025-08-28 20:44 ` Konstantin Ryabitsev
2025-08-29 0:33 ` John Hubbard
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=a33aff7e-c260-4d7e-ad18-e919706cdbda@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=joelagnelf@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=tzimmermann@suse.de \
/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.