IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le mélange de Rust et de C dans Linux est assimilé à un « cancer » par un responsable du noyau,
« je ne veux pas qu'il s'approche d'une énorme base de code C que je dois maintenir », dit-il à propos de Rust

Le , par Mathis Lucas

47PARTAGES

18  0 
L'intégration du langage Rust dans le noyau Linux continue de créer des divergences d'opinions dans le rang des mainteneurs. Certains voient en Rust une opportunité d'améliorer la sécurité et la robustesse de Linux, notamment grâce à sa gestion de la mémoire et à sa prévention des erreurs courantes en C. D'autres expriment des réserves, soulignant la complexité du langage et les risques liés à son adoption dans un projet aussi vaste que Linux. Un responsable du noyau, Christoph Hellwig, s'est récemment opposé à l'intégration d'un correctif écrit en Rust dans le noyau, indiquant clairement qu'il n'est tout simplement pas intéressé par le code Rust.

Rust for Linux : une initiative qui provoque des divisions dans la communauté du noyau

Le projet Rust for Linux vise à intégrer le langage de programmation Rust au sein du noyau Linux, historiquement écrit en C et en assembleur. Lancé en 2020, ce projet a pour objectif principal de tirer parti des garanties de sécurité mémoire offertes par Rust afin de réduire les bogues et vulnérabilités dans le développement des pilotes du noyau. Toutefois, bien que le projet soit jugé prometteur, il semble que les choses ne se passent pas comme prévu.

Certains craignent que la multiplicité des langages rende plus difficile la maintenance de ce super-projet open source, d'autres ne sont pas d'accord. Et aujourd'hui, les développeurs qui tentent d'ajouter du code Rust au noyau Linux se heurtent à l'opposition des responsables du noyau. Certains responsables du noyau estiment notamment que l'utilisation de plusieurs langages est une « complication indésirable et risquée ». C'est le cas de Christoph Hellwig.

Des inquiétudes sont apparues en août 2024 lorsque l'ingénieur logiciel de Microsoft Wedson Almeida Filho s'est retiré du projet Rust for Linux, citant sa frustration face à des « absurdités non techniques », ce qui est une façon de décrire la difficulté de collaborer avec ceux qui ont des objectifs différents.


Le problème s'est à nouveau posé en janvier 2025, lorsqu'une proposition d'abstraction permettant aux pilotes de périphériques écrits en Rust d'appeler l'API DMA de Linux principalement basé sur le langage C s'est heurtée à l'opposition ferme de Christoph Hellwig, un responsable du noyau.

Plus précisément, un contributeur du noyau a soumis un correctif pour permettre aux pilotes Rust d'utiliser la fonction C dma_alloc_coherent() de l'API DMA afin d'allouer et de faire correspondre de grandes zones de mémoire pour un accès direct à la mémoire. Christoph Hellwig s'est opposé à ce correctif.

Dans un message adressé à la liste de diffusion du noyau Linux, Christoph Hellwig a écrit : « pas de code Rust dans kernel/dma, s'il vous plaît ». Par la suite, Miguel Ojeda, le développeur principal du projet Rust for Linux, a demandé à Christoph Hellwig de suggérer une alternative.

Christoph Hellwig : « ne me forcez pas à travailler avec votre langage brillant du jour »

En adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit les atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups, étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo. Mais les habitués du langage C désapprouvent l'initiative et n’entendent pas se laisser embarquer dans ce qu’ils appellent la nouvelle religion du Rust.

En réponse à Miguel Ojeda, Christoph Hellwig a déclaré : « gardez les wrappers dans votre code au lieu de rendre la vie difficile aux autres », et a poursuivi en affirmant que « les interfaces de l'API DMA devraient rester dans un code C lisible et non dans des bindings bizarres afin qu'il [reste] greppable et maintenable ».

Le souhait de Christoph Hellwig semble être que les pilotes qui ne sont pas écrits en C aient leurs propres liaisons privées avec le code C, et que ces abstractions ne soient pas maintenues séparément, pas même dans l'arbre rust/kernel. Interrogé par Danilo Krummrich, un ingénieur logiciel de Red Hat impliqué dans le projet Rust for Linux, Christoph Hellwig a clairement fait savoir qu'il n'est tout simplement pas intéressé par le code Rust :

Citation Envoyé par Christoph Hellwig

Ne me forcez pas à travailler avec votre langage brillant du jour. La maintenance de projets multilingues est une tâche pénible à laquelle je n'ai aucune envie de m'atteler. Si vous voulez utiliser quelque chose qui n'est pas du C, que ce soit de l'assembleur ou du Rust, vous écrivez dans des interfaces C et vous vous occupez vous-même du décalage d'impédance en ce qui me concerne.

En réponse, Danilo Krummrich a expliqué que Rust for Linux crée un code Rust qui abstrait les API C pour tous les pilotes Rust et qui est maintenu par les développeurs Rust. En d'autres termes, le côté C du noyau reste le même, et les pilotes Rust utilisent des abstractions de ce code C, et ces abstractions sont maintenues par une équipe centralisée dans rust/kernel, ce qui est sans doute mieux que des pilotes ayant leurs propres bindings C individuels.

Mais Christoph Hellwig ne semble pas intéressé par le fait que les abstractions DMA Rust soient maintenues séparément. Christoph Hellwig a expliqué qu'il ne voulait pas d'un autre mainteneur. Il a poursuivi en affirmant que le fait de demander à d'autres de maintenir la couche d'abstraction Rust pour l'allocateur cohérent DMA en tant que composant séparé n'améliore pas les choses et entrave la maintenabilité du noyau Linux :

Citation Envoyé par Christoph Hellwig

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. (Où ce cancer est explicitement une base de code interlangage et non Rust lui-même, juste pour échapper à la brigade flameware.)

Chaque bit supplémentaire introduit par un autre langage réduit considérablement la maintenabilité du noyau en tant que projet intégré. La seule raison pour laquelle Linux a réussi à survivre aussi longtemps est qu'il n'a pas de frontières internes, et l'ajout d'un autre langage rompt complètement avec cela.

Vous n'aimerez peut-être pas ma réponse, mais je ferai tout ce qui est en mon pouvoir pour arrêter cela. Ce n'est pas parce que je déteste Rust. Même si ce n'est pas mon langage préféré, c'est certainement l'un des meilleurs nouveaux langages et j'encourage les gens à l'utiliser pour de nouveaux projets là où il convient.

Je ne veux pas qu'il s'approche d'une énorme base de code C que je dois maintenir.

Les remarques de Christoph Hellwig contrastent avec les analyses du créateur de Linux, Linus Torvalds. Il est d'avis que Rust peut aider à corriger des erreurs commises en C. Il pense que Rust est une solution d’avenir pour le développement du noyau. Ainsi, Linus Torvalds considère la prise en charge de Rust pour le développement du noyau Linux comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr ».

Il a déclaré : « le C est, en fin de compte, un langage très simple. C'est l'une des raisons pour lesquelles j'apprécie le C et pour lesquelles beaucoup de programmeurs C apprécient le C, même si le revers de la médaille est évidemment que, parce qu'il est simple, il est aussi très facile de faire des erreurs ».

Les remarques de Christoph Hellwig sont jugées en violation du code de conduite

Hector Martin, chef de projet d'Asahi Linux, estime que « les remarques de Christoph Hellwig constituent une violation du code de conduite », mais doute que des mesures disciplinaires soient prises. Il estime que les développeurs de Rust for Linux devraient ignorer les préoccupations de Christoph Hellwig et soumettre leur correctif à l'approbation du patron du noyau, Linus Torvalds. Selon lui, l'avenir de Rust for Linux dépendra de la réponse de Linus Torvalds.

Citation Envoyé par Hector Martin

Si Linus n'apporte pas de réponse officielle à ce fil de discussion, Miguel et les autres développeurs Rust devraient simplement fusionner cette série une fois qu'elle sera revue et prête, en ignorant la tentative manifeste de Christoph de saboter le projet. Si Linus [accepte la pull request], ce que dit Christoph n'a pas d'importance. Si Linus ne l'accepte pas, le projet [Rust for Linux] est essentiellement mort jusqu'à ce que Linus ou Christoph fassent un geste. Tout le reste, c'est tourner autour du pot.

Le 7 février 2025, Hector Martin a demandé à être retiré de la liste des mainteneurs de Linux. « Je n'ai plus aucune confiance dans le processus de développement du noyau ou dans l'approche de la gestion de la communauté », a-t-il écrit dans une note adressée à la...
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.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Christophe
Responsable Systèmes https://www.developpez.com
Le 11/02/2025 à 19:48
N'y aurait-il pas Ada en 1983 qui était fort novateur à l'époque
Ada n'a pas percé. Peu de gens doivent le connaitre ici.

Mais il n'y a pas forcément de lien entre la popularité de quelque chose et sa valeur pertinente.

L'avenir dira ce qu'il en est pour Rust.
7  0 
Avatar de Christophe
Responsable Systèmes https://www.developpez.com
Le 08/02/2025 à 20:03
pourquoi ne pas envisager de développer un nouveau Linux entièrement avec Rust ?
Parce qu'il y a plus de 27,8 millions de lignes de code à refaire (chiffre de 2020).
Et on ne parle que du noyau.
6  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 20/02/2025 à 10:59
Citation Envoyé par d_d_v Voir le message
J'avais écrit sur un autre fil que seuls les incompétents ou très très débutants écrivaient du c++ avec une écriture non "sécurisée" (pas de conteneurs STL, pas de shared pointeurs), et on m'a répondu qu'on ne pouvait pas faire confiance dans le développeur.
Ce qui fait toute la différence entre Rust et C++ au niveau de la sécurisation, c'est qu'elle est opt-in en C++ alors qu'elle est opt-out en Rust.

Même si l'on considérait que la STL et les smart pointers sont memory safe (ce qui n'est pas le cas), il faudrait toujours s'assurer de bien les employer, tout le temps. En C++, quand on sort des clous par erreur, le plus souvent, rien ne nous l'indique. Il ne s'agit pas que d'un problème de débutant, même un développeur expérimenté finit par faire des erreurs, car il n'y a pas de démarcation précise entre ce qui est sûr et ce qui ne l'est pas.

En Rust, par défaut, tout est sécurisé d'un point de vue mémoire. il est peu probable d'écrire unsafe { x.get_unchecked(i) } en toute lettre, sans que l'auteur ne se rendre compte qu'il est en train de faire quelque chose de potentiellement dangereux, et que le relecteur n’identifie immédiatement le risque. Si on travaille avec des gens auquel on ne fait pas assez confiance (qui n'ont probablement pas besoin de code unsafe), il y a moyen de verrouiller son usage dans le projet, ou forcer à documenter chaque utilisation pour expliquer ce qui permet de vérifier que l'utilisation est correcte.
6  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 22/02/2025 à 6:18
Citation Envoyé par djm44 Voir le message
Il me semble qu'il est possible d'écrire un code exact en C ou dans un autre langage.
En théorie, avec des développeur parfait, oui. Mais dans la pratique, même les meilleurs développeurs font des erreurs. L'historique de Linux parle de lui-même : 1020 CVE pour des erreurs de corruption mémoire ont dû être corrigées l'année dernière. Utiliser un langage qui empêche par défaut certains types d'erreurs dont la corruption mémoire est un gros avantage.

Citation Envoyé par djm44 Voir le message
Beaucoup de publicités sont faites sur ce langage Rust auquel je n'adhère pas. Il y a déjà une profusion de langages qui nuit à la simplicité des approches . Chez Mozilla c'est Rust, chez Google c'est Go, chez Apple c'est Swift. Sur le web c'est Java, JavaScript, PHP.
Le terme publicité est très mal adapté. Rust a ses défenseurs qui apprécient ses qualités, mais il n'est pas la propriété d'une société qui aurait besoin qu'il soit largement adopté pour l'écosystème qu'elle distribue comme Apple avec Swift, ou Microsoft avec C#.
Mozilla à participé aux débuts du langage, mais il n'en a jamais particulièrement fait la promotion. Rust était déjà un projet indépendant de la fondation Mozilla lors de sa sortie officielle, il y a dix ans. Ca fait un moment que la contribution de Mozilla à Rust est anecdotique.

Citation Envoyé par djm44 Voir le message
Et finalement le mieux c'est encore le C ou mieux encore le C++ à mon avis vu le nombre de codes existants . Linus Torvalds devrait passer au C++ mais il a une aversion pour ce langage ce qui le pousse vers Rust.
Ce qui fait que le Rust a été choisi là ou d'autres ont été écarté, c'est parce qu'il apportait des garanties de sécurités(contrairement au C++), sans sacrifier les performances et le contrôle du bas niveau (contrairement à la plupart des langages sûrs).
7  1 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 07/02/2025 à 22:29
Citation Envoyé par DNABSY Voir le message
Avec tout ce ramdam autour de C et de Rust, pourquoi ne pas envisager de développer un nouveau Linux entièrement avec Rust ?
Linux c'est des milliers de contributions depuis plus de 30 ans et des drivers pour énormément de matériel différents. C'est pas envisageable de refaire tout en Rust sans perdre beaucoup au passage. Même Microsoft alors qu'il a passé des années à travailler sur Singularity, n'a au final pas pris le risque de remplacer son noyau NT.
Il y a bien des projets de noyaux en Rust, mais ils n'ont clairement pas l'ambition de refaire tout ce que fait Linux. Il faudrait des années et des moyens colossaux.

Citation Envoyé par DNABSY Voir le message
Tout le code Linux serait entièrement migré en Rust (il y a du boulot) et plus d'embrouille avec les mainteneurs en C car plus de contacts avec eux.
Et on aurait deux noyaux concurrents avec possiblement des problèmes de compatibilité entre eux. Le but du projet est de permettre d'intégrer Rust progressivement sans fragmenter Linux

Citation Envoyé par DNABSY Voir le message
Aujourd'hui, ce ramdam risque de ne pas attirer ceux qui font du Rust et qui souhaiteraient malgré tout participer au développement de Linux
=> Nouveau projet en partant du début => Nouvelle motivation => Nouveaux mainteneurs
Décourager les gens du projet Rust for Linux semble clairement l'objectif de certains mainteneurs Linux.
Malheureusement repartir de zero n'est pas une alternative si on on veut un OS grand public comparable à Linux : performant et qui supporte tout le matériel générique.

Citation Envoyé par Mingolito Voir le message
Linux est encore en vie uniquement grâce à une petite poignée de vieux grabataires pré retraités de plus de 50 ans qui codent en C avec un truc qui s'appelle un clavier.
La nouvelle génération Z qui sait pas coder et qui a obtenu son certificat de codage dans une pochette surprise en faisant ses devoirs grâce à ChatGP ne risque pas de pondre un truc utile comme Linux, même en Rust, même en Basic ils n'en seraient pas capables.[...]
Quel superbe ramassis de clichés.
Tous les gens capables de travailler sur le code de Linux ne sont heureusement pas de vieux grabataires, tout comme les codeurs en Rust ne sont pas des jeunot incapables de coder sans IA.
C'est evident que les jeunes qui viennent d'avoir leur diplôme ne sont pas aussi efficace que des développeurs confirmé, mais ça n'a rien de nouveau. Les formation des écoles ne sont par parfaitement en adéquation avec ce qui sera utile dans 100% des cas qui se présenteront au travail, là encore, rien de nouveau, ça à toujours été le cas.

Citation Envoyé par Mingolito Voir le message
Une fois que tous les anciens seront à la retraite, je pense que le monde va mourir
On disait déjà ça en Grèce 4 siècles avant JC, je vous rassure, le monde est toujours là.
5  0 
Avatar de Christophe
Responsable Systèmes https://www.developpez.com
Le 08/02/2025 à 21:04
oui mais donc en ne supportant plus ce matériel toujours supporté, et donc faire une régression.

Mais même divisé par 2 ou 3, A quoi bon recoder 9 millions de lignes ?
Rajouter du nouveau code en Rust, éventuellement, mais pas refaire la roue.
6  1 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 16/02/2025 à 1:07
Citation Envoyé par d_d_v Voir le message
pourquoi ne pas inventer des extensions aux langages existants pour expliciter l'utilisation obligatoire d'un code securisé
Dans le cas du C++, c'est techniquement possible, mais le comité C++ a refusé.
Le 11 septembre 2024, Sean Baxter avait proposé Safe C++.
Le 15 octobre 2024, pour contrer Sean Baxter, Herb Sutter a proposé d'ajouter des principes qui empêchent C++ d'avoir un sous-ensemble à la fois performant et sécurisé : P3466R0 "(Re)affirm design principles for future C++ evolution".
Le 24 octobre 2024, Sean Baxter a argumenté contre ces nouveaux principes ainsi que contre la proposition des "Safety Profiles" de Bjarne Stroustrup : Why Safety Profiles Failed.
En novembre 2024, le comité C++ a voté pour ces nouveaux principes à 29 voix pour, 22 neutres et 2 contre : Trip report: November 2024 ISO C++ standards meeting (Wrocław, Poland).
Le destin du C++ a été scellé.
5  0 
Avatar de Mingolito
Expert éminent https://www.developpez.com
Le 07/02/2025 à 16:19
Citation Envoyé par DNABSY Voir le message
Avec tout ce ramdam autour de C et de Rust, pourquoi ne pas envisager de développer un nouveau Linux entièrement avec Rust ?
Tu as oublié de voir la série en totalité, à partir du début depuis l'épisode 1 saison 1.

Linux est encore en vie uniquement grâce à une petite poignée de vieux grabataires pré retraités de plus de 50 ans qui codent en C avec un truc qui s'appelle un clavier.
La nouvelle génération Z qui sait pas coder et qui a obtenu son certificat de codage dans une pochette surprise en faisant ses devoirs grâce à ChatGP ne risque pas de pondre un truc utile comme Linux, même en Rust, même en Basic ils n'en seraient pas capables.
Les entreprises ne veulent plus recruter de juniors car elle savent très bien qu'ils ne valent absolument rien, et encore quand ils se pointent au travail. 37 % des employeurs préfèrent embaucher une IA plutôt qu'un jeune diplômé de la génération Z, les employeurs déplorent le manque de motivation et d'initiative des jeunes diplômés de la génération Z, et des rapports indiquent que les juniors en informatique n'ont pas les compétences techniques requises.

De toute façon la génération Z le codage ça les intéresse pas, ils se disent "super bon en codage et en informatique", des vrais "hackers" parce qu'ils jouent 10 heures par jours à Counter strike.
Voila l'avenir de l'humanité et ceux qui sont censés payer notre retraite : 57 % des membres de la génération Z veulent devenir des influenceurs

Une fois que tous les anciens seront à la retraite, je pense que le monde va mourir

6  2 
Avatar de fdecode
Membre habitué https://www.developpez.com
Le 07/02/2025 à 17:31
Citation Envoyé par DNABSY Voir le message
pourquoi ne pas envisager de développer un nouveau Linux entièrement avec Rust ?
Il existe différents projets d'OS.
https://www.redox-os.org/
https://docs.tockos.org/kernel/

Des projets universitaires aussi:
https://github.com/hermit-os
https://github.com/theseus-os/Theseus
4  0 
Avatar de Christophe
Responsable Systèmes https://www.developpez.com
Le 09/02/2025 à 9:12
Une régression à quel niveau exactement ?
Régression au sens perte de fonctionnalité, enfin ici plus précisément perte d'accès aux mises à jours (correctives et de fonctionnalités) pour les architectures supprimées. Pourquoi ces archis ne sont pas actuellement supprimées ? c'est qu'il y a un intérêt de les garder. Après je ne dis pas qu'il n'y a pas de ménage à faire. Mais ça ne change pas la problématique de tout recoder.

Si on parle de problème d'avoir une communauté de développeurs, on va parler ici d'une ressource limitée, soit on leur fait évoluer le code existant (avec ou sans Rust le prob. n'est pas là), soit on leur fait tout refaire en Rust. A ton avis qu'est ce qui est le plus pragmatique.

Je n'ai rien contre Rust, ni contre les changements, mais c'est pas pour rien que les institutions financières utilisent encore COBOL, un langage obsolète que quasiment personne ici ne doit connaitre ? Tout simplement car refaire tout ça représente des millions d'heures de travail et un risque car ces vieux produits fonctionnent très bien. Bien sûr ça m'étonnerais qu'ils commencent des nouveaux projets en COBOL. c'est un cas intéressant qui montre aussi un problème de stratégie à long terme.

Pour le cas de Linux, on va se retrouver à devoir maintenir du code en assembleur, C, et Rust, avec des ressources hommes limitées. C'est un type de développement qui requiert des développeurs expérimentés. Rust reste jeune, Rust 1.0 date de 2015.
4  0