Kernel Traffic #241 For 16 Nov 2003

There were 396 different contributors. 175 posted more than once. 160 posted last week too.

4 Nov 2003 - 7 Nov 2003 (21 posts) Subject: "[ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6)."

Une nouvelle version du driver de la famille 8.x pour les kernels Linux 2.6.x a été téléchargée sur SourceForge:

http://sourceforge.net/projects/linux-qla2xxx/

Les changements depuis la dernière (8.00.00b5) incluent:

Gestion RSCN intelligent.
Allocations slab cache pour les SRBs du driver.
Support d'un grand nombre de cibles.
Début de la révision des fonctionnalités de logging.

Reportez vous aux notes pour de plus amples détails sur les changements dans la 8.00.00b6.

A partir de cette bêta, les distributions du driver ne se feront plus qu'au format tarball source. Ce n'est pas la peine de construire un add-on pour l'arbre du kernel, étant donnée la variabilité des périodes entre deux versions du driver. Un résultat similaire à un add-on aux sources du kernel peut être obtenu par:

        sources du driver dans /tmp/qla8_b6

        # cd <sources du kernel>
        # patch -p1 < /tmp/qla8_b6/add_to_kernel.diff
        # mkdir drivers/scsi/qla2xxx
        # cp /tmp/qla8_b6/* drivers/scsi/qla2xxx
        # make ...

La fonctionnalité failover est présente dans la distribution. A ce moment, je n'envisage pas de changement de politique concernant sa présence dans la famille des drivers 8.x. La prochaine version bêta de 8.x sera synchronisée avec la dernière bêta 6.x (6.07.xx) en ce qui concerne le failover.

Christoph Hellwig remarqua, "votre API ioctl est de pire ne pire. Vous vous attendez pas à ce que cette énorme pile d'ioctls tous marqués _BAD soit inclue dans le kernel, n'est-ce pas? Par ailleurs, avoir des valeurs ioctl différentes pour des plateformes différentes n'est pas possible avec Linux." Andrew reconnût le problème, et dit qu'il ne pensait pas que le code ioctl soit inclus dans le kernel. Mais il expliqua, "des logiciels (SMS 3.0) ont été construits sur cette interface IOCTL. Nous avons découvert ce problème lorsque nous avons commencé à regarder d'autres plateformes que x86 (ppc64)." Concernant les différentes valeurs ioctl pour différentes architectures, Andrew ajouta, "La meilleure (juste) correction, serait de déplacer ce changement d'interface vers l'appelant des IOCTLs où ils géreront les différences, le driver se débarrasserait enfin de ce problème. C'est le consensus ici. La conversion _BAD n'a été faite que pour que le driver compile." Arjan de Ven pensa que la plupart ou la totalité du plat de spaghettis ioctl pouvait être supprimée, en utilisant, à la place, les APIs déjà définies autre part dans le kernel. Mais Andrew ne voyait pas comment cela pouvait être fait avec les API existantes. Ses ioctls, a-t-il dit, font beaucoup plus que les fonctions génériques définies autre part; il n'y eut plus de discussion là dessus.

Autre part, Mike Anderson demanda à Andrew, " Pouvez vous expliquer pourquoi, à partir de la b5, le clustering fut désactivé? "

Ce changement faisait partie d'un patch performance relativement grand qui était originellement destiné à la famille des drivers 6.x. Il y a deux principales raisons pour désactiver le support du clustering:

Étant donné la capacité de l'ISP à transférer un grand nombre de données par la DMA à partir et vers des segments de données (à travers des IOCBs de type command/continuation), nous nous sommes posés des questions concernant les bénéfices du clustering étant donné la surcharge due à la couche médiane devant grouper les requêtes.
Du à l'incapacité de l'ISP de gérer des segments de données qui dépassent les frontières d'une page 32 bits, et la surcharge de travail pour prévenir de tel cas (comparez les codes 6.x et 8.x et vous verrez ce que je veux dire), en désactivant le clustering nous garantissons qu'un seul élément SG ne dépassera jamais la frontière de 4Go.

Maintenant, dans le 2.6, il y a des changements significatifs. Par exemple, avec la réécriture de la couche block et la possibilité de limiter les frontières de segments d'une requête block queue avec l'appel blk_queue_segment_boundary(), le LLDD n'a pas besoin de se préoccuper avec du code pour gérer le dépassement de 4Go.

Donc nous profitons de ce processus de groupage dans la couche block. Je suis ouvert au réexamen du clustering à condition d'avoir de solides arguments montrant une augmentation de la performance et/ou un assourdissant 'ouais, active le!' des connaisseurs de la couche block.

Jens Axboe intervint à ce moment là, disant que le premier point d'Andrew était correct, et que le second ne l'était pas: Jens expliqua que Linux n'autoriserait jamais le dépassement d'une frontière 4Go, il n'y avait donc pas besoin de s'en protéger. La conclusion de Jens était que bien que le bénéfice du clustering puisse s'avérer minime, "Avec le 2.6, le clustering est gratuit, ça serait bête de ne pas l'activer." Andrew accepta la correction, et dit qu'il réactiverait le clustering dans le prochaine version du driver. Ils discutèrent sur quelques détails périphériques, et le fil s'éteint.

Bradley Bozarth demanda qui maintenait actuellement CramFS. Il dit, "Daniel Quinlan le maintenait à l'origine, maintenant, il est orphelin. Le patch endian qui implémentait le comportement correct par rapport aux docs (qui stipulait de toujours utiliser le codage little endian), a été rejeté. Nous avons maintenu ce patch sur notre kernel, mais il devrait vraiment être intégré - je ne veux cependant pas passer tout mon temps dessus comme la dernière fois pour qu'il soit encore rejeté - est-ce quelqu'un pense maintenir cramfs? Quelles sont les chances du correctif endian d'être intégré si je le soumets de nouveau? (même si le précédent mainteneur n'y réussit pas). Je pourrais maintenir cramfs si on le désire - il n'a pas vraiment changé depuis un moment excepté quelques changements de haut niveau sur les fs." H. Peter Anvin répliqua, "Je pense que Al Viro à fait un réécriture. Vous devriez voir avec lui."

3. Sortie Du Test De Régression Du Modèle Driver Pour La Plateforme De Test d'OSDL

Un test de régression du modèle de driver à été ajouté à la Scalable Test Platform d'OSDL.

http://www.osdl.org/lab_activities/kernel_testing/stp/

Le test est une famille de scripts et de modules compilés en dehors du kernel afin d'aider à tester le modèle driver. Un nombre extensible de bus, classes de drivers, classes de périphériques et de périphériques sont chargés, déchargés en parallèle dans une tentative de pousser le modèle driver à ses derniers retranchements. Le temps d'exécution est mesuré et donné en sortie lors d'une exécution réussie du test. Un des buts du test est de détecter les baisses (ou augmentations) de performance sur les kernels anciens ou nouveaux.

Carl-Daniel Hailfinger annonça de la part de lui-même, Manfred Spraul, et Andrew de Quincey:

Ci-joint se trouve forcedeth: un nouveau driver pour l'interface ethernet du chipset nForce de NVIDIA, licencié sous GPL.

Le driver a été développé sans assistance de NVIDIA, c'est le résultat d'un développement en salle blanche:

Carl-Daniel et Andrew on fait du reverse engineering sur le driver nvnet et on écrit une spécification, Manfred à écrit le driver à partir de la spec. Puisque le driver est disponible et marche depuis un moment maintenant, Carl-Daniel a développé une couche de compatibilité pour le faire compiler sous 2.4.

Cette version est destinée aux développeurs, c'est d'une qualité alpha: le trafic réseau normal devrait marcher, bien que lent du à une gestion partielle des interruptions. Il marche sur deux systèmes nForce 2, nForce et nForce 3 ne sont pas testés.

Essayez-le, mais ne vous plaignez pas si quelque chose ne marche pas. Notez que le driver genère pas mal de messages de debug.

Envoyez les comptes-rendus sur linux-kernel ou sur netdev@oss.sgi.com et Manfred s'en chargera.

Vous pouvez aussi télécharger des patches pour Linux 2.4.x et 2.6.x sur http://www.hailfinger.org/carldani/linux/patches/forcedeth/

Bon! J'ai vu que Manfred avait posté ce driver pour 2.6.x aussi. Je suis content que quelqu'un ait ENFIN réussi à supporter ce chipset sous Linux.

De toute façon, bien qu'il soit de qualité alpha, ce driver marche là où le kernel ne marche pas. Donc, après que j'aie révisé le driver, je le mergerais aussi vite que possible. Ça aide les utilisateurs après tout.

Autre part, Christoph Hellwig suggéra d'utiliser un nom plus proche du matériel comme 'nforce_eth'. Krzysztof Halasa en fut d'accord, mais Jeff dit qu'il y avait des problèmes de marque enregistrée à considérer dans ce cas la, et cela "je préférerais l'éviter complètement, plutôt qu'avoir à chercher des avocats et avoir une réponse définitive." Carl-Daniel dit aussi, " Nous (Manfred, Andrew et moi) avons débattu sur le nom un bon moment et forcedeth, forced et forceeth furent les finalistes. forcedeth n'était pas seulement un nom descriptif, mais aussi un jeu de mots malin. Il gagna donc le concours."

Marcelo Tosatti annonça la Linux 2.4.23-rc1 et dit, " Il contient des correctifs pour les drivers réseau (b44, tg3, 8139cp), diverses corrections de bogues x86-64, entre autres." Willy Tarreau remarqua, "De manière intéressante, tg3 qui avait une légère tendance à geler sur 2.4.22, maintenant les différences de duplex semblent solide. J'ai même pu faire une négociation et des différences de duplex sous de grosses charges (pktgen) sans même un warning dans les logs. "

11 Nov 2003 (1 post) Subject: "Announce: kdb v4.3 is available for kernel 2.4.23-rc1"

ftp://oss.sgi.com/projects/kdb/download/v4.3/

Les versions actuelles sont kdb-v4.3-2.4.23-rc1-common-1.bz2, kdb-v4.3-2.4.23-rc1-i386-1.bz2. D'autres plateformes vont suivre au fur et a mesure qu'elles sont portées sur 2.4.23-rc1. Ceci est juste une version de maintenance pour se synchroniser avec la kernel 2.4.23-rc1.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

Kernel Traffic #241 For 16 Nov 2003

By Zack Brown

Translated By: Frederik Deweerdt

1.	4 Nov 2003 - 7 Nov 2003	(21 posts)	Mise A Jour Du Driver QLogic qla2xxx Pour Le 2.6
2.	7 Nov 2003 - 9 Nov 2003	(2 posts)	Maintenance De CramFS
3.	7 Nov 2003	(1 post)	Sortie Du Test De Régression Du Modèle Driver Pour La Plateforme De Test d'OSDL
4.	7 Nov 2003 - 9 Nov 2003	(15 posts)	Nouveau Driver Pour L'Interface Ethernet Du Chipset nForce De NVIDIA
5.	10 Nov 2003 - 12 Nov 2003	(15 posts)	Sortie De Linux 2.4.23-rc1
6.	11 Nov 2003	(1 post)	Sortie De kdb 4.3 Pour Le Kernel 2.4.23-rc1