Journal Le kernel 2.6.0 stable, c'est pas pour demain

Posté par  (site web personnel) .
Étiquettes : aucune
0
29
nov.
2003
En rapport avec des journaux récents sur le prochain noyau:

http://linuxfr.org/~quzqo/7179.html(...)
http://linuxfr.org/~ngc891/7203.html(...)

Un thread de la lkml met le doigt où ça gratouille:

http://testing.lkml.org/slashdot.php?mid=433931(...)

En gros, à la question "Le kernel sera-t-il stable d'ici un mois, pour sa sortie", la réponse est "non, mais c'est normal, cf noyau 2.4". Larry McVoy dit même que le 2.6.0 ne servira pas à grand chose. Il faudra attendre plusieurs mois pour avoir quelque chose d'exploitable.

Je ne sais pas ce que vous en pensez, mais moi ça me fait un peu mal. Je me souviens d'avoir attendu le 2.4.18 pour faire marcher correctement ma webcam , qui n'a rien d'exotique par ailleurs, alors que ce noyau était estampillé "support USB".

Je préférerais sincèrement que la sortie du 2.6.0 soit repoussée de plusieurs mois afin d'offrir un niveau de finition supérieur à la série 2.4. Après tout, si certaines personnes sont pressées, elles peuvent utiliser les versions de test.

J'ai hâte de voir l'intervention de Linus dans ce thread (il semble hors-ligne depuis quelque temps)
  • # Re: Le kernel 2.6.0 stable, c'est pas pour demain

    Posté par  . Évalué à 8.

    Ben oui mais c'est le genre de dilemne qui se mord la queue. Si ton noyau n'est pas "stable", tu ne le sors pas. Mais si tu ne le sors pas, il n'y aura pas assez de testeurs pour éprouver la majorité des situations et son noyau ne sera jamais "stable".

    Il y a trop de variabilité dans les configs de PC actuellement (notamment avec tout le bordel des machins USB, bidules wi-fi & co) pour espérer avoir un noyau stable dès la première version. Microsoft permet aux drivers d'être livrés sous forme de binaires indépendants de la version du noyau, ce qui résoud le problème pour eux (ils sortent l'OS d'abord et les constructeurs s'occupent des errata dans leur coin). Linux n'a pas fait ce choix (notamment pour que la GPL ne perde pas de sa force dans le cadre du noyau), et doit gérer la cohérence et la stabilité des drivers à l'intérieur du noyau lui-même.
    • [^] # Re: Le kernel 2.6.0 stable, c'est pas pour demain

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

      C'est vrai, je suis d'accord avec toi, mais quand tu vois ce genre de chose:

      http://lkml.org/lkml/2003/11/27/107(...)

      Ça fait peur. Surtout que les bugzillas en question datent du -test4
      C'est un problème de base du système qui est loin d'être évident. Il y a eu d'autres rapport de bugs sur des corruptions de mémoire, plus ou moins aléatoires et plus ou moins reliées à CONFIG_PREEMPT.

      On ne parle pas de drivers et/ou code annexe, mais bien du core. Le 2.6.0-test est quasi-inexploitable chez moi, même en virant toutes les options.
      • [^] # Re: Le kernel 2.6.0 stable, c'est pas pour demain

        Posté par  . Évalué à 2.

        C'est variable, en effet. Chez moi, j'ai un 2.6.0-test9 qui fonctionne sans problème sur un portable Centrino.
        • [^] # Re: Le kernel 2.6.0 stable, c'est pas pour demain

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

          J'aurais du préciser. En fait, le 2.6.0-test9 fonctionne comme un charme chez moi aussi mais depuis le -test10, plus rien à faire.

          Le problème est bien plus ancien (-test4) mais il n'apparait sur ma bécane que maintenant, ce n'est donc pas le passage -test9 -test10 qui est en cause. C'est juste un catalyseur. C'est pour ça que c'est assez grave: c'est une mise en lumière d'un défaut de base.

          Je t'incite fortement à tester le -test11. Peu importe la config (mais avec PREEMPT, c'est plus facilement reproductible), pour le tester essaie juste de recompiler un noyau 2.6 avec pas mal d'option pour mettre ta bécane en charge. Chez moi, ça plante systematiquement à la première compilation.
          Tu peux réessayer 2 ou 3 fois à la suite pour être sur.

          J'ai même reproduit le oops avec un tout petit noyau de 700Ko, c'est indépendant d'à peu près tout, même l'architecture: les gars d'IBM avait reproduit le truc sur ppc64. Tout ce qu'on sait, c'est que l'endroit où ça plante (slab.c) n'est pas en cause. Il y a juste un bit d'erreur en mémoire.

          Et personne ne sait comment résoudre ce oops.
          • [^] # Re: Le kernel 2.6.0 stable, c'est pas pour demain

            Posté par  . Évalué à 2.

            Je suis exclusivement sous 2.6 quasiment depuis la sortie des -test*. Je n'ai eu aucun problème jusqu'à recemment. La configuration a même été simplifiée par l'inclusion d'alsa dans les sources.
            Et je n'ai ni plus ni moins de plantages qu'avant (nvidia oblige).

Suivre le flux des commentaires

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