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 !

Les développeurs semblent d'accord à l'unanimité pour la prise en charge de Rust pour le développement du noyau Linux
Lors de la conférence Linux Plumbers

Le , par Bill Fassinou

267PARTAGES

21  0 
Alors, faut-il aujourd’hui réécrire tout le noyau Linux avec le langage Rust ? Cette discussion ne date pas d’aujourd’hui et s’est accentuée depuis l’apparition de la première version stable de Rust en 2015. Au regard des possibilités offertes par Rust, certains proposent de le faire. Cette année, lors de la conférence Linux Plumbers en août, les intervenants ont, une fois encore, eu le temps d’en discuter. Ils semblent être d'accord à l’unanimité, non pas pour réécrire le code existant en Rust, mais pour que le développement du noyau se poursuive en utilisant Rust. C’est-à-dire qu’ils envisagent un monde où les nouveaux morceaux de codes pourraient être écrits en Rust.

Le langage de programmation Rust a longtemps eu pour objectif de remplacer le C dans le développement du noyau Linux. Au fur et à mesure que Rust a mûri, plusieurs développeurs ont exprimé un intérêt croissant pour son utilisation dans le noyau Linux. Lors de la conférence virtuelle Linux Plumbers de 2020, le volet de la microconférence LLVM a organisé une session sur les questions ouvertes et les obstacles à l'acceptation de Rust en amont dans le noyau Linux. L'intérêt pour ce sujet est visible, car cette session a été la plus suivie de l'événement 2020.

Cette session s'est appuyée sur les travaux antérieurs de nombreux développeurs, notamment une conférence donnée l'année passée par Alex Gaynor et Geoffrey Thomas lors du sommet sur la sécurité de Linux. Lors de la conférence, ils ont présenté leur travail de prototypage des modules du noyau Rust et ont plaidé pour l'adoption de Rust dans le noyau. Ils ont cité des travaux qui montrent qu'environ deux tiers des vulnérabilités du noyau auxquelles ont été attribués des CVE dans Android et Ubuntu sont toutes liées à des problèmes de sécurité de la mémoire.

Ils ont fini en expliquant que Rust peut complètement éviter cette classe d'erreur grâce à des API plus sûres activées par son type de système et son vérificateur d'emprunt. Cette étude a réussi à convaincre plusieurs mainteneurs, et Linus Torvalds, qui ont donné leur aval à l'introduction de Rust dans le noyau. Thomas et Gaynor, Josh Triplett, coresponsable de l'équipe du langage Rust et développeur de longue date du noyau Linux, ainsi qu'un certain nombre d'autres développeurs intéressés, ont participé à la discussion sur le sujet.

Ils ont brièvement évoqué leur travail jusqu'à présent et certaines de leurs premières réflexions et questions avant d'ouvrir la majeure partie du temps à la discussion. Ils ont donné un bref exemple de ce à quoi pourrait ressembler le code Rust en mode noyau. Les participants ont souligné qu'ils ne proposent pas de réécrire le noyau Linux entier en Rust ; ils se concentrent uniquement sur l'évolution vers un monde où un nouveau code pourrait être écrit en Rust. La discussion qui a suivi s'est concentrée sur trois domaines de préoccupation potentielle pour le support de Rust.


Il s’agit de l’utilisation des API existantes dans le noyau, le support de l'architecture et une question sur la compatibilité ABI entre Rust et C. En effet, ils estiment dans un premier temps que l’introduction de Rust dans l’arborescence doit obligatoirement respecter les API C existantes. Selon eux, pour être utile au développement du noyau, il ne suffit pas que Rust soit capable de générer du code pouvant être lié au noyau ; il faut aussi que Rust puisse accéder au grand nombre d'API utilisées dans le noyau Linux, qui sont toutes actuellement définies dans des fichiers d'en-tête C.

Rust dispose d'un bon support pour l'interopérabilité avec le code C, y compris pour l'appel de fonctions utilisant l'ABI C et pour la définition de fonctions avec des ABI compatibles C qui peuvent être appelées depuis le C. De plus, l'outil bindgen est capable d'analyser les fichiers d'en-tête C pour produire les déclarations Rust appropriées, de sorte que Rust n'a pas besoin de dupliquer les définitions du C, ce qui permet aussi de vérifier le type de langage. En apparence, ces caractéristiques font que Rust est bien équipé pour s'intégrer aux API C existantes.

Cependant, tous estiment que le diable est dans les détails, et tant le travail effectué jusqu'à présent que la conversation lors de la session ont révélé quelques défis ouverts. Par exemple, Linux fait un usage intensif des macros de préprocesseur et des fonctions en ligne, qui ne sont pas aussi facilement prises en charge par l’outil bindgen et l'interface de fonctions étrangères de Rust. Les intervenants ont également relevé d’autres détails qui méritent une attention particulière. Dans un second temps, Rust doit prendre en charge l’architecture existante.

Selon eux, actuellement, l’unique implémentation Rust mature est le compilateur rustc, qui émet du code via LLVM. Le noyau Linux prend en charge un large éventail d'architectures, dont plusieurs n'ont pas de backend LLVM disponible. Pour quelques autres, un backend LLVM existe, mais rustc ne le supporte pas encore. Les présentateurs ont voulu comprendre si la prise en charge complète de l'architecture était un obstacle à l'activation de Rust dans le noyau Linux. Et dans ce cas, comment Rust peut-il alors résoudre le problème ?

Beaucoup ont proposé d'implémenter dans Rust des pilotes qui ne seraient jamais utilisés sur les architectures les plus obscures. De son côté, Triplett a suggéré que l'ajout de Rust dans le noyau aiderait à augmenter la prise en charge de l'architecture pour Rust, en citant son expérience avec le projet Debian. Il a mentionné que l'introduction du logiciel Rust dans Debian a aidé à motiver les enthousiastes et les utilisateurs d'architectures de niche à améliorer le support de Rust, et il s'attend à ce que l'ajout du support au noyau ait un effet similaire.

En particulier, il était convaincu que toute architecture avec un backend LLVM serait rapidement supportée par Rust. La discussion a aussi porté sur les implémentations alternatives de Rust comme une voie vers un support plus large de l'architecture. Par exemple, le projet mrustc est un compilateur Rust expérimental qui émet du code C. Son utilisation peut potentiellement permettre à Rust d'être compilé via le même compilateur C que celui qui compile le reste du noyau. En outre, Triplett a fait part de son intérêt et de son travail pour un frontal Rust pour GCC.

Cela peut permettre à Rust de cibler toutes les architectures prises en charge par GCC. Ce projet n'en est qu'à ses débuts, mais il représente une voie pour combler le fossé de l'architecture à l'avenir. La conclusion de cette section est un peu incertaine, mais il ne semble pas y avoir de forte opposition à l'idée de soutenir les pilotes de périphériques Rust sans attendre une prise en charge plus large de l'architecture. Enfin, le dernier volet auquel Rust doit répondre pour être utilisé dans le code Linux est la compatibilité de l'ABI avec le noyau.

En fait, puisque Rust est (actuellement) compilé via LLVM, et que le noyau est le plus souvent construit avec GCC, lier le code de Rust dans le noyau peut signifier mélanger le code émis par GCC et LLVM. Même si LLVM vise à être compatible ABI avec GCC, il y a eu un certain retour de bâton en raison des craintes que cette façon de faire ne crée un risque d'incompatibilité ABI subtile. Les participants à la discussion se sont demandé si la communauté des noyaux ne préférait pas limiter le support de Rust aux noyaux construits avec Clang afin d'assurer la compatibilité.

Selon Greg Kroah-Hartman, un autre participant à la discussion, la règle actuelle du noyau est que la compatibilité n'est garantie que si tous les fichiers objet du noyau sont construits avec le même compilateur, en utilisant des drapeaux identiques. Cependant, il s'est également déclaré favorable à la liaison des objets Rust construits par LLVM dans un noyau construit par GCC, à condition que les objets soient construits en même temps, avec les options appropriées définies, et que les configurations résultantes soient entièrement testées.

Florian Weimer, un autre participant à vidéoconférence, a précisé que les questions relatives à l'ABI ont tendance à se situer dans des coins obscurs du langage, par exemple renvoyer une structure contenant un champ binaire par valeur. Cela dit, Triplett a souligné que les appels entre GCC et Rust étaient routiniers et très répandus dans l'espace utilisateur, et que du côté de Rust, il n'a donc aucun problème de compatibilité. Il semble que cette préoccupation ne devrait pas, en fin de compte, être un obstacle à l'introduction de Rust dans le noyau.

La session s'est terminée sans autre étape spécifique, mais il semble que, dans l'ensemble, il y ait un enthousiasme pour soutenir les modules Rust et un accord croissant sur les exigences générales de ce soutien. La prochaine grande étape sera probablement lorsque quelqu'un proposera un véritable pilote Rust à inclure dans le noyau. Un cas d'utilisation concret et une mise en œuvre contribuent toujours à forcer la clarté sur les questions litigieuses restantes et les décisions de conception.

Source : LWN.net

Et vous ?

Quel est votre avis sur le sujet ?
Êtes-vous d'avis pour le développement du noyau de Linux en Rust ? Pourquoi ?
Selon vous, devrait-on reprendre tout le noyau en Rust ? Pourquoi ?

Voir aussi

L'année 2020 est-elle celle de Rust au sein du noyau Linux ? C'est ce que suggère une sortie de Linus Torvalds qui donne des instructions sur l'introduction de son support au système de build

« 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

Rust : les développeurs révèlent pourquoi ils ne sont pas plus nombreux à utiliser le langage de programmation, en pointant du doigt un manque d'adoption en entreprise, d'après un sondage

Le langage Rust est la meilleure chance offerte à l'industrie informatique pour la mise sur pied d'applications système sécurisées, d'après Microsoft

« Rust est le futur de la programmation système et C le nouvel assembleur », d'après un ingénieur d'Intel qui explique pourquoi il est pertinent de passer à Rust

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

Avatar de N_BaH
Modérateur https://www.developpez.com
Le 03/09/2020 à 16:33
Selon [les intervenants], actuellement, l’unique implémentation Rust mature est le compilateur rustc, qui émet du code via LLVM. Le noyau Linux prend en charge un large éventail d'architectures, dont plusieurs n'ont pas de backend LLVM disponible
voilà, voilà.

comme vu ailleurs, Rust n'a que 5 ans; c'est peut-être un peu jeune pour un projet de l'ampleur du noyau Linux ?
4  0 
Avatar de N_BaH
Modérateur https://www.developpez.com
Le 03/09/2020 à 18:08
exactement, n'importe quoi. Tu pourrais te renseigner pour argumenter.
Rust est un langage de programmation développé principalement par Mozilla. La première version stable, la 1.0, est sortie en 2015
3  0 
Avatar de barmic
Membre actif https://www.developpez.com
Le 05/09/2020 à 18:02
Citation Envoyé par N_BaH Voir le message
alors, ils ne seraient pas tentés de développer en Rust, parce que... ? c'est un langage récent, qui n'a pas toutes les "interfaces" nécessaires ?!
Ils font bien ce qu'ils veulent. Remonte le fil de discussion. Je dis juste que la possibilité d'utiliser rust pour écrire des drivers linux n'implique pas que la NASA se retrouve avec du rust sur leurs engins. Ils choisiront de s'y mettre quand ils voudront.
3  0 
Avatar de N_BaH
Modérateur https://www.developpez.com
Le 03/09/2020 à 17:10
il me semble que la NASA utilise Linux.
3  1 
Avatar de barmic
Membre actif https://www.developpez.com
Le 03/09/2020 à 19:29
Citation Envoyé par N_BaH Voir le message
il me semble que la NASA utilise Linux.
Oui mais elle n'utilise pas le driver que tu as codé dimanche dernier. De ce que je comprends de l'article il est question uniquement de driver.

Mais surtout, l'utilisation d'un langage dans un noyau a ça de particulier que c'est du code sans dépendance il me semble. Tu ne te lie pas avec une bibliothèque extérieure. Donc les éventuels bugs de la bibliothèque standard de rust ne les concernent pas.

Pour que rust lui-même produise un bug, il faut :

- soit qu'il y a un bug dans le compilateur : c'est toujours possible, mais là il n'y a que le frontend rust qui est nouveau tout le reste est déjà utilisé par linux :
- soit que l'interfaçage avec le reste du code se passe mal et c'est de ça dont ils parlent avoir une ABI compatible.

Je ne vois pas d'autres cas et quoi qu'il arrive dans le pire cas c'est un nouveau driver qui aura un problème.

En soit, j'ai du mal à imaginer des développeurs comme Linus ou GKH comme étant touchés par la hype. Ils ont envoyé bouler pendant 20 ans le C++ et on un caractère qui fait qu'on ne les forcera pas à intégrer quelque chose s'ils ne pensent pas réellement que ça va le faire.
2  0 
Avatar de Mimoza
Membre averti https://www.developpez.com
Le 03/09/2020 à 16:54
Pourquoi se priver de quelque chose qui répond a une problématique spécifique (fuite mémoire).
On est pas dans l'aéronautique/spacial, si un soucis est détecté il y aura rapidement un correctif ou un retour arrière au pire. L'adoption de Rust par Linux est un signal fort pour que justement son support soit plus rapidement fait.
3  2 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 03/09/2020 à 18:32
Rust est très prometteur, mais il y a certains concepts natifs au langage tels que les lifetimes explicites qui me paraissent superflu car le compilateur devrait en théorie pouvoir gérer cela implicitement.
1  0 
Avatar de N_BaH
Modérateur https://www.developpez.com
Le 03/09/2020 à 20:24
Oui mais elle n'utilise pas le driver que tu as codé dimanche dernier. De ce que je comprends de l'article il est question uniquement de driver.
la NASA et moi n'avons pas les mêmes périphériques à piloter.
je n'ai pas de canadarm, moi, mais eux en ont un, qu'ils doivent piloter avec un driver (non?), et ce n'est qu'un de leurs "joujoux".
1  1 
Avatar de Steinvikel
Membre expert https://www.developpez.com
Le 04/09/2020 à 12:48
Tous les équipements de la NASA ne sont pas des vielleries de 30 ans... ils renouvellent également leur parc, leurs outils, et utilisent sans cesse des outils de remplacement soit plus spécialisés, soit plus polyvalents.
Tout ceci ne requiert-il pas des pilotes récents ?
0  0 
Avatar de barmic
Membre actif https://www.developpez.com
Le 05/09/2020 à 8:40
Ce n'est pas une question d'âge. Ils ont le contrôle total sur les drivers qu'ils utilisent, soit parce qu'ils les développent eux-même, soit parce qu'ils ont un cahier des charges sur ce qu'ils acceptent ou non. Les machines critiques n'utilisent probablement pas de matériel grand public, comme elles n'ont pas installation d'ubuntu 20.4 par exemple.
0  0