Kernel Traffic #246 For 26 Dec 2003

J'ai entendu pas mal de gens évoquer le fait que bien que Linux soit sous licence GNU GPL, ce code est licencé avec une clause spéciale disant que les modules binaires n'ont pas a être sous GPL. Il y a de manière évidente des entreprises qui distribuent des modules binaires (qui ne sont pas supportés par les développeurs du kernel bien sûr), ces gens là y croient. J'étais cependant curieux sur la forme de cette clause spéciale, je l'ai donc recherchée, mais sans la trouver. J'ai téléchargé le code source du kernel 2.6-test1 et regardé le fichier COPYING, sans trouver de rapport (simplement la note de Linus en haut disant que les programmes utilisateurs ne sont pas couverts par la GPL). J'ai aussi regardé le fichier README et rien n'était mentionné là non plus, du moins je n'ai rien trouvé.

Cette clause spéciale existe-t-elle ou pas? Si non, comment peut-on avoir des modules binaires sous Linux sans que le source soit disponible sous les termes de la licence GNU GPL?

Finalement, j'ai remarqué que les quelques codes source de modules auxquels j'ai jeté un coup d'oeil pour voir si la clause spéciale y était mentionnée, n'avaient pas le préambule GNU GPL habituel dans chaque fichier. AMHA tous les fichiers devraient avoir ce texte, sinon ils ne sont pas sous GPL (tout comme avoir un archive ZIP/tar avec un fichier COPYING ne met pas un fichier sous GNU GPL). Vu tout les problèmes légaux avec SCO, je me suis dit que chaque fichier aurait cette en-tête. En fait certains fichiers que j'ai examiné n'avaient même pas de notice de copyright!!

Il n'existe pas de clause spéciale.

Il existe une clarification disant que les programmes en espace utilisateur utilisant les interfaces standard d'appels systèmes ne sont pas considéré comme des travaux dérivés, mais ceci n'a rien de "spécial" - c'est juste la description de ce qui est considéré comme la frontière des "travaux dérivés". Les programmes utilisateur ne sont _clairement_ pas des travaux dérivés du kernel, et comme tels la licence du kernel importe peu.

En fait, en ce qui concerne les modules, le problème GPL est le même. Le kernel _est_ GPL. Pas de si, mais ou peut-être là-dessus. Par conséquent, tout travail dérivé doit être GPL. C'est aussi simple que cela.

Ceci dit, le problème du "travail dérivé" dans les lois du copyright est la seule chose qui puisse nous conduire en zone grise. Il y a des zones qui ne sont pas grises du tout: l'espace utilisateur n'est clairement pas un travail dérivé, alors que les patches kernel _sont_ clairement des travaux dérivés.

Mais un zone grise est quelque chose comme un driver qui était écrit pour un autre système d'exploitation (donc clairement pas un travail dérivé de Linux). A quel moment exactement, ceci devient-il un travail dérivé du kernel (et donc devient GPL)?

ÇA c'est la zone grise, et c'est la zone où je considère personnellement que certains modules pourraient ne pas être considérés comme des travaux dérivés simplement parce qu'ils ne sont pas conçus pour Linux et ne s'appuient pas sur un comportement particulier de Linux.

En somme:

• tout ce qui a été écrit avec Linux dans la tête (même si ça marche _aussi_ sur d'autres systèmes d'exploitation) est clairement en partie un travail dérivé.
• tout ce qui connaît et utilise les comportement interne de Linux est clairement un travail dérivé. Si vous devez toucher du code central, vous êtes dérivé, pas de doute là-dessus.

Historiquement, il y a eu des choses comme le module Andrew filesystem original: un système de fichiers standard qui n'était pas vraiment écrit pour Linux au départ, et qui implémente simplement un système de fichiers UNIX. Est-ce dérivé simplement parce que ça a été porté sous Linux qui avait un interface VFS similaire à celle des autres UNIXes? Personnellement, je ne pourrais pas prendre cette décision. Ce l'était peut-être ou peut-être pas mais, c'était clairement en zone grise.

Personnellement, je pense que ce cas n'était pas du travail dérivé, et c'est ce que je dirais aux gars d'AFS.

Cela veut-il dire que tout module kernel est automatiquement pas un travail dérivé. BIEN SÛR QUE NON! Ça n'a rien a voir avec les modules en tant que tels, sauf que les non-modules sont clairement des travaux dérivés (si c'est si central dans le kernel que vous ne pouvez pas le charger comme un module, ce sont clairement des travaux dérivés juste parce qu'ils sont très intimes - et parce que la GPL mentionne l'édition de liens expressément).

Donc être un module n'est pas la marque d'un travail non-dérivé. C'est juste la marque que _peut-être_ il pourrait y avoir des arguments tendant à démontrer que ce n'est pas dérivé.

Note: historiquement, Les interfaces des modules kernel de Linux étaient relativement faibles, et n'exportaient que quelques dizaines de points d'entrées, et ne permettaient pratiquement que des drivers de périphérique block ou caractère avec des interfaces standard, et des systèmes de fichiers changeables.

Donc historiquement, le fait de ne pas pouvoir charger un module n'utilisant rien que ces interfaces standard était un argument fort démontrant qu'on n'était pas étroitement couplé avec le kernel.

Ça a changé, et les interfaces de modules kernel que nous avons aujourd'hui sont bien plus larges que ce quelles étaient en '95 où autres. De nos jours, les modules sont utilisés pour tout, y compris des trucs "internes au kernel" et par conséquent la "barrière implicite" historique entre les modules et le kernel est devenue plus ténue, il n'y a donc pas d'argument fort démontrant une indépendance du travail venant du fait que vous êtes simplement un module.

De manière similaire, il y avait des arguments bien plus forts pour les choses comme AFS et les drivers binaires (oubliés depuis longtemps maintenant) pour avoir été développés de manière indépendante à Linux: ils avaient été littéralement développés avec que Linux n'existe, par des gens qui ne connaissaient pas Linux. Ce qui tend a démontrer qu'ils n'étaient pas dérivés.

A l'opposé, ces jours-ci il serait difficile de dire qu'un nouveau driver ou système de fichiers ait été développé sans penser à Linux. Je pense que les gens de NVidia peut honnêtement dire que dans le code qu'ils ont porté il n'y avait _pas_ d'origine Linux. Mais franchement, je serais plus dubitatif sur certains projets là dehors..

C'est surtout pour indiquer quels cas sont clairement tranchés et où les gens ne devraient même pas se poser la question. Ça ne fait pas disparaître la zone grise, mais ça la limite un peu ("si vous avez besoin de cet export, vous faîtes clairement quelque chose qui nécessite la GPL").

Note: puisque le kernel lui-même est sous GPL, tout le monde peut modifier la ligne EXPORT_SYMBOL_GPL(), et retirer la partie _GPL. Ça n'irait pas à l'encontre de la licence en soi. Mais ça ne rend pas un module qui nécessite ce symbole moins dépendant de la GPL - précisément parce que la chose est un indice plus qu'autre chose.

un "module binaire du kernel linux" est un travail dérivé du kernel, et doit par conséquent venir avec des sources.

Mais si vous utilisez ces mêmes sources (et que _vous_ les avez écrites) elles ne contiennent pas de code Linux, elles ne sont _clairement_ pas dérivées de Linux, et vous pouvez licencier et utiliser votre propre code de la façon que vous voulez.

Vous ne pouvez pas faire un module binaire pour Linux et dire que le module n'est pas dérivé du kernel. Parce que c'est généralement le cas - le module binaire ne fait pas qu'inclure les fichiers en-tête, mais plus grave, ce n'est _pas_ un travail indépendant. Donc même si vous faîtes vos propres prototypes et que vous évitiez les en-têtes du kernel, vous seriez _toujours_ connecté et dépendant du kernel.

Et notez que je ne parle que du binaire. Le code source reste toujours votre propriété, vous avez le droit de le distribuer séparément de la façon dont vous l'entendez. Vous l'avez écrit, vous possédez donc les copyrights dessus, et c'est un travail indépendant.

Mais quand vous le distribuez d'une façon qui est clairement liée au kernel GPL (et un module binaire est un de ces liens clairs - un "patch" pour le compiler ou le lier d'une certaine façon au kernel est aussi un tel lien, même si vous en distribuez le source sous un autre licence), vous n'êtes PAR DÉFINITION plus un travail indépendant.

(Mais parce que je ne suis pas une personne qui voit les choses soit en noir ou en blanc, je me réserve le droit de prendre un décision pondérée sur tout cas particulier. J'ai plusieurs fois senti qu'un auteur de module avait un argument tout a fait valide pour lequel la "présomption de culpabilité" d'être dérivé n'était pas justifiée. C'est pourquoi des choses comme le modules AFS on été acceptées - sans être aimées -).

C'est pourquoi les arguments de SCO sont spécieux. IBM a écrit leur code, garde leurs copyrights sur leur code ET ILS ONT AGGRAVÉ LE LIEN AVEC LE CODE DE SCO (et, probablement, les liens n'existaient même pas, puisque des choses comme JFS ont été écrites aussi pour OS/2, et le port Linux était basé sur celui-ci - mais c'est une discussion différente et indépendante de ce que je disais).

Voir la définition de "dérivé" dans USC 17.1.101:

Un "travail dérivé" est un travail basé sur un ou plusieurs travaux préexistants, comme une traduction, un arrangement musical, une théâtralisation, en fiction, une version de déssin animés, un enregistrement sonore, une reproduction artistique, abrégé, résumé, ou tout autre forme dans laquelle le travail pourrait être réfait, transformé ou adapté. Un travail consistant en révisions éditoriales, annotations, élaboration, ou tout autre modification qui, en soi, représentent un travail d'auteur original, est un "travail dérivé".

Et un module binaire est une "élaboration" sur le kernel. Désolé, mais c'est comme ÇA.

En bref: votre code est à vous. Le code que vous écrivez est automatiquement copyrighté par VOUS, et comme tel vous avez le droit de le licencier, et de l'utiliser comme vous le voulez (bon, modulo _d'autres_ lois, bien sur - aux US, votre licence ne peut pas être raciste, par exemple, mais ça n'a rien avec les lois du copyright, et tomberait dans un tout autre cadre légal).

Mais lorsque vous utilisez ce code pour créer une "élaboration" sur le kernel, ça devient un travail dérivé, et vous ne pouvez pas le distribuer sans l'accompagner par la GPL. Un module binaire est dans ce cas, et même un patch source est _aussi_ dans ce cas. Les lignes qui sont ajoutées sont vôtres, mais lorsque vous les distribuez comme une élaboration, vous devez vous conformer aux restrictions sur les travaux dérivés.

Ou vous devriez avoir de forts arguments à opposer. Ce que j'ai toujours dit par ailleurs.

personnellement, j'ai ma propre idée sur ce que sont les "travaux dérivés", et j'utilise cette idée pour décider de me plaindre ou d'aller plus loin.

Et donc _je_ pense personnellement que les modules binaires sont OK, et vous avez lu pourquoi. Cela veut dire que _je_ ne porterai pas plainte pour ces utilisations, puisque mon opinion est qu'il n'y a pas de violation de copyright DANS CES CAS puisque je ne les considère pas comme dérivés.

Mes opinions sont publiques, et les choses que je dis en public ont un poids légal puisque ça limite ce que je peux faire (si je dis en public que je pense que quelque chose est ok, j'aurais du mal à dire que ce n'est _pas_ ok en face d'un juge - c'est ce que veut dire "estoppel").

Mais la chose est que, mes opinions publiques n'engagent personne d'autre. Donc si Alan Cox, ou _tout_ autre détenteur de copyright sur le kernel, conteste mon point de vue (et croyez-moi, certains le font), ils ont le droit de se plaindre. Leur plainte sera affaiblie par ma position (simplement parce que l'accusé pourrait parler de mon opinion et que le juge pourrait être influencé par cela).

Et franchement, la raison la plus importante pour ne pas me plaindre a souvent été que je suis paresseux, et dans plusieurs cas où des gens utilisant du travail GPL de mauvaise manière, j'ai été prêt a me joindre à une poursuite que quelqu'un d'autre initierait. Pour l'instant les gens ont tendance a attendre.

Je voudrais indiquer que je suis bien plus souple que certains là-dessus, - j'ai clairement indiqué que les modules binaires _sont_ ok, mais le fardeau de la preuve démontrant que c'est ok reste sur les épaules de l'entreprise qui les fait.

Comprenez-moi bien: je suis bien connu pour permettre a des modules binaires comme AFS et nVidia d'exister, là ou certains pensent que ça ne devrait pas être autorisé.

Mais le vrai problème ici (et dans la ligne sujet de toute cette discussion) concerne la "clause d'exception".

Il n'y en a pas. Et je dis juste qu'il n'y a pas de façon de rendre un module binaire "automatiquement ok". Il _pourrait_ y en avoir, mais sur une base totalement différente de "c'est un module".

C'est pourquoi je voudrais clarifier le fait que la "modulation" (qui n'est pas un mot mais qui devrait en être un) n'est pas ce qui compte. Il y a toujours un fort "lien" a un kernel particulier dans un module binaire, et le fait de lancer l'éditeur de liens n'est pas ce qui détermine si une oeuvre est un travail dérivé ou pas.

En bref, vous ne devriez pas voir mes arguments comme une façon de dire "tous les modules sont des travaux dérivés". Je ne dis pas cela du tout, puisque j'_autorise_ les modules binaires et je ne dis pas qu'ils violent les lois du copyright.

Je ne plaide pas pour une notion très large du travail dérivé: je plaide contre l'étroite notion qu'un module devrait être automatiquement _non_ dérivé.

C'est pourquoi j'ai dit au moins cinquante fois qu'un module kernel doit être considéré comme étant "dérivé par défaut". La non-dérivation vient de choses qui n'ont rien a voir avec le fait que ce soit ou non un module.

Quel est le sentiment général sur devfs aujourd'hui? Je me rappelle que Christoph et d'autres ont fait de sales remarques dessus il y a 6 mois, mais j'ai remarqué que Christoph avait fait de l'élagage et du nettoyage par la suite.

Est-ce 'bon' aujourd'hui?

D'après ce que j'ai compris, udev prend les informations exportées par sysfs sur les périphériques existants dans le système, et crée des noeuds périphériques dans /dev (qui peut être un montage ramfs ou faire partir d'un système de fichiers permanent, udev ne s'en soucie pas). Je suppose que ça parcourt sysfs pour voir ce que le système a vu au démarrage (une variante de "find /sys -name devide", peut-être) puis reçoit les évènements hotplug lorsque de nouveaux périphériques sont ajoutés par la suite. En gros, c'est cool, marche bien avec hotplug, et petit, et simple. _et_ le résultat est un répertoire /dev familier, les applications utilisateur n'ont donc pas a être "devfs aware" (ce qui était un mauvais signe depuis le premier jour à mon avis).

Malheureusement, sysfs n'exporte pas les informations concernant les noeuds de périphériques pour tout ce qu'il y a dans le système pour l'instant. (Il n'y a rien dans /sys/cdev, /sys/devices/legacy, ou /sys/devices/system par exemple). Il y a des patches en attente, mais ce ne sont pas des correction de bogues, donc Linus ne les prend pas avant le 2.6.0, et nous devrons attendre la 2.6.0 pour que le développement sur ce système s'achève.

Probablement autour de la 2.6.4 ou de la 2.6.6, sysfs aura toutes les exportations de périphériques qu'udev nécessite. (Ou au moins toutes celles dont les gens se sont plaints) Jusqu'à maintenant ... chais pas. Peut-être pouvez vous utiliser un /dev sur un système de fichiers persistant ou ferez des mknod pour les périphériques dont vous avez besoin?)

Ceci est la première version d'une nouvelle arborescence kernel nommée '-tiny' (quelqu'un a déjà pris -mm). Le but de cette arborescence est de regrouper les patches pour réduire l'encombrement disque et mémoire du kernel ainsi que les outils permettant de travailler sur les petits systèmes, une zone que le courant principal de Linux a évité depuis que Linus a un vrai job. Les objectifs visés sont les choses comme les systèmes embarqués, les petits ou anciens PCs, et les portables.

Pour le lancement, j'ai mis une cinquantaine de patches qui enlèvent diverses parties du kernel, configurables pour la plupart, et un bon nombre qui pourraient être ok pour la version principale. Toutes les options de config sont mises sous CONFIG_EMBEDDED et pas mal de petites bidouilles sont sous un ensemble d'options de config appelé CONFIG_CORE_SMALL, CONFIG_NET_SMALL, et CONFIG_CONSOLE_SMALL.

Choses sympa que j'ai inclus:

• Compilation avec -Os
• piles de process de 4k (via -wli)
• suppression configurable de printk, BUG et panic()
• HZ configurable
• support configurable pour vm86, core dumps, kcore, sysfs, aio, etc.
• un système de compta sympa pour kmalloc via /proc/kmalloc
• comptabilité de l'usage de bootmem
• un système pour comptabiliser les instantiations inline
• mes patches netpoll/netconsole
• mes correctifs drivers/char/random

Quelques éléments de ma liste todo:

• emprunter kgdb de -mm
• mon kgdb-over-ethernet basé sur netpoll
• mémoire kernel paginable pour un sous-ensemble du kernel
• fonctionnalité vt réduites pour les petits systèmes gui
• code de management lookup/hash

Quelle est la taille de -tiny? C'est difficile a quantifier puisque c'est tout configurable et quelques fonctionnalités sont plus encombrantes que d'autres, ma configuration de test actuelle a une pile IPv4 complète ainsi que d'autres fonctionnalités et bootera confortablement sur une machine x86 avec 4Mo et laisser 2Mo en free+buffers+cache.

Rapports de bogues, suggestions, et les soumissions de patches sont les bienvenus.

Le patch, contre 2.6.0-test11, peut-être trouvé sur:

http://selenic.com/tiny/

OK, J'ai mis en ligne la version html pour votre plaisir: le diff est important et difficile à lire.

http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/

J'ai prototypé une extension de BitKeeper qui fournit des tarballs et des patches. L'idée est de rendre possible l'accès à toutes les arborescences de bkbits.net avec un client libre (inclus ci-dessous sous la forme d'un prototype).

Le système est simple, ça fournit juste un moyen de recevoir les sources les plus récents comme un tarball et les mises à jours suivantes comme un patch. Il n'y a pas d'empêchements à générer des diffs, éditer les fichiers, intégrer, etc. Tout ceci est quelque chose que vous pouvez écrire si vous voulez, en utilisant des outils standard.

Avant de déployer cela, je veux savoir si ça va (finalement) mettre un terme à toutes les plaintes sur le fait que BK n'est pas un logiciel open source, disponible sur toutes les plate-formes, etc. Vous devez comprendre que ceci est tout ce que vous recevrez, nous n'allons pas étendre cela pour que vous puissiez suivre les sources les plus récentes de manière fiable. Pas de diffs. Rien d'autre que la version la plus récente. Pas d'historique.

Si vous voulez autre chose que la version la plus récente, vos choix sont soit d'utiliser BitKeeper lui-même, ou si vous voulez une des branches principales du kernel Linux, les exports BK2CVS. Ceci n'est pas une passerelle, c'est un moyen pour les développeurs d'obtenir la dernière version avec un client libre. Ce n'est pas un moyen de convertir les repos BK vers $SCM.

Si la réponse est majoritairement positive, j'enverrais ceci sur le serveur bkbits.net et peut-être sur le produit BK lui-même.

Licencié sous la NWL - No Whining License (NDT: License sans plainte).

Vous pouvez utiliser ceci, modifier ceci, redistribuer ceci, si vous acceptez:

• de ne pas vous plaindre de ce produit ou d'autres produits de BitMover, Inc.
• qu'il n'y ait pas de garantie d'aucune sorte.
• de conserver ce copyright dans sont intégralité.

C'est accessible via libusb de nos jours en ouvrant /prob/bus/usb/*/*

Emerge (apt-get, etc, suivant votre distrib) quelque chose comme gphoto2 qui devrait inclure libusb dans ses dépendances et configurer hotplug.

Une nouvelle édition des mises à jour du driver réseau.

Résumé des changements:

• annulation des patches de nettoyage skfddi. plus de changements skfddi dans ce patchkit. Stephen Hemminger a un patch skfddi bien meilleur qui a rendu obsolètes les changements skfddi déjà intègres.
• correction de fuites mémoire atmel wireless SKB
• correction deadlock 3c574_cs
• travail d'Al rendant l'allocation de net_device dynamique et saine (incluant une allocation privée const-offset rapide pour les drivers)
• mise à jour sk98lin du fabriquant
• mise à jour TG3 de DaveM
• nouveau pc200syn driver WAN du mainteneur WAN Krzysztof Halasa
• correctifs r8169 de Francois Romieu

Résumé du patchkit:

• nouveau driver e100 (réécrit)
• nouveau driver nVidia nForce NIC
• nouveau driver pc200syn WAN
• correctifs de bogue tg3
• correctifs majeurs de bogue r8169
• mises à jour / correctifs mineurs e1000
• mises à jour / correctifs du fabriquant sk98lin
• divers correctifs
• support NAPI 8139too
• support NAPI tulip
• support netconsole / netdump
• travail sur l'allocation net_device et comptage de références

Patch:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-test11-bk11-netdrvr-exp1.patch.bz2

Changelog complet:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-test11-bk11-netdrvr-exp1.log

repo BK:
bk://gkernel.bkbits.net/net-drivers-2.5-exp

"Le castor a fini la désintox"
- Anon

Ceci ne devrait être une surprise pour personne sur la liste, puisque nous avons avancé vers lui depuis un moment, et les dernieres semaines je n'ai pas accepté de patches mis à par les une-ligne évidents.

Bien, le 2.6.0 est sorti, et le patch sur -test11 fait un maigre 11Ko. Ce n'est pas le patch totalemment vide que j'avais esperé, mais, d'après les bogues sur lesquels j'ai travaillé, les choses me semblent pas mal.

Pour vous donner un example, un des bogues les plus sales que nous avons traqué les 5 dernières semaines était un bogue qui ne se produisait de manière récurrente sur un système à 16 ou 32 processeurs, et seulement avec des disques défectueux. Mettre de bons disques faisait disparaître le problème. Compiler le kernel avec un autre kernel faisait disparaître le problème aussi.

Ca s'avéra êter un bogue subtil ayant à voir avec l'ordonnancement SMP et l'allocation de la pile, mille mercis à Ram Pai pour recueuillir toute l'information qui à permis de le corriger. Le correctif faisait une ligne et un gros commentaire - mais ce que je veux dire c'est que la qualité des bogues a été relativement haute ces derniers temps, et nous sommes en bonne forme.

Andrew a écrit quelques avertissements et indications pour informer sur les changements 2.4.x vs. 2.6.x, je lui laisser les poster. Quelques problèmes connus ne furent pas considerés comme critiques et un grand nombre ont des correctifs en attente sur la file -mm. Generalement ils n'avaient pas été suffisament vérifés, et je voulais les mettre a part pour avoir une bonne version 2.6.0.

NOTE! Je continuerai a m'occuper de l'arborescence BK 2.6 jusqu'à ce que nous soyons proches du temps où nous séparerons 2.7.x, parce que Andrew et moi sommes habitués à nos outils respectifs. Mais Andrew est le mainteneur de l'arborescence stable, donc tout devrait être approuvé par lui à partir de ce moment. Voyez l'arborescence -mm comme une zone d'attente, et de la mienne comme l'arborescence de sortie. Nous travaillerons ensemble, mais le boss c'est Andrew.

(l'integration BK devrait se faire à travers un format d'approbation, nous verrons comment ça marchera exactement).

C'est en fait assez court parce que j'ai commencé tard. Vois ci-dessous.

Il y a aussi les listes "must-fix" et "should-fix" que nous avons déterminées comme restant à faire. Elles sont sur

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/must-fix/must-fix-7.txt and ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/must-fix/should-fix-7.txt

• Le kernel 2.6.0 kernel à subi plusieurs semaines de stabilisaton et nous pensons qu'il tournera bien sur des machines serveur.

  Les stations de travail ainsi que les portable pourraient avoir plus de mal cette fois-ci à cause de la gamme plus large de matériel et de correctifs non-implémentés pour les bogues matériels ou BIOS que ces machines ont tendance à avoir.

  Pendant la période de stabilisation 2.6.0 un nombre signifiant de correctifs moins ciritiques ont été accumulés sur diverses arborescences auxiliaires et ceci devrait être integré dans le flot 2.6 après la sortie du 2.6.0. Beaucoup de ces correctifs sont dans l'arborescence "-mm" sur

  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/

• Rapportez vos problèmes sur la mailing list appropriée. Si vous ne savez pas laquelle utiliser, envoyez un rapport à linux-kernel@vger.kernel.org et ça devrait toucher la bonne personne. Quelques mailing lists de sous-systèmes actives sont:

  linux1394-devel@lists.sourceforge.net
  linux-xfs@oss.sgi.com
  linux-acpi@intel.com
  linux-scsi@vger.kernel.org
  ext2-devel@lists.sourceforge.net
  linux-usb-users@lists.sourceforge.net

  Autrement, les rapports de bogues kernel peuvez être entrés dans le système de traçage de bogues sur http://bugme.osdl.org/

• Il y a des changements signifiants dans les sous-systèmes de modules, le LVM (Device Mapper), et le RAID. Les détails là-dessus et autres changements dans le kernel sont décrits dans le document de David Jones sur la mise à jour du kernel sur

  http://www.linux.org.uk/~davej/docs/post-halloween-2.6.txt

  Les utilisateurs testant les kernels 2.6 pour la première fois devraient consulter ce document.

• Les drivers RAID ATA (c'est à dire le driver HighPoint) n'ont pas été portés sur le nouveau code BIO et ne sont pas disponibles sur le kernel 2.6 en ce moment.
• cryptoloop ne marche pas sur les machines avec beaucoup de mémoire. Les correctifs sont sur -mm et sont prévus pour 2.6.1.

• Il y a des problèmes de performance connus avec les scheduler d'E/S disque qui se montrent quand la charge de travail fait de petites lectures et écritures aléatoires (c'est à dire base de données). C'est corrigé largement en -mm.

  De manière genérale le scheduler E/S "deadline" est, et restera plus rapide que le schedules E/S "anticipant" dans ces sorte de charges. Les administrateurs de base de données devraient ajouter le paramètre de boot "elevator=deadline".

• Il y a des problèmes de performance du à un mauvais comportement du code de readahead qui impacte aussi les charges de travail type base de données. Corrigés dans -mm, en attente pour 2.6.1.
• Il y a un grand nombre de correctifs du driver frame buffer en attente.

Je pense que les processes que nous avons utilisé l'année dernière ont bien marché (sinon dites le). Dont les changements que nous apportons à ce process ne devraient pas être arbitraire.

Je pense que jusqu'à la séparation 2.7.0, Linus et moi nous continuerons de travailler sur le 2.6.x de la même manière - c'est ce que je prefère de toute façon.

Le seuil d'intégration pour 2.6 devient plus elevé, mais les gros changements seront rejetés en attendant plus de vérificatons et plus de tests. Je continuerai d'avoir une arborescence alternative pour ce service de test.

De manière generale, nous devrions nous attendre à de gros changements au cous de la vie du 2.6 - ce n'est pas réaliste de croire à autre chose. Nous devons trouver un process pour absorber ces changements (et de les mettre / prendre en 2.7.x) sans rien endommager. Nous avons bien fait au cours du 2.5, je pense.

Nous devrions attendre tranquillement une semaine, au cas ou nous devrions sortir un 2.6.1 pour des bogues insoupçonnés. Après cela nous devrions chercher à réduire le patchset -mm.

La version 0.4.0 de libsysfs est disponible sur:

http://linux-diag.sourceforge.net

Un bon nombre de changements dans cette version qui nécessitera des modifications sur les applications qui utilisent déjà cette bibliothèque. (udev-009 à déjà une partie de ces changements).

Voici les additions/changements importants:

• Remise à plus tard de la lecture des répertoires jusqu'à ce que ce soit nécessaire.
• Stucturation des éléments qui sont des listes ou des références pour les structures qui ne sont pas peuplées par défaut. Les API pour les peupler sont fournies.
• Toutes les fonctions "open" qui ont un chemin absolu comme argument ont maintenant un suffixe "_path".
• Fourniture de fonctions d'attribut "refresh" pour lire les attributs mis à jour.
• Changes pour compatibilité klibc.
• Forniture d'APIs pour récuperer device/class_device "parent".
• Ajout de pages man pour lsbus et systool (Merci à Martin Pitt).

Visitez http://linux-diag.sourceforge.net/Sysfsutils.html pour plus d'informations.

Le premier patchkit x86-64 pour le kernel 2.6.0 est sorti. Je n'annonce génerallement pas les patchkit sur linux-kernel, mais pas mal de gens semblent ne pas les connaître. Le patchkit a des correctifs pour pas mal de bogues sérieux (y compris des problèmes de corruption de données e/s) sur x86-64 qui ne sont pas dans le 2.6.0 officiel. Ne m'informez plus de problèmes x86-64 si vous n'avez pas mis le patchkit d'abord.

J'espère que maintenant que les arborescences sont plus ouvertes, la plupart de ça pourra aller dans l'arborescence officille, mais ça dépend de la politique adoptée par Linus/Andrew.

Cette version a quelques correctifs mineurs sur la dernière version du patchkit (x86_64-2.6.0test11-3)

ftp://ftp.x86-64.org/pub/linux/v2.6/x86_64-2.6.0-1.bz2
df65fee5a0388a036d324cb9b16bd778 x86_64-2.6.0-1.bz2

ChangeLog depuis x86_64-2.6.0test11-3:

• Marquage de drivers non 64bits !64BIT
• Retrait de dump_sg dans pci-gart.c encore
• Inefficatictés dans find_next_bit

Un Changelog plus ancien est disponible sur

ftp://ftp.x86-64.org/pub/linux/v2.6/RELEASE-NOTES

Quelques problème connus:

• Taskfile IO peut planter le hwscan de SuSE. Mieux vaut le désactiver.
• Taskfile IO peut causer une corruption disque.
• NMI watchdog se lance trop souvent (HZ au lieu d'une seconde) (toujours vrai?) [Je pense que c'est corrigé mais ça doit être vérifié]
• Machine Check appelle printk actuellement, mais ça peut faire un deadlock quand le MCE arrive dans un lock console.
• support de sysfs pour arch/ pourrait ne pas être complet.
• Le SYSCALL 32bits semble avoir quelques problèmes avec certains programmes (desactivé actuellement)
• Rapports de segfaults persistants après des tests en charge (vu un ici aussi, je dois le reproduire). Pourrait être un overflow IOMMU.
• Bogue timer mistérieux dans certains cas. Peut après le boot, les listes timer sont corrompues dans certaines configurations. Ca semble dépendre de la longueur du boot.
• JFS semble corrompre les systèmes de fichiers rapidement (bogue 64bit générique) [le mainteneur ne peut pas le reproduire]
• WCHAN semble ne pas marcher
• Suspend n'initialise souvent pas la video après le réveil Problème généréique, nécessite beaucoup de travail pour le corriger correctement. La carte graphique doit être POSTée correctement ce qui est assez compliqué.
• Le driver MPT fusion ne marche pas lors que iommu est desactivé (lancé avec iommu=merge) Un contounement pour cela est activé par défaut. Le bogue sous-jascent est toujours là. Le bogue ne semble arriver que sur certaines machines, la plupart des utilisateurs MPT fusion n'ont sans doute pas à s'en préoccuper. Ca semble être un bogue driver.
• Le dirver Realtek 8169 ne supporte pas >4Go (le patch existe mais devrait être integré par le mainteneur du driver réseau)
• Les cartes Nvidia et VIO sont forcées d'avoir IO-APIC off pour contourner certains bogues ACPI. Ceci sera un problème majeur lorsque des cartes SMP seront sorties avec ces chipsets.
• Quelques cartes ne mettent pas l'horloge correctement
• Le G400 DRM plante la machine
• Le VIA SATA ne marche pas
• Certaines personnes rapportent des corruptions disque IOMMU. Incapble de le reproduire. Ca semble arriver sur les drivers de périphériques de bloc qui ont une file d'attente profonde. La plupart de ces périphériques n'ont pas besoin d'un IOMMU (3ware est une exception) parce qu'ils supportent des E/S 64bit. Malheureusement beaucoup de gens tournent avec CONFIG_IOMMU_DEBUG ce qui force le support IOMMU pour chaque périphérique. Modifier le flush IOMMU afin de flusher sur chaque mapping semble le corriger Actuellement il y a des contounements actifs qui cherchent du matériel Qlogic et 3ware. Que ceux qui voient encore cela essayent iommu=fullflush et en disent plus. Le bogue sous-jascent est toujours à déboguer.
• Le scheduleur ne marche pas bien avec NUMA. Il ne distribue pas les threads rapidement à tous els CPUs, ce qui fait allouer de la mémoire sur les mauvais noeuds.
• Quelques combinaisons carte-mère/cpu ne rebootent pas automatiquement
• Le code de setup IPSec netlink n'est pas sain pour l'émulation 32bits
• l'émulation 32bits iptables n'est pas saine
• valgrind ne tourne pas avec linux32 --3gb. Regarder ce qui est différent
• [Un a.out d'emacs ne marche pas. Sans doute la même différence]