Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Oui bien sur que un meilleur accès au cœur du noyau va arriver progressivement, mais dire qu'il n'y aurait pas encore assez de Rust dans le noyau pour faire quoi que ce soit d'intéressant, c'est un peu fort. Il y a déjà quelques projets très intéressants construit sur la base actuelle comme un driver pour les GPU Apple et NVMe.
La première version candidate de Linux 6.1 est disponible avec le support initial du langage Rust
Linus Torvalds aux développeurs du noyau : « grandissez et arrêtez de faire des demandes d'extraction juste avant la date limite »
la première version candidate de Linux 6.1 est disponible
Linus Torvalds a publié dimanche la première version candidate de Linux 6.1 (Linux 6.1-rc1) avec le support initial de Rust, l'ajout de MGLRU et la prise en charge de nouveaux matériels. La version stable de Linux 6.1 devrait arriver en décembre et sera probablement la version du noyau de Linux LTS de cette année. Torvalds a également lancé un appel aux développeurs pour qu'ils lui facilitent la vie en ajoutant du code plus tôt dans le cycle de développement. Il demande à chaque développeur de préparer le code qu'il souhaite ajouter à la nouvelle version du noyau avant l'ouverture de la fenêtre de fusion.
La fenêtre de fusion de deux semaines qui s'est ouverte avec la publication du noyau Linux 6.0 le 2 octobre est maintenant officiellement fermée et il est temps d'avoir un avant-goût de la prochaine version majeure, le noyau Linux 6.1. Linux 6.1-rc1 est prêt pour les testeurs, les adopteurs précoces et les utilisateurs à la pointe de la technologie qui veulent avoir un aperçu de ce qui sera inclus dans la version stable, qui est attendu pour le début ou la mi-décembre 2022 (soit le 4 décembre ou le 11 décembre). Comme cela a été annoncé depuis un moment, la plus grande nouveauté de Linux 6.1 est probablement la fusion du code de l'infrastructure Rust.
Cela rend possible le développement de pilotes dans un autre langage que le C. Toutefois, bien que cela semble très excitant pour les développeurs Rust, il ne s'agit que d'une mise en œuvre très basique du support pour le langage Rust qui ne peut pas être utilisé pour des cas d'utilisation réels pour le moment. Pendant la fenêtre de fusion, Linux 6.1 a ajouté de nombreuses autres fonctionnalités excitantes, notamment : MGLRU a été fusionné pour offrir un potentiel de performance significatif, en particulier pour les systèmes à mémoire limitée, et le travail sur le nouveau support graphique Intel Arc Graphics et AMD RDNA3 a été poursuivi.
En outre, KMSAN (Kernel Memory Sanitizer) a ajouté. KMSAN est un détecteur dynamique d'erreurs de mémoire pour le noyau Linux. Il fournit une solution rapide et complète pour trouver les bogues d'utilisation après la libération et hors limites. Entre autres nouveautés de Linux 6.1, Linux x86_64 émettra un avertissement par défaut sur les mappages W+X et AMD Platform Management Framework a fusionné, imprimant les cœurs de CPU où les défauts de segmentation se produisent. Cette dernière fonctionnalité aurait permis de détecter tous les débordements de tampon basés sur memcpy de ces dernières années, et bien plus encore.
Torvalds estime que le nouveau noyau Linux 6.1 pourrait recevoir jusqu'à huit versions candidates. « Cette version ne s'annonce pas particulièrement importante : nous n'avons "que" 11 500 commits non fusionnés pendant cette fenêtre de fusion, contre 13 500 la dernière fois. Donc pas exactement minuscule, mais plus petit que les dernières versions. Au moins en nombre de commits », a déclaré Torvalds. Une autre chose importante est la série de VM LRU multi-gen. Par ailleurs, puisque ce sera la dernière version majeure du noyau Linux de l'année, elle devrait également être la prochaine série LTS (Long-Term Support).
Enfin, Torvalds a profité de l'occasion pour demander aux développeurs du noyau d'être plus "proactifs" à l'avenir afin qu'il n'ait pas trop de choses à gérer à la fin de la fenêtre de fusion. « Laissez-moi juste dire qu'après avoir réglé ma machine et rattrapé la fenêtre de fusion, j'ai été quelque peu frustré par les demandes d'extraction tardives. Je l'ai déjà mentionné, mais c'est vraiment assez ennuyeux de recevoir un certain nombre de demandes d'extraction dans les derniers jours de la fenêtre de fusion », explique Torvalds. Il a offert des conseils sur la façon dont les développeurs de noyaux peuvent faire les choses correctement.
« Oui, la fenêtre de fusion est de deux semaines, mais c'est surtout pour me laisser le temps d'examiner les choses, pas pour "deux semaines pour mettre en place à la hâte une branche que vous enverrez à Linus le vendredi de la deuxième semaine". L'idée de "faire une nuit blanche pour rendre le papier la veille de la réunion" est quelque chose qui aurait dû disparaître après le lycée. Pas pour le développement de noyaux. La règle est que les choses qui me sont envoyées doivent être prêtes *avant* l'ouverture de la fenêtre de fusion, pas pendant la fenêtre de fusions », a déclaré dimanche Torvalds dans son message.
Il a ajouté : « avec un peu de mou pour "la vie arrive", bien sûr, mais j'ai vraiment l'impression que quelques personnes traitent la fin de la fenêtre de fusion comme une date limite, manquant l'ensemble "il était censé être prêt avant la fenêtre de fusion" ». Torvalds a reconnu que ce n'est pas la première fois qu'il dit cela, mais aimerait que ce soit la dernière. Il espère que plus de développeurs pourraient le prendre à cœur cette fois.
Source : Linus Torvalds
Et vous ?
Que pensez-vous des nouveautés de Linux 6.1-rc1 ?
Voir aussi
« Oui, la fenêtre de fusion est de deux semaines, mais c'est surtout pour me laisser le temps d'examiner les choses, pas pour "deux semaines pour mettre en place à la hâte une branche que vous enverrez à Linus le vendredi de la deuxième semaine". L'idée de "faire une nuit blanche pour rendre le papier la veille de la réunion" est quelque chose qui aurait dû disparaître après le lycée. Pas pour le développement de noyaux. La règle est que les choses qui me sont envoyées doivent être prêtes *avant* l'ouverture de la fenêtre de fusion, pas pendant la fenêtre de fusions » a déclaré dimanche Torvalds dans son message.
Pourquoi ne pas mettre en place une fenêtre d'une ou 2 semaines de propositions/analyses de branches **AVANT** l'ouverture de la fenêtre de fusion ?
Lycée & autodidacte
J'adore :Je vais être la risée : je ne comprends pas (et n'ai malheureusement jamais compris)L'idée de "faire une nuit blanche pour rendre le papier la veille de la réunion" est quelque chose qui aurait dû disparaître après le lycée.
Vous l'aurez compris, je suis un ancien, et (donc ? si ?) autodidacte……2 semaines de merge, avec un freeze au milieu, c'est-à-dire que seules les merge request déposées…
J'ai essayé une fois de travailler avec un tiers sur un projet : j'ai fait fuir le partenaire !
Il y a du progrès, si il n'a pas utiliser de "fuck" ou autre nom d'oiseau.
Mais il a raison.
C'est ce genre de comportement qui oblige à rajouter des règles, alors qu'il faudrait que les gens soient raisonnables et se disent que tout ajout de dernière minute à des conséquence pour le groupe.
A part ça même après le lycée ça m'arrivait de finir à la dernière minute, et je detestais ça
Quand j'étais comptable la pérriode d'inventaire ressemblait aussi à ça, un gros stresse pour boucler et retomber sur des pièces au dernier moment
La prochaine itération de Rust for Linux pour la version 6.2 du noyau est en cours de gestation
La prochaine itération de Rust for Linux pour la version 6.2 du noyau est en cours de gestation et ravive le débat sur la nécessité de la mise au rebut du C
En matière de programmation système
Après 31 ans, un deuxième langage de programmation a été admis pour le développement du noyau Linux : c’est le Rust. Un premier aperçu de Rust for Linux est disponible dans la version 6.1 du noyau. Même si Jonathan Corbet précise « qu’il n’y aurait pas encore assez de Rust dans le noyau pour faire quoi que ce soit d’intéressant », l’inclusion de ce langage vient raviver le débat sur la nécessité de la mise au rebut du langage C au profit du Rust en matière de programmation système. La question divise la communauté des développeurs.
Asahi Linya s’est penchée sur la tâche de développement d’un pilote pour unité de traitement graphique (GPU) pour les Macs M1 et ce, en Rust. Son comparatif entre les langages Rust et C se fait sans langue de bois : « Il n'y a absolument aucune chance que je n'aie pas eu à faire face à la gestion d’accès concurrents, des tentatives d’accès de zones mémoire après libération et toutes sortes d'autres problèmes si j'avais écrit cela en C. Tous les problèmes de concurrence disparaissent avec Rust ! La mémoire est libérée quand elle doit l'être ! Une fois que vous avez appris à faire fonctionner Rust avec vous, j'ai l'impression qu'il vous guide pour écrire du code correct, même au-delà des promesses de sécurité du langage. C'est vraiment magique ! »
« Il y a beaucoup de débats sur l'utilité ou non de Rust dans le noyau... d'après mon expérience, c'est bien plus utile que je ne l'aurais jamais imaginé ! », ajoute-t-elle.
Son retour d’expérience est une espèce de redite d’une compilation de raisons techniques susceptibles de justifier une mise au rebut du langage C au profit du Rust. En effet, 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.
De plus, 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 Linus Torvalds a ouvert la porte au développement du noyau en Rust.
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.
Source : lkml
Et vous ?
Voir aussi :
Je ne suis pas de ceux qui aiment les projets fait d'un patchwork de langages. Il faudrait plutôt miser sur un transcompiler Rust->C et voir si dans la durée, le Rust peut gagner la partie pour éventuellement abandonner la partie transcompilation.
Quand on voit les tweets, c'est certain que RUST apporte énormément de fiabilité pour de la programmation système.
Je ne suis pas sur de la pertinence d'un transcompilateur car cela peut produire des choses difficilement compréhensibles.
Les bibliothèques système peuvent aussi être écrites en RUST et utilisées pour tout.
Avoir le C et RUST pour le noyau complexifie probablement mais si on peut avoir des éléments de qualité, performants, stables et sécurisés il faut continuer l'intégration progressive de RUST.
Linus Torvalds demande aux développeurs du noyau de soumettre le code pour Linux 6.2 avant les congés de Noël
Linus Torvalds demande aux développeurs du noyau de soumettre le code pour Linux 6.2 avant les vacances de Noël "pour lui faciliter la vie"
et ajoute qu'il sera plus strict sur le sujet à l'avenir
Linus Torvalds a publié dimanche la septième version candidate (RC) du noyau Linux 6.1. Linux 6.1-rc7 devrait être l'avant-dernière version candidate avant la sortie officielle de Linux 6.1, probablement le 11 décembre. En outre, Torvalds a rappelé aux contributeurs que le rythme du cycle de développement du noyau se heurtera à Noël, et a donc invité les développeurs à soumettre leur travail pour la prochaine version noyau, Linux 6.2, avant les vacances. L'annonce de Torvalds indique également que Linux 6.1 a connu une augmentation des changements dans ce cycle, alors qu'il préfère voir le flux de correctifs ralentir.
Torvalds a hésité ces dernières semaines à prolonger le cycle de développement de Linux 6.1 d'une semaine supplémentaire. En l'état actuel des choses, il penche vers la publication de Linux 6.1-rc8 la semaine prochaine avant de publier le noyau stable de Linux 6.1 la semaine suivante. Ainsi, la version stable de Linux 6.1 sera publiée le 11 décembre, à moins que la semaine prochaine ne soit extrêmement calme, ce qui conduirait Torvalds à passer directement à la version 6.1. Dimanche, Torvalds a fait quelques remarques dans le message annonçant la dernière version candidate du noyau, Linux 6.1-rc7. « Une autre semaine s'est écoulée », a-t-il déclaré.
« Elle a commencé tranquillement, et j'étais presque certain que le fait que ce soit la semaine de Thanksgiving ici aux États-Unis signifiait qu'elle continuerait aussi en douceur. Mais je me suis trompé. La fin de la semaine a été marquée par le constat habituel : "les gens m'envoient leurs trucs le vendredi". Et le week-end a à peine ralenti les gens. Les statistiques de cette semaine sont donc presque identiques à celles des deux semaines précédentes. Et il n'y a pas que les statistiques, tout est très similaire. Il n'y a vraiment rien qui me préoccupe, si ce n'est que c'est un peu plus que ce qui me convient. Il aurait dû ralentir davantage depuis le temps ».
« En conséquence, je suis maintenant presque sûr qu'il s'agira d'une de ces sorties du type "nous aurons une semaine de plus et je ferai une rc8". Ce qui signifie que la prochaine fenêtre de fusion se situera pendant la période des fêtes. Peu importe. C'est ce que c'est », a ajouté Torvalds dans le message. En raison de ces constats et de la charge de travail qui lui aurait été imposée pendant la semaine, Torvalds a émis un avertissement concernant la prochaine fenêtre de fusion. Il a notifié aux contributeurs qu'il va tout simplement "ignorer" les demandes d'extraction qui arrivent "en retard" et les prendre en compte lors de la prochaine fenêtre de fusion.
« Cela signifie que je serai plus intransigeant que d'habitude lors de la prochaine fenêtre de fusion : la règle habituelle est que les choses qui me sont envoyées pour la fenêtre de fusion doivent être prêtes _avant_ l'ouverture de la fenêtre de fusion. Mais comme le guichet de fusion se déroule en grande partie pendant la période des vacances, je vais appliquer cette règle de manière assez stricte. Je veux voir tout le travail effectué dans les demandes de modification *avant* les festivités, et non pendant que vous buvez votre lait de poule et que vous êtes stressé par la saison », a-t-il averti. Torvalds a déclaré qu'il sera intraitable sur le sujet.
« Si l'on m'envoie des demandes d'extraction en retard, je dirai simplement : "ça peut attendre". OK ? Maintenant, je soupçonne que tout le monde _autre_ veut sortir son travail avant les fêtes de fin d'année aussi, donc j'espère que nous sommes tous en accord complet et violent sur ce sujet. Cependant, j'ai pensé que je devais commencer à sensibiliser les gens à ce sujet », a-t-il ajouté. Parmi les nombreux autres correctifs de bogues apportés au noyau Linux au cours de la semaine dernière, il faut noter que Linux 6.1-rc7 permet désormais aux utilisateurs de basculer plus facilement du pilote AMD P-State vers le pilote ACPI CPUFreq.
Ce n'est pas la première fois que Torvalds invite les contributeurs à être plus "proactifs" dans le développement du noyau. Le mois dernier, lors de la publication de la première version candidate de Linux 6.1 (Linux 6.1-rc1), Torvalds a lancé un appel aux développeurs afin que ces derniers "lui facilitent la vie en ajoutant du code plus tôt dans le cycle de développement". Il a invité chaque développeur à préparer le code qu'il souhaite ajouter à la nouvelle version du noyau avant l'ouverture de la fenêtre de fusion. Selon Torvalds, cette démarche lui évite d'avoir trop de choses à faire à la fin d'une fenêtre de fusion.
« Laissez-moi juste dire qu'après avoir réglé ma machine et rattrapé la fenêtre de fusion, j'ai été quelque peu frustré par les demandes d'extraction tardive. Je l'ai déjà mentionné, mais c'est vraiment assez ennuyeux de recevoir un certain nombre de demandes d'extraction dans les derniers jours de la fenêtre de fusion », explique Torvalds. Il a offert des conseils sur la façon dont les développeurs de noyaux peuvent faire les choses correctement. Torvalds a reconnu que ce n'est pas la première fois qu'il dit cela, mais aimerait que ce soit la dernière. Il espère que plus de développeurs pourraient le prendre à cœur cette fois.
« Oui, la fenêtre de fusion est de deux semaines, mais c'est surtout pour me laisser le temps d'examiner les choses, pas pour "deux semaines pour mettre en place à la hâte une branche que vous enverrez à Linus le vendredi de la deuxième semaine". L'idée de "faire une nuit blanche pour rendre le papier la veille de la réunion" est quelque chose qui aurait dû disparaître après le lycée. Pas pour le développement de noyaux. La règle est que les choses qui me sont envoyées doivent être prêtes *avant* l'ouverture de la fenêtre de fusion, pas pendant la fenêtre de fusions », a déclaré Torvalds le mois dernier.
Il a ajouté : « avec un peu de mou pour "la vie arrive", bien sûr, mais j'ai vraiment l'impression que quelques personnes traitent la fin de la fenêtre de fusion comme une date limite, manquant l'ensemble "il était censé être prêt avant la fenêtre de fusion" ». En ce qui concerne Linux 6.1, cette version est le plus susceptible d'être la version du noyau LTS (Long-Term Support) de cette année. Torvalds a invité les développeurs à la tester. « Allez tester, et pouvons-nous _s'il vous plaît_ commencer à calmer les choses ? Ne m'envoyez rien qui ne soit pas un bug clair et présent. Plus de nettoyages de dernière minute. Vous avez entendu ? ».
Source : Linus Torvalds
Et vous ?
Voir aussi
Linus Torvalds annonce la disponibilité de Linux 6.1 avec Rust comme 2e langage pour le développement
Linus Torvalds annonce la disponibilité de Linux 6.1 : après 31 ans, un deuxième langage est admis pour le développement du noyau, c’est le Rust
Considéré comme candidat à la mise au rebut du C
Linus Torvalds a annoncé la disponibilité de la version 6.1 du noyau Linux. À partir de cette mouture, un deuxième langage fait son entrée pour le développement du noyau ; c’est le langage Rust. Les débats en lien avec cette mesure 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.
En effet, Comme l'a déclaré Wedson Almeida Filho, de l'équipe Android de Google, « Nous pensons que Rust est désormais prêt à rejoindre le C en tant que langage pratique pour l'implémentation du noyau. Il peut nous aider à réduire le nombre de bogues potentiels et de failles de sécurité dans le code privilégié tout en jouant agréablement avec le noyau central et en préservant ses caractéristiques de performance. »
Plus précisément, comme Alex Gaynor et Geoffrey Thomas l'ont expliqué lors du Linux Security Summit 2019, près des deux tiers des failles de sécurité du noyau Linux proviennent de problèmes de sécurité de la mémoire. Et d'où viennent-ils ? Des faiblesses inhérentes au langage C et C++. Rust, en revanche, esquive ces problèmes en utilisant des interfaces de programmation d'applications (API) bien plus sûres. Rust est tout simplement plus sûr que C.
Récemment, l'Agence nationale de sécurité américaine (NSA), qui est chargée de sécuriser le code et de le casser, a suggéré que l'une des meilleures choses à faire pour la sécurité d’un programme est d'utiliser Rust plutôt que C. Bien sûr, il existe d'autres langages de ce type, tels que Swift, Go ou C#, mais ils ne se prêtent pas au type de programmation de bas niveau nécessaire à un système d'exploitation.
Dans la pratique, Google, par exemple, utilise désormais largement Rust dans Android. « L'objectif n'est pas de convertir le C/C++ existant en Rust, mais plutôt de transférer le développement de nouveaux codes vers des langages à mémoire sécurisée au fil du temps », indique le géant technologique.
Résultat : « la quantité de nouveau code non sécurisé par la mémoire entrant dans Android a diminué, le nombre de vulnérabilités de sécurité de la mémoire a également diminué. De 2019 à 2022, il est passé de 76 % à 35 % du total des vulnérabilités d'Android. 2022 est la première année où les vulnérabilités de sécurité de la mémoire ne représentent pas une majorité des vulnérabilités d'Android », ajoute-t-il.
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 pour Linux. C’est dire que l’ouverture du noyau Linux à ce langage poursuit son bout de chemin avec la conséquence que la mise au rebut du langage C n’est pas prévue pour demain. Néanmoins, c’est un changement qui tire sa source de la disponibilité et des compétences des tiers qui participent au développement du noyau.
En effet, 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.
Source : lkml
Et vous ?
Voir aussi :
J'ai plutôt l'impression que les dev C n'ont pas envie de réecrire du code qui fonctionne à peu près alors que les dev Rust sont eux très motivés pour réinventer la roue en mieux.
L'intégration RUST avec Cargo est beaucoup plus pratique que le C. Réécrire des bibliothèque permet aussi de se faire la main sur le langage.Envoyé par 23JFK
Je ne suis pas spécialement pour une réécriture de toutes les bibliothèques mais certaines gagneraient en lisibilité, performance et/ou fiabilité.
levez les yeux.
un démiurge autocrate(etc...) pose les mains sur les accoudoirs de son trône pour se lever...
"des mainteneurs pour le noyau Linux risque d’aller croissant si son développement se poursuit en langage C."
Ben voyons
C'est juste le langage le plus utilisé dans les OS (au sens large, démons, DE, ...) inclus, l'embarqué et une bonne partie des applications les plus utilisées.
Alors s'il est difficile de trouver de bons programmeurs C(++), le C a encore de beaux jours devant lui.
"Bon" pas dans le sens "connaisseur du C", mais bon dans le sens "qui maitrise l'algorithmie, ne font pas du code crade, respectent les ressources" : Les enseignements basés autour de langages plus permissifs tel que Python ou Java font que le code qu'ils pondent est au mieux "passable" dès que le langage ne corrige pas toutes leurs lacunes.
% de code en Rust dans Linux.
Si j'ai bien compris le nouveau noyau 6.2 est écrit en partie en Rust, mais de combien % ?
Ok j'ai trouvé ma réponse sur GitHub: 0%
Analyse GitHub:
c'est arrivé récemment, donc très peu. tout le code C ne va pas être réécrit en Rust, mais au fur et à mesure du temps ça va augmenter.
Presque rien en fait. Les noyau 6.1 (et suivants) ont juste mis a disposition une API Rust pour permettre de commencer le développement de drivers en Rust qui interagissent de manière propre avec le cœur du noyau en restera en C.
Quand des drivers écrits en Rust auront atteint un niveau de qualité suffisamment avancé pour être intégré au projet, ils pourraient le rejoindre, mais ça ne sera probablement pas le cas avant un moment.
Rust dans le noyau Linux : un projet prometteur, mais pas sans complications. La communauté dresse un bilan
Rust dans le noyau Linux : un projet prometteur, mais pas sans complications. La communauté dresse un bilan
lors de l'édition 2023 du Kernel Maintainers Summit
Rust, un langage de programmation moderne et sécurisé, suscite l’intérêt des développeurs du noyau Linux depuis plusieurs années. Lors du sommet des mainteneurs du noyau de 2023, le sujet a de nouveau été abordé. Comme l’a souligné Miguel Ojeda, le développeur principal du projet Rust-for-Linux, le nombre de personnes intéressées par l’utilisation de Rust pour le développement du noyau a considérablement augmenté au cours de la dernière année. Rust a été ajouté à Linux comme une expérience : la communauté du noyau est-elle prête à dire que l’expérience a réussi ?
Tout d'abord, pourquoi un autre langage après plus de 30 ans en C et en assembleur ? Et pourquoi Rust ?
Les principaux mainteneurs du noyau Linux ont un âge qui commence par le chiffre 5. Certains se rapprochent même de la soixantaine. Aussi, 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 est devenue l’année du langage Rust au sein du noyau Linux.
C'est ainsi qu'est né le projet Rust-for-Linux : initié en 2020 par Miguel Ojeda, un ingénieur logiciel chez CERN, il a reçu le soutien de Linus Torvalds, le créateur du noyau Linux. Le projet a été fusionné dans la branche principale du noyau Linux en version 6.1, en tant qu’expérience visant à déterminer si Rust est adapté pour le noyau, c’est-à-dire s’il vaut les compromis. Le projet fournit une infrastructure et des outils pour compiler, charger et déboguer du code Rust dans le noyau, ainsi qu’une bibliothèque standard minimale (core) et une bibliothèque d’abstraction du noyau (kernel).
Rust a une propriété clé qui le rend très intéressant à considérer comme un autre 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 (Use-After-Free (UAF) est une vulnérabilité liée à une utilisation incorrecte de la mémoire dynamique lors du fonctionnement du programme. Si après avoir libéré un emplacement mémoire, un programme n'efface pas le pointeur vers cette mémoire, un attaquant peut utiliser l'erreur pour pirater le programme), double free (des erreurs qui surviennent lorsque free() est utilisé plus d’une fois avec la même adresse mémoire comme entrée. Appeler free() deux fois sur la même variable peut entraîner une fuite de mémoire), data race (une data race survient quand une donnée partagée est accédée par au moins deux threads dont au moins un en écriture et ce, sans synchronisation), etc.
Le projet Rust for Linux n’a pas pour objectif de réécrire le noyau entier en Rust, mais plutôt d’ajouter du nouveau code, écrit en Rust, qui s’interface proprement avec l’infrastructure existante du noyau. Le projet vise également à encourager les développeurs à utiliser Rust pour les parties du noyau qui sont particulièrement sensibles ou complexes, telles que les pilotes de périphériques, les sous-systèmes de sécurité ou les protocoles réseau. Rust pourrait ainsi apporter des bénéfices en termes de qualité, de performance et de sécurité du code du noyau, tout en réduisant les coûts de développement et de maintenance.
Rust-for-Linux, ses apports et ses défis
Le projet Rust-for-Linux a recruté un ingénieur à temps plein l’année dernière, a déclaré Ojeda, 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é.
En général, il constate un nombre croissant de mainteneurs qui sont ouverts à l’idée d’utiliser Rust. Cela conduit à un problème auquel les développeurs Rust se sont heurtés, cependant. Il serait bon d’avoir quelques pilotes de référence dans le noyau comme exemple de la façon dont les pilotes peuvent être écrits et de permettre de comparer les pilotes Rust et C. La meilleure façon de le faire semble souvent être de fusionner un pilote Rust qui duplique la fonctionnalité d’un pilote C existant - mais ce genre de fonctionnalité dupliquée n’est pas apprécié par les mainteneurs. Peut-être, a-t-il dit, serait-il bon de permettre quelques pilotes dupliqués qui ne sont pas destinés à être utilisés, mais seulement comme exemples pour les autres développeurs.
Il y a aussi 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 Christian Brauner a dit 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. Un pilote bientôt ?
Bientôt une branche Rust ?
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.
À partir de là, la conversation a pris plusieurs directions.
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 : LWN
Et vous ?
Je me permets de poster un complément important à ce vieux message que je ne peux plus éditer:
Si cette interdiction est sacrosainte, c'est que c'est un comportement indéfini (UB), et il ne faut surtout pas utiliser ce contournement.
Dans cet exemple précis, le compilateur peut faire de l'optimisation de code en utilisant l'information de mutabilité de la référence, ce qui peut induire des résultats imprédictibles si on a transgressé les règles de mutabilité.
Ces optimisations peuvent être comparées à ce que permet le mot clef `restrict` en C.
En mieux...ou pas !
Répondre avec citation
Partager