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 !

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

Le , par Bruno

8PARTAGES

8  0 
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
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
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
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
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

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

Avatar de Ti-Slackeux
Membre éprouvé https://www.developpez.com
Le 02/04/2024 à 11:35
je me suis arrêté là :
Faut-il opérer le retrait de termes comme master ou slave au motif de ce qu’ils véhiculent des stéréotypes raciaux ?
"Deux choses sont infinies : l'Univers et la bêtise humaine.
Mais, en ce qui concerne l'Univers, je n'en ai pas encore acquis la certitude absolue."
Albert Einstein
18  2 
Avatar de OrthodoxWindows
Membre émérite https://www.developpez.com
Le 02/04/2024 à 12:03
Citation Envoyé par Ti-Slackeux Voir le message
je me suis arrêté là :

"Deux choses sont infinies : l'Univers et la bêtise humaine.
Mais, en ce qui concerne l'Univers, je n'en ai pas encore acquis la certitude absolue."
Albert Einstein
Je suis d'accord, ce débat est vraiment con. Mais bon, visiblement certains n'ont pas mieux à faire que perdre du temps au lien de réaliser des vrais corrections dans le code.
Cependant, ce genre de polémique stérile est souvent soutenu pas des grosses entreprises ; peut-être faut-il y voir un intérêt pour détourner l'attention de leur méfaits.
Parfois c'est plus direct, c'est le logiciel libre qui est visé (je pense à la polémique sur Stallman).

C'est comme ceux qui sont contre l'utilisation des termes "liste noir/blanche". Alors que culturellement, associer le noir au "mal" ou a la mort n'a rien de raciste, c'est quelque chose de très ancien qui vient du fait que sans lumière, on ne voit rien (on risque donc sa vie). Je ne serai pas surpris que certains peuples en Afrique fassent la même association.
Comparer ça au racisme c'est à peu près la même logique que de dire qu'utiliser la couleur orange pour indiquer un chantier revient à traiter tous les roux de travailleur du BTP
Surtout qu'en plus, aucun homme n'est vraiment "noir" sur Terre, en réalité, il n'y a que des nuances de brun...
11  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 02/04/2024 à 20:03
Comme si ne plus utiliser les termes maitres/esclaves allait faire disparaitre l'esclavage ou rendre justice aux victimes présentes, passés, ou futurs.

On peut aller très loin dans la connerie :

Nous tous (ou quasiment) travaillant dans l'informatique sommes des prestataires de services.
service désigne l'action de servir, càd être au service, à la disposition de quelqu'un. Du coup faut-il remettre ce terme en question dans ce contexte, surtout que service vient du latin servitium signifiant état d’esclave, cervitude).
10  1 
Avatar de Aspartame
Membre confirmé https://www.developpez.com
Le 02/04/2024 à 13:08
Bonjour

étudiant en master, je m'inquiète sérieusement sur mon diplôme.
12  4 
Avatar de yannoo95170
Membre régulier https://www.developpez.com
Le 17/10/2022 à 23:49
« 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 ?
7  0 
Avatar de petitours
Membre chevronné https://www.developpez.com
Le 02/04/2024 à 17:02
Citation Envoyé par shunesburg69 Voir le message
L'esclavage s'est terminé en France en 1848 et aux USA en 1865, je vois personne de vivant concerné par cette histoire d'esclavage. Pour info, la plupart du temps c'est des militants (noir ou blanc) qui non jamais eux de famille dans l'esclavage et qui oublient que des blancs comme moi ont des ancêtres esclaves et qui s'en foutent de ses débats stériles. Ils feraient mieux de s’inquiéter de la discrimination positive (et autre racisme anti-blanc) qui font du racisme en passant faire l'inverse.
Inde, Chine (les Ouïghours ), Pakistan, et bien d'autres pays. L'esclavage existe bien encore aujourd'hui. Mais une fois de plus le problème est l'esclavage, pas le mot qui le désigne très bien et ça n'a rien à faire dans les discussions sur l'intégration de Rust dans Linux.
6  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 16/10/2022 à 8:03
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.
5  0 
Avatar de smarties
Expert confirmé https://www.developpez.com
Le 20/11/2022 à 11:20
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.
5  0 
Avatar de petitours
Membre chevronné https://www.developpez.com
Le 02/04/2024 à 16:29
Citation Envoyé par Stéphane le calme Voir le message
« Il est clair que certaines personnes sont blessées par ces termes et que leur utilisation suscite chez elles un sentiment de malaise, non pas pour des raisons techniques, mais en raison de leur contexte historique et social », a déclaré Google, en estimant qu'il s'agissait d'arguments suffisants pour les faire disparaître. « Master-slave est une métaphore oppressive qui ne sera et devrait jamais être totalement détachée de notre histoire », souligne un développeur de Microsoft, qui appelle à leur remplacement.
"Maitres" et "esclave" ont un sens très clair, il se trouve que ce sens désigne très bien des choses affreuses qui se sont produites et qui se produisent encore. Le malaise concerne la situation qui est décrite par ces termes parfaitement adaptés, pas par les termes eux même. "Malaise" est bien a l'image de ce débat de vocabulaire stupide ; je doute que les gens concernés par cette horreur soient "blessés" ou "mal à l'aise", ils souffrent sûrement, ils sont en colère peut être mais certainement pas "mal à l'aise" !

Pour revenir au sujet du code, ces gens peuvent aussi sans malaise utiliser ces 2 termes parfaitement adaptés a certains modèles de communication. Et en plus personne ne souffre et personne n'est opprimé dans ces usages informatiques des mots.
J'espère que Linus Torvalds, prompt a envoyer balader les mauvais, remettra rapidement en place ces gens qui veulent se rendre intéressant en massacrant le vocabulaire et donc la fameuse clarté.

"Le Schtroumpf n'a pas besoin de se prendre le Schtroumpf concernant le Schtroumpf pour faire Schtroumpfer le Schtroumpf" Comprend qui peut, mais c'est ça de tuer le vocabulaire.

Pour le reste les questions sont trop dispersées. Il y a des questions super pertinentes sur Rust et Linux suivies de ce sujet inepte de destruction du vocabulaire qui en aucun cas améliorera l'inclusion et la diversité de qui que ce soit.
5  0 
Avatar de pokap
Membre régulier https://www.developpez.com
Le 02/04/2024 à 13:03
Citation Envoyé par Ti-Slackeux Voir le message
je me suis arrêté là :

"Deux choses sont infinies : l'Univers et la bêtise humaine.
Mais, en ce qui concerne l'Univers, je n'en ai pas encore acquis la certitude absolue."
Albert Einstein
“Celui qui ressent sa propre vie et celle des autres comme dénuées de sens est fondamentalement malheureux, puisqu'il n'a aucune raison de vivre.”
Albert Einstein
4  0