« Autocompiler » son noyau au démarrage avec TCCBoot

Posté par  (site web personnel) . Modéré par Benoît Sibaud.
Étiquettes :
0
27
oct.
2004
Noyau
À ceux qui trouvent que le noyau Linux démarre bien trop vite, Fabrice Bellard propose une solution : TCCBoot. Il s'agit d'un petit noyau (indépendant de Linux) qui contient le petit-compilateur C "TCC" du même F. Bellard. Une fois chargé, celui-ci compile les sources qu'on lui fournit dans une image ROMFS et exécute le binaire résultant. Si les sources en question sont celles du noyau Linux... alors TCC compile Linux à chaque démarrage.

Ça ne sert à rien mais c'est beau !

Aller plus loin

  • # plop

    Posté par  . Évalué à 8.

    Absolument indispensable

    • [^] # Re: plop

      Posté par  . Évalué à 10.

      « Rigoureusement inutiles donc absolument indispensables »
      -- Jérome Bonaldi, NPA 1999

      Ce grand philosophe des catastrophes live'ienne :)

      • [^] # Re: plop

        Posté par  . Évalué à 5.

        Si mes souvenirs sont bons...
        - il était dans les premiers arrivés dans NPA, il devait avoir sa propre émission le midi vers 1999 => Ca doit dater de vachement plus tot !!
        - C'est : "Totallement inutile donc rigoureusement indispensable"

        Note : Il a surement du en faire qq variantes ;-)

        Respect pour le plus grand disciple de Murphy :)
        De plus, il continue de se meler de tout à notre plus grand plaisir : https://linuxfr.org/2004/10/21/17476.html(...)

      • [^] # Re: plop

        Posté par  . Évalué à 8.

        Si la compile du noyau au boot semble effectivement assez futile, tcc lui même ne l'est pas :
        • C script supported : just add '#!/usr/local/bin/tcc -run' at the first line of your C source, and execute it directly from the command line.
        • With libtcc, you can use TCC as a backend for dynamic code generation.
        Ça ça peut clairement avoir des vraies applications. À noter aussi que tcc inclue un memory & bounds checker (un machin pour vérifier qu'on se gauffre pas dans l'utilisation des tableaux et pointeurs), ce qui fait défaut à gcc (enfin pas vraiment, le patch est là : http://web.inter.nl.net/hcc/Haj.Ten.Brugge/(...) ). Et ça, c'est Bien™.

        • [^] # Re: plop

          Posté par  . Évalué à 5.

          C script supported : just add '#!/usr/local/bin/tcc -run' at the first line of your C source, and execute it directly from the command line.

          Ça ne doit pas être bien compliquer à faire avec gcc ça...
          Avec un bon petit script qui supprime la première ligne du fichier et qui compile puis exécute dans un répertoire temporaire, y'a rien d'exceptionnel...

          With libtcc, you can use TCC as a backend for dynamic code generation.

          Ça parcontre, ça semble plus intéressant, bien que, avec un script du même style, tu recompiles tes sources et tu charges le merdier avec un dlopen...

  • # Débugage

    Posté par  . Évalué à 6.

    Limite, ça peut être pratique pour le débuguage. Un fichier pose problème? On monte l'image, on édite, on démonte puis reboot. Encore un pb, idem...

  • # CD live ?

    Posté par  . Évalué à 8.

    À quand un CD live avec OOo, KDE, y tout, qui se compile au boot ?

    • [^] # Re: CD live ?

      Posté par  . Évalué à 10.

      Ah il marche pas comme ça le live CD de gentoo ? je suis deçu ...

      • [^] # Re: CD live ?

        Posté par  . Évalué à 3.

        c'est malin, j'ai éclaté de rire comme un con devant mon écran

      • [^] # Re: CD live ?

        Posté par  . Évalué à -5.

        Certes c'est très drôle, mais doit-on plusser le caractère comique d'un commentaire ou son coté pertinent relativement à l'article ?

        • [^] # Re: CD live ?

          Posté par  . Évalué à 8.

          doit-on plusser le caractère comique d'un commentaire ou son coté pertinent relativement à l'article


          ... Ou, pourquoi pas, le plusser pour son caractère comique relativement à l'article ?

          Ce qui pose la grande question : le comique contextuel existe-t-il? "Oui !", répondront en masse les Desprogiens. ("42", s'exclameront les lecteurs peu attentifs)

          Bref, dans la veine comique, c'est tout de même F. Bellard qui a commencé, non ?

          • [^] # Re: CD live ?

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

            Ce qui pose la grande question : le comique contextuel existe-t-il? "Oui !", répondront en masse les Desprogiens. ("42", s'exclameront les lecteurs peu attentifs)

            Ook.

            N'empêche, ça peut être relativement utile pour frimer devant ses copains, ça : "je recompile mon noyau toutes les semaines, ça m'évite de rouiller" :P

            • [^] # Re: CD live ?

              Posté par  . Évalué à 3.

              De toute façon, n'est-on pas sensé ne rebooter que pour changer de noyau ? :)
              De ce point de vue là, ça économise des lignes de shell, ce genre de programme/concept.
              Il pourrait même être bon d'intégrer ce genre de truc dans les bécanes pour parfaire la portabilité : le bios ou équivalent compile un bootloader qui se charge de charger et/ou compiler la suite, etc.

              • [^] # Re: CD live ?

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

                Oui, enfin, bon, je suis quand même pas un pur, un dur, un tatoué : ça m'embêterait que mon noyau se recompile chaque fois qu'il y a une coupure de courant !
                Comment ça, "petit joueur" o_O ?:-D

          • [^] # Re: CD live ?

            Posté par  . Évalué à 4.

            > Ce qui pose la grande question : le comique contextuel existe-t-il?

            Ben oui, c'est le comique de situation.

        • [^] # Re: CD live ?

          Posté par  . Évalué à 1.

          Je vois que certains utilisateurs de linuxfr ont du mal à s'exprimer avec des mots pour répondre à une question pas très compliquée et préfèrent moinser, ça doit faire partie du coté comique... "Moi moinser ! é Rigolo !"

          Merci Mercurial de t'être réellement posé la question.

    • [^] # Re: CD live ?

      Posté par  . Évalué à 7.

      Il y a déjà un live CD qui contient TCC (mais qui ne s'autocompile pas). Il s'agit de Damn Small Linux (http://damnsmalllinux.org(...)), le live-CD de moins de 50Mo. Et quand on le copie en RAM, ca booooste !

      Pour ceux qui auraient raté les épisodes précédents, je précise que le Sieur Bellard code comme un malpropre : il avait en effet remporté l'IOCCC (pour la seconde fois) avec la première version de TCC ;-)
      Et en plus, dans la catégorie "best abuse of the rules" ! Respect.
      http://ioccc.org(...)
      http://www.de.ioccc.org/years.html#2001_bellard(...)

  • # Vive le C !!

    Posté par  . Évalué à 2.

    Ca sert a prouver que le C c'est cool.

    c'est tellement hasbeen de ne pas utiliser de templates de nos jours .. Moi je m'en vais customiser le noyau avec la STL, histoire de rajouer un peu de temps au temps au boot.

    • [^] # Re: Vive le C !!

      Posté par  . Évalué à 0.

      Juste pour info, ton noyau tourne sur une VM ?

      • [^] # Re: Vive le C !!

        Posté par  . Évalué à 3.

        yes ofcourse, il depend de .NET, mais il est portable, dans un disque dur .. (VM = Machine virtuelle ??)

    • [^] # Re: Vive le C !!

      Posté par  . Évalué à 0.

      "-4" pour dire que le C c'est cool, ca laisse reveur.

      J'ai pas dit que la STL puait, la j'aurais certainement tord. Je sous entends simplement que c'est parfois long a compiler. Vous pouvez toujours moinsser, mais c'est un fait. Une forward declaration avec les Standard iostreams, c'est 3000 ligne de header quand meme ...

  • # Fabrice Bellard

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

    Quand je vois le travail de Fabrice Bellard, je suis à la fois admiratif et jaloux... Qemu, TCC, Qemacs, FFMPEG et maintenant TCC Boot ...

    Incroyable.

    • [^] # Re: Fabrice Bellard

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

      Ué une fois j'etais passé sur sa page d'accueil
      Deja qemu tt seul j'etais impressionné
      page d'accueil:
      qemu & ffmpeg & plein de "petits" trucs a cote
      et maintenant ca
      pour moi c'est un dieu lui!
      J'exagere ptet un tantinet mais quand meme

      • [^] # Re: Fabrice Bellard

        Posté par  . Évalué à 3.

        Et je crois que ça date pas d'hier, il me semble avoir utilisé il y a longtemps un éditeur télétexte écrit par lui pour faire des pages pour un serveur RTC. Je sais plus comment s'appellait l'appli par contre.

    • [^] # Re: Fabrice Bellard

      Posté par  . Évalué à 5.

      Quand je vois le travail de Fabrice Bellard, je suis à la fois admiratif et jaloux... Qemu, TCC, Qemacs, FFMPEG et maintenant TCC Boot ...

      J'ai connu par hasard ce type qui était un camarade de mon frère. En 1995 on était allé dans sa chambre d'étudiant, où j'avais vu mon premier Linux, il tournait sous X11 et j'avais été impressionné par quelques démos, voire des jeux (à l'époque j'étais sur Amiga, et là sur Linux on pouvait bouger une fenêtre et le contenu continuait à se rafraîchir).

      Quand j'avais lu dans une revue scientifique qu'un record concernant les décimales de Pi était tombé (avec un développement en série original, en binaire), j'ai vu son nom et je m'étais demandé si c'était le même; eh bien oui ! Cf http://fabrice.bellard.free.fr/pi/(...) et "A world record ! The 1000 billionth binary digit of Pi is '1'".
      Ce type est impressionnant de productivité, ffmpeg est déjà un beau morceau.

  • # Commentaire supprimé

    Posté par  . Évalué à 6.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Impressionnant !

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

      M'enfin, quels sont les inconvénients de TCC pour qu'il n'ait pas remplacé GCC ? Il y en a forcément, non, ce serait trop simple...

      Quelqu'un a une idée ?

      • [^] # Re: Impressionnant !

        Posté par  . Évalué à 7.

        GCC n'est pas qu'un compilateur C, mais une suite de compilation "générique" qui sait également bouffer du C++, du Java, du Fortran, ...

        Et puis aussi, des choses comme ça:

        TCC implements many features of the new C standard: ISO C99. Currently missing items are: complex and imaginary numbers and variable length arrays.

        Et enfin le fait que, si TCC est léger et compile vite, il n'est pas garanti du tout que le code produit soit plus efficace que celui écrit par GCC.

        TCC est une très jolie démonstration du savoir-faire du monsieur (même si QEmu et FFMpeg sont plutôt plus significatifs, à mon avis), ainsi qu'un outil de plus dans la malette de l'utilisateur de logiciel libre. Un outil qui peut s'avérer utile dans certains cas, peu fréquents certes, mais qui mérite tout de même d'exister.

      • [^] # Re: Impressionnant !

        Posté par  . Évalué à 3.

        Au hasard, que GCC fonctionne sur un cinquantaine d'architectures ?
        (Je dis ça au pif.)

        Tiens ça me rappelle des discu^Wtrolls sur Debian...

    • [^] # Re: Impressionnant !

      Posté par  . Évalué à -5.

      > TCC peut compiler un noyau Linux classique en moins de 15 secondes

      Un noyau classique... C'est celà oouuiii...

      > TCCBOOT is only 138 KB big (uncompressed code)

      Ben ici le tar décompressé de Linux 2.6.9 fait 196 Mo ! Plus de mille fois plus.

      Rien que pour lire l'archive (un gros fichier et pas des milliers de fichier) en 15 seconde il faut la "bouffer" à plus de 10 Mo/s.

      • [^] # Re: Impressionnant !

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

        quand tu compile le noyau tu compile *TOUT*?
        Et pis bon faut voir ce qu'il compile
        S'il compile à partir des sources deja compilé
        et rajoute une option
        Prendre 15s c'est plus que possible

        • [^] # Re: Impressionnant !

          Posté par  . Évalué à -4.

          > Prendre 15s c'est plus que possible

          Pour un noyau "classique" comme c'est indiqué ?
          Mon vmlinuz (compressé) "classique" (de la distribution) fait 1.4 Mo et j'ai 31 Mo de modules.
          Mon vmlinuz au petit oignons fait 930 Ko et j'ai 2.5 Mo de modules. 15 secondes pour mon noyau customiser, je n'y crois pas 0,0002 quart de seconde.

          Arrêter les cigarettes qui font rire.

      • [^] # Re: Impressionnant !

        Posté par  . Évalué à 1.

        ce doit etre sans les modules. Chez moi, avec uCLinux, le noyau n'est que de 800ko, les sources conscernees ne doivent pas representer tellement plus.

      • [^] # Re: Impressionnant !

        Posté par  . Évalué à 1.

        Marrant moi mon noyau fait ~3.5Mo non compresser (et pas 196), a mon avis tu as confondu avec le code source du noyau.

      • [^] # Re: Impressionnant !

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

        Rien que pour lire l'archive (un gros fichier et pas des milliers de fichier) en 15 seconde il faut la "bouffer" à plus de 10 Mo/s.

        Oui, sauf qu'un compilateur ne lit pas des archives, mais des fichiers .c par exemple. De plus, pour compiler un noyeau pour une archi, certains fichiers ne vont pas etre lu par le compilateur, par exemple les fichiers des autres architectures.

        Enfin, voici les resultats de TCC pris de http://fabrice.bellard.free.fr/tcc/(...) :
        Compiler             Time(s)     lines/second MBytes/second 
        
TinyCC 0.9.14     12.1         134000         4.8 
        
GCC 2.95.2 -O0  103.0       16000           0.56 
        
GCC 3.2 -O0       111.4       15000           0.52 
        
Measures were done on a 500 MHz K6. Real time is measured. Compilation time includes compilation, assembly and linking.


        Donc avec une machine plus recente, il doit surement etre possible d'aller au dela des 4.8MB/s.

        • [^] # Re: Impressionnant !

          Posté par  . Évalué à -2.

          Pour :
            Compilation speed for the Links Browser project. There are 76936 lines (including headers). 1632659 lines (57.9 MBytes) are compiled because the same headers are included in many files.


          Notes que _tout_ tient dans le cache.
          Ça doit beaucoup jouer sur le temps de chargement de gcc.
          Le 4.8 Mo/s est en tenant compte de la _relecture_ des entêtes.
          Soit (sans compter la relecture des headers) : 0.226 Mo/s (beau score) !
          Pour Linux (en imaginant qu'on peut extrapoler car Linux est beaucoup plus complexe que links) à ce rythme, il faut 867 secondes (14 minutes et 27 secondes).

          Je ne critique pas TCC, c'est peut-être un truc super. Mais il ne faut pas "n'importe quoi".

      • [^] # Re: Impressionnant !

        Posté par  . Évalué à 3.

        > Rien que pour lire l'archive (un gros fichier et pas des milliers de
        > fichier) en 15 seconde il faut la "bouffer" à plus de 10 Mo/s.

        Nan mais je suppose qu'on parle là de temps CPU, sans les IO. Après tout, c'est ça qui compte pour comparer les perfs d'un compilo ; tu comptes juste le parsing et la génération du code binaire.

        (Enfin en simplifiant, parceque en fait des compilateurs peuvent aussi se différencier avec des astuces limitant entre autres les IO redondantes, comme les multiples relecture d'un même header.)

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 5.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Impressionnant !

          Posté par  . Évalué à 4.

          > abstient toi de dénigrer gratuitement son travail.

          Où tu vois ça ?
          Je dis qu'il ne faut pas 15 secondes pour compiler un noyau linux classique.
          Je suis sûr que TCC ne fait pas ça.
          L'image initrd décompressée avec les sources linux à compiler fait 18Mo (compilateur compris) ! Linux en fait 10 fois plus.
          Les sources dans l'image font : 399 742 (251 fichiers ".c")
          Linux 2.6.9 (non, je ne vais pas downloader le 2.4.18 pour ça) : 6 463 002 (6841 fichiers ".c")

          Le README :
          http://fabrice.bellard.free.fr/tcc/tccboot_readme.html(...)
            For your information, the patch 'linux-2.4.26-tcc.patch' gives the
            necessary modifications to build a Linux kernel with TCCBOOT (NOTE: it
            is not suffisant to build the kernel with its own Makefiles             - I never
            tried)

          Voilà comment est compilé le noyau :
            # This file contains the TinyCC command line arguments needed to
            # produce the kernel.

            # the output binary (DO NOT CHANGE IT)
            -o kernel
            # LDFLAGS
            -nostdlib -static -Wl,-Ttext,c0100000 -Wl,--oformat,binary
            # CFLAGS
            -D__KERNEL__ -nostdinc -Iusr/local/lib/tcc/include -Iusr/src/linux/include
            -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__OPTIMIZE__ -fno-common
            # sources files
            usr/src/linux/tcc/kstart.S
            usr/src/linux/arch/i386/kernel/head.S
            usr/src/linux/arch/i386/kernel/init_task.c
            ...

          Pas de dépendances, etc...

          Je ne critique pas son boulot _ni_ ne remets en cause ses chiffres, _ni_ sont exploit !

          Par contre l'interprétation de certains "Super, je vais pouvoir compiler mon noyau en 15 seconde avec TinyCC" m'énerve.


          C'est chiant de devoir toujours se justifier pour des trucs aussi évidents.

          • [^] # Re: Impressionnant !

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

            C'est chiant de devoir toujours se justifier pour des trucs aussi évidents.

            Si tu t'exprimais correctement aussi ... les gens te comprendraient.

            Tu es un incompris.

            • [^] # Re: Impressionnant !

              Posté par  . Évalué à 2.

              > Si tu t'exprimais correctement aussi ... les gens te comprendraient.

              J'ai été claire (il me semble).

              La différence c'est que les autres disent qu'il est normal de compiler un noyau "classique" en 15 secondes et n'ont pas à le prouver.
              Moi je dois prouver noir sur blanc que ce n'est pas possible alors que c'est évident.

              Cherchez l'erreur.

              • [^] # Re: Impressionnant !

                Posté par  . Évalué à 4.

                J'ai été claire (il me semble).

                Je croyais que tu etais 007.

              • [^] # Re: Impressionnant !

                Posté par  . Évalué à 2.

                Bah ca a rien d'impressionnant de compiler aussi rapidement, maintenant c'est sur que le code généré est surrement tres tres peu optimisé. Je me souviens que Turbo C etait ultra rapide sur un 486 avec un cache disque quand je codais sous DOS.

                Quand a savoir ce qu'il faut à un noyau pour etre classique...

          • [^] # Re: Impressionnant !

            Posté par  . Évalué à 1.

            > Les sources dans l'image font : 399 742 (251 fichiers ".c")

            Ooops :
            Les sources dans l'image font : 399 742 lignes (251 fichiers ".c")

  • # Pas moi!

    Posté par  . Évalué à 0.

    Je sais que c'est une blague mais "À ceux qui trouvent que le noyau Linux démarre bien trop vite", je n'en fais pas parti: apres avoir testé BeOS qui mettait ~20s pour arriver en mode graphique contre 1+min pour Linux (avec KDE, j'ignore si Gnome démarre plus vite)..

    C'était sur un Céléron 333 à l'époque, mais bref, je ne trouve pas que Linux demarre trop vite!

    Et BeOS ne trichait pas comme WindowsXP: il était immédiatement utilisable dès que l'interface graphique donnait la main..

    • [^] # Re: Pas moi!

      Posté par  . Évalué à 3.

      Ici on parle du noyau Linux. C'est à dire juste avant le démarrage du premier process ('init' ou 'linuxrc' pour une ramdisk).

    • [^] # Re: Pas moi!

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

      Si tu vire tout les trucs absolument inutile, tu peux réduire le temps de boot, 30s pour une LFS brute de décoffrage (bon sans KDE, juste X et oroborus) sur un Duron 600

      • [^] # Re: Pas moi!

        Posté par  . Évalué à 2.

        Bin oui, mais être "juste", il faut comparer des choses comparables..

        Je trouve que le desktop de BeOS et KDE sont a peu pres équivalent, j'avoue ne pas connaitre oroborus..

        Et puis pour BeOS je n'avais rien eu à faire, pas de recompilation rien, pas de daemon à virer, ce qui est quand même différent d'une LFS.

      • [^] # Re: Pas moi!

        Posté par  . Évalué à 1.

        Concernant le temps de boot, pour mon juke-box de voiture il y a +/- 35 secondes entre le moment où le PC s'allume et le moment où il joue le premier morceau.

        Là où il perd le plus de temps, c'est dans le BIOS et dans syslinux lors du chargement du kernel et du ramdisk à partir de la CompactFlash.

        Faut dire que j'ai aussi triché un peu:
        - busybox dans le ramdisk
        - le /usr n'est pas sur le ramdisk: il est dans un autre fichier sur la flash qui est monté par après (Goret powah !!)
        - J'ai un serveur X avec XMMS sans WM, arraché de ma Woody avec un script maison.

        J'estime pouvoir gagner environ 5 secondes si je vire l'image de la bootrom PXE du bios à coups de CBROM et 5 à 10 autres secondes si je fous le /lib dans le fichier du /usr (Encore plus goret... :-P)

  • # "Ça ne sert à rien mais c'est beau !"

    Posté par  . Évalué à 1.

    Quand bien même sa ne servirait a "rien", le seul fait que ca soit beau permet de prouver (encore une fois) la puissance des solutions libres et de Linux et ca c'est toujours utile.

    Après, vu l'augmentation des débits de connexion et des processeurs, on pourrait imaginé un micro noyau qui va chercher les sources du noyau, les compiles, le boot, puis va chercher quelques soft. A tout casser, ca doit tenir dans 300Ko au début !!
    (Bon c'est juste une idée comme ca, je n'ai pas le temps de bosser dessus en ce moment)

    Bravo quand même.

  • # Plus besoin d'un noyau modulaire ?

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

    A quoi servent les modules alors maintenant ?

    Il ne reste qu'à faire un programme qui détecte le matériel et produit le fichier .config pour compiler le kernel, le tout au boot : ce qui fait qu'on a toujours un noyau monolithique mais avec les modules utiles uniquement . Si on rajoute du matériel, on reboote et un nouveau noyau est généré en fonction de sa config qui a changée.

    Pour faire ce programme, il y a un bon nombre de routines de détection de matériel qu'on peut reprendre directement... du noyau.

    Avis aux amateurs !

Suivre le flux des commentaires

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