A ferrugem não ficou isenta das críticas de Linus Torvalds

Algumas semanas atrás as notícias de sobre algumas implementações que foram feitas em a ramificação linux-next, que inclui um conjunto inicial de componentes desenvolver drivers de dispositivo na linguagem Rust.

Esta documentação foi publicada separadamente sobre o uso do Rust no kernel Linux e um exemplo de um módulo do kernel com um driver de dispositivo de caractere na linguagem Rust. O código foi adicionado por Stephen Rothwell, mantenedor do branch.

Depois disso, Linus Torvalds revisou a revisão da implementação patch de possibilidades para definir drivers de linguagem Rust no kernel Linux e expressou algumas críticas.

As maiores reclamações foram causadas por o potencial para escapar "Panicen de falha em tempo de execução" em situações erradas, por exemplo, em uma situação de falta de memória, quando as operações de alocação de memória dinâmica, incluindo operações de kernel, podem falhar.

Torvalds afirmou que tal foco no kernel é fundamentalmente inaceitável, E se você não entender este ponto, você pode rejeitar completamente qualquer código que tente usar tal abordagem. Por outro lado, o desenvolvedor do patch concordou com o problema e considerou-o solucionável.

Outro problema tem sido as tentativas de usar tipos de ponto flutuante ou 128 bits, que não são válidos para ambientes como o kernel Linux.

Você pode não entender as ramificações de quando isso pode acontecer, então talvez
é menos problemático do que eu penso, mas fundamentalmente
Eu acho que se qualquer mapeamento de Rust pode causar pânico, isso é simplesmente
_ fundamentalmente_ não é aceitável.

Mapeamento de falhas em um controlador ou código não-core, ou seja, para
definição, todo novo código Rust, nunca pode NUNCA causar
pânico validamente. O mesmo vale para «oh, em alguns casos eu não tentei o uso de
Inteiros de 128 bits ou ponto flutuante '.

Portanto, se o compilador Rust causar atribuições ocultas que não podem ser
detectar e retornar como erros, então acredito seriamente que tudo isso
abordagem deve ser completamente NAK'ed, e a infraestrutura Rust,
tanto no nível do compilador quanto nos wrappers do kernel, você precisa de mais
trabalhar

Isso acabou sendo um problema mais sério., desde neste momento A biblioteca central de Rust é indivisível e representa uma grande mancha; não há como solicitar apenas alguns dos recursos, evitando assim o uso de uma ou outra funcionalidade problemática.

A solução para o problema pode exigir mudanças no compilador e na biblioteca do Rust, embora a equipe ainda não tenha uma estratégia sobre como implementar a modularidade para bibliotecas de linguagem.

Além disso, Torvalds apontou que o controlador de exemplo fornecido é inútil e aconselhado a anexar como exemplo um driver que resolva um dos problemas reais.

Antes disso O Google anunciou sua participação em uma iniciativa para promover o suporte a Rust no kernel Linux y forneceu aspectos técnicos da viabilidade de implementação do Rust para combater problemas que surgem de erros no trabalho com memória.

O Google acredita que Rust está pronto para se juntar ao C como uma linguagem de desenvolvimento Componentes do kernel do Linux. O artigo também fornece exemplos de uso da linguagem Rust para desenvolver drivers de kernel, no contexto de seu uso na plataforma Android (Rust é reconhecida como uma linguagem oficialmente suportada para desenvolvimento Android).

Note-se que O Google preparou um protótipo inicial de um controlador escrito em Rust para o mecanismo de comunicação entre processos do Binder, que permitirá uma comparação detalhada do desempenho e da segurança das implementações do Binder em C e Rust.

Em sua forma atual, o trabalho ainda não foi concluído, mas para quase todas as abstrações básicas da funcionalidade do kernel necessárias para o Binder funcionar, as camadas foram preparadas para usar essas abstrações no código Rust.

Por fim, se você quiser saber mais sobre isso, você pode verificar os detalhes no link a seguir.