Re: [PATCH v2 2/3] rust: Add support for deriving `AsBytes` and `FromBytes`

[Daniel Almeida <daniel.almeida@collabora.com>]

> On 17 Dec 2025, at 15:01, Matthew Maurer <mmaurer@google.com> wrote:
> 
> On Tue, Dec 16, 2025 at 7:12 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>> 
>> On Tue Dec 16, 2025 at 9:44 AM JST, Matthew Maurer wrote:
>>> This provides a derive macro for `AsBytes` and `FromBytes` for structs
>>> only. For both, it checks the respective trait on every underlying
>>> field. For `AsBytes`, it emits a const-time padding check that will fail
>>> the compilation if derived on a type with padding.
>>> 
>>> Signed-off-by: Matthew Maurer <mmaurer@google.com>
>> 
>> I like this a lot. We have a bunch of unsafe impls in Nova that this
>> could help us get rid of.
>> 
>> Amazed that this even seems to work on tuple structs!
>> 
>>> ---
>>> rust/macros/lib.rs       | 63 ++++++++++++++++++++++++++++++++++++++++++++++++
>>> rust/macros/transmute.rs | 58 ++++++++++++++++++++++++++++++++++++++++++++
>>> 2 files changed, 121 insertions(+)
>>> 
>>> diff --git a/rust/macros/lib.rs b/rust/macros/lib.rs
>>> index b38002151871a33f6b4efea70be2deb6ddad38e2..d66397942529f67697f74a908e257cacc4201d84 100644
>>> --- a/rust/macros/lib.rs
>>> +++ b/rust/macros/lib.rs
>>> @@ -20,9 +20,14 @@
>>> mod kunit;
>>> mod module;
>>> mod paste;
>>> +mod transmute;
>>> mod vtable;
>>> 
>>> use proc_macro::TokenStream;
>>> +use syn::{
>>> +    parse_macro_input,
>>> +    DeriveInput, //
>>> +};
>>> 
>>> /// Declares a kernel module.
>>> ///
>>> @@ -475,3 +480,61 @@ pub fn paste(input: TokenStream) -> TokenStream {
>>> pub fn kunit_tests(attr: TokenStream, ts: TokenStream) -> TokenStream {
>>>     kunit::kunit_tests(attr, ts)
>>> }
>>> +
>>> +/// Implements `FromBytes` for a struct.
>>> +///
>>> +/// It will fail compilation if the struct you are deriving on cannot be determined to implement
>>> +/// `FromBytes` safely. It may still fail for some types which would be safe to implement
>>> +/// `FromBytes` for, in which case you will need to write the implementation and justification
>>> +/// yourself.
>>> +///
>>> +/// Main reasons your type may be rejected:
>>> +/// * Not a `struct`
>>> +/// * One of the fields is not `FromBytes`
>>> +///
>>> +/// # Examples
>>> +///
>>> +/// ```
>>> +/// #[derive(FromBytes)]
>>> +/// #[repr(C)]
>>> +/// struct Foo {
>>> +///   x: u32,
>>> +///   y: u16,
>>> +///   z: u16,
>>> +/// }
>>> +/// ```
>> 
>> One thing I have noticed is that I could sucessfully derive `FromBytes`
>> on a struct that is not `repr(C)`... Is that something we want to
>> disallow?
>> 
> 
> Why should we disallow this? I can enforce it very easily if we want
> it, but the only difference between `#[repr(C)]` and `#[repr(Rust)]`
> is whether we can statically predict their layout. In theory you can
> use this to elide the padding check for `#[repr(C)]` structs (and
> `zerocopy` does this), but it's significantly more complicated.
> 
> The only argument I see in favor of disallowing `#[repr(Rust)]` here
> is that if it's not a struct that also supports `AsBytes`, there's a
> question about where you're getting the bytes to load from.
> 
> I will point out that we probably don't *just* want to restrict to
> `#[repr(C)]` because `#[repr(transparent)]` and `#[repr(packed)]` are
> also great use cases.
> 

I don’t see the point of disallowing other reprs. You can currently derive
FromBytes/AsBytes for any repr anyways. It’s up to the caller to make sure
that deriving these traits make sense.