Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Qui sommes nous ? Contact rédaction Contact site Forum
Flux RSS
GitHub Discord

À propos

Abonnez-vous

Rust dans le noyau Linux : nouvelles bisbilles, Linus Torvalds s’en mêle

Plume assassine

Rust dans le noyau Linux : nouvelles bisbilles, Linus Torvalds s’en mêle

Le noyau Linux contient du code Rust depuis bientôt trois ans. De petits ajouts, qui ont surtout consisté pendant un temps à permettre à du code Rust d’être ajouté, notamment dans les pilotes. Mais la progression du langage dans le noyau reste complexe.

Le 10 février à 16h15

C’est ce qu’a tenté de faire Hector Martin. Si le nom vous parle, c’est peut-être parce qu’il est le fondateur et développeur principal de la distribution Asahi Linux, spécialisée dans le support matériel des Mac équipés d’une puce Apple Silicon. Un travail qui l’a mené d’ailleurs à la faille « M1RACLES » dans les puces M1. Ou peut-être parce qu’il fut un redoutable hacker, spécialisé dans les consoles de jeu, tout particulièrement les PlayStation et la Wii.

Garde-barrières

Le développeur a toutefois un problème : il promeut activement l’usage de Rust dans le noyau Linux et le processus de révision de ce dernier est bien trop lent selon lui. Le mois dernier, il a souhaité pousser un patch qui aurait permis aux pilotes de périphériques écrits en Rust de faire appel à la fonction DMA (Direct Memory Access) du noyau. Refus catégorique de Christoph Hellwig, mainteneur principal du noyau.

Ces tensions entre promoteurs du Rust et mainteneurs habitués au C n’est pas nouvelle. Elles avaient notamment provoqué des départs dans l’équipe de Rust for Linux. Il y a quelques jours, The Register signalait la tension montante entre Hector Martin et Christoph Hellwig, le premier poussant l’équipe de Rust for Linux à ignorer les remarques du second et d’envoyer quand même leurs propositions de modifications. Tout du moins tant que Linus Torvalds n’intervenait en personne.

« Le problème vient peut-être de vous »

Et Linus Torvalds est intervenu. Répondant directement à Hector Martin qui expliquait combien ces tensions le fatiguaient, le père du noyau Linux s’est montré franc dès la première ligne : « Et si vous acceptiez le fait que le problème vient peut-être de vous ? ». Il continue : « Vous pensez que vous savez mieux [que les autres]. Mais le processus actuel fonctionne. Il a des problèmes, mais les problèmes font partie de la vie.  La perfection n’existe pas ».

Dans la suite du message, il accuse Hector Martin de « brigadage » sur les réseaux sociaux et Reddit, le développeur ayant essayé d’alerter de la situation. « Parce que si nous avons des problèmes dans le modèle de développement du noyau, alors les médias sociaux ne sont certainement pas la solution. De la même manière qu'ils n'étaient pas la solution à la politique », a ajouté Linus Torvalds.

Torvalds n'est pas contre le Rust

Au sein du noyau Linux, la priorité reste le code en C. Le mélange de deux langages est considéré comme risqué. Christoph Hellwig l’a même comparé à un « cancer », ce qui faisait dire à Hector Martin que le propos violait probablement les règles de bonne conduite. L’expression rappelle également les propos que Steve Ballmer, ancien CEO de Microsoft, avait tenu au sujet de Linux lui-même.

Linus Torvalds, de son côté, n’a rien contre le Rust en tant que tel. Sa position est connue depuis septembre dernier, lors de la version européenne de l'Open Source Summit. « Certaines discussions deviennent désagréables. Je ne sais pas vraiment pourquoi Rust est un domaine si controversé. Cela me rappelle ma jeunesse. Les gens se disputaient entre vi et EMACS. Pour une raison ou pour une autre, toute la discussion sur Rust contre C a pris des accents presque religieux dans certains domaines », avait-il alors indiqué.

Il s’était montré philosophe : « Rust est très différent, et beaucoup de gens sont habitués au modèle C. Ils n'aiment pas les différences, mais ce n'est pas grave ». Il avait toutefois plaidé pour qu’on laisse sa chance au langage : « Cela ne fait que deux ans que nous travaillons avec Rust, il est donc bien trop tôt pour dire que Rust est un échec ».

Commentaires (41)

votre avatar
Je comprend que Hector Martin voudrait que ca aille plus vite.

Mais je comprend aussi que les mainteneurs ne veuillent pas un mélange de C et de Rust dans leur code.
Ca serait davantage de boulot seulement pour faire plaisir à la nouvelle garde.
Donc je mise sur une énoooorme inertie des mainteneurs du noyau.

Si les dev Rust sont pressés, je leur conseillerais plutôt de participer à un Redox, ou un projet de réécriture de Linux en Rust... ou, plus simplement, de maintenir leur API/Abstraction Rust pour Linux en dehors du kernel (dans un SDK/DDK).
votre avatar
Si Rust est accepté, il n'y a pas de raison de ne pas l'utiliser.

Linux sur Apple Silicon (le projet ou travail Hector Martin) est très bien avancé, avec encore du développement à faire, c'est utilisable quotidiennement.
Linux supporte très bien Aarch64, les pilotes broadcom déjà présents, le pagesize de 16k, mesa3d avec OpenGL, Vulkan, OpenCL, l'émulation x86 via FEX-EMu, etc...
votre avatar
En fait le patch à l'origine du drama ne mélangeait pas C et Rust. C'était une abstraction en Rust qui se branchait au code C existant sans rien y modifier. Et les personnes en charge de Rust for Linux ont bien précisées qu'elles se chargeaient elles même de maintenir ce code si un changement dans le code du DMA en C cassait son fonctionnement.
Sur ce point je donne raison à Hector Martin : Christoph Hellwig n'avais pas de bonne raison de s'opposer. Dans la mesure ou il a été acté que l'on voulait pouvoir faire des drivers en Rust, c'est la meilleure méthode avec le moins d'impact possible sur les développement en C. Si on suit ses préconisations en s'opposant a tout code Rust même bien séparé du code C existant, c'est juste rendre impossible le projet Rust for Linux.

Ceci dit je rejoint Linus Torvald sur la critique de la manière dont Hector Martin c'est exprimée sur les réseaux sociaux, pour pousser Linus à prendre parti, plutôt que de le joindre directement, ce qui a jeté inutilement de l'huile sur le feu.
votre avatar
" Il avait toutefois plaidé pour qu’on laisse sa chance au langage : « Cela ne fait que deux ans que nous travaillons avec Rust, il est donc bien trop tôt pour dire que Rust est un échec »."
Difficile de laisser sa chance à un nouveau langage quand chaque PR est systématiquement rejetée parce qu'elle utilise le dit langage...
votre avatar
Parce que les PR demandent des changements dans des sous-systèmes existants... donc du code C en maintenance (par des gatekeepers :).
L'idéal pour Rust serait la création d'un tout nouveau sous-système écrit from-scratch en Rust.
Mais c'est pas tous les jours que Linux a besoin d'un nouveau sous-système :)

Et puis faut bien avouer que Rust... Comment dire...
C'est légèrement chiant comme syntaxe et frustrant en terme de limitations quand tu viens du C.

Perso j'ai découvert Zig et je ne veux pas retourner à Rust.
Ca me fait le même effet que TypeScript vs Javascript.
votre avatar
+1 le plus gros soucis de Rust est sa syntaxe complexe et totalement peté !
Et dès qu'on essaye du fonctionnel ça devient très vite illisible et la POO avec Rust est encore plus immonde qu'en Fortran.
votre avatar
Dans mon expérience limitée de Rust (datant de quelques années), le gros gros mur est le borrow checker, le vérificateur qui empêche qu’une variable (et celles qu’elle référence) ne puisse être utilisée de manière non-sûre par plusieurs threads ou plusieurs contextes (pour éviter les accès concurrents et les libérations multiples, entre autres): ça rend certains algos et structures de données difficiles à implémenter quand on reste dans les paradigmes des autres langages.
Ça rajoute aussi de la complexité dans la syntaxe quand on doit spécifier la portée des paramètres, mais ça m’a moins gêné que le point précédent.
votre avatar
Il me semble que la crate rayon vise à adresser ce problème.

Ce qui m'a le plus gêné en Rust, c'est la complexité inutile de sa syntaxe et, dans une moindre mesure, la difficulté à faire produire un code performant par le compilateur. Je trouve que pour un langage qui se dit concurrencer le C on est en deçà de ce point essentiel.
votre avatar
Parce que les PR demandent des changements dans des sous-systèmes existants... donc du code C en maintenance (par des gatekeepers :).
En l’occurrence non.
Le patch en question était juste une abstraction de l'API C pour le DMA pour permettre aux drivers Rust d'y accéder avec une interface adaptée au langage. Ca n'avait aucun impact sur le code existant.
L'idéal pour Rust serait la création d'un tout nouveau sous-système écrit from-scratch en Rust. Mais c'est pas tous les jours que Linux a besoin d'un nouveau sous-système :)
En l’occurrence ça arrive souvent pour les drivers et ça tombe bien c'est le premier objectif du projet Rust for Linux : pouvoir faire des drivers en Rust. C'est pour cela qu'il mettent en place une API en Rust pour accéder au sous-systèmes existants
Et puis faut bien avouer que Rust... Comment dire... C'est légèrement chiant comme syntaxe et frustrant en terme de limitations quand tu viens du C.
Pour ce qui est de la syntaxe Rust, je suppose que tu ne t'y est pas trop attardé trop longtemps. Ça m'a fait ça aussi au début, mais quand on a pris l'habitude, c'est la syntaxe du C qui parait bizarre.
Quant au limitation, il n'y en a pas vraiment. Certaines choses potentiellement dangereuses sont justes plus complexes a réaliser, mais c'est volontaire car il vaut mieux être sur de ne pas les faire par erreur.
votre avatar
Il est philosophe... car combien de langages prétendant remplacer le C a-t-il vu passer?
Pour ce qui est en prise directe avec le matériel je ne crois pas a Rust. Assez de pb avec une complexité croissante de ce côté pour cumuler avec un langage egalement plus complexe et moins proche de la suite d'opcodes que le processeur va dérouler. Sans même parler de l'aspect perf ou chaque % compte pour se démarquer.
Pas oublier que parmi les gros contributeurs côté support materiel il y a les fondeurs quibse tirent la bourre. Tant que Rust laissera ne serait-ce qu'un % au C il sera out.
votre avatar
Hmm... Pas convaincu.

Le code C tellement proche du hardware que c'est limite du code machine, c'est une infime portion du noyau.

La plupart du code c'est celui des sous-systèmes, et eux ils manipulent surtout des états dans des zones mémoire. Donc un langage "memory-safe by design" aurait tout son intérêt.

Actuellement c'est du "memory safe by good coding practices".
Ca nécessite de l'expérience/rigueur, et des phases d'intégrations + non-régressions.
votre avatar
Un langage memory-safe by design oui. Mais Rust est très restrictif en ce qui concerne la gestion mémoire en parallèle. Après ça reste quand même un défi.
votre avatar
Ce n'est pas du code machine... hormis quelques primitives asm et les prologues/épilogues d'exceptions qu'aucun langage n'évitera. C'est juste la bonne distance pour avoir du code portable... ou pas. Avec une maîtrise des allocations totale absolument indispensable dans certaines phases certes très déterministes mais qui doivent rester frugales (ex: avoir une pile temporaire avant la complexe init DDR qu'aucun intégriste ne voudrait vouloir coder en asm car un language objet ne permettra jamais la finesse nécessaire).
Tout le noyau Linux est juste écrit en C! C'est de l'open source, va y voir... Quel autre langage permet de coder un OS complet de A à Z? Et même l'applicatif si on le souhaitait (c'est alors moins optimal).
Si c'est Mozilla qui a initié Rust, car ils font de l'applicatif qui évolue beaucoup et en frontal réseau avec une interface chaise-clavier aux commandes: C'est pas forcément un hasard et là, OK, cela a du sens.
votre avatar
"un language objet ne permettra jamais la finesse nécessaire"
C'est assez catégorique. Il est possible de trouver un langage qui fait ça, je suppose (en fait...).
votre avatar
"*Actuellement c'est du "memory safe by good coding practices".
Ca nécessite de l'expérience/rigueur, et des phases d'intégrations + non-régressions.*"

Ça s'appelle "développer". Aucun langage ne fera le ménage dans la tête des développeurs !

Si certains pouvaient apprendre le pattern Singleton et utiliser un peu plus les références plutôt que des copies ; le monde se porterait bien mieux.
votre avatar
Si certains pouvaient apprendre le pattern Singleton et utiliser un peu plus les références plutôt que des copies ; le monde se porterait bien mieux.
Si on se concentre uniquement sur le développement safe, c'est compliqué de sortir ça comme un good practice. Faut plutôt pousser les gens à savoir utiliser correctement les références, et ça pousse plutôt à les sortir moins facilement et se baser sur des copies si possible justement. Tu pourras à juste titre dire que ça a du sens du point de vue performance, mais on sort du cadre de la bonne pratique du point de vue "safety".
votre avatar
Il faut sortir du mythe du C qui permet de prédire ce qui sera compilé. Les compilateurs modernes font énormément d'optimisation qui font que plus grand monde a part des experts n'est capable de prédire les opcodes générés pour tout code non trivial. La seule chose qui est vraiment prévisible c'est l'arrangement mémoire, et c'est également le cas en Rust si on le souhaite.

Rust a des performances comparables au C, parfois meilleur, parfois en dessous, globalement au même niveau. Les règles d'ownership permettent notamment certaines optimisations difficiles en C.
votre avatar
Quelles sont les optimisations difficiles en C que permettent les règles d'ownership ?
votre avatar
Par exemple Rust interdit qu'il y ait en même temps, sur une même variable, deux références mutables (en termes C, deux pointeurs non constants) . Le compilateur peut s'en servir pour optimiser, alors qu'en C il faut déclarer manuellement les pointeurs 'restrict' pour promettre au compilateur que les pointeurs sont uniques, ce que presque personne ne prend la peine de faire en pratique.

D'ailleurs quand Rust a activé cette optimisation, ça a permis de détecter des bugs dans la gestion du noalias de LLVM, et par conséquence dans l’implémentation de "restrict" de clang. Ces bugs étaient là depuis des années mais on ne s'en était pas rendu compte avant car "restrict" est très peu utilisée en C, alors qu'il est utilisée implicitement partout en Rust.
votre avatar
Je ne sais pas avec quoi tu compiles en C, mais GCC depuis un moment fait automatiquement cette hypothèse. ça fait un moment que je ne déclare plus mes pointeurs avec le mot clé restrict. D'ailleurs le code assembleur n'est absolument pas modifié.
La dernière fois que j'ai du mettre du restrict, c'était parce que le code servait de doc en même temps et que donc il fallait préciser ce point.

Donc en gros Rust interdit aliasing de pointeur.
votre avatar
Je serais curieux de voir des exemples réels. Si le mot clé restrict a été ajouté au langage, c'est justement parce que la norme du C interdit au compilateur de faire cette hypothèse, et qu'il fallait un moyen de le lui permettre.

Si GCC faisait vraiment ça, ça voudrait dire qu'il produirait des programmes carrément faux selon la norme.
votre avatar
J'ai fait un petit exemple rapide : https://godbolt.org/z/dn1Kn89e9
Rust est bien par défaut plus optimal. Il faut rajouter restrict au paramètre 'a' pour que le C génère le même code que Rust.
votre avatar
Je confirme ton exemple, cependant j'ai repris les codes où j'avais de l'aliasing et pourquoi je t'ai affirmé plus haut que GCC avait changé.

C'est ma faute, en substance je compile toujours avec l'option -frename-registers qui n'empêche pas l'aliasing mais qui fait que GCC "découple". Si tu reprends ton exemple du haut en C et que tu rajoutes cette option, tu verras que les deux variables sont chargés dans des registres différents puis additionner. ça n'a pas choqué au début car j'ai toujours retenu que l'aliasing fait mov, add , mov. ça reste vrai qu'il y a aliasing et que le processeur fait deux load au lieu d'un, mais en pratique les deux codes s’exécuteront de la manière sur le processeur.

Dans le cas de Rust, les deux additions ne pourront s'effectuer qu'une fois que l'instruction mov sera retiré. Dans le cas du C, les deux instructions moves seront executés ensemble, puis au cycle suivant les deux instructions add. Finalement, il faudra bien 2 cycles d'horloge au deux codes pour arriver au même résultat.

D'où le fait que je ne voyais pas la différence car finalement il faut le même nombre d'horloge pour arriver à ce résultat.
votre avatar
Pour voir du dev de driver linux en rust en direct, AsahiLina stream sur sa chaîne youtube. Il y a aussi de la rétro-ingénierie du GPU d'Apple.
Il y a aussi les redifs de 7h...
votre avatar
Le mois dernier, il a souhaité pousser un patch qui aurait permis aux pilotes de périphériques écrits en Rust de faire appel à la fonction DMA (Direct Memory Access) du noyau. Refus catégorique de Christoph Hellwig, mainteneur principal du noyau.
Le refus de Christoph Hellwig n'est pas un simple non. C'est un refus argumenté, que je trouve tout à fait pertinent pour ma part. Pour résumer grossièrement :
- Le coeur du noyau ne doit utiliser qu'un et un seul langage
- il n'est pas contre Rust, il est contre l'inclusion de tout autre langage que le C dans le coeur du noyau (maintenir le code du noyau est déjà très difficile avec un seul langage, s'il fallait en plus en connaitre plusieurs pour y arriver, cela serait extrêmement dur)
- son objectif premier est la maintenabilité, pas la diffusion du code rust (et pourtant il dit du bien de rust dans un ce ses commentaires). Il n'a aucun problème à ce qu'un driver soit fait en rust, tant que cela reste cloisonné au driver. Par contre, le coeur du noyau, écrit en C depuis plus de 20 ans, non.

Quelques extraits de ces interventions :
Keep the wrappers in your code instead of making life painful for
others.
Yes, interfaces to the DMA API should stay in readable C code and not in weird bindings so that it reminds greppable and maintainable.
If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).
Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this. This is NOT because I hate Rust. While not my favourite language it's definitively one of the best new ones and I encourage people to use it for new projects where it fits. I do not want it anywhere near a huge C code base that I need to maintain.
Et au delà des problèmes de lecture du code et de maintenabilité, il y a aussi des outils qui scanne le code du noyau voire qui apporte des modifications automatiquement (changement d'API interne par exemple). Ces outils sont fait pour du C, pas pour du Rust.
votre avatar
Le refus de Christoph Hellwig est très très mal argumenté, étant donné qu'il a déjà été décidé que l'on allait accepter des drivers en Rust dans le noyau.
Yes, interfaces to the DMA API should stay in readable C code and not in weird bindings so that it reminds greppable and maintainable.
Les interface pour les drivers écrits en C restent en C, mais c'est normal que les drivers écrits en Rust aient une interface écrite en Rust tant qu'elle est maintenue à part et n'a pas d'impact sur le code C sous-jacent.
S'il grep le code qu'il maintient, il n'est pas impacté.
If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).
L'interface étant maintenue à part par le groupe Rust for Linux, et pas directement dans le sous-domaine DMA. Dupliquer cette interface dans chaque driver poserait beaucoup de problème et ne résout rien.
votre avatar
Les interface pour les drivers écrits en C restent en C, mais c'est normal que les drivers écrits en Rust aient une interface écrite en Rust tant qu'elle est maintenue à part et n'a pas d'impact sur le code C sous-jacent.
C'était tout le sujet de la discussion:
1. est-ce qu'un mainteneur peut émettre un PR "C only" qui casse la compilation Rust ?
=> Ca sera aux équipes Rust de corriger le code APRES que le PR soit mergé.

2. est-ce qu'un mainteneur doit émettre un PR "C + Rust" qui ne casse pas la compilation Rust.
=> C'est au mainteneur de modifier/corriger le code Rust AVANT que le PR soit mergé.

Christoph Hellwig pointe que Linus a refusé un PR émis par un mainteneur parce que le PR cassait la compilation Rust. Mais c'était un cas particulier d'un PR sur la toolchain... donc c'était pas clair pour le cas général.
votre avatar
Le refus de Christoph Hellwig est très très mal argumenté, étant donné qu'il a déjà été décidé que l'on allait accepter des drivers en Rust dans le noyau.
Il a été décidé d'autorisé les drivers en Rust, pas le coeur du noyau (les bus de communications, le DMA, etc.). Nuance.
L'interface étant maintenue à part par le groupe Rust for Linux, et pas directement dans le sous-domaine DMA. Dupliquer cette interface dans chaque driver poserait beaucoup de problème et ne résout rien.
C'est là où tu te trompes. Une des forces (et des faiblesses !) du noyau linux, est que son API interne peut changer à tout moment. Quand c'est le cas, l'équipe qui a fait la modification reporte la modification sur les drivers impactés lorsque c'est possible. C'est actuellement faisable car quasiment tout le code de Linux est en C.

Demain, si l'équipe en charge du DMA décide de changer son API, non seulement il faut mettre à jour tous les drivers écrit en C, mais il faut aussi :
- mettre à jour le wrapper Rust
- mettre à jour les drivers écrit en Rust.

Il faut donc des compétences en Rust. Compétences que tout le monde n'a pas.

Sans compter qu'en cas de problème avec un driver DMA avec un driver rust, il faudra trouver si le problème vient du code DMA en C ou du Wrapper en Rust.

On peut ne pas être d'accord. Cloisonner l'usage de Rust aux "drivers" terminaux me semble une sage décision, d'autant plus dans un projet legacy où le cross language apporte de la complexité supplémentaire et où certains paradigmes de programmation sont très différents.

Comme le dit Linus, le système actuel n'est pas parfait mais à fait ses preuves. Autoriser le R4L a gérer ça et intégrer du code Rust pour le coeur du noyau, c'est ouvrir une boite de Pandore en l'état actuel des choses.

Le cloisonnement par driver a aussi un avantage relativement simple : en cas de besoin (absence de mainteneur compétent en Rust par exemple), on peut plus ou moins facilement réécrire le driver en question en C, sans trop d'impacts sur le reste du système.

Si aujourd'hui on autorise un wrapper Rust dans le coeur de Linux, demain ce sera du code Rust dans le coeur de Linux.

Une fois encore, on peut ne pas être d'accord avec la stratégie. Maintenant, il ne faut pas oublier que Linux est un logiciel libre, sous GPL-v2. Libre à l'équipe R4L de faire un fork pour intégrer directement ses wrappers s'il le souhaite. L'équipe de maintenance du noyau ne pourra rien dire. Grsecurity le faisait (fait ?) depuis fort longtemps par exemple.

Linux a des règles, qui peuvent paraitre rigides, mais c'est sans doute aussi grâce à ces règles que le noyau a pu se développer ainsi et perdurer pendant presque 30 ans.
votre avatar
Il a été décidé d'autorisé les drivers en Rust, pas le coeur du noyau (les bus de communications, le DMA, etc.). Nuance.
Encore une fois le patch ne touche pas au cœur, c'est juste une interface pour les drivers Rust, qui utilise l'API C existante.
Demain, si l'équipe en charge du DMA décide de changer son API, non seulement il faut mettre à jour tous les drivers écrit en C, mais il faut aussi : mettre à jour le wrapper Rust, mettre à jour les drivers écrit en Rust.
A partir du moment où on a décidé qu'on permettait les drivers en Rust, le problème de la maintenance est inévitable. Refuser une API Rust commune pour le DMA ne résout rien : le code d’adaptation à l'API C va juste se retrouver dupliqué dans chaque driver et résoudre les impacts d'une évolution de l'API C sera encore plus complexe.

Pour limiter le poids sur les mainteneurs actuels qui ne connaissent que le C que le projet Rust for Linux c'est engagé a mettre a jour l'API et les drivers Rust en cas de changement dans l'API C.
Cloisonner l'usage de Rust aux "drivers" terminaux me semble une sage décision, d'autant plus dans un projet legacy où le cross language apporte de la complexité supplémentaire et où certains paradigmes de programmation sont très différents.
Et c'est bien le cas. Encore une fois le projet Rust for Linux crée juste des wrapper Rust pour permettre au drivers Rust de s'interfacer plus naturellement avec le code C du coeur du noyau. Il ne le modifie pas directement.
Si aujourd'hui on autorise un wrapper Rust dans le coeur de Linux, demain ce sera du code Rust dans le coeur de Linux.
Le wrapper permet au contraire d'établir une frontière claire entre le Rust du driver d'un coté, et le C du coeur de l'autre coté.
votre avatar
Encore une fois le patch ne touche pas au cœur, c'est juste une interface pour les drivers Rust, qui utilise l'API C existante.
Si. Le patch créé une couche supplémentaire entre les drivers et le coeur en C. Ce n'est plus un driver.
A partir du moment où on a décidé qu'on permettait les drivers en Rust, le problème de la maintenance est inévitable. Refuser une API Rust commune pour le DMA ne résout rien : le code d’adaptation à l'API C va juste se retrouver dupliqué dans chaque driver et résoudre les impacts d'une évolution de l'API C sera encore plus complexe.
Un changement d'API au niveau C peut provoquer des problèmes de compilation pour certains drivers Rust. Avec cette modification, un changement d'API au niveau C peut provoquer des problèmes de compilations pour TOUS les drivers Rust.
Et c'est bien le cas. Encore une fois le projet Rust for Linux crée juste des wrapper Rust pour permettre au drivers Rust de s'interfacer plus naturellement avec le code C du coeur du noyau. Il ne le modifie pas directement.
Comme je le disais, la création de cette interface, c'est ajouter un coeur Rust au coeur C.
Le wrapper permet au contraire d'établir une frontière claire entre le Rust du driver d'un coté, et le C du coeur de l'autre coté.
En créant une interface Rust qui devient, de facto, une partie du coeur.

Je comprends parfaitement les motivations des développeurs Rust. Je comprends aussi parfaitement les motivations des développeurs & mainteneurs du noyau qui préfère le C.

Actuellement, il y a des règles qui ont été établies. Le Rust est autorisé pour les drivers. Point barre. Il n'a pas été autorisé pour autre chose. C'est une des raisons pour lesquels le patch a été refusé. Le code est dans un drvier ? non => patch refusé.

On peut espérer que le patch et son refus ouvre des discussions et surtout une prise de décision consensuelle sur ce qui est, ou n'est pas, autorisé au sein du noyau Linux.

Et encore une fois, si l'équipe R4L n'est pas contente de la direction prise, libre a elle de forker le noyau pour intégrer les modifications comme elles le souhaitent. Ainsi, aucune maintenance supplémentaire pour l'équipe "historique" du noyau.

A partir du moment où l'équipe R4L souhaite rester dans le giron du projet Linux, c'est à elle de se conformer aux règles qui ont été établies.
votre avatar
Si. Le patch créé une couche supplémentaire entre les drivers et le coeur en C. Ce n'est plus un driver.
La couche d'abstraction est là depuis le début du projet Rust for Linux et c'est sa mission majeure. C'est le mode de fonctionnement qui a été validé et qui est en place depuis 3 ans. La couche d'abstraction était là avant les premiers drivers Rust. Ce patch l'étend juste pour prendre en charge le DMA.

Les drivers et le noyau font partie du code Linux (entre autre). Il n'y aurait pas de sens à mettre ailleurs la couche qui s'intercale entre les deux.
Un changement d'API au niveau C peut provoquer des problèmes de compilation pour certains drivers Rust. Avec cette modification, un changement d'API au niveau C peut provoquer des problèmes de compilations pour TOUS les drivers Rust.
Qu'ils soient écrits en Rust ou en C, les drivers n'ont pas de raison d'être impactés la modification d'une API qu'ils n'utilisent pas. Le wrapper n'y change rien.
En créant une interface Rust qui devient, de facto, une partie du coeur.
J'ai du mal a comprendre pourquoi les bindings Rust devraient être considérés comme faisant partie du cœur de Linux :
- D'un point de vue technique, ils ne permettent pas d'interagir plus que les drivers C avec les différents composants du noyau. Ils passent par les mêmes API.
- D'un point de vue organisationnel, ils sont dans le répertoire "rust" à la racine du projet, les drivers sont dans le répertoire "driver" et le cœur du noyau est dans le répertoire "kernel". Il n'y a actuellement aucun code Rust en dehors des bindings et des drivers Rust.
Actuellement, il y a des règles qui ont été établies. Le Rust est autorisé pour les drivers. Point barre. Il n'a pas été autorisé pour autre chose. C'est une des raisons pour lesquels le patch a été refusé. Le code est dans un drvier ? non => patch refusé.
Sauf que cette règle n'a jamais existé, c'est juste l'idée trouvé par Christoph Hellwig pour refuser le patch sans admettre que c'était un soucis pour faire des drivers en Rust. La couche d’abstraction à toujours été le maillon essentiel de l'intégration du code Rust dans Linux. La refuser c'est justement aller contre le fonctionnement défini.
On peut espérer que le patch et son refus ouvre des discussions et surtout une prise de décision consensuelle sur ce qui est, ou n'est pas, autorisé au sein du noyau Linux.
Ce point là a été décidé avant même le début du projet, ça n'est pas un problème.

Le vrai soucis, c'est que le ton c'est envenimé des deux coté :
- Christoph Hellwig a levé des objection sans prendre en compte les choix fait lors de l'introduction de Rust dans le noyau et de manière de plus en plus véhémente alors que les gens du projet Rust for Linux lui expliquaient les effort qu'il faisaient pour garantir un impact minimal.
- Hector Martin de son coté à essayé de pousser sur les réseaux sociaux pour prendre à partie la communauté et Linux Torvalds ce qui a agavé la situation.
votre avatar
J'ai du mal a comprendre pourquoi les bindings Rust devraient être considérés comme faisant partie du cœur de Linux
Je pense que beaucoup d'incompréhension viens justement de là (que ce soit entre nous ou au niveau du projet Linux lui-même) : quelle définition donne t-on au coeur du noyau ? Si c'est tout ce qui n'est pas un driver, alors oui, un wrapper fait parti du coeur. Si c'est tout ce qui est utilisable par un driver, un wrapper fait aussi parti du coeur. Si c'est le code C, non le wrapper ne fait pas parti du coeur.
Sauf que cette règle n'a jamais existé, c'est juste l'idée trouvé par Christoph Hellwig pour refuser le patch sans admettre que c'était un soucis pour faire des drivers en Rust
Pourtant, c'est dans les règles : chaque sous-système fait comme il le souhaite. Some subsystems may decide they do not want to have Rust code for the time being, typically for bandwidth reasons. This is fine and expected.
Le vrai soucis, c'est que le ton c'est envenimé des deux coté :
- Christoph Hellwig a levé des objection sans prendre en compte les choix fait lors de l'introduction de Rust dans le noyau et de manière de plus en plus véhémente alors que les gens du projet Rust for Linux lui expliquaient les effort qu'il faisaient pour garantir un impact minimal.
- Hector Martin de son coté à essayé de pousser sur les réseaux sociaux pour prendre à partie la communauté et Linux Torvalds ce qui a agavé la situation.
Comme je le disais plus haut, chaque sous-système fait comme il le souhaite vis-à-vis de Rust (et c'est R4L qui le rappel !). Je comprends la frustration des développeurs Rust, mais ils veulent un peu le beurre (Rust) et l'argent du beurre (au sein du noyau linux).

Encore une fois, le noyau Linux existe depuis 3 décennies maintenant. 3 décennies de code C. Même des portions écrites en assembleur (généralement, pour des raisons d'optimisations) sont réécrites en C pour plus de maintenabilité et de portabilité.

Intégrer un nouveau langage dans un projet de 30 ans d'âge, c'est tout sauf anodin, et cela ne doit pas se faire n'importe comment. Le comportement d'Hectore Martin a jouer les pleureuses sur les réseaux sociaux est très loin de faire avancer le débat, et ne pourra, au contraire, que le cristaliser.

Christoph Hellwig refuse peut être le patch un peu brutalement, mais il le dit lui-même : pas de code rust pour ce sous-système (et c'est une règle tout à fait applicable comme le rappel R4L).

Une fois encore, si la politique d'intégration de Rust au sein du noyau pose problème, libre à l'équipe de R4L de forker le noyau et/ou de le fournir sous forme de patch (c'est faisable, grsecurity le faisait très bien par le passé). Ils auront moins de soucis de gouvernance, pourront faire les choix qu'ils veulent, mais auront plus de boulot de maintenance.
votre avatar
quelle définition donne t-on au coeur du noyau ? Si c'est tout ce qui n'est pas un driver, alors oui, un wrapper fait parti du coeur.
Cette définition par dichotomie est difficilement applicable. En regardant le code source de Linux on voit bien qu'il y a plein de choses qui ne sont manifestement ni le cœur ni les drivers.
Si c'est tout ce qui est utilisable par un driver.
Là on est dans la définition ad-hoc sur un point trop spécifique. Ça n'a pas vraiment de sens où on va devoir classer la lib C dans le noyau, vu quelle est utilisée par les drivers en tant que bibliothèque au même titre que les wrapper.
Si c'est le code C, non le wrapper ne fait pas parti du coeur.
La encore c'est trop spécifique pour avoir un sens.
Rien n’empêcherai techniquement d'utiliser du Rust dans des sous-systèmes qui font manifestement partie du cœur d'un OS comme le scheduler par exemple. Ça ne deviendrait pas des drivers pour autant.
Et pire encore : les drivers en C deviendraient le noyau :mad2:
Pourtant, c'est dans les règles : chaque sous-système fait comme il le souhaite.
En effet et les wrapper Rust ne font pas partie du sous-système DMA (dans /kernel/dma). Ils sont dans leur propre domaine(/rust). Les retirer n'aurait aucun impact sur le code DMA, juste sur les drivers Rust qui l'utilisent

Il faut vraiment comprendre que ce wrapper n'est qu'une bibliothèque utilisée par les drivers Rust. ils pourraient tout a fait être dans le code des drivers, mais ça serait de la duplication inutile de code complexe.
votre avatar
Je pense que tu as compris où je voulais en venir avec la définition du coeur du noyau ;) Il est facile, à tout à chacun, d'utiliser le même terme pour parler de choses proches mais aux frontières différentes.

Qui plus est, attention avec la notion de wrapper. Un wrapper peut vite devenir plus qu'un wrapper. C'est plus que cela. Cela devient souvent a minima un adapteur.
En effet et les wrapper Rust ne font pas partie du sous-système DMA (dans /kernel/dma). Ils sont dans leur propre domaine(/rust)
Il faut comprendre que le sous-système ce n'est pas qu'une arborescence au sein de linux. Le /rust/kernel/dma fait, pour moi, parti du sous-système /kernel/dma. Ca n'a pas de sens de définir un sous-système sur la base d'un langage et non pas sur la base de la fonctionnalité/scope.
Il faut vraiment comprendre que ce wrapper n'est qu'une bibliothèque utilisée par les drivers Rust. ils pourraient tout a fait être dans le code des drivers, mais ça serait de la duplication inutile de code complexe.
Ah mais je comprends très bien, rassure toi (le dev, c'est mon métier, et les wrappers, j'en ai déjà fait plein !). Je sais aussi qu'un wrapper ne reste rarement qu'un wrapper, et peut vite devenir un adapteur. Et ici, dans le cadre d'un projet comme le noyau linux, c'est une des pires choses qui puissent arriver je pense, car tu peux avoir une interface en C qui soit ait évolué à la version n+1 tendu que la version en rust continu d'utiliser la version n, car le wrapper joue la glue nécessaire pour rendre compatible la version n avec la version n+1 (et devient donc un adapteur).

Maintenant, Linus a très bien résumé la situation je trouve. Et pour la dernière fois, l'intégration de Rust a été autorisée de manière très cadrée. Si cela ne plait pas à l'équipe de R4L, alors, comme je ne cesse de le répéter => fork, patch, etc.
votre avatar
Il faut comprendre que le sous-système ce n'est pas qu'une arborescence au sein de linux. Le /rust/kernel/dma fait, pour moi, parti du sous-système /kernel/dma. Ca n'a pas de sens de définir un sous-système sur la base d'un langage et non pas sur la base de la fonctionnalité/scope.
Sauf que comme je l'expliquais que ce soit du point de vu fonctionnel ou organisationnel le wrapper n'a pas a faire partie du scope DMA, et ça n'a jamais été cocidéré comme étant le cas pour tous les autres wrappers développés jusqu'a présent.

Si on considère que ce qui utilise l'API DMA fait partie du domine DMA, tous les drivers qui utilisent le DMA font partie du domaine DMA.
Maintenant, Linus a très bien résumé la situation je trouve. Et pour la dernière fois, l'intégration de Rust a été autorisée de manière très cadrée. Si cela ne plait pas à l'équipe de R4L, alors, comme je ne cesse de le répéter => fork, patch, etc.
Linus a surtout critiqué a raison la forme de la discussion. Il n'a, à ma connaissance, pas tranché le problème du point de vue technique.
votre avatar
Sauf que comme je l'expliquais que ce soit du point de vu fonctionnel ou organisationnel le wrapper n'a pas a faire partie du scope DMA, et ça n'a jamais été cocidéré comme étant le cas pour tous les autres wrappers développés jusqu'a présent.
Je ne partage pas ton avis. Le wrapper DMA fait partie du scope DMA. Sinon, c'est dire que l'interface (les API) du DMA ne sont pas dans le scope du DMA.

Mais qu'importe ton avis ou le mien (il n'y en a pas un de meilleur que l'autre, de toute façon). C'est à l'équipe noyau de trancher. Equipe au sens large (incluant R4L).
Si on considère que ce qui utilise l'API DMA fait partie du domine DMA, tous les drivers qui utilisent le DMA font partie du domaine DMA.
Non. Ca n'a pas de sens. Mais le wrapper n'est pas une partie qui utilise le DMA. C'est une partie qui fourni le DMA (bon, ok, techniquement, en fait, elle fait les deux !!)
Linus a surtout critiqué a raison la forme de la discussion. Il n'a, à ma connaissance, pas tranché le problème du point de vue technique.
Alors, quand je disais qu'il a bien résumé la situation, ce n'était pas du point de vue technique, effectivement. Il a juste dit 2 choses :
- que les développeurs Rust ont parfois du mal à se remettre en question
- que ces discussions doivent avoir lieu "en interne" et pas sur les réseaux sociaux.
votre avatar
Pour info Linus Torvalds a finalement répondu techniquement sur le sujet. Il a bien explicité sans ambiguïté possible que les bindings Rust n'ont rien a voir avec sous domaine dont Christoph Hellwig est responsable.
votre avatar
merci pour la mise à jour
sa réponse est très intéressante je trouve, et assez explicite

concernant Linus lui-même, j'aime beaucoup le "I say some stupid things at times, there needs to be people who just stand up to me and tell me I'm full of shit.", je trouve ça sain
votre avatar
En effet, ça n'a pas toujours été le cas. Il s'est beaucoup assagi ces dernières années.
votre avatar
Oui, je viens de voir ça. J'allais justement poster ce lien à ce sujet : https://linuxfr.org/users/linkdd/journaux/linus-repond-a-la-controverse-sur-r4l-rust-pour-linux
Mais tu m'as devancé. Mais le mien est en français :p
votre avatar
Après, des systèmes "infaillibles" "by design", ça va pas plaire à tout le monde. Les dépassements de tampon sont des failles intéressantes car on ne peut pas les trouver facilement, mais si on y met le prix, on les trouve sans que que ces failles ne se voient, à fortiori dans un code source ouvert. Cela réduit le nombre d'acteurs qui peuvent trouver et exploiter ces failles. Donc peut être que Torvald compose avec plusieurs influences. Je viens d'y penser car je trouve ses citations contradictoires. On ne sais pas trop ce qu'il pense de Rust au final. Laisser Rust en périphérie du noyau, c'est un peu quand même ne pas lui donner de rôle, donc contradictoire à mon sens. La question de savoir s'il y a assez compétences en Rust est importante, mais si les portes ne sont pas ouvertes à minima, les compétences ne se développeront pas non plus. La complexité supposée augmentée du noyau par l'ajout de Rust, c'est discutable à mon sens. Linux, c'est plusieurs millions de lignes de code. J'entends bien l'argument de dire que le "coeur" (à définir) du noyau ne dois pas être complexifié. Mais même en ne prenant que le "coeur", le noyau sera très complexe, et à mon sens, personne n'est vraiment capable de le comprendre dans son ensemble. A l'inverse, et en conséquence, on peut presque dire qu'un langage à mémoire sécurisée peut dans l'absolue faire tendre à un code plus facile à analyser du point de vue de la sécurité informatique.

Peut être qu'il y a plusieurs composantes sur le sujet, qui met en balances plusieurs points de vues éventuellement difficilement conciliables. Vous me diriez que peut être que je sur interprète. Je répondrais "peut être" ou "peut être pas". Donc voici les signaux faibles qui me font douter :
- on sais maintenant que dans ce pays, déstabiliser une personne par l'action du chef en dépassant la politesse tacite (et explicite) peut parfois être une manière de faire diversion pour cacher une politique qui ne sera pas débattue. Un "grand chef" de Linux qui humilie une personne en public peut être vu comme un problème caractériel, le choix sage du chef pour les cheffistes, ou comme un acte politique. C'est léger, mais c'est un signal faible quand même.
- demander à ce que la discussion se fasse en privé, c'est mieux pour la cohérence de l'équipe, mais moins bien pour la transparence
- Linus Torvald a déjà été approché pour qu'il mette une porte dérobée dans Linux. Là, c'est plutôt un signal fort.

Rust dans le noyau Linux : nouvelles bisbilles, Linus Torvalds s’en mêle

  • Garde-barrières

  • « Le problème vient peut-être de vous »

  • Torvalds n'est pas contre le Rust

Fermer