- Código em Rust que implementa a API de Direct Memory Access foi enviado como pull request para o repositório do kernel Linux.
- O mantenedor intermediário do kernel Linux, Christoph Hellwig, recusou o código em Rust dizendo que ele não deveria entrar no kernel Linux, e o conflito começou.
- À medida que a disputa foi crescendo, Christoph Hellwig comparou Rust a células cancerígenas.
- Hector Martin, principal responsável pelo Asahi Linux, reagiu a essa fala sobre câncer e, ao envolver Linus Torvalds nas redes sociais, fez duras críticas.
- Linus Torvalds advertiu Hector Martin dizendo que "o problema é você mesmo" e pediu que ele "não fizesse brigading nas redes sociais".
- Atualmente, Hector Martin pediu para deixar o cargo de mantenedor do código upstream do Linux que dá suporte a hardware compatível com Apple Arm.
28 comentários
O resumo menciona apenas os acontecimentos, mas no final do texto original (em coreano) há mais dois contextos adicionais para ajudar a entender melhor o caso.
Acho que é melhor gerenciar o projeto em uma única linguagem, mas, fora isso, a forma de convencer os colegas disso é péssima.
Forçar alguém a se ajoelhar pelo poder é algo absurdo.
Esta é a thread do e-mail do PR:
https://lwn.net/ml/all/…
Pelo visto, não é um PR que altera a implementação de DMA nem mexe diretamente na API de DMA, mas sim um PR que escreve bindings FFI para permitir acesso à API de DMA a partir de Rust.
E um PR desses foi rejeitado com a resposta seca: "No rust code in kernel/dma, please.", https://lwn.net/ml/all/20250108135951.GA18074@lst.de/
Quando perguntaram então qual seria a forma correta de fazer, a resposta foi: "Keep the wrappers in your code instead of making life painful for others." https://lwn.net/ml/all/20250108151858.GB24499@lst.de/
(Isso foi exatamente o que fizeram. O PR não modifica
kernel/dma, e sim a subárvorerust/kernel.)Claro, se bindings FFI forem adicionados, existe o ônus de também precisar atualizá-los quando a API de DMA mudar,
mas, mesmo depois de o lado que mexe com Rust dizer que cuidaria disso por conta própria, não sei se é correto alguém que nem é responsável por essa árvore reagir dessa forma.
(Christoph Hellwig é mantenedor principal de
kernel/dma: https://docs.kernel.org/process/maintainers.html#dma-mapping-helpers)Por isso, parece que o Hector Martin puxou o Linus para a discussão:
https://lwn.net/ml/all/2b9b75d1-eb8e-494a-b05f-59f75c92e6ae@marcan.st/
Mas o que foi dito na thread imediatamente anterior também é interessante:
se surgir uma
breaking changena API e o time de Rust não reagir rapidamente, o build quebra e o Linus deixa de aceitar o PR.Pensando nisso como um problema entre o módulo que criou a
breaking changee outro módulo, pessoalmente me parece melhor quando há Rust no lado afetado.O módulo x criou uma
breaking change, e o módulo y não conseguiu reagir rápido:No kernel Linux, a maior parte dos trechos em que Rust usa
unsafeé justamente na parte de integração com C.Além disso, também existem partes de controle de hardware em que é preciso lidar diretamente com memória, mas são trechos bem pequenos.
A parte em que Rust é aplicado é o desenvolvimento de drivers. Não é necessário mexer no próprio kernel, como gerenciamento de memória ou a block layer, e nem dá para fazer isso.
Há muito mais código de driver do que código do próprio kernel. E a maior parte dos pontos em que surgem problemas também está no código dos drivers.
Eu acho certo que a parte de desenvolvimento de drivers seja feita em uma linguagem com mais segurança de memória e melhor segurança do que C.
Se isso vai ser Rust, Zig ou outra coisa, eu não sei.
Também concordo que Rust é complexa demais para desenvolver aplicações comuns e difícil para desenvolvedores de C aprenderem rapidamente.
Mesmo assim, seja qual for a linguagem, espero que pelo menos o desenvolvimento de drivers mude para uma linguagem mais moderna.
Na minha empresa anterior, levei cerca de 7 anos para desenvolver e estabilizar um driver com apenas alguns milhares de linhas; não dá para simplificar completamente, mas acho que algo em torno de 3 anos foi só de depuração.
A maior parte eram bugs relacionados à memória. Erros lógicos, como deadlocks, eram minoria.
Não me parece uma boa ideia usar um projeto grande como campo de testes para a sua própria linguagem.
Se a coisa desandar, talvez seja preciso voltar aos velhos tempos em que se fazia fork.
Num kernel que lida com o dispositivo como um todo, mesmo usando Rust, quando começam a usar
unsafe, só consigo pensar que isso acaba virando um código difícil de ler e cheio de problemas.Não estamos falando de um projeto sem release principal, tipo 0.91, 0.92, 0.99, 0.991 e por aí vai; não entendo por que estão portando partes que já funcionavam bem.
Também não é o caso de "apareceu um grande bug e, aproveitando para corrigir, tornamos isso mais seguro".
Esse PR não é um port. É um PR que adiciona bindings FFI do lado do Rust para que a API de DMA existente também possa ser usada em módulos baseados em Rust escritos do zero. E foi isso que o responsável por DMA bloqueou.
É uma pena que o texto da matéria não tenha trazido o trecho original citado. Fui procurar o original por curiosidade e li, e embora eu também não ache que tenha entendido tudo perfeitamente, parece que há bem mais contexto por trás do que simplesmente contar a história como no texto original.
O título do artigo foi alterado para o nome original.
Obrigado pelo processamento.
Pelo visto, adicionar Rust a uma grande base de código em C não é tão divertido quanto parece. Para dizer que isso aumenta a segurança de memória, no fim a área de
unsafeacaba crescendo, então a efetividade não é tão grande.... parece não ter muito significado além de ampliar a área de uso de Rust.... então acho que é um caminho natural acabar gerando a resistência dos desenvolvedores de C que já existiam. Talvez seja melhor focar em um projeto de kernel que realmente comece em Rust desde o início.Nossa, a qualidade do texto é melhor do que eu imaginava. Foi uma leitura bem divertida.
A questão que Torvalds levantou — de que o problema é você — tinha o argumento de que, independentemente da adoção de Rust, a resposta para um problema técnico não pode vir das redes sociais, mas esse resumo, do jeito que está, parece dar margem a mal-entendidos.
Para Hector Martin, foi uma escolha inevitável.
Quando todos os gerentes intermediários do Linux estão cheios de especialistas em C, será que eles aceitariam sequer a opinião de um pequeno grupo de desenvolvedores Rust?
https://youtu.be/opTJH76wJxs?si=WHR0_1uPpSlpDTHr mostra o processo de como isso evolui para uma controvérsia.
O Torvalds não estava permitindo Rust também?
Torvalds não disse uma palavra sobre Rust nessa discussão.
Quando houver divergências de opinião técnica, o debate deve ser conduzido com base em argumentos técnicos, e não se deve tentar encerrar a disputa formando opinião pública nas redes sociais.
Se vocês são tão bons assim, façam um fork do kernel e escrevam tudo em Rust. Em vez de ficar se infiltrando aos poucos como um câncer. Parece que há muita gente com essa opinião.
Não sei se teria sido diferente se o código mexesse em
kernel/dmapara facilitar o uso em Rust,mas o que foi adicionado foi uma camada FFI que encapsula
kernel/dmaemrust/kernel/dma.Não mexeram no código original.
Na prática, o ponto central é algo como:
"Não gosto quando usam errado a FFI oficial de DMA feita em Rust e depois vêm me perguntar."
E ainda por cima disseram algo sem pé nem cabeça, do tipo: "Então manda cada driver se virar e criar sua própria FFI."
Isso é o Redox mesmo. Ainda deve haver partes que ele não suporta, então imagino que seja por isso que estão indo para o Linux...
https://vt.social/@lina/113064510447670892
O que você escreveu parece ser exatamente a fala de Hellwig, mas não sei se dá para considerar que essa opinião seja a da maioria.
Olá. Obrigado por publicar um bom texto. Li com prazer.
No entanto, depois de verificar o texto original e o título original, fiquei com uma pequena preocupação e resolvi deixar este comentário.
https://news.hada.io/guidelines
> Em princípio, use o título original do texto ou publique uma tradução do título para o coreano.
É isso que está sendo sugerido. E, ao ler o conteúdo desse texto, acho que, em vez de "A polêmica sobre Rust no kernel Linux volta a esquentar", o título "Linus Torvalds: 'O problema é você'" pode causar ainda mais mal-entendidos sobre o conteúdo do texto do que o título original.
Obrigado novamente por resumir e apresentar o texto. Tenha um ótimo dia.
sensacional
Vou considerar isso.
'm 'b Tenha um bom dia! Obrigado por me proporcionar uma boa leitura. \(__ )
Eu tinha o costume de acrescentar meu próprio subtítulo ao título para dar uma explicação mais precisa, mas além de o título não ter agradado outra pessoa, eu também não sabia que existia essa regra. Da próxima vez, vou publicar exatamente como no original.
Embora o título original deixe claro de imediato sobre o que se trata, o título alterado que você propôs pode acabar dando margem a mal-entendidos, como se fosse sensacionalista. É uma opinião pessoal.
Obrigado pela opinião.
Considerei a fala do Linus a parte mais importante e coloquei isso no título, mas parece que acabou ficando bastante distorcido.
Com certeza vou tomar mais cuidado.