Dans une récente discussion au sein de la communauté du noyau Linux, Linus Torvalds a clarifié sa position concernant l'intégration du code Rust dans le noyau, en réponse aux objections de certains mainteneurs. Cette intervention fait suite aux préoccupations exprimées par Christoph Hellwig, un développeur influent du noyau, qui s'oppose à l'utilisation de Rust aux côtés du C traditionnel. Hellwig a notamment affirmé que l'introduction de Rust entraînerait une fragmentation et des directives de langage ambiguës, imposant une charge supplémentaire aux mainteneurs. Il a également rapporté que Torvalds aurait indiqué en privé son intention de fusionner du code Rust, même en cas d'opposition de la part des mainteneurs concernés.L’introduction de Rust dans le noyau Linux est l’un des changements techniques les plus significatifs de ces dernières années. Ce langage de programmation, réputé pour sa sécurité mémoire et sa modernité par rapport au C, a suscité un débat intense parmi les développeurs du noyau.
Depuis l'annonce de la prise en charge expérimentale de Rust dans le noyau Linux, plusieurs mainteneurs ont exprimé des inquiétudes quant à l'impact de ce changement. Parmi eux, Christoph Hellwig a pris une position ferme contre l'utilisation de Rust, mettant en avant des arguments relatifs à la complexité et à la fragmentation du développement du noyau.
Hellwig, connu pour ses opinions tranchées, a notamment affirmé que l'introduction de Rust compliquerait le travail des développeurs en les obligeant à apprendre et à maintenir un deuxième langage aux côtés du C. Il a aussi insisté sur le fait que Rust apporterait une surcharge inutile pour les outils et les chaînes de compilation, ce qui compliquerait le travail des mainteneurs. Il a déclaré : « si vous voulez rendre Linux impossible à maintenir à cause d'une base de code interlangage, faites-le dans votre pilote pour que vous ayez à le faire au lieu de répandre ce cancer dans les sous-systèmes centraux... Je ne veux pas qu'il s'approche d'une énorme base de code C que je dois maintenir ».
Dans ce contexte, Hellwig a récemment affirmé que Linus Torvalds lui-même aurait envisagé d’intégrer du code Rust dans le noyau malgré les objections des mainteneurs concernés :
Envoyé par Christoph Hellwig
« Certains sous-systèmes peuvent décider de ne pas avoir de code Rust pour le moment, généralement pour des raisons de bande passante. C'est une bonne chose et on s'y attend ». Alors que Linus a dit en privé qu'il allait absolument fusionner du code Rust malgré l'objection d'un mainteneur. (Il l'a fait en privé au cas où vous chercheriez une référence.)
Ainsi, à partir de maintenant, en tant que développeur ou mainteneur Linux, vous devez faire face à Rust, que vous le vouliez ou non.
Ainsi, à partir de maintenant, en tant que développeur ou mainteneur Linux, vous devez faire face à Rust, que vous le vouliez ou non.
Torvalds clarifie sa position : Rust ne sera pas imposé
Face aux préoccupations soulevées, Linus Torvalds a rapidement répondu pour rectifier les déclarations de Hellwig. Il a affirmé qu'il n'était pas question d'imposer Rust aux mainteneurs qui ne souhaitent pas travailler avec ce langage.
Torvalds a expliqué que les mainteneurs ne seront pas contraints d'interagir avec du code Rust s'ils n'en voient pas l’utilité. Cependant, cela ne signifie pas qu'ils ont le droit de bloquer son intégration dans des domaines où il est jugé bénéfique.
Il a précisé que la demande d’intégration d’un module en Rust, qui était à l’origine du débat, n’avait aucune incidence directe sur le code existant maintenu par Hellwig. Dès lors, il n’était pas justifié que ce dernier cherche à bloquer l’évolution du noyau dans ce sens.
Torvalds a également insisté sur un principe fondamental du développement de Linux : le pragmatisme et la flexibilité. Selon lui, l'objectif n'est pas d'obliger quiconque à travailler avec Rust, mais de permettre à ceux qui veulent l’utiliser de le faire sans contraintes excessives.
Ci-dessous, un extrait de son courriel adressé à Hellwig :
Le fait est que la pull request à laquelle vous vous êtes opposé n'a PAS DU TOUT TOUCHÉ À LA COUCHE DMA. Il s'agissait littéralement d'un autre utilisateur, dans un sous-répertoire complètement séparé, qui ne modifiait pas le code que vous maintenez de quelque manière que ce soit... Honnêtement, ce que vous avez fait, c'est essentiellement dire "en tant que mainteneur du DMA, je contrôle ce à quoi le code DMA est utilisé".
Et ce n'est pas du tout comme cela que cela fonctionne. Quelle est la prochaine étape ? Dire que certains pilotes ne peuvent pas faire de DMA, parce que vous n'aimez pas ce périphérique, et qu'en tant que mainteneur DMA vous contrôlez qui peut utiliser le code DMA ? C'est littéralement exactement ce que vous essayez de faire avec le code Rust. Vous dites que vous n'êtes pas d'accord avec Rust - ce qui est très bien, personne ne vous a jamais demandé d'écrire ou de lire du code Rust. Mais ensuite, vous prenez cette position pour signifier que le code Rust ne peut même pas utiliser ou s'interfacer avec le code que vous maintenez...
Vous n'êtes pas obligé d'aimer Rust. Vous n'avez pas à vous en préoccuper. Cela a été dit clairement dès le début, personne n'est obligé d'apprendre soudainement un nouveau langage, et les personnes qui veulent travailler uniquement en C peuvent continuer à le faire. Pour en revenir au cœur même de votre déclaration :
"Le document affirme qu'aucun sous-système n'est forcé de prendre Rust"
c'est tout à fait vrai. Vous n'êtes pas obligé de prendre du code Rust, ou de vous préoccuper du code Rust dans le code DMA. Vous pouvez l'ignorer...
On ne peut pas avoir le beurre et l'argent du beurre. Vous ne pouvez pas dire « Je ne veux rien avoir à faire avec Rust », et dans la phrase suivante dire « Et cela signifie que le code Rust que j'ignorerai ne pourra pas utiliser les interfaces C que je maintiens ».... Ainsi, lorsque vous modifiez les interfaces C, les gens de Rust devront faire face aux retombées, et devront corriger les liaisons Rust. C'est un peu la promesse ici : il y a ce « mur de protection » autour des développeurs C qui ne veulent pas s'occuper des problèmes Rust dans la promesse qu'ils n'ont pas devoir s'occuper de Rust.
Mais ce « mur de protection » va dans les deux sens. Si vous ne voulez pas vous occuper du code Rust, vous n'avez rien à dire sur le code Rust. En d'autres termes, « personne n'est obligé de traiter avec Rust » n'implique pas que « tout le monde est autorisé à opposer son veto à tout code Rust ».
Et ce n'est pas du tout comme cela que cela fonctionne. Quelle est la prochaine étape ? Dire que certains pilotes ne peuvent pas faire de DMA, parce que vous n'aimez pas ce périphérique, et qu'en tant que mainteneur DMA vous contrôlez qui peut utiliser le code DMA ? C'est littéralement exactement ce que vous essayez de faire avec le code Rust. Vous dites que vous n'êtes pas d'accord avec Rust - ce qui est très bien, personne ne vous a jamais demandé d'écrire ou de lire du code Rust. Mais ensuite, vous prenez cette position pour signifier que le code Rust ne peut même pas utiliser ou s'interfacer avec le code que vous maintenez...
Vous n'êtes pas obligé d'aimer Rust. Vous n'avez pas à vous en préoccuper. Cela a été dit clairement dès le début, personne n'est obligé d'apprendre soudainement un nouveau langage, et les personnes qui veulent travailler uniquement en C peuvent continuer à le faire. Pour en revenir au cœur même de votre déclaration :
"Le document affirme qu'aucun sous-système n'est forcé de prendre Rust"
c'est tout à fait vrai. Vous n'êtes pas obligé de prendre du code Rust, ou de vous préoccuper du code Rust dans le code DMA. Vous pouvez l'ignorer...
On ne peut pas avoir le beurre et l'argent du beurre. Vous ne pouvez pas dire « Je ne veux rien avoir à faire avec Rust », et dans la phrase suivante dire « Et cela signifie que le code Rust que j'ignorerai ne pourra pas utiliser les interfaces C que je maintiens ».... Ainsi, lorsque vous modifiez les interfaces C, les gens de Rust devront faire face aux retombées, et devront corriger les liaisons Rust. C'est un peu la promesse ici : il y a ce « mur de protection » autour des développeurs C qui ne veulent pas s'occuper des problèmes Rust dans la promesse qu'ils n'ont pas devoir s'occuper de Rust.
Mais ce « mur de protection » va dans les deux sens. Si vous ne voulez pas vous occuper du code Rust, vous n'avez rien à dire sur le code Rust. En d'autres termes, « personne n'est obligé de traiter avec Rust » n'implique pas que « tout le monde est autorisé à opposer son veto à tout code Rust ».
Une réponse loin de faire l'unanimité
Si certains ont apprécié le retour plus modéré d'un Linus Torvalds qui aurait, selon eux, été plus incendiaire il y a deux décennies, d'autres estiment que le problème n'est pas résolu en réalité. Nous avons par exemple ce développeur qui indique qu'il s'y prend « trop tard » (le débat a débuté depuis plusieurs mois déjà) et qu'en plus il ne répond pas vraiment aux arguments avancés :
« Le problème est que les développeurs C ne veulent pas maintenir le code Rust. Les développeurs de Rust disent qu'ils le feront. Le problème est que la règle de Linus dit que les développeurs C sont obligés de réparer le code Rust s'ils le cassent, et donc, l'idée que "vous ne pouvez pas contrôler les utilisateurs de votre code" tombe à plat, parce que la règle de Linus dit qu'ils sont obligés de maintenir tous les utilisateurs de leur code, ce qui signifie maintenant qu'ils doivent maintenir le code Rust. C'est la question fondamentale que les deux parties doivent accepter. Le fait que les développeurs de R4L disent qu'ils s'occuperont du problème quand il sera cassé ne changera rien au fait que les règles de Linus disent que cela ne doit pas se produire en premier lieu. Et non seulement cette règle doit changer, mais les développeurs C only doivent croire que Linus ne va pas simplement revenir sur ce changement de règle à l'avenir. Plus Linus attendra pour régler ce problème, plus il y aura de drames et moins les gens pourront croire que Linus ne...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
