Kernel Traffic #240 For 10 Nov 2003

Il n'y a pas de version 2.6 de kgdb actuellement, la version 2.4 a aussi quelques problèmes qui font que c'est mieux de ne pas l'utiliser du tout

Je prévoyais de porter à nouveau le code dans -mm et de me débarrasser d'une partie des bidouilles pas belles dans le 2.4. Faire ceci de manière satisfaisante suppose d'ajouter des annotations dwarf2 dans entry.S et autres fichiers assembleur. Cela permettrait de se débarrasser de la bidouille "interrupt threads" dans le 2.4, parce que gdb pourrait backtracer directement à travers les exceptions et interruptions.

Voila -pre8... Il contient un bon nombre de correctifs ACPI, changements réseau, changements drivers réseau, quelques correctifs IDE, merge SPARC, merge SH, correctifs tmpfs, correctifs NFS, la correction d'une importante faute d'orthographe dans VM, entre autres.

Les gens ayant des crashs IDE sur des Alpha avec les kernels précédents, peuvent essayer ça.

Ce sont les même symptômes que j'ai vu dans test7, corrigés par:

http://marc.theaimsgroup.com/?l=linux-kernel&m=106606272103414&w=2

Patrick, alliez vous soumettre le patch pour résoudre ceci? Je pense que ce genre de problème pourrait cadrer avec les critères d'intégrations de Linus pour test10.

(Ce n'est pas un problème APM, c'est un problème PM générique qui apparaît aussi dans swsusp. Et sûrement même dans quelques systèmes ACPI.)

Ok, 2.6.0-test9 est sorti et se trouve aux lieux habituels..

Tout d'abord, je dois dire que cette semaine a été bien meilleure que la dernière. J'ai bien _moins_ maudit certains développeurs: tandis que beaucoup de gens voulaient se synchroniser avec moi après le "gel de stabilité" de -test7 avec des choses qui ne concernaient pas vraiment la stabilité, cela a bien baissé cette semaine, et je n'ai pas eu a être vraiment grossier avec gens.

Il y a quelques mises à jour XFS et cifs, mais elles sont plutôt bénignes et sont simplement des correctifs. Oh, et les driver SATA a été inclus, vous pouvez soit le désactiver soit vous autoriser à utiliser du matériel moderne.

De toute façon, bien que j'aie été content du progrès depuis -test7, je veux que ce gel de stabilité total marche encore mieux. Le patch test9 fait environ 120Ko compressé, ce qui est peu pour une semaine de travail, mais qui est toujours plus que ce que je veux voir avant une release stable.

Donc, les gars, travaillons encore plus pour la test10. Je vais ignorer _complètement_ les patches qui ne corrigent pas de bogues majeurs. Ne m'envoyez pas quoique ce soit que d'_autres_ ne considéreraient pas comme horriblement critique.

En d'autres mots, même si vous pensez que quelque chose est le bout de code le plus important du monde, si vous ne pouvez pas amener tante Tilly à dire "oh, mais c'est indispensable", alors ne me l'envoyez pas.

Si ça corrompt les données, c'est un problème de sécurité, ou cause des plantages, ou un dysfonctionnement basique; et que cela apparaît sur du matériel que les gens _normaux_ sont supposés avoir, alors c'est critique. Sinon, c'est du bruit et ça devrait attendre.

Si ça marche, je soumettrai -test10 à Andrew Morton, et si il le prend, nous aurons un vrai 2.6.0 après un dernier test d'endurance. Alors essayez de donner un coup de main. Nous en serons tous plus heureux.

Il y a des choses qu'Andrew voudra ,je parie, appliquer à -STABLE: des trucs comme les mises à jours d'architectures, etc, qui clairement permettent de corriger certaines choses. Mais en ce moment, je veux éviter même ce type de bruit: ça n'aide clairement pas à _tester_ la stabilité, et je ne suis intéressé que par ça.

Par exemple, la semaine dernière j'ai juste laissé tomber quelques mises à jour S390 sans même les regarder. C'était trop tard - et même si ça corrigeait des bogues, je ne pense pas qu'appliquer ces patches soit important pour 2.6.0.

Ainsi, je suis content de voir que la taille des patches -test8 et -test9 ait été en diminuant, mais même -test9 était trop gros pour que je dise que nous étions clairement en train d'"approcher asymptotiquement un kernel stable". D'un certain point, "les patches bruyants" sont mauvais parce qu'ils rendent difficile de se rendre compte de l'état général de l'arbre.

En particulier, si le patch 2.6.0-test10 fait juste 30Ko compressé, et que je peux le visionner avec "less" et voir que chaque partie du patch est claire et pas quelque chose de vraiment effrayant, je serai bien _plus_ content de passer le relais à Andrew. A l'opposé, si le patch est plein de choses qui ne sont pas clairement évidentes, je serai moins content et je devrai m'interroger sur les effets de bord.

Je viens de finir une seconde version de mon "Wonderful World of Linux 2.6" que j'ai mailé en juillet. Ce document est la liste raisonnablement complète des nouvelles fonctionnalités de Linux 2.6, avec des explications. Celui-ci va jusqu'au test9 sortie hier et prend en considération beaucoup des retours de membres de la liste et d'ailleurs. D'importantes parties on été réécrites pour des questions de style, etc...

Si vous avez lu le précédent, il n'y a en fait pas tellement de changements depuis -test1. Si vous voulez juste voir quelques uns des changements, j'ai esquissé une liste sur http://kniggit.net/wwol26-changes.html.

Si vous n'avez pas lu le précédent (même si vous l'avez lu), j'ai posté l'update sur http://kniggit.net/wwol26.html. (Version texte: http://kniggit.net/wwol26.txt)

Dites-moi ce que vous en pensez. J'espère que ça sera une bonne ressource pour les gens voulant en savoir plus sur Linux 2.6. A moins qu'il n'y ait d'importantes inexactitudes, je ne mettrai pas ceci à jour jusqu'à la sortie officielle du 2.6.

netdev@oss.sgi.com n'a pas de page web officielle pour dire que ça existe. Pas d'info sur comment souscrire ou quelles sont les règles de la liste.

Sur http://oss.sgi.com/ la liste netdev n'est même pas mentionnée.

Je ne trouve pas d'archive de la mailing list netdev.

J'aimerais lire netdev mais je ne suis pas décidé à souscrire puisque les informations la concernant sont introuvables.

Peut-être que SGI devrait créer une page "netdev" quelque part sur oss.sgi.com, faire un lien à partir de "projects lists" ou "newsgroups and mailinglists", et faire revivre l'archive? SVP?

Je l'ai généralisé afin d'enlever une tonne de sales bidouilles 440GX. J'ai aussi réduit la taille du code en échangeant une grosse table contre des petites fonctions __init. J'ai envoyé des commentaires à akpm la dessus mais je n'ai jamais fait une version 2.6. C'est le même code dans les deux cas de toute façon.

En ce moment, j'ai des examens, c'est pourquoi je lis mes mails, je ne révise pas ;)

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm1

• kernel.org est lent - le diff est aussi sur

  http://www.zip.com.au/~akpm/linux/patches/2.6.0-test9-mm1.gz

• Quelques correctifs pour la récupération de la mémoire dans la VM.
• Le code EFI ia32 semble complet maintenant.
• Les régressions du récent scheduler E/S devraient être corrigées.
• Abandonné les patches scheduler-E/S-selectionnable-au-runtime.
• Un bon nombre de correctifs au code readahead pagecache devrait aider les grosses charges comme les bases de données à E/S non directes.
• Divers correctifs, pour la plupart mineurs.

Voici la -pre9. Seuls les corrections de bogues seront acceptées jusqu'à la 2.4.24-pre maintenant.

-pre9 retire quelques changements ACPI problématiques. Il inclut aussi une mise à jour USB, JFS, corrections sis900/starfire/tg3, etc.

ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/modutils/v2.4

modutils-2.4.26.tar.gz          Tarball source, inclut le fichier spec RPM
modutils-2.4.26-1.src.rpm       Comme précédemment, au format SRPM
modutils-2.4.26-1.i386.rpm      Compilé avec gcc 2.96 20000731, glibc 2.2.2.
modutils-2.4.26-1.ia64.rpm      Compilé avec gcc 2.96-ia64-20000731, glibc-2.2.3.
patch-modutils-2.4.26.gz        Patch pour modutils 2.4.25 to 2.4.26.

Extrait du Changelog

• Ignore les sections SHT_MIPS_DWARF. Alvaro Martinez Echevarria.
• Ajoute -malign-double aux cflags pour les builts 64 bit.
• Corrigé les problèmes d'édition de liens avec zlib. Maciej W. Rozycki.
• Retiré les limites mises en dur sur la longueur des lignes de modules.conf.
• Updates des alias. Red Hat.
• Correction des makefiles pour les builds paralleles utilisant bison. Andreas Haumer.
• Documentation des différences entre les patterns et les modules dans modprobe. Frank Murphy.
• Suppression du message "module not found" lors de modprobe -q. Frank Murphy.
• Ajout du nom du module sur quelques messages. Red Hat.
• Ajout du support amd64. i386 correspond maintenant à du 32/64 bit combiné. Arnd Bergmann.
• Les anciennes versions de la glibc avaient un mauvais nom pour R_390_GOTOFF32 Arnd Bergmann.
• Lancer les répertoires connus dans l'ordre historique correct. Red Hat.
• Mise à jour de config.sub, config.guess avec la glibc 2.3.2.
• Ajout du support sh64. Benedict Gaster.
• Ne compiler sys_oim.o quand COMPAT_2_0 est mis, ça ne marche pas avec ia64 et les récentes glibc.

La version 1.1.4 de JFS est disponible aujourd'hui.

Drop 67 du 30 octobre 2003 inclut les correctifs pour le système de fichiers et les utilitaires.

Changements aux utilitaires

• Contournement du bogue de gcc 2.95
• Gère le log complet dans crash
• Correctif du format des messages

Changements au Système de fichiers

• S'assurer que le buffer du journal est écrit sur le disque
• Gestion des erreurs améliorée
• Retrait d'un appel redondant et pouvant causer une concurrence critique (race condition) block_flushpage
• Correction de correction critique entre link() et unlink()

Note: Les kernels de développement 2.4.23 et 2.6 sur kernel.org sont mis à jour avec le dernier code JFS. Les mises à jour du système de fichiers disponibles sur le site web ne sont utiles que pour maintenir les kernels 2.4 précédents.

Pour plus de détails sur JFS, visitez notre site web: http://oss.software.ibm.com/jfs

Le patch de 54Ko sur http://ftp.linux.org.uk/pub/linux/willy/patches/fs-const.diff met beaucoup des file_operations, dentry_operations, address_space_operations, inode_operations, super_operations et dquot_operations à const.

Cela fut inspiré par intermezzo qui faisait quelque chose de mal et que le compilateur ne pouvait pas détecter. En faisant en sorte que ces pointeurs pointent sur des structs constants, le compilateur sait que nous ne devrions pas faire ça et émettra un warning.

Comme bonus pour les gens de l'embarqué, ce la nous autorise à déplacer une plus grosse partie du kernel dans des parties ROM. Je l'ai juste fait pour ext2 et quelques *_operations connus dans ce patch, mais ça pourrait être fait dans beaucoup d'autres systèmes de fichiers, ça ne sauve que quelques centaines d'octets par système de fichier, mais tout s'additionne.

J'ai rendu disponible un nouveau snapshot de la chaîne d'outils uClinux/ColdFire basé sur GCC 3.3.2 et GCC 3.4-prerelease:

http://www.uclinux.org/pub/uClinux/uclinux-elf-tools/gcc-3/

Cette version incorpore un bon nombre de mises à jour et de correctifs depuis la dernière version officielle.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm2/

• Divers correctifs. Peut-être la moitié d'entre eux méritent d'aller en 2.6.0.

• Quelques améliorations à l'ordonnanceur E/S anticipant et quelques bidouilles dans le readahead pourraient aider certains benchmarks de base de données.

  L'ordonnanceur anticipant est toujours un peu en deçà par rapport à l'ordonnanceur deadline dans ces charges lourdes un peu aléatoires - il le sera sans doute toujours.

• "Un nouveau driver pour l'interface ethernet du chipset nForce NVIDIA licensé sous la GPL"

  Tester ceci serait grandement apprécié. Envoyez les résultats à linux-kernel ou netdev@oss.sgi.com et Manfred les rassemblera, merci.

• Je serai hors-ligne pour quelques jours.

Quelqu'un a modifié l'arbre CVS sur kernel.bkbits.net directement. Dave à jeté un coup d'oeil à la machine et il semble bien que quelqu'un ait essayé et réussi à y entrer.

Nous avons corrigé le fichier en question, la modification a été faite ici même à BitMover et après avoir transféré les fichiers, nous les vérifions et nous nous assurons qu'ils sont OK et que le fichier a été converti.

L'arbre CVS est bon, vous devriez effacer et mettre à jour exit.c pour vous assurer que la version actuelle est dans votre arbre.

Le fichier incriminé est kernel/exit.c qui a quelques entrées en trop comme ça:

    revision 1.121
    date: 2003/11/04 16:44:19;  author: davem;  state: Exp;  lines: +58 -0
    Oops, I worked on the  the wrong file, fixed again.
    ----------------------------
    revision 1.120
    date: 2003/11/04 16:42:00;  author: davem;  state: Exp;  lines: +0 -58
    *** empty log message ***
    ----------------------------
    revision 1.119
    date: 2003/11/04 16:22:47;  author: davem;  state: Exp;  lines: +2 -0
    *** empty log message ***
    ----------------------------
    revision 1.118
    date: 2003/10/27 19:50:03;  author: torvalds;  state: Exp;  lines: +11 -5
    Fix ZOMBIE race with self-reaping threads.

    exit_notify() used to leave a window open when a thread
    died that made the thread visible as a ZOMBIE even though
    the thread reaped itself. This closes that window by marking
    the thread DEAD within the tasklist_lock.

    (Logical change 1.14141)
    ----------------------------

Remarquez comment les trois entrées du haut n'ont pas le (Logical change X.YZ) à la fin. C'est un pointeur pour que vous puissiez vous rendre compte des frontières de changeset et c'est ajouté pendant le processus de conversion. Le fichier ici est bon, ce qui me conduit à penser quelqu'un a modifié le fichier soit sur kernel.bkbits.net ou à réussi à la mettre à travers le pserver. Dave jure ses grands dieux que ce n'était pas lui, donc si quelqu'un peut sortir du rang et prendre ses responsabilités ça serait bien.

Ce n'est pas un gros problème, nous avons les moyens de gérer ce genre de problème, mais c'est gênant pour les utilisateurs CVS.

Non. Il y a deux façons d'arriver à une version du kernel: les patches pour moi par émail (qui reçoivent un examen plus ou moins détaillé en fonction de la personne, mais les fichiers de base nécessiteraient de toute façon une explication) et à travers les merges BK.

Et les personnes qui mergent avec BK n'auraient pas utilisé l'arbre CVS.

BK a vraiment besoin de signatures digitales par changeset, et je l'ai demandé à Larry pendant des années. :-) Et il y a un risque similaire mettant en jeu un patch subtil prétendant de corriger un bogue, mais qui en réalité crée une faille de sécurité. Quelqu'un de suffisamment malin pour envoyer un "patch" à Linus, qui peut forger les en-têtes de mail pour qu'il ne remarque rien --- et peut-être même forger un cc à la LKML, bien qu'il ne soit jamais envoyé là bas, pourrait être capable d'introduire un tel code dans les sources officielles. Ceci est particulièrement vrai si le troyen est camouflé autour d'autres modifications plausibles, et ait un champ SMTP From désignant un développeur du kernel connu.

Une suggestion pourrait être que tous les patches envoyés à Linus soient au moins signés avec GPG, mais ça suppose que Linus soit d'accord pour utiliser GPG, ou que son lecteur de mail fasse de la vérification GPG automatique. Une des raisons pour laquelle je pense que l'intégration avec BK serait une Bonne Chose est que (a) cela deviendrait automatique, et (b) au lieu d'être uniquement vérifié par Linus quand il reçoit le patch, moi ou qui que ce soit pouvons vérifier la signature digitale du changeset de notre choix. Cette vérification distribuée est extrêmement puissante, et je l'espère, cela explique pourquoi nous avons tant besoin de de cette fonctionnalité.

Nous avons sorti libsysfs v0.3.0 en tant que partie du package sysfsutils.

Ce package peut être téléchargé à partir de: http://linux-diag.sourceforge.net/

Les changements incluent:

• Support du sous-système "block". Block est maintenant considéré comme une "classe" sysfs.
• Possibilité de construire des librairies à la fois partagées et statiques.
• Correction du support de l'attribut "write".
• Ajout de quelques routines "test" pour démontrer l'utilisation de l'API.
• Les fichiers en-tête seront dorénavant installés dans /usr/include/sysfs
• Support du décodage des noms PCI.

Les commentaires, suggestions et contributions sont les bienvenues. La mailing list pour les discussions sur libsysfs et autres utilitaires de diagnostic est

http://lists.sourceforge.net/lists/listinfo/linux-diag-devel

La suite de test Linux Test Project <http://www.linuxtestproject.org> est disponible. La dernière version de la suite de tests contient plus de 2000 tests pour Linux. Notre site web contient aussi d'autres informations comme: résultats de tests, une matrice d'utilitaires de tests pour Linux, une zone pour maintenant les correctifs pour des problèmes bloquants connus dans les versions 2.5/2.6 du kernel, des articles techniques et HowTos sur le tests Linux, ainsi qu'un utilitaire d'analyse de couverture de code.

Point importants:

• Mise à jour du script LTP pour recueillir des statistiques 'iostat' si besoin est.
• Mise à jour des tests SCTP afin de supporter le code SCTP du kernel 2.6 actuel.
• Ajout d'un nouveau test NFS, nfs04, afin d'aider à tester l'intégrité des données lors de copies à travers les montages.
• Application de plus de correctifs de bogues, de patches et nettoyage du code.

Nous encourageons la communauté à poster les résultats, patches ou nouveaux tests sur la mailing list <ltp-list@lists.sf.net> et d'utiliser le CVS bug tracking afin de rapporter les problèmes que vous pourrez rencontrer avec la suite de tests.