O Kernel Linux se Prepara para a Atualização para Rust 1.77

Artigo original ↗ Discussão no Hacker News ↗

A mudança do Linux para toolchains Rust mais novas, incluindo a atualização planejada para Rust 1.77, está gerando debate sobre o quanto o kernel deve depender de recursos instáveis do compilador e o que isso significa para a manutenibilidade de longo prazo. Os comentaristas ponderam os benefícios do Rust — segurança de memória, abstrações modernas e suporte de alocador em evolução — contra preocupações práticas como bootstrap do compilador, tamanho binário e a proporção ainda minúscula do código do kernel escrito em Rust. Há amplo consenso de que o Rust continuará opcional e incremental no kernel por enquanto, servindo como um campo de testes para moldar tanto a linguagem quanto suas ferramentas para trabalho de sistemas de baixo nível.

Versionamento do Rust e uso de recursos instáveis no kernel

  • Para projetos comuns que usam Rust estável, as atualizações do compilador são em grande parte compatíveis com versões anteriores; ferramentas como clippy e cargo fmt ajudam a acompanhar mudanças de estilo e lint.
  • O Rust-for-Linux usa deliberadamente recursos nightly/instáveis, então as atualizações podem exigir correções não triviais.
  • Isso é visto como necessário para exercitar recursos ausentes (por exemplo, offset_of, APIs de alocador) e ajudar a empurrá-los em direção à estabilização.
  • Estimativa citada: ~0,5 horas por milhão de linhas de Rust para atualizar compiladores em bases de código grandes; o Rust-for-Linux tem sobrecarga maior devido ao uso de nightly.

Alocadores e manipulação de memória

  • O kernel precisa de alocação granular, falível e por tipo de objeto, o que o empurra para as APIs instáveis de Allocator em vez de apenas GlobalAlloc.
  • allocator_api fornece construção falível (por exemplo, try_new) e flexibilidade que as APIs estáveis não têm.
  • A biblioteca padrão sozinha pode usar recursos instáveis; crates de terceiros não podem fazê-lo no estável.

Tamanho binário e dependências

  • Muitas reclamações sobre o tamanho binário do Rust estão ligadas a:
    • Máquinas de debug/panic (por exemplo, backtrace, formatação sensível a Unicode).
    • Linkagem estática de std.
    • Árvores de dependências pesadas e monomorfização.
  • Em contextos no-std (microcontroladores, kernel), os binários podem ser muito menores.
  • Strip/divisão de debug e os próximos padrões do Cargo reduzirão os tamanhos; mas o “hello world” em Rust ainda tem uma sobrecarga constante relativamente grande em relação ao C.
  • Alguns argumentam que grandes árvores de build e caches (centenas de MB) são problemáticos; outros observam que isso é comparável a toolchains modernas e que o Rust no kernel não trará grandes grafos de dependências.

Extensão e estrutura do Rust no kernel

  • O código Rust atualmente é uma fração minúscula do kernel (na ordem de ~0,03–0,05% das linhas).
  • A maior parte é infraestrutura; drivers em Rust ainda são “erros de arredondamento”, com exemplos como uma reescrita do binder do Android.
  • O kernel usa core e um alloc personalizado, mas não std.

Bootstrap, LFS e toolchains

  • Preocupação: a história de bootstrap do Rust é “feia” e pode ameaçar o Linux From Scratch (LFS).
  • Contraponto: o LFS já assume um compilador C no host; da mesma forma, poderia assumir um compilador Rust no host e usar apenas rustc para produzir arquivos objeto.
  • Em comparação com o bootstrap de outros compiladores complexos (por exemplo, GHC), a situação do Rust é criticada, mas não única.

Segurança de baixo nível, ponteiros e escolha da linguagem

  • A discussão sobre operações inseguras com ponteiros e macros versus aritmética de ponteiros segura destaca sutilezas de UB e trade-offs de desempenho.
  • Esclarecimento sobre as camadas da biblioteca do Rust: core (primitivas da linguagem), alloc (tipos de heap), std (recursos dependentes do SO).
  • Alguns querem não apenas uma reescrita da linguagem, mas verificação formal semelhante à do seL4.
  • Pergunta levantada: “Por que Rust em vez de Zig?”
    • Um lado valoriza as fortes garantias de segurança de memória do Rust.
    • Outro afirma que bugs de memória podem ser tratados com testes e que a segurança do Rust tem seus próprios trade-offs; não houve consenso.