Greg K-H : « Écrire tout nouveau code en Rust profite à tout le monde »
(lore.kernel.org)Pourquoi il faut introduire Rust dans le noyau Linux
- Fort de l’expérience acquise en examinant presque tous les correctifs de bugs et problèmes de sécurité du noyau Linux au cours des 15 dernières années, il explique pourquoi l’adoption de Rust est nécessaire
- Tous les correctifs de bugs ne sont pas intégrés à l’arbre des versions stables, mais en général les plus importants le sont, et il est dans une position où il vérifie tous les CVE du noyau
Les limites du C et les avantages de Rust
- La plupart des bugs qui surviennent dans le noyau Linux proviennent des limites structurelles du langage C
- En particulier, il existe de nombreux bugs causés par de simples erreurs, et ces problèmes surviennent rarement en Rust
- Écrasement mémoire (Rust ne détecte pas tous les cas, mais peut en résoudre une grande partie)
- Problèmes de nettoyage sur les chemins d’erreur
- Oubli de vérification des valeurs d’erreur
- Bugs de type use-after-free (utilisation après libération)
- L’introduction de Rust dans le noyau permet aux développeurs et mainteneurs de se libérer de ces erreurs de base pour se concentrer sur les vrais problèmes difficiles (erreurs logiques, conditions de concurrence, etc.)
Il faut aussi continuer à maintenir l’existant en C
- Le noyau Linux actuel est composé de plus de 30 millions de lignes de code C, et il est impossible de le remplacer par Rust à court terme
- Par conséquent, les travaux de renforcement de la sécurité du code C menés par des développeurs comme Kees et Gustavo sont indispensables et doivent se poursuivre
- L’idéal n’est pas que Rust remplace le code existant, mais d’écrire le nouveau code (en particulier les pilotes) en Rust afin de réduire les problèmes
La sûreté des API apportée par Rust
- Rust permet de concevoir les API internes du noyau de manière plus sûre et plus simple à utiliser
- Les API actuelles du noyau, basées sur C, sont complexes, propices aux erreurs, et demandent souvent une relecture très minutieuse de la part des mainteneurs
- Par exemple, il existe plusieurs façons d’utiliser correctement une structure comme
struct cdev, et il faut beaucoup d’expérience pour s’en servir comme il faut - Avec Rust, il est possible de définir plus clairement les API, ce qui réduit fortement la probabilité d’erreur côté développeur
- Ce n’est pas seulement utile pour les utilisateurs de Rust, mais aussi un changement bénéfique pour les utilisateurs du code C existant
Réponses aux inquiétudes sur la difficulté d’adopter Rust
- Rust n’est pas une solution miracle → mais il peut résoudre une grande partie des problèmes existants
- Augmentation de la charge des mainteneurs → mais les développeurs qui souhaitent introduire Rust font eux-mêmes le travail
- Difficulté de maintenance d’une base de code multilingue → mais le noyau Linux a déjà résolu des problèmes bien plus difficiles jusqu’ici
Conclusion
- Linux est un outil utilisé par d’innombrables développeurs dans le monde pour résoudre des problèmes,
- et désormais, s’il existe une demande de la part de développeurs qui veulent écrire du code sûr pour le matériel, il ne faut pas l’ignorer
- Le modèle de développement de Linux a grandi à une échelle que personne n’avait anticipée, en démontrant des capacités d’ingénierie exceptionnelles
- Il est maintenant temps d’aller de l’avant avec l’adoption de Rust pour préparer les plus de 20 prochaines années d’évolution
Il faut accueillir les nouvelles technologies et les nouvelles idées, et faire en sorte de réussir avec la communauté.
24 commentaires
L’adoption de Rust est sans doute un changement difficile à éviter si l’on prend en compte la memory safety. J’imagine qu’on essaiera probablement de recoudre tout ça en passant par un compromis acceptable.
Cela dit, personnellement, j’ai du mal à bien assimiler les mots-clés de Rust, et même quand j’y reviens longtemps après, j’ai du mal à m’en souvenir, donc je n’arrive pas vraiment à m’y mettre ;;;; Je sais bien qu’ils sont tous nécessaires, mais j’ai parfois l’impression d’apprendre de force des verbes irréguliers en anglais. En même temps, il est vrai aussi que les logiciels écrits en Rust causent moins de problèmes sur le terrain.....
Je me demande si le fait de refuser d’intégrer au kernel un langage qui n’est pas encore mature mérite vraiment d’être autant critiqué. Si on vous demandait tout de suite de trouver autour de vous des personnes vraiment à l’aise avec Rust, il n’y en aurait presque pas, non ? Je pense qu’il ne sera pas trop tard pour l’inclure une fois que le langage aura davantage mûri et qu’une base d’utilisateurs suffisante aura été constituée, même si elle n’atteint pas celle des langages legacy.
Je suis convaincu que l’utilité du langage Rust pourra être pleinement démontrée même sans application au kernel Linux.
Il est déjà surprenant d’entendre dire que Rust est encore « un langage immature » à ce stade, mais indépendamment de cela, je me demande s’il est vraiment si condamnable d’essayer, même maintenant, de réduire la part des langages non sûrs dans le noyau. Autour de vous, il n’y a sans doute pas tant de personnes capables d’écrire en C du code suffisamment sûr pour pouvoir contribuer au noyau, n’est-ce pas ? Plutôt que d’attendre une maturité supplémentaire du langage C, j’ai l’impression que le moment actuel, où les exigences d’une nouvelle époque sont désormais pleinement établies, n’est justement pas trop tard.
Rust est déjà utile, et s’il cherche à être inclus dans le noyau, ce ne sera probablement pas pour prouver son utilité.
Quand il a été décidé d’introduire Rust au départ, j’imagine qu’il y a dû y avoir des discussions à ce sujet.
Si l’on réfléchit à quel groupe est le plus large, entre les experts en C et les experts en Rust, c’est clairement C qui l’emporte largement.
Cela dit, on peut aussi se dire que, pour un programmeur qui possède déjà toutes les connaissances métier, apprendre un langage de plus n’est peut-être pas une si grosse affaire,
mais le niveau d’expertise exigé des personnes qui travaillent sur le noyau, c’est encore une autre histoire...
Cet avis est bien aussi.
Je ne comprends absolument pas l'argument disant qu'il devrait forker et partir. Pourquoi diable Linus devrait-il forker Linux et s'en aller ?
Y a-t-il quelqu’un qui dise à Linus de faire un fork et de partir ? Je n’ai pas l’impression d’avoir vu quelqu’un dire ça dans cette controverse..
J’utilise moi aussi Rust, mais si du code Rust et du code C se retrouvent mélangés dans un projet open source, alors à moins d’avoir des règles extrêmement strictes sur jusqu’où l’on autorise le code Rust, cela me semble ingérable, ou du moins le coût de revue et de maintenance risque d’exploser ; je pense donc que le choix le plus judicieux est de faire un fork plutôt que d’ajouter ce code.
Je ne m’y connais pas très bien en kernel, mais je me dis que ce serait bien si on pouvait traduire automatiquement du code C en Rust. Bien sûr, il y aura sans doute aussi des problèmes humains, pas seulement des problèmes de traduction de code.
S’il y a autant de personnes qui veulent introduire Rust dans le kernel, ne pourraient-elles pas faire un fork et partir sur un nouveau projet ? Puis, une fois suffisamment mûr, les principales distributions passeraient à un kernel basé sur Rust.
Je ne comprends pas très bien pourquoi ils se battent entre eux.
Je ne sais pas très bien si vous avez de l’expérience en développement du kernel, donc je ne sais pas trop quoi vous répondre, mais
d’abord, appliquer le langage Rust ne signifie pas remplacer le kernel par Rust. On peut se dire qu’il suffirait sinon de séparer cela et de créer un autre kernel, mais
l’idée n’est pas de créer le kernel en Rust ; il s’agit plutôt de créer uniquement en Rust un wrapper pour l’interface destinée aux pilotes de périphériques dans le kernel, afin que seuls les pilotes de périphériques puissent être développés en Rust.
C’est pourquoi partir sur un nouveau projet n’a pas de sens.
Je n’ai jamais développé côté Linux.
J’imagine donc que le wrapper Rust du pilote de périphérique a une structure qui ne peut pas être dissociée du noyau...
C’est assez ironique de voir que la communauté Linux, qui a longtemps justifié son ton toxique au nom de la stabilité du kernel, considère maintenant que répondre « si ça ne te plaît pas, fais un fork » est une réponse raisonnable.
Je ne fais pas partie de la communauté Linux, mais...
Je pense qu’il ne faut pas considérer ces personnes et l’auteur de ce commentaire comme appartenant à la même communauté.
J’ai l’impression qu’il y a un point difficile à prévoir : est-ce que le résultat du fork deviendra une migration, ou plutôt une période de chaos façon États combattants.
Même après le fork, répercuter les changements de l’upstream ne me semble pas être une situation très agréable.
https://fr.news.hada.io/topic?id=16860
Quand on voit que le fork de Realtime Linux n’a été fusionné qu’au bout de 20 ans, on peut se dire qu’il ne faudrait pas décider de forker à la légère.
C’est ce que je voulais dire en voyant ça.
Les fonctionnalités temps réel ont pu être maintenues pendant longtemps dans un projet séparé du noyau, et ceux qui en avaient besoin pouvaient les récupérer, les appliquer au noyau et les utiliser.
Bien que je sois utilisateur de Rust, le commentaire de hgwxx7_ publié sur r/rust m’a marqué1.
Je me souviens que lorsqu’un backport vers la version stable était nécessaire et que je le contactais, il répondait bien même au milieu de son emploi du temps chargé.
« Rust n’est pas la réponse absolue, mais il s’en rapproche davantage que Java et Python » -codemaster kimc-
Avis Hacker News
Est-ce qu’on ne peut pas signaler ce genre de commentaire haineux ?
Je suis d'accord.