Désormais, il est possible d'écrire des modules pour Linux en C++ en utilisant les constructeurs et destructeurs, les exceptions et la vérification de type dynamique. (NdM : de tels modules ne fonctionneront bien sûr qu'avec un noyau compilé avec ce patch.)
Ce patch n'est disponible que pour la série 2.6.x du noyau.
NdM : le patch est basé sur le compilateur GNU g++, son implémentation des exceptions et son interface binaire (ABI). Sinon il est peu probable qu'il soit incorporé au noyau officiel. Voir « Pourquoi ne pas réécrire le noyau en C++ ? » dans le FAQ linux-kernel
Aller plus loin
- Page sur le patch (9 clics)
- Noyau Linux (4 clics)
- FAQ linux-kernel : Why don't we rewrite the Linux kernel in C++? (21 clics)
# C++
Posté par farib . Évalué à 0.
[^] # Re: C++
Posté par Guillaume Knispel . Évalué à 3.
[^] # Re: C++
Posté par farib . Évalué à 1.
J'ai cru entendre dire ( corrigez moi au cas ou ) que sous OSX ( d'ou ma confusion avec darwin ) il y avait justement possibilité d'écrire des pilotes en C++
Encore tout faux ?
[^] # Re: C++
Posté par 007 . Évalué à 1.
[^] # Re: C++
Posté par ckyl . Évalué à 5.
XNU pour lui est du C pur et dur.
http://developer.apple.com/documentation/DeviceDrivers/Conceptual/I(...)
http://developer.apple.com/documentation/Darwin/Conceptual/KernelPr(...)
Pour ce qui est du C++ dans le noyau je crois que linus a deja dit ce qu'il en pensait dans le passe :
http://kerneltrap.org/node/view/2067(...)
Je lis plus lkml mais je pense pas que son avis soit beaucoup différent maintenant...
[^] # Re: C++
Posté par Pierre . Évalué à 3.
http://kerneltrap.org/node/view/2067(...(...))
a signaler que le mini flamewar qui s'ensuit est très interressant..
[^] # Re: C++
Posté par Manuel Menal . Évalué à 1.
(évidemment, je ne compte pas la libkern en C++. Il est évident qu'elle devait s'y trouver.)
Voili, voilà.
[^] # Re: C++
Posté par Pierre . Évalué à 2.
Voici ce qu'en dit la doc d'IOKit :
"Language Choice
Apple considered several programming languages for the I/O Kit and chose a restricted subset of C++. This subset is based on the Embedded C++ specification (http://www.caravan.net/ec2plus/(...)).
C++ was chosen for several reasons. The C++ compiler is mature and the language provides support for system programming. In addition, there is already a large community of Macintosh (and BSD) developers with C++ experience.
The restricted subset disallows certain features of C++, including
- exceptions
- multiple inheritance
- templates
- runtime type information (RTTI)?the I/O Kit uses its own implementation of an runtime typing system
These features were dropped because they were deemed unsuitable for use within a multithreaded kernel. If you feel you need these features, you should reconsider your design. You should be able to write any driver you require using I/O Kit with these restrictions in place."
[^] # Re: C++
Posté par Pierre . Évalué à 1.
[^] # Re: C++
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: C++
Posté par reno . Évalué à 4.
Sachant que BeOS a d'abord tourné sur PPC avant d'être porté sur x86, j'ai comme un *gros* doute pour cette partie..
[^] # Re: C++
Posté par Pierre . Évalué à 1.
Il me semblait qu'a l'époque, il faisait grand bruit parceque c'était du C++.
Remarque, à l'époque, je lisait SVMMac, et je tournait un OS écrit en pascal, alors la différence entre le noyau et le user space.. :)
[^] # Re: C++
Posté par Anonyme . Évalué à -1.
# C++ interdit de noyau.
Posté par Anonyme . Évalué à 5.
Mhh, je me dirais plutôt que sa dépendra des killer features que ca permettra.
A priori, c'est tellement bas niveau que du C++ c'est pas forcément très intéressant, mais l'avenir nous réservera peut être des suprises !
[^] # Re: C++ interdit de noyau.
Posté par Raphaël Maurel-Segala . Évalué à 3.
Bon, ce serait quoi, l'intérêt de supporter le C++ dans le noyau ?
[^] # Re: C++ interdit de noyau.
Posté par Erwan . Évalué à 7.
[^] # Re: C++ interdit de noyau.
Posté par 007 . Évalué à -10.
Excellente question.
Fesons une analogie.
KDE => C++
Gnome => C
Voilà, tu as ta réponse.
[^] # Re: C++ interdit de noyau.
Posté par Raphaël Maurel-Segala . Évalué à 9.
Dois-je comprendre que ça servira à doter Linux d'une gestion avancée du troll directement au niveau noyau ? C'est clairement une fonctionnalité cruciale pour le power-user.
Si c'est le cas, il faudra penser à en causer sur fr.comp.os.linux.debats. Luc2 sera certainement intéressé.
Mais je suis pas sûr de très bien comprendre. Tu pourrais préciser avec d'autres analogies ? Quest-ce que ça donne avec Vi/Emacs ? Avec Gentoo/Debian ? etc.
[^] # Re: C++ interdit de noyau.
Posté par 007 . Évalué à -10.
Si t'as toujours pas compris quel est le meilleur des deux languages, j'y suis pour rien.
Compte pas sur moi pour nourrir le troll.
[^] # Re: C++ interdit de noyau.
Posté par KaZeKaMi (site web personnel) . Évalué à 1.
la réponse est bien sûr le Java
[^] # Re: C++ interdit de noyau.
Posté par Larry Cow . Évalué à 7.
C++ est un bon langage pour certaines choses. Pour de la simulation, par exemple.
C++ est un langage quelconque, voire médiocre, pour d'autres choses, comme le développement de GUIs. Typiquement, les meilleurs APIs graphiques basées sur du C++ ajoutent toutes une bidouille à leur sauce pour dépasser les limites du langage. Genre QT avec le moc. Sans parler de cette vision si particulière (d'autres diraient "psycho-rigide") de l'objet.
C++ est un (très) mauvais langages pour d'autres tâches, et la programmation système en fait partie.
[^] # Re: C++ interdit de noyau.
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 5.
Je crois que tu place la médiocrité au mauvais endroit. En effet, les rustines made in QT ont été écrites pour pallier à des manques initiaux du C++. Depuis, le C++ a évolué... QT est resté dans ses rustines...
[^] # Re: C++ interdit de noyau.
Posté par Pinaraf . Évalué à 1.
[^] # Re: C++ interdit de noyau.
Posté par zeSixty4Douille . Évalué à 1.
Qq1 sait ou l'on peut trouver les C++ coding rules de KDE ? Celle de mozilla sont tres bonnes en tout cas.
[^] # Re: C++ interdit de noyau.
Posté par Pinaraf . Évalué à 1.
J'attend beaucoup de QT4 + KDE4... Vitesse, conso mémoire...
Cependant je suis persuade que les gars qui ont fait Qt s'y connaissent vraiment en compilateur.
J'avais lu une interview d'un dév de Qt, et je confirme, ils ont une expérience énorme en matière de compilo ! Ils ont des règles définissant ce qu'on peut faire ou pas, en fonction des compilateurs. Par exemple les namespaces n'arrivent dans Qt4 que parce que maintenant assez de compilateurs sont aptes à gérer ça correctement.
[^] # Re: C++ interdit de noyau.
Posté par 007 . Évalué à -6.
[^] # Re: C++ interdit de noyau.
Posté par 007 . Évalué à -2.
Il est piquant de voir qu'un commentaire neure peut déchainer autant de [-].
Sûr que les pro C ont autant noté [-] que les pro C++.
Apparament la présence de "KDE" et "Gnome" ou "C" et "C++" en même temps braque les gens. Même si on ne dit rien.
Je voulais dire que discuter des avantages du C par rapport aux avantages du C++ et vice versa relève de la "guerre de religion".
Je l'ai dit et vous le démontrez avec la pluie de [-] que j'ai reçu.
[^] # Re: C++ interdit de noyau.
Posté par Gart Algar . Évalué à 6.
Tu l'as pas vraiment dis, en fait pour moi tu as plutôt sorti un appeau à troll de la taille de l'arche de la défense. Et vu que la saison de la chasse n'a pas encore commencée, tu t'es fait arrêter en plein braconnage.
Allez, file avec que j'appel le garde-chamêtre :)
[^] # Re: C++ interdit de noyau.
Posté par Antoine . Évalué à 5.
Apparemment le problème est surtout que tu ne dis rien...
[^] # Re: C++ interdit de noyau.
Posté par Fabimaru (site web personnel) . Évalué à 3.
Utiliser des destructeurs pour s'assurer que tout est bien nettoyé quand tu sors d'une fonction.
[^] # Re: C++ interdit de noyau.
Posté par Ramso . Évalué à 4.
[^] # Re: C++ interdit de noyau.
Posté par Ayrton . Évalué à -1.
[^] # Re: C++ interdit de noyau.
Posté par Christophe Lucas (site web personnel) . Évalué à 2.
Bonne journée à tous :-)
[^] # Re: C++ interdit de noyau.
Posté par Fabimaru (site web personnel) . Évalué à 2.
static CMutex m_Mutex;
{
CMutextGuard guard(m_Mutex);
// du code
}
Quand tu as des "return", "goto" ou des exceptions C++ dans une fonction, c'est vite fait d'oublier un cas de sortie de la fonction (et le C n'a pas de clause "try/finally" comme Java et en Python pour faire un nettoyage forcé).
[^] # Re: C++ interdit de noyau.
Posté par zeSixty4Douille . Évalué à 1.
Puis la taille du code pour gerer des objects automatiques peut vraiment devenir problematique lorsque tu utilises des objects haut niveau si il y a beaucoups de conditions de sortie.
Enfin, lorsque l'on utilise des mutex/sections critique, si tu veux pas pourrir les perfos, tu limites au maximum la taille du code enclos. A la limite, tu evites meme de faire les appels pour eviter des exceptions.
Je connais des gars qui utilisent RogueWave, qui font ce genre de code, ca ne fonctionne que si le code est compile en debug ...
[^] # Re: C++ interdit de noyau.
Posté par manatane . Évalué à 4.
# DLFP: Poster un commentaire
Posté par Antoine . Évalué à 0.
Il n'y a aucun rapport entre ces deux phrases. Le kernel pourrait très bien être "compatible C++" (avec le patch mentionné) sans être réécrit en C++.
[^] # Re: DLFP: Poster un commentaire
Posté par Erwan . Évalué à 6.
En l'occurence le « Pourquoi ne pas réécrire le noyau en C++ ? » c'est le titre du paragraphe qui parle de C++ et inclus plusieurs questions.
[^] # Re: DLFP: Poster un commentaire
Posté par Jean Canazzi . Évalué à 2.
Is it a good idea to write a new driver in C++? The short answer is no, because there isn't any support for C++ drivers in the kernel.
et juste en dessous :
Why not add a C++ interface layer to the kernel to support C++ drivers? The short answer is why bother, since there aren't any C++ drivers for Linux.
Conclusion : on n'écrit pas de drivers C++ parce qu'il n'y a pas de support dans le noyau, et on n'ajoute pas de support C++ dans le noyau parce qu'il n'y a pas de drivers C++.
Ils auraient pu écrire plus simplement : "we won't add C++ support because we don't like C++". Cela aurait rendu la FAQ plus claire, vous ne trouvez pas ?
[^] # Re: DLFP: Poster un commentaire
Posté par 007 . Évalué à 1.
Si avoir des drivers un C++ était un gros avantage, il y aura un fork "populaire" de linux avec une interface C++. Mais ça n'existe pas...
[^] # Re: DLFP: Poster un commentaire
Posté par fabien turmel . Évalué à 3.
tu devrais aussi lire le lien cité plus haut http://kerneltrap.org/node/view/2067(...)
le C et le C++ ne sont pas entierement compatible.Certaines structures du C ne sont pas admises en C++ .De plus le noyau ne peut pas comprendre les exceptions C++.
Autre problème du C++,les ABI différent d'une version de GCC à une autre .Cela peut poser poser problème si on est hélas obligé d'installer un driver proprietaire .
# C'est une très mauvaise idée
Posté par Ontologia (site web personnel) . Évalué à -2.
Le gros problème de la liaison dynamique c'est qu'elle construit le code
sur des pointeurs sur fonctions, résultat , le processeur n'a pas de code statique à optimiser ce qui impliquent des pertes de performances par non utilisation du cache, et tout s'écroule.
Dans le cadre d'une application, c'est juste dommage, dans le cadre d'un noyau c'est problématique.
A la limite intégrer de l'objet pourrait se faire avec GNU/Eiffel et Lisaac, ce sont les seuls langages objets (à ma connaissance) supprimant la liaison dynamique et générant du code statique, donc optimisable.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est une très mauvaise idée
Posté par shbrol . Évalué à 6.
tu est sur de toi, la ?
C++ n'est pas un langage à objet classique (genre Smalltalk), et la liaison dynamique n'a rien d'obligatoire. Les templates, si je ne m'abuse, c'est tres, tres statique.
[^] # Re: C'est une très mauvaise idée
Posté par Jean Canazzi . Évalué à 0.
[^] # Re: C'est une très mauvaise idée
Posté par manatane . Évalué à 0.
[^] # Re: C'est une très mauvaise idée
Posté par Snark_Boojum . Évalué à 2.
Snark sur #eiffel
[^] # Re: C'est une très mauvaise idée
Posté par Jean Canazzi . Évalué à 2.
Et dans une certaine école d'ingénieur, le projet de fin de première année est un convertisseur C++ vers C :)
[^] # Re: C'est une très mauvaise idée
Posté par Erwan . Évalué à 1.
[^] # Re: C'est une très mauvaise idée
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
"La première sécurité est la liberté"
[^] # Re: C'est une très mauvaise idée
Posté par shbrol . Évalué à 1.
[^] # Re: C'est une très mauvaise idée
Posté par Tobu . Évalué à 2.
[^] # Re: C'est une très mauvaise idée
Posté par Ontologia (site web personnel) . Évalué à 1.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# compilation
Posté par ckyl . Évalué à 8.
Aïe patapai !
[^] # Re: compilation
Posté par jimee (site web personnel) . Évalué à -1.
# Et pourquoi pas le noyau en user-space ?
Posté par Obsidian . Évalué à 2.
Une killer-feature pour éviter toutes les failles de sécurité, processus en uninterruptible state, deadlocks, etc. , ce serait d'exporter le noyau en user-space. Je ne comprends pas que personne n'y ait pensé avant :-)
[^] # Re: Et pourquoi pas le noyau en user-space ?
Posté par shbrol . Évalué à 3.
[^] # Re: Et pourquoi pas le noyau en user-space ?
Posté par Snark_Boojum . Évalué à 3.
(le truc sur lequel le hurd va tourner un jour)
# Une brèche
Posté par Veiovis . Évalué à 3.
Cela peut augmenter le nombre de développeurs. Comme on peut le lire dans les commentaires, il est évident que certains sont attachés au C et d'autres penchent vers le C++.
On pourrait reprocher le manque de lisibilité qui peut en découler. Mais, après tout, n'est-il pas courant de recourir à plusieurs langages pour une même application? Par exemple, les codes de calcul numérique manipulent souvent du Fortran appelé depuis le C ou le C++.
On peut aussi prétendre que le C++ cache les choses, pour faire référence au commentaire de Torvald. Le C++ dissimule un certain nombre de choses, ce qui ne les rend pas opaques pour autant. Le véritable problème est qu'il est plus difficile de bien comprendre ce qu'il se passe. Il faut donc des programmeurs de très bon niveau pour éviter quelques écueils.
Reste à voir comment les développeurs du noyau vont accepter cela. Mal si on en croit ce que dit Torvald. La dimension purement technologique n'est pas toujours le seul angle d'appréciation. Il existe une communauté qui souhaite rester sur de vieilles méthodes parce qu'ils les maîtrisent bien. Ca me rappelle ce que disent certains, dans la communauté scientifique, qui restent en Fortran 77. Argument historique de poids... D'un autre côté, si on ne force jamais la main, tout reste à l'identique, pour fort, fort longtemps!
Je voudrais enfin ajouter que forcer trop la main peut conduire à une mauvaise intégration du C++. Si les développeurs boudent le langage au lieu de définir un cadre propre de développement pour ce langage, l'effet pourrait être assez désastreux. C'est dommage car le C++ fait plus que le C et je ne vois pas pourquoi les développeurs ne s'autoriseraient pas certains ajouts du C++, quitte à ne pas programmer véritablement objet.
[^] # Re: Une brèche
Posté par 007 . Évalué à 0.
Ben regardes le code de Linux pour voir comment code les "vieux" (dont la moyen d'âge ne doit pas dépasser les 35 ans).
Conseil : Prévois du café et une boîte d'aspirine.
Et si c'est compliqué, ce n'est pas à cause du C mais car un noyau est compliqué.
[^] # Re: Une brèche
Posté par Sebastien . Évalué à 3.
Il faut bien se rendre à l'évidence qu'un jour ou l'autre un langage (objet ou pas, mais je pense que la prochaine génération sera objet) détrônera le C. Même pour écrire un noyau. Et le plus tôt Linux aura amorcé sa conversion/migration ou en tout cas "l'infrastructure" la permettant, mieux ce sera.
if ( "Soyons fou" == mode ) {
Ce qui serait classe c'est que pour chaque bout de code du noyau, il y ait une compétition "génétique" darwinienne entre plusieurs algos écrits en différents langages. On aurait alors les meilleurs des meilleurs des meilleurs (citation tirée (et adaptée) de : "Clerks, employés modèles" ).
}//! end "Soyons fous"
C'est pour çà qu'à mon avis dire "le C y a pas mieux pour les noyaux" et se cantonner à cette vision étriquée et statique, c'est faire preuve d'un manque total d'anticipation et de recul sur l'Histoire du code au travers des ages ;)
Bien sûr, Linux n'est pas une fin en soit, et peut-être que dans 10 ans un nouveau noyau libre codé dans un langage de la mort qui tue les mamans ours par brouettes entières le supplantera. Mais si Linux veut vivre jusque là, il me semble nécessaire qu'il y ait aussi de l'innovation au niveau du langage utilisé pour le coder.
En conclusion, il est bien sûr évident que cette querelle du C VS C++ est stérile puisqu'elle s'apparente à la séculaire bataille des Anciens contre les Nouveaux (cf les cours de phranssais de 1ère) dont les philosophes des Lumières ont la paternité (en (très très) gros, déjà à leur époque ils disaient : la jeunesse fout le camps, ce sont tous des cons, et leurs enfants disaient la même chose d'eux :). Il ne faut donc pas épiloguer plus que de raison.
[^] # Re: Une brèche
Posté par Veiovis . Évalué à 1.
En effet, il peut être intéressant d'attendre qu'une technologie s'améliore ou carrément attendre l'évolution suivante. La question se pose souvent. Par exemple, certains codes ont été écrits en C++ avant que ce dernier ne soit mature. Ils ont pu partir sur de mauvaises bases. Maintenant que le langage est standardisé et que les compilateurs sont d'un tout autre niveau, il est plus aisé de partir sur des bases pérennes.
Il ne faut pas fermer le débat sur un argument fataliste, en invoquant par exemple la sempiternelle bataille des Anciens et des Modernes. Les seconds l'ont souvent emporté, au moins de facto, mais cela n'a pas toujours été une bonne chose.
[^] # Re: Une brèche
Posté par nodens . Évalué à 0.
if ( "Soyons fou" == mode ) {
Ce qui serait classe c'est que pour chaque bout de code du noyau, il y ait une compétition "génétique" darwinienne entre plusieurs algos écrits en différents langages. On aurait alors les meilleurs des meilleurs des meilleurs (citation tirée (et adaptée) de : "Clerks, employés modèles" ).
}//! end "Soyons fous"
tu as une idée de la complexité du code nécessaire pour rassembler tous ces "bouts de code" en un tout cohérent ? il faudrait rajouter une couche supplémentaire pour avoir une API unifiée qui éviterait les écueils d'incompatibilité inévitable (mots réservés, etc).
Ce type d'usine à gaz n'apporterait rien de bon, si ce n'est une baisse des performances et de la stabilité (complexifier le code, c'est augmenter le risque d'avoir des bugs... et surtout, c'est les rendre plus durs à débusquer). D'autant que linux se veut performant et à même d'être employé pour des applications critiques.
Sans parler du fait qu'il faudrait la maintenir, probablement la réécrire souvent (nouveau driver dans un nouveau langage...), et que ça ralentirait beaucoup le dévelopement du noyau proprement dit.
Bref, je veux croire que tu plaisantes et te lances dans un grand délire sans rien de sérieux derrière :)
[^] # Re: Une brèche
Posté par zeSixty4Douille . Évalué à 1.
Sans parler de problemes de perfo du C++, pour le C, avec un bon linker, tu peux aussi faire pas mal de choses qu'il est tres difficile de faire en C++. Interposer des symboles (du VRAI polymorphisme ??? en fonction de l'heure, de l'utilisateur ou autre), ordonner les symboles relativement les uns aux autres dans une lib, vraiment masquer des symboles, surtout, eviter pas mal de trucs que le C++ t'impose.
Enfin, l'approche "OO" n'est pas forcement bonne pour toutes les problematiques. Moi je vois des methodes virtuelles de 6000 lignes, qui monocode leur traitement en fonction du type des arguments ... J'ai meme passe une certification Java, et je peux t'assurer que deja, t'en voies dans les exemples, alors que tu peux tres bien les eviter, avec une architecture + propre en prime.
P-e aussi que les dev du noyau on d'autres choses a faire que se prendre la tete avec la facon dont les compilateurs C++ fonctionnent. Parce que c'est LA qu'est le probleme.
# TCCBoot
Posté par Pinaraf . Évalué à 0.
Ok, je -->[]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.