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

"Alexandre Courbot" <[email protected]>
Newsgroups dev.linux.lists.nova-gpu,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-kernel,org.kernel.vger.rust-for-linux
Message-ID <[email protected]>
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 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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.