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

21PARTAGES

9  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 expérimenté 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
20  3 
Avatar de denisys
Membre chevronné https://www.developpez.com
Le 03/09/2024 à 18:59
Remonté contre les habitués du C qui freinent les mises à jour de la base de code du noyau vers Rust
Pour faire une bonne vinaigrette.
Il faut de l’huile et du vinaigre !!!!


A mon point de vue, ce n’est qu’une question de temps et de génération.
Ma génération, qui a étais élevé au bon code en C et C++, vers la fin du siècle dernier (1992).
Les jeunes et futures générations qui intégrerons et compileront plus facilement le code en Rust.

Moi, quand j’ai commencé à développer, le Java Scripte n’existais pas.
Aujourd’hui, tous les jeunes savent coder en Java Scripte.

Haaa !!!
Il ne faut pas oublier, non plus, que le créateur de PHP a conçu ce langage en C, parce que il en avait marre de répéter les mêmes routines en C, pour construire des pages Internet , a l’époque.

C’est une question de temps, uniquement !!!
14  0 
Avatar de OrthodoxWindows
Membre expert 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...
12  0 
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.
14  4 
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).
11  1 
Avatar de LittleWhite
Responsable 2D/3D/Jeux https://www.developpez.com
Le 22/10/2024 à 18:09
Linus Torvalds est de plus en plus frustré par le matériel bogué et les attaques théoriques du processeur
Moi aussi ! (mais on s'en fout)
9  0 
Avatar de eomer212
Membre confirmé https://www.developpez.com
Le 22/10/2024 à 18:50
je me rappelle d'une époque, l'époque "bénie" (j'étais jeune, beau, et je le suis toujours dans ma tête) ou n'y avait pas de coprocesseur, et ou il fallait comprendre comment calculer un sinus à partir d'entiers en assembleur.
bref, on devait ramer comme des malades pour sortir les processeurs et les cartes graphiques vga de leur létargie. il fallait comprendre le materiel, et en particulier le processeur, son fonctionnement et ses limites. qu'on pouvait éventuellement dépasser, par la ruse et l'intelligence.
une des astuces existantes était le déroulé de code.
on déroule des fonctions qui auraient du faire un saut pour boucler, pour éviter le plus possible les branchements qui brisent la prédiction ou le pré chargement de code du processeur.
c'est con, c'est basique, et c'est très, très efficace.
moi je dis ca. mais bon, je peux me tromper, mais je pense que ca doit encore marcher..
en passant, un petit coucou extrêmement révérencieux à Mr Torvald, à qui nous devons tous beaucoup.
10  1 
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 ?
8  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.
8  0 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 03/09/2024 à 20:00
Cette "mégalomanie" existe dans toutes les équipes qui sont formattés à travailler avec un langage informatique. Vous allez dans les banques où on fait du COBOL, les développeurs rabaisseront ceux qui font du Java pour sa syntaxe, ceux qui font du Java rabaisseront ceux qui font du NodeJS/TypeScript pour son manque de typage runtime, ceux qui font du NodeJS/TypeScript rabaisseront ceux qui font du Python pour ses performances, et généralement tout le monde excepté ceux qui font du PHP rabaisseront PHP

Il faut aller au-delà de cela, de cette passion qui nous anime pour un langage informatique, parce que oui nous avons appris, travaillé et en quelque sorte "grandi" avec un certain langage, et on arrive d'ailleurs à reconnaitre les générations grâce à leur formation universitaire Pascal, C++, Java, et plus récemment Python... Et je comprends aussi que certains en ait marre d'apprendre le dernier langage à la mode (je pense personnellement aux langages JVM tels que Scala complètement mort et Kotlin propulsé par IntelliJ+Google suite au procès d'Oracle en ayant fait du Java), ce qui me perturbe c'est que Rust soit considéré comme une mode ou bien les goûts syntaxiques évoqués par certains pour ne pas adopter le Rust. Rust est basé sur le retour d'expérience des langages existants, il existe des raisons pour laquelle Rust inclu/limite des features, comme pourquoi il n'y a pas d'héritage à plusieurs niveaux, pourquoi on continue à utiliser le point-virgule etc (je ne vais pas rentrer dans les détails ici)

Un langage informatique est un outil, ce n'est pas votre enfant ou votre animal de compagnie, l'affect n'a pas lieu d'être. Il faut citer les "vrais" avantages et inconvénients techniques de Rust pour être juste, Rust n'est pas parfait : moins de libraries contrairement à Go qui est supporté par Google (quelqu'un sait s'il existe un driver Sybase en Rust ? ), lent à compiler etc... mais en tant qu'expert seriez-vous capable de me citer des langages libres (compilateur inclu) qui sont à la fois memory-safe, null-safe, thread-safe et qui ne requirent pas une VM que l'on doit installer et qui doit gérer un système de ramasse-miettes ?

Bref, pour en revenir à Linux, bien que le C soit un langage simple et très apprécié, ce dernier ne respecte pas les critères cités au-dessus (je vous invite à regarder les taux des failles de sécurités causés par l'absence du memory-safe ou null-safe), donc qui maintiendra aussi bien le noyau lorsque Linus Torvalds ne sera plus de ce monde ?
8  0