Rust pour les systèmes de fichiers

Utiliser Rust pour les systèmes de fichiers

Objectifs

• Utiliser le système de types de Rust pour détecter davantage d’erreurs à la compilation
• Automatiser des tâches comme la libération des ressources afin d’améliorer la productivité par rapport au code C
• Réduire les vulnérabilités liées à la mémoire et raccourcir le temps de débogage

Avantages de Rust

• Rust élimine les comportements indéfinis et offre des mécanismes permettant de voir ce qui se passe à l’intérieur du code
• Il est possible de prouver la justesse du code écrit en Rust, ce qui réduit les bugs qui freinent le développement de fonctionnalités

Exemple du système de types de Rust

• La fonction iget_locked() comporte des exigences complexes
• En Rust, elle peut être remplacée par la fonction get_or_create_inode(), et le système de types permet d’imposer ces exigences

Discussion sur le changement de nom des API

• Problème de divergence de noms entre l’API C et l’API Rust
• Cela peut ne pas être familier à la communauté de développement existante
• Il peut être nécessaire d’aligner les noms

Problèmes généraux

• Il faut décider si les abstractions Rust seront utilisées de manière générale pour tous les systèmes de fichiers du noyau, ou si elles se concentreront uniquement sur des systèmes de fichiers simples écrits en Rust
• À mesure que le code C évolue, des problèmes de synchronisation avec le code Rust peuvent apparaître

Problèmes de cycle de vie des objets

• Le cycle de vie des objets peut varier selon le système de fichiers
• Encoder un cycle de vie unique dans l’API Rust peut ne pas fonctionner pour certains systèmes de fichiers

Problèmes des bindings Rust

• Tous les systèmes de fichiers ne passeront pas immédiatement à Rust
• À mesure que le code C évolue, les bindings Rust peuvent se casser
• Si les bindings Rust se cassent, cela restera un problème à la charge des développeurs de Rust-for-Linux

Conclusion

• Continuer à développer les bindings Rust tout en laissant le code C évoluer
• Avec le temps, on verra plus clairement s’il est bon ou mauvais d’encoder beaucoup de sémantique dans le système de types de Rust

Le résumé de GN⁺

• Introduire Rust dans les systèmes de fichiers aidera grandement à améliorer la sûreté mémoire et la productivité
• Le système de types de Rust permet d’imposer des exigences API complexes, ce qui améliore la justesse du code
• Si les développeurs C existants n’apprennent pas Rust, des difficultés comme les problèmes de synchronisation peuvent survenir
• Si les bindings Rust se cassent, ce sera aux développeurs de Rust-for-Linux de les corriger
• Un projet aux fonctionnalités similaires est Fuchsia OS de Google

[GN⁺]

Commentaires sur Hacker News

• Le fait que chaque système de fichiers gère différemment le cycle de vie des inodes tout en les traitant avec une même fonction va à l’encontre de la couche d’abstraction

  • Le cycle de vie des inodes devrait être géré par chaque système de fichiers

• Une question est soulevée sur la nécessité de modifier Rust pour faciliter les appels vers C

  • Il y a un manque de compréhension claire de l’interopérabilité entre Rust et C
  • En C++ et en Objective-C, il suffit d’inclure les fichiers d’en-tête et d’appeler les fonctions
  • Swift peut inclure des fichiers Objective-C et appeler du C
  • Plutôt que d’adapter Rust aux développeurs du kernel, le langage lui-même aurait peut-être besoin d’un peu plus de souplesse

• Il n’est pas clair si l’API Rust encapsule l’API C ou la réimplémente

  • Si c’est une réimplémentation, utiliser les mêmes noms que l’API C peut poser problème

• Ajouter Rust au kernel entraîne une complexité supplémentaire

  • Si l’on écrit un nouvel OS à partir de zéro, on peut utiliser toutes les fonctionnalités du langage
  • L’ajouter à une vaste base de code existante crée des problèmes supplémentaires

• La discussion est très civilisée

  • Désaccord avec le ton négatif
  • Optimisme quant au fait que les personnes concernées aient clairement exposé les problèmes

• Avoir davantage d’options dans le kernel Linux est toujours bénéfique

  • Rust n’est pas la solution à tous les problèmes
  • Rust offre un modèle de programmation sûr, mais limité
  • Problèmes de mémoire ? Utilisez Rust !
  • Problèmes de concurrence ? Passez à Rust !
  • Mais il est impossible de tout faire comme en C sans utiliser de blocs unsafe
  • Rust peut apporter une nouvelle perspective, mais ce n’est pas une solution complète

• Certains commentaires en bas de la page lwn.net sont impolis

  • Imaginez écrire à quelqu’un qui contribue à un projet open source : « la science progresse d’un enterrement à la fois »

• Discussion sur le problème d’incohérence des noms entre l’API C et l’API Rust

  • La difficulté des conventions de nommage héritées
  • On peut soit conserver les mêmes noms, soit encapsuler avec de nouveaux noms
  • Nommer les choses est difficile