Rust para sistemas de arquivos

Usando Rust em sistemas de arquivos

Objetivos

• Usar o sistema de tipos do Rust para detectar mais erros em tempo de compilação
• Aumentar a produtividade em relação ao código em C automatizando tarefas como limpeza de recursos
• Reduzir vulnerabilidades relacionadas à memória e encurtar o tempo de depuração

Vantagens do Rust

• O Rust elimina comportamento indefinido e oferece recursos para ver o que está acontecendo dentro do código
• É possível provar a correção do código escrito em Rust, reduzindo bugs que atrapalham o desenvolvimento de funcionalidades

Exemplo do sistema de tipos do Rust

• A função iget_locked() tem requisitos complexos
• Em Rust, ela pode ser substituída pela função get_or_create_inode(), com o sistema de tipos impondo esses requisitos

Discussão sobre mudança de nomes de API

• Problema de inconsistência entre os nomes da API em C e da API em Rust
• Isso pode não ser familiar para a comunidade de desenvolvimento existente
• Pode ser necessário alinhar os nomes

Problemas gerais

• É preciso decidir se as abstrações em Rust serão usadas de forma geral em todos os sistemas de arquivos do kernel ou se o foco ficará apenas em sistemas de arquivos simples escritos em Rust
• À medida que o código em C evolui, podem surgir problemas de sincronização com o código em Rust

Problemas do ciclo de vida dos objetos

• O ciclo de vida dos objetos pode variar conforme o sistema de arquivos
• Codificar um único ciclo de vida na API Rust pode fazer com que ela não funcione em alguns sistemas de arquivos

Problemas dos bindings em Rust

• Nem todos os sistemas de arquivos vão migrar imediatamente para Rust
• À medida que o código em C evolui, os bindings em Rust podem quebrar
• Se os bindings em Rust quebrarem, isso continuará sendo um problema dos desenvolvedores do Rust-for-Linux

Conclusão

• Continuar desenvolvendo os bindings em Rust enquanto o código em C continua evoluindo
• Com o tempo, ficará mais claro se codificar muito significado no sistema de tipos do Rust é algo bom ou ruim

Resumo do GN⁺

• Introduzir Rust em sistemas de arquivos deve ajudar bastante a aumentar a segurança de memória e a produtividade
• O sistema de tipos do Rust pode impor requisitos complexos de API, aumentando a correção do código
• Se os desenvolvedores de C existentes não aprenderem Rust, podem surgir dificuldades como problemas de sincronização
• Se os bindings em Rust quebrarem, caberá aos desenvolvedores do Rust-for-Linux corrigi-los
• Um projeto com funcionalidade semelhante é o Fuchsia OS, do Google

[GN⁺]

Comentários do Hacker News

• Gerenciar todos com a mesma função, enquanto cada sistema de arquivos administra o ciclo de vida de inode de forma diferente, vai contra a própria camada de abstração

  • O ciclo de vida de inode deve ser gerenciado por sistema de arquivos

• Há questionamentos sobre se o Rust precisa mudar para facilitar mais chamadas em C

  • Falta uma compreensão clara da interoperabilidade entre Rust e C
  • Em C++ e Objective C, basta incluir arquivos de cabeçalho e chamar funções
  • Swift pode incluir arquivos Objective C e chamar C
  • Em vez de o Rust se moldar aos desenvolvedores de kernel, talvez a própria linguagem precise se tornar um pouco mais flexível

• Não está claro se a API Rust envolve a API C ou a reimplementa

  • Se for uma reimplementação, usar os mesmos nomes da API C pode causar problemas

• Adicionar Rust ao kernel traz complexidade extra

  • Se um novo SO fosse escrito do zero, seria possível usar todos os recursos da linguagem
  • Ao adicioná-lo a uma base de código existente e enorme, surgem problemas adicionais

• A discussão está sendo muito civilizada

  • Não concordam com o tom negativo
  • Há otimismo pelo fato de as pessoas envolvidas terem comunicado os problemas com clareza

• Ter mais opções no kernel Linux é sempre benéfico

  • Rust não é a solução para todos os problemas
  • Rust oferece um modelo de programação seguro, mas limitado
  • Problemas de memória? Use Rust!
  • Problemas de concorrência? Migre para Rust!
  • Mas não é possível fazer tudo o que C faz sem usar blocos unsafe
  • Rust pode oferecer uma nova perspectiva, mas não é uma solução completa

• Alguns comentários no fim da página da lwn.net são rudes

  • Imagine dizer "a ciência avança com um funeral de cada vez" para alguém que contribui com um projeto de código aberto

• Há discussão sobre o problema de incompatibilidade de nomes entre a API C e a API Rust

  • A dificuldade das convenções de nomenclatura legadas
  • É possível manter os mesmos nomes ou encapsular com nomes novos
  • Dar nomes é uma tarefa difícil