Discussion :

[Stéphane le calme]

Faut-il convertir le noyau Linux de C à C++ moderne ? Oui, selon un développeur Linux de longue date.
Peter Anvin explique pourquoi, selon lui, il est temps de le faire

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 1^er 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 1^er 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.

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.

Un avis partagé

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

[Aiekick]

c'est une tres mauvais idée. un developpeur c++ professionnel ne devrait pas proposer ca..

[CaptainDangeax]

Passer de C à C++ pour un noyau est une très très mauvaise idée. De toute façon, Linus n'est pas d'accord.
Pour les parties en assembleur, c'est quasiment impossible de faire autrement, vu le grand nombre d'architectures avec lesquelles le noyau Linux peut être compilé. D'ailleurs, dans le noyau Windows, il y a aussi des morceaux d'assembleur dedans, et vu qu'il est écrit en C++ et vu comment il fonctionne, c'est une mauvaise idée de changer

[prisme60]

Il faut savoir qu'en C++, il y a 25 manières de faire des initialisations.
On peut surcharger les opérateurs. On peut redéfinir une fonction en changeant uniquement la signature d'un paramètre avec const.

Je fais du C++ de manière professionnels, et je me tiens à jour sur les normes du C++, et pourtant je déconseille de commencer un nouveau projet en C++! J'appréhende quand des gens inexpérimentés rejoignent un projet en C++. Chaque nouvelle norme apporte des choses intéressantes (nouvelles bibliothèques standard : regex, thread, mutex, filesystem, chrono), mais aussi de la compléxité supplémentaires tout en restant rétro compatible.

Je fais du Rust dans le cadre de mes projets personnels, et j'apprécie la clareté des messages du compilateur. Rien que l'étape de compilation est une étape garantissant un niveau de qualité du code et une certaine assurance au moment de l'éxécution (contrairement au Python ou Javascript où ça peut péter à tout moment à l'exécution!).

Si le C# ou le java conviennent, autant choisir ces langages qui sont bien plus adaptés pour des programmes avec interfaces graphiques ou si l'empreinte mémoire ou la latence n'est pas une contrainte forte.

[Padget]

Le travail de conversion du c au c++ sera bien moindre que du c à rust. De plus le vivier de développeurs c++ est autrement plus important que le vivier rust. Avec le c++ moderne, on ne peut plus dire que le code c++ n'est pas sécurisé. Les smart pointer en sont un exemple. Seul ceux qui ne connaissent vraiment pas le c++ pensent qu'il est toujours celui des années 90.

[chrtophe]

Je ne suis pas développeur, mais de ma vision extérieure, je suis mitigé.

L'utilisation de Rust en parallèle au C est en cours, le rajout de C++ va générer l'usage de trois langage ?


Si les spécialistes sont partagés, ce qui semble le cas des développeurs Linux de longue date, ça ne va faire avancer ma vision.

[Mingolito]

Si je me réfere à cette news : « Rust est une solution pour éviter au noyau Linux et aux mainteneurs de plonger dans la stagnation », d'après Linus Torvalds

Les principaux mainteneurs du noyau Linux sont des habitués du langage C dont l’âge commence par le chiffre 5. Certains se rapprochent même de la soixantaine. Une nouvelle génération de mainteneurs dont la tranche d’âge se situe dans la trentaine gravit les échelons et donc la difficulté de trouver des mainteneurs pour le noyau Linux risque d’aller croissant si son développement se poursuit en langage C. Ce pourrait être un motif de stagnation dans le processus de développement du kernel. C’est l’une des raisons de l’adoption du Rust comme deuxième langage pour la poursuite de cette activité. En sus, il y a que « Rust est digne d'intérêt d’un point de vue technique » comme le souligne Linus Torvalds lors du récent sommet Open Source de la Fondation Linux.

Le but c'est de remplacer les codeurs C soixantenaires vieillissants par des nouveaux codeurs de la génération Z, en leur faisant miroiter Rust, parce que le C c'est totalement "has been".
Je ne voie pas en quoi passer à C++ serait une solution à ce problème, le C++ moderne c'est bien trop difficile pour les codeurs de la génération Z.
Au pire il faudrait leur proposer de programmer le Kernel en Basic, ou alors peut être avec des outils no code comme ça ils auraient rien à foutre.
Déjà vu que 57 % des membres de la génération Z veulent devenir des influenceurs, on risque pas de les voir venir comme codeur, et encore moins comme codeur open source s'il y a rien à gagner
Tous les programmeurs de la génération Z que je connais soit se plaignent de ne pas trouver de job à la sortie de leur bootcamp de 4 semaines tout pourri , soit ils sont en train de programmer des influenceurs AI ou des petites amies AI virtuelles, et ceux qui y sont arrivés se font de la tune par contre.

[abgech]

C++ est un monstre issu d'un croisement entre un dinosaure et une baleine à bosses.

Je ne vois pas l'intérêt de changer en passant du C au C++. Et si l'on veut absolument faire de l'objet, c'est parfaitement possible en C, les pointeurs ne sont pas faits pour les chiens.
D'autant plus qu'au niveau de performance du code produit, ce n'est pas la joie.

Quant à l'argument anti-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, ...

Il est non seulement ridicule, mais risible. Un programmeur (je n'aime pas trop le terme développeur) qui sait programmer, c'est-à-dire qui sait développer des algorithmes, n'est jamais gêné par une nouvelle syntaxe plus de 2-3 semaines. J'ai programmé dans ma longue carrière en, au minimum, une vingtaine de langages différents, allant de FORTRAN à RUST en passant par divers assembler, PL1, ADA, Pascal, etc. J'ai même écrit des programmes en très verbeux COBOL, peu, il est vrai, mais c'est dire mon ouverture d'esprit .

[unanonyme]

il programme kernel c++, pas de problèmes, heureux.

[destroyedlolo]

Rust, vers C++ ... autant autoriser les modules dans ces langages, oui bien sûr, mais alors migrer entièrement le kernel, je suis vraiment très très mitigé !

Ca va être encore l'occasion de faire le ménage dans des technos qu'ils jugent obsolètes, car plus vendus. Mais ce n'est pas parce que microsoft, Intel ou HP décide qu'un truc n'est plus au catalogue qu'il devient inutilisé ! Et le gros intérêt de Linux est de pouvoir recycler des machines que la marche forcée de windows destinent au pilon ! Et sur les PC, hormis la question écologique, ce n'est pas hyper utile vu que c'est avant tout du jetable, ce n'est pas le cas de l'embarqué ou des archi alternatives comme Sparc, HP-PA et autre VAX (même si je préfère largement NetBSD dans ce cas).

[destroyedlolo]

Passer de C à C++ pour un noyau est une très très mauvaise idée. De toute façon, Linus n'est pas d'accord.
Pour les parties en assembleur, c'est quasiment impossible de faire autrement, vu le grand nombre d'architectures avec lesquelles le noyau Linux peut être compilé. D'ailleurs, dans le noyau Windows, il y a aussi des morceaux d'assembleur dedans, et vu qu'il est écrit en C++ et vu comment il fonctionne, c'est une mauvaise idée de changer

Mouai, difficile de reporter les problèmes de windows uniquement sur le C++ : c'est avant tout un gros problème de design générale (et ce, dès l'origine) avec des choix bringuebalants et une dette technologique énorme (d'autres en ont autant sans que ca amène autant de problèmes), doublé d'un manque total de politique de qualité chez l'éditeur.

[chrtophe]

Pourquoi parler de Windows ici ?

[Leo24]

Si il y a débat je trouve qu’il faudrait l’orienter vers la qualité du compilateur non? Le compilateur de Rust est-il suffisamment mature pour répondre aux besoins du noyau Linux?

Il est clair qu’utiliser trois langages de programmation pour le noyau ne ferait qu’augmenter la complexité. Cependant, l’architecture du noyau est modulaire, ce qui est discutable. L’utilisation d’un langage OOP natif simplifierait grandement le code, facilitant la compréhension des fonctionnalités et donc une meilleure maintenance, sans parler de la réduction des risques de bugs. Un langage n’est rien sans son compilateur. Je pense donc que le choix de l’un ou de l’autre langage devrait se faire par une analyse approfondie du degré de sécurité et de fiabilité du compilateur.

[Axel Mattauch]

le "noyau C++", que [suggère H. Peter Anvin serait] d'être un sous-ensemble strictement défini de C++20

Je crois que c'est une fichue bonne idée, et certainement loin d'être triviale (je fais confiance à un éventuel comité pour cela).

De façon générale (i.e.: je ne me limite pas au cas du kernel Linux) la perception que j'ai du C++ est la suivante:

• Au fil des générations, le C++ est de plus en plus mature, permettant de coder avec sobriété (parfois) et sécurité (moyennant les sempiternelles bonnes pratiques)
• Le fort niveau de compatibilité entre générations de C++ est à la fois un avantage (maintenance de code ancien, apprentissage...) et un boulet (lourdeurs, niches d'insécurité, style de codages variés).

Il me semble que certaines lourdeurs d'écriture proviennent aussi de la volonté de faire comme avant, mais mieux, en se démarquant par la syntaxe (par exemple les cast).

Supprimer des vieux riblons et réduire les variantes d'écriture seraient un bienfait. Et l'existence d'un sous-ensemble réduit (défini par guides, options de compilation et autres) serait également utile à l'apprentissage du C++.

[Grool]

Bonjour,
Je ne suis pas un grand fan de ce genre de débats.
Parce que même sur un forum technique comme ici, les commentaires se résument vite aux poncifs habituels des pro-ceci et des anti-cela.
Laissons les contributeurs du Noyau Linux débattre entre eux de leurs besoins et de leur problèmes.

Là où je me pose des questions tout de même, c'est l'apport concret du C++ (même moderne) dans le domaine spécifique de la programmation système.

Le C++ moderne pour moi, c'est:
- la sémantique de déplacement,
- pas mal d'améliorations côté programmation générique
- mais surtout de nouvelles bonnes pratiques dans la gestion de la mémoire en prônant l'utilisation des conteneurs STL plutôt que de manipuler des pointeurs, et donc d'utiliser assez massivement le tas.

C'est parfaitement compréhensible en programmation haut niveau, mais je suppose que le tas est prohibé en programmation système ou embarqué, non?

[djm44]

C'est une bonne idée de migrer certains aspects du noyaux en C++. C'est pour le futur un gain de temps dans le processus de développement qui assure moins de risques liés aux pointeurs. C'est une solution beaucoup plus souple et réaliste que celle qui constituerait à opter pour le Rust qui est une horreur syntaxique. C++ offre de nombreuses possibilités d'implémentation tout en étant un langage sur. Ceci étant pour la programmation du noyau Linux il faut reconnaître que l'approche objet n'est pas d'une grande pertinence ce qui explique la persistance du C . Cet existant en C pourrait être prolongé par une mutation progressive en C++ qui n'est pas qu'un langage objet. Le C++ n'est pas la dictature de l'héritage ce qui le rend adaptable à la programmation système.