Patch pour le support du C++ dans le noyau

Posté par  . Modéré par Pascal Terjan.
0
28
oct.
2004
Noyau
Des étudiants de l'université de Reykjavik (Islande), viennent de créer un support du C++ pour le noyau.
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

  • # C++

    Posté par  . Évalué à 0.

    En parlant de noyau, c'est pas justement Darwin qui est en C++ très objet ?
    • [^] # Re: C++

      Posté par  . Évalué à 3.

      La dernière fois que j'ai regardé darwin, je crois que c'etait un OS complet et non un noyau, et son noyau XNU etait bel et bien en C...
      • [^] # Re: C++

        Posté par  . Évalué à 1.

        Bon, je me suis emmelé les pinceaux et j'ai dit n'importe quoi


        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  . Évalué à 1.

          Il est possible d'"enrober" un drivers en C++ dans un module Linux. C'est "ugly".
        • [^] # Re: C++

          Posté par  . Évalué à 5.

          Tu peux bien ecrire des drivers I/O en (un sous ensemble du) C++ via l'I/O kit.
          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  . É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  . Évalué à 1.

            Juste pour la remarque, quand même : xnu, le noyau de Darwin, contient également les fondements de l'IOKit, donc toutes les interfaces et le code C++ qu'il contient. Qui plus est, il contient aussi une partie des drivers utilisant l'IOKit, donc une très, très grande partie est faite en C++ (et ça marche aussi pour les drivers externes).
            (évidemment, je ne compte pas la libkern en C++. Il est évident qu'elle devait s'y trouver.)

            Voili, voilà.
            • [^] # Re: C++

              Posté par  . Évalué à 2.

              Plus exactement l'IOKit est écrit en Embedded-C++, un sous-ensemble du C++ (sous la forme d'une norme) qui retire les fonctionnalités coûteuses tout en gardant les principaux avantages objet du C++. Ce qui en fait un langage tout à fait sérieux pour la programmation système.

              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  . Évalué à 1.

      ne confond tu pas avec BeOS?
      • [^] # Re: C++

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Dont le noyau est écrit en assembleur, les pilotes en C, et l'API graphique en C++...
        • [^] # Re: C++

          Posté par  . Évalué à 4.

          Tu as un lien pour "le noyau est écrit en assembleur"?

          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  . Évalué à 1.

          Ah oui?
          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  . Évalué à -1.

      A mes souvenirs, Darwin c'est plutôt Objective-C.
  • # C++ interdit de noyau.

    Posté par  . Évalué à 5.

    Sinon il est peu probable qu'il soit incorporé au noyau officiel

    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  . Évalué à 3.

      Puisque le sujet "à quoi ça sert" vient d'être évoqué, le non-informaticien raplique pour s'enquérir des détails.
      Bon, ce serait quoi, l'intérêt de supporter le C++ dans le noyau ?
      • [^] # Re: C++ interdit de noyau.

        Posté par  . Évalué à 7.

        Ca servira a ceux qui preferent le C++ au C d'ecrire des modules dans un langage qu'ils preferent. C'est tout. C'est comme les bindings C++ de Gtk/Gnome, ca ne permet pas d'ajouter des "killer features" mais juste d'apporter du confort a certains developpeurs.
      • [^] # Re: C++ interdit de noyau.

        Posté par  . Évalué à -10.

        > Bon, ce serait quoi, l'intérêt de supporter le C++ dans le noyau ?

        Excellente question.
        Fesons une analogie.
        KDE => C++
        Gnome => C

        Voilà, tu as ta réponse.
        • [^] # Re: C++ interdit de noyau.

          Posté par  . Évalué à 9.

          Magnifique. Du grand art, je suis sincèrement admiratif.

          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  . Évalué à -10.

            > Mais je suis pas sûr de très bien comprendre.

            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  (site web personnel) . Évalué à 1.

              >Si t'as toujours pas compris quel est le meilleur des deux languages

              la réponse est bien sûr le Java
            • [^] # Re: C++ interdit de noyau.

              Posté par  . Évalué à 7.

              Si tu n'as toujours pas compris qu'un langage ne pouvait être le meilleur que pour un (ou plusieurs, certes) domaine donné... si tu n'as toujours pas compris ce qui dérange certaines personnes dans le C++... c'est peut-être que tu n'en as pas fait suffisament.

              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  (site web personnel, Mastodon) . Évalué à 5.

                > 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.

                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  . Évalué à 1.

                  Et il me semble qu'avec QT4 on verra une certaine évolution de ce point de vue là (utilisation des templates, des namespace...)
                  • [^] # Re: C++ interdit de noyau.

                    Posté par  . Évalué à 1.

                    c'est vraiment dommage ... J'espere pas qu'il considere cela comme la killer feature de Qt4. Cependant je suis persuade que les gars qui ont fait Qt s'y connaissent vraiment en compilateur.

                    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  . Évalué à 1.

                      Les killer features de Qt4 sont trop nombreuses (enfin par rapport à Qt3 je suppose que d'autres libs concurrentes de Qt ont déjà certaines de ces features).
                      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  . Évalué à -6.

                T'aimes pas KDE ?
                • [^] # Re: C++ interdit de noyau.

                  Posté par  . Évalué à -2.

                  Les gens n'ont pas d'humour. Je n'ai dit pas que le C était meilleur que le C++ ou l'inverse.
                  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  . Évalué à 6.

                    Je l'ai dit et vous le démontrez avec la pluie de [-] que j'ai reçu.

                    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  . Évalué à 5.

                    Même si on ne dit rien.

                    Apparemment le problème est surtout que tu ne dis rien...
      • [^] # Re: C++ interdit de noyau.

        Posté par  (site web personnel) . Évalué à 3.

        Bon, ce serait quoi, l'intérêt de supporter le C++ dans le noyau ?
        Utiliser des destructeurs pour s'assurer que tout est bien nettoyé quand tu sors d'une fonction.
        • [^] # Re: C++ interdit de noyau.

          Posté par  . Évalué à 4.

          Je suis sûr qu'il y a l'équivalent des destructeurs dans l'API du noyau et qui est appelé par exemple quand on retire un module (rmmod).
          • [^] # Re: C++ interdit de noyau.

            Posté par  . Évalué à -1.

            C'est kobject.
          • [^] # Re: C++ interdit de noyau.

            Posté par  (site web personnel) . Évalué à 2.

            Bah c'est au programmeur de faire cela correctement dans module_exit()

            Bonne journée à tous :-)
          • [^] # Re: C++ interdit de noyau.

            Posté par  (site web personnel) . Évalué à 2.

            Avec un destructeur d'objec C++ construit sur la pile, tu peux faire plein de trucs pratiques comme prendre un mutex dans un bloc de code et le libérer à la fin.

            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  . Évalué à 1.

              moi je vois un probleme dans ce type de code : tu ne sais pas QUAND ton mutex est desalloue. Si tu as plusieurs objects automatiques, dans quel ordre sont appeles les destructeurs (pas simplement dans l'ordre inverse d'allocation) ?

              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  . Évalué à 4.

          Bin justement un reproche fait au C++ dans la programmation d'un système d'exploitation : any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
  • # DLFP: Poster un commentaire

    Posté par  . Évalué à 0.

    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

    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  . Évalué à 6.

      T'as pas lu le lien. Dedans il y a une question (avec sa reponse): Why not add a C++ interface layer to the kernel to support C++ drivers?

      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  . Évalué à 2.

        A ce propos, la FAQ est d'd'une rare mauvaise foi :

        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  . Évalué à 1.

          C'est oublier la nature libre de Linux.
          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  . Évalué à 3.

      Ce n'est pas aussi simple que ça.

      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  (site web personnel) . Évalué à -2.

    C++ est un langage relativement lent, car en tant que langage à objet classique il est basé sur la liaison dynamique..

    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  . Évalué à 6.

      C++ est un langage relativement lent, car en tant que langage à objet classique il est basé sur la liaison dynamique..

      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  . Évalué à 0.

      Eiffel produit du code en C d'ailleurs non?
      • [^] # Re: C'est une très mauvaise idée

        Posté par  . Évalué à 2.

        Eiffel ne produit rien, c'est un langage. Par contre, le compilateur smarteiffel produit du code C, oui.

        Snark sur #eiffel
        • [^] # Re: C'est une très mauvaise idée

          Posté par  . Évalué à 2.

          A ce propos, le premier compilateur C++, écrit par son inventeur Bjarne Stroustrup, produisait aussi du code C.

          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  . Évalué à 1.

      Il faut preciser explicitement "virtual" sur les methodes pour que la resolution soit dynamique.
    • [^] # Re: C'est une très mauvaise idée

      Posté par  . Évalué à 2.

      En même temps le polymorphisme nécessite l'indirection des méthodes (alias liaison retardée). Sans polymorphisme ce n'est pas vraiment de l'OO, c'est plus du sucre syntaxique autour de choses que l'on peut faire en C avec des struct et un this en premier argument.
      • [^] # Re: C'est une très mauvaise idée

        Posté par  (site web personnel) . Évalué à 1.

        Ce qui confirme ce que je disais, soit il n'y a pas d'OO et c'est effectivement du "sucre syntaxique" qui, cela dit, peut simplifier la vie du dev, dans ce cas pourquoi pas, mais dès qu'il y a polymorphisme, donc oo, il y a liaison dynamique, d'où le problème.

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # compilation

    Posté par  . Évalué à 8.

    Ca tombe bien ! Deux news plus bas on apprennait qu'on pouvait compiler son noyau en 15 secondes maintenant qu'il y a du C++ on va pouvoir le compiler en 15 heures !

    Aïe patapai !
  • # Et pourquoi pas le noyau en user-space ?

    Posté par  . Évalué à 2.

    Pourquoi ne pas réécrire le noyau en C++ ?

    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 :-)
  • # Une brèche

    Posté par  . Évalué à 3.

    Voilà une très bonne initiative!

    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  . Évalué à 0.

      > Il existe une communauté qui souhaite rester sur de vieilles méthodes

      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  . Évalué à 3.

      Je souhaite autant de longévité au noyau Linux que Fortran77 dans le monde scientifique, mais il faut bien se rendre à l'évidence que le C ne sera pas toujours la panacée.
      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  . Évalué à 1.

        J'ai proposé quelques éclairages qui n'étaient pas proprement technologiques, comme la mise en perspective historique. Tu rappelles que, dans la perspective historique, le C++ est à son avantage technologiquement. Je modérais en considérant qu'il n'était pas facile de changer. Je voudrais maintenant ajouter qu'il y a aussi un moment propice pour le changement.

        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  . É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  . Évalué à 1.

      Si certaines personnes souhaitent rester avec Fortran 77, c'est pour des raisons techniques. Tu n'imagines pas ce que l'on peut demander a un bon compilateur Fortran.

      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  . Évalué à 0.

    TCCBoot il compilera toujours le noyau en moins de 30 secondes au boot avec ce patch ?


    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.