Re: [PATCH v2 02/16] rust: io: add `IoRepr` trait

On Mon Aug 10, 2026 at 8:21 PM JST, Gary Guo wrote:
> On Mon Aug 10, 2026 at 10:30 AM BST, Alexandre Courbot wrote:
>> On Thu Aug 6, 2026 at 1:35 AM JST, Gary Guo wrote:
>>> diff --git a/rust/kernel/io.rs b/rust/kernel/io.rs
>>> index adfc555de7d0..71c6180ed745 100644
>>> --- a/rust/kernel/io.rs
>>> +++ b/rust/kernel/io.rs
>>> @@ -276,6 +276,91 @@ pub trait IoCapable<T>: IoBackend {
>>>      fn io_write<'a>(view: Self::View<'a, T>, value: T);
>>>  }
>>>  
>>> +/// Safe transmute that performs size check on monomorphization-time.
>>> +///
>>> +/// Can be considered as generic version of [`zerocopy::transmute!`] macro but using the unstable
>>> +/// `core::mem::transmute_neo` instead of [`core::mem::transmute`].
>>> +#[inline(always)] // This is a no-op.
>>> +fn transmute_neo<Src: IntoBytes, Dst: FromBytes>(val: Src) -> Dst {
>>> +    const_assert!(size_of::<Src>() == size_of::<Dst>());
>>> +
>>> +    // SAFETY: `Src: IntoBytes` and `Dst: FromBytes` and we've checked size is the same.
>>> +    unsafe { core::mem::transmute_copy(&core::mem::ManuallyDrop::new(val)) }
>>> +}
>>
>> This is universally useful, so let's move this to the `transmute` module?
>
> I think we can just have a `kernel::mem` and put it there so it's consistent
> with std naming. The `transmute` module just contains two types that are going
> away.

Yes, that would work as well and is probably an even better location.

>
> Ideally we have this function in `zerocopy`. But my understanding is that this
> depends on inline const which is stable since 1.79 but zerocopy's MSRV is 1.56.
>
>>
>>> +
>>> +/// Trait indicating the underlying primitive types to be used for I/O operations.
>>> +///
>>> +/// Implementing trait allows arbitrary types to be used for I/O operations, not just raw
>>> +/// primitives.
>>> +///
>>> +/// The layout of the type and the underlying primitive must match; this is enforced via const
>>> +/// assertions when I/O methods are used, as the type system cannot represent this.
>>> +/// [`IoRepr::from_repr`] and [`IoRepr::into_expr`] can be overridden for conversions, however it
>>> +/// should be noted that they are only invoked on value read/write operations and are not invoked
>>> +/// on byte operations such as [`Io::copy_read`].
>>> +///
>>> +/// # Examples
>>> +///
>>> +/// ```
>>> +/// # use kernel::io::*;
>>> +/// #[repr(transparent)]
>>> +/// #[derive(FromBytes, IntoBytes)]
>>> +/// pub struct MyNewType(u32);
>>> +///
>>> +/// impl IoRepr for MyNewType {
>>> +///     type Repr = u32;
>>> +/// }
>>> +///
>>> +/// #[repr(C)]
>>> +/// pub struct MyStruct {
>>> +///     raw: u32,
>>> +///     new_type: MyNewType,
>>> +/// }
>>> +///
>>> +/// # fn test(mmio: Mmio<'_, MyStruct>) {
>>> +/// // let mmio: Mmio<'_, MyStruct>;
>>> +/// let val: u32 = io_read!(mmio, .raw); // Raw primitive read
>>> +/// io_write!(mmio, .raw, val);          // Raw primitve write
>>> +/// let val: MyNewType = io_read!(mmio, .new_type); // Read via `IoRepr`.
>>> +/// io_write!(mmio, .new_type, val);                // Write via `IoRepr`.
>>> +/// # }
>>> +/// ```
>>> +pub trait IoRepr: FromBytes + IntoBytes + Sized {
>>> +    /// The backing I/O capable type.
>>> +    type Repr: FromBytes + IntoBytes;
>>> +
>>> +    /// Convert from [`IoRepr::Repr`] to `Self`.
>>> +    #[inline(always)]
>>> +    fn from_repr(repr: Self::Repr) -> Self {
>>> +        transmute_neo(repr)
>>> +    }
>>> +
>>> +    /// Convert from `Self` to [`IoRepr::Repr`].
>>> +    #[inline(always)]
>>> +    fn into_repr(this: Self) -> Self::Repr {
>>> +        transmute_neo(this)
>>> +    }
>>> +}
>>> +
>>> +macro_rules! impl_io_repr {
>>> +    ($($ty:ty => $backing:ty,)*) => {
>>> +        $(impl IoRepr for $ty {
>>> +            type Repr = $backing;
>>> +        })*
>>> +    };
>>> +}
>>> +
>>> +impl_io_repr! {
>>> +    u8 => u8,
>>> +    u16 => u16,
>>> +    u32 => u32,
>>> +    u64 => u64,
>>> +    i8 => u8,
>>> +    i16 => u16,
>>> +    i32 => u32,
>>> +    i64 => u64,
>>> +}
>>
>> ... and `IoRepr` and its implementations for primitive types should also
>> be part of `transmute` IMHO (after being renamed to e.g. `Repr`), for
>> there is nothing I/O exclusive to it. It just indicates that one type
>> can be represented by another, a property that is again useful outside
>> of I/O.
>
> I tried to be a little bit forward looking in designing this, so I ended up
> with a design that provides conversion functions instead of just transmutation.
> If we're moving it we should probably just get rid of these and just require a
> transmutability with the raw repr.

If that works for you then that would simplify things a bit yes, and we
can think about hypotheticals when we need them.

>
> Note that there is `AtomicType` which has similar (but not equivalent
> requirement). `AtomicType` requires a round-trip transmutability only, and
> `IoRepr` needs both directions. So `repr(C)` enums (that is not used up all its
> variant reprs) can be `AtomicType` but not `IoRepr`.
>
>>
>> That way `bitfield` gets a dependency on `transmute` rather than `io`,
>> which doesn't break layering.
>
> We can also avoid breaking layering by requiring user to need to specify
> `#[derive(IoRepr)]` when declaring bitfield.

Yup, that sounds like a good solution to the problem as well.

<...>
>> These appear to repeat quite a bit of [1] which is already in
>> `driver-core-next`. You'll want to rebase, I think the only difference
>> between the two is the removal of $storage from @io_base.
>
> I'm thinking of moving this entire thing to syn :)

Heh, I guess that's the next logical step. It would also avoid the (for
now harmless) recursion introduced by the token muncher of this series.