IdentifiantMot de passe
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 !

Linus Torvalds se prépare à faire passer le noyau Linux au C moderne (C11)
Dans un contexte où le langage Rust apparaît de plus en plus comme candidat idéal à la mise au rebut du langage C

Le , par Patrick Ruiz
24 commentaires

152PARTAGES

17  1 
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. Linus Torvalds s’est penché il y a peu sur un potentiel problème de sécurité avec les fonctions primitives d'exécution spéculative de la liste liée du noyau écrit en ANSI C. C’est en corrigeant ce problème qu’il s’est rendu compte qu’en C99 l'itérateur passé aux macros de parcours de liste doit être déclaré dans une portée en dehors de la boucle elle-même. C’est de constat que vient sa décision de faire passer le noyau Linux au C moderne (C11) dont la normalisation est achevée en 2011. La nouvelle tombe dans un contexte où le langage Rust apparaît comme candidat idéal à la mise au rebut du C.

Arnd Bergmann, développeur du noyau Linux, est d’avis que la manœuvre est réalisable. L’idée est bonne selon ce dernier étant donné que C99 n'a jamais été très populaire et que C11 a introduit le support standardisé du multithreading et a rendu le langage un peu plus sûr. GCC 5.1 est disponible depuis 2015 avec le support complet des standards C++ 11 et C++14. Cet état de choses ouvre la possibilité de voir la version 5.18 du noyau sortir avec prise en charge du C moderne.


La nouvelle arrive dans un contexte où le regard de Linus Torvalds sur le langage Rust a changé. En effet, la prise en charge de Rust pour le développement du noyau Linux commence à prendre forme et est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

Et vous ?

Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ? Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents

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

24 commentaires
Commenter Signaler un problème
KiLVaiDeN
Avatar de KiLVaiDeN
Membre expert https://www.developpez.com
Le 27/02/2022 à 10:00
Je trouve le débat sur la réécriture du noyau Linux en Rust un peu trop "optimiste". Rust n'est pas aussi mature en terme d'options de compilation, de vitesse de compilation, et sa "sécurité" est un frein plus qu'une feature pour du code kernel où il est nécessaire de faire des opérations dites "unsafe". Il faut voir que le C est le langage le plus proche de la machine, à part l'assembleur bien entendu, et il est choisi pour sa portabilité. Si il existait un assembleur aussi portable que du C, le noyau serait probablement écrit dans cet assembleur. Car le but c'est d'avoir un code rapide et efficace, permettant d'exploiter un maximum de possibilités des machines visées. Le fait que chaque CPU a son propre jeu d'instruction fait que le C est une bonne virtualisation, et c'est le rôle des compilateurs de produire le code optimisé pour la machine cible. Et C, de ce côté là, est doté d'un arsenal que Rust n'a pas encore.

Donc oui, Rust a des avantages sur C pour la programmation de tous les jours, par les protections qu'il apporte notamment qui évite certains bugs, mais Rust est encore bien moins équipé en termes d'outils que C pour la compilation de noyau. J'ai l'impression que pas mal de personnes se disent que Rust est forcément "mieux" que C parce qu'il est plus récent et moderne, mais la finalité c'est de produire un code optimisé et correcte, ce qui est possible en C, preuve en est justement le kernel Linux qui est utilisé par des millions de machines tous les jours et qui fournit très peu de bugs. (précision là-dessus, quand j'entend "très peu de bugs" veuillez comprendre "en moyenne pour un code aussi utilisé et déployé"

Le C a encore de longues années devant lui pour ces raisons. Et même si un jour Rust devenait aussi équipé que C en termes d'outils, même si son mode "unsafe" était aussi accessible que celui du C, il faudrait une raison valable pour entamer une telle réécriture, et pour l'instant j'ai du mal à en voir une, car si la raison évoquée est d'avoir accès à un langage plus "sûr", qui serait donc sensé compenser les erreurs des programmeurs, je trouve cette raison regrettable. La seule raison serait pour moi d'avoir un code tout aussi robuste et optimisé, tout en fournissant accès à des structures de données et un langage plus évolué, là oui, on pourrait alors imaginer avoir un code Linux plus "parlant", et ce serait une bien meilleure raison.
24  3 
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 27/02/2022 à 17:44
Citation Envoyé par KiLVaiDeN Voir le message
Je trouve le débat sur la réécriture du noyau Linux en Rust un peu trop "optimiste".

C'est surtout qu'il n'y a pas de débat. Il n'y a aucun plan qui prévoit de réécrire le noyau Linux en Rust. La seule chose qui est prévue, c'est de permettre d'écrire des modules (en gros des drivers) en Rust.

Citation Envoyé par KiLVaiDeN Voir le message
Rust n'est pas aussi mature en terme d'options de compilation, de vitesse de compilation, et sa "sécurité" est un frein plus qu'une feature pour du code kernel où il est nécessaire de faire des opérations dites "unsafe". Il faut voir que le C est le langage le plus proche de la machine, à part l'assembleur bien entendu, et il est choisi pour sa portabilité.

Au niveau de la vitesse de compilation, c'est vrai que le Rust est plus lent que le C, mais dans le cadre du développement d'un noyau, je ne pense pas que ça soit le plus gros problème.
Par contre, le compilateur Rust se base sur le backend LLVM qui sert de base à clang. Il a donc quasiment les mêmes options de compilation que le C ou C++.
Enfin, le coté sécurité de Rust ne pose pas de problème pour le bas niveau, au contraire. Rust permet de faire des blocs unsafe pour isoler les sections qui ont réellement besoin de faire des accès directs au matériel tout en gardant une grosse partie du code safe. Ça reste un gros avantage comparé a C qui est potentiellement dangereux partout.

Citation Envoyé par KiLVaiDeN Voir le message
Si il existait un assembleur aussi portable que du C, le noyau serait probablement écrit dans cet assembleur.
Ça n'a pas de sens de parler d'assembleur portable. L'assembleur est par définition l'inverse du langage portable : c'est juste une représentation textuelle du code machine. En fait il faudrait parler des langages d'assemblage, vu qu'il y en a au moins un différent pour chaque architecture, et en fait, même sur une même architecture, il peut y avoir plusieurs syntaxes différentes.
De plus même s'il n'existait qu'une seule architecture et un seul langage d'assemblage, le kernel ne serait probablement pas codé avec. L'assembleur est langage un langage bien trop complexe et verbeux pour être pratique a utiliser de manière généralisée. Un bon langage avec un compilateur efficace, de la structuration des données, une bonne lisibilité, ... ça offre de gros avantages, particulièrement en matière de maintenabilité, ce qui est aussi un point crucial pour un kernel.

Citation Envoyé par KiLVaiDeN Voir le message
Car le but c'est d'avoir un code rapide et efficace, permettant d'exploiter un maximum de possibilités des machines visées. Le fait que chaque CPU a son propre jeu d'instruction fait que le C est une bonne virtualisation, et c'est le rôle des compilateurs de produire le code optimisé pour la machine cible. Et C, de ce côté là, est doté d'un arsenal que Rust n'a pas encore.
Rust a, à peu près, le même arsenal que le C vu qu'il s'appuie actuellement sur LLVM, un des meilleurs backend de compilateur qui sert de notamment de base au compilateur C clang. Le code qu'il génère est généralement au même niveau de performance que du code C similaire. La seule limite est que LLVM gère mois d'architectures que GCC, donc Rust est plus limité sur ce point. Mais les principales architectures actuelles (x86, x86_64, ARM, ARM64, mips, powerpc, riscv,...) sont quand même gérées, et ça devrait encore s'améliorer avec l'arrivée prévue du backend GCC.

Citation Envoyé par KiLVaiDeN Voir le message
J'ai l'impression que pas mal de personnes se disent que Rust est forcément "mieux" que C parce qu'il est plus récent et moderne, mais la finalité c'est de produire un code optimisé et correcte, ce qui est possible en C, preuve en est justement le kernel Linux qui est utilisé par des millions de machines tous les jours et qui fournit très peu de bugs. (précision là-dessus, quand j'entend "très peu de bugs" veuillez comprendre "en moyenne pour un code aussi utilisé et déployé"
Vu qu'il y a pas de point de comparaison, ça n'a pas vraiment de sens de dire que le langage C fournit très peu de bugs.

Citation Envoyé par KiLVaiDeN Voir le message
Le C a encore de longues années devant lui pour ces raisons.
C a de longes années devant lui, mais certainement pas pour ces raisons. Il a de bonnes années devant lui car c'est une référence dans le bas niveau et qu'il est présent partout. On ne va pas réécrire un code qui fonctionne en un autre langage sans de très bonnes raisons et la sécurité supplémentaire, n'est généralement pas un argument suffisant. Et même si tout le monde était convaincu qu'il faut d'urgence faire disparaitre le C de partout , ça prendrait quand même des dizaines d'années de le remplacer totalement.

Citation Envoyé par KiLVaiDeN Voir le message
Et même si un jour Rust devenait aussi équipé que C en termes d'outils, même si son mode "unsafe" était aussi accessible que celui du C, il faudrait une raison valable pour entamer une telle réécriture, et pour l'instant j'ai du mal à en voir une, car si la raison évoquée est d'avoir accès à un langage plus "sûr", qui serait donc sensé compenser les erreurs des programmeurs, je trouve cette raison regrettable. La seule raison serait pour moi d'avoir un code tout aussi robuste et optimisé, tout en fournissant accès à des structures de données et un langage plus évolué, là oui, on pourrait alors imaginer avoir un code Linux plus "parlant", et ce serait une bien meilleure raison.
En soit les fonctionnalité unsafe de Rust sont tout aussi utilisable que le C. Elle sont plus verbeuses a utiliser, mais c'est voulu : les opérations "unsafe" doivent être explicites pour être sur qu'on ne les utilise pas par inadvertance comme malheureusement bien souvent en C.
Et Rust ne se limite bien sur pas à la sécurité. Le fait d'offrir un langage évolué avec entre autre des structures de données plus avancés, fait bien entendu partie des raisons essentielles d'utiliser Rust.

Citation Envoyé par chrtophe Voir le message
De ce que j'ai compris, Les blocs de codes unsafe donnent des "superpouvoirs", peut-être nécessaire pour faire de la programmation système, et on en revient au prob. du C.

Mais peut-être qu'avec Rust, un développeur débutant pourra peut-être générer du code moins dangereux, en dehors de code bas niveau qui n'est en général pas fait par un débutant.
La grosse différence, c'est que Rust est safe par défaut alors que C est unsafe par défaut. En Rust on ne peut pas faire d'opération "unsafe" par inadvertance, alors qu'en C ça finit fatalement par arriver, même aux développeurs chevronnés. Certes quand on utilise un bloc unsafe, on met la sécurité du code en jeu, mais le principe de faire ça dans un bloc, c'est que le code à risque est bien contenu dans des sections réduites, auxquelles on sait qu'il faudra porter une attention particulière. Elles sont clairement identifiées et donc bien plus faciles à vérifier.
17  0 
gzii69
Avatar de gzii69
Membre régulier https://www.developpez.com
Le 27/02/2022 à 10:44
D'un côté je suis d'accord que le Rust doit encore mûrir, et que tout réécrire n'est sans doute pas possible (c'est plutôt quelque-chose qui se ferait petit à petit avec de nouvelles fonctionnalités).

De l'autre dire qu'il suffit de ne pas faire d'erreur ? On en fait tous, une faute d'inattention, un cas auquel on n'aurait pas pensé. Et réfléchir une nième fois parce que le compilateur refuse une façon de faire qui pourrait être unsafe, c'est pas forcément mauvais (surtout quand les messages sont clairs).
C'est comme pour les tests. Sont ils inutiles ? Faut-il considérer qu'ils ne sont valables que pour les débutants ?

Et en plus de ce que j'ai pu tester, j'obtiens des perfs vraiment équivalentes à celles du C, avec une grande stabilité en multithread et utilisation intensive avec plein de connexions et mémoire partagée (une plus grande stabilité que celle que j'aurais obtenu en C surtout avec un code si jeune). Et je suis plutôt débutant en Rust.
Bref à mon avis non le C ne va pas disparaitre comme ça, c'est sûr, mais c'est sympa de s'intéresser au Rust et de le tester.
Et plus si affinités (souvent il y en a, on n'est pas si éloignés de la machine par rapport au C si on en a fait).
7  0 
SofEvans
Avatar de SofEvans
Membre émérite https://www.developpez.com
Le 28/02/2022 à 9:29
Citation Envoyé par chrtophe  Voir le message
code réentrant avec goto ? comment tu libère l'espace sur la pile pour les variables de ta fonction réentrante si tu en sors avec goto ?

Je ne sais pas si j'ai bien compris, mais j'ai l'impression que tu confonds "goto" et "setjmp".
goto ne permet que de faire un saut local à la fonction, donc toutes les variables de la pile seront nettoyées.

Citation Envoyé par chrtophe  Voir le message
Je suis pas spécialiste développeur mais le seul usage pertinent à l'utilisation de goto est de sortir rapidement de boucles imbriquées.

Ah je dirais que non ^^
Pour ma part, le seul usage pertinent, c'est de faire une sorte de gestion d'exception :

Code C : Sélectionner tout 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
bool MyFunction(void) 
{ 
    char *logPathfile = NULL; 
    FILE *logFile = NULL; 
    char *msg = NULL; 
    bool returnValue = false; 
  
    logPathfile = malloc(...); 
    if (!logPathfile) { 
        // Message erreur 
        goto END_FUNCTION; 
    } 
  
    logFile = fopen(logPathfile, "w"); 
    if (!logFile) { 
        // Message erreur 
        goto END_FUNCTION; 
    } 
  
    msg = malloc(...); 
    if (!msg) { 
        // Message erreur 
        goto END_FUNCTION; 
    } 
  
  
  
    /* .. le reste du code, avec possiblement d autres tests */ 
  
  
  
  
    // Fin de la fonction 
    returnValue = true; 
  
    /* GOTO */END_FUNCTION: 
    free(logPathfile); 
    if (logFile) { 
        fclose(logFile); 
    } 
    free(msg); 
  
    return returnValue; 
}

Ainsi, de cette manière, tu peux être assuré de ne pas faire de fuite de mémoire quelque soit l'endroit où le code échoue, et l'ajout d'autres variables à nettoyer se fait simplement, même si la fonction est longue.

Le fait de sortir d'une double boucle, c'est vrai que c'est pratique, mais c'est une pente vraiment glissante.
En théorie, il vaut mieux mettre la boucle interieur dans une fonction et faire un break dans la première boucle si la fonction retourne un code erreur.
Mais bon, ca c'est la théorie.
7  0 
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 28/02/2022 à 17:49
Citation Envoyé par JPLAROCHE Voir le message
Non aujourd'hui et encore plus demain « Linux » sera et est un système fiable, alors le langage "C" peut-être fiable. Ça ne remet pas en cause "Rust" ce serait idiot...
Ce n'est pas parce qu'un funambule est capable de traverser un précipice en marchant sur un câble que l'on peut conclure que ça peut-être une façon fiable de traverser. Même si Linux était parfaitement fiable (ce qui n'est pas le cas) ça ne voudrait pas pour autant dire que le langage dans lequel il a été écrit l'est.

L'histoire a montré que aucun langage n'est parfaitement fiable a l'usage, pas même le Rust ou l'Ada, et que le C l'est clairement moins que la moyenne. Il ne s'agit pas de remettre en cause son intérêt, mais d'être conscient de ses limites. Le C est encore la pour longtemps et Linux n'est pas prêt de le remplacer en tant que langage principal.
7  1 
chrtophe
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 27/02/2022 à 10:02
Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
Je pense que oui.

De ce que j'ai compris de Rust, il met par défaut certains gardes fous avec par exemple l'immuabilité d'une variable (une variable ne peut être affectée qu'une fois sans le mot-clé mut pour mutable). si ça emmerde un développeur et qu'il déroge par défaut à ce type de garde-fou par convenance, donc une mauvaise pratique, on en revient au même prob. qu'avec le C.

De ce que j'ai compris, Les blocs de codes unsafe donnent des "superpouvoirs", peut-être nécessaire pour faire de la programmation système, et on en revient au prob. du C.

Mais peut-être qu'avec Rust, un développeur débutant pourra peut-être générer du code moins dangereux, en dehors de code bas niveau qui n'est en général pas fait par un débutant.
6  1 
chrtophe
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 28/02/2022 à 6:57
code réentrant avec goto ? comment tu libère l'espace sur la pile pour les variables de ta fonction réentrante si tu en sors avec goto ?

Je suis pas spécialiste développeur mais le seul usage pertinent à l'utilisation de goto est de sortir rapidement de boucles imbriquées. Mais je pense que le compilateur sera tout aussi capable de le faire efficacement sans goto.

Mal utilisé, tu crées un code spaghetti.

Pour en revenir à Rust, si 90% du code d'un pilote est en mode unsafe (par obligation ou convenance du développeur), il n'y a pas plus trop d’aventage à l'utiliser.
4  0 
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 28/02/2022 à 7:21
Citation Envoyé par chrtophe Voir le message
Pour en revenir à Rust, si 90% du code d'un pilote est en mode unsafe (par obligation ou convenance du développeur), il n'y a pas plus trop d’aventage à l'utiliser.
Si c'était le cas en effet Rust perdrait son intérêt, mais la pratique a démontré que même le code des applications les plus dépendantes du système, comme les OS ou les drivers, reste en très grande majorité constitué de code "safe".
En fait les seul projets qui sont majoritairement constitués de code unsafe, c'est les wrapper pour les bibliothèques écrites en un autre langage vu que le compilateur Rust ne peut pas garantir lui même leur sécurité.
4  0 
onilink_
Avatar de onilink_
Membre émérite https://www.developpez.com
Le 28/02/2022 à 11:12
Citation Envoyé par KiLVaiDeN Voir le message
Si il existait un assembleur aussi portable que du C, le noyau serait probablement écrit dans cet assembleur.
Y a l'IR LLVM qui est assez proche de ça. Mais les compilateurs font presque toujours un meilleur travail que les devs pour produire de l'assembleur pour des architectures modernes. Sans parler de la relecture du code, donc la maintenabilité, la productivité etc...

Je pense que l'assembleur plus rapide qu'un langage "haut niveau" ce n'est juste plus d'actualité.
C'était vrai a l'époque ou les CPU étaient tellement "basiques" et les ressources tellement limitées qu'en fait il était difficilement envisageable d'écrire en autre chose que l'assembleur de l'architecture visée.

Mais maintenant nos CPU sont tellement complexes qu'on ne peut pas prendre en compte toutes les optimisations possibles.
3  0 
Madmac
Avatar de Madmac
Membre extrêmement actif https://www.developpez.com
Le 28/02/2022 à 6:27
Citation Envoyé par KiLVaiDeN Voir le message
Je trouve le débat sur la réécriture du noyau Linux en Rust un peu trop "optimiste". Rust n'est pas aussi mature en terme d'options de compilation, de vitesse de compilation, et sa "sécurité" est un frein plus qu'une feature pour du code kernel où il est nécessaire de faire des opérations dites "unsafe".
Peu importe la maturité, les contraintes du langage pour assurer la sécurité deviennent une camisole de force. Par exemple, le goto est considéré un sacrilège pour la plupart des enseignants. Mais utilisé intelligemment, il peut servir à forcer le compilateur à produire du code semblable à des boucles optimisés en langage machine. Autre exemple, la création de code réentrant. Sans un truc semblable au goto, c'est à peu prêt impossible à fabriquer.
2  0 
Commenter Signaler un problème