Discussion :

[Patrick Ruiz]

Linus Torvalds annonce que Rust for Linux est susceptible d’être prêt pour la version 5.20 du noyau
Dans un contexte où le langage Rust apparaît comme candidat idéal à la mise au rebut du langage C

Les principaux mainteneurs du noyau Linux ont un âge qui commence par le chiffre 5. Certains se rapprochent même de la soixantaine. Du coup, la communauté du célèbre noyau open source commence à penser au changement de générations. Une nouvelle dont la tranche d’âge se situe dans la trentaine gravit les échelons, mais comme Linus lui-même le souligne : « Il s'avère qu'il est vraiment difficile de trouver des personnes qui sont des mainteneurs » ; un fait lié à ceci que le développement du kernel Linux continue de se faire en C et assembleur – des langages auxquels la vieille génération est plus accoutumée ? C’est une possibilité et elle est susceptible d’expliquer pourquoi 2022 pourrait être l’année du langage Rust au sein du noyau Linux. Linus Torvalds annonce en effet que Rust for Linux est susceptible d’être prêt pour la version 5.20 du noyau.

Linus Torvalds et Dirk Hohndel ont eu leur habituelle échange lors d’une session de l’édition 2022 de l’Open Source Summit. Linus Torvalds commentait alors sur les évolutions du projet Rust for Linux en soulignant qu’il est susceptible d’être prêt pour Linux 5.20. Les publications de Miguel Ojeda, chef du projet Rust for Linux, avait déjà permis de dresser une liste des progrès de l’initiative : support d’un compilateur Rust bêta, test du support des architectures ARM et RISC-V, nouvelles abstractions Rust, etc.

15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans (chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE)) sont liées à des tares que traînent le langage C : problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. Linus Torvalds s’est penché il y a peu sur un potentiel problème de sécurité avec les fonctions primitives d'exécution spéculative de la liste liée du noyau écrit en ANSI C. C’est en corrigeant ce problème qu’il s’est rendu compte qu’en C99 l'itérateur passé aux macros de parcours de liste doit être déclaré dans une portée en dehors de la boucle elle-même. C’est de ce constat que venait sa récente décision de faire passer le noyau Linux au C moderne (C11) dont la normalisation est achevée en 2011. C’est le genre de raisons techniques susceptibles de justifier la mise au rebut du langage C au profit du Rust pour le développement du noyau sur le long terme.

La nouvelle arrive dans un contexte où le regard de Linus Torvalds sur le langage Rust a changé. En effet, la prise en charge de Rust pour le développement du noyau Linux commence à prendre forme et est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

Et vous ?

La difficulté de trouver des mainteneurs est-elle la conséquence de ce que le développement du noyau Linux continue de se faire en C et en assembleur au moment où les développeurs s’intéressent de plus en plus à des langages comme Rust ?
Êtes-vous aussi d’avis que la communauté Linux anticipe non seulement sur les départs en retraite des actuels mainteneurs et sur les qualités que Rust offre en comparaison au langage C ?
Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ? Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents

[Astraya]

La difficulté de trouver des mainteneurs est-elle la conséquence de ce que le développement du noyau Linux continue de se faire en C et en assembleur au moment où les développeurs s’intéressent de plus en plus à des langages comme Rust ?

En plus de la complexité de celui-ci je le pense oui.

Êtes-vous aussi d’avis que la communauté Linux anticipe non seulement sur les départs en retraite des actuels mainteneurs et sur les qualités que Rust offre en comparaison au langage C ?

Oui, et c'est plutôt un signe qu'il garde la tête sur les épaules. Le C était incontournable en sont temps, les temps changes, les technos évolues, les logiciels doivent suivre cette évolution pour assurer une maintenance possible.

Pourquoi le langage C pourrait encore avoir de longues années devant lui ?

Enlever le C ne se fera pas du jour au lendemain. De plus, même une fois changé, il faudra tellement de test, de retour utilisateur pour valider à 100% que le changement est positif.

Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?

Oui, le C a fait son temps, il ne faut pas craché sur lui, il est sacrément puissant, mais tellement puissant qu'on peut se tirer dans le pied avec une nuke.

Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?

Oui et non, on peut avoir le même raisonnement sur plein de choses. De plus, même si l'on fait du C depuis 30 voir 40 ans... on fait encore des erreurs, et pire, elle sont détectées à l’exécution...

Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ? Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?

Pourquoi pas... ou alors fournir une interface Rust si ils veulent pas changer l'existant.

[defZero]

LE truc que je trouve ballot, c'est que le Rust est plutôt un remplaçant pour du Modern C++ que pour du C.

Le C permet en effet de se "tirer une balle dans le pied", mais c'est justement ce comportement qui lui permet de gérer du matos ne respectant pas toujours les "normes" comme il le devrait (ex: l'arithmétique des pointeurs, absolument unsafe, mais quasi obligatoire pour taper dans certains registres ou zones mémoires non couver par les APIs public des microcodes).
Pensez aussi que le matos et leurs microcodes contiennent pas mal de bug et de souplesses dans leurs implémentations des specs en général.

Pour moi, des langages comme Zig ou Odin sont plus intéressant comme remplaçant du C legacie que Rust, même s'ils demandent encore du travail ils prennent la bonne voie.

Enfin, dans tous les endroits ou Rust peut être utilisé, autant qu'il le soit plutôt que du "C with Object" avec plein de code Boilerplate (même avec des Macro ).

[sergio_is_back]

Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?

Ça c'est valable pour tous les langages !
Quelque soit le niveau d'abstraction proposé... Mauvais usage ne veut pas dire mauvais langage

[fdecode]

Le C permet en effet de se "tirer une balle dans le pied", mais c'est justement ce comportement qui lui permet de gérer du matos ne respectant pas toujours les "normes" comme il le devrait (ex: l'arithmétique des pointeurs, absolument unsafe, mais quasi obligatoire pour taper dans certains registres ou zones mémoires non couver par les APIs public des microcodes).
Pensez aussi que le matos et leurs microcodes contiennent pas mal de bug et de souplesses dans leurs implémentations des specs en général.

Les références et références mutables de rust sont des pointeurs (des pointeurs bas-niveau, pas des pointeurs "intelligents") dont l'usage est controlé par la sémantique du langage.
Mais en Rust il est tout à fait possible de travailler sur les pointeurs de manière non-contrôlée, tout simplement en utilisant le mode unsafe { ... }.
C'est découragé, c'est vrai, mais vous pouvez même faire de l'arithmétique de pointeurs en vue d'un adressage non contrôlé de la mémoire.
Même la sacrosainte interdiction de dupliquer les références mutables peut être contournée, comme le montre l'exemple suivant:

https://play.rust-lang.org/?version=...db6b8494ff95b5

Dans ce code, la charge de calcul se limite à 3 lignes (copie du pointeur, multiplication et addition sur la donnée pointée), le reste est pour ainsi dire du casting de type.

On peut donc travailler en unsafe, mais la philosophie globale est de limiter cet usage à des situations nécessaires.

LE truc que je trouve ballot, c'est que le Rust est plutôt un remplaçant pour du Modern C++ que pour du C.

La structure de donnée est très simple: des types 'struct', des types 'union' (unsafe) et les types 'enum' qui sont des sortes d'unions labélisées (donc safe).
Rien de plus, puisque dans rust, la hiérarchie "objet" ne concerne pas les structures de donnée.
En ce sens, rust est très proche du C. Plus proche du C que du C++, je dirais.

En revanche, la hiérarchie "objet", et plus généralement les qualités multi-paradigme du langage, se construisent au travers des traits, qui n'accèdent pas directement aux données.
Le système de trait de rust est vraiment très puissant...
L'approche objet de Rust, qui dissocie les méthodes des structures, est un peu atypique pour un langage objet. Mais ça fonctionne très bien.

Bref, pour simplifier, le langage rust c'est comme du C avec en plus une union labélisée, une sémantique de contrôle (débrayable) des pointeurs, un système de trait, qui est essentiellement indépendant de la structure de donnée, et la possibilité de paramètres de types pour faire de la programmation générique.
Je le vois bien plus comme une évolution du C que du C++.

[chrtophe]

Je pense pas qu'ils vont recoder ce qui est en C, les ajouts/modifs se feront par contre en Rust.

Du coup, pour être dev noyau il faudra maitriser le C et Rust. Mais c'est peut-être pas un prob quand on a un bon niveau en programmation, ce qui est le cas de ce type de dev.

[Patrick Ruiz]

Après 31 ans, un deuxième langage sera admis pour le développement du noyau Linux : c’est le Rust
Considéré par plusieurs comme candidat idéal pour la mise au rebut du langage C

Les principaux mainteneurs du noyau Linux sont des habitués du langage C dont l’âge commence par le chiffre 5. Certains se rapprochent même de la soixantaine. Une nouvelle génération de mainteneurs dont la tranche d’âge se situe dans la trentaine gravit les échelons et donc la difficulté de trouver des mainteneurs pour le noyau Linux risque d’aller croissant si son développement se poursuit en langage C. C’est pour autant de raisons que 2022 pourrait être l’année du langage Rust au sein du noyau Linux. Rust for Linux est susceptible d’être prêt pour la version 6.1 du kernel Linux. C’est ce qui ressort d’une récente intervention de Linus Torvalds lors du dernier Open Source Summit.

Les notes de version de Linux 6.0 rc1 dressent un état des lieux des avancées en ce qui concerne le projet Rust for Linux : un groupe de travail y relatif est en place, un pilote préliminaire pour les supports de stockage NVMe développés avec ledit langage est disponible, ainsi qu’un pilote pour un serveur destiné au protocole de réseau 9P. L’équipe continue néanmoins à faire face des difficultés avec la compilation. En effet, elle se fait avec GCC pour le noyau tandis que Rust l’est encore avec LLVM. Un frontend Rust pour GCC est en cours de gestation mais l’initiative est encore au stade de l’enfance.

La prise en charge de Rust pour le développement du noyau Linux commence se poursuit et est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

Et vous ?

Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ? Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents

[chrtophe]

Pourquoi le langage C pourrait encore avoir de longues années devant lui ?

Parce que même au cas ou plus aucun projet n'est démarré en C, on ne va recoder from scratch un projet conséquent, encore moins le noyau linux qui fait environ 28 millions de lignes.

Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?

difficile de répondre pour moi.

Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?

Si ces mauvais usages peuvent être "empêchés" avec Rust pourquoi pas, mais pour participer au développement il faudra connaitre et le C et Rust.

[disedorgue]

Avons nous besoin du C pour compiler le compilateur Rust et celui-ci utilise-t-il toujours la lib C ?

[Uther]

Si ces mauvais usages peuvent être "empêchés avec Rust pourquoi pas, mais pour participer au développent il faudra connaitre et le C et Rust.

Pas vraiment, le cœur du noyau reste en C, il n'est pas prévu que ça change. On pourra toujours le développer sans connaitre Rust. Le Rust gagne juste une API officielle pour permettre de faire des modules séparés (en gros les drivers).

Avons nous besoin du C pour compiler le compilateur Rust et celui-ci utilise-t-il toujours la lib C ?

Rust n'a pas besoin de la lib C en mode nostd (sans accès aux fonctionnalité de l'OS) qui est justement ce que l'on utilise quand on développe pour un noyau. Il en a juste besoin de la libc en mode standard car c'est la seule API stable pour accéder aux fonctionnalités de la grande majorité OS modernes.
Par contre le backend habituel de Rust repose sur LLVM qui est écrit en C++ pour bénéficier de ces grosses capacités d'optimisation. Il existe un backend alternatif en Rust mais il vise surtout la compilation rapide de code peu optimisé.

[OrthodoxWindows]

Pourquoi le langage C pourrait encore avoir de longues années devant lui ?

Un langage est adapté pour son usage. Il ne me semble pas qe le C se soit retrouvé inadapté du jour au lendemain. Donc si le C est toujours adapté, le C est effectivement de très longues années devant lui.

Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?

Non. Mais peut-être d'un langage complémentaire.

Comme chrtophe, je ne connait pas assez bien le sujet pour répondre plus précisément. Mais pour suivre les discussions sur le sujet durant les dernières année, il me semble que si certains langages posent problème, c'est plutôt des langages de haut-niveau (l'inverse du C).

[d_d_v]

Pourquoi ne pas faire évoluer le langage C, plutôt que d'utiliser un nouveau langage ? Il y a beaucoup de changements dans le C++, je ne vois pas pourquoi ce ne serait pas possible pour le C.

[disedorgue]

Bah, à ma connaissance, ce n'est pas les développeurs Linux qui développent aussi le C ou Rust.

[petitours]

Pour ma part la grande question est "Pourquoi y aurait il besoin de mettre au rebus le C ?" pourquoi vouloir changer ce qui va très bien ?

[chrtophe]

Parce que ça ne pas si très bien que ça.

Il est facile en C de créer une fuite mémoire ou un segfault en gérant mal des pointeurs par exemple. Si Rust évite cela nativement, c'est comme ça que j'ai compris le truc, ça a une utilité. Ca ne pas pas dire que le C sera ou doit être mis au rebus.

[gzii69]

Oui et même en y faisant attention, on peut oublier qu'il peut y avoir des accès concurrents par exemple.
J'ai été rappelé à l'ordre plusieurs fois par le compilateur Rust, pour des choses qui m'avaient échappé.

En C++ ça se serait compilé, mais j'aurais pu avoir des problèmes ultérieurs.
Maintenant mon code tourne bien sur les serveurs depuis un moment, et si au début je m'inquiétais un peu (nouveau code fait assez vite, bref l'habitude au début de surveiller tout le temps), maintenant ça fait des mois que je suis tranquille pour cette partie là.
Est-ce que j'aurais pu prévoir et éviter ces erreurs ?
Oui sans doute.
Est-ce que je suis à l'abri des erreurs ?
Certainement pas, même avec les méthodes et la volonté, quand j'ai la tête dans le guidon c'est très facile d'oublier quelque-chose,
et je crois que c'est assez improbable que ça soit détecté par la personne qui fait la revue mais qui passe moins de temps dessus.

Maintenant j'aime bien le C pour sa simplicité, le C++ pour les possibilités, et je n'ai pas l'impression d'être brimé, j'ai plutôt l'impression d'être aidé par le compilateur Rust.
Et je suis content que ça soit fait à la compilation, le code compilé n'a plus toutes ces vérifications, il reste léger et rapide.

[Patrick Ruiz]

L’inclusion de Rust for Linux à la version 6.1 du noyau est désormais en cours comme souhaité par Linus Torvalds
Et va rendre possible le développement de pilotes dans un autre langage que le C

Linus Torvalds l’avait promis lors du dernier Open Source Summit : il pousserait pour l’inclusion de Rust for Linux à la version 6.1 du noyau. La manœuvre est désormais en cours comme le confirme un récent Pull Request. Après 31 ans, un deuxième langage sera donc admis pour le développement du noyau : c’est le Rust. Les débats y relatifs tournent au tour de la possibilité d’une mise au rebut du C au profit du langage Rust compte tenu des avantages qu’il introduit. Petite précision néanmoins : pour le moment, le Rust gagne juste une API officielle pour permettre de développer des modules séparés ou pilotes.

Sur la question de l’éventualité d’une mise au rebut du langage C, le créateur du langage C3 liste un ensemble de raisons pour lesquelles les initiatives allant dans ce sens ont de fortes chances d’échouer :

La chaîne d'outils du langage C

Le langage C n'est pas seulement le langage lui-même, mais aussi tous les outils de développement développés pour ce langage. Vous voulez faire une analyse statique de votre code source ? - Il y a beaucoup de gens qui travaillent sur ce sujet pour le C. Des outils pour détecter les fuites de mémoire, les courses de données et autres bogues ? Il y en a beaucoup, même si votre langage est mieux outillé.

Si vous voulez cibler une plateforme obscure, il est probable que vous utilisiez le C. Le statut du C en tant que lingua franca de l'informatique d'aujourd'hui fait qu'il vaut la peine d'écrire des outils pour ce langage, et de nombreux outils sont donc écrits.

Si quelqu'un a mis en place une chaîne d'outils qui fonctionne, pourquoi risquer de changer de langage ? Un "meilleur C" doit apporter beaucoup de productivité supplémentaire pour motiver le temps passé à mettre en place une nouvelle chaîne d'outils. Reste même à savoir si cela est possible.

Les incertitudes d'un nouveau langage

Avant qu'un langage ne soit arrivé à maturité, il est probable qu'il comporte des bogues et qu'il soit modifié de manière significative pour résoudre les problèmes de sémantique du langage. Et le langage est-il même conforme à la publicité ? Il offre peut-être quelque chose comme "des temps de compilation exceptionnels" ou "plus rapide que le C" - mais ces objectifs s'avèrent difficiles à atteindre lorsque le langage ajoute l'ensemble des fonctionnalités.

Et qu'en est-il des mainteneurs ? Bien sûr, un langage open source peut être bifurqué, mais je doute que de nombreuses entreprises soient intéressées par l'utilisation d'un langage qu'elles pourraient être obligées de maintenir plus tard. Parier sur un nouveau langage est un gros risque.

Le fait que le langage pourrait tout simplement ne pas être assez bon

Le langage s'attaque-t-il aux véritables points faibles du C ? Il s'avère que les gens ne sont pas toujours d'accord sur ce que sont les points sensibles du C. L'allocation de mémoire, la gestion des tableaux et des chaînes de caractères sont souvent délicates, mais avec les bonnes bibliothèques et une bonne stratégie mémoire, elles peuvent être minimisées. Le langage ne traite-t-il pas des problèmes dont les utilisateurs avancés ne se soucient pas vraiment ? Si c'est le cas, sa valeur réelle pourrait être beaucoup plus faible que prévu.

Et pire encore, que se passe-t-il si le langage omet des fonctionnalités cruciales qui sont présentes en C ? Des fonctionnalités sur lesquelles les programmeurs avancés du C comptent ? Ce risque est accru si le concepteur du langage n'a pas beaucoup utilisé le C, mais vient du C++, du Java, etc.

L’absence de développeurs expérimentés pour un nouveau langage

Un nouveau langage disposera naturellement d'un groupe beaucoup plus restreint de développeurs expérimentés. Pour toute entreprise de taille moyenne ou grande, c'est un énorme problème. Plus il y a de développeurs disponibles pour une entreprise, mieux elle se porte.

De plus, si l'entreprise a l'expérience du recrutement de développeurs C, elle ne sait pas comment recruter pour ce nouveau langage.

L'ABI C

Si le langage ne peut pas facilement appeler - ou être appelé - par du code C, alors toute personne utilisant le langage devra faire un travail supplémentaire pour faire à peu près tout ce qui est interface avec du code extérieur. C'est potentiellement un énorme inconvénient.

Linus Torvalds fait-il fausse route en ouvrant le développement du noyau Linux au langage Rust ?

Les principaux mainteneurs du noyau Linux ont un âge qui commence par le chiffre 5. Certains se rapprochent même de la soixantaine. Du coup, la communauté du célèbre noyau open source commence à penser au changement de générations. Une nouvelle dont la tranche d’âge se situe dans la trentaine gravit les échelons, mais comme Linus lui-même le souligne : « Il s'avère qu'il est vraiment difficile de trouver des personnes qui sont des mainteneurs » ; un fait lié à ceci que le développement du kernel Linux continue de se faire en C et assembleur – des langages auxquels la vieille génération est plus accoutumée ? C’est une possibilité et elle est susceptible d’expliquer pourquoi 2022 pourrait être l’année du langage Rust au sein du noyau Linux.

Les notes de version de Linux 6.0 rc1 dressent un état des lieux des avancées en ce qui concerne le projet Rust for Linux : un groupe de travail y relatif est en place, un pilote préliminaire pour les supports de stockage NVMe développés avec ledit langage est disponible, ainsi qu’un pilote pour un serveur destiné au protocole de réseau 9P. L’équipe continue néanmoins à faire face des difficultés avec la compilation. En effet, elle se fait avec GCC pour le noyau tandis que Rust l’est encore avec LLVM. Un frontend Rust pour GCC est en cours de gestation mais l’initiative est encore au stade de l’enfance.

15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans (chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE)) sont liées à des tares que traînent le langage C : problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. Linus Torvalds s’est penché il y a peu sur un potentiel problème de sécurité avec les fonctions primitives d'exécution spéculative de la liste liée du noyau écrit en ANSI C. C’est en corrigeant ce problème qu’il s’est rendu compte qu’en C99 l'itérateur passé aux macros de parcours de liste doit être déclaré dans une portée en dehors de la boucle elle-même. C’est de ce constat que venait sa récente décision de faire passer le noyau Linux au C moderne (C11) dont la normalisation est achevée en 2011. C’est le genre de raisons techniques susceptibles de justifier la mise au rebut du langage C au profit du Rust pour le développement du noyau sur le long terme.

La nouvelle de la prochaine inclusion de Rust for Linux à la version 6.1 du noyau arrive dans un contexte où le regard de Linus Torvalds sur le langage Rust a changé. La prise en charge de Rust pour le développement du noyau Linux se poursuit et est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

Source : lkml

Et vous ?

Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ? Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents

[Bill Fassinou]

Rust for Linux est officiellement fusionné
le support initial de Rust for Linux fournit l'infrastructure de base et une intégration élémentaire

Le code initial de l'infrastructure Rust a été fusionné dans l'arbre Git principal de Linux 6.1 ce lundi par Linus Torvalds. Ce nouveau code initial de 12 500 lignes ne fournit que l'infrastructure de base et une intégration très élémentaire, tandis que les futures demandes d'extraction ajouteront plus d'abstractions de sous-systèmes, divers pilotes écrits en Rust, et plus encore. La construction du noyau Linux avec le support Rust reste facultative. Le projet "Rust for Linux" franchit une nouvelle étape importante, mais certains développeurs semblent toujours sceptiques face à l'introduction du langage Rust dans le noyau Linux.

Dans un message adressé à la communauté du noyau lundi, Torvalds a déclaré : « l'arbre a une base récente, mais est fondamentalement dans linux-next depuis un an et demi. Il a été mis à jour sur la base des retours du Kernel Maintainer's Summit. Miguel est le mainteneur principal, et j'aide quand c'est nécessaire. Notre plan est que l'arbre passe à la pratique standard de non-rebasage une fois que cette série initiale d'infrastructures sera terminée. Le contenu est le minimum absolu pour permettre la construction du code Rust dans le noyau, avec beaucoup plus d'interfaces (et de pilotes - NVMe, 9p, M1 GPU) sur le chemin ».

Pour rappel, le projet "Rust for Linux" vise à introduire un nouveau langage de programmation système dans le noyau. Rust a une propriété clé qui le rend très intéressant à considérer comme le deuxième langage du noyau : il garantit qu'aucun comportement indéfini n'a lieu (tant que le code non sécurisé est sain). Cela inclut l'absence d'erreurs de type use after-free, double frees, data races, etc. Après 31 ans, un deuxième langage sera donc admis pour le développement du noyau. Les débats y relatifs tournent au tour de la possibilité d’une mise au rebut du C au profit du langage Rust.

Petite précision néanmoins : pour le moment, Rust gagne juste une API officielle pour permettre de développer des modules séparés ou pilotes. Torvalds a annoncé que le support initial de Rust for Linux concerne environ 4 domaines, notamment :

• éléments internes du noyau (expansion kallsyms pour les symboles Rust, format %pA) ;
• infrastructure Kbuild (règles de construction Rust et scripts de support) ;
• crates et bindings Rust pour la construction initiale minimale viable ;
• documentation et échantillons du noyau Rust.

Linus Torvalds fait-il fausse route en ouvrant le développement du noyau Linux au langage Rust ? Les principaux mainteneurs du noyau Linux ont un âge qui commence par le chiffre 5. Certains se rapprochent même de la soixantaine. Du coup, la communauté du célèbre noyau open source commence à penser au changement de générations. Une nouvelle dont la tranche d’âge se situe dans la trentaine gravit les échelons, mais comme Linus lui-même le souligne : « il s'avère qu'il est vraiment difficile de trouver des personnes qui sont des mainteneurs ». Un fait lié à ceci est que le développement du noyau Linux continue de se faire en C et assembleur.

Il semble en effet qu'il s'agit de langages avec lesquels la vieille génération est plus habituée. Ainsi, l'introduction de Rust dans le noyau pourrait être un moyen pour Torvalds et les mainteneurs séniors du noyau d'attirer de jeunes talents - qui sont beaucoup plus à l'aise avec les langages modernes - pour participer au développement de Linux. L'autre chose est que 15,9 % des 2 288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des tares que traîne le langage C : problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoires invalides ou libérées, etc.

Torvalds s’est penché il y a peu sur un potentiel problème de sécurité avec les fonctions primitives d'exécution spéculative de la liste liée du noyau écrit en ANSI C. C’est en corrigeant ce problème qu’il s’est rendu compte qu’en C99 l'itérateur passé aux macros de parcours de liste doit être déclaré dans une portée en dehors de la boucle elle-même. C’est de ce constat que venait sa récente décision de faire passer le noyau Linux au C11 dont la normalisation a été achevée en 2011. C’est le genre de raisons techniques susceptibles de justifier la mise au rebut du langage C au profit du Rust pour le développement du noyau sur le long terme.

La prise en charge de Rust pour le développement du noyau Linux se poursuit et est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr ». Le langage Rust, développé par Mozilla Research, est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt.

Selon certains observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Par exemple, chez le leader mondial du cloud computing AWS, on précise que choisir Rust pour ses projets de développement, c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

Source : Linus Torvalds

Et vous ?

Que pensez-vous de l'introduction du langage Rust dans le noyau Linux ?

Voir aussi

L'inclusion de Rust for Linux à la version 6.1 du noyau est désormais en cours comme souhaité par Linus Torvalds, et va rendre possible le développement de pilotes dans un autre langage que le C

« Il est vraiment difficile de trouver des mainteneurs » : Linus Torvalds parle de la prochaine génération de responsables, du développement de Linux à l'occasion de la conférence Open Source Summit

Programmation : une étude révèle les langages les plus voraces en énergie. Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

[Bruno]

Un premier aperçu de Rust dans le noyau 6.1, avec Jonathan Corbet,
« il n'y aurait pas encore assez de Rust dans le noyau pour faire quoi que ce soit d'intéressant », estime-t-il

De nombreux changements importants ont été intégrés dans la version 6.1, mais l'un des changements qui a reçu le plus d'attention aura également le moins d'effet à court terme pour les utilisateurs du noyau : l'introduction du support du langage de programmation Rust. Linus Torvalds l’avait promis lors du dernier Open Source Summit : il pousserait pour l’inclusion de Rust for Linux à la version 6.1 du noyau. Il a annoncé le 2 octobre la disponibilité générale de Linux 6.0 avec des ajouts notables en matière de prise en charge matérielle et d'autres améliorations.

Le code initial de l'infrastructure Rust a été fusionné dans l'arbre Git principal de Linux 6.1 le 3octobre par Linus Torvalds. Ce nouveau code initial de 12 500 lignes ne fournit que l'infrastructure de base et une intégration très élémentaire, tandis que les futures demandes d'extraction ajouteront plus d'abstractions de sous-systèmes, divers pilotes écrits en Rust, et plus encore. La construction du noyau Linux avec le support Rust reste facultative.

Dans un message adressé à la communauté du noyau, Torvalds a déclaré : « l'arbre a une base récente, mais est fondamentalement dans linux-next depuis un an et demi. Il a été mis à jour sur la base des retours du Kernel Maintainer's Summit. Miguel est le mainteneur principal, et j'aide quand c'est nécessaire. Notre plan est que l'arbre passe à la pratique standard de non-rebasage une fois que cette série initiale d'infrastructures sera terminée. Le contenu est le minimum absolu pour permettre la construction du code Rust dans le noyau, avec beaucoup plus d'interfaces (et de pilotes - NVMe, 9p, M1 GPU) sur le chemin ».

Selon Jonathan Corbet, aucun système doté d'un noyau 6.1 de production n'exécutera de code Rust, mais ce changement donne aux développeurs du noyau une chance de jouer avec le langage dans le contexte du noyau et de se faire une idée de la façon dont le développement Rust se déroule. La conclusion la plus probable pour la plupart des développeurs est qu'il n'y a pas encore assez de Rust dans le noyau pour faire quoi que ce soit d'intéressant.

Jonathan Corbet a eu son premier aperçu des sources BSD Unix en 1981, lorsqu'un instructeur de l'Université du Colorado l'a laissé « corriger » l'algorithme de pagination. Depuis, il n'a cessé de fouiller dans tous les systèmes sur lesquels il a pu mettre la main, travaillant au passage sur des pilotes pour les systèmes VAX, Sun, Ardent et x86. Il a obtenu son premier système Linux en 1993, et n'a jamais regardé en arrière. Corbet est actuellement cofondateur et rédacteur en chef de Linux Weekly News.

Le travail sur Rust pour le noyau Linux est en cours depuis quelques années, et il a abouti à la création de beaucoup de code de soutien et de quelques pilotes intéressants à regarder. D'autres initiatives sont en cours, notamment l'écriture d'un pilote graphique Apple en langage Rust. Pour la fusion initiale dans le noyau principal, Linus Torvalds a clairement indiqué qu'il fallait inclure le moins de fonctionnalités possibles. Ces pilotes et leur code de support ont donc été supprimés et doivent attendre une future version du noyau. Ce qui est présent est le support nécessaire pour construire un module qui peut être chargé dans le noyau, ainsi qu'un petit module d'exemple.

Pour rappel, le projet Rust for Linux vise à introduire un nouveau langage de programmation système dans le noyau. Rust a une propriété clé qui le rend très intéressant à considérer comme le deuxième langage du noyau : il garantit qu'aucun comportement indéfini n'a lieu (tant que le code non sécurisé est sain). Cela inclut l'absence d'erreurs de type use after-free, double frees, data races, etc. Après 31 ans, un deuxième langage sera donc admis pour le développement du noyau. Les débats y relatifs tournent au tour de la possibilité d’une mise au rebut du C au profit du langage Rust.

Construction du support Rust

« Le premier défi que les développeurs intéressés rencontreront est de construire le support Rust », déclare Jonathan Corbet. Le processus de configuration du noyau recherche les prérequis sur le système de construction et, s'ils ne sont pas présents, désactive silencieusement les options Rust afin qu'elles n'apparaissent même pas dans, par exemple, make menuconfig. Jonathan Corbet, bien qu'ayant installé Rust sur le système en question, s'est heurté à ce problème et a donc été contraint au processus ignominieux de lire la documentation pour comprendre ce qui manquait.

La construction du support Rust nécessite des versions spécifiques du compilateur Rust et de l'utilitaire bindgen - plus précisément, Rust 1.62.0 et bindgen 0.56.0. Si le système cible possède des versions plus récentes, le processus de configuration émettra des avertissements mais se poursuivra quand même. Plus gênant pour quiconque essaie de construire avec la chaîne d'outils Rust fournie par son distributeur, le processus de construction a également besoin de la source de la bibliothèque standard Rust afin de pouvoir construire sa propre version des crates core et alloc.

« Jusqu'à ce que les distributeurs commencent à fournir des paquets "Rust pour le noyau", il sera un peu difficile de placer ce code à un endroit où le processus de construction le trouvera », déclare Jonathan Corbet. « La façon d'obtenir facilement cette dépendance est de jeter l'éponge, d'abandonner la chaîne d'outils du distributeur et d'installer tout depuis les dépôts Rust à la place », poursuit-il.

La page getting started décrit comment le faire ; inévitablement, cela implique une de ces opérations de mise en confiance curl|bash. Le programme d'installation ne s'intéresse absolument pas à l'endroit où l'on souhaite que les éléments Rust soient installés (ils vont dans ~/.cargo) et modifie silencieusement les scripts de démarrage Bash de l'utilisateur pour ajouter le nouveau répertoire dans la variable PATH. Le résultat final fonctionne cependant et permet d'installer facilement les dépendances nécessaires.

Le module d'exemple

Une fois cela fait, le système de configuration du noyau consentira à définir l'option CONFIG_RUST ; une option supplémentaire permettra de construire le module d'exemple. Ce module (samples/rust/rust_minimal.rs) est en effet minimal, mais il est suffisant pour avoir une idée de ce à quoi ressemblera le code du noyau en Rust. Il commence par l'équivalent Rust d'une ligne #include :

use kernel::prelude::*;
Il reprend les déclarations trouvées dans rust/kernel/prelude.rs, en rendant disponibles quelques types, fonctions et macros.

Un module de noyau écrit en C comprend un certain nombre d'appels à des macros comme MODULE_DESCRIPTION() et MODULE_LICENSE() qui stockent des métadonnées sur le module dans une section ELF séparée. Les macros module_init() et module_exit() identifient respectivement les fonctions constructeur et destructeur du module. L'équivalent Rust met une grande partie de ce passe-partout dans un seul appel de macro :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
module! {
        type: RustMinimal,
        name: b"rust_minimal",
        author: b"Rust for Linux Contributors",
        description: b"Rust minimal sample",
        license: b"GPL",
    }

Cette macro est exigeante quant à l'ordre des différents champs et se « plaindra » si le développeur se trompe. En plus de rassembler toutes ces informations en un seul appel, la macro module ! inclut une entrée type : qui sera le pointeur vers le code réel du module. Le développeur devra fournir un type qui fait quelque chose d'intéressant. Dans l'exemple de module, ce type ressemble à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
struct RustMinimal {
        numbers: Vec<i32>,
    }

Il s'agit d'une simple structure contenant un Vec (un tableau, plus ou moins) de valeurs entières de 32 bits. C'est assez ennuyeux en soi, mais Rust permet ensuite d'ajouter des implémentations d'interfaces ("trait") à un type de structure. Ainsi, le module d'exemple implémente le trait kernel::Module pour le type RustMinimal :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
impl kernel::Module for RustMinimal {
        fn init(_module: &'static ThisModule) -> Result<Self> {
            pr_info!("Rust minimal sample (init)\n");
            pr_info!("Am I built-in? {}\n", !cfg!(MODULE));
 
            let mut numbers = Vec::new();
            numbers.try_push(72)?;
            numbers.try_push(108)?;
            numbers.try_push(200)?;
 
            Ok(RustMinimal { numbers })
        }
    }

La fonction init() est censée faire le travail habituel d'initialisation du module. Dans ce cas, elle bavarde un peu dans le journal du système (montrant au passage la macro cfg !() qui peut être utilisée pour interroger les paramètres de configuration du noyau au moment de la compilation). Il alloue ensuite un Vec mutable et tente d'y placer trois nombres. L'utilisation de try_push() est importante ici : un Vec se redimensionnera lui-même si nécessaire. Cela implique l'allocation de mémoire, qui peut échouer dans l'environnement du noyau. Si cette allocation échoue, try_push() renverra un statut d'échec et cela, à son tour, fera que init() renvoie un échec (c'est ce que fait le "?" à la fin de la ligne).

Enfin, si tout se passe bien, elle renvoie une structure RustMinimal avec le Vec alloué et un statut de réussite. Puisque ce module n'a pas interagi avec d'autres sous-systèmes du noyau, il ne fera rien d'autre que d'attendre patiemment d'être retiré. Il n'y a pas de fonction pour la suppression du module dans le trait Kernel::Module ; à la place, un simple destructeur pour le type RustMinimal est utilisé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
impl Drop for RustMinimal {
        fn drop(&mut self) {
            pr_info!("My numbers are {:?}\n", self.numbers);
            pr_info!("Rust minimal sample (exit)\n");
        }
    }

Cette fonction affiche les nombres qui ont été stockés dans le Vec au moment de l'initialisation (confirmant ainsi que les données ont survécu entre-temps) et retourne ; après cela, le module sera retiré et sa mémoire libérée. Il ne semble pas y avoir de moyen de faire échouer la suppression d'un module, ce qui doit parfois se produire dans les modules du monde réel.

« C'est, en première estimation, l'étendue de ce qui peut être fait avec les modules du noyau Rust en 6.1. Torvalds a demandé quelque chose qui pourrait faire "hello world" et c'est ce que nous avons obtenu. C'est quelque chose avec lequel on peut jouer, mais qui ne peut être utilisé pour aucune sorte de programmation réelle du noyau à ce stade », déclare Jonathan Corbet.

« Cette situation va, espérons-le, changer dans un avenir proche. La prochaine étape pour les développeurs de Rust-for-Linux sera de commencer à ajouter une partie de l'infrastructure qu'ils ont créée pour s'interfacer avec d'autres sous-systèmes du noyau. Cela permettra d'écrire du code réel pour le noyau et, tout aussi important, de montrer à quoi ressembleront les abstractions nécessaires pour travailler avec d'autres sous-systèmes du noyau », ajoute-t-il.

Source : LWN

Et vous ?

Quel est votre avis sur le sujet ?

Partagez-vous l'avis de qui estime qu'« il n'y aurait pas encore assez de Rust dans le noyau pour faire quoi que ce soit d'intéressant » ?

Voir aussi :

L'inclusion de Rust for Linux à la version 6.1 du noyau est désormais en cours comme souhaité par Linus Torvalds et va rendre possible le développement de pilotes dans un autre langage que le C

Rust for Linux est officiellement fusionné, le support initial de Rust for Linux fournit l'infrastructure de base et une intégration élémentaire

[smarties]

« il n'y aurait pas encore assez de Rust dans le noyau pour faire quoi que ce soit d'intéressant », estime-t-il

L'annonce est assez récente, ça ne va pas se faire du jour au lendemain ! Il est normal aussi de commencer doucement et de ne pas faire des choses ambitieuses dès le début.

Même si c'était en cours d'étude avant, je serais développeur pour le noyau, je ne commencerais pas à écrire du RUST pour le noyau tant que l'annonce officielle n'est pas parue.