Sortie du noyau 2.6.11

Posté par . Modéré par Nÿco.
0
2
mar.
2005
Noyau
Ce noyau apporte une grande liste de mises à jour : pilotes ACPI, architecture DRI, pilotes ALSA, SCSI et système XFS font partie des chantiers qui devraient (encore) mieux fonctionner.

L'architecture de bus InfiniBand est prise en charge dans ce nouveau noyau : c'est apparemment une alternative au bus PCI où les données sont transmises en série et en multiplexage, au lieu d'être transmises en parallèle, ceci ne concernant pour l'instant que les serveurs « high-end » et certains PC.
  • # whaouh! j ai hate d essayer çà !!

    Posté par . Évalué à 6.

    Ce soir c'est soirée compilation!!
    avec mon ibm t42, lire cette phrase :
    "Ce noyau apporte une grande liste de mises à jour : pilotes ACPI, [..]"
    c'est que du bonheur, non pas que l'ACPI ne focntionnait pas jusqu'à présent, non, juste que peut être le déréglage de l'horloge et l usb qui saute en retour de suspend auront peut etre disparus...
    allez, bon "make menuconfig" à tous !
    • [^] # Re: whaouh! j ai hate d essayer çà !!

      Posté par . Évalué à 4.

      tout pareil avec le x31 (devenue une excroissance permanente de mon anatomie ;-)

      je suis un peu las de devoir décharger tous les modules usb avant de partir en suspend ou en hibernation (sans assurance d'ailleurs que ça refonctionnera au resume).

      /me's going to pray...
      • [^] # testé ok sur un laptop AmiloA

        Posté par (page perso) . Évalué à 5.

        j'ai pas encore testé le swsuspend, mais j'ai trouvé une regression ?

        le "double tap" ne marche plus comme click gauche, mais y a un param de boot peut etre : mousedev.tap_time

        sinon des patchsets sympatoches a l'horizon pour le 2.6.11 ?

        A suivre...

        gpg:0x467094BC

        • [^] # Re: testé ok sur un laptop AmiloA

          Posté par . Évalué à 2.

          "sinon des patchsets sympatoches a l'horizon pour le 2.6.11 ?"

          Moi je patch toujours mon kernel avec le cko (Con Kolivas patchset based overloaded kernel), voir ici : http://kem.p.lodz.pl/~peter/cko/(...)

          C'est une suite sympathique, avec des mises à jour de alsa, acpi, bttv, avec fbsplash et vesafb-ng, avec le Software Suspend 2, reiser4 et supermount, ainsi que les patchs d'Alan Cox (les -ac) ... bref, que du bonheur !

          ;-]
  • # Il manque

    Posté par (page perso) . Évalué à 10.

    Euh, je pense qu'il manque tout de meme dans la description des changements apportés à cette release, le patch permettant d'utiliser des tables de pages à 4 niveaux permettant d'utiliser pleinement les architectures 64 bits.

    Voilà, mes deux cents ;-) et je => []
    • [^] # Re: Il manque

      Posté par . Évalué à 10.

      Quelques infos sur le 2.6.11 :
      Four-level page tables :
      http://lwn.net/Articles/117749/(...)
      Optimisation d'ext3 :
      http://lwn.net/Articles/112566/(...)
      Circular pipes (très interessant) :
      http://lwn.net/Articles/118750/(...)
      Big Kernel Semaphore :
      http://lwn.net/Articles/102253/(...)

      Merci à lwn pour ces excellents articles.
    • [^] # Re: Il manque

      Posté par . Évalué à 4.

      Apparement ca ne porte que sur l'extension 64bit d'AMD et ne fait qu'ettendre la taille memoire physique supporte.

      Je serais beaucoup plus heureux lorsque cela integrera le support de taille de page variable.
      • [^] # Re: Il manque

        Posté par . Évalué à 0.

        > Apparement ca ne porte que sur l'extension 64bit d'AMD et ne fait qu'ettendre la taille memoire physique supporte.

        Les autres cpu 64bit suivront.

        > Je serais beaucoup plus heureux lorsque cela integrera le support de taille de page variable.

        ???
        à chaud ou via une recompilation du noyau ?
        Pourquoi faire ?
        • [^] # Re: Il manque

          Posté par . Évalué à 3.

          Les autres cpu 64bit suivront.
          C'est mis au conditionel pour l'instant. Mais je ne faisais que dire que ce n'etait pas pour tous "aujourd'hui". Rien d'autre.

          à chaud ou via une recompilation du noyau ?
          Via recompilation noyau on sait deja faire. La gestion de taille de page variable est "live". En fait le gestionnaire choisit, par les fait, la taille de la page. Il peut decider de decomposer une grande page en plusieur, ou de le recomposer des plus petites en plus grandes.

          La granularite se fait a la page elle-meme. Une meme application peut avoir plusieurs tailles de page.

          Pourquoi faire ?
          J'ai pas envie de rentrer dans la theorie. En gros, certaines applications fonctionnent mieux avec des pages plus grandes, d'autres fonctionnent mieux avec des pages plus petite. Aujourd'hui, pour les architectures qui supportent plusieurs taillent, tu imposes, a la compilation du noyau, une taille fixe pour tout le monde. Donc tu favorises une application par rapport a une autre. Le support de la gestion de page variables permet de:
          - avoir la taille correcte pour chaque applications/zone de donnees
          - Ne plus avoir a se poser la question lors de la compilation

          Dans les deux cas, le Kernel s'occupe de tout.
          • [^] # Re: Il manque

            Posté par . Évalué à 2.

            > Via recompilation noyau on sait deja faire.

            Je ne suis pas convaincu que toutes les applis marchent après avoir changé PAGE_SIZE (qui est une macro définie dans /usr/include/asm/page.h).

            > En gros, certaines applications fonctionnent mieux avec des pages plus grandes, d'autres fonctionnent mieux avec des pages plus petite.

            Je dis pas non mais t'aurais un exemple concret ou un bench je te plusserais :-)

            Puis c'est peut-être plus pertinent de faire ça côté libc si tu penses à l'optimisation de malloc/free. Un malloc n'aboutis pas systématique a un appel système "malloc" et beaucoup d'appels systèmes peuvent marcher sur une page mémoire (read, write, brk, etc).

            Au feeling, je n'ai pas l'impression que ça peut apporter un gain important.
            • [^] # Re: Il manque

              Posté par . Évalué à 2.

              Je ne suis pas convaincu que toutes les applis marchent après avoir changé PAGE_SIZE (qui est une macro définie dans /usr/include/asm/page.h).

              Normalement une application ne doit pas se préoccuper de PAGE_SIZE ou de tout autre particularité de la mémoire virtuelle.

              Au feeling, je n'ai pas l'impression que ça peut apporter un gain important.

              Pour faire les conversions adresse mémoire virtuelle -> adresse physique, le processeur utilise un cache TLB (Translation Lookaside Buffer). A priori, je dirais que plus la taille des pages est grande, plus on peut stocker d'associations (adresse virtuelle, adresse physique) dans cette table. Mais je me trompe peut-être.
              • [^] # Re: Il manque

                Posté par . Évalué à 2.

                > Normalement une application ne doit pas se préoccuper de PAGE_SIZE ou de tout autre particularité de la mémoire virtuelle.

                Les man de mmap et mlock ne sont pas d'accord avec toi... Ok, la taille de page dont ils parlent ne correspond pas nécessairement à la taille de page réelle utilisée par le noyau, mais à mon avis à l'heure actuelle c'est le cas.
                • [^] # Re: Il manque

                  Posté par . Évalué à 1.

                  Mouais, effectivement. Quoique mmap() parle plutôt de getpagesize() et mlock() de PAGESIZE définie dans <limits.h>

                  Quoiqu'il en soit, tant que tu respectes la contrainte imposée (offset multiple de PAGESIZE ou autre), tu te moques complètement de comment est réalisée l'implémentation derrière, et des particularités du CPU et de sa MMU. C'était le sens de mon message :)
              • [^] # Re: Il manque

                Posté par (page perso) . Évalué à 1.

                Euh, c'est pas vraiment le TLB qui fait la traduction d'adresses virtuelles en adresses physiques. C'est la MMU :-) Le TLB est comme son nom l'indique un cache permettant de trouver plus rapidement l'association pages virtuelles-pages physiques.

                D'ailleurs au passage, le code gérant le TLB sur architecture PPC a été revu.

                Bonne journée les gens...
                • [^] # Re: Il manque

                  Posté par . Évalué à -1.

                  Bonjour, dans la série "j'apprends à lire":

                  "le processeur utilise un cache TLB"
                  • [^] # Re: Il manque

                    Posté par (page perso) . Évalué à 3.

                    Bonjour,

                    J'ai bien compris merci et je sais très bien ce qu'est un cache TLB. Maintenant, si préciser réellement ce qui fait une traduction d'adresses virtuelles en adresses physiques est un crime, j'aurais peut-être dû me taire !
                    La phrase d'origine laissait penser que c'est le cache TLB qui fait cette traduction, je voulais juste souligner cela.

                    Bon bah je retourne apprendre à lire et => [].
                    • [^] # Re: Il manque

                      Posté par . Évalué à 1.

                      Moui, enfin dans le cas présent le fait que le TLB ne soit qu'une partie du MMU n'a rien avoir avec la choucroute..

                      Comme dit plus haut une gestion par le noyeau de taille de page variable permettrait une meilleure utilisation du TLB, qui en général n'est pas bien gros..

                      J'ajouterai que le noyeau gère des listes qui décrivent l'utilisation des pages, avec les taille mémoires actuelles et des pages de 4k, la taille de ces structures est assez importantes..
                      Une gestion des pages avec une taille variable permettrait probablement de réduire la taille occupées par ces listes.
                      Le gain en performance se faisant problablement sentir sur les configurations avec beaucoup de mémoire.
                • [^] # Re: Il manque

                  Posté par . Évalué à -8.

                  pfffffffff
            • [^] # Re: Il manque

              Posté par . Évalué à -5.

              rien a voir avec la libc. tu devrais pouvoir changer pour une application la taille des pages pour les archi le supportant (pour la heap, la stack ou le code). On devrait pouvoir le faire pour une lib ou un process precis.

              Quand au gains, j'ai vu certains scenario passer 50 % de leurs temps a convertir des adresses physiques en adresse virtuel en 32-bit (dependant de l'archi).

              Je trouve desolant qu'actuellement, Linus passe plus de temps a faire des fixes pour les portable IBM qu'a developper serieusement. Les mecs de Debian et de Fedora devrait lui lacher la grappe.

              Je trouve desolant aussi que l'on parle ENCORE de l'ACPI.

              J'aime pas IBM.
            • [^] # Re: Il manque

              Posté par . Évalué à 6.

              si tu penses à l'optimisation de malloc/free.
              Je pense au fait qu'aujourd'hui, sur certaine machines, le cache est trop gros pour avoir une complete couverture par la TLB (lire dans le document de mon second lien).

              Par "couverture", je parle de la traduction Memoire Virtuelle => Memoire Physique.

              Augmenter la taille des pages etend la couverture de la TLB, et donc limite le nombre de Page Fault (zone virtuelle non decrite dans la TLB, ce qui necessite une serie d'acces en memoire, tres couteuse, permettant de trouver la description, si elle existe, Memoire Virtuelle => Memoire Physique.

              Mais, augmenter la taille des pages peut etre a l'origine de gachis. Il suffit de penser a la taille de bloc dans les systemes de fichier. Plus c'est gros, plus tu as de chance de "perdre" de la memoire. Si une application n'a besoin que de 2Ko, tu perds moins de memoire en allouant 4ko au lieu de 16ko par exemple.

              Quand je parle d'allocation, c'est pas malloc/free, mais dans la VM.

              Bon quelques liens:
              http://www.gelato.unsw.edu.au/IA64wiki/NPTLbenchmarks(...)

              C'est plutot un bench qui a ete fait lors de l'implementation des NPTL. Mais par contre il montre l'influence de la taille d'une page.

              http://www.cs.rice.edu/~ssiyer/r/superpages/(...)
              Un document expliquant la problematique surement mieux que moi et une possible mise en oeuvre (pour FreeBSD).
              • [^] # Re: Il manque

                Posté par . Évalué à 1.

                > Je pense au fait qu'aujourd'hui, sur certaine machines, le cache est trop gros pour avoir une complete couverture par la TLB (lire dans le document de mon second lien).

                Au niveau hardware/cpu, je n'y connais pas grand chose :-)

                Merci pour tes précisions.
              • [^] # Re: Il manque

                Posté par . Évalué à 4.

                > Augmenter la taille des pages etend la couverture de la TLB, et donc
                > limite le nombre de Page Fault (zone virtuelle non decrite dans la
                > TLB, ce qui necessite une serie d'acces en memoire, tres couteuse,
                > permettant de trouver la description, si elle existe, Memoire Virtuelle > => Memoire Physique.

                Non, un Page Fault, c'est quand la _page_ n'est pas présente en mémoire physique, c'est-à-dire quand elle a été swappée sur le disque.
                Quand le traduction virtuelle=>physique n'est pas dans la TLB, c'est un Cache Miss comme dans n'importe quel cache, un TLB miss ici.

                Un TLB Miss, c'est plusieurs accès mémoire donc c'est lent.
                Un page fault, c'est un accès disque donc TRES TRES lent.
        • [^] # Re: Il manque

          Posté par . Évalué à 4.

          > > Apparement ca ne porte que sur l'extension 64bit d'AMD et ne fait
          > qu'ettendre la taille memoire physique supporte.
          >
          > Les autres cpu 64bit suivront.

          Non, ca n'a rien a voir avec le fait d'etre une architecture 32 ou 64 bits. Ca ne depend que du nombre de niveaux de table de pages supportés par le matériel.
          Les processeurs intel en supportent 2 ou 3. Les anciennes archis 64bits generalement 3. L'Opteron d'AMD en supporte 4.

          Le noyau a donc du passer en 4 niveaux logiciels pour utiliser la capacité des opterons au maximum.
          Sur les autres architectures, on rend 1 ou 2 des 4 niveaux logiciels pipo pour n'utiliser que les 2 ou 3 niveaux materiels.

          Ensuite, on choisit la taille de chaque niveau et de la page, en général autour de 10 car c'est un bon rapport performance/cout.
          Par exemple, Linux sur Opteron choisit 12 bits pour les pages (4ko) et 9bits pour chacun des 4 niveaux. Cela donne 48bits d'adresse physique supportés (contre 39 avant si je ne m'abuse).
          On peut donc utiliser 256To de RAM physique.
          Par contre la mémoire virtuelle des processus est limitée à 40bits (1To).
          • [^] # Re: Il manque

            Posté par . Évalué à 2.

            > Cela donne 48bits d'adresse physique supportés (contre 39 avant si je ne m'abuse).

            Ce n'est pas tout à fait ça si j'ai bien compris. Sur amd64 il y a deux espaces mémoires (parmis d'autres) :
            - espace utilisateur
            - espace physique

            2^35 bits de page pour la mémoire virtuelle et 2^40 bits pour la mémoire physique selon les specs.

            Avec page = 2^12.
            Espace utilisateur est de 47 bits (128To). C'est les spec du cpu qui limite. Linux utilise tout.

            Espace physique est de 52 bits (4096To) pour les spec. C'est 46 bits(64To) pour l'implémentation Linux. Les cpu actuels ne dépassent pas 40 bits (1To).

            http://www.x86-64.org/lists/discuss/msg06059.html(...)

            > Par contre la mémoire virtuelle des processus est limitée à 40bits (1To).

            128To si j'ai bien compris.
            mémoire virtuelle peut-être supérieur à mémoire physique car il y a le swap et mmap.
            • [^] # Re: Il manque

              Posté par . Évalué à 1.

              > 2^35 bits de page pour la mémoire virtuelle et 2^40 bits pour la
              > mémoire physique selon les specs.
              >
              > Avec page = 2^12.
              > Espace utilisateur est de 47 bits (128To). C'est les spec du cpu
              > qui limite. Linux utilise tout.

              Ah oui en effet, c'est 47 et pas 48 bits d'adresse physique.
              Voir dans include/asm-x86_64/pgtable.h :
              et http://lwn.net/Articles/116954/(...)

              Apparemment, les AMD64 supportent moins que sur les Opterons.

              > > Par contre la mémoire virtuelle des processus est limitée à
              > > 40bits (1To).
              >
              > 128To si j'ai bien compris.
              > mémoire virtuelle peut-être supérieur à mémoire physique car il y a > le swap et mmap.

              La mémoire virtuelle peut avoir une taille quelconque indépendante de la quantité de mémoire physique (128To ici puisque 47bits).

              Le système peut limiter la mémoire virtuelle à la taille qu'il veut.
              Linux a finalement choisit de limiter également à 47bits, en effet.
              (cf TASK_SIZE dans include/asm-x86_64/processor.h)
              • [^] # Re: Il manque

                Posté par . Évalué à 1.

                > Apparemment, les AMD64 supportent moins que sur les Opterons.

                Je n'ai pas pensé qu'il puisse être différent sur ce point :-)

                > Linux a finalement choisit de limiter également à 47bits, en effet.
                > (cf TASK_SIZE dans include/asm-x86_64/processor.h)

                Je n'y connais pas grand chose mais ce n'est pas ce que je vois.
                Il me semble que c'est une limite du cpu qui se retrouve dans processor.h (voir pgtable.h que tu as pointé, 4 "indirections" de 9 bits (512 slots)). Ce qui est normal, Linux n'a pas à tenter d'accéder à un espace mémoire que le cpu ne peut de toute façon pas atteindre. N'oublions pas que page_size = 2^12. Si page_size > 2^12 on peut repousser cette limite.
                Selon ce que je comprend, Linux "subit" le fait que le cpu ne peut utiliser que 2^35*page_size pour les adresses virtuelles. (D'accord, c'est 2^36 (2^(9*4)) mais je ne sais pas où j'ai perdu un bit :-)).

                Là où Linux limite, c'est pour l'espace physique qui peut monter à 2^52 et Linux limite à 2^46 (pour des raisons que je n'ai pas compris). Mais ce n'est pas grave car actuellement le maximum disponible ("à l'achat") est 2^40.
                • [^] # Re: Il manque

                  Posté par . Évalué à 1.

                  > D'accord, c'est 2^36 (2^(9*4)) mais je ne sais pas où j'ai perdu un bit :-)

                  Finalement j'ai compris. C'est 2^36*2^12 (2^48) pour tous l'asdressage mémoire mais il est divisé en deux :
                  - mémoire virtuel : 2^47
                  - mémoire noyau : 2^47

                  > Là où Linux limite, c'est pour l'espace physique qui peut monter à 2^52 et Linux limite à 2^46 (pour des raisons que je n'ai pas compris).

                  Non, Linux ne limite pas.
                  Puisque page_size fait 2^12, il y a 2^47 pour le mode noyau (comme pour la mémoire virtuelle) et dans ce 2^47 on garde la moitier (2^46) pour la mappage vers les adresses physiques.


                  Finalement, j'ai beaucoup appris :-)
                  Ce qui limite l'espace adressable par Linux, c'est le choix fait par Linux d'utiliser page_size=4096 comme pour x86 afin de pouvoir exécuter aussi des applis x86 (qui ont page_size=4096) et éviter d'inutile problème de compatibilité.
                  Mais augmenter page_size c'est aussi bouffer plus de mémoire.
                  Rien de dramatique dans le "page_size=4096" car on est déjà bien au delà des limites du hardware disponible. Pour un espace mémoire maxi avec amd64 et selon ses specs (mémoire physique limité à 2^52) il faudrait page_size=2^18 soit 256 ko (!). On aurait :
                  - mémoire virtuelle : 8192 To
                  - mémoire physique : 4096 To
                  Y a du gras.
    • [^] # Re: Il manque

      Posté par (page perso) . Évalué à 7.

      En effet, c'est un patch qui change pas mal quelques algorithmes.

      N'empeche il serait temps que linux definisse une API de gestion de la VM qui se detache un peu des details de la MMU du x86. C'est pas pour dire, mais sur d'autres archi, la MMU ne travaille pas du tout avec des tables de traduction "directes" comme dans le cas x86 (je pense a ppc). Mieux vaudrait avoir une API bien plus propre, bien plus simple et bien plus portable que celle qui consiste a emuler les X niveaux d'indirection de la MMU x86.

      Voila, c'etait mes 3 cents de mauvaise humeur... Troll en perspective ?
      • [^] # Re: Il manque

        Posté par . Évalué à 1.

        > detache un peu des details de la MMU du x86.

        C'est le role du noyau d'être au plus près du hardware pour être le plus rapide possible.
        Ce qu'il faut c'est que les drivers, applis soient portables. C'est le cas.
        Dans un noyau il y a toujours des parties qui sont spécifiques au hardware.
        • [^] # Re: Il manque

          Posté par . Évalué à 1.

          Ce que voulait surement dire D2 (ou plutôt D3, non ? ;) ), c'est qu'un noyau qui se veut conçu pour être portable devrait être indépendant d'un quelconque modèle d'architecture réelle spécifique, et permettant cependant d'utiliser des optimisations pour une implémentation d'une cible particulière.
          La conception actuelle en 3 niveaux d'indirection fait référence au x86, alors que sur d'autres archi, on peut avoir 1 ou 2 niveau, voire un fonctionnement différent.
          D'ailleurs, je ne sais pas comment ca se passe sur la MMU du PPC...

          Linux a quand même été conçu initialement pour tourner sur un x86, mono-proc, etc, etc. Et ca se sent.... même dans la ligne 2.6 !
          • [^] # Re: Il manque

            Posté par . Évalué à 1.

            > c'est qu'un noyau qui se veut conçu pour être portable devrait être indépendant d'un quelconque modèle d'architecture réelle spécifique

            Oui mais c'est impossible.

            > et permettant cependant d'utiliser des optimisations pour une implémentation d'une cible particulière.

            Optimization qui ne concerne qu'une partie du noyau. Les drivers ignorent cette optimisation dans la majorité des cas et ne vois que "bête" adresse.

            > Linux a quand même été conçu initialement pour tourner sur un x86, mono-proc, etc, etc. Et ca se sent.... même dans la ligne 2.6 !

            Linux tient compte du réel. Si le cpu a besoin x niveaux pour l'exploité, Linux n'a d'autre choix que de les implémenter. Si tu ne les utilises pas (entre autre pour distinguer mémoire virtuelle et physique) autant retourner sous DOS.
            • [^] # Re: Il manque

              Posté par (page perso) . Évalué à 2.

              (mais qui es-tu "borntoulouse" ? Tes initiales seraient-elles L.C. ? Ou R.J. ?)

              Chouette, un troll pour techos !

              >> c'est qu'un noyau qui se veut conçu pour être portable devrait être indépendant d'un quelconque modèle d'architecture réelle spécifique

              Linux ne se voulait pas portable a ses debuts, c'est d'ailleurs sans doute pour ca qu'on a cette API foireuse au niveau de la gestion de la MMU.

              > Oui mais c'est impossible.

              Oh, allez, ne soyons pas defaitiste comme ça ! Allons, reprenons-nous ;)

              > Optimization qui ne concerne qu'une partie du noyau. Les drivers ignorent cette optimisation dans la majorité des cas et ne vois que "bête" adresse.

              Donc ca voudrait dire que les drivers devraient se contrefoutre de ces histoires de X niveaux d'indirection. Ce qui veut dire que si on a une API de gestion de la MMU qui ne rend pas publique ces histoires de X niveaux d'uindirections, alors les drivers ne se porteront pas plus mal. Bref, cette remarque va dans le sens de ce qui suit...

              > Linux tient compte du réel. Si le cpu a besoin x niveaux pour l'exploité, Linux n'a d'autre choix que de les implémenter. Si tu ne les utilises pas (entre autre pour distinguer mémoire virtuelle et physique) autant retourner sous DOS.

              Le CPU, ou plutot la MMU (qui est certes dans le CPU sur x86), a besoin de ces x niveaux, en effet. Par contre, "tu" ne les utilises pas directement. Justement, une API de la gestion de la MMU est une interface coincee entre la MMU et "tu" : c'est une couche d'abstraction intermediaire pour que "tu" n'aies pas a s'e**erder avec des histoires de niveaux d'indirection (x86), de tables de hachage (ppc), etc.. et bien sûr c'est cette couche qui s'occupe de fournir le necessaire a la MMU (tables de traduction directes, de hachage, etc...).
              • [^] # Re: Il manque

                Posté par . Évalué à 0.

                > c'est d'ailleurs sans doute pour ca qu'on a cette API foireuse au niveau de la gestion de la MMU.

                De quoi tu parles ?

                > Le CPU, ou plutot la MMU (qui est certes dans le CPU sur x86), a besoin de ces x niveaux, en effet. Par contre, "tu" ne les utilises pas directement. Justement, une API de la gestion de la MMU est une interface coincee entre la MMU et "tu" : c'est une couche d'abstraction intermediaire pour que "tu" n'aies pas a s'e**erder avec des histoires de niveaux d'indirection (x86), de tables de hachage (ppc), etc..

                Donc tout va pour le mieux dans le meilleur des mondes.
                Pour ton histoire d'API je ne vois pas de quoi tu parles. L'API pour accéder à la mémoire est une adresse mémoire. Ce n'est pas un "truc" avec des indirections etc.
                • [^] # Re: Il manque

                  Posté par . Évalué à 3.

                  > Pour ton histoire d'API je ne vois pas de quoi tu parles. L'API pour
                  > accéder à la mémoire est une adresse mémoire. Ce n'est pas un
                  > "truc" avec des indirections etc.

                  Il parle du fait qu'actuellement, si tu veux traduire une adresse virtuelle, en adresse physique, tu dois parcourir la table des pages à la main. Les indirections dont il parle, ce sont les etapes du parcours des differents niveaux de la table de page.

                  Actuellement, si t'as une adresse "addr" d'un espace d'adressage "mm", tu dois faire (en virant les routines les verifications) :

                  pgd = pgd_offset(mm, addr);
                  pud = pud_offset(pgd, addr);
                  pmd = pmd_offset(pud, addr);
                  pte = pte_offset_map(pmd, addr);
                  page = pte_page(*pte);
                  pte_unmap(pte);

                  Et enfin tu as le cadre physique "page" où est mappée ton adresse virtuelle.

                  Cette API ne correspond à rien sur certaines architectures qui utilisent autre chose d'une table de page.
                  Il serait donc mieux d'avoir une API du genre:

                  page = mmu_translate(mm, addr);

                  Et que mmu_translate fasse le code ci-dessus sur ia32 et fasse un truc adapté à l'architecture sur les autres.
                  C'est ce qui a été proposé recemment.
                  Voir "A proposal for a major memory management rework" dans
                  http://lwn.net/Articles/124966(...)
                  • [^] # Re: Il manque

                    Posté par . Évalué à 0.

                    > Actuellement, si t'as une adresse "addr" d'un espace d'adressage "mm", tu dois faire (en virant les routines les verifications) :
                    > pgd = pgd_offset(mm, addr);
                    > ...

                    Qui doit faire/utiliser ça ?
                    Il n'y a que la partie du noyau qui gère la mémoire qui utilise ça (répertoire mm qui n'est pas lourd par rapport au reste).

                    C'est une API qui n'est pas exportée. C'est une API spécifique au hardware. Nul part (sauf répertoire mm) cette API est utilisée (sauf peut-être pour quelques cas d'optimisations).

                    Si tu fais un drivers, un fs, tout sauf ce qui n'est pas lié à la vm, tu ne touches jamais à ça.

                    Donc, tu ne parles pas d'API mais d'implémentation de la vm. C'est différent.

                    > Voir "A proposal for a major memory management rework" dans
                    http://lwn.net/Articles/124966(...)

                    Je n'y ai pas accès. Mais lis bien, c'est "A proposal for a major memory management rework". Ça ne conserne pas (mais je n'ai pas lu l'article) l'API qui est exporté.
                    • [^] # Re: Il manque

                      Posté par . Évalué à 4.

                      > Qui doit faire/utiliser ça ?
                      > Il n'y a que la partie du noyau qui gère la mémoire qui utilise ça
                      > (répertoire mm qui n'est pas lourd par rapport au reste).

                      Rien qu'en cherchant 3mn, j'ai le driver de ma webcam (spca50x) qui utilise ca, le DRM standard du noyau aussi, les drivers Myrinet, ...

                      Le noyau fournit aussi une API de plus haut niveau qui enrobe le parcours de page (par exemple pci_map_single). Et il ne faut pas oublier que le mapping linéaire permet de faire la translation rapidement avec virt_to_phys car on sait à l'avance ce que le parcours de la table de pages va donner.
                      Mais moralement, c'est la meme chose, les drivers veulent souvent traduire en adresses physiques.
                      Evidemment, ils utilisent la methode la plus simple.
                      Mais elle ne suffit pas toujours. Et dans ce cas, on utilise cette API.

                      > Donc, tu ne parles pas d'API mais d'implémentation de la vm. C'est
                      > différent.

                      Une API, c'est une "Application Programming Interface", ca veut dire interface logicielle de programmation. Ces fonctions sont exportées
                      dans les include/asm-/*.h de toutes les architectures.
                      Et un .h, c'est precisement un fichier où on ecrit les API.

                      > Je n'y ai pas accès. Mais lis bien, c'est "A proposal for a major
                      > memory management rework". Ça ne conserne pas (mais je n'ai
                      > pas lu l'article) l'API qui est exporté.

                      En effet, tu n'as pas lu l'article...

                      Par exemple :
                      "Christoph Lameter would like to get rid of the disconnect between in-kernel and hardware page tables; to that end, he has proposed a new abstraction layer which would handle access to the processor's memory management unit (MMU)."
                      puis
                      "The proposed replacement interface is somewhat vague at this stage, but some features have been sketched out:"

                      Une "nouvelle couche d'abstraction" puis une "interface de remplacement proposée", c'est une nouvelle API.
                      • [^] # Re: Il manque

                        Posté par . Évalué à -2.

                        > Une API, c'est une "Application Programming Interface", ca veut dire interface logicielle de programmation. Ces fonctions sont exportées

                        $ find * -not -path "Documentation/*" -not -path "arch/*" -not -path "include/*" -not -path "mm/*" -print0 | xargs -0 egrep -n "(pgd_offset)|(pud_offset)|(pmd_offset)|(pte_offset_map)|(pte_page)|(pte_unmap)"
                        drivers/char/drm/drm_memory.h:127: pgd_t *pgd = pgd_offset_k((unsigned long) vaddr);
                        drivers/char/drm/drm_memory.h:128: pmd_t *pmd = pmd_offset(pgd, (unsigned long) vaddr);
                        drivers/char/drm/drmP.h:155:#ifndef pte_offset_map
                        drivers/char/drm/drmP.h:156:#define pte_offset_map pte_offset
                        drivers/char/drm/drmP.h:157:#define pte_unmap(pte)
                        drivers/char/drm/drmP.h:165: pgd_t *pgd = pgd_offset_k(addr);
                        drivers/char/drm/drmP.h:170: pmd = pmd_offset(pgd, addr);
                        drivers/char/drm/drmP.h:173: ptep = pte_offset_map(pmd, addr);
                        drivers/char/drm/drmP.h:176: page = pte_page(pte);
                        drivers/char/drm/drmP.h:177: pte_unmap(ptep);
                        fs/exec.c:313: pgd = pgd_offset(mm, address);
                        fs/exec.c:323: pte_unmap(pte);
                        fs/exec.c:331: pte_unmap(pte);

                        Voilà, c'est tout.
                        Impressionnant l'utilisation de l'API...

                        > Ces fonctions sont exportées dans les include/asm-/*.h de toutes les architectures.

                        Et les ficheirs dans include/asm sont spécifiques aux architectures !
                        Ils n'ont à être utilisé que si tu fais un truc SPÉCIFIQUE à l'architure et qu'en gros tu n'as pas le choix !

                        > Christoph Lameter would like to get rid of the disconnect between in-kernel and hardware page tables

                        Et alors ? Qui te dis que ça impacte l'API (or arch et include/asm car c'est SPÉCIFIQUE au hardware).

                        > Une "nouvelle couche d'abstraction" puis une "interface de remplacement proposée", c'est une nouvelle API.

                        Une API pour qui ?
                        Pour "mm/" seulement ?
                        • [^] # Re: Il manque

                          Posté par . Évalué à 2.

                          > Et les ficheirs dans include/asm sont spécifiques aux architectures
                          > Ils n'ont à être utilisé que si tu fais un truc SPÉCIFIQUE à l'architure
                          > et qu'en gros tu n'as pas le choix !

                          Un contre-exemple parmi des centaines :
                          Copier des données entre espace user et noyau est une chose très courante et que n'importe quel driver non-architecture-spécifique peut vouloir faire (relance ton find pour t'en rendre compte). Mais l'implémentation de copy_from_user est très architecture spécifique et exportée uniquement dans les asm/uaccess.h.

                          Les fichiers asm/*.h du noyau sont justement là pour masquer les choses dépendantes de l'architecture et fournir une interface uniforme.
                          Il est tout a fait normal pour n'importe qui d'inclure un fichier asm/*.h même pour programmer un truc pas du tout architecture spécifique.

                          > > Christoph Lameter would like to get rid of the disconnect
                          > > between in-kernel and hardware page tables
                          >
                          > Et alors ? Qui te dis que ça impacte l'API (or arch et include/asm
                          > car c'est SPÉCIFIQUE au hardware).

                          C'est facile de dire ca après avoir viré les parties intéressantes du texte que j'avais cité. Il dit explicitement qu'il veut créer une nouvelle couche d'abstraction des MMU et une interface de remplacement, c'est-à-dire une API :

                          "he has proposed a new abstraction layer which would handle access to the processor's memory management unit (MMU)."
                          "The proposed replacement interface is somewhat vague at this stage, but some features have been sketched out:"

                          (Je réinsère la citation pour voir si tu vas encore la virer).

                          Visiblement tu as très peu de connaissance du noyau et de sa programmation donc je vais te laisser continuer à troller tout seul
                          car je vous bien que je perds mon temps à essayer de t'expliquer les choses de la vie.
                          • [^] # Re: Il manque

                            Posté par . Évalué à -3.

                            > > Et les ficheirs dans include/asm sont spécifiques aux architectures
                            > > Ils n'ont à être utilisé que si tu fais un truc SPÉCIFIQUE à l'architure
                            > > et qu'en gros tu n'as pas le choix !

                            J'ai écrit une connerie car t'as écrit une connerie :
                            - Ces fonctions sont exportées dans les include/asm-/*.h de toutes les architectures.

                            Je voulais dire "include/asm-*".

                            Pour priciser :
                            include/asm : API indépendante de l'architecture
                            include/asm-* : API dépendante de l'architecture
                            Que asm soit un lien sur asm-* ne change rien.
                            Lorsque tu fais "include <asm/*.h>" tu signifies : j'ai besoin de l'API générique (portable (indépendante du hardware)).
                            Lorsque tu fait "include <asm-*/*.h>" tu signifies : j'ai besoin de l'API spécifique à un hardware. Donc normalement "include/asm-*" n'est pas utilisé hors "arch/*".

                            > Visiblement tu as très peu de connaissance du noyau et de sa programmation

                            Connard.
                            • [^] # Re: Il manque

                              Posté par . Évalué à 3.

                              > J'ai écrit une connerie car t'as écrit une connerie :
                              > - Ces fonctions sont exportées dans les include/asm-/*.h de
                              > toutes les architectures.

                              N'essaie pas de te cacher derrière des caractères manquant ou en trop. Ma phrase reste parfaitement vraie que ce soit asm ou asm-*.
                              grep est là pour le prouver.
                              Les gens qui incluent pgtable.h pour utiliser pgd_offset and co, ils incluent bien asm/pgtable.h et pas asm-*/pgtable.h.
                              C'est le cas dans drm et dans fs que tu avais cités avec ton find, et également dans le driver de ma webcam et le driver Myrinet.

                              > Lorsque tu fais "include <asm/*.h>" tu signifies : j'ai besoin de l'API
                              > générique (portable (indépendante du hardware)).
                              > Lorsque tu fait "include <asm-*/*.h>" tu signifies : j'ai besoin de l'API
                              > spécifique à un hardware. Donc normalement "include/asm-*" n'est
                              > pas utilisé hors "arch/*".

                              Exactement, c'est ce qui permet de conclure que l'API pgd_offset and co. est bien independante de l'architecture.
                              CQFD.
                              • [^] # Re: Il manque

                                Posté par . Évalué à 1.

                                > Exactement, c'est ce qui permet de conclure que l'API pgd_offset and co. est bien independante de l'architecture.

                                Et comme indiqué plus haut, ce n'est pas ou peu utilisé. C'est utilisé que s'il n'y a pas le choix. L'architecture ou certain driver l'impose mais pas Linux. Linux doit faire avec ce que lui fournit le hardware.
                            • [^] # Re: Il manque

                              Posté par (page perso) . Évalué à 2.

                              fabb, dans un noyau il n'y a pas qu'1 API destinee aux drivers. Il y en a pour tous les sous-systemes, qui sont eux-memes utilises par les autres sous-systemes, utilises par les autres sous-systemes, etc... utilises par les drivers, utilises par d'autres sous-systemes, etc... utilises par les applications utilisateur.

                              Bref, une API noyau n'est pas forcement utilisee par les drivers directement. C'est pas pour ca qu'on doit dire "boarf, c'est de la cuisine interne au noyau, c'est forcement bas niveau, donc ca depend du matos et le noyau se debrouille.". Non. Par exemple, pour la MMU, c'est pas parce que c'est utilise essentiellement par VMM (le sous-systeme de gestion de la mem virtuelle) que ca ne doit pas etre une API a part entiere, claire et precise. Parce qu'une contrainte des noyaux du genre Linux, c'est qu'il doit etre "portable", ie adaptable a plusieurs archi en touchant le moins de code possible. Dans Linux comme dans les Unix, la VMM, interne au noyau, doit avoir le meme comportement dans toutes les archi, et donc, si possible *partager* le meme code pour toutes les archi. Quelle autre solution pour ca que de dire que VMM repose sur une API de gestion de la MMU uniforme sur toutes les archis ?

                              Bon, j'espere que jusqu'ici c'est clair. Maintenant qu'on a dit qu'une API de gestion de la MMU etait necessaire (bien que peu de drivers l'utilisent directement), la question se pose de la definir. Dans Linux, l'histoire a choisi une API a base de tables simples avec 2 ou 3 indirections (resp 3 ou 4 niveaux de tables). Eh bien je ne suis pas convaincu que ce soit le meilleur choix. D'une part parce que cette API est un gouffre en termes de perf quand l'archi ne repose pas sur un systeme a indirection simple parce que emuler en soft ce systeme peut etre tres complexe quand on ne dispose pas en hard des elements en question (ex : ppc repose sur une serie de tables de hachage, pas facile d'emuler des tables a indirection a partir de ca). D'autre part parce que le code de gestion de la VMM n'a pas un besoin fondamental de gerer des tables a 2 ou 3 indirections : il est essentiellement question d'etablir des traductions adresse virtuelle -> physique, pas de dire que l'entree 12 de la table de niveau 4 pointe sur la table a l'adresse physique 0x1234000, etc... Si la VMM pouvait se passer de ce genre de detail, ca serait quand meme plus elegant.

                              Pour Brice : vivement Jeudi que je lise cet article lwn ! Si ca continue je m'abonne.
                              • [^] # Re: Il manque

                                Posté par . Évalué à 1.

                                > Par exemple, pour la MMU, c'est pas parce que c'est utilise essentiellement par VMM (le sous-systeme de gestion de la mem virtuelle) que ca ne doit pas etre une API a part entiere, claire et precise.

                                Je suis parfaitement d'accord. Mais lorsqu'on parle API il faut être précis. Si on me parle d'API de la vmm sans plus de précision, je pense à l'API utilisable par un module externe et pas au sein du système de gestion de la vmm.

                                Si je dis que l'API de libxml2 est bien faite, tout le monde comprend que je parle de l'API "externe" et pas de la tembouille interne.

                                > Dans Linux comme dans les Unix, la VMM, interne au noyau, doit avoir le meme comportement dans toutes les archi, et donc, si possible *partager* le meme code pour toutes les archi.

                                Pas totalement d'accord. Dans l'idéal, ça doit être le même code. Ce qui compte avant tout c'est que l'interface, l'API "externe", soit la même pour tout le monde.
                                De tout manière, il est *impossible* d'avoir le même code pour toute les architectures, ou plus précisément il y a toujours un moment ou tu dois prendre en compte les spécificité de l'architecture pour des raisons de performance. C'est bien le role du noyau (ou de tout module réutilisable) de prendre en compte les spécificités et de les masquer. Mais au final il faudra *toujours* du code spécifique.

                                > Quelle autre solution pour ca que de dire que VMM repose sur une API de gestion de la MMU uniforme sur toutes les archis ?

                                Tu peux toujours repousser l'encapsulation. Savoir où et jusqu'où il faut le faire n'est en rien évident (surtout pour un noyau ou le critère performance est très important).
                                Tu peux faire un noyau en java, mais c'est lent et le code spécifique que tu as retiré en utilisant java, tu le retrouves dans java. Le gain est nul.

                                > D'autre part parce que le code de gestion de la VMM n'a pas un besoin fondamental de gerer des tables a 2 ou 3 indirections : il est essentiellement question d'etablir des traductions adresse virtuelle -> physique, pas de dire que l'entree 12 de la table de niveau 4 pointe sur la table a l'adresse physique 0x1234000, etc... Si la VMM pouvait se passer de ce genre de detail, ca serait quand meme plus elegant.

                                L'interface (externe) se passe de ce genre de détail (sauf pour quelques cas rarement utilisé). Donc la voie est libre pour implémenter différement la VMM où même faire une VMM totalement spécifique à ppc sans retoucher (ou peu) l'API externe.

                                Au final et pour être bien d'accord. Je ne vais pas dire les avantages ou inconvénient des techniques de telle ou telle vmm. Je n'ai pas les compétences. Ce qui m'"énerve" c'est de voir les gens parler d'_API_ en des définissants comme spécifiques à une architecture.
                                Ce que tu reproches à la vmm ici (et si j'ai bien compris) a du sens. Tu ne reproches pas l'API (externe) mais que la vmm "colle" que système qu'on retrouve sur les systèmes types x86 et que ce n'est pas forcement la bonne aproche pour toutes les architectures. Tu ne demandes pas que l'API (externe) soit encore plus neutre par rapport au architecture mais que son fonctionnement interne soit plus neutre et pas "optimisé" pour un type d'architecture.
                                Je n'ai pas de problème avec ça.
                              • [^] # Re: Il manque

                                Posté par . Évalué à 2.

                                > vivement Jeudi que je lise cet article lwn !

                                Tu peux aussi aller lire directement l'annonce sur la LKML :
                                http://marc.theaimsgroup.com/?l=linux-ia64&m=110922543030922&w=2
  • # Ahh

    Posté par . Évalué à 4.

    Salut,

    et xen c'est pour quand ?

    http://www.cl.cam.ac.uk/Research/SRG/netos/xen/(...)

    J'ai lu quelque part que c'etait pour le 2.6.12, quelqu'un confirme ?

    ici :
    http://www.crn.com/sections/breakingnews/breakingnews.jhtml?article(...)

    Merci
  • # InfiniBand...

    Posté par . Évalué à 10.

    L'architecture de bus InfiniBand est prise en charge dans ce nouveau noyau : c'est apparemment une alternative au bus PCI où les données sont transmises en série et en multiplexage, au lieu d'être transmises en parallèle, ceci ne concernant pour l'instant que les serveurs « high-end » et certains PC.


    Il me semble que cette définition est inexacte (cf http://www.oreillynet.com/pub/a/network/2002/02/04/windows.html(...) )
    L'infiniband, c'est plutôt une technologie d'interconnection caractérisée par une faible latence et un gros débit, et est plutôt présenté comme un remplaçant d'ethernet ou mirinet pour les calculs sur grid.

    Bon, si on regarde sur le wikipedia: http://en.wikipedia.org/wiki/InfiniBand(...) il semble bien qu'Infiniband se veut comme un remplaçant d'autant ethernet que le bus PCI...
    Tout ça pour dire que jusqu'à présent, on pouvait difficilement avoir des gros débits de noeuds à noeuds en réseau local avec des technologies courantes, mais que heureusement est arrivé Infiniband!
    • [^] # Re: InfiniBand...

      Posté par (page perso) . Évalué à 6.

      Je confirme Infiniband est d'une certaine manière le successeur de myrinet ou de Dolphin SCI, en ce qui concerne les cartes réseau faible latence et fort débit utilisés dans les clusters Hautes Performances (HPC). Infiniband, en plus d'être plus performant a également l'avantage d'être un standard, donc on n'est plus cantonné à un seul fournisseur.

      Par contre, rien à voir avec les calculs sur grid. Dans les grids, la vitesse de communication entre les noeuds est extremment aléatoire, ils ne sont pas concus pour faire tourner des programmes ayant de gros besoin de communication entre eux. Pas de MPI sur les grids en général, alors qu'au contraire avec Infiniband, on n'utilisera à 90% des programmes basés sur MPI (ou son ancêtre PVM).
      • [^] # Re: InfiniBand...

        Posté par . Évalué à 4.

        > Infiniband, en plus d'être plus performant a également l'avantage
        > d'être un standard, donc on n'est plus cantonné à un seul
        > fournisseur.

        C'est la théorie ça.
        En pratique, il n'y a que Mellanox qui produit réellement du matériel.
        Il y a pas mal "d'assembleurs" InfiniBand en quelque sorte. Mais au final c'est pas si différent de Quadrics et Myrinet qui sont les seuls a produire leur matériel respectif.

        Au niveau performance, la bande passante annoncée (12x voire 30x, c'est à dire 3Go/s voire 7,5Go) est enorme mais completement inobservable en pratique puisque les bus d'entrées-sorties des machines actuelles ne supportent guere plus que ce que InfiniBand 4x promet.
        Donc au final, en bande passante c'est pareil que Quadrics (qui reste la référence du marché).

        En latence, c'est beaucoup moins bons que Quadrics et Myrinet (moins de 2 et 3us respectivement) alors qu'Infiniband passe difficilement sous les 5-6us.

        SCI a quasiment disparu du marché depuis quelques années déjà.
  • # InfiniBand, c'est un réseau pour grappes

    Posté par . Évalué à 10.

    En fait, InfiniBand devait initialement remplacer le bus PCI mais ca a été abandonné. Desormais, c'est juste un réseau tres hautes
    performances utilisées dans les grappes de calcul.
    En gros, c'est 5-10 microsecondes et 1Go/s.
    Mais pour cela, il faut utiliser un protocole et des applications très speciales.
    Le vrai support de ce protocole natif haute performance ne sera probablement jamais inclu car il est trop intrusif et concerne tres peu de gens.
    Là, ils ont simplement inclu dans le noyau le support du protocole IP pour ces cartes.
  • # Imodules proprio NVIDIA

    Posté par (page perso) . Évalué à 2.

    Il semblerait que les modules proprio NVIDIA ne fonctionne plus avec ce nouveau kernel. Aprés quelques recherches, j'ai trouvé ça, mais n'ai pas encore eu le temps de tester

    http://unixforge.org/~matthias-christian-ott/index.php?entry=entry0(...)
    • [^] # Re: Imodules proprio NVIDIA

      Posté par . Évalué à 6.

      Pour ce qui est du driver proprio nvidia, la recette et le patch qu iva bien pour le faire tourner sur un beau noyau 2.6.11 sont là :
      http://www.nvnews.net/vbulletin/showthread.php?t=46676(...)
    • [^] # Re: modules proprio NVIDIA

      Posté par (page perso) . Évalué à 7.

      Le paquet debian des drivers doit avoir l'un ou l'autre patch alors, parce que chez moi, c'est passé comme un pet sur une toile cirée (ou comme une fleur, pour les plus poétiques)
      • [^] # Re: modules proprio NVIDIA

        Posté par (page perso) . Évalué à 3.

        Ma petite aventure NVidia...

        j'ai installé le 2.6.11 en croisant les doigts, make && make install && make modules_install
        ça boot !

        j'installe le driver NVIDIA, startx, et poof, ça marche !

        là, je lance ma carte TV, ça freeze (comme d'hab) et je reboot (reset button), et là, plein de UNEXPECTED SYMBOL au moment du chargement NVidia.

        solution : ré-installer le driver à chaque reboot, en attendant le patch :/

        (rude, but woks)

        Mes2cents
        • [^] # Re: modules proprio NVIDIA

          Posté par . Évalué à 2.

          Quelqu'un pourrait m'expliquer ce que signifie l'histoire des "2cents" qui reviennent si souvent sur DLFP ?
          • [^] # Re: modules proprio NVIDIA

            Posté par . Évalué à 6.

            C'est la traduction mot à mot de l'expression "my two cents". Je le traduirais plutôt par "ma modeste contribution", "mon humble avis" ou encore "ma réflexion à deux balles" si on veut garder le côté monétaire de l'expression originale.

            Le fait de dire cents au lieu de centimes doit être pour faire plus djeuns...
            • [^] # Re: modules proprio NVIDIA

              Posté par . Évalué à 2.

              merci ! ;)
            • [^] # Re: modules proprio NVIDIA

              Posté par . Évalué à 2.

              >Le fait de dire cents au lieu de centimes doit être pour faire plus djeuns...

              Sur les pièces françaises, il est bien marqué "cent" et non pas "centime". Ce qui me choque le plus, c'est que sur ces mêmes pièces, le nom n'est pas accordé ; ainsi on a "10 euro cent" alors que j'aurais plutôt mis "10 euro cents".
  • # 2.6.12

    Posté par . Évalué à 8.

    Intérressant, sur KernelTrap, un aperçu de quelques unes des nouveautés prévues pour le 2.6.12, dont en particulier :
    - FUSE (système de fichiers en user space, à la LUFS et compagnie)
    - cpusets: un système de partitionnement des resources CPU des machines SMP (en gros si je comprends bien, à la fois de la virtualisation et de l'allocation explicite des ressources CPU à certaines tâches)

    Et puis plein d'autres choses, dont rien de garanti bien sûr.

    http://kerneltrap.org/node/4789(...)
    • [^] # Re: 2.6.12

      Posté par . Évalué à 2.

      ça promet FUSE, avec ça les devels ouvrent les portes vers tout un tas d'extensions très intéressantes et pourquoi pas se rapprocher du fonctionnement des translators sous hurd ... c'est dommage, ça enlève encore un intéret à ce dernier, va pu lui rester grand chose :-/
      • [^] # Re: 2.6.12

        Posté par (page perso) . Évalué à 4.

        Dire que FUSE c'est du user space, c'est quand meme un demi gros mensonge, ca reste quelque chose qui tourne en kernel space pour la présentation(l'intégration?) dans le fs linux, donc bon, le hurd propose quelque chose de mieux ;)
        • [^] # Re: 2.6.12

          Posté par . Évalué à 2.

          > Dire que FUSE c'est du user space, c'est quand meme un demi gros mensonge

          la partie vfs tourne en kernel space, le reste en user space.

          > le hurd propose quelque chose de mieux ;)

          c-à-d ?
          la partie vfs est en user space ?
        • [^] # Re: 2.6.12

          Posté par . Évalué à 1.

          Pour le fun, une partie de la partie user space d'un fs rpm :

          #! /bin/sh
          ...
          mcrpmfs_list ()
          {
          # set MCFASTRPM_DFLT to 1 for faster rpm files handling by default, to 0 for
          # slower handling
          MCFASTRPM_DFLT=0
          if test -z "$MCFASTRPM"; then
          MCFASTRPM=$MCFASTRPM_DFLT
          fi
          FILEPREF="-r--r--r-- 1 root root "
          DESC=`rpm -qip "$1"`
          DATE=`rpm -qp --qf "%{BUILDTIME:date}\n" "$1" | cut -c 5-11,21-24`
          HEADERSIZE=`echo "$DESC" | wc -c`
          echo "-r--r--r-- 1 root root $HEADERSIZE $DATE HEADER"
          echo "-r-xr-xr-x 1 root root 39 $DATE INSTALL"
          echo "-r-xr-xr-x 1 root root 39 $DATE UPGRADE"
          echo "dr-xr-xr-x 3 root root 0 $DATE INFO"
          echo "$FILEPREF 0 $DATE INFO/NAME-VERSION-RELEASE"
          echo "$FILEPREF 0 $DATE INFO/GROUP"
          ...
          mcrpmfs_copyout ()
          {
          case "$2" in
          HEADER) rpm -qip "$1" > "$3"; exit 0;;
          INSTALL) echo "# Run this to install this RPM package" > "$3"; exit 0;;
          UPGRADE) echo "# Run this to upgrade this RPM package" > "$3"; exit 0;;
          INFO/NAME-VERSION-RELEASE) rpm -qp --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" "$1" > "$3"; exit 0;;
          INFO/RELEASE) rpm -qp --qf "%{RELEASE}\n" "$1" > "$3"; exit 0;;
          INFO/GROUP) rpm -qp --qf "%{GROUP}\n" "$1" > "$3"; exit 0;;
          ...
  • # Macs

    Posté par (page perso) . Évalué à 6.

    Et les laptops Apple G4 dotés d'une ATI, comme les iBooks G4 ou certains AlBooks, sont enfin capables de se mettre en veille! (merci BenH, comme d'hab)
    • [^] # Re: Macs

      Posté par . Évalué à 1.

      Ça c'est vraiment une bonne nouvelle, je l'attendais depuis longtemps.
      Félicitation a BenH qui fait vraiment du très bon boulot.
      Il ne manque plus que le support du chipset Airport Broadcom pour finaliser le support des portables Apple car il faut dire que c'est quand même un gros handicap pour linux sur Mac (surement pas pour tout le monde mais pour moi ça en est un gros).
  • # 2.6.11 sur laptop ASUS W1N

    Posté par (page perso) . Évalué à 6.

    Testé et approuvé...le support d'ALSA permet maintenant d'avoir du son et le réglage du volume via artsd sur le laptop ASUS W1N sans avoir à forcer les valeurs pour les registres d'alsa.
    Le son fonctionnait mais les HP n'étaient pas activés.

    Sur les noyaux précédents il fallait compiler avec les options de debug pour ALSA et forcer à la main les valeurs suivantes pour les registres :

    echo -n "26 000F" > /proc/asound/card0/codec97#0/ac97#0-0+regs
    echo -n "36 0000" > /proc/asound/card0/codec97#0/ac97#0-0+regs
    echo -n "64 7110" > /proc/asound/card0/codec97#0/ac97#0-0+regs
  • # Version de développement

    Posté par (page perso) . Évalué à 5.

    D'après les dernières discussions sur la lkml dans le thread "Kernel release numbering" de Linus, il s'agirait d'une version de développement. Ou du moins, les futures versions impaires 2.6.x seraient des versions de développement.

    http://lkml.org/lkml/2005/3/2/247(...)
    • [^] # Re: Version de développement

      Posté par . Évalué à -1.

      Je comprends pas pourquoi ce comm a été "moinsé"...
      • [^] # Re: Version de développement

        Posté par (page perso) . Évalué à 4.


        In other words, we'd have an increasing level of instability with an odd
        release number, depending on how long-term the instability is.

        - 2.6.: even at all levels, aim for having had minimally intrusive
        patches leading up to it (timeframe: a week or two)

        with the odd numbers going like:

        - 2.6.: still a stable kernel, but accept bigger changes leading up
        to it (timeframe: a month or two).
        - 2..x: aim for big changes that may destabilize the kernel for
        several releases (timeframe: a year or two)
        - .x.x: Linus went crazy, broke absolutely _everything_, and rewrote
        the kernel to be a microkernel using a special message-passing version
        of Visual Basic. (timeframe: "we expect that he will be released from
        the mental institution in a decade or two").



        he he :)
        • [^] # oops pardon

          Posté par (page perso) . Évalué à 2.


          In other words, we'd have an increasing level of instability with an odd
          release number, depending on how long-term the instability is.

          - 2.6.< even >: even at all levels, aim for having had minimally intrusive
          patches leading up to it (timeframe: a week or two)

          with the odd numbers going like:

          - 2.6.< odd >: still a stable kernel, but accept bigger changes leading up
          to it (timeframe: a month or two).
          - 2.< odd >.x: aim for big changes that may destabilize the kernel for
          several releases (timeframe: a year or two)
          - < odd >.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
          the kernel to be a microkernel using a special message-passing version
          of Visual Basic. (timeframe: "we expect that he will be released from
          the mental institution in a decade or two").
          • [^] # Re: oops pardon

            Posté par . Évalué à 4.

            Tu devrai lire tout le thread:

            From: Linus Torvalds <torvalds () osdl ! org>
            "[...]I think we should drop the
            original even/odd suggestion for now, and see if this would make more
            sense.."

            http://marc.theaimsgroup.com/?l=linux-kernel&m=110987495523158&(...)
            • [^] # Re: oops pardon

              Posté par . Évalué à 1.

              Oui en fait, beaucoup de développeurs se sont plaints de l'idée de Linus. Linus voulait surtout sortir un 2.6.impair et que les gens le testent pour faire un 2.6.pair bien stable.
              Mais beaucoup de developpeurs pensent que les gens vont arreter de tester les 2.6.impair. Retour au probleme initial donc.

              De plus, cela aurait imposé des delais d'attente plus grand pour tous les gens qui veulent soumettre des patchs.

              Donc, Linus and co. ont finalement décidé de garder le modèle actuel en ajoutant une vraie branche 2.6.x.y comme cela avait été fait avec 2.6.8.1 pour fixer un enorme bug NFS.
              Greg KH va (pour commencer) maintenir 2.6.11.x (et a deja sorti 2.6.11.1 ce soir).
              La branche 2.6.x.y sera susceptible de recevoir tous les petits patchs fixant des choses vraiment importantes.
              Des que 2.6.(x+1) sortira, la branche 2.6.x.y sera stoppée.
  • # No medium found

    Posté par . Évalué à 3.

    Malgré d'innombrables tentatives de me sortir de cette galère, mes lecteurs multi-cartes (Xdrive II et lecteur simple) auxquels je confie ma SD, me renvoient toujours ce message : "No medium found".
    Les rescan-scsi.sh, echos 1 > /sys/.../rescan, le paramétrage de udev pour pré-allouer les pilotes, n'ont aucun effet. J'ai testé tout ce que Google me trouvait.
    Tout est là, dans /dev, la log indique que tout est reconnu...
    Ça marchait à une époque (sur un 2.4 c'est sûr, mais y'a pas udev - qui m'a incité à passer au 2.6), mais ça ne marche plus. Je nourrissais quelque espoir pour ce nouvo noyo, en vain.

    Devrai-je faire une recherche dichotomique pour retrouver un kernel qui marche (pas glop), ou bien quelqu'un aurait-il une solution miraculaire ?

    AU SECOURS :-)
    • [^] # Re: No medium found

      Posté par . Évalué à 2.

      salut t'as essayé :

      http://ebdomino.free.fr/lecteur_multi_cartes.html(...)

      ??

      tiens moi au courant
      • [^] # Re: No medium found

        Posté par . Évalué à 2.

        Merci pour le lien, mais ça ne marche pas. Pourtant j'suis pas un imbécile, puisque je suis doua^Winformaticien :-)

        J'ai viré mes "renommages" udev, on ne sait jamais.
        J'avais bien "Probe all LUNs..." activé (et j'avais lu que ça dispensait du paramètre "max_scsi_luns", mais j'ai testé quand même).

        Ce qui est frustrant, c'est qu'il reconnait tous les lecteurs (SMC, CFC, MMC, MSC), il dit qu'il les attache à sd[a..d], et effectivement, je les retrouve dans /dev.
        (D'ailleurs j'ai le même résultat que je branche d'abord le lecteur puis que j'y glisse la SD ou que je branche le lecteur avec la SD déjà connectée.)

        Mais le mount est toujours aussi agaçant...

        Le seul truc qui semble rester, c'est les pilotes USB compilés dans le noyo plutôt qu'en modules. Au fait, je n'ai activé le support d'aucun lecteur en particulier (sous "USB Mass Storage support") puisqu'il *semble* être reconnu.

        Bord... c'est le premier truc qui me résiste autant sous Linux, grrr
  • # Oui, mais ...

    Posté par . Évalué à 2.

    ... j'aurais déjà aimé profité des 2.6.9 et 2.6.10 sous debian ...

    Alors le 2.6.11 ! :)

    /!\ débranchez vos trollomètres, je confirme que c'en était un ! :)

    Dommage que debian ne mette pas à dispo les sources des différents noyaux patchés, histoire qu'on puisse nous même se les compiler sans problème.
    • [^] # Re: Oui, mais ...

      Posté par . Évalué à 3.

      > ... j'aurais déjà aimé profité des 2.6.9 et 2.6.10 sous debian ...

      Le 2.6.10 est dans sid. Le 2.6.9 y a surement été avant.

      > Dommage que debian ne mette pas à dispo les sources des
      > différents noyaux patchés, histoire qu'on puisse nous même se les
      > compiler sans problème.

      Il est vraiment si difficile d'aller telecharger les sources toi-meme sur kernel.org ?
      Sinon le petit utilitaire ketchup permet de recuperer automatiquement le dernier noyau -rc, -mm, .... Très utile.
      • [^] # Re: Oui, mais ...

        Posté par . Évalué à 1.

        Il est vraiment si difficile d'aller telecharger les sources toi-meme sur kernel.org ?

        Non, car je suis déjà sous un 2.6.11.

        Cependant, j'ai beau faire un coup de
        root@brouettej ~ #>apt-cache search 2.6.1| grep -i kernel
        kernel-patch-2.6-bluez - Linux Bluetooth protocol stack kernel patches
        kernel-patch-lkcd - linux Kernel Crash Dump - kernel patch


        Pas de kernel-source, ni de header, ni de binaire, etc...
        Perso, je préfère compiler les sources du noyaux patchées par Debian.

        Bon, cela dit, make bzImage, make modules, make modules_install, mkinitrd -o /boot/initrd-2.6.11N 2.6.11N, ça n'est effectivement pas très difficile ! :)
        • [^] # Re: Oui, mais ...

          Posté par . Évalué à 2.

          make-kpkg --initrd kernel-image !

          (Ça fonctionne aussi très bien avec des noyaux de kernel.org !)
        • [^] # Re: Oui, mais ...

          Posté par . Évalué à 2.

          > Pas de kernel-source, ni de header, ni de binaire, etc...
          > Perso, je préfère compiler les sources du noyaux patchées par
          > Debian.

          Le noyau 2.6.10 précompilé est dans sid, pas dans sarge (dont le noyau standard est 2.6.8). C'est pareil pour les sources.
          kernel-source-2.6.10 est dispo dans sid.

          kernel-headers n'a plus vraiment d'utilité depuis 2.6 car (contrairement à 2.4), il faut beaucoup plus que quelques fichiers.h pour pouvoir compiler un module externe.

          Ceci dit, je suis d'accord, Debian n'est vraiment pratique pour recuperer facilement les sources de leurs noyaux precompilés
          (ou le patch associé). C'est vraiment fatiguant quand on veut compiler un module externe.

          Par contre, comme Debian applique très peu de patchs (contrairement à Redhat ou Mandrake), partir d'un noyau Vanilla est finalement pas très différent. Si vraiment on veut un noyau proche de Debian, on peut appliquer eventuellement le patch -as qui est justement géré par le mainteneur Debian et sert de base au noyaux précompilés.

          > Bon, cela dit, make bzImage, make modules, make modules_install,
          > mkinitrd -o /boot/initrd-2.6.11N 2.6.11N, ça n'est effectivement pas
          > très difficile ! :)

          Surtout que depuis 2.6, il suffit de faire "make" au lieu de "make bzImage" et "make modules" comme précedemment...
          • [^] # Re: Oui, mais ...

            Posté par . Évalué à 1.

            kernel-source-2.6.10 est dispo dans sid

            Sans vouloir dire que j'ai une machine de production chez moi, je ne me limite qu'aux paquets de la testing. C'est que, si je peux supporter que certaines fonctionnalités soient déficientes par ma faute, il n'en est pas forcément de même pour les autres utilisateurs ;)

            kernel-headers n'a plus vraiment d'utilité depuis 2.6 car (contrairement à 2.4), il faut beaucoup plus que quelques fichiers.h pour pouvoir compiler un module externe.

            Damned ! Je n'avais pas l'info. Donc, je m'embête pour rien quand j'installe les kernel-headers du 2.6.8 ? Dépaqueter les sources, ça suffit ?

            Une feature qui m'avait bloquée pour compiler moi-même mes noyaux, dernièrement, c'est qu'à l'install du noyau compilé via make-kpkg, mkinitrd rate parce-qu'il cherche les modules dans /lib/modules/<nom_correct>N

            Je ne sais pas d'où sort ce "N", mais le noyau ne s'installe pas correctement. Alors, bien sûr, on peut contourner, mais j'ai par habitude de ne pas faire de choses hasardeuses lorsqu'il s'agit du noyau.

            Voilà pourquoi je regrettais que les 2.6.10 et Cie n'étaient pas présents dans testing, ...

            Merci pour les réponses en tout cas.
          • [^] # Re: Oui, mais ...

            Posté par . Évalué à 1.

            > Par contre, comme Debian applique très peu de patchs (contrairement à Redhat

            Faut te renseigner, depuis Fedora Red Hat applique peu de patch. Leur objectif est de bosser le plus possible en upstream. Il n'y a que RHEL qui est beaucoup patché.
            Faut bien comprendre que les distributeurs ne font pas ça de gaité de coeur. C'est une nécessité.
            • [^] # Re: Oui, mais ...

              Posté par . Évalué à 1.

              > Faut te renseigner, depuis Fedora Red Hat applique peu de patch.

              C'est pour ca que j'avais dit Red Hat et pas Fedora...
  • # Pas de ports ps2 en 2.6.11

    Posté par . Évalué à 3.

    salut,

    depuis le 2.6.5 compilé avec les sources kernel.org aucun soucis (2.6.7, 2.6.9, 2.6.10 actuellement)

    mais lors de la compil du 2.6.11 avec la configuration du 2.6.10, au reboot tout se passe bien aucune erreur sauf que mes ports ps2 ne marchent plus.

    pas de clavier et pas souris. n'ayant rien toucher à la configuration, et en ayant vérifié à plusieurs yeux que tous les modules nécessaires au ps2 avaient été compilés, je n'ai pas résolu l'affaire !

    suis je le seul?

    0000:00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4)
    pour la carte.

    et la souris logitech usb/ps2 IR 3 boutons clavier ps2 de base .

    testé avec et sans les driver nvidia
    testé module dans et hors noyau

    aucune erreur, X se charge mais pas de souris

    a+
  • # drm et dc10 \o/

    Posté par . Évalué à 1.

    J' ai lu le changelog et pour moi 2 de bonnes nouvelles :
    le module drm des ati r2** est amélioré ( vérifié ET tourne mieux).
    et le module zoran mjpeg est amélioré (peut être que je pourrais capturer en couleur maintenant)
    \o/
    • [^] # Re: drm et dc10 \o/

      Posté par (page perso) . Évalué à 1.

      bon vu que tu en parle (de la dc10) peux tu maider?
      perssonne ne ma repondu la http://linuxfr.org/forums/10/7271.html
      j'hesitais a poster ici mais vu que plein de gens ont posté pour les drivers nvidia.

      pour ceux qui ont le flemme de cliquer sur le lien:

      Bonjour
      Je dispose d'une carte DC10+ (Chipset Zoran) et depuis le 2.6.1 jusqu'au 2.6.10 elle marchait sans problème (option en brut dans le kernel).
      Mais avec le 2.6.11 elle stop carémment le boot du kernel en me mettant:
      "cannot load module saa7110" et "cannot load module adv7175".
      Même pas de kernel panic, un gros freeze. (j'avais deja ces erreurs la avant mais ca marchait tres bien)

      J'ai donc essayer de tous mettre en module mais la je constate qu'il n'existe pas de module saa7110 et adv7175 a cocher...
      J'ai donc tous coché dans "video for linux".
      Et effectivement il me compile des modules saa7110 et adv7175.
      Malheuresement ca marche toujours pas.. crash avec les modules.

      Donc trois questions:
      -Quelqu'un a t'il le même problème et/ou une solution?
      -Comment se fait-il qu'il y ai des modules "caché" qui n'apparraisent pas dans les choix? (je subodore qu'il sont produits par le module dc10+ mais bon...
      -J'aimerais avoir un kernel sans module (c'est mon choix) d'où le fait que tous est en "brut" MAIS comment se fait il qu'il me réclame des modules alors que j'en ai pas activé le support? (bug?,normal?)

      Merci d'avance
      • [^] # Re: drm et dc10 \o/

        Posté par . Évalué à 1.

        Aïe malheureusement je ne serais pas d' un grand secours , la mienne c' est l' une des premiéres DC10 , celle qui ressemble a une DC30 avec le mse3000. Donc ça ne correspond pas. Et tu peux me croire j' ai déja toutes les peines du monde a avoir une image....

Suivre le flux des commentaires

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