O ecossistema do kernel Linux continua preparando terreno para a adoção da linguagem Rust no desenvolvimento de componentes do sistema. No dia 14 de novembro de 2026, o desenvolvedor Shuai Liu apresentou a oitava revisão de uma série de patches que propõe abstrações para o subsistema SPI (Serial Peripheral Interface). O objetivo é fornecer a infraestrutura necessária para que programadores possam escrever drivers de periféricos SPI utilizando Rust, aproveitando as garantias de segurança de memória da linguagem, sem precisar reescrever a base consolidada em C.
A proposta, intitulada [PATCH v8 0/3] rust: spi: add SPI driver abstractions, ajusta o código para as árvores de desenvolvimento mais recentes do kernel e refina o modelo de transferência de dados. É importante destacar o status técnico do projeto: trata-se de um trabalho em fase de revisão pelos mantenedores, ainda não incorporado à versão principal (mainline) do Linux.
O que é o protocolo SPI e qual a sua importância?
O SPI é um protocolo de comunicação síncrona amplamente utilizado em sistemas embarcados, computadores industriais e dispositivos de internet das coisas (IoT). Ele atua como uma ponte de comunicação rápida entre um controlador central e diversos componentes eletrônicos periféricos, como sensores de temperatura, conversores analógico-digitais, memórias flash e pequenos displays LCD.
O kernel Linux já possui um subsistema SPI maduro e robusto, escrito inteiramente em C. A novidade proposta não visa substituir os drivers dos controladores SPI (o hardware que gerencia o barramento), mas sim criar uma interface segura para que os drivers de dispositivos (os sensores e telas em si) possam ser desenvolvidos em Rust.
A oitava revisão e o que muda na infraestrutura
A principal motivação para o envio da versão v8 foi o alinhamento do código com a árvore linux-next mais recente (especificamente a revisão next-20261113), garantindo que as modificações possam ser testadas sobre a base de código atual. Além disso, o autor iniciou uma nova linha de discussão pública (thread) na lista de e-mails do kernel, atendendo a uma orientação do mantenedor Mark Brown para facilitar a revisão.
Do ponto de vista arquitetural, a série mantém uma mudança estrutural importante introduzida na versão v7. As operações de entrada e saída de dados agora utilizam um mecanismo central baseado na função SpiDevice::transfer(). Essa implementação em Rust atua como um invólucro (wrapper) para a função spi_sync() do subsistema existente em C. Na prática, isso permite que o desenvolvedor organize diversas transferências de dados dentro de uma única mensagem SPI, simplificando o controle da comunicação.
Como funcionam os três patches propostos
A série está dividida em três partes complementares, separando a integração com a linguagem C, a infraestrutura em Rust e um exemplo prático.
Integração com C e funções auxiliares
O primeiro patch resolve um problema técnico de compatibilidade entre as duas linguagens. Muitas funções críticas do subsistema SPI em C são declaradas como static inline, o que impede que o código em Rust as chame diretamente de forma convencional. Para contornar essa limitação, o patch introduz funções auxiliares (helpers) em C que expõem recursos como spi_unregister_driver(), spi_message_init() e spi_message_add_tail(). Toda essa camada de compatibilidade é condicionada à opção CONFIG_SPI no momento da compilação do kernel.
As abstrações principais em Rust
O segundo patch carrega o núcleo do projeto, adicionando o módulo rust/kernel/spi.rs. Ele fornece as ferramentas que um desenvolvedor precisará para criar um driver. O módulo introduz estruturas fundamentais:
- spi::DeviceId: gerencia as identificações que associam o hardware físico ao driver correto.
- spi::Driver: define os comportamentos obrigatórios do driver, como os momentos de inicialização (probe) e desligamento (remove).
- spi::SpiDevice: representa o periférico em si e fornece os métodos para ler configurações e executar transferências, mas apenas quando o dispositivo está devidamente vinculado.
- spi::Transfer: abstrai as operações de envio e recebimento de dados.
O patch também traz as macros module_spi_driver! e spi_device_table!, criadas para automatizar e simplificar o registro do driver no sistema.
O driver demonstrativo
O terceiro patch introduz o arquivo samples/rust/rust_driver_spi.rs. Trata-se de um driver de exemplo cujo único propósito é documentar e demonstrar como utilizar as novas estruturas. Ele mostra como ler propriedades do hardware (como frequência máxima e bits por palavra) e como estruturar os callbacks exigidos pelo kernel. Este código não foi feito para operar um sensor comercial específico.
Transferências simultâneas e gerenciamento de buffers DMA
A nova interface em Rust contempla diferentes métodos de conveniência para a comunicação com os periféricos. Estão disponíveis comandos diretos de leitura (read()), gravação (write()), e a combinação sequencial de ambos (write_then_read()).
Um aspecto de destaque é o suporte a transferências full-duplex (Transfer::full_duplex()), nas quais o hardware envia e recebe dados no mesmo exato momento. Contudo, a limitação física do hardware dita as regras: esse recurso só funcionará se tanto o controlador da placa-mãe quanto o periférico conectado suportarem comunicação simultânea.
Outro desafio técnico resolvido pela proposta é o uso de DMA (Direct Memory Access). O subsistema SPI em C exige que os buffers de memória utilizados nas transferências sejam adequados para DMA. Como o código em Rust pode fornecer dados espalhados em diferentes áreas da memória, a implementação de Shuai Liu utiliza buffers intermediários, conhecidos como bounce buffers.
Antes de iniciar a transferência, os dados são copiados da memória do Rust para esses buffers intermediários. Após a operação, os dados recebidos fazem o caminho inverso. Embora esse mecanismo garanta a estabilidade e o respeito às exigências da interface em C, o processo de cópia adiciona um custo computacional. A série de patches não apresenta benchmarks ou medições, portanto, não é possível afirmar se drivers escritos com essa infraestrutura apresentarão diferenças perceptíveis de latência ou uso de CPU em comparação com equivalentes nativos em C.
Segurança de memória: o papel do Rust
O grande atrativo da iniciativa Rust for Linux é a segurança de memória, e as abstrações SPI aplicam esse conceito diretamente. A implementação utiliza o sistema de tipos da linguagem para impedir que o software tente se comunicar com um dispositivo que já foi desconectado ou desvinculado do driver.
Isso é feito através de estados no nível da compilação, como o uso da estrutura SpiDevice<Bound>. O compilador do Rust só autoriza as operações de entrada e saída (I/O) se tiver a garantia de que o dispositivo está no contexto correto e devidamente associado. No modelo tradicional em C, o desenvolvedor precisa garantir manualmente que nenhuma condição de corrida (race condition) ocorra caso o hardware seja removido durante uma transferência.
Apesar dos avanços estruturais, a comunicação com o subsistema em C ainda exige código do tipo unsafe nos bastidores. As abstrações encapsulam o perigo, mas a segurança final do driver depende de quão bem essa fronteira de compatibilidade foi desenhada.
Limitações atuais: o desafio da validação física
A oitava revisão inclui testes unitários básicos utilizando o framework KUnit, focados principalmente nas estruturas de identificação de dispositivos. No entanto, existe uma limitação técnica no atual estágio de desenvolvimento do projeto.
Em discussões anteriores na lista de e-mails, o autor relatou não possuir hardware SPI físico disponível para submeter as abstrações a testes em cenários reais de estresse. Até o momento desta publicação, o código foi validado por meio de testes de compilação e infraestrutura automatizada, mas a comprovação prática de estabilidade dependerá da colaboração de outros desenvolvedores que possuam placas e sensores físicos compatíveis.
O que falta para a incorporação ao kernel?
O projeto encontra-se em fase de revisão. Para que as abstrações SPI em Rust sejam integradas definitivamente à árvore principal de Linus Torvalds, a série precisará da aprovação formal de Mark Brown (mantenedor do subsistema SPI) e possivelmente de Miguel Ojeda (mantenedor do Rust for Linux).
Entenda sem termos técnicos: o que muda para quem utiliza Linux?
Se você é um usuário comum de distribuições Linux no PC, essa mudança não trará impactos imediatos na sua rotina. A novidade é voltada para quem constrói o sistema.
Imagine que o kernel Linux tem um “departamento de comunicação” bem antigo e funcional (escrito em C) que fala com pequenos componentes de hardware (telas, sensores, LEDs). O que o desenvolvedor Shuai Liu está propondo não é demolir esse departamento, mas sim construir um novo “balcão de atendimento” (escrito em Rust).
Esse novo balcão permite que futuros criadores de drivers utilizem ferramentas modernas que evitam falhas humanas comuns, como tentar enviar um pacote de dados para um sensor que já foi desconectado. A vantagem em longo prazo é um sistema operacional com menos travamentos causados por pequenos erros na comunicação com o hardware.
