- Du code Rust implémentant l’API Direct Memory Access a été proposé au dépôt du noyau Linux via une pull request.
- Christoph Hellwig, mainteneur intermédiaire du noyau Linux, l’a rejeté en affirmant qu’il ne fallait pas faire entrer du code Rust dans le noyau Linux, ce qui a déclenché le conflit.
- À mesure que la controverse prenait de l’ampleur, Christoph Hellwig a comparé Rust à des cellules cancéreuses.
- Hector Martin, responsable principal d’Asahi Linux, a réagi vivement à cette comparaison et a vivement critiqué la situation sur les réseaux sociaux, en y impliquant Linus Torvalds.
- Linus Torvalds a averti Hector Martin que « le problème, c’est vous-même » et lui a demandé de « ne pas faire de brigading sur les réseaux sociaux ».
- Hector Martin demande désormais à quitter son rôle de mainteneur du code Linux en amont prenant en charge le matériel compatible Apple Arm.
28 commentaires
Le résumé ne mentionne que les événements survenus, mais à la fin du texte original (en coréen), deux informations de contexte supplémentaires sont ajoutées pour mieux comprendre ce qui s’est passé.
Je pense qu’il vaut mieux gérer un projet avec un langage unique, mais indépendamment de cela, la manière de convaincre ses collègues est vraiment la pire.
Forcer quelqu’un à se soumettre par le pouvoir, c’est absurde.
Voici le fil d’e-mails de cette PR :
https://lwn.net/ml/all/…
Il semble que cette PR ne modifie pas l’implémentation de DMA ni ne touche directement à l’API DMA, mais qu’elle ajoute des bindings FFI pour permettre à Rust d’accéder à l’API DMA.
Et cette PR a été rejetée par la réponse laconique « No rust code in kernel/dma, please. », https://lwn.net/ml/all/20250108135951.GA18074@lst.de/
Puis, lorsqu’on lui a demandé ce qu’il faudrait faire, il a répondu : « Keep the wrappers in your code instead of making life painful for others. » https://lwn.net/ml/all/20250108151858.GB24499@lst.de/
(C’est bien ce qui a été fait. La PR ne modifiait pas
kernel/dma, mais le sous-arbrerust/kernel.)Bien sûr, si des bindings FFI sont ajoutés, cela crée la contrainte de devoir aussi mettre à jour les bindings FFI Rust quand l’API DMA change,
mais même si le camp qui touche à Rust a dit qu’il s’en chargerait, je ne sais pas vraiment si le fait qu’une personne qui n’est pas responsable de cet arbre réagisse ainsi est approprié.
(Christoph Hellwig est le mainteneur principal de
kernel/dma: https://docs.kernel.org/process/maintainers.html#dma-mapping-helpers)C’est sans doute pour cela que Hector Martin a fait intervenir Linus dans le fil :
https://lwn.net/ml/all/2b9b75d1-eb8e-494a-b05f-59f75c92e6ae@marcan.st/
Mais ce qui s’est dit dans le fil juste avant est assez intéressant :
si l’API subit un breaking change et que l’équipe Rust ne réagit pas assez vite, la build casse et Linus n’accepte pas la PR.
Si je vois ça comme un problème entre le module qui a introduit le breaking change et un autre module, j’ai plutôt l’impression que la situation avec Rust est meilleure.
Le module x a introduit un breaking change, et le module y n’a pas pu réagir assez vite :
Dans le noyau Linux, les parties où Rust utilise
unsafesont pour la plupart celles qui servent d’enrobage autour du code C.Il y a aussi, en dehors de cela, quelques parties de contrôle matériel où il faut manipuler directement la mémoire, mais elles sont très limitées.
Là où Rust est appliqué, c’est au développement de pilotes. Il n’est ni nécessaire ni possible de toucher au noyau lui-même, comme la gestion mémoire ou la block layer.
Il y a bien plus de code dans les pilotes que dans le code du noyau lui-même. Et la plupart des problèmes surviennent aussi dans le code des pilotes.
Je pense qu’il est juste que la partie développement de pilotes soit réalisée dans un langage offrant une meilleure sûreté mémoire et une meilleure sécurité que le C.
Que ce soit Rust, Zig ou autre, je ne sais pas encore.
Je comprends aussi l’idée que Rust est excessivement complexe pour développer des applications classiques et qu’il est difficile à apprendre rapidement pour un développeur C.
Malgré cela, quel que soit le langage, j’espère qu’au moins le développement de pilotes passera à un langage moderne.
Dans mon entreprise précédente, il nous a fallu environ sept ans pour développer et stabiliser un pilote de quelques milliers de lignes seulement ; on ne peut pas tout simplifier à ce point, mais j’ai l’impression qu’environ trois ans ont été consacrés uniquement au débogage.
La plupart des problèmes étaient des bugs liés à la mémoire. Les erreurs logiques comme les interblocages étaient minoritaires.
Je ne trouve pas très judicieux d’utiliser un grand projet comme terrain d’essai pour son propre langage.
S’il le faut, on devrait revenir à l’époque où on forkait quand ça tournait mal.
Pour un kernel qui gère l’ensemble du matériel, même si on utilise Rust, dès qu’on commence à écrire de l’
unsafe, on finit de toute façon avec du code difficile à lire, c’est en tout cas ce que je pense.Ce n’est pas non plus un projet sans vraie release majeure du genre 0.91, 0.92, 0.99, 0.991 ou je ne sais quoi, donc je ne vois pas pourquoi ils portent des parties qui fonctionnaient très bien.
Ce n’est même pas comme s’ils corrigeaient un gros bug et en profitaient pour rendre ça plus sûr.
Cette PR n’est pas un portage. C’est une PR qui ajoute, côté Rust, des liaisons FFI pour que l’API DMA existante puisse aussi être utilisée dans des modules basés sur Rust nouvellement écrits. Et c’est le responsable de DMA qui l’a bloquée.
C’est dommage que le texte original cité ne figure pas dans l’article. Par curiosité, je suis allé le chercher et le lire, et même si je n’ai pas tout parfaitement saisi, j’ai l’impression qu’il y a pas mal de contexte supplémentaire, si bien qu’on ne peut pas simplement en parler comme le fait le texte original.
Le titre de l’article a été remplacé par son intitulé d’origine.
Merci pour le traitement.
Ajouter Rust à une grande base de code en C n’est finalement pas aussi enthousiasmant qu’on pourrait le croire. Si l’objectif est d’améliorer la sécurité mémoire, l’efficacité réelle semble limitée de toute façon, puisque la part de code
unsafefinit par devenir importante... Au fond, cela ne semble pas avoir beaucoup plus de sens que d’élargir simplement le périmètre d’utilisation de Rust... Il me paraît donc naturel que cela provoque une réaction de rejet chez les développeurs C existants. Il vaudrait peut-être mieux se concentrer sur un véritable projet de noyau lancé en Rust dès le départ.Franchement, la qualité du contenu est meilleure que je ne l’imaginais ; c’était une lecture vraiment agréable.
L’idée de Torvalds, en disant que le problème, c’est vous, était que, indépendamment de l’adoption de Rust, les réseaux sociaux ne peuvent pas être la réponse à des problèmes techniques ; mais avec ce seul résumé, il me semble qu’il y a un risque de malentendu.
Pour Hector Martin, c’était un choix inévitable.
Les cadres intermédiaires de Linux étant tous des experts en C, il n’y avait aucune chance qu’ils prennent en compte l’avis de la petite minorité de développeurs Rust.
https://youtu.be/opTJH76wJxs?si=WHR0_1uPpSlpDTHr montre comment cela a dégénéré en polémique.
Torvalds n'autorisait pas non plus Rust ?
Torvalds n’a pas dit un mot sur Rust dans cette controverse.
Quand il y a un désaccord d’opinions techniques, il faut mener le débat sur des bases techniques,
et non pas essayer d’y mettre fin en fabriquant l’opinion publique sur les réseaux sociaux.
Si vous êtes si doués que ça, fork ez le kernel et réécrivez-le entièrement en Rust. Au lieu de vous y infiltrer petit à petit comme un cancer. On voit beaucoup d’avis de ce genre.
Je ne sais pas si le code en question touchait à
kernel/dmapour le rendre plus facile à utiliser depuis Rust, mais c’était un code qui ajoutait àrust/kernel/dmaune couche FFI encapsulantkernel/dma. Le code source d’origine n’a pas été modifié.En réalité, le point central, c’était plutôt quelque chose comme : je n’aime pas qu’on vienne me demander de l’aide après avoir mal utilisé l’interface DMA FFI officielle écrite en Rust... Et ensuite, il a dit quelque chose qui ne tenait pas debout : qu’on laisse simplement chaque pilote se débrouiller pour fabriquer sa propre FFI.
C’est Redox. Il y a sans doute encore des éléments non pris en charge, donc ils se tournent vers Linux…
https://vt.social/@lina/113064510447670892
Ce que vous avez écrit semble reprendre entièrement les propos de Hellwig tels quels, mais je ne sais pas si l’on peut considérer que cet avis est majoritaire.
Bonjour. Merci d’avoir publié ce bon article. Je l’ai lu avec plaisir.
Cependant, après avoir vérifié le texte original et son titre, j’ai quelques réserves, donc je me permets de laisser ce commentaire.
https://news.hada.io/guidelines
> En principe, merci de reprendre le titre original de l’article, ou de le publier avec un titre traduit en coréen.
C’est ce qui est suggéré. Et après avoir lu le contenu de l’article concerné, je pense que le titre « Le débat sur Rust dans le noyau Linux s’embrase à nouveau » rend mieux compte du texte, tandis que « Linus Torvalds : “Le problème, c’est vous” » risque davantage d’induire une mauvaise compréhension du contenu que le titre d’origine.
Merci encore pour le résumé et pour avoir présenté l’article. Je vous souhaite une excellente journée.
super génial
Je vais en prendre note.
'm 'b Bonne journée ! Merci, grâce à vous j’ai pu lire un bon article. (__ )
J’avais l’habitude d’ajouter mon propre sous-titre au titre pour apporter une explication plus précise, mais non seulement le titre ne convenait pas à une autre personne, je ne savais pas non plus qu’il existait une telle règle. À partir de la prochaine fois, je publierai le texte original tel quel.
Le titre original permet de comprendre immédiatement de quoi il s’agit, tandis que le titre modifié pourrait donner l’impression d’un titre racoleur. Ce n’est que mon avis personnel.
Merci pour votre avis.
J’estimais que les propos de Linus étaient les plus importants, c’est pourquoi je les ai mis dans le titre, mais il semble que cela les ait fortement déformés.
Je ferai clairement plus attention.