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 !

« Rust est une solution pour éviter au noyau Linux et aux mainteneurs de plonger dans la stagnation », d'après Linus Torvalds
à propos de l'impact de ce langage dans le développement du kernel

Le , par Patrick Ruiz

37PARTAGES

40  0 
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. Ce pourrait être un motif de stagnation dans le processus de développement du kernel. C’est l’une des raisons de l’adoption du Rust comme deuxième langage pour la poursuite de cette activité. En sus, il y a que « Rust est digne d'intérêt d’un point de vue technique » comme le souligne Linus Torvalds lors du récent sommet Open Source de la Fondation Linux.

En effet, il y a une liste de griefs qui reviennent à l’encontre du langage C : les 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. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

C’est là qu’intervient le langage Rust considéré par des acteurs de la filière comme le futur de la programmation système en lieu et place du langage C ou encore comme la meilleure chance de l’industrie informatique pour la mise sur pied d’applications système sécurisées. Chez Amazon par exemple, on est d’avis que « choisir Rust c’est opter pour une meilleure sécurisation des logiciels qu’avec le C, mais une efficacité énergétique et une performance d’exécution que seul le C offre. »

En effet, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++.

Ainsi, en adoptant Rust, la communauté autour du noyau Linux entend mettre à profit ces 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.


« Nous commencerons à intégrer certains pilotes et sous-systèmes développés en Rust dès l’an prochain, mais il faudra de nombreuses années avant que Rust ne constitue une grosse part de la base de code dont dépend le noyau », déclare Linus qui suscite de l’intérêt sur le bilan de cette initiative

En effet, Rust est un projet prometteur, mais pas sans complications. Le projet Rust-for-Linux a recruté un ingénieur à temps plein l’année dernière, ainsi qu’un étudiant développeur. Plusieurs entreprises ont rejoint le projet pour soutenir ce travail. Il y a aussi un travail en cours pour faire fonctionner l’outil Coccinelle avec le code Rust. Une priorité actuelle est de trouver plus de relecteurs pour le code qui est soumis.

Sur le plan de la chaîne d’outils, le travail sur gccrs, le compilateur Rust basé sur GCC, a considérablement ralenti. Le générateur de code GCC pour rustc progresse mieux ; il peut compiler du code noyau maintenant et a été fusionné dans le compilateur. Ce backend basé sur GCC permettra d’étendre le support de Rust à des architectures qui ne sont pas supportées par rustc basé sur LLVM. Pendant ce temps, le projet Rust lui-même s’implique davantage dans ce travail ; c’est une bonne chose, car le noyau a des besoins spécifiques et aura besoin de garanties que les changements de langage ne casseront pas le code du noyau à l’avenir.

Au sein du noyau, le travail se poursuit dans un certain nombre de sous-systèmes. L’implémentation Rust du binder d’Android fonctionne bien et ses performances sont équivalentes à celles de l’implémentation C. La quantité de code non sécurisé qui a été nécessaire pour y parvenir était agréablement faible. Les liaisons avec les systèmes de fichiers font l’objet d’un travail de Wedson Almeida Filho, qui vise pour l’instant un support en lecture seule. L’objectif est de rendre possible l’implémentation d’un système de fichiers en Rust 100% sécurisé.

Il y a un nombre croissant de mainteneurs qui sont ouverts à l’idée d’utiliser Rust. Cependant, ces derniers se heurtent à la non disponibilité d’exemples de la façon dont les pilotes peuvent être écrits. Un palliatif serait de permettre la duplication de quelques pilotes uniquement à des fins d’usage comme exemples pour les développeurs

Il y a en sus d’autres défis ; l’intégration des abstractions de la couche bloc a rencontré une certaine résistance. Le mainteneur de la couche virtuelle de systèmes de fichiers souligne qu’il n’était pas opposé à fusionner ces abstractions, mais qu’il préférerait ne pas le faire et voir des systèmes de fichiers construits dessus tout de suite. Il préférerait voir une implémentation de quelque chose de relativement simple, dans le style du pilote binder, pour montrer que les choses fonctionnent comme prévu.


Dave Airlie, le mainteneur du sous-système DRM (graphique), a dit que, s’il en avait le pouvoir, il y aurait un pilote DRM Rust fusionné dans les prochaines versions. Christoph Hellwig a répliqué qu’Airlie était prêt à « rendre la vie de tout le monde infernale » pour qu’il puisse jouer avec son jouet préféré. Fusionner Rust, a dit Hellwig, obligerait les autres à gérer un second langage, de nouvelles chaînes d’outils, et « des wrappers avec des sémantiques bizarres ». Dan Williams a estimé que la situation actuelle « est ce à quoi ressemble le succès », et que la communauté du noyau s’était déjà engagée en faveur de Rust.

Airlie a poursuivi en disant qu’une grande partie du travail sur Rust est actuellement bloquée dans une sorte de problème de l’œuf et de la poule. Les abstractions ne peuvent pas être fusionnées tant qu’il n’y a pas d’utilisateur pour elles, mais le code qui a besoin de ces abstractions est bloqué en attendant que le code soit intégré dans plusieurs sous-systèmes. En conséquence, les développeurs travaillant sur Rust se traînent de grandes piles de correctifs dont ils ont besoin pour travailler sur leur code. Il a suggéré qu’il serait peut-être bon de créer une branche spéciale pour le code Rust, où les abstractions pourraient être fusionnées plus facilement, en attendant qu’elles soient prêtes pour la branche principale.

Rust : oui, mais...

Greg Kroah-Hartman, le mainteneur du noyau stable, a dit qu’il n’était pas opposé à l’idée d’une branche Rust, mais qu’il faudrait qu’elle soit maintenue par quelqu’un d’autre que lui. Il a aussi demandé comment le code Rust serait testé, et s’il y aurait des outils pour vérifier la qualité du code et la conformité aux normes de codage du noyau. Ojeda a répondu qu’il y avait déjà des outils pour le formatage du code Rust, et qu’il travaillait sur un outil pour vérifier les règles spécifiques au noyau. Il a aussi dit qu’il y avait des tests unitaires pour le code Rust, et qu’il espérait que le code Rust serait intégré dans les systèmes de test existants du noyau.

Dave Chinner s'inquiète du fait que les responsables manquent d'expertise pour examiner correctement les abstractions en cours de fusion. Airlie a répondu que les responsables fusionnent désormais de nombreuses API C sans vraiment comprendre comment elles fonctionnent. De nombreuses erreurs ont été commises au cours du processus, mais « nous sommes toujours là ». Lorsque des choses s’avèrent être cassées, elles peuvent être réparées, et cela se produira plus rapidement si le code remonte en amont.

Ted Ts'o s'est dit préoccupé par le fardeau que l'ajout du code Rust imposerait aux responsables. Les développeurs de Rust établissent des normes plus élevées que celles fixées par le passé, a-t-il déclaré. Fusionner de bonnes abstractions est une chose, mais qui est responsable de la révision des pilotes et comment les modifications à l'échelle de l'arborescence seront-elles gérées ? L’effort de Rust, a-t-il dit, arrive à un point où il touche une partie croissante de la communauté.

Williams a souligné que durant la session précédente, la difficulté de faire migrer les sous-systèmes du noyau vers de nouvelles API avait été évoquée ; maintenant, dit-il, on parle de passer à un tout nouveau langage. Hellwig a déclaré que le vrai problème est que les liaisons Rust ont tendance à fonctionner différemment des API C pour lesquelles elles fournissent des abstractions ; les nouvelles API sont peut-être meilleures, mais ce sont toujours des API complètement nouvelles. Ce qu’il faudrait faire, dit-il, c’est d’abord corriger les API C afin qu’elles soient directement utilisables par le code Rust. Il a proposé que, pour chaque sous-système envisageant d'introduire du code Rust, un an ou deux soient d'abord consacrés au nettoyage de ses API dans ce sens. Ojeda a déclaré que ce type d'amélioration de l'API s'était déjà produit dans certains sous-systèmes.

Linus Torvalds a déclaré qu'il voyait un fossé entre le système de fichiers et les responsables des pilotes. Les développeurs du côté des systèmes de fichiers ont tendance à être plus conservateurs, tandis que le monde des pilotes « c'est le Far West ». Les auteurs de pilotes ont tendance à ne pas comprendre la concurrence, a-t-il déclaré, et une grande partie du code est défectueux et irréparable. Il n’est donc pas surprenant qu’il y ait un intérêt à introduire un langage qui prenne mieux en charge l’écriture d’un code correct et sûr.

Brauner a déclaré que Rust peut aider à résoudre de nombreux problèmes, car le compilateur peut empêcher de nombreux bogues de pénétrer dans le noyau. Mais il s'inquiétait de savoir s'il y aurait un support pour le mainteneur et le développement dans quelques années. Airlie a de nouveau mentionné les développeurs avec du code hors arborescence nécessaire au code Rust; Cook a répondu que les personnes qui supervisent ce code sont des responsables, et que l'introduire entraînerait les responsables avec lui. Airlie a ajouté que ces responsables sont le genre de jeunes développeurs que la communauté du noyau aimerait attirer.

Les incertitudes sur le langage

Ts'o a demandé quand la communauté se sentirait suffisamment en confiance pour pouvoir avoir des modules dont la seule implémentation est dans Rust. Binder pourrait être un bon début, a-t-il déclaré, peut-être suivi par un pilote dont l'utilisation serait plus large. Airlie a déclaré qu'il envisageait un pilote graphique virtuel qui réimplémenterait un pilote C existant. Il existe également le pilote pour les GPU Apple M1. Il ressent une forte pression pour l'amener en amont et se demande s'il y a une raison pour laquelle il devrait le garder à l'écart. Après cela, il adorerait voir une réécriture du pilote Nouveau pour les GPU NVIDIA.

Arnd Bergmann a déclaré que ces pilotes pourraient être OK, mais qu'il faudra un peu plus de temps avant que quelque chose comme un pilote de clavier puisse être fusionné ; La chaîne d'outils n'est tout simplement pas prête, a-t-il déclaré, pour un pilote qui serait largement utilisé. Cela a conduit à une question sur les mises à niveau fréquentes de version observées dans le noyau, qui est passé à Rust 1.73.0 pour 6.7. Ce processus de mise à niveau finira par s'arrêter et une version minimale de Rust sera définie une fois que les fonctionnalités importantes dont dépend le noyau se seront stabilisées. Il a déclaré qu'il travaillait pour intégrer le code du noyau dans les tests d'intégration continue de Rust afin de garantir qu'il continue de fonctionner à mesure que le compilateur et le langage évoluent.

Bergmann a déclaré qu'il n'avait pas l'intention d'examiner sérieusement le langage jusqu'à ce qu'il puisse être compilé avec GCC. Torvalds a répondu que, même s'il avait l'habitude de trouver des problèmes dans le compilateur LLVM Clang, il est désormais plus susceptible de rencontrer des problèmes avec GCC ; il construit maintenant avec Clang. Ojeda a déclaré qu'il travaillait à la recherche de ressources de développement pour gccrs ; le projet repose actuellement sur plus de 800 correctifs hors arborescence et a encore beaucoup de travail à faire en plus. Le soutien du CCG prendra du temps, a-t-il déclaré.

Ts'o s'est plaint du fait que le langage n'est toujours pas entièrement stable. Cela pourrait constituer un problème particulier pour la communauté informatique confidentielle ; ils sont préoccupés par la sécurité et, par conséquent, par les rétroportages vers des noyaux supportant à long terme. Mais si ces noyaux sont sur des versions Rust différentes, ces rétroportages seront problématiques. Ojeda a déclaré que, bien qu'il s'agisse d'une "idée folle", le rétroportage des mises à niveau de version pourrait être envisagé. Il ne pense cependant pas que le taux de changement sera suffisamment élevé pour constituer un problème.

En conclusion, Torvalds a souligné qu'il y avait eu des problèmes au fil des années avec les changements de GCC qui cassaient le noyau ; la même chose arrivera sûrement avec Rust, mais ce sera finalement la même chose. La séance, bien au fil du temps, a été interrompue à ce stade. Reste à savoir si la communauté du noyau a réellement conclu à son engagement envers Rust ; il y aura presque certainement des Pull Request ajoutant du code Rust important dans un avenir proche.

Source : Video, LWN

Et vous ?

Quels sont les avantages et les inconvénients de Rust par rapport au C pour le code du noyau ?
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

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

Avatar de NotABread
Membre habitué https://www.developpez.com
Le 26/08/2024 à 16:27
@23JFK Qu'est-ce qui fait vieux/dégueulasse dans la syntaxe Rust ? As-tu un exemple que tu considères plus modern/exemplaire ?
5  0 
Avatar de NotABread
Membre habitué https://www.developpez.com
Le 26/08/2024 à 13:45
> Quels sont les avantages et les inconvénients de Rust par rapport au C pour le code du noyau ?
Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
La sécurité de la mémoire et de la concurrence garanti à la compilation et sans ramasse-miette est LE point fort de Rust. Cependant, Rust reste relativement jeune et son écosystème manque de maturité (lib parfois incompatible entre elle à cause du multithreading, grosse tendance à la sur-inclusion de dépendances, beaucoup en version 0.x, pas encore de framework UI qui se soit démarqué, ...)
C ne sera pas mis au placard par Rust dans la prochaine décennie au sein de Linux pour une simple: Linux est majoritaire écrit en C et le restera car aucun ne veut tout ré-écrire en Rust.

> 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 ?
En théorie, on peut faire du code sûr en C, en pratique cela demande beaucoup d'effort et d'attention. Le monde est vaste et complexe, il y aura toujours un pour trouver un scénario tordu auquel le développeur n'aura pas pensé et qui causera une mauvaise manipulation de la mémoire. Même pour opensshd, logiciel solide et exemplaire, on a trouvé un scénario menant à une mauvaise manipulation de mémoire.
Il est facile de blâmer les développeurs mais ils restent humain, soumis à la fatigue, aux deadlines et aux ressources limités. L'usage d'un langage garantissant sûreté de la mémoire et performance permet de combler le manque d'attention ou de forcer la main sur les problèmes mémoires.

> 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 ?
Pour l'UEFI, BIOS, driver et microcode, oui, cela fera sense car se sont des parties critiques pour un OS, mais aussi parce que sont des programmes très isolé du reste en dehors de ce qu'ils exposent.
Pour des logiciels plus orienté utilisateur (tableur, logiciel de peinture, calculatrice, ...), non car tant que la haute performance et la stabilité ne sont pas primordiales (et que l'écosystème de Rust ne sera pas mature) il n'y a pas de raison à privilégier python ou un kit webapps à Rust
4  0 
Avatar de floyer
Membre confirmé https://www.developpez.com
Le 27/08/2024 à 2:58
Lambda calcul avec closure, tuples… ce sont des éléments de sémantique, pas de syntaxe. (La syntaxe c’est plutôt le choix des accolades, begin/end, parentheses…). Et ce n’est pas parce que le lambda calcul ou les tuples (proposé par Python d’ailleurs) datent de 1958 avec Lisp que c’est une mauvaise chose.

Les types… comment un langage peut être sûr en vérifiant la cohérence à la compilation des types sans cela ? Et côté performance, il faut bien des types statiques comme en C. Non je ne vois pas où est le procès.

Le typage dynamique (Lisp, Python, Javascript…) c’est bien pour des scripts, du prototypage… dès que l’on fait des choses plus sérieuses, le typage statique (Typescript…) s’impose, et dans les langages assez modernes, l’inference de type évite que ce soit trop une gêne.

En quoi let est redondant… il indique la déclaration d’une variable par opposition a une affectation qui ne marche qu’avec des variables déjà crées. Cette distinction contribue aux vérifications sémantiques et permet de détecter des erreurs. Par ailleurs il permet l’inférence de type (let a=42)… évitant de devoir préciser le type si celui inféré est adéquat.
4  0 
Avatar de floyer
Membre confirmé https://www.developpez.com
Le 27/08/2024 à 10:25
La syntaxe de Rust ne me semble pas parfaite non plus (je pense qu’il faut un peu d’habitude). Notamment pour les chaînes de caractères (où il y a pas mal de & à placer ici où là).

Mais critiquer la syntaxe avec let et les tuples alors que c’est assez naturel:

let tuple = ('Hello', 5, 3.14);

Je pense que l’exemple est fort mal choisi.

Bon évidemment tuple.0 surprendra le programmeur Python (habitué à tuple[0]). Mais pas de quoi disqualifier le language.
3  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 27/08/2024 à 19:47
Citation Envoyé par 23JFK Voir le message
Pour le let, c'est surtout qu'il faille saisir 3 lettres à chaque fois... il ne semble pas y avoir d'opérateur séquentiel comme en C : pour être clair sa donne des trucs du genre ("en C" int a, b, c, d ; "en Rust" let a : u64 let b : u64 let c : u64 let d : u64 ) Désolé, mais à la fin, c'est le C qui gagne.
En Rust, on peut écrire :

Code Rust : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
fn main() {
    let (a, b, c, d);
    a = 1;
    b = 2;
    c = 3;
    d = 4;
    for (id, value) in [("a", a), ("b", b), ("c", c), ("d", d)] {
        println!("{id} == {value}");
    }
}
On peut aussi écrire :

Code Rust : Sélectionner tout
1
2
3
4
5
6
fn main() {
    let (a, b, c, d) = (1, 2, 3, 4);
    for (id, value) in [("a", a), ("b", b), ("c", c), ("d", d)] {
        println!("{id} == {value}");
    }
}
3  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 30/08/2024 à 7:49
Il y a de gros projet sérieux en Python mais le prob n'est pas là, on parle du noyau là. Je ne pense pas que le Python soit adapté à ça.
3  0 
Avatar de floyer
Membre confirmé https://www.developpez.com
Le 27/08/2024 à 17:47
Effectivement, si taper des lettres de plus t’est pénible, le C est peut-être préférable (peut-être lorgner sur APL réputé plus compact ?). Mais les constructions de plus haut niveau (pas de malloc à transtyper), free implicite, etc font que le language présente des avantages. J’avoue que j’aurais a priori plus confiance pour du code en Rust qu’en C. S’il compile, tu as déjà une partie des bugs potentiels détectés. Les autres aspects me semblent un peu secondaires.

(J’utilise actuellement plutôt OCaml qui est assez efficace, même si moins que C/Rust, mais présente le bon niveau d’abstraction).
2  0 
Avatar de NotABread
Membre habitué https://www.developpez.com
Le 27/08/2024 à 17:53
Je trouve la comparaison un poil injuste dans la mesure où le cas idéal de Rust est d'user de l'inférence de type alors qu'en C, on préféra expliciter le type.
Donc, en utilisant le typage automatique, Rust fait gagner une lettre (auto fait parti du standard 23 de C). Quite à pousser le vise sur le nombre de lettre, on peut compter le nombre de lettre des types de base:
- 'double' => 'f64'
- 'float' => 'f32'
- 'unsigned long long int' => 'u64'.
Bref, je trouve l'argument un peu léger, je ne pense pas qu'un code C en équivalent Rust soit significativement plus long pour le rayer des potentiels remplaçant de C.
Par contre mentalement, ça peut être agaçant de taper trois fois les même lettres partout dans le code.
2  0 
Avatar de prisme60
Membre régulier https://www.developpez.com
Le 10/01/2024 à 10:56
Comme toutes les nouveautés, cela se paye, mais cela est nécessaire pour avoir une amélioration de la qualité du noyau. Personnellement, je suis un fervent partisan du Rust, et des API bien construites. Une bonne API doit être intuitive et dans la mesure du possible rendre tout mauvais usage impossible. Pour un tel résultat, il faut notamment un typage fort que l'on a pas en C (C++). Le Rust sans unsafe interdit les transtypage à base de cast (comme caster un entier en pointeur, ou un pointeur d'un type dans un pointeur d'un autre type).
1  0 
Avatar de JPLAROCHE
Membre expérimenté https://www.developpez.com
Le 11/01/2024 à 15:42
Avoir une belle voiture au top de ses performances, répondant à ce que l'on attend d'elle, mais n'avoir qu'un seul ingénieur capable de remonter le réveil, n'est pas encourageant pour l'avenir, il est important d'activer l'engagement d'acteurs pour la suite de Linux.
ps( j'ai vécu cela )
1  0