Uma atualização crucial para o futuro dos drivers gráficos no Linux aterrissou na lista de discussão do kernel. Joel Fernandes, engenheiro da Nvidia, submeteu a décima primeira versão (v11) dos bindings em Rust para o alocador “Buddy” de GPU. Esta série de patches é uma peça fundamental para o desenvolvimento do nova-core, o novo driver de código aberto para GPUs Nvidia escrito inteiramente em Rust, e marca uma mudança estrutural importante na forma como o kernel gerencia memória de vídeo.
Embora a parte da infraestrutura em C já tenha sido aceita pelos mantenedores do subsistema DRM (Direct Rendering Manager) na fila de desenvolvimento, a camada de abstração em Rust (o foco desta v11) chegou após o fechamento da janela de fusão do 7.0. Portanto, esta tecnologia está sendo preparada para estrear no Kernel Linux 7.1. A mudança não afeta apenas placas de vídeo, mas prepara o terreno para aceleradores de computação e virtualização via VFIO.
O que isso significa na prática
Imagine a memória da sua placa de vídeo (VRAM) como uma folha de papel grande. Quando um jogo ou aplicativo precisa de memória, o sistema precisa “recortar” um pedaço para ele. O sistema “Buddy Allocator” é uma técnica clássica e eficiente que divide essa memória sempre pela metade (em potências de dois: 4MB, 2MB, 1MB) para atender ao pedido com o menor desperdício possível.
A novidade aqui não é o algoritmo em si, que já existia, mas sim duas mudanças: primeiro, ele foi “promovido” dentro do kernel para ser usado por mais tipos de hardware além de telas; segundo, agora ele pode ser controlado com segurança pela linguagem Rust. Isso significa que o futuro driver da Nvidia (nova) terá menos chances de sofrer com vazamentos de memória ou telas azuis (kernel panics) causados por má gestão da VRAM.
Detalhes da implementação
A série de patches realiza uma cirurgia significativa no subsistema de GPU. Originalmente, o alocador residia em drivers/gpu/drm/drm_buddy.c, atrelado especificamente ao subsistema de display. A mudança move este código um nível acima, para drivers/gpu/buddy.c, e o renomeia de drm_buddy para gpu_buddy.
Isso foi feito para permitir que drivers que não lidam com display — como drivers de computação pura ou VFIO (para passar a GPU para uma máquina virtual) — possam utilizar o mesmo alocador de memória eficiente.
Do lado do Rust, a implementação introduz as estruturas GpuBuddy e AllocatedBlock dentro do diretório rust/kernel/gpu/. O patch utiliza o sistema de tipos do Rust para garantir que o bloqueio (locking) seja respeitado:
- A estrutura GpuBuddyInner é protegida por um Mutex.
- O acesso ao alocador C só é permitido através de um GpuBuddyGuard, que garante que o lock está ativo.
- A memória alocada (AllocatedBlocks) é automaticamente liberada quando a variável sai de escopo (Drop trait), prevenindo memory leaks.
Curiosidades e bastidores da discussão
A discussão na LKML revela um trabalho colaborativo intenso entre Nvidia, Red Hat e a equipe do Rust-for-Linux. Um ponto crítico resolvido nesta versão v11 foi trazido por Koen Koning. Ele identificou que drivers embutidos (built-in) causavam pânico no kernel durante o boot.
O motivo era técnico e sutil: o alocador buddy usava module_init, que roda depois da inicialização de muitos subsistemas. Se um driver de GPU tentasse usar o alocador antes dele estar pronto, o sistema travava. A solução foi mudar para subsys_initcall, garantindo que o alocador esteja “acordado” antes que qualquer driver de GPU tente conversar com ele.
Outro ponto de debate foi a API de flags. Alexandre Courbot e Danilo Krummrich discutiram a melhor forma de expor as flags de alocação (como RANGE_ALLOCATION ou TOPDOWN) para o Rust. A decisão pendeu para o uso da macro impl_flags!, criando uma interface segura onde combinações inválidas de flags podem ser rejeitadas em tempo de compilação ou tratadas de forma elegante, em vez de causar erros silenciosos no lado do C.
Esta atualização é um complemento direto aos esforços que acompanhamos recentemente no SempreUpdate, onde a versão v5 do driver Nova já trazia refinamentos críticos para as arquiteturas Blackwell e Hopper, evidenciando o ritmo acelerado da Nvidia em adotar Rust.
Quando isso chega no meu PC?
Aqui é preciso atenção ao calendário. Como o patch v11 foi submetido em 24 de fevereiro, dois dias após o lançamento do Linux 7.0-rc1 (que congelou novas funcionalidades), ele perdeu o “trem” para a versão 7.0.
A infraestrutura em C já está na branch drm-misc-next, o que confirma seu agendamento para a próxima janela de abertura. Portanto, espere ver essa funcionalidade oficialmente no lançamento do Kernel Linux 7.1 (previsto para meados de 2026). Para usuários de distros “Rolling Release” (como Arch ou Tumbleweed), o suporte chegará poucas semanas após o lançamento estável do 7.1.