L'actualité du noyau
Depuis le début de la semaine, j'essaie de suivre le développement du noyau Linux en lisant quelques messages de la
Linux Kernel Mailing List au travers d'un
newsgroup. Ça faisait plusieurs années que je n'avais pas utilisé de
newsgroups, les délaissant au profit des listes de diffusion. Mais finalement, pour une liste avec un traffic comme la
LKML (plusieurs centaines de courriers électroniques par jour), les newsgroups sont une bonne idée, car ils évitent de surcharger une boîte aux lettres vers laquelle affluent déjà de nombreux courriers électroniques.
Durant ces lectures, j'ai pu y découvrir plusieurs choses intéressantes:
- Un étudiant a posté le résultat de son travail réalisé dans le cadre d'une EndThesis à l'Université de Niederrhein. Il s'agit d'un framework permettant d'automatiser la création du fichier .config (contenant la configuration du noyau à compiler). Pour cela, il se base sur la configuration actuelle de la machine. Le README explique relativement bien le fonctionnement de la chose: un fichier XML définit des règles pour les différentes options du noyau. Pour déterminer si une option doit être activée ou pas, il fait appel à un script ou à un binaire externe qui répond simplement "y", "n" ou "m", en fonction des besoins. En utilisant les informations de /proc/cpuinfo, on peut déterminer automatiquement pour quel CPU le noyau doit être compilé, avec le résultat de lspci, on peut déterminer les périphériques présents sur la machine et activer les pilotes correspondants.
Dans tous les cas, même pour les power-users, ce genre d'automatisation peut-être assez pratique. Combien de fois n'éprouve-t-on pas des difficultés à trouver quel module du noyau correspond à tel ou tel périphérique. Une opération qui peut très bien être automatisée.
- Peter T Breuer a publié un outil appelé tout simplement "c". Il s'agit d'un analyseur statique de code pour le noyau Linux qui permet de détecter des choses intéressantes comme les sleep alors qu'un spinlock est pris, les prises doubles de spinlocks ou les utilisations de mémoire après libération par kfree. En particulier, sa demande concernait les fichiers .o.cmd: il souhaitait que d'autres développeurs lui envoient de tels fichiers, car ils contiennent la ligne de compilation utilisée pour compiler le fichier .o correspondant. Ainsi, Peter pourrait tester son outil sur une plus vaste partie du noyau. D'autres développeurs noyau lui ont rappelé l'existence de la cible allmodconfig du Makefile du noyau, qui active la compilation de tous les modules.
À noter que Linus développe déjà un outil d'analyse statique du code appelé
Sparse et qui permet de vérifier un certain nombre de choses dans les sources du noyau. Ces outils d'analyse statique semblent décidement être à la mode, puisque Rusty Russell en a parlé à l'Ottawa Linux Symposium, et Dave Jones également dans sa
Keynote.
Je ne suis absolument pas un expert dans le domaine de la compilation, mais je pense que disposer d'un analyseur statique de code qui comprend correctement toute la grammaire du C, avec toutes les extensions de Gcc ne doit pas être évident. Du coup, je trouve dommage d'avoir ces duplications d'efforts: il y a
sparse, il y a
c, mais également
ncc, un compilateur destiné à générer des informations pour réaliser des graphes d'appel. Ne serait-il pas possible d'avoir un seul analyseur statique de code qui sache parfaitement parser le langage C, auquel on puisse « brancher » différents outils de vérification. Ainsi, la partie « analyse de la grammaire C » serait factorisée et donc serait sans doute de meilleure qualité, et cela faciliterait le développement de nouveaux types de vérification. Pour donner une illustration de la difficulté de bien analyser un source en C, j'ai découvert un bug dans
ncc qui le faisait purement et simplement segfaulter avec un bout d'assembleur... alors que
ncc passe sans problème sur le noyau Linux. Avoir un analyseur qui marche vraiment dans tous les cas est donc difficile, alors autant regrouper les efforts.
- L'éternel troll sur devfs n'en finit plus. Pour rappel, ce système de fichiers développé par Richard Gooch et intégré dans la branche de développement 2.3.x permettait d'avoir un "/dev/" dynamique. Au lieu d'avoir des noeuds stockés en dur, les périphériques apparaissent automagiquement dans "/dev/". Néanmoins, ce système de fichiers n'a jamais donné entière satisfaction, et depuis l'intégration de son remplaçant, udev, il vise à être supprimé. Greg KH avait déjà proposé sa suppression pour le 2.6.13, qui a été finalement refusée au profit d'une désactivation. Greg KH a donc soumis de nouveau des patches pour le supprimer dans le 2.6.14, soumission qui a relancé le vif débat sur le sujet. Greg KH, principal développeur d'udev soutient que sa solution remplace avantageusement devfs, en particulier parce qu'une grosse partie de ce que devfs faisait en espace noyau est maintenant fait en espace utilisateur par udev, grâce aux évènements envoyés par hotplug. Toutefois, certains pensent qu'il est encore trop tôt pour retirer devfs, par exemple parce que l'installeur de Debian est fortement dépendant de devfs. Pour clarifier la discussion, Mike Bell a publié une FAQ udev vs devfs qui liste les avantages et les inconvénients des différentes solutions. L'affaire devfs n'est donc pas encore close...
- Quelques jours plus tard, le même Greg KH annonçait la version 070 de udev et surtout un changement de mainteneur. C'est donc maintenant Kay Sievers qui est responsable d'udev.
- En début de semaine, Linus Torvalds a annoncé la sortie du 2.6.14-rc1. Comme son nom l'indique, c'est la première release candidate depuis la sortie du 2.6.13. En application du nouveau modèle de développement discuté par les développeurs noyau à Ottawa durant le Linux Kernel Summit, cette première release candidate, publiée 2 semaines après la sortie du 2.6.13, clôture la période durant laquelle les patches intégrant de nouvelles fonctionnalités sont acceptés. À partir de maintenant, et jusqu'à la sortie du 2.6.14, seuls des patches corrigeant des bugs seront acceptés. Ce nouveau modèle de développement est censé permettre aux développeurs de se focaliser pendant un moment sur la correction de bugs plus que sur le développement de nouvelles fonctionnalités. Linus Torvalds a d'ailleurs appelé à jouer le jeu, en intitulant son mail « Read my lips: no more merges », et en rappelant « Be nice now, and follow the rules: put away the new toys, and instead work on making sure the stuff that got merged is all solid. Ok? »
En même temps que j'ai décidé d'essayer de suivre un peu plus l'actualité du noyau, j'ai décidé d'essayer de tester les versions release candidate de ce dernier. J'ai donc téléchargé le patch de cette 2.6.14-rc1, qui s'applique sur le noyau 2.6.13 lui-même. En effet, bien qu'un noyau 2.6.13.1 soit sorti avant le 2.6.14-rc1, le développement du noyau se poursuit à partir du 2.6.13 officiel: les 2.6.x.y ne sont que des versions stabilisées du noyau 2.6.x, maintenues dans une branche séparée.
La configuration de ce
2.6.14-rc1 s'est déroulée très rapidement et sans encombre grâce à
make oldconfig. Avec cette cible, seules sont posées des questions concernant les options de compilation ayant changé. La compilation s'est bien déroulée et le tout fonctionne très bien, aucun plantage, et j'utilise donc ce noyau de manière courante. D'autre part, j'ai mis en place le système
KLive proposé par
Andrea Arcangeli. Il s'agit d'un petit script qui tourne en tâche de fond, et qui va régulièrement informer un serveur de la version du noyau utilisée, de l'
uptime, et de quelques informations sur la configuration de la machine. L'objectif de ce projet est de répondre à une question que se posait les développeurs noyau à Ottawa cet été: combien de personnes testent les noyaux
-rc. J'ajoute donc ma toute petite pierre à cet édifice en signalant que j'utilise le
2.6.14-rc1 avec succès. Vous pouvez faire de même ;-)
- J'ai été assez impressionné par la mise en application de la fonctionnalité bisect de git, dont j'avais déjà parlé. Un utilisateur a reporté une régression intervenue entre le 2.6.12.6 et le 2.6.13-rc1 (et toujours visible dans 2.6.14-rc1). Finalement, l'utilisateur a décidé d'utiliser git bisect pour déterminer précisement le patch ayant introduit la régression. Au bout de 13 compilations de noyau et reboots, le patch incrimé a été trouvé. Cela peut paraître beaucoup, mais comme le souligne Torvalds, 13 recompilations sont finalement assez peu si l'on considère le fait qu'il y eu 2069 patches intégrés entre le 2.6.12.6 et le 2.6.13-rc1. Git bisect semble donc définitivement être un outil très pratique.
- Dès la sortie du 2.6.13.1, le travail sur la 2.6.13.2 a commencé, mené par Chris Wright. Rappelons que l'objectif de la branche 2.6.x.y est de proposer une version un peu plus stable que la version 2.6.x de base, grâce à l'intégration de correctifs de bugs et de sécurité. Cette branche a été appelée sucker tree par Linus Torvalds lors de sa création, en raison du caractère ingrat du travail consistant à la maintenir.
Le processus pour la sortie d'un 2.6.x.y semble être le suivant: Chris Wright
poste une liste de patches (ici au nombre de 11), en demandant l'avis des autres développeurs noyau, et en leur demandant de signaler d'autres patches qui auraient vocation à être intégrés. Chris précise également à la fin de son courrier :
« Responses should be made by Sat Sep 17 01:00 2005 UTC. Anything received after that time, might be too late.». Il semble qu'il souhaite maintenir une certaine fréquence dans la sortie des versions 2.6.x.y et impose donc des dates limites. Tout ce qui n'est pas intégré dans 2.6.x.y pourra l'être dans 2.6.x.(y+1) de toute façon. À partir de ce post de Chris, vous pouvez suivre l'organisation et le déroulement de la sortie de ces versions stabilisées du noyau.
Le read-ahead est un mécanisme qui permet d'améliorer les performances en lecture depuis les périphériques de stockage. Il part du principe que le plus souvent, lorsqu'une application lit une petite quantité de données depuis un disque dur, il y a de fortes chances pour qu'elle accède à la suite de ces données (par exemple parce qu'elles sont dans le même fichier). Par exemple, si une application lit un fichier 4 Ko par 4 Ko un fichier de 16 Ko, et qu'on lit naïvement sur le disque dur, il faudra réaliser 4 requêtes de lecture. En étant un peu plus intelligent, on peut lire en avance (d'où le terme de read-ahead), ce qui a un double avantage. Tout d'abord, on réalisé une seule requête de lecture au lieu de quatre: il n'est donc nécessaire de calibrer la tête de lecture qu'une seule fois. En effet, les disques durs ont la propriété d'être lent pour le déplacement de leur tête de lecture, et d'offrir un bon débit une fois la tête positionnée. Ainsi, lire 16 Ko au lieu de 4 Ko ne prend que très peu de temps supplémentaire, puisque la majorité du temps est passé à déplacer la tête. Le second avantage est que grâce à cette lecture en avance, les données à lire sont présentes en mémoire avant même que l'application ne les demande.
Le problème est bien entendu de calibrer cette lecture en avance, pour qu'elle lise suffisamment (pour qu'elle soit utile), mais pas trop (pour ne pas qu'elle dégrade les performances en chargeant des données qui ne seront jamais utilisées). Et évidemment, le paramétrage de ce read-ahead dépend du type d'entrées-sorties réalisées par l'application. Si elles sont purement séquentielles (bloc N, puis bloc N+1, puis bloc N+2), alors il vaut mieux augmenter le read-ahead. En revanche, si les requêtes d'entrées-sorties concernent des blocs aléatoires sur le disque, alors il vaut mieux diminuer le read-ahead.
Le travail de WU Fengguang propose donc d'adapter le
read-ahead en fonction du contenu du
page cache. J'avoue ne pas avoir eu le temps de lire et de comprendre en détail le fonctionnement de son mécanisme d'adaptation, mais celui-ci est détaillé avec précision dans
le courrier électronique et
accompagné de nombreux benchmarks.
- Arnd Bergmann a publié une nouvelle série de patches concernant spufs. Je n'ai absolument pas regardé les patches, je n'y comprendrai rien, mais il m'a paru intéressant de parler brièvement de ce qu'est spufs.
spufs s'intègre dans le portage de Linux sur le
processeur Cell. Celui-ci, qui sera utilisé dans la Playstation 3, propose une architecture assez originale. Il est constitué d'un PowerPC 64bits "classique", mais également de 8 unités spécialisées appelées
Synergistic Processing Elements (SPE). Comme l'explique la page Wikipédia, chaque SPE est un petit processeur RISC disposant de 256 Ko de mémoire cache, qui permet d'exécuter du code en parallèle du processeur principal, le PowerPC 64 bits.
Pour que le portage de Linux soit complet, il fallait non seulement que le noyau Linux fonctionne sur le PowerPC 64 bits, mais également qu'il fournisse une interface de programmation pour ces
SPE, afin que des applications tournant sur le processeur principal puissent lancer des traitements spécifiques en parallèle dans les
SPE. Pour cela, les ingénieurs chargés du portage ont choisi d'utiliser un système de fichiers baptisé
spufs. Dans ce système de fichiers spécialisé, chaque répertoire représente un
SPE, et les différents fichiers contenus dans ce répertoire permettent de manipuler ce
SPE. La
page consacrée à ce sujet sur le site d'IBM donne l'exemple suivant:
$ mkdir /spu/myspu-12345
$ ls -lR /spu/
spu/:
total 0
drwxr-xr-x 2 arnd arnd 4096 Jun 17 21:00 my-spu-12345
spu/my-spu-12345:
total 0
-r--r----- 1 arnd arnd 0 Jun 17 21:01 ibox
-r--r----- 1 arnd arnd 0 Jun 17 21:01 mbox
-rw-rw---- 1 arnd arnd 262144 Jun 17 21:01 mem
-rw-rw---- 1 arnd arnd 2048 Jun 17 21:01 regs
-rw-rw---- 1 arnd arnd 0 Jun 17 21:01 run
--w--w---- 1 arnd arnd 0 Jun 17 21:01 wbox
Le fichier /spu/myspu-12345/mem représente le contenu des 256 Ko de mémoire cache d'un SPE. En réalisant des écritures dans ce fichier, on peut donc charger le contenu de la mémoire du SPE avec du code et des données. Je trouve ça assez amusant comme fonctionnement ;-)
Voilà, ce sera tout pour l'actualité du noyau. N'hésitez pas à poster vos remarques et suggestions dans les commentaires, en particulier sur ce qui vous a intéressé ou pas intéressé. On sait jamais, peut-être que je trouverais le temps de faire d'autres résumés de temps à autre.
