Le noyau Linux est principalement composé de code C avec diverses parties écrites en assembleur et le travail croissant autour du support de Rust dans le noyau Linux. Alors qu’il n’est pas encore clair s’il y a suffisamment de poids pour en faire une réalité, un débat sur la liste de diffusion du noyau Linux a été relancé sur la possibilité de voir le code C du noyau Linux converti en C++ à l’avenir.Le 1er avril 2018, David Howells, ingénieur chez Red Hat, a publié un ensemble de 45 correctifs pour commencer à convertir le noyau en C++. Cela permettrait au noyau principal d'utiliser les fonctions modèles en ligne, les fonctions surchargées en ligne, l'héritage de classe et d'autres fonctionnalités qui ne sont pas actuellement prises en charge par le noyau Linux avec son code C. Il a été un peu difficile de mener des discussions sérieuses ce jour-là (poisson d'avril oblige) et, en fin de compte, les correctifs sont restés sur la liste de diffusion du noyau Linux pendant six ans sans faire l'objet d'une discussion approfondie.
Cependant, la semaine dernière, le développeur Linux de longue date H. Peter Anvin a répondu à ce fil de discussion sur la liste de diffusion du noyau. Anvin a écrit un long message sur la LKML avec ses raisons pour lesquelles il est enfin temps pour le noyau Linux de passer au C++ :
Andrew Pinski m’a récemment fait prendre conscience de ce fil. Je me rends compte qu’il a été publié le 1er avril 2018, et qu’il était soit une blague, soit qu’il a été pris comme tel. Cependant, je pense qu’il y a de la validité à cela, et je vais essayer de donner mon opinion ici.
Le C et le C++ ont tous deux connu beaucoup de développement depuis 1999, et le C++ est en fait, à mon avis personnel, enfin “mûr” pour être un meilleur C pour le genre de programmation embarquée qu’un noyau d’OS illustre. Je dis cela en tant qu’auteur d’un très grand nombre de hacks de macros et d’assembleur en ligne dans le noyau.
Ce qui me fait vraiment dire cela, c’est qu’un grand nombre de choses que nous avons récemment demandées comme extensions spécifiques à gcc sont en fait relativement faciles à implémenter en C++ standard et, dans de nombreux cas, permettent d’améliorer l’infrastructure sans changements de code globaux (voir ci-dessous).
Le C++14 est à mon avis la version “minimum” qui a un support raisonnable de la métaprogrammation et qui a la plupart sans l’enfer des types des versions antérieures (le C++11 avait la plupart, mais le C++14 comble quelques pièces manquantes clés). Cependant, le C++20 est vraiment le principal facteur de changement à mon avis ; bien que les versions antérieures pouvaient jouer beaucoup de hacks SFINAE, elles donnaient aussi des messages d’erreur absolument inutiles.
Nous faisons beaucoup de métaprogrammation dans le noyau Linux, mise en œuvre à l'aide de macro-hacks souvent vraiment hideux. Celles-ci sont également pratiquement impossibles à déboguer. Prenons l'exemple du type hacks uaccess.h, dont j'ai conçu et écrit certains éléments. En C++, les différents casts et déclarations de cas peuvent être décomposés en instances de modèles séparées et, avec un peu d'ingéniosité, on peut aussi appliquer strictement des choses comme les pointeurs de l'espace utilisateur par rapport à ceux de l'espace noyau, ainsi que les pointeurs de l'espace utilisateur déjà vérifiés par rapport à ceux qui ne le sont pas, sans parler de gérer facilement le cas des types de l'espace utilisateur 32 bits dans un noyau 64 bits et d'appliquer la conversion endiannée.
Le C et le C++ ont tous deux connu beaucoup de développement depuis 1999, et le C++ est en fait, à mon avis personnel, enfin “mûr” pour être un meilleur C pour le genre de programmation embarquée qu’un noyau d’OS illustre. Je dis cela en tant qu’auteur d’un très grand nombre de hacks de macros et d’assembleur en ligne dans le noyau.
Ce qui me fait vraiment dire cela, c’est qu’un grand nombre de choses que nous avons récemment demandées comme extensions spécifiques à gcc sont en fait relativement faciles à implémenter en C++ standard et, dans de nombreux cas, permettent d’améliorer l’infrastructure sans changements de code globaux (voir ci-dessous).
Le C++14 est à mon avis la version “minimum” qui a un support raisonnable de la métaprogrammation et qui a la plupart sans l’enfer des types des versions antérieures (le C++11 avait la plupart, mais le C++14 comble quelques pièces manquantes clés). Cependant, le C++20 est vraiment le principal facteur de changement à mon avis ; bien que les versions antérieures pouvaient jouer beaucoup de hacks SFINAE, elles donnaient aussi des messages d’erreur absolument inutiles.
Nous faisons beaucoup de métaprogrammation dans le noyau Linux, mise en œuvre à l'aide de macro-hacks souvent vraiment hideux. Celles-ci sont également pratiquement impossibles à déboguer. Prenons l'exemple du type hacks uaccess.h, dont j'ai conçu et écrit certains éléments. En C++, les différents casts et déclarations de cas peuvent être décomposés en instances de modèles séparées et, avec un peu d'ingéniosité, on peut aussi appliquer strictement des choses comme les pointeurs de l'espace utilisateur par rapport à ceux de l'espace noyau, ainsi que les pointeurs de l'espace utilisateur déjà vérifiés par rapport à ceux qui ne le sont pas, sans parler de gérer facilement le cas des types de l'espace utilisateur 32 bits dans un noyau 64 bits et d'appliquer la conversion endiannée.
Pourquoi pas Rust ?
Pour ceux qui pourraient alors soulever la question de « réécrire le code C en Rust », Anvin a ajouté de manière proactive dans son message :
Maintenant, "pourquoi pas Rust" ? Tout d'abord, Rust utilise une syntaxe différente (souvent, à mon avis, gratuitement), et non seulement tous les développeurs du noyau devraient se familiariser intimement avec la syntaxe afin d'obtenir le même type de "feeling" que nous avons pour le C, mais convertir du code C en Rust n'est pas quelque chose qui ne peut être fait par les développeurs du noyau qu'au coup par coup, alors qu'avec quelques nettoyages le code C existant peut être compilé en C++.
Cependant, je ne suis pas d'accord avec certaines des conclusions de David. en fait, je crois que David est inutilement pessimiste, du moins en ce qui concerne le C++ moderne.
Notez que personne de sain d'esprit ne s'attend à utiliser toutes les fonctionnalités de C++. Tout comme nous avons le "kernel C" (actuellement un sous-ensemble de C11 avec un avec un ensemble relativement large d'extensions spécifiques au compilateur), nous aurions le "noyau C++", que je suggère d'être un sous-ensemble strictement défini de de C++20, combiné à un ensemble similaire d'extensions de compilateur). Je me rends compte que que la prise en charge du C++20 par les compilateurs est encore très récente pour des raisons évidentes, de sorte qu'au moins une partie de ce qui précède est tournée vers l'avenir.
Cependant, je ne suis pas d'accord avec certaines des conclusions de David. en fait, je crois que David est inutilement pessimiste, du moins en ce qui concerne le C++ moderne.
Notez que personne de sain d'esprit ne s'attend à utiliser toutes les fonctionnalités de C++. Tout comme nous avons le "kernel C" (actuellement un sous-ensemble de C11 avec un avec un ensemble relativement large d'extensions spécifiques au compilateur), nous aurions le "noyau C++", que je suggère d'être un sous-ensemble strictement défini de de C++20, combiné à un ensemble similaire d'extensions de compilateur). Je me rends compte que que la prise en charge du C++20 par les compilateurs est encore très récente pour des raisons évidentes, de sorte qu'au moins une partie de ce qui précède est tournée vers l'avenir.
Jiri Slaby de SUSE Lans s'est prononcé en faveur de cette initiative C++ pour le noyau Linux. David Howells de Red Hat, qui a initialement publié les correctifs du noyau, s'est également prononcé en faveur de cette discussion.
Nous verrons où cette discussion sur LKML nous mènera et s'il y a finalement assez de traction en 2024 pour supporter le code C++ moderne, ou au moins un sous-ensemble défini de C++14~20, dans le noyau Linux. Dans le passé, Linus Torvalds s'est passionnément opposé au C++, mais nous verrons si le vent a finalement tourné, s'il est plus satisfait des normes C++ récentes ou s'il reste déterminé à maintenir le noyau Linux en C.
Ce n'est qu'en 2022 que le noyau Linux a commencé à passer de C89 à C11. En particulier, s'il existe un consensus pour autoriser un sous-ensemble de programmation C++14/C++20 dans le noyau, il faudra peut-être encore un certain temps avant qu'il ne soit adopté pour permettre le déploiement d'un support plus large des compilateurs avant d'augmenter les exigences de base des compilateurs et même s'il reçoit l'aval miraculeux de Torvalds, ce n'est pas une décision qui doit être prise à la légère.
Conclusion
Le débat sur la LKML a suscité de nombreuses réactions, certaines favorables, d’autres sceptiques ou opposées à l’idée de passer au C++ pour le noyau Linux. Certains ont suggéré que Rust serait un meilleur choix que C++ pour le noyau Linux, car il offre plus de garanties de sécurité, de vérification formelle et de vérification des types. D’autres ont souligné que le C++ moderne est très différent du C++ ancien et qu’il a beaucoup évolué en termes de performance, de lisibilité et de fonctionnalités. D’autres encore ont fait valoir que le C est suffisant pour le noyau Linux et qu’il n’y a pas besoin de changer un code qui fonctionne.
Il n’est pas clair si ce débat aboutira à une décision concrète ou s’il restera une discussion théorique. Il est probable que le passage du noyau Linux au C++ nécessiterait un énorme effort de réécriture, de test et de maintenance, ainsi qu’un consensus de la part des principaux développeurs du noyau. Il est également possible que le noyau Linux continue à utiliser le C comme langage principal, tout en intégrant progressivement d’autres langages comme Rust ou C++ pour certaines parties du noyau. Quoi qu’il en soit, le débat sur le C++ pour le noyau Linux montre que le développement du noyau n’est pas figé et qu’il est toujours ouvert à l’innovation et à l’expérimentation.
Source : Peter Anvin
Et vous ?
Quels sont les avantages et les inconvénients du C++ par rapport au C pour le développement du noyau Linux ? Quelles sont les parties du noyau Linux qui pourraient bénéficier le plus d’une conversion en C++ ? Quels sont les obstacles techniques, organisationnels et culturels à une telle conversion ? Quel est l’impact potentiel d’une conversion en C++ sur la performance, la sécurité, la portabilité et la maintenabilité du noyau Linux ? Quelles sont les alternatives au C++ pour le noyau Linux, comme Rust ou d’autres langages ? Quelle est votre opinion personnelle sur le C++ pour le noyau Linux ? Seriez-vous prêt à contribuer au développement du noyau en C++ ?Voir aussi :
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 
Envoyé par CaptainDangeax
