O que esperar da linguagem de programação Rust no Kernel Linux?

Arm ajuda com AArch64 Rust Linux Kernel Enablement — rust

Por três décadas, o Linux foi escrito na linguagem de programação C. Mas uma mudança importante e radical pode estar chegando.Há um ímpeto crescente por trás de um esforço para tornar a linguagem de programação Rust uma segunda linguagem para C para o kernel Linux. O Google está apoiando um projeto liderado pelo desenvolvedor Miguel Ojeda que veria Rust sendo usado para escrever elementos do kernel Linux, que agora sustenta algumas das peças mais críticas da infraestrutura da Internet hoje. Então, o que esperar da linguagem de progração Rust no Kernel Linux?

O Google argumenta que o Rust deve ajudar a reduzir os erros de memória que levam a vulnerabilidades de segurança, que constituem a maior parte das falhas que empresas de tecnologia e projetos de código aberto corrigem em cada atualização. O objetivo não é escrever todas as 30 milhões de linhas de código C novamente em Rust, mas sim escrever um novo código em Rust.

No entanto, apesar de alguns benefícios potenciais, ainda não está claro se o esforço para tornar o Rust uma segunda linguagem para o desenvolvimento do kernel terá sucesso. No mínimo, o Rust for Linux deve ser visto como um projeto de longo prazo e é quase certo que não será incorporado ao kernel Linux 5.14 – a versão atualmente em desenvolvimento e que deverá ser estável por volta do terceiro trimestre de 2021.

O projeto não terminou, mas estamos prontos para manter a linha se os mantenedores de alto nível aceitarem as mudanças atuais e preferirem que trabalhemos dentro do kernel”, disse Ojeda ao ZDNet. “A maior parte do trabalho ainda está à nossa frente.

O que esperar da linguagem de programação Rust no Kernel Linux?

A linguagem de programação Rust tem suas origens na Mozilla. Ela foi usada para construir o motor de renderização Servo para Firefox e ganhou força com Amazon Web Services, Microsoft, Google e Facebook para programação de sistemas – muitas vezes para construir em cima de grandes bases de código C e C ++.

Como resultado dessa popularidade crescente, a ideia do Rust no kernel ganhou o apoio de algumas grandes empresas de tecnologia.

No entanto, apesar de alguns benefícios potenciais, os fãs do Rust não podem simplesmente torná-lo uma linguagem de programação para o kernel Linux por conta própria. Ele precisa da aprovação de Linus Torvalds e dos mantenedores de alto nível que orientam o desenvolvimento do kernel.

E Torvalds não indicou se aprovaria o pull request (PR) para mesclar os últimos patches do Rust para Linux no kernel Linux principal.

Ojeda postou uma primeira solicitação de comentário (RFC) na lista de discussão do kernel Linux em abril e seguiu com um conjunto de correções propostas no início de julho que ele e seus colegas esperavam que fossem incluídas no kernel Linux.

O primeiro RFC de Ojeda incluiu exemplos de drivers Rust, mas a resposta de Torvalds aos drivers de hardware do Linux não foi positiva: ele disse que o pânico de falha em tempo de execução – um tipo de erro – é um “problema fundamental”.

Longo caminho pela frente

O comentário de Torvalds destacou o longo caminho à frente para o projeto Rust for Linux. Como Steven J. Vaughan-Nichols da ZDNet relatou em março, Torvalds está no campo do ‘esperar para ver’ para trazer o Rust para o kernel Linux: ele não é nem a favor, nem contra o Rust, mas está aberto para ver se os benefícios prometidos realmente dão certo.

“Acho que é dirigido por pessoas que estão muito entusiasmadas com o Rust, e quero ver como ele realmente acaba funcionando na prática”, disse Torvalds, acrescentando que os drivers parecem ser o alvo mais óbvio para o Rust.

Ojeda reconhece as preocupações de Torvalds, mas também diz que a equipe de desenvolvedores que está tentando trazer o Rust para o Linux está tratando dos problemas.

Ele diz que remover pânicos desnecessários é uma preocupação chave entre a comunidade do kernel Linux, mas acredita que é “principalmente um obstáculo técnico e foi resolvido.”

“O outro é fazer com que os módulos do kernel sejam escritos como provas de conceito”, diz Ojeda.

O módulo do kernel Rust Binder está funcionando e os resultados preliminares de desempenho que temos em um benchmark de latência trivial são melhores do que a versão C, o que é muito encorajador; embora ainda estejamos no processo de melhorar o código e limpar as coisas. Estamos também trabalhando na escrita de módulos que impulsionam o hardware real e criando maneiras de melhorar a ergonomia em torno disso.

Maior obstáculo

Mas o maior obstáculo, diz Ojeda, é fazer com que os contribuidores do kernel Linux, que têm codificado em C por décadas, aprendam o Rust e seus conceitos.

“Na minha opinião, o maior obstáculo vem da ensinabilidade. A ferrugem é mais complexa do que a C”, diz ele.

Isso também não é um problema pequeno, dadas as centenas de patches e mudanças que chegam a cada nova versão do kernel. Alguém tem que escrevê-los – e agora pode-se esperar que aprenda Rust quando eles já estão operando em um cronograma apertado.

Alguns dos conceitos em Rust são estranhos a outras linguagens, como o ‘verificador de empréstimo‘ com o qual os desenvolvedores geralmente lutam ao tentar entender quando o código não compila conforme o esperado; outro conceito estranho é a divisão segura/insegura de Rust.

“Os desenvolvedores de kernel são muito inteligentes, mas também muito ocupados. Não é fácil envolver todos e explicar por que achamos que a introdução de uma segunda linguagem vale o custo da complexidade”, diz Ojeda.

Tudo isso significa que o projeto Rust for Linux parece ter algum caminho a percorrer ainda antes de seus patches serem mesclados. Seguindo os novos patches, o mantenedor do kernel estável do Linux Greg Kroah-Hartman pediu ao projeto um driver Linux “concreto” escrito em Rust.

E os drivers?

Como Torvalds, ele acreditava que os drivers do kernel faziam sentido porque eles são “as ‘folhas finais’ da árvore de dependências no código-fonte do kernel”.

E se os pacotes Rust for Linux forem rejeitados, o exercício de pensar em um kernel com menos bugs de memória é um fim em si mesmo.

“Mesmo que o projeto recebesse um não – de que não há nenhuma chance de ele dar certo agora ou no futuro – o projeto não teria sido uma perda de tempo”, disse Ojeda.

“O exercício de adicionar uma segunda linguagem ao kernel é interessante e gerou muita discussão. Mesmo que não fosse o Rust, é bom ter toda essa experiência se outra linguagem quiser tentar.

“Mais importante, acho que ter aumentado a conscientização sobre as garantias de segurança de memória que o uso de uma nova abordagem pode trazer já é fundamental. Em minha opinião, se quisermos ter qualquer segunda linguagem no kernel, deve ser uma que melhore significativamente o estado de coisas a esse respeito.”

Via ZDNet

Assuntos