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 !

Linux : un framework pour la mise au point de drivers en langage Rust pourrait faire son entrée dans le noyau
De l'OS

Le , par Patrick Ruiz

307PARTAGES

15  0 
Il s’agit d’une proposition d’un contributeur faite à Greg Kroah-Hartman – l’un des mainteneurs du noyau Linux engagé sur cet axe. Rien de concret pour le moment, mais il se dit qu’il est possible qu’un framework dédié à la mise au point de drivers en langage Rust soit accepté dans le noyau de l’OS open source. Pour cela, Greg Kroah-Hartman formule deux conditions : primo, ledit framework ne sera pas activé par défaut dans le cas de son intégration, ce, pour éviter que l’on n’ait besoin de Rust pour compiler le noyau ; secundo, que l’approche proposée présente de réels avantages en comparaison à ceux qui découlent de l’utilisation du langage C.

C’est connu, le noyau Linux est le produit de développements en langages C et assembleur. Dans la filière de la mise au point de drivers pour le système d’exploitation open source, c’est encore ce tandem qui règne en maître. Les développeurs engagés sur cet axe le plébiscitent pour les énormes possibilités qu’il offre en matière de manipulation des ressources matérielles d’un système informatique. Dans le jargon du milieu, on parle de « proximité avec le hardware. » Seulement, de plus en plus de voix s’élèvent pour appeler au passage au langage Rust – l’un de ceux pressentis comme remplaçant du C sur le terrain du contrôle du matériel.

Il y a seulement que lors du dernier Linux Security Summit, des chercheurs en sécurité ont, à côté d’autres, mis le doigt sur l’une des plus grosses tares que le langage C traîne : les 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. D’après les chiffres rapportés par le duo de chercheurs, 65 % des vulnérabilités du noyau Linux recensées sur les 6 derniers mois en résultent. Les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE) abordent dans le même sens : 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon. À contrario, l’équipe de chercheurs est d’avis qu’à côté d’autres atouts, Rust offre de meilleures garanties en matière de gestion de la mémoire que le langage C.


L’équipe de chercheurs ne s’est pas limitée à parler des avantages que le langage Rust offre en comparaison au C. Elle en a profité pour présenter une initiative relative au développement d’un framework dédié à la mise au point de drivers Linux en langage Rust. De façon brossée, l’effort consiste en la mise sur pied de wrappers vers des API du noyau Linux. Les développements visent les architectures x86, arm/arm64, mips, POWERPC, RISC-V, s390 et SPARC.

Mais, il y a seulement que Linus Torvalds est d’avis qu’il n’y a rien de mieux que le langage C pour la programmation système.

« Je dois dire que je suis assez vieux jeu sur des sujets comme celui-là. La raison pour laquelle je me suis lancé dans Linux et les systèmes d’exploitation en général est que j’aime vraiment le hardware ; j’aime explorer l’aspect matériel. Je ne le dis pas pour souligner que je suis un expert en hard parce que me tendre un fer à souder serait une mauvaise idée. Ce que je veux dire c’est que j’aime interagir avec le matériel à partir du logiciel. Vu sous cet angle, je n’ai pas encore vu un langage de programmation qui approche seulement le langage C. Cette affirmation ne tient pas uniquement à ce que le C soit utile pour générer du bon code pour piloter le matériel. Ce qu’il faut dire en plus c’est que l’usage du C fait sens pour des personnes qui pensent comme un ordinateur. Je crois que la raison pour laquelle il en est ainsi est que les personnes qui ont conçu le langage C l’ont fait à un moment où les compilateurs devaient être simples ; à un moment où le langage devait être adapté à la sortie ou au résultat attendu. Donc lorsque je lis du code en langage C, je sais à quoi va ressembler le code assembleur et c’est ce qui m’intéresse », a-t-il déclaré il y a 7 ans lors d’une de ses interventions à l’Intel Open source Technology Center.

Auparavant, il a balayé d’un revers de la main des propositions similaires visant à introduire le C++ dans le cercle des langages dédiés au développement de drivers pour Linux. Il avait notamment mis en avant la possibilité de faire de l’orienté objet de façon plus propre avec le C qu’avec le C++.

L’initiative d’Alex Gaynor & Geoffrey Thomas reste un énorme chantier sur de nombreux axes. Par exemple, l’équipe de chercheurs souligne la nécessité de poursuivre avec le développement de pilotes pour des systèmes de fichiers et pour des types d’appareils spécifiques. Faudra ensuite voir si les contenus arrivent à convaincre les mainteneurs Linux.

Source : lwn, lss, GitHub

Et vous ?

Qu’en pensez-vous ?

Êtes-vous d’accord avec cette proposition d’ouverture du noyau Linux au langage Rust pour la programmation système ?

Le Rust peut-il remplacer le C pour la programmation système ? Est-il meilleur ?

Voir aussi :

Programmation : un « Pony » peut cacher un langage, l'outil adéquat, d'avis d'utilisateurs, pour le développement d'applications concurrentes

C2 : un langage qui se présente comme une évolution de C, plus rapide, sans fichiers d'en-tête, avec système de build intégré et d'autres changements

Quel avenir pour le langage C ? Un développeur expérimenté fait ses adieux au langage et livre ses inquiétudes quant à son avenir

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

Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 30/08/2019 à 21:30
Donc lorsque je lis du code en langage C, je sais à quoi va ressembler le code assembleur et c’est ce qui m’intéresse »
Cette affirmation est de moins en moins vraie avec les optimisations des compilateurs C récents (ça vaut aussi pour le Rust) qui peuvent se permetre de faire des optimisations toujours plus poussées, mais aussi plus surprenantes.
6  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 02/09/2019 à 15:00
Ces chiffres ne viennent pas de dépot github choisis au hasard, mais de sociétés qui ont une vraie politique de sécurité et dont le code est forcément relu.
La pratique a clairement montré que, sur des base de code un minimum complexe, on peut être certains que même les meilleurs développeurs C finiront par faire des erreurs. A partir de là dire que c'est seulement un problème des développeur incompétents, c'est se voiler la face.
3  0 
Avatar de Guntha
Membre éprouvé https://www.developpez.com
Le 02/09/2019 à 9:24
Il y a seulement que lors du dernier Linux Security Summit, des chercheurs en sécurité ont, à côté d’autres, mis le doigt sur l’une des plus grosses tares que le langage C traîne : les 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. D’après les chiffres rapportés par le duo de chercheurs, 65 % des vulnérabilités du noyau Linux recensées sur les 6 derniers mois en résultent. Les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE) abordent dans le même sens : 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon. À contrario, l’équipe de chercheurs est d’avis qu’à côté d’autres atouts, Rust offre de meilleures garanties en matière de gestion de la mémoire que le langage C.
Ça ressemble plus à une tare des programmeurs incompétents qu'à une tare du langage C. Si les mêmes programmeurs abusent des blocs "unsafe" en Rust, il y aura les mêmes problèmes.

Perso j'aime bien Rust, à part son système de build (cargo), même si le langage a déjà aussi des défauts, mais ça me fait plaisir de le voir de plus en plus mis en avant Après je ne peux pas m'exprimer plus que ça, je ne connais pas grand chose au milieu de la programmation de drivers sous Linux.
1  1