Re: [PATCH RFC 0/4] rust: dma: bridge zerocopy-derived types into the transmute byte-safety bound

On 2026-06-29 at 17:17 +1000, Alexandre Courbot <[email protected]> wrote...
> On Mon Jun 29, 2026 at 2:10 AM JST, SeungJong Ha via B4 Relay wrote:
> > DMA-coherent allocations (CoherentAllocation/Coherent/dma::Pool) bound
> > their element type on kernel::transmute::{AsBytes, FromBytes}. This RFC
> > lets a type satisfy that bound by deriving zerocopy's byte-safety traits
> > instead of a hand-written unsafe impl.
> >
> > The bound cannot be switched to zerocopy wholesale (some DMA structs are
> > unions that IntoBytes cannot derive), and a blanket bridge impl is
> > rejected by coherence. So the series bridges the two per type:
> >
> >   1. add the bridge macro impl_transmute_via_zerocopy!, which emits the
> >      transmute impls only for a zerocopy-derived type.
> >   2. re-export zerocopy::Immutable from the prelude.
> >   3-4. worked example: convert nova-core's GspMem and msgq POD types.
> 
> Can you give more details about what the macro is for? My understanding
> is that it is a temporary fix for the generated bindings; if so, I'd
> prefer to apply a definitive solution (like using
> `#[derive(zerocopy_derive::most_traits)]`, or updating the bindings
> generator tool) rather than something that will be removed later.

I think the context is in the description for patch 1. It's not directly related
to the bindings generator. Basically the problem is that these bindings are a
little bit unique in that we access them using the dma_write/read macros. In
other words we use these with Dma::Coherent which still requires the transmute
rather than zerocopy trait bounds to be implemented.

That said I think the correct long-term fix here would be to fix Dma::Coherent
to make it work with the zerocopy traits. Not sure if anyone is looking at that
or not.

 - Alistair

> I also notice that the macro is in the Rust `transmute` module, but the
> only user is Nova; so it should have been either be Nova-local, or used
> by other Rust modules.
> 
> But intuitively I'd say that we can (and should) probably do without
> this intermediate step. But please let me know if there is something I
> missed.
>