Kernel Traffic #244 For 8 Dec 2003

Le patch ci-joint permet à depmod de sortir le fichier modules.pnpmap généré à partir de la table des périphériques pnp.

Le format de sortie n'est pas compatible avec le vieux modules.isapnpmap. Le nouveau format montre la chaîne ID pnp (c'est à dire CTL0301) alors que le vieux format utilise des nombres hexadécimaux. Je ne pense pas que ça vaille le coup de rester compatible pour cela (puisque le nouveau est plus intuitif), mais il serait facile de suivre la vieille façon de faire.

Ca semble étrange. Si vous ne vous souciez pas de compatibilité ascendante, alors la nouvelle approche de scripts/file2alias.c est meilleure, elle genére des alias pour chaque module (depmod recupère ensuite ceux-ci dans /lib/modules/`uname -r`/modules.alias pour aller plus vite).

Les tables genérées par depmod ne sont destinées qu'à la compatibilité ascendante, bien qu'il semble que ce sera requis pour la 2.6.

Cela vous aide-t-il?

Tout d'abord j'ajouterais le support de l'ancien format isapnp pour rester compatible avec les anciens programmes.

Le format file2alias pour les périphériques pnp (isa) auront besoin d'un nombre variable d'objets, puisqu'un driver peut requérir des id multiples. Par example, snd-cs4236 supporte les cartes avec trois ids comme

CSCe825:CSC0100:CSC0110

Et quatre ids comme

CSCd937:CSC0000:CSC0010:CSC0003

Dans chaque cas, une carte correspondante doit inclure tous les ids listés ici.

En fait, je ne suis pas sûr de quel lettre identifiante (séparateur) dans quel style doive être utilisée. Quelque chose comme

pnp:idXXXxxxxd0XXXxxxxd1XXXXxxxx

?? les séparateurs incluant un nombre sont peut-être un mauvaise idée cependant.

Le patch ci-joint, permet d'ajouter les entrées pnp dans file2alias.c. j'ai déplacé les définitions de pnp_device_id et pnp_card_device_id dans mod_devicetable.h comme pour les autres périphériques. si ça ne vous convient pas, je reviendrais en arrière en mettant les définitions dans file2alias.c pour réduire les changements.

le format de pnp alias est:
pnp:dXXXYYYY
ou
pnp:cXXXYYYYdXXXYYYY[dXXXYYYY...]
où XXXYYYY est l'id pnp avec 7 lettres (c'est à dire CTL0301), c montre l'id de la carte et d donne l'id du périphérique. les ids multiples des périphériques seront seront listés en fonction du driver.

par exemple,

alias pnp:dYMH0021* opl3sa2
alias pnp:cALS0001d@@@0001d@X@0001d@H@0001* snd_als100

Andrey, cela peut-il être faisable pour le hotplug?

Chaque d sera-t-il passé comme un paramètre particulier à hotplug? Ca veut dire que l'agent doit gérer un nombre inconnu de paramètres ou bien y a-t-il un nombre limité de périphériques? apparament non, puisque les maximum est 8 et dans votre example seuls 3 d'entre-eux sont définis.

Si le nombre est variable, je pense que ce serait meilleur:

alias pnp:cXXXXXXdYYYYYYY[:YYYYYY...]

donc, mettre tous les ID de périphériques dans un champ; en fait peut-être même que les séparateurs sont inutiles, puisque les ID ont un format bien défini à ma connaissance.

Alors l'agent hotplug reçoit deux paramètres - PNPID et PNPDEVS - et ça devient facile de construire les alias.

Je pense qu'il est grand temps de débarasser SIIMAGE.C 1.06 de ses bogues. Il smble avoir des problèmes avec mon disque dur+convertisseur SATA surtout dans le domaine de la performance. Je pense que ça vient d'une erreur affichée sans arrêt dans dmesg à moins que je ne la commente dans les sources:

hde: sata_error = 0x00000000, watchdog = 0, siimage_mmio_ide_dma_test_irq

Quel est le problème? Je pense que ça peut venir du fait que j'ai un contrôleur integré SiI3112A et le driver le detecte dans la révision A (comme un SiI3112). Et/ou ceci peut-être du au fait que j'ai connecté un disque PATA avec un convertisseur SATA au contrôleur.

Avec le 2.6-test10, la performance s'est legérement améliorée en comparaison avec test9 est les kernels 2.6 précédents. Avant il a donnait 22Mo/sec contre 25Mo/sec actuellement. Mais c'est toujours loin du kernel 2.4.22-ac4 qui réussissait 37Mo/sec, ce qui est toujours mauvais en comparaison de windows qui atteint 50Mo/sec.

Ce n'est pas un problème de read-ahead. J'ai essayé divers paramètres hdparm et cela n'a pas amélioré la situation. Ce qui rend la situation encore plus mauvaise:

Lorsque j'essaye hdparm -d1 /dev/hde (bien qu'hdparm dise que le dma est déjà actif) le disque cesse de marcher et j'ai des lignes d'erreur comme l'erreur drive-seek et des machins liés aux irqs. Je dois donc appuyer sur le bouton.

Quelqu'un d'autre utilisant un Maxtor SATA sur Sil3112 (je ne sais pas si A ou non) et n'ayant pas de problèmes, hdparm -d marche aussi et il a 40Mo/sec en test10.

Cela peut donc être le problème, comment le résoudre? (1. message d'erreur 2. mauvaise performance, 3. dysfonctionnnement de hdparm -d1). 1 & 3 étaient présents en 2.4.22-ac4 mais 2 n'était pas si mauvais, comme je le disais ci-dessus, donc mis à part 2, il n'y a pas de régression, mais pas de correctif non plus. Changer max_kb_per_request n'a rien apporté non plus.

Holy Shit!(Nom de zeus! NDT)

Je viens d'essayer le driver libata et ça DECHHHHIRE!!!! Pour l'instant au moins.

J'ai déjà écrit sur le mauvais driver ide SiI3112, maintenant avec libata j'ai >60Mo/sec. Plus que ce que j'ai avec windows.

Même les tests avec dd. Ca déchire. Voyons si il aime swsup aussi...

Donc les gars, essayez libata aussi.

Je ne sais pas ce qui est nécessaire en fait. J'ai mis scsi, scie disk, scsi generic, sata et son driver. Dans grub, j'ai rajouté "doataraid noraid".

OUI!

Je ne trouve pas le driver Silicon Image sous

"SCSI low-level drivers" -> "Serial ATA (SATA) support"

en 2.6.0-test11. Il n'y a que les suivants:

ServerWorks Frodo
Intel PIIX/ICH
Promisa SATA
VIA SATA

De quel kernel ais-je besoin?

OK, arrêtez de descendre le driver IDE... trois mails sont suffisants...

Appliquez ce patch et vous devriez obtenir une performance similaire du driver IDE. Vous obtenez sans doute de grandes améliorations avec le driver libata parce que vous utilisez des disques Samsung et IBM/Hitachi uniquement, pour les Seagate ça marche sans doute aussi mal que le driver IDE...

Le driver IDE limite les requêtes à 15Ko pour tous les lecteurs SATA... libata ne limite les requêtes à 15Ko que pour les disques Seagate SATA...

Les deux drivers nécessitent un correctif approprié pour les lecteurs Seagate...

pour tous ceux qui ont pensé que "stoned beaver" (voir l'édition #243 de KT NDT) n'était pas un nom approprié pour un kernel (ouais, je suis sur qu'IBM est inquiet au sujet de mes méthodes de nommage, et a mortellement peur d'effrayer ses clients), je suis heureux de vous annonçer que le castor (beaver NDT) est parti en désintox, et que je serai absent pour le weekend de Thanksgiving.

Je vous donne le "Beaver in Detox", alias linux-2.6.0-test11. Qui est principalement nécessité par le fait que le vieux driver aic7xxx ne marchait pas en -test10, et qu'Ingo a trouvé ce programme de test diabolique qui montrait un cas d'erreur dans do_fork() que nous n'avions jamais geré correctement. Bon!

D'ailleurs, cela ajoute quelques correctifs firewire et solutione quelques fuites de skbuff potentielles.

Ne vous donnez pas la peine de m'envoyer des patches, parce que je ne regarderais pas mes mails ces jours à venir. Puis après cela, ça sera à Andrew de diriger les opérations.

Mmmm. De la dinde.

Ceci est le portage du patch d'Hugh Dickins pour implémenter le support de larges PAGE_SIZE logicielles préservant la compatibilité ABI, effectivement "large taille de bloc de la VM". Ca a aussi été appelé "subpages". "pgcl" est une abbréviation de "page clustering", après le sens historique, mais différent dans BSD.

Le but est de rendre la gestion de mémore plus éfficace en réduisant le nombre d'objets à gérer, ainsi qu'en offrant une continuité physique plus importante en gardant les morceaux plus grands que ce vers quoi pointent les ptes individuels. Ceci réduit notoirement les besoins d'espace pour mem_map[]. J'espère démontrer bientôt plus d'avantages comme le support de plus gros blocs dans les systèmes de fichiers, et l'abaissement de la longueur de la sglist.

Cette version met en oeuvre la réécriture de toute la logique de gestion de fautes. Ceci devrait marcher bien mieux que les versions précédentes puisque ça implémente le COW (copy-on-write NDT) et intègre le search overhead, bien qu'il y ait beaucoup de possibilités d'optimisation encore.

Testé pour les fonctionnalités de base en espace utilisateur sur un Thinkpad T21 de 256Mo et un NUMA-Q de 32Go avec une PAGE_SIZE de 32Ko. Ca plante si vous le poussez un peu loin, mais ça lance les scripts init, la plupart des programmes, et quelques benchmarks ici.

Disponible sur: ftp://ftp.kernel.org/pub/linux/kernel/people/wli/vm/pgcl/

Des patches incrémentaux pour toutes les étapes de la réécriture ainsi que des diffs cumulatifs pour 2.6.0-test5-bk3 et 2.6.0-test5 sont aussi disponibles là-bas.

Errata:

1. le cas CONFIG_PAGE_CLUSTER==0/PAGE_MMUCOUNT==1 ne marche pas
2. quelques oops en faisant tourner KDE
3. quelques mystérieuses imbalances dans preempt
4. les drivers et les fs's ne sont pas vérifiés, et probablement défectueux
5. les architectures non-i386 ne marchent pas
6. CONFIG_DEBUG_HIGHMEM ne marche pas
7. CONFIG_DEBUG_PAGEALLOC ne marche pas
8. bien, bien d'autres

TODO:

1. joindre au kernel actuel
2. nettoyage des drivers/fs
3. optimisation et travail de l'API kmap_atomic_sg() pour ne pas impacter CONFIG_NOHIGHMEM
4. nettoyage du code non indispensable (c-à-d code de debug)
5. révision de l'allocation de la pagetable
6. révision/optimisation de l'intéraction rmap
7. révision des invalidations des TLB
8. correction de tous les bogues (comme d'habitude)
9. peut-être essayer l'émulation 32-bit de l'ia64

ftp://oss.sgi.com/projects/xfs/download/patches/2.4.23.

Pendant un certain temps, le groupe XFS à produit des patches découpés pour XFS séparant les patches centraux XFS des patches additionnels comme kdb, acl et dmapi. Les patches découpés sont distribués dans l'espoir que les développeurs et les distributeurs les trouveront utiles.

Lire le README dans chaque répertoire attentivement, le format des patches découpés à changé entre les sorties de kernels. Toutes les questions traitées par le README seront ignorées. Il y a même un 2.4.24/README pour les impatients :).

Repensez-y s'il vous plaît -- les changements "centraux" pour le kernel, sont là depuis plus de trois ans, en dehors de l'arbre principal, chacun est petit et facilement compréhensible qui n'affecte pas les autres systèmes de fichiers. Il y a aussi une correction VFS d'Ethan Benson, que nous avons discuté pendant le 2.4.23-pre, lorsque vous nous avez demandé de renvoyer XFS pour le 2.4.24-pre!) Tout ce qu'il y a ici, est un portage de ce qu'il y a en 2.6 d'une certaine manière, il ne devrait pas y avoir de surprise.

Ne pas avoir XFS en 2.4 est extrêmement désavantageux pour nous, gars XFS (surtout depuis que tous les autres systèmes de fichiers journalisés on été intégrés). Pour nos utilisateurs cela veut dire que certaines disquettes de réparation ne supportent pas XFS, vous ne pouvez donc pas monter les systèmes de fichiers lorsque vous en avez _vraiment_ besoin, etc, etc. C'est aussi du travail supplémentaire pour les distributeurs qui doivent intégrer XFS eux-mêmes, et donc, certains ne le font pas (et nous disent qu'ils attendent que vous les intégriez) - ce qui veut dire que certains utilisateurs n'ont même pas le choix d'utiliser XFS, malgré tous nos efforts.

>D'après mes discussions avec les distributeurs, une distribution 2.6 stable ne viendra que des mois après la sortie officielle du 2.6.0, donc ces problèmes ne aucunement se règler bientôt.

Donc, integrez s'il vous plaît XFS cette fois-ci - c'est activement développé, a une large base installée, a été maintenu en dehors du 2.4 depuis longtemps. Nous avons attendu patiemment votre aquiescemment à chaque version, mais nous avons été rejettés à chaque fois alors que diverses autres intégrations étaient faites.

Concernant XFS, Christoph va vérifier les patches et me dire ce qu'il en pense.

D'autres personnes m'ont aussi mailé disant qu'ils avaient vérifié le code.

Ca me rend plus confiant dans l'intégration des modifications XFS.

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

des rpms sont disponibles sur:
kernel.org/pub/linux/utils/kernel/hotplug/udev-008-1.i386.rpm
avec le rpm source sur:
kernel.org/pub/linux/utils/kernel/hotplug/udev-008-1.src.rpm

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

Note:

La façon dont les fichiers de configuration d'udev sont structurés a beaucoup changé. Précedemment il y avait deux fichiers de configuration, /etc/udev/udev.config et /etc/udev/udev.permissions. La localisation de ces fichiers peut-être modifiée lors de la compilation ou au runtime avec des variables d'environemment.

Il y a maintenant un seul fichier de configuration a /etc/udev/udev.conf. Le contenu de ce fichier dit à udev où se trouvent les autres fichiers de configuration (pour les règles et les permissions) et spécifient d'autres choses configurables. Pour plus de détails sur ce fichier, se reporter à la page man, qui traite cette page et comme la configurer. Voir aussi le fichier udev.conf par défaut inclu dans cette version.

Les principaux changements depuis la version 007 sont:

• structure differente des fichiers de configuration (voir la Note ci-dessus pour plus d'info.)
• gestion appropriée des valeurs BUS maintenant (avant elles étaient ignorées.)
• Un ensemble basique d'expressions régulières est maintenant supporté. Voir la page man pour plus de détails.
• La logique de gestion des permissions a été réécrites pour marcher correctement avec les règles qui ont des expressions.
• nouveau modificateur de format '%D' ajouté pour rendre plus facile la creation de noms semblables à devfs.
• script automatisé de regression ajouté (lancer le script udev-test.pl dans le répertoire test/ pour être sur que les changements que vous faites ne cassent rien d'autre).

Encore, merci à Kay Sievers, pour un tas de bons patches dans cette version. Je suis vraiment reconnaissant pour le script de test automatisé et le support des regex qu'il a apporté. Cette version inclut des patches de diverses personnes, voir ci-dessous.

Il y a quelques fonctionnalités à venir dans la prochaine version de libsysfs qui devraient aider un peu udev, mais cette version montre à quel point udev est flexible dans la création de différents types de noms de périphériques. Si vous n'avez toujours pas testé udev, pensant qu'il était trop top, je vous suggère d'essayer cette version, elle inclut toutes les fonctionnalités requises aujourd'hui.

J'attends toujours un fichier de config correspondant au système de nommage devfs. Quelqu'un peut-il vérifier si udev supporte tout ou pas? Je sais que ça fait quelques versions que je le dis...

Le ChangeLog peut être trouvé ci-dessous.

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

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

Minuetes LSE Call du 3 décembre 2003

Zwane Mwaikambo - Experiences OSDL

D'une manière générale, travailler avec OSDL a été génial.

Afin d'utiliser les machies d'OSDL, vous devez vous enregistrer comme associé et inscrire un projet. Vous devez ensuite attendre qu'OSDL le vérifie. Zwane voulait une grosse machine pour travailler sur le sous-système d'irqs. Il avait besoin d'un accès au machines NUMA-Q afin de tester d'éventuelles regressions.

La plupart de ses contacts se sont faits avec Christine qui répond rapidement à ses mail et a corrigé le peu de problèmes qui sont apparus.

Zwane a eu quelques problèmes en utilisant le PLM (Patch Lifetime Manager). Cliff lui parlera de son utilisation. Zwane a fait quelque chose de similaire manuellement.

Le STP permet à l'ingénieur de gagner du temps en n'ayant pas a attendre entre chaque étape. Il permet d'automatiser une bonne partie du processus de test.

Marcelo Tosatti - Il utilise aussi les machines OSDL. Il dit que ça avait été très facile à utiliser. Ce sont les seules systèmes avec beaucoup de mémoire qu'il a à disposition. Il les utilise pour des grosses charges de test et teste quelque fois le 2.6 dessus.

Zwane dit qu'il aime les possibilités de compilation croisée qui ont été ajoutées recemment. Cliff dit que c'était un résultat direct des commentaires d'OLS cette année.

Zwane dit qu'un incovenient de STP et de Tinderbox est l'énorme masse de données qui vient de la et qui est difficile à traiter. Il préfererait une information plus minimaliste disant si le kernel a booté ou pas ainsi que les erreurs. Cliff lui dit d'essayer HackBench, le test STP le plus petit.

Le temps de roulement de la soumission du patch aux résultats sur un système libre est de 1.5 heures. C'est du au reimaging du système complet entre les lancements. Cliff y jettera un coup d'oeil afin de rendre ceci plus rapide.

Bill Irwin suggéra d'utiliser nfs pour la partition root alors le système hôte peut le fournir en nfs et pourrait nettoyer et verifier en utilisant les sommes de contrôle md5 ce qui serait bien plus rapide que le reimaging. Cliff dit que la plupart des utilisateurs n'utiliseraient pas nfs en root, et cela pourrait impacter les resultats de benchmarks. Bill dir que la plupart des benchmarks n'étaient pas lancés en root de toute façon. Cliff dit que c'était une bonne idée et qu'il se pencherait dessus.

Cliff White - Kernel Tinderbox

History- Venu du Brésil. Christian Reis d'Asynch Open Source qui a travaillé sur la Tinderbox Mozilla demanda à Marcelo ce qu'il pensait d'une Kernel Tinderbox. Marcelo lui répondit d'aller en parler à OSDL, et le reste c'est de l'histoire.

La Tinderbox Mozilla est basée sur CVS et peut faire de belles choses avec les triggers. Celle du kernel n'est pas aussi belle parce qu'ils travaillent toujours sur des problèmes avec BK.

Brievement, le client lance une boucle, et se reveille toutes les 15 minues et vérifie bkbits. Si il y a eu des changements dans ces 15 minues, le nouveau kernel est téléchargé et compilé avec le script de regression de John Cherry, qui est exhaustif. La meilleure façon de voir les résultats est d'aller sur http://developer.osdl.org et de cliquer sur le lien tinderbox ou ici (http://tinderbox.osdl.org/showbuilds.pl?tree=linux2.5-bk)

Intel a contribué avec un client 32 et 64 bits. OSDL cherche à ajouter d'autres architectures (appel appel, spéciallement des Power tout de suite).

Marcelo demanda si ça bootait aussi le kernel. Cliff, non, ça le compile juste pour l'instant. On travaille sur un client qui bootera mais STP est plus adapté pour booter un kernel inconnu. Cliff cherche a utiliser STP comme client Tinderbox.

Ils ne traitent pas avec mm ou d'autres arbres, ils ne marchent qu'avec bkbits pour l'instant.

Cliff demanda si quelqu'un avait un matériel Power ils en auraient vraiment l'utilité. Ca n'a pas a être sur le site ils n'ont besoin que d'un accès à la machine. Zwane dit qu'ils pourraient utiliser la compilation croisée pour tester les trucs Power à la place puisqu'ils ne bootent pas.

Si quelqu'un veut bidouiller, le client est disponible sur la page de Cliff sur osdl: http://developer.osdl.org/cliffw/

Nous avons échangé quelques mails avec support@bitmover.com et ils ont été d'une aide précieuse. Il reste deux choses.

La première se sont les triggers. La tinderbox Mozilla est dirigée par les triggers des commits CVS. Je pense que les triggers sont réservés à la version commercial de BK.

Cependant, contrairement à CVS, BK a une manière élégante de demande à l'entrepôt distant si de nouveaux changements existent, nous n'avons donc pas vraiment besoin d'un trigger pour nous dire de commencer une compilation. A la place on lance la colonne timestamp dans un cron, afin que ce soit toujours incrémenté. (Mozilla n'imcrémente sa colonne timestamp que lorsqu'un trigger est reçu).

Le passage de timestamps dirigés par les triggers à des timestamps dirigés par le temps a fait que nous n'avons pas essayé de créer un lien entre le timestamp et le source commit. Là encore, puisque Mozilla est dirigié par les triggers, ils ont ce lien.

Donc le second problème est le lier soit la colonne timestamp ou la colonne de la machine compilateur directement à une vue web du code. BkWeb fournit déjà cette vue.

Le principal problème ici est de trouver la syntaxe adaptée pour l'url bkweb pour que nous recevions tous les changesets inclus dans le commit. Nous avons reçu quelques examples de vos gars du support, et nous en utilisons un actuellement.

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

Ceci est du code alpha. Il a reçu un test minimal avec un petit ensemble d'options de configuration. En particulier, il n'a pas été testé avec CONFIG_PREEMPT. Il ne marche que sur des machines ia64 vanilla en utilisant la console série et un clavier PC/VT. Des patches pour porter la console USB de kdb du 2.4 au 2.6 seront grandement appréciés.

Ces patches 2.6.0-test11 doivent être appliqués dans cet ordre, sur le 2.6.0-test11 plus le patch linux-2.6.0-test11-ia64-031126 de David Mosberger.

kdb-v4.3-2.6.0-test11-common-1.bz2
kdb-v4.3-2.6.0-test11-salinfo.bz2 (brings salinfo processing up to 2.4.23)
kdb-v4.3-2.6.0-test11-xfsidbg.bz2 (corrects out of date XFS debug code)
kdb-v4.3-2.6.0-test11-ia64-031126-1.bz2

Ceci est un clone de kdb v4.3-2.4.23, avec des changements de diverses personnes pour le 2.6, merci à Xavier Bru et Jim Houston pour les changements 2.6 à kdb.

La suite de tests 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: les resultats de test, un matrice d'outils de test Linux, une zone maintenant les correctifs pour des problèmes connus dans les versions 2.5/2.6 du kernel, des articles techniques et des HowTos sur le test sous Linux, et un outil d'analyse de couverture du code.

Points importants:

• Mis à jour le driver de test LTP pour gèrer les signaux temps-réel.
• Mis à jour les tests command pour assurer un meilleure portabilité.
• Ajour d'un nouveau test NFS, nfs_fsstress, pour charger NFS en utilisant le test fsstress.
• Ajout de nouveau tests pour le SCSI bas-niveau, virtual SCSI, E/S asynchrones & contrôle et gestion des ACL
• Ajout de corrections de bogues, patches et nettoyages du code.

Nous encourageons la communauté à poster des resultats, patches ou nouveau tests sur notre mailing list <ltp-list@lists.sf.net> et d'utiliser le bug tracking sur CVS pour rapporter les problèmes que vous pourriez rencontrer avec notre suite de tests.

Je me suis finalement lassé de lancer "bk -r get" avant de lancer une compilation, j'ai donc appris à kbuild à récuperer les fichiers pour moi. J'ai fait la plupart du travail avant que Sam n'ajoute l'option KBUILD_OUTPUT, ça ne marche donc pas lorsque vous compilez vers un répertoire différent. Il pourrait probablement être ajouté avec quelques bidouilles à scripts/getfiles, mais je suis paresseux, et je n'utilise pas KBUILD_OUTPUT personellement. Si ça vous ennuie, vous êtes libre de prendre ce code et de le lancer. La même chose est valable pour CVS ou subversion -- ça ne devrait pas être très difficile de les faire marcher aussi.

Ce n'est pas vraiment destiné à être inclus, c'est juste quelque chose qui me rend la vie plus facile. Ca facilitera peut-être la votre aussi. J'aurais cependant à faire beaucoup, beaucoup de compilations pour rattraper le temps perdu.... :)

Les patches suivent, ou les utilisateurs BK (le public visé) peuvent faire un

bk pull http://typhoon.bkbits.net/autoget-2.5