jeudi 24 juillet

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

Articles précédents : Développeur

Liens connexes

Page sur le patch (739 hits)
Noyau Linux (367 hits)
FAQ linux-kernel : Why don't we rewrite the Linux kernel in C++? (3791 hits)

Dépêche modérée par

pterjan

Dépêche éditée par

Développeur : Patch pour le support du C++ dans le noyau

Posté par Dekany Brice (page perso, ). Modéré le 28 octobre 2004.

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

Page sur le patch (739 hits)
Noyau Linux (367 hits)
FAQ linux-kernel : Why don't we rewrite the Linux kernel in C++? (3791 hits)

> Lire la dépêche (64 commentaires, moyenne: 1,8).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

C++

Posté par farib () le 28/10/2004 à 14:40. (lien). Évalué à 0.

En parlant de noyau, c'est pas justement Darwin qui est en C++ très objet ?

[^]Re: C++

Posté par Guillaume Knispel () le 28/10/2004 à 14:44. (lien). É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 farib () le 28/10/2004 à 15:14. (lien). É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 007 () le 28/10/2004 à 15:21. (lien). Évalué à 1.
    Il est possible d'"enrober" un drivers en C++ dans un module Linux. C'est "ugly".
  - [^]Re: C++
    
    Posté par cykl (Jabber id, ) le 28/10/2004 à 15:29. (lien). É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 lordcow () le 28/10/2004 à 16:52. (lien). Évalué à 3.
      
      http://kerneltrap.org/node/view/2067(...(...))
      
      a signaler que le mini flamewar qui s'ensuit est très interressant..
      
      --
      Je est un autre.
    - [^]Re: C++
      
      Posté par Manuel Menal (page perso, ) le 28/10/2004 à 21:49. (lien). É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 Pierre () le 04/11/2004 à 12:33. (lien). É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 lordcow () le 28/10/2004 à 14:50. (lien). Évalué à 1.
ne confond tu pas avec BeOS?

--
Je est un autre.
- [^]Re: C++
  
  Posté par LupusMic (page perso, ) le 28/10/2004 à 16:27. (lien). Évalué à 3.
  Dont le noyau est écrit en assembleur, les pilotes en C, et l'API graphique en C++...
  - [^]Re: C++
    
    Posté par reno () le 28/10/2004 à 21:39. (lien). É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 lordcow () le 29/10/2004 à 07:52. (lien). É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.. :)
    
    --
    Je est un autre.

[+] [^]Re: C++

Posté par √λιi () le 28/10/2004 à 16:35. (lien). Évalué à -1.
A mes souvenirs, Darwin c'est plutôt Objective-C.

C++ interdit de noyau.

Posté par √λιi () le 28/10/2004 à 16:39. (lien). É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 Raphaël Maurel-Segala () le 28/10/2004 à 16:45. (lien). É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 Erwan (page perso, ) le 28/10/2004 à 17:26. (lien). É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 007 () le 28/10/2004 à 17:41. (lien). É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 Raphaël Maurel-Segala () le 28/10/2004 à 18:17. (lien). É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 007 () le 28/10/2004 à 18:39. (lien). É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 KaZeKaMi (page perso, ) le 28/10/2004 à 19:40. (lien). É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 Larry Cow () le 28/10/2004 à 23:09. (lien). É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 LupusMic (page perso, ) le 29/10/2004 à 07:31. (lien). É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 Pinaraf (Jabber id, ) le 30/10/2004 à 10:25. (lien). É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 zeSixty4Douille () le 31/10/2004 à 13:47. (lien). É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 Pinaraf (Jabber id, ) le 31/10/2004 à 14:02. (lien). É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 007 () le 29/10/2004 à 09:59. (lien). Évalué à -6.
        T'aimes pas KDE ?
        
        [+] [^]Re: C++ interdit de noyau.
        
        Posté par 007 () le 29/10/2004 à 12:23. (lien). É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 Gart Algar (Jabber id, ) le 29/10/2004 à 13:43. (lien). É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 :)
        
        --
        Ubuntu is an ancient african word meaning : "I can't configure Debian"
        
        [^]Re: C++ interdit de noyau.
        
        Posté par Antoine () le 29/10/2004 à 16:07. (lien). É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 Tennis Prono (page perso, ) le 28/10/2004 à 20:04. (lien). É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.
  
  --
  Pas de bureau 3d libre sans drivers libres!
  - [^]Re: C++ interdit de noyau.
    
    Posté par Ramso (page perso, ) le 28/10/2004 à 20:37. (lien). É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).
    
    --
    Groar !
    - [+] [^]Re: C++ interdit de noyau.
      
      Posté par Ayrton () le 28/10/2004 à 21:15. (lien). Évalué à -1.
      C'est kobject.
    - [^]Re: C++ interdit de noyau.
      
      Posté par Christophe Lucas (page perso, ) le 29/10/2004 à 09:20. (lien). Évalué à 2.
      Bah c'est au programmeur de faire cela correctement dans module_exit()
      
      Bonne journée à tous :-)
      
      --
      - Christophe -
    - [^]Re: C++ interdit de noyau.
      
      Posté par Tennis Prono (page perso, ) le 29/10/2004 à 11:26. (lien). É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é).
      
      --
      Pas de bureau 3d libre sans drivers libres!
      - [^]Re: C++ interdit de noyau.
        
        Posté par zeSixty4Douille () le 31/10/2004 à 13:36. (lien). É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 manatane () le 28/10/2004 à 21:28. (lien). É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 Antoine () le 28/10/2004 à 17:22. (lien). É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 Erwan (page perso, ) le 28/10/2004 à 17:30. (lien). É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 Jean Canazzi () le 31/10/2004 à 10:30. (lien). É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 007 () le 31/10/2004 à 10:45. (lien). É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 fabien turmel () le 28/10/2004 à 18:50. (lien). É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 .

--
thegnou

[+] C'est une très mauvaise idée

Posté par Ontologia (page perso, ) le 28/10/2004 à 18:13. (lien). É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.

[^]Re: C'est une très mauvaise idée

Posté par shbrol () le 28/10/2004 à 18:46. (lien). É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 Jean Canazzi () le 31/10/2004 à 10:33. (lien). Évalué à 0.
  C'est effectivement très statique, et c'est d'ailleurs un des nombreux repproches fait au langage par ses détracteurs.

[^]Re: C'est une très mauvaise idée

Posté par manatane () le 28/10/2004 à 21:32. (lien). Évalué à 0.
Eiffel produit du code en C d'ailleurs non?
- [^]Re: C'est une très mauvaise idée
  
  Posté par Snark_Boojum () le 29/10/2004 à 07:02. (lien). É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 Jean Canazzi () le 31/10/2004 à 10:37. (lien). É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 Erwan (page perso, ) le 29/10/2004 à 03:32. (lien). É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 Nicolas Boulay () le 29/10/2004 à 07:29. (lien). Évalué à 0.
  d'ailleurs, une méthode virtual n'est pas hérité correctement selon le sens objet, c'est hyper chiant !
  - [^]Re: C'est une très mauvaise idée
    
    Posté par shbrol () le 29/10/2004 à 10:08. (lien). Évalué à 1.
    tu peux preciser ce que tu entends par "hérité correctement selon le sens objet" ?

[^]Re: C'est une très mauvaise idée

Posté par Tobu () le 31/10/2004 à 05:06. (lien). É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 Ontologia (page perso, ) le 03/11/2004 à 13:42. (lien). É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.

compilation

Posté par cykl (Jabber id, ) le 28/10/2004 à 19:03. (lien). É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 !

[+] [^]Re: compilation

Posté par jimee (page perso, ) le 29/10/2004 à 07:40. (lien). Évalué à -1.
...et automatiquement au boot, en plus!

--
C'est la lutte finale
Groupons-nous et demain...

Et pourquoi pas le noyau en user-space ?

Posté par Obsidian () le 29/10/2004 à 11:59. (lien). É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 :-)

[^]Re: Et pourquoi pas le noyau en user-space ?

Posté par shbrol () le 29/10/2004 à 13:05. (lien). Évalué à 3.
quelque chose comme ca: http://user-mode-linux.sourceforge.net/(...) ?

[^]Re: Et pourquoi pas le noyau en user-space ?

Posté par Snark_Boojum () le 30/10/2004 à 11:34. (lien). Évalué à 3.
Quelque chose comme ça: http://www.l4ka.org(...) ?

(le truc sur lequel le hurd va tourner un jour)

Une brèche

Posté par Veiovis () le 30/10/2004 à 15:37. (lien). É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 007 () le 30/10/2004 à 17:59. (lien). É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 Sebastien Binet () le 31/10/2004 à 10:07. (lien). É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 Veiovis () le 31/10/2004 à 15:03. (lien). É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 nodens (page perso, ) le 03/11/2004 à 22:14. (lien). É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 :)
  
  --
  Clément Hermann (nodens)
  - "L'air pur ? c'est pas en RL, ça ? c'est pas hors charte ?"
  Jean in L'Histoire des Pingouins, http://tnemeth.free.fr/fmbl/linuxsf/
  GPG : pgp.mit.edu - 0xEBD1399D

[^]Re: Une brèche

Posté par zeSixty4Douille () le 31/10/2004 à 14:24. (lien). É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 Pinaraf (Jabber id, ) le 31/10/2004 à 10:51. (lien). Évalué à 0.

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

Ok, je -->[]

Revenir en haut de page

Articles précédents : Développeur

Liens connexes

Dépêche modérée par

Dépêche éditée par

Développeur : Patch pour le support du C++ dans le noyau

C++

[^]Re: C++

[^]Re: C++

[^]Re: C++

[^]Re: C++

[^]Re: C++

[^]Re: C++

[^]Re: C++

[^]Re: C++

[^]Re: C++

[^]Re: C++

[^]Re: C++

[+] [^]Re: C++

C++ interdit de noyau.

[^]Re: C++ interdit de noyau.

[^]Re: C++ interdit de noyau.

[+] [^]Re: C++ interdit de noyau.

[^]Re: C++ interdit de noyau.

[+] [^]Re: C++ interdit de noyau.

[^]Re: C++ interdit de noyau.

[^]Re: C++ interdit de noyau.

[^]Re: C++ interdit de noyau.

[^]Re: C++ interdit de noyau.

[^]Re: C++ interdit de noyau.

[^]Re: C++ interdit de noyau.

[+] [^]Re: C++ interdit de noyau.

[+] [^]Re: C++ interdit de noyau.

[^]Re: C++ interdit de noyau.

[^]Re: C++ interdit de noyau.

[^]Re: C++ interdit de noyau.

[^]Re: C++ interdit de noyau.

[+] [^]Re: C++ interdit de noyau.

[^]Re: C++ interdit de noyau.

[^]Re: C++ interdit de noyau.

[^]Re: C++ interdit de noyau.

[^]Re: C++ interdit de noyau.

DLFP: Poster un commentaire

[^]Re: DLFP: Poster un commentaire

[^]Re: DLFP: Poster un commentaire

[^]Re: DLFP: Poster un commentaire

[^]Re: DLFP: Poster un commentaire

[+] C'est une très mauvaise idée

[^]Re: C'est une très mauvaise idée

[^]Re: C'est une très mauvaise idée

[^]Re: C'est une très mauvaise idée

[^]Re: C'est une très mauvaise idée

[^]Re: C'est une très mauvaise idée

[^]Re: C'est une très mauvaise idée

[^]Re: C'est une très mauvaise idée

[^]Re: C'est une très mauvaise idée

[^]Re: C'est une très mauvaise idée

[^]Re: C'est une très mauvaise idée

compilation

[+] [^]Re: compilation

Et pourquoi pas le noyau en user-space ?

[^]Re: Et pourquoi pas le noyau en user-space ?

[^]Re: Et pourquoi pas le noyau en user-space ?

Une brèche

[^]Re: Une brèche

[^]Re: Une brèche

[^]Re: Une brèche

[^]Re: Une brèche

[^]Re: Une brèche

TCCBoot