Kernel Traffic #243 For 1 Dec 2003

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

kernel.org est lent en ce moment. Ça sera sur:

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

• Diverses corrections; non critiques généralement.
• Changements significatifs au code AIO et direct-io. Ça a encore besoin d'améliorations; j'espère que nous sommes proches d'une solution à ces problèmes.
• Diverses corrections à l'allocator ext2 et ext3. Cela a besoin de tests sur de gros systèmes SMP.
• Quiconque à des patches et qui pense qu'ils devraient aller dans la 2.6.0, re-testez les avec -mm3 et faites-le moi savoir, merci.

Vous ne pouvez pas déboguer les triples faults, ils lèvent un connecteur hors du CPU, ce qui provoque un reboot sur du matériel PC classique.

Mais les double faults sont sont interceptées, et les outils de deboguage sont en fait dans le kernel standard. Ça ne donnera pas un rapport de bogue aussi bon qu'un oops "classique", puisque je ne voulais pas que le gestionnaire de double fault ne touche au quoi que ce soit de potentiellement dommageable, mais ça donne souvent une bonne idée sur ce qui a pu mal tourner. Bien mieux que le triple faut (ce que nous faisons toujours pour des cas de corruption catastrophiques, des tables de pages du kernel complètement sans dessus-dessous etc - c'est juste très difficile a éviter une fois que vous êtes suffisamment corrompu).

Puisque certains constructeurs refusent de rendre disponible des specs ou même un driver Linux binaire pour leurs cartes WLAN, j'ai décidé de résoudre ce problème en développant un module kernel qui peut charger des drivers Ndis (API des drivers réseau de windows). Je n'essaye pas d'implémenter toutes les API Ndis, mais plutôt d'implémenter les fonctions nécessaires à ce que ces cartes non supportées marchent.

Pour l'instant ça marche bien avec ma Broadcom 4301 et je voudrais contacter des personnes ayant des cartes similaires et désireuses de faire quelques tests/bidouillages.

Visitez cette page pour plus d'infos: http://ndiswrapper.sourceforge.net/

SVP! Je ne veux pas lancer une flamewar débattant du bien fondé de la chose. J'essaye juste de faire avancer mon propre problème, et je doute que ce projet change en quoi que ce soit la manière dont Broadcom traite les utilisateurs de Linux.

Allez vous charger ces drivers en ring 0 (espace kernel)? Pour ce que j'en sais, linux ne supporte que ring 0 (kernel) et ring 3 (espace utilisateur). Cependant, il semble qu'il soit préférable de charges les modules binaires en ring 1 (ou même en espace utilisateur si c'était possible). Je ne peux pas dire que je fais confiance aux drivers binaires et/ou windows de ne pas mettre le kernel en l'air :) en fait le driver pourrait être exempt d'erreurs - il est juste fait pour un autre OS, et donc des choses incompréhensibles pourraient arriver...

Pendant qu'on y est, charges les modules binaires en ring 1 pourrait aussi être une bonne idée pour le module NV et cie. Bien que je n'aie aucune idée de la difficulté que représente le fait de faire marcher ring 1 (et même si c'est pertinent de le faire en ring 1 au lieu de ring 3 avec iopl/ioperm) et de la pénalité en termes de performance pour ne pas être en ring 0...

Est-ce que les drivers NDis marchent en 32bits? Quelques bidouilles oui! C'étaient les interfaces des drivers DOS en mode réel pour MS-DOS. Maintenant il y a une bidouille sur une autre appelée NDIS-6. Ils utilisaient aussi la convention d'appel Pascal qui plantait le code 'C' (vous aviez besoin d'un wrapper assembleur)

Ils sont une perte de temps. Pourquoi voulez vous cloner une interface Microsoft pour une OS non-Microsoft alors que vous ne pouvez pas autoriser de tels déchets tourner dans le kernel de toute façon.

Le problème avec les drivers binaires de tiers n'est pas l'interface avec le kernel. Linux a une interface publique, bien connue et établie. Le problème c'est que n'importe que driver venant d'un tiers peut f**rer le kernel par erreur ou par volonté. Donc les drivers venant de tiers DOIVENT fournir le code source pour que l'on puisse les corriger ou les modifier si (lire quand) des problèmes sont découverts.

Cela pourrait être une réponse correcte (excepté pour Intel), mais je suppose que la _vraie_ réponse c'est que les ring 1/2 sont juste fondamentalement inutiles, et ça n'a rien à voir avec les implémentations ou quoi que ce soit d'autre.

Pour avoir une performance raisonnable, un driver nécessite d'avoir un accès direct aux buffers qu'il doit remplir. Et pas juste les données , mais les méta données aussi - les pointeurs qui comprennent les listes skb (ou mbuf dans BSD), etc...

Donc, même si vous utilisiez ring 1/2 pour le driver vous auriez besoin de donner la permission en écriture pour une grosse partie des structures de données que le "coeur" du kernel réseau utiliserait.

Ce qui veut dire que soit vous mettez le coeur du kernel en ring1/2 aussi (au quel cas vous n'utilisez plus ring0 pour quoi que ce soit d'intéressant - vous pourriez mettre un micro noyau, mais, il n'y a pas vraiment de raison), ou vous mappez un _tas_ des metadonnées de ring0 dans ring1/2, au quel cas vous perdez les raisons qui vous ont conduit à utiliser un domaine de protection différente.

Et, franchement, si vous vouliez mapper dynamiquement tous les intervalles en faisant attention, pourquoi utiliser ring1/2? Vous pourriez tout aussi bien utiliser ring3 et tout ça pourrait un wrapper en mode utilisateur. Vous n'aurez jamais une performance extraordinaire, mais pour le deboguage, c'est acceptable.

De toute façon, quelle que soit la façon de voir le problème, ring1/2 ne vous _apporte_ rien. Ce qui est, pour finir, la _vraie_ raison pour laquelle personne ne les utilise.

(Je suis d'accord, le fait que le matériel de pagination x86 rende les 1/2/3 équivalents, le rend encore _moins_ utile, mais je pense que c'est une erreur de penser que ça serait plus utile si les tables de pages perdaient de précieux bits en information de niveau inutile).

Le multi-ring était une erreur. Paix à son âme. La seule raison pour laquelle il fait une sorte de comeback aujourd'hui (Palladium-ou-quelque-soit -son-nom-aujourd'hui) n'a pas de raison technique, est purement sur d'autres sujets.

Les bonnes gens de Cambridge ont fait une (très bonne) VMM qui exploite ring0/1/3 pour permettre à une même machine de faire tourner divers kernels indépendamment (les kernels doivent être portés afin d'utiliser l'architecture xen).

Xen lui-même s'exécute en ring0 et les systèmes d'exploitations "hôtes" s'exécutent en ring1, le code utilisateurs tourne en ring3, comme d'habitude. Ils font tourner linux sous xen ;)

La page d'accueil du projet est sur http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ et un papier décrivant le tout est sur: http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf

C'est ce à quoi je faisais allusion quelques lignes plus tard - disant que si vous déplaciez le driver dans ring1, vous devriez _tout_ déplacer en ring1 en ne laissant qu'un micro noyau en ring0.

Je ne suis pas trop pour les micro noyaux, mais une machine virtuelle abstraite pure, n'est plus la masturbation intellectuelle académique que nous avons vu dans les années 80.

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

• Quelques corrections sur des patches qui ne sont que sur -mm actuellement.
• Correctifs mineurs que nous gardons pour le post-2.6.0.
• Les problèmes d'intéractivité que le patch ACPI PM timer montra devraient être résolus la - en cas contraire faites-le moi savoir.

Voici la -rc2.

D'importants correctifs netfilter, divers correctifs ACPI, quelques corrections dans les drivers (tulip, tg3, megaraid2), entre autres.

Si aucun problème n'apparaît, cela devrait devenir une version finale dans quelques jours.

J'ai sorti la version 006 de udev. Vous pourrez le trouver sur: kernel.org/pub/linux/utils/kernel/hotplug/udev-006.tar.gz

Du a mon congé de paternité pour tout le mois de novembre, je n'ai pas fait de rpms, mais le fichier spec est dans le tarball, donc je peux le faire si vous le désirez.

udev est une implémentation de devfs en espace utilisateur utilisant sysfs et /sbin/hotplug. Il nécessite un noyau 2.6 pour tourner.

Les principaux changements depuis la version 005 sont:

• Les règles sont maintenant appliquées dans l'ordre approprié, au lieu de l'ordre qui se trouve dans les fichiers de config.
• les partitions marchent correctement pour tous les types de règles, au lieu de juste marcher pour les règles de type LABEL.
• Des modificateurs de format ont été ajoutés de manière à ce que NAME soit maintenant dynamique. Voir le fichier udev.config et la page man pour plus de documentation là-dessus (NOTE, si vous avez des règles qui nommaient des partitions dans le passé, elles devront être modifiées pour prendre en compte ces modificateurs pour marcher correctement).
• les sous-répertoires dans /udev sont maintenant gérés correctement.
• la logique d'analyse est meilleure afin de gérer les fichiers défectueux de manière plus saine.
• ajout ("added" dans la VO NDT)
• déplacement des tests dans un répertoire test/ avec le commencement d'une suite de tests de régression.
• beaucoup de petites corrections.

Mille mercis à Kay Sievers, pour cette version, pour avoir implémenté beaucoup des nouvelles fonctionnalités, je l'apprécie vraiment.

Merci aussi à Dan Stekloff, Robert Love, Paul Mundt, Chris Friesen, Arnd Bergmann et Olaf Hering, qui ont tous soumis des patches pour cette version.

Le ChangeLog complet se trouver sur:

La FAQ udev se trouve sur : kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

L'arbre BitKeeper de udev à changé de place en ce moment, vu que kernel.bkbits.net est dans les choux, vous le trouverez sur: bk://linuxusb.bkbits.net/udev

Note, pour compiler en utilisant klibc, voyez le README de klibc dans le répertoire klibc, et lancez la compilation en utilisant 'make -f Makefile.klibc'.

Si quiconque veut un instantané de l'arbre courant, pour ne pas utiliser BitKeeper, ou d'autres raison, c'est toujours disponible, à n'importe quel moment, par simple demande.

Oups, deux changements majeurs que je n'ai pas mentionnée:

• udev.permissions peut maintenant gérer les jokers. La ligne suivante s'appliquera donc à tous les périphériques ttyUSB:
  ttyUSB*:::0666
• J'ai ajouté deux programmes externes au tarball d'udev, dans le répertoire extras/. Ce sont le programme scsi-id de Pat Mansfield, et le programme multipath de Christophe Varoqui. Les deux peuvent marcher comme des programmes de CALLOUT. Je ne pense pas qu'ils compilent correctement dans l'arbre en faisant l'édition de liens sur klibc, mais les patches permettant de corriger cela dans leurs Makefile seront grandement appréciés :)

Merci beaucoup à Pat et Christophe de me laisser inclure leurs programmes dans la version principale de udev, je l'apprécie grandement. Et si il y a d'autres programmes que vous voulez voir intégrés dans udev, faites-le moi savoir.

Je suppose que c'est plus de support de drivers, etc... Les périphériques d'entrée par exemple ne semblent pas avoir de support sysfs pour l'instant, et un support complet de initramfs dans udev, et un setup de udev.permissions pour avoir des permissions générales, etc, pourraient rendre udev plus conseillable pour les masses (pas besoin de maintenir /dev ou le coût initial pour les utilisateurs n'étant pas intéresse par la machinerie interne).

Disons que d'après ce que j'ai vu des demandes, réflexions d'utilisateurs, la configuration initiale et l'apparent 'manque de fonctionnalités' est le plus grand blocage.

mon driver cuecat est prêt a être testé.

http://zinx.xmms.org/cuecat/cuecat-2.6-0.0.2.tar.gz

Il n'utilise pas le même format en sortie que le driver qui est dans les kernels 2.2.x/2.4.x.

Il nécessite actuellement un patch qui change l'ordre dans lequel les drivers serio sont recherchés (le driver le plus récent est recherché en premier maintenant), et ajoute une fonction pour parcourir la liste des ports serio.

J'espère que le patch sera inclus dans le kernel à un moment -- il est disponible séparément sur: http://zinx.xmms.org/cuecat/linux-2.6.0-test9-serio.diff

Le driver a quelques défauts, comme se mettre entre -tous- les périphériques serio capables de supporter un cuecat, et pas seulement ceux qui ont un cuecat (et il n'y a pas de moyen de spécifier quels ports il faut utiliser), mais j'espère trouver un moyen pour corriger cela avant la 0.0.3.

Le nombre majeur est alloué dynamiquement -- si vous n'utilisez pas devfs, regardez dans /proc/devices.

Le nombre mineur pour lire tous les cuecats est 0, et le nombre mineur est leur index [assigné par le driver] plus 1. Les noms recommandés sont:

/dev/cuecat/cuecats
/dev/cuecat/0
/dev/cuecat/1

Et ainsi de suite.

L'input core est plutôt destiné pour de vrais périphériques d'entrée plutôt que pour des périphériques envoyant des données arbitrairement grandes.

Le driver pourrait probablement être simplifié un peu (superficiellement) en envoyant les codes barre comme des évènements (il devra y avoir plusieurs évènements par code barre -- l'input core a des communications très réduites avec l'espace utilisateur), mais ça compliquerait un peu l'espace utilisateur, mais c'est vraiment pas le genre de chose que je verrais dans input core.

De toute façon, si vous voyez un moyen d'envoyer les codes barre comme un seul évènement sans changer l'interface d'input core en espace utilisateur, je suis tout ouïe :)

Pour ceux qui aiment visualiser les données, j'ai fait quelques graphiques comparant divers tests STP. J'utilise la 2.6.0-test9 et 2.4.22/23-rc1 comme points de comparaison. Les données seront mises à jour comme les nouveaux tests tournent sur STP.

Graphiques ici: http://developer.osdl.org/cliffw/reaim/compares/index.html

D'autres tests ici:

http://developer.osdl.org/cliffw/reaim/index.html

Le code test reaim ici: http://sourceforge.net/project/showfiles.php?group_id=71019

Il y a une différence entre la 2.4 (testée en 2.4.23-rc2) et la 2.6 (testée en 2.6.0-pre9) dans la gestion de "int 3" dans un gestionnaire de SIGTRAP.

En 2.4, le gestionnaire est récursivement ré-appelé. En 2.6, la tâche est killée avec les autres tâches qui partagent la même VM (Je ne parle pas de thread groups, j'ai CLONE_PARENT et CLONE_VM mis mais pas CLONE_THREAD).

Je ne suis pas sur de savoir quelle est la réponse correcte, dans le cas ou c'est spécifié. Au contraire, dans FreeBSD 5.1, on m'a dit que le gestionnaire de tâches se termine d'abord avant d'être appelé par la suite. Je suggérerai que ce comportement correspond plus au principe de la moindre surprise, mais je suis peut-être surpris de manière étrange.

Le changement de base est basiquement:

• quelques signaux sont "thread synchrones", c'est à dire que le thread ne peut _pas_ continuer dans les traiter. Basiquement toutes les fautes d'instruction le font, puisque simplement retourner causerait une ré-exécution de l'instruction causant, la même faute.
• la différence entre 2.4.x et 2.6.x est que dans 2.4.x une telle instruction "thread synchrone" serait juste lancé sans être bloquée. Donc même si vous les bloquez, ils arriveront toujours. En 2.6.x, essayer de bloquer un signal thread synchrone provoquera le killage de ce process avec ce signal ("il ne peut pas être livré, il ne peut pas être ignoré, disons-le à l'utilisateur")

La raison du changement est que le comportement 2.4.x finit par par cacher les bogues, et peut causer des situations d'interblocage inattendues dans les programmes multi-threadés. Le comportement 2.6.x veut dire "Vous avez fait quelque chose de fondamentalement faux, _meurs_ maintenant".

Ça marche parce que "int 3" et "into" est ce qu'Intel appelle un "trap" à opposer à un "fault", et comme tel, nous _pourrions_ retarder la gestion du signal et continuer simplement - lorsque l'exception arrive, le CPU a déjà exécute l'instruction, et l'exception retournera _après_ l'instruction.

De toute façon, Linux refusera de faire ça parce que retarder le SIGTRAP est sans objet:

• vous l'aurez au mauvais endroit, rendant le SIGTRAP sans objet
• le mauvais thread pourrait le recevoir si vous le considérez comme un signal normal.

Donc Linux considère "int 3" et "into" comme thread synchrone, même si ils sont trivialement récupérables. Ce qui veut dire que nous avons deux options, et deux options seulement: ignorer que le signal est bloqué, ou juste dire "c'est faux", et le killer.

NOTE NOTE NOTE!! Si vous _voulez_ le comportement 2.4.x d'invocation récursive du signal, vous avez juste à dire au kernel de faire ainsi: utilisez le flag SA_NODEFER dans sigaction() pour dire au kernel que vous ne voulez pas déferrer les signaux récursifs.

En bref, le comportement de la 2.6.x est le bon, 2.4.x était une étrange violation du blocage de signaux, et je considère que le comportement de FreeBSD est simplement bizarre.

Et avec la 2.6.x, si vous _voulez_ des gestionnaires de signaux récursifs, vous pouvez le faire (de manière relativement portable, ajouterais-je - avec le flags SA_NODEFER mis, tout le monde devrait faire la même chose, même *BSD).

J'ai occasionnellement rencontré le cas ou le process init reçoit une faute d'instruction (souvent à cause d'un bogue kernel, en fait), comme un accès à une mauvaise adresse. Sur les plate-formes embarquées, nous avons parfois le cas où init utilise des instructions point flottant, mais le CPU n'a pas de point flottant et le kernel à été compilé sans émulation FP. Dans ces situations, le système semble geler, puisque init déclenche le même signal encore et encore.

Dans ce cas le signal ne devrait pas être bloqué ou ignoré mais il finira ignoré à cause de la règle "init ne reçoit pas de signal qu'il ne veuille pas". Je préférerais voir de signaux thread synchrone killer init s'ils ne sont pas traités, comme ça nous avons au moins un panic avec un message qui dit ce qui s'est mal passé plutôt qu'avoir un système qui tourne en boucle inutilement.

Hmm.. actuellement, le cas particulier pour init est dans le chemin de _livraison_ du signal, ce qui rend difficile de faire quelque chose comme ça, puisque à ce moment là nous ne savons pas qui a envoyé le signal.

Nous pourrions déplacer le cas particulier dans le chemin d'envoi (et puis ne le faire que pour les "signaux externes" et pas de cas particulier init du tout pour les signaux internes).

Hmm.. En regardant le code d'envoi de signal, nous faisons en fait un cas particulier pour init déjà - mais seulement pour le cas "kill -1". Si la condition "pid > 1" était déplacée dans "group_send_sig_info()" à la place, ça suffirait sans doute, je pense.

N'hésitez pas à essayer quelque chose comme ça. Je ne vais pas l'appliquer tout de suite de toute façon ;)

Pourquoi s'embêter avec un init faisant des cas particuliers?

Il semble que la seule chose qu'init ne puisse pas demander au kernel de faire pour lui soit de bloquer SIGSTOP et SIGKILL, et il semble que si vous vous killez (ou stopez?) init, vous devriez obtenir un kernel panic.

Si il y a quelque chose qui vale un cas particulier, alors peut-être ce devrait être qu'init devrait être autorisé à bloquer/intercepter/ignorer SIGSTOP et SIGKILL. Peut-être ceci devrait être une possibilité?

Parce que le kernel dépend de son existence, "init" _est_ littéralement spécial du point de vue du kernel, parce que c'est le "repaire a zombies" (et, ajouterais-je ça serait un bon nom pour un groupe de rock).

Donc, sans init, le kernel n'aurait rien pour rattraper quand un processus parent meurt, et deviendrait très très triste. Historiquement ça oopsait le kernel.

Les sémantiques d'UNIX _requièrent_ que "getppid()" retourne 1 si votre parent meurt, et c'est "current->p_parent->tgid". Nous sommes donc obligés d'avoir un parent de pid 1, et init _est_ donc particulier.

Ouais, nous pourrions avoir d'_autres_ cas particuliers (nous pourrions créer un autre process invisible avec un pid de 1), mais le fait est, _quelques_ cas particuliers sont nécessaires. Ça pourrait vouloir dire "vous ne pouvez pas killer init".

Nous n'avons toujours pas un scheduler HT-sensible, ce qui est dommage puisqu'un truc bizarre comme ça semble devoir devenir de plus en plus commun dans le futur.

J'ai fait un patch sur mes récents trucs NUMA/SMP pour implémenter des classes d'ordonnancement généralisées. Avec cette modification nous pouvons permettre aux architectures de contrôler la politique d'ordonnancement de manière plus fine. L'hyperthreading en devrait pas être un problème, des noeuds hiérarchiques (NUMA) devraient être tout aussi faisables.

Je ne suis pas absolument sur du comment le code spécifique à l'architecture est supposé être géré, je jetterai un coup d'oeil à quelques exemples. Basiquement, les architectures construisent vos propres "classes" d'ordonnancement.

J'ai fait une fonction par défaut pour construire les classes si aucune n'est fournie. Elle les construit afin que les fonctionnalités soient similaire au précèdent comportement local / distant.

Je n'ai pas fait beaucoup de tests, j'attends des commentaires. Ces classes seront-elles suffisantes pour tout le monde.

Une classe est un struct sched_class dans include/linux/sched.h Les classes par défaut sont construites par arch_init_sched_classes dans kernel/sched.c

http://www.kerneltrap.org/~npiggin/w23/. Le patch en question est le suivant: http://www.kerneltrap.org/~npiggin/w23/broken-out/sched-domain.patch

La version 2.6.2 de perfctr, le driver de compteurs de surveillance de performance pour Linux/x86, est disponible à l'endroit habituel: http://www.csd.uu.se/~mikpe/linux/perfctr/

J'ai aussi fait des fichiers .rpm pour les composants en espace utilisateur. Essayez les s'il vous plaît et faites-moi connaître les problèmes que vous rencontrerez.

Version 2.6.2, 2003-11-23

• libperfctr.so est maintenant installé avec un versionnage correct.
• Les structures d'information et de contrôle ABI ont été replies afin d'accepter certaines extensions sans changer la compatibilité binaire avec d'autres applications/libraires. Version ABI incrémentée a "5".
• Le driver vérifie que seuls les P4 <= 2 utilisent IQ_ESCR0/1.
• Support du kernel 2.4.22-1.2115.nptl de Fedora Core 1.
• Correction de la compilation du driver pour AMD64 dans les kernels 2.6.

J'ai sorti la version 007 d'udev, elle est disponible sur: kernel.org/pub/linux/utils/kernel/hotplug/udev-007.tar.gz

udev est une implémentation de devfs en espace utilisateur utilisant sysfs et /sbin/hotplug. Il nécessite un noyau 2.6 pour tourner. Voyez la FAQ udev pour vos questions sur: kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

Note:

Le format de la règle CALLOUT a été changé. Si vous avez un fichier de configuration utilisant cette règle, changez le pour suivre le nouveau format. Voir la page man pour le style correct.

Les changements majeurs depuis la version 006 sont:

• meilleure analyse du fichier udev.permissions
• le propriétaire de chaînes et les noms de groupe dans udev.permissions marcheront si vous compilez avec glibc.
• correction de la règle CALLOUT afin qu'elle ressemble aux autres règles.
• ajout du format char pour la sortie de la règle CALLOUT
• support d'arguments dans l'appel d'exec
• ajout de la possibilité pour le programme CALLOUT d'accepter des modificateurs de format.
• rejet de Makefile.klibc. Pour compiler en utilisant klibc, faites
  make KLIBC=true
• mise à jour de la page man pour documenter les nouveaux changements.

Encore, merci beaucoup à Kay Sievers, pour beaucoup de bons patches dans cette version. Merci aussi à Marco d'Itri et Olaf Hering, qui ont soumis de patches pour cette version.

Je pense qu'avec la possibilité de capturer la sortie de la règle CALLOUT, combinée avec la possibilité de mettre des modificateurs de format dans la chaîne du programme CALLOUT, nous avons tout en place pour émuler la politique de nommage de devfs. Quelqu'un veut le vérifier ou pas?

Le ChangeLog complet peut-être trouvé ci-dessus.

Le développement est fait dans un entrepôt Bitkeeper situé sur: bk://linuxusb.bkbits.net/udev

Des instantanés quotidiens de cet arbre sont sur: http://www.codemonkey.org.uk/projects/bitkeeper/udev/. Merci à Dave Jones pour le gérer.

il y a eu presque un mois entre test9 et test10, avec un flot constant mais diminuant de petits patches. Les changements sont un peu plus gros que ce que j'espérais, mais vu que le patch fait a peine plus de 100Ko compressé pour une mois de travail, je suis quand même heureux.

Il y a toujours quelque chose de bizarre qui semble être déclenché par la préemptibilité, par conséquent, nous suggérons de ne pas activer CONFIG_PREEMPT si vous voulez une plus grande stabilité. D'un autre côté, j'aimerais avoir plus de tests, afin que nous puissions avoir une image plus claire de ce qui se passe - mentionnez explicitement que vous tourniez avec la préemption si vous avez des problèmes.

Une bonne partie des patches -test10 sont des une-ligne (one-liner NDT) qui sont relativement triviaux. J'ai essayé d'être strict en ce qui concerne l'acceptation de patches, donc les changements sont largement des corrections de choses qui peuvent planter la machine, ils sont aussi du type "ne peut rien casser". Mais bon, nous savons tous que théorie et pratique ne n'accordent pas toujours. ;)

J'envisage/espère passer cela à Andrew, et le laisser décider de faire la 2.6.0 finale ou pas. Andrew, soucieux du timing, semble devoir être absent pour quelques semaines, donc, indépendamment du fait que ça devienne solide comme du roc ou pas, nous aurons quelques semaines de tests finaux. Ce qui veut dire que je pourrais finir par faire une test11 si Andrew n'est pas revenu et que nous trouvons quelque chose qui le justifie.

D'ailleurs, je suis heureux de pouvoir dire que les mainteneurs ont fait preuve d'une admirable auto-discipline. Merci à tous ceux qui sont impliqués.

Le changelog donne plus de détails, mais les plus grosses choses là sont divers correctifs réseau, le SCSI compte mieux les références de certaines structures de données (les oops lors du retrait de périphériques de stockage USB que certaines personnes ont vu devraient être corrigés).

[ D'ailleurs, j'ai essayé de trouver un bon nom pour cette version. Mais le fait est que, comme Scott Adams l'a souvent dit, vous ne pouvez pas faire mieux que "weasel" ("belette" NDT) en ce qui concerne la drôlerie. Depuis les series "greased weasel" ("belette graissée") du kernel, je n'ai pas trouvé un aussi bon nom.

Cette version est apellée "stoned beaver" ("castor stone" NDT) (les castors sont _presque_ aussi bons que les belettes, je suis sûr que Scott Adams sera d'accord).

Si vous avez du ressentiment sur ce problème, envoyez vos votes et idées à "feedback@beaver-overlord.com" ("feedback@seigneur-castor.com"), je suis sur que quelqu'un trouvera votre avis fascinant.

Merci par avance. ]

Statistiques de compilation de Linux 2.6 (gcc 3.2.2) Sommaire de Warnings/Erreurs

Kernel         bzImage    bzImage  bzImage  modules  bzImage   modules
             (defconfig)  (allno)  (allyes) (allyes) (allmod) (allmod)
-----------  -----------  -------- -------- -------- -------- ---------
2.6.0-test10   0w/0e       0w/0e   170w/ 0e  12w/0e   3w/0e    209w/0e
2.6.0-test9    0w/0e       0w/0e   174w/ 0e  12w/0e   3w/0e    217w/0e
2.6.0-test8    0w/0e       0w/0e   178w/ 0e  12w/0e   3w/0e    219w/0e
2.6.0-test7    0w/0e       0w/0e   173w/ 1e   8w/0e   3w/0e    226w/0e
2.6.0-test6    0w/0e       1w/0e   188w/ 1e  12w/0e   3w/0e    260w/2e
2.6.0-test5    0w/0e       2w/0e   205w/ 9e  15w/1e   0w/0e    305w/5e
2.6.0-test4    0w/0e       2w/0e   797w/55e  68w/1e   3w/0e   1016w/34e
2.6.0-test3    0w/0e       2w/0e   755w/66e  62w/1e   7w/9e    984w/42e
2.6.0-test2    0w/0e       1w/0e   952w/65e  63w/2e   7w/9e   1201w/43e
2.6.0-test1    0w/0e       1w/0e  1016w/60e  75w/1e   8w/9e   1319w/38e

Page web avec liens pour plus de détails:
http://developer.osdl.org/cherry/compile/
Daily compiles (ia32):
http://developer.osdl.org/cherry/compile/2.6/linus-tree/running.txt
Daily compiles (ia64):
http://developer.osdl.org/cherry/compile/2.6/linus-tree/running64.txt
Derniers changements dans l'arbre bitkeeper de Linus:
http://linux.bkbits.net:8080/linux-2.5

Quelqu'un fait-il pression sur Intel en ce qui concerne les drivers centrino wireless?

Il me semble qu'il aurait pu être écrit 20 fois depuis le temps qu'ils disent être en développement.

Cette citation datant de mars m'embête un peu:

"Le constructeur de semi-conducteurs de Santa Clara, Californie fait tourner des drivers Linux dans ses labos, mais le fait que ces drivers sortent ou pas des labos dépend de la demande des utilisateurs, dit Scott McLaughlin, le porte-parole d'Intel"

Ben, je demande, et ma patience atteint ses limites. Et Amd semble devoir sortir des composants 64bits mobiles bientôt et paraît être bien disposé envers Linux. Suis-je le seul ennuyé là dessus?

Quelqu'un peut-il me rassurer, ou me suggérer les raisons pour lesquelles Intel serait réticent à sortir les drivers?

Non, vous n'êtes pas seul... Bien que je n'ai pas de machine avec Centrino pour le moment, la façon dont Intel se comporte m'empêche d'acheter un portable de remplacement.

Je pense que ce genre de désintérêt pour les drivers Centrino Linux est motivée par le fait que Microsoft a de fortes relations avec Intel et, que vous le vouliez où non, puisque Windows a 90% de la part de marché dans les ordinateurs de bureau, Intel ne voit pas l'intérêt de dépenser quelques centaines de dollars à développer le driver eux-mêmes.

De toute façon, ils pourraient au moins rendre publique leur documentation. Puisque le driver sera, je pense, GPL, ils n'ont pas a craindre la divulgation du fonctionnement internet de Centrino.

Nous sommes heureux d'annoncer un outil basé sur Tinderbox que les développeurs Kernel peuvent utiliser pour déceler les défauts et les régressions dans le kernel Linux et pour faire le lien entre ces défauts et régressions et les changes sets pour le kernel. L'outil est toujours en développement et il permet de faire des tests distribués du kernel utilisant différentes plateformes matérielles et différentes configuration logicielles.

Cet outil est dérivé de l'infrastructure Tinderbox de Mozilla avec beaucoup d'aide des gens d'Async (http://www.async.com.br/) La Linux Kernel Tinderbox est un système client-serveur: les clients font un cycle continuel de vérification, compilation et test du dernier code intégré dans l'entrepôt des sources (sources repository NDT). La serveur fournit une série de pages web, montrant les changements faits a l'arborescence du kernel comme un ensemble de boîtes colorées ordonnées par date et arrangées en colonnes, une par client.

Un prototype de Linux Kernel Tinderbox est visible sur:

http://tinderbox.osdl.org/showbuilds.pl?tree=linux2.5-bk

La documentation du projet est située sur:

http://www.osdl.org/cgi-bin/osdl_development_wiki.pl?Linux_Kernel_Tinderbox

Le projet supportera toute architecture, capable de faire tourner Linux. Notre but est que les possesseurs des diverses plate-formes matérielles puissent fournir des clients Tinderbox.

Un client kernel tinderbox basique est sur: http://developer.osdl.org/cliffw/kernel_tinderclient.tar.gz

Le support est fourni via une mailing list: Kernel-tinderbox@lists.osdl.org http://lists.osdl.org/mailman/listinfo/kernel-tinderbox

Faites nous savoir si vous pouvez fournir une machine non-Intel.

Attaché à ce mail, vous trouverez un patch pour un nouveau sous-driver ataraid, "iswraid" (Intel Software RAID) pour la série de Kernels 2.4. Le patch est fait contre le Kernel 2.4.22.

Le driver (ainsi que le driver ata_piix) peut-être utilisé avec le chipset ICH5R d'Intel. Vous aurez besoin de l'Option ROM pour configurer la RAID. Ce driver diffère légèrement d'autres sous-drivers ataraid en ce qu'il opère sur des périphériques block SCSI plutôt que ATA/IDE. "iswraid" dépend du driver "ata_piix" pour détecter et charger les disques SATA connectés au ICH5R. Notez que le driver est toujours considéré comme expérimental, vous l'utilisez à vos risques et périls.

Merci à Arjan van de Ven (ataraid), Jeff Garzik (ata_piix) et James Bottomley (scsi) pour avoir patiemment répondu à mes questions.

FYI: patch ata_piix pour 2.4.22: ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/