Miguel Ojeda est un informaticien du CERN à Genève, en Suisse, qui travaille maintenant à plein temps sur le projet Rust for Linux. Dans son billet, il a commencé par expliquer que les allocations infaillibles ont été supprimées par le biais d'un crate de bibliothèque standard "alloc" personnalisé. En effet, une allocation infaillible, c'est lorsqu'un développeur suppose qu'une allocation de mémoire va toujours réussir. Si elle ne réussit pas, Rust met fin au processus. Les allocations infaillibles ne sont pas acceptables dans le noyau, car les échecs provoquent une panique du noyau. Une allocation faillible permet au développeur de tester le succès.
Ojeda a écrit que les intrinsèques de panique de "compiler_builtins" sont toujours là, mais ils seront résolus en partitionnant "core" via des portes de fonctionnalités. La première, pour désactiver la fonctionnalité de virgule flottante, vient d'être acceptée en amont. « À terme, l'objectif est d'avoir tout ce dont le noyau a besoin dans "alloc" en amont et de le supprimer de l'arbre du noyau », a-t-il déclaré. Plusieurs autres améliorations majeures ont été apportées au support général de Rust. Les sous-sections suivantes les couvrent.
Support d'un compilateur Rust bêta
Rust for Linux nécessite de nouvelles fonctionnalités dans le compilateur Rust (rustc) ainsi que dans le code du noyau. Mais jusqu'à présent, le projet n'a utilisé que les versions nightly de rustc, car il a besoin des derniers correctifs et des fonctionnalités instables. Cela n'est plus désormais nécessaire, car le noyau peut maintenant être compilé avec les versions bêta et stable de rustc. Pour le moment, le projet utilise la version 1.54-beta1 comme compilateur de référence. À la fin de ce mois, la version 1.54 de rustc sera publiée, et le projet passera à cette version comme référence.
Notez que le noyau nécessite toujours des fonctionnalités instables, même s'il est compilé avec une version stable de rustc. Ainsi, Ojeda a déclaré que l'équipe ne pourra pas garantir que les futures versions de rustc fonctionneront sans changements dans l'arbre du noyau. « De ce fait, jusqu'à ce que toutes les fonctionnalités instables dont nous avons besoin soient stabilisées, nous supporterons une seule version de rustc pour chaque version du noyau », a-t-il déclaré. L'écriture de tests unitaires pour le code du noyau Rust fonctionne maintenant avec l'attribut standard Rust #test.
Ils ne s'exécutent pas encore dans le noyau, mais selon Ojeda, « l'objectif est de les faire fonctionner dans l'espace du noyau, afin que nous puissions tester le code qui dépend des fonctionnalités du noyau ».
Architectures et support du compilateur
« Nous avons demandé à Compiler Explorer d'ajouter le support de tous les compilateurs alternatifs. Au moment d'écrire ces lignes, ils ont déjà ajouté mrustc et GCC Rust ; et rustc_codegen_gcc sera bientôt disponible », a-t-il déclaré. Autrement dit, les architectures ARM et RISC-V sont maintenant supportées, grâce au travail sur rustc_codgen_gcc, qui est un codegen GCC pour rustc. Cela signifie que rustc effectue la compilation initiale du code Rust, mais que GCC (la collection de compilateurs GNU) effectue la compilation finale, ce qui permet la prise en charge des architectures que GCC supporte.
Il existe une proposition pour fusionner ce travail dans la base de code principale de Rust, ce qui soulève un problème de licence, car Rust utilise les licences MIT et Apache v2 alors que GCC utilise la GPLv3. La Fondation Rust a examiné la question et a conclu que : « le changement proposé n'aura pas d'impact sur la licence de rustc sauf lorsqu'il est construit avec le back-end gcc, auquel cas la GPLv3 s'appliquera au binaire résultant » – ce qui signifie le binaire du compilateur, pas les applications qu'il compile.
Abstractions Rust et mises à jour des pilotes
Ojeda a annoncé que l'équipe de Rust for Linux a développé de nouvelles abstractions Rust qui utilisent les implémentations du noyau C, notamment : red-black trees, reference-counted objects, file descriptor creation, tasks, files, io vectors, etc. En outre, l'équipe a aussi amélioré le support des pilotes : améliorations de "file_operations" (plus d'opérations supportées, état arbitraire), de la macro module!, des macros d'enregistrement, des pilotes de plateforme rudimentaires ("probe" et "remove", la réduction du code passe-partout, etc.
Selon le message d'Ojeda, sur Binder, il y a maintenant un support pour le transfert des descripteurs de fichiers et des hooks LSM ; et l'équipe travaille sur des chiffres préliminaires de performance. De plus, un travail est en cours sur un pilote d'exemple Rust, bcm2835-rng. Il s'agit du générateur de nombres aléatoires matériel présent sur les Raspberry Pi Zero(W), Classic, Two et Three. Il y a d'autres petites améliorations, comme le fait que les pilotes sont limités sur les fonctionnalités instables qu'ils peuvent utiliser.
Quel est le statut des séries de correctifs ?
Selon Ojeda, la prise en charge de Rust est toujours considérée comme expérimentale. Cependant, comme indiqué en avril, le support est suffisamment bon pour que les développeurs du noyau puissent commencer à travailler sur les abstractions Rust pour les sous-systèmes et écrire des pilotes et autres modules. Il faut noter que les séries actuelles de correctifs viennent "linux-next", donc la première exécution a eu lieu mardi dernier.
Soutien de la communauté à Rust for Linux
Le projet bénéficie d'un soutien important de la part de l'industrie. En avril, Google a déclaré : « Nous pensons que Rust est désormais prêt à rejoindre le langage C en tant que langage pratique pour l'implémentation du noyau et que cela réduirait le nombre de bogues et de failles de sécurité potentiels ». Google sponsorise Ojeda pour qu'il travaille à temps plein sur le projet pendant un an, par l'intermédiaire de l'ISRG (Internet Security Research Group). L'ISRG a déclaré le mois dernier que cela s'inscrivait dans le cadre des efforts visant à faire évoluer l'infrastructure logicielle critique d'Internet vers un code sûr pour la mémoire.
L'ISRG est également l'organisation à but non lucratif à l'origine des certificats de sécurité gratuits Let's Encrypt. Ojeda a mentionné que le groupe Linux Systems de Microsoft contribue et espère soumettre certains pilotes Hyper-V écrits en Rust. Arm promet une assistance avec Rust pour Linux sur les systèmes basés sur ARM. IBM a contribué au support du noyau Rust pour son processeur PowerPC. Plus de détails devraient être révélés lors de la prochaine conférence Linux Plumbers en septembre. En attendant, le projet est disponible sur GitHub.
Linus Torvalds a déclaré à plusieurs reprises qu'il se réjouissait de la possibilité d'utiliser Rust aux côtés de C pour le développement du noyau, et a déclaré à en avril que le projet a atteint un point où il pourrait être fusionné avec la version 5.14 du noyau.
Sources : Miguel Ojeda, Rust for Linux
Et vous ?
Quel est votre avis sur le sujet ?
Voir aussi
Linux 5.13 est disponible avec le support de l'Apple M1, Landlock, FreeSync HDMI et a été publié sous le nom de code "Opossums on Parade"
La prise en charge de Rust pour le développement du noyau Linux commence à prendre forme, le langage fait un premier pas vers la branche "Linux-Next"
La prise en charge de Rust pour le développement du noyau Linux fait l'objet d'une nouvelle série de discussions, après une proposition de RFC
Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google