[PATCH 0/7] drm/nova: replace `transmute` with `zerocopy`

Pedro Yudi Honda niyudi.honda em usp.br
Qui Jun 25 16:09:06 -03 2026


[image: image.png]
Aparentemente pra enviar pro cara da nvidia a autenticação não deu certo...
Mas pro resto parece ter ido, então só deixo assim mesmo?

Em qui., 25 de jun. de 2026 às 14:28, David Tadokoro <
davidbtadokoro em ime.usp.br> escreveu:

> Oi Pedro,
>
> On Thu Jun 25, 2026 at 2:14 PM -03, Pedro Yudi Honda wrote:
> > Queria ajuda para saber para quem mandar. Esse é o resutlado do
> > get_maintainers pra pasta que eu estou mexendo:
> > [image: image.png]
>
> Difícil saber ao certo se todos que aparecem devem ser destinatários da
> mensagem, mas acho que faz sentido sim. Você pode excluir a
> <linux-kernel em vger.kernel.org> (a chamada LKML), porque é uma lista
> geral do kernel e que o pessoal costuma ignorar. Aliás, você está usando
> o `kw send-patch` pra enviar o patch ou direto com o `git send-email`?
> Usando o kw facilita e você só precisa se preocupar em adicionar quem
> falta (como a seguir...)
>
> > Eu também ia mandar para quem abriu a issue no rust-next que eu usei de
> > base (Miguel Ojeda <ojeda em kernel.org>). Só envio para todos
> > indiscriminadamente?
>
> Acho uma boa incluir o Miguel Ojeda, pois ele é o cara (ao menos, um
> dos) do Rust no kernel. Se ele que criou a issue então, mais motivo
> ainda. Talvez, incluir também a lista do rust-for-linux
> (<rust-for-linux em vger.kernel.org>)?
>
> Abraços,
> David
>
> >
> > Em qui., 25 de jun. de 2026 às 12:14, David Tadokoro <
> > davidbtadokoro em ime.usp.br> escreveu:
> >
> >> Oi Pedro,
> >>
> >> Não olhei a fundo o seu patchset, mas pode já enviar para a revisão de
> >> verdade!
> >>
> >> Parabéns pelo trabalho e obrigado por estreiar o Rust no kernel dentro
> >> disciplina :)
> >>
> >> Abraços,
> >> David
> >>
> >> On Mon Jun 22, 2026 at 3:40 PM -03, Pedro Yudi Honda wrote:
> >> > From: Pedro Yudi Honda <niyudi.honda em usp.br>
> >> >
> >> > This series follows the introduction of `zerocopy` to rust-next and
> >> > replaces `transmute` traits with `zerocopy` traits. These changes are
> >> > mechanical and don't alter functionality.
> >> >
> >> > Specifically, the trait `transmute::FromBytes` is replaced by
> >> > `zerocopy::FromBytes` and the trait `transmute::AsBytes` is replaced
> >> > by `zerocopy::IntoBytes`. Additional traits such as
> >> > `zerocopy::Immutable` and `zerocopy::KnownLayout` are implemented as
> >> > necessary.
> >> >
> >> > This does not replace the trait implemented in newtypes over
> >> > bindings. Currently, the only solution I can think of is mirroring
> >> > the bindings into another type and transmuting when necessary, but
> >> > that does not seem practical. Another issue is a type like
> >> > `gsp::cmdq::GspMem` that explicitly does not meet the requirements
> >> > for `FromBytes`, but unsafely implements the trait anyway because it
> >> > knows all of its uses. Unsafely implementing `zerocopy::FromBytes` is
> >> > not allowed, and implementing `zerocopy::TryFromBytes` would add
> >> > unnecessary overhead.
> >> >
> >> > Feedback from the maintainers on the direction in these cases would
> >> > be appreciated.
> >> >
> >> > Pedro Yudi Honda (7):
> >> >   drm/nova: use `zerocopy` in firmware.rs
> >> >   drm/nova: use `zerocopy` in vbios.rs
> >> >   drm/nova: use `zerocopy` in booter.rs
> >> >   drm/nova: use `zerocopy` in fwsec.rs
> >> >   drm/nova: use `zerocopy` in bootloader.rs
> >> >   drm/nova: use `zerocopy` in riscv.rs
> >> >   drm/nova: remove unused trait in commands.rs
> >> >
> >> >  drivers/gpu/nova-core/firmware.rs             | 16 ++-----
> >> >  drivers/gpu/nova-core/firmware/booter.rs      | 26 +++-------
> >> >  drivers/gpu/nova-core/firmware/fwsec.rs       | 47
> +++++--------------
> >> >  .../nova-core/firmware/fwsec/bootloader.rs    | 16 ++-----
> >> >  drivers/gpu/nova-core/firmware/riscv.rs       | 10 ++--
> >> >  drivers/gpu/nova-core/gsp/commands.rs         |  9 +---
> >> >  drivers/gpu/nova-core/vbios.rs                | 34 ++++----------
> >> >  7 files changed, 40 insertions(+), 118 deletions(-)
> >>
> >>
>
>


Mais detalhes sobre a lista de discussão kernel