Greg K-H: “Escrever código novo em Rust beneficia todo mundo”
(lore.kernel.org)Por que o Rust deve ser introduzido no kernel Linux
- Com base na experiência de ter analisado quase todas as correções de bugs e problemas de segurança do kernel Linux nos últimos 15 anos, ele defende a necessidade de adotar Rust
- Nem todas as correções de bugs são refletidas na árvore de versões estáveis, mas, em geral, as mais importantes são, e ele está em uma posição de verificar todos os CVEs do kernel
Os limites de C e as vantagens de Rust
- A maior parte dos bugs que ocorrem no kernel Linux vem de limitações estruturais da linguagem C
- Em especial, há muitos bugs causados por erros simples, e esses problemas quase não acontecem em Rust
- Sobrescrita de memória (Rust não captura todos os casos, mas pode resolver uma parte considerável)
- Problemas de limpeza no caminho de erro
- Verificações ausentes de valores de erro
- Bugs de use-after-free (uso após liberação)
- Ao introduzir Rust no kernel, desenvolvedores e mantenedores podem deixar de lado esses erros básicos e se concentrar nos problemas realmente difíceis (erros lógicos, condições de corrida etc.)
A base de código existente em C também precisa continuar sendo mantida
- Atualmente, o kernel Linux é composto por mais de 30 milhões de linhas de código em C, e substituí-las por Rust no curto prazo é impossível
- Portanto, o trabalho de reforço de segurança do código C realizado por desenvolvedores como Kees e Gustavo é essencial e deve continuar
- O ideal não é que Rust substitua o código existente, mas sim escrever código novo (especialmente drivers) em Rust para reduzir problemas
A segurança de APIs oferecida por Rust
- Rust permite projetar APIs internas do kernel de forma mais segura e mais fácil de usar
- Hoje, as APIs do kernel baseadas em C são complexas, propensas a erros e frequentemente exigem revisão minuciosa por parte dos mantenedores
- Por exemplo, há várias formas de usar com segurança estruturas como
struct cdev, e aproveitar isso corretamente exige muita experiência - Com Rust, é possível definir APIs com mais clareza, o que reduz bastante a chance de erro por parte dos desenvolvedores
- Isso não beneficia apenas usuários de Rust, mas também representa uma mudança útil para quem usa o código C existente
Contestando as preocupações de que adotar Rust será difícil
- Rust não é uma solução mágica → mas pode resolver uma parte significativa dos problemas existentes
- Aumento da carga sobre os mantenedores → mas os próprios desenvolvedores que querem adotar Rust estão fazendo o trabalho
- Dificuldade de manter uma base de código em linguagens mistas → mas o kernel Linux já resolveu problemas muito mais difíceis até hoje
Conclusão
- O Linux é uma ferramenta usada por inúmeros desenvolvedores no mundo todo para resolver problemas, e
- agora, se há desenvolvedores pedindo a possibilidade de escrever código seguro para hardware, isso não deve ser ignorado
- O modelo de desenvolvimento do Linux cresceu em uma escala que ninguém previa e demonstrou uma capacidade de engenharia extraordinária
- Agora é hora de avançar com a adoção de Rust para os próximos mais de 20 anos de evolução
É preciso acolher novas tecnologias e ideias e trabalhar para que elas tenham sucesso junto com a comunidade.
24 comentários
A adoção de Rust provavelmente é uma mudança difícil de evitar quando se considera
memory safety. Talvez tentem costurar tudo de novo por meio de algum meio-termo adequado.Mas, pessoalmente, as palavras-chave de Rust não entram muito bem na minha cabeça, e quando volto a vê-las depois de um tempo também não consigo me lembrar direito, então acabo não conseguindo pegar gosto pela coisa ;;;; Sei que todas são necessárias, mas às vezes parece decorar à força verbos irregulares do inglês. Ainda assim, também é verdade que os produtos feitos em Rust acabam causando menos problemas na prática.....
Fico pensando se é realmente algo tão condenável assim não querer incluir no kernel uma linguagem que ainda não amadureceu. Se você procurar agora mesmo pessoas ao seu redor que dominem Rust, quase não vai encontrar, não é? Parece que não seria tarde demais incluí-la quando a linguagem estiver mais madura e já tiver conquistado uma base de usuários suficiente, mesmo que não chegue ao nível das linguagens legadas. Acredito que a utilidade da linguagem Rust pode ser comprovada o suficiente mesmo sem ser aplicada ao kernel Linux.
Já é surpreendente que Rust, mesmo no estágio em que está hoje, ainda seja chamada de “uma linguagem ainda não madura”, mas, à parte disso, fico pensando se realmente merece tanta crítica a ideia de ao menos tentar reduzir, no kernel, a dependência de linguagens inseguras. Não é como se houvesse tantas pessoas ao nosso redor capazes de escrever código seguro em C com proficiência suficiente para contribuir para o kernel, certo? Em vez de esperar mais amadurecimento do C, parece que agora, quando as exigências de uma nova era já estão suficientemente estabelecidas, ainda não é tarde.
Rust já é útil, e tentar incluí-la no kernel provavelmente não é para provar essa utilidade.
Quando decidiram adotar Rust pela primeira vez, imagino que deve ter havido alguma discussão sobre isso.
Se pensar em qual dos dois grupos é maior, entre os especialistas em C e em Rust, C acaba sendo esmagadoramente maior.
Também fico pensando se, para um programador que já tem todo o conhecimento de domínio, aprender mais uma linguagem é realmente algo tão grande assim,
mas o nível de proficiência exigido de quem trabalha com kernel já é outra história...
Também achei essa opinião boa.
Não entendo nem um pouco a afirmação de que ele deveria fazer um fork e ir embora. Afinal, por que cargas d'água o Linus teria que fazer um fork do Linux e sair?
Tem alguém mandando o Linus pegar o fork e ir embora? Acho que não vi ninguém dizendo isso nesta discussão..
Eu também sou usuário de Rust, mas se código Rust e código C ficarem misturados, sem regras rigorosas em projetos open source sobre até que ponto o código Rust é permitido, isso me parece impossível de controlar ou, no mínimo, elevaria enormemente os custos de revisão e manutenção. Acho que a escolha mais sensata é fazer um fork sem adicionar isso.
Não entendo muito de kernel, mas acho que seria ótimo se fosse possível traduzir automaticamente código C para Rust. Claro, além do problema da tradução de código, também haveria a questão humana.
Se há tantas pessoas querendo introduzir Rust no kernel, elas não poderiam fazer um fork e seguir com um novo projeto? Depois, quando ele amadurecesse o suficiente, as principais distribuições poderiam migrar para um kernel baseado em Rust.
Não entendo muito bem por que estão brigando entre si.
Não sei ao certo se o senhor tem experiência com desenvolvimento de kernel, então não sei muito bem como devo responder, mas
antes de tudo, aplicar a linguagem Rust não significa mudar o kernel para Rust. Dá para perguntar se não seria melhor separar e criar outro kernel, mas
não se trata de fazer um kernel em Rust; a ideia é criar wrappers em Rust apenas para a interface de drivers de dispositivo no kernel, para que somente os drivers de dispositivo
possam ser feitos em Rust. Portanto, seguir como um novo projeto não faz sentido.
Nunca desenvolvi nada para o lado do Linux.
Pelo visto, o wrapper em Rust para drivers de dispositivo tem uma estrutura que não pode ser separada do kernel...
É bem irônico que a comunidade Linux, que vinha justificando um tom tóxico em nome da estabilidade do kernel, agora considere a reação de "se não gostou, faz um fork" como uma resposta razoável.
Eu não faço parte da comunidade Linux, mas...
Acho que não se deve considerar essas pessoas e o autor deste comentário como pertencentes à mesma comunidade.
Acho que pode haver uma dificuldade em prever se o resultado do fork vai acabar sendo uma migração ou um período caótico de fragmentação.
Mesmo depois do fork, refletir as mudanças do upstream provavelmente não vai ser uma situação muito agradável.
https://pt.news.hada.io/topic?id=16860
Ao ver que o fork do Realtime Linux foi incorporado depois de 20 anos, acho que não deveríamos decidir por um fork sem muito cuidado
Eu estava falando isso ao ver isso.
Porque foi possível manter por muito tempo as funcionalidades em tempo real como um projeto separado do kernel, e quem precisasse podia pegar, aplicar ao kernel e usar.
Embora eu seja usuário de Rust, achei impressionante o comentário de hgwxx7_ no r/rust1.
Lembro que, quando era preciso fazer backport para a versão stable ou algo assim e eu entrava em contato, ele sempre respondia bem mesmo no meio de toda aquela correria.
"Rust não é a resposta certa, mas está mais perto da resposta certa do que Java e Python" -codemaster kimc-
Comentários do Hacker News
Não dá para denunciar comentários de ódio como este?
Concordo.