Sortie du noyau Linux 2.6.9

Posté par (page perso) . Modéré par jerome.
0
19
oct.
2004
Noyau
Linux 2.6.9 est sorti hier, le 18 octobre.

Entre 2.6.8 et 2.6.9, il y a beaucoup de différences, qui représentent beaucoup de petites choses :
mises à jour de différentes architectures (Sparc, PPC, ARM), ACPI, i2c, USB, systèmes de fichiers, pilotes vidéo et réseau...

ALSA a bénéficié d'une mise à jour massive, grâce à une synchronisation avec leur CVS; les vérifications de types sont maintenant plus strictes (d'où l'augmentation du nombre de warnings à la compilation - corrigez-en!) et pas mal d'annotations ont été ajoutées (elles permettent d'identifier correctement ce qui vient de l'espace utilisateur et ce qui vient du noyau, afin d'éviter que le noyau patouille dans les données utilisateur). Cette version apporte donc beaucoup de nettoyages et quelques fonctionnalités supplémentaires (notamment dans ALSA, mais aussi quelques unes dans différents pilotes).

Certains utilisateurs pourront se rendre compte que les pilotes nVidia sont (encore) cassés, un patch est disponible.

À noter que le Changelog est pour l'instant incomplet, mais Linus Torvalds va le corriger pour qu'il couvre l'intégralité des changements depuis 2.6.8.

À noter aussi que le patch-2.6.9 disponible sur kernel.org est un patch du 2.6.8 au 2.6.9 et non du 2.6.8.1 au 2.6.9.
  • # Quelques corrections assez importantes

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

    Une faille de sécurité (pas énorme) à été corrigée au passage.
    [PATCH] security issue in firmware system

    The firmware loader has a security issue. Firmware on some devices can
    write to all memory through DMA. Therefore the ability to feed firmware
    to the kernel is equivalent to writing to /dev/kmem. CAP_SYS_RAWIO is
    needed to protect itself.

    [ Editors note: the firmware file is 0644, and owned by root, so this
    "security issue" is really only an issue for people who use
    capabilities explicitly, rather than the regular Unix permissions.
    This patch makes it do the same checks we do for /dev/mem etc. ]
    (au passage, il feraient mieux de prendre l'habitude de les anoncer plus lisiblement que dans le changelog, surtout qu'il y a eu quelques cas très douloureux y'a pas si longtemps).

    Ainsi qu'une autre mise à jour critique de corruption des paquets UDP mais seulement pour "Linux en mode utilisateur".
    • [^] # Re: Quelques corrections assez importantes

      Posté par . Évalué à 5.

      > au passage, il feraient mieux de prendre l'habitude de les anoncer plus lisiblement que dans le changelog

      Le Linux vanilla n'est plus un noyau pour la production. Ou uniquement pour les personnes abonnées à la lkml et qui comprennent ce qui s'y dit.

      C'est lié au nouveau modèle de développement défini durant le dernier sommet noyau :
      http://lwn.net/Articles/94386/(...)
        Andrew pointed out that, during the 2.6 process, he and Linus have been merging patches at a rate of about 10MB/month. There is, he says, no reason to believe that things will not continue that way. The traditional stabilization mechanism, where almost no patches are accepted for long periods of time, does not strike him as a good idea. Instead, Andrew would like to see a 2.6 tree which continues to change and evolve, and let the distributors do the final stabilization work. In his vision of the future, the kernel.org kernel will be the most featureful and fastest kernel out there, but it will not necessarily be the most stable.


      Un autre article qui parle de la même chose :
      http://lwn.net/Articles/95312/(...)

      À lire attentivement avant de protester.
      • [^] # Re: Quelques corrections assez importantes

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

        Le Linux vanilla n'est plus un noyau pour la production. Ou uniquement pour les personnes abonnées à la lkml et qui comprennent ce qui s'y dit.

        Exagéré, pour le moins.

        let the distributors do the final stabilization work. In his vision of the future, the kernel.org kernel will be the most featureful and fastest kernel out there, but it will not necessarily be the most stable.

        Il faut lire stable au sens stabilité des interfaces, APIs et tout ça, pas au sens ça va m'exploser à la figure à chaque branchement de périphérique USB.
        • [^] # Re: Quelques corrections assez importantes

          Posté par . Évalué à 1.

          > Il faut lire stable au sens stabilité des interfaces

          Non.
          Au sens ou la stabilité/sécurité n'est pas la priorité. C'est pris en compte, mais ce n'est pas la priorité. Si tel ou tel driver sucks ou s'il y a un trou de sécurité : tant pis. Tu peux attendre plusieurs semaines avant d'avoir un noyau vanilla avec un fix de sécurité (c'est déjà arrivé plusieurs fois !).

          Relis bien :
          http://lwn.net/Articles/94386/(...)
            ...
            The traditional stabilization mechanism, where almost no patches are accepted for long periods of time, does not strike him as a good idea.
            ...
            These patches include API changes, incidentally. Stable internal kernel APIs have never been guaranteed, but the developers have usually tried to not make big changes during a stable kernel series. That looks to change now.


          Ça me parait claire. Si t'as un serveur en production et met à jour vers Linux 2.6.n+1, ça peut ne pas marcher entre autre à cause d'incompatibilité. Mais évidemment que le noyau vanilla marchera sur la plus part des configurations. Sinon comme ils font les développeurs pour bosser :-)
          • [^] # Re: Quelques corrections assez importantes

            Posté par . Évalué à 1.

            Non.Au sens ou la stabilité/sécurité n'est pas la priorité.

            Ben si, c'est exactement ce qu'il dit....
            • [^] # Re: Quelques corrections assez importantes

              Posté par . Évalué à 1.

              > Ben si, c'est exactement ce qu'il dit....

              Oui, il a raison, :
              - "pas au sens ça va m'exploser à la figure à chaque branchement de périphérique USB."

              Effectivement, ça ne va pas exploser à la figure à chaque branchement de périphérique USB. C'est aussi bien qu'un 2.5.

              Questions :
              C'est bien qu'une machine en production ait les sécurités fix bien après les autres ?
              C'est bien qu'une mise à jours (peut-être avec sécurité fix) soit incompatible avec la version production ?

              Si pour toi ça aussi ça te parait adapté pour la production...., je ferme ma gueule. J'ai des exigences qui n'ont manifestement plus cours.
              • [^] # Re: Quelques corrections assez importantes

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

                Effectivement, ça ne va pas exploser à la figure à chaque branchement de périphérique USB. C'est aussi bien qu'un 2.5.

                T'as pas dû essayer beaucoup de 2.5. C'est incomparable. Le 2.5.69 bootait avec 11472.3 jours d'uptime sur ppc, par exemple...

                C'est bien qu'une machine en production ait les sécurités fix bien après les autres ?
                C'est bien qu'une mise à jours (peut-être avec sécurité fix) soit incompatible avec la version production ?


                C'est pour ça que les gens qui font des choses sérieuses utilisent le noyau de leur distribution. Ils font ça depuis très longtemps, entre nous. Depuis bien avant le "nouveau" modèle de développement qui n'est que l'officialisation de ce qui se passait déjà avant.
                • [^] # Re: Quelques corrections assez importantes

                  Posté par . Évalué à -1.

                  T'es très claire.........................

                  > des choses sérieuses

                  La production n'est pas une "chose sérieuse" ?

                  > Depuis bien avant le "nouveau" modèle de développement qui n'est que l'officialisation de ce qui se passait déjà avant.

                  C'est ce qui est dit dans les url données. Mais il faut faire attention avec toi car tu as sûrement un "avant" et un "avant". C'est le nouveau modèle pour Linux >= 2.6 . L'url donnée ne dit pas que c'est le nouveau modèle pour Linux >= 2.6.9 .

                  Pour ton info, Linux 2.4 était la précédente branche stable. Donc avant, par rapport à 2.6, ce n'était pas comme maintenant.
                  • [^] # Re: Quelques corrections assez importantes

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

                    La production n'est pas une "chose sérieuse" ?

                    C'est de ça dont je parle. T'es bouché, un peu, non?

                    Pour ton info, Linux 2.4 était la précédente branche stable. Donc avant, par rapport à 2.6, ce n'était pas comme maintenant.

                    Je pense à "avant" dans le sens < 2.6. Pour ton info, je suis au courant pour le 2.4. Je suis aussi au courant qu'avant encore il y avait le 2.2, etc.
                    • [^] # Re: Quelques corrections assez importantes

                      Posté par . Évalué à 1.

                      Je veux bien admettre que tu es particuliairement heureux avec Linux 2.6 vanilla en production (comme certainement beaucoup de personnes), mais là ce sont des mainteneurs du noyau qui disent qu'il y a changement.
                      Ils ont tords aussi car ils n'ont pas ton niveau d'"expertise" ?
                      C'est le rédacteur de lwn qui affabule ?

                      Fais moi une explication de texte.
        • [^] # Re: Quelques corrections assez importantes

          Posté par . Évalué à 5.

          Stable au sens stabilité des interfaces?

          Mouai, le fait de devoir utiliser cdrecord avec le setuid bit maintenant, ce n'est pas tres "stable" comme interface, mais j'admets que c'est "presque stable" *cough*.

          Et puis je crois que recemment il y avait une fuite mémoire lors de la gravure d'un CD justement, alors certes ça n'explose pas lors du branchement d'un périphérique USB mais..

          D'un autre coté le 2.4 marche bien alors il y a peu de raison d'etre presser de passer en 2.6..
          • [^] # Re: Quelques corrections assez importantes

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

            Et puis je crois que recemment il y avait une fuite mémoire lors de la gravure d'un CD justement

            Ça c'est ce qu'on appelle un gros bug, comme le coup du NFS qui a motivé la sortie du 2.6.8.1. Ça n'a rien à voir avec le "nouveau modèle de développement", c'est un bug qui serait arrivé de toutes façons...
            • [^] # Re: Quelques corrections assez importantes

              Posté par . Évalué à 0.

              Je ne pense pas. Avec l'ancien mode de développement du noyau, on aurait eu un 2.6.8.2 à mon avis.
              • [^] # Re: Quelques corrections assez importantes

                Posté par . Évalué à 1.

                w.x.y.z : le z est pour les distributeurs, etc...
                Linus c'est fait remonté les bretelles pour le 2.6.8.1 (qui a été qualifié de "fiasco" pour le nom) et il a "promis" de ne plus recommencer pour une release officielle.
                D'ailleur le patch du 2.6.9 est basé sur un 2.6.8 et non sur un 2.6.8.1. Ceux qui ont un 2.6.8.1 doivent faire un "downgrade" avant d'appliquer le patch.

                > Avec l'ancien mode de développement du noyau

                On aurait un 2.6.9 à la place de 2.6.8.1. J'avais EXTRAVERSION n'avait été utilisé pour une release officiel sauf pour le 2.6.8.1.
                • [^] # Re: Quelques corrections assez importantes

                  Posté par . Évalué à 2.

                  Exact, ce que je voulais dire exactement, c'est qu'avec l'ancien mode de développement, on aurait eu des corrections sur des versions stables, et donc un 2.6.9 pour la correction NFS, puis un 2.6.10 pour la correction du problème de gravure. Ceci au lieu de laisser trainer des versions 'stables' avec des bugs/failles à corriger par patch comme actuellement.
            • [^] # Re: Quelques corrections assez importantes

              Posté par . Évalué à 4.

              > Ça c'est ce qu'on appelle un gros bug, comme le coup du NFS qui a motivé la sortie du 2.6.8.1. Ça n'a rien à voir avec le "nouveau modèle de développement", c'est un bug qui serait arrivé de toutes façons...

              Bin si un peu quand meme: le systeme des "release candidate" est sens'e attraper ce genre de bug trivial a detecter, mais j'ai comme l'impression que comme ils ont decid'e que c'etait au distrib de stabiliser le kernel, ils vont parfois un 'peu vite' : sur une branche stable, livrer "quand ca compile", ca fait quand meme un poil desordre..
      • [^] # Re: Quelques corrections assez importantes

        Posté par . Évalué à 2.

        > Le Linux vanilla n'est plus un noyau pour la production.

        De toute façon, qui aurait l'idée de mettre un noyau Vanilla dès qu'il sort ? Les éditeurs font le travail de packaging et il faut laisser le temps de tester.

        Bon bien sûr y'a les gentooïstes qui font leurs ports vite fait, comme si c'était critque de l'avoir le soir même... mais qui aurait l'idée de mettre et maintenir une Gentoo en production ?
        • [^] # Re: Quelques corrections assez importantes

          Posté par . Évalué à 2.

          > Bon bien sûr y'a les gentooïstes qui font leurs ports vite fait

          J'ai testé une Gentoo assez longuement et cette distribution m'a "bluffée" par sa qualité globale compte tenu de ses objectifs (dont je ne suis pas fou mais c'est une autre histoire).
          Le noyau par défaut (stable, c-à-d USE="x86") est un 2.4.
          Le noyau en développement (USE="~x86") est un 2.6 et a les patchs de sécurité/fix "qui vont bien".

          Il faut bien tester les nouveaux noyaux. Que ce soit en parti fait pas les "gentooïstes" ne me dérange en rien.

          Tiens, il y a Linux 2.6.9 dans Rawhide (Fedora). Chiao, je m'en vais tester tout ça.
        • [^] # Re: Quelques corrections assez importantes

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

          Chez gentoo, les paquets vanilla-sources / developpement-sources est mis a jour assez rapidement, oui, mais:
          - pas forcement en stable, sauf maj de sécu.
          - ce n'est pas le kernel "officiel" et par défaut, simplement un parmis ceux que on te propose

          Je sais que ca va te surprendre, mais oui, gentoo fait un travail de packaging et laisse le temps de tester.

          (NB pour le commentaire a coté: c'est ACCEPT_KEYWORDS.)
    • [^] # Re: Quelques corrections assez importantes

      Posté par . Évalué à 8.

      Ainsi qu'une autre mise à jour critique de corruption des paquets UDP mais seulement pour "Linux en mode utilisateur".

      Pour les anglophobes qui ne tiltent pas, il s'agit de User-Mode Linux (UML), le patch de virtualisation de système (un noyau maître permettant de faire tourner plusieurs noyaux fils totalement isolés les uns des autres, partageant les ressources de la machine hôte), qui est une alternative à VServer.


      http://www.usermodelinux.org/(...)
  • # Commentaire supprimé

    Posté par . Évalué à 4.

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

    • [^] # Commentaire supprimé

      Posté par . Évalué à 10.

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

    • [^] # Re: Possibilité d'inclure DSDT perso

      Posté par . Évalué à 2.

      Avant c'etait aussi possible en l'incluant directement lors de la compilation.

      Maintenant il serait capable de le recuperer dans /boot, ca ma l'air effectivement mieux.

      T'as un lien sur cette nouvelle fonctionalite (je n'ai rien trouve dans Documentation/ ) ?
  • # alsa ?

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

    Quelqu'un a plus d'infos concernant les changements dans Alsa ? J'aimerais savoir si ma carte Nforce2 intel8x0 sera mieux supportée (actuellement, je peux pas régler le volume et les applis doivent utiliser l'émulation OSS, le ALSA direct plantant)

    Sinon, j'attend toujours que ma carte graphique (une geforce2MX) supporte le frame-buffer :-(
    • [^] # Re: alsa ?

      Posté par . Évalué à 2.

      Ben déjà pour le frame-buffer, il faut utiliser VESA et non celui pour les Nvidia Riva...
      Sinon moi j'ai aucun problème grave avec le chip audio Nforce 2 et Alsa...
    • [^] # Re: alsa ?

      Posté par . Évalué à 2.

      Au passage y a des deadlock dans les drivers alsa avec le nouvel module-init-tools ...
      Ne fait pas comme moi un script dans /etc/init.d/ qui charge les soundfont midi, sinon vous riquez d'attendre longtemps ;)
    • [^] # Re: alsa ?

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

      Sinon, j'attend toujours que ma carte graphique (une geforce2MX) supporte le frame-buffer :-(

      man vi, man gcc :-)

      Sérieusement, c'est un projet de quelques semaines pour un non-professionnel de la programmation noyau. La plupart du code est "facile" à écrire en prenant exemple sur un autre driver framebuffer et en dégottant les trucs spécifiques dans le driver nv de Xorg... (d'où rivafb vient tout droit, apparemment - d'après les commentaires dans drivers/video/riva/*c)
    • [^] # Re: alsa ?

      Posté par . Évalué à 1.

      J'utilise ALSA avec le 2.6.8.1 sur ma carte mère nForce2 (Shuttle SN45G) et ça marche comme un charme, y compris en 5.1 et avec le mixing software (dmix).

      Je vais essayer le 2.6.9 ce soir si j'ai le temps.
  • # Il n'y a pas que Alsa :-)

    Posté par . Évalué à 8.

    Selon lwn :
    - a lot of NTFS updates
    - block I/O barrier support ( http://lwn.net/Articles/103183/(...) )
    - patch allowing unprivileged process to lock small amounts of memory in RAM
      http://lwn.net/Articles/96587/(...)
      Rik van Riel and Arjan van de Ven have put together a new patch which allows normal users to lock memory into physical RAM without root privilege. The RLIMIT_MEMLOCK resource limit puts an upper bound on how much memory can be locked, and its default value is zero. By raising this limit, system administrators can enable users to lock a single page (useful for cryptographic applications which do not want to see passphrases and clear text swapped to disk) or larger amounts (for CD writing tasks, for example).

    - new USB storage driver
    - cluster-wide file locking infrastructure
    - completely out-of-line spinlocks ( http://lwn.net/Articles/97537/(...) )
    - AMD dual-core support
    - support for the POSIX waitid() system call
    - KProbes ( http://www-124.ibm.com/linux/projects/kprobes/(...) )
    - USB "on the go" support
    - the "flex mmap" user-space memory layout
    - m32r architecture support ( http://www.linux-m32r.org/(...) )
    - a bunch of latency-reduction work (Ingo Molnar)
    - Nouvelle adressage mémoire : http://lwn.net/Articles/91829/(...)
    - new I/O memory access mechanism ( http://lwn.net/Articles/102232/(...) )
    - and lots of fixes :-)

    Après le Kernel coding style, il y a maintenant le "Linux kernel management style" :
    http://lwn.net/Articles/105375/(...)

    Merci à lwn.
  • # Corruption avec gcc 3

    Posté par . Évalué à 3.

    Attention si vous utilisez gcc 3, Richard B. Johnson a remarqué que certaines instabilités ou corruptions des données pouvaient être liées à un bogue de gcc 3. Le kernel 2.6.9 est aussi concerné :

    http://00f.net/blogs/index.php/2004/10/20/register_corruption_with_(...)
    • [^] # Re: Corruption avec gcc 3

      Posté par . Évalué à 2.

      d'après Linus Torvalds il sagit effectivement d'un problème de compilateur, mais affirme cependant n'avoir aucun problème avec ses versions de gcc:


      "Heh. Clearly there's a gcc bug.. What compiler version?

      I've got gcc-3.2 and gcc-3.3, and neither seems to have any trouble, but
      hey, I'm cursed by having fairly up-to-date systems.

      That said, I know what's up, but it would be good to know what compilers
      have this problem.."



      http://kerneltrap.org/node/view/4026(...)

      histoire aussi de comparer le nombre des différents warnings entre les versions de la branche 2.6 avec gcc 3.2.2 vous pouvez jetter un coup d'oeil sur ce lien:

      http://developer.osdl.org/cherry/compile/(...)
  • # Patch grsec ou equivalent

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

    Bon, sachant que le site de GRsecurity ne va pas sortir de patch GRsec pour 2.6.{8,9}.x, quelqu'un aurait-il une bonne adresse pour un patch de sécurité sur kernel 2.6 ?

    Merci,
    Steph
  • # Graveur SCSI

    Posté par . Évalué à 1.

    J'ai beaucoup de probleme avec le noyau 2.6.8.1 avec une Fedora 2 pour graver :(

    Je doit utiliser, en root, un console avec les programmes mkisofs/cdrecord et encore, ca ne passe pas a chaque fois.
    J'ai finit par arreter le _gravationnage_ sous Linux et je doit repasser sous Window$ pour ne pas casser tous mes cdr(w).

    Quelqu'un a t'il des informations les graveurs SCSI avec le 2.6.9 ?
    • [^] # Re: Graveur SCSI

      Posté par . Évalué à 2.

      > Je doit utiliser, en root

      Normal :
      http://lwn.net/Articles/98379/(...)

      Pour le reste, j'ai entendu parlé de quelques problèmes qui doivent être corrigés.
      Avec la dernière FC3T3 je peux graver sans être root et sans suid pour cdrecord (graveur IDE).

      > avec une Fedora 2

      Il y aura _peut-être_ une mise à jour pour FC2 après la sortie de FC3.
  • # Kernel 2.6.9 ? Yes ! Mais ...

    Posté par . Évalué à 0.

    Hmm ... Je tourne sous le Kernel 2.6.9 sur mon portable depuis samedi soir ... Ha çà y a pas, c'est un excellent kernel : c'est stable, mon proc (un Pentium-M 715 alias "Dothan 1.5 GHz") est bien reconnu, c'est bien le speedstep avec le démon PowerNowD !

    MAIS il y a un truc qui me choque : ils ont viré le supermount !
    Comment je fais moi, maintenant, avec ma clef USB, sans supermount, sachant qu'avec submount, si je lance submountd, j'ai doit au message "submountd: 1 argument received, 6 needed." ?

    Comment je fais, hm, pour utiliser ma clef USB avec le kernel 2.6.9 ?

    Ils se seraient pas un peu ch*é dessus, Linus et les autres, en enlevant le supermount du kernel 2.6.9 ? :)

Suivre le flux des commentaires

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