Actualité du noyau #2
Le résumé de l'actualité du noyau de la semaine dernière semblant avoir été apprécié par quelques lecteurs, j'ai essayé de faire de même pour cette semaine. Malheureusement, je me rends compte que je n'aurai certainement pas le temps de continuer toutes les semaines. Peut-être faudrait-il monter un site communautaire francophone où plusieurs rédacteurs pourraient se partager la tâche. D'un autre coté, est-il vraiment nécessaire d'avoir quelque chose de plus que
LWN ou
KernelTrap ?
Cette semaine:
- Ram Pai a posté un jeu de patches important implémentant les VFS Shared subtrees. Une des parties du patch est une documentation, expliquant de quoi il s'agit. Cette fonctionnalité était en discussion depuis plusieurs mois, puisque déjà en janvier 2005, Al Viro avait résumé la sémantique des différentes opérations par rapport aux shared subtrees.
Depuis le noyau 2.5, il est possible sous Linux de mettre en place des
per-process namespace, c'est-à-dire d'offrir aux
process des visions différentes de l'espace de nommage (l'arborescence des fichiers). Comme l'explique
Jonathan Corbet, le concept vient du système d'exploitation
Plan 9 (voir également
ce papier).
Par ailleurs, depuis les noyaux 2.4, on peut utiliser l'option --bind de la commande mount qui permet de remonter une partie de l'arborescence à un autre endroit de l'arborescence.
Néanmoins, comme l'explique Ram Pai,
les montages «bind» et les espace de nommage sont statiques par nature. Ils créent un snapshot des points de montage courants. Cependant, tous les nouveaux montages et démontages réalisés dans le point de montage originel ne seront pas répercutés dans le nouveau point de montage. Les «shared subtrees» rendent les montages «bind» et les espaces de nommage dynamique par nature. Les montages et les démontages réalisés sous n'importe lequel des réplicats sont répercutés dans les autres. Le développeur annonce dans son courrier électronique que cette fonctionnalité est attendue par des projets tels que
FUSE (systèmes de fichiers en espace utilisateur),
SeLinux (Security-Enhanced Linux, développé par la NSA), MVFS (multiversions file system, un système de fichiers développé par IBM, et visiblement utilisé par le système de gestion de version propriétaire ClearCase) et
autofs (mécanisme permettant le montage automatique).
Ram Pai distingue 4 types de montages, pour lesquels il donne des exemples dans sa documentation:
- les montages partagés ou shared mounts, qui propagent les nouveaux montages et démontages dans tous les réplicats ;
- les montages esclaves ou slave mounts, qui fonctionnent comme les montages partagés, sauf que les montages/démontages réalisés au sein du montage esclave ne sont pas propagés au montage parent ;
- les montages privés ou private mounts sont les montages classiques que nous connaissons. Il n'y a pas de propagation des nouveaux montages et démontages dans les réplicats ;
- les montages inclonables ou unclonable mounts, qui sont des points de montage qu'on ne peut répliquer.
La documentation donne beaucoup d'autres détails: elle précise la sémantique de toutes les opérations par rapport aux différents types de montage, elle donne plusieurs cas d'utilisation, et propose même un Quiz pour permettre au lecteur de tester sa compréhension de la chose ;-)
Le patch lui-même, découpé en 10 parties, touche bien évidemment le coeur du VFS, en particulier fs/namespace.c et ajoute un nouveau fichier fs/pnode.c.
- La semaine dernière, nous évoquions le processus de développement des versions 2.6.x.y, mené par Chris Wright. Celui-ci avait alors proposé une liste de patches pour la version 2.6.13.2, et avait invité les autres développeurs à lui soumettre des patches avant « Sat Sep 17 01:00 2005 UTC ». Et effectivement, le 17 septembre à 1h20 UTC, il a livré cette version 2.6.13.2, contenant 8 correctifs, dont aucun ne concerne un problème de sécurité. Le processus de construction de ces versions stables semble être bien rodé.
- Le déménagement de master.kernel.org à Open Source Lab de l'Université de l'Oregon a été annoncé et réalisé par avion privé. Visiblement, ce déménagement a un peu affecté la sortie de la version 2.6.14-rc2: les arbres git ont mis plusieurs heures à se répliquer, et les tarballs et patchs officiels ont mis plusieurs jours après l'annonce de la sortie de la version par Linus Torvalds pour être disponibles. KernelTrap parle également de ce déménagement.
- Hans Reiser, récemment interviewé sur KernelTrap a une nouvelle fois demandé l'inclusion de ReiserFS 4 dans le noyau. Cette demande a déjà été effectuée à plusieurs reprises, mais à chaque fois les développeurs du noyau n'étaient pas prêts à intégrer ce nouveau système de fichiers. Au début, c'est la fonctionnalité d'avoir des fichiers se comportant comme des répertoires afin d'accéder à des méta-données qui a posé problème, car cela semblait mal s'accorder avec la sémantique de certaines opérations sur les fichiers. D'autre part, ReiserFS dispose d'un propre mécanisme de plugin que les développeurs du noyau aimeraient mieux voir intégré de manière générique au VFS. Mais dans ce nouveau fil de discussion consacré à ReiserFS, c'est plutôt le style de code qui a été discuté. Comme dans toutes les discussions avec Hans Reiser, le débat a été très houleux, mélangeant des attaques personnelles et quelques arguments techniques semblant parfois assez faibles. Extraits choisis:
- Christoph Hellwig, chargé de la relecture du code des systèmes de fichiers: « additinoal comment is that the code is very messy, very different from normal kernel style, full of indirections and thus hard to read. », Hans Reiser répond: « Most of my customers remark that Namesys code is head and shoulders above the rest of the kernel code. So yes, it is different. »
- Denis Vlasenko: « This is it. I do not say "accept reiser4 NOW", I am saying "give Hans good code review". », Christoph Hellwig répond: « After he did his basic homework. Note that reviewing hans code is probably at the very end of everyones todo list because every critizm of his code starts a huge flamewar where hans tries to attack everyone not on his party line personally. ».
- Hans Reiser répondant à Christoph Hellwig: « Hellwig, people who write slow file systems should not lecture their measurably superiors on how to code. [...] If you were as well suited to doing code reviews as I am, you would have written a faster file system yourself. Anybody can find things to fix in someone else's code, and it can go on for years if they want it to. I could get what you do from hiring a college junior, and if it was a good university I'd probably learn more from that junior in college than from you. We are doing work, and you are getting in the way. Nobody who wants reiser4 views your contributions as the least bit positive. ». Et également « Reiser4? works just fine without Christoph. Users are happy with it. None of them have asked for his help. I don't consider Christoph to be qualified to work on our filesystem. I would not hire him if he applied - he is not capable of innovative work. »
Bref, on voit bien que les attaques personnelles sont légion, et que la personnalité d'Hans Reiser n'arrange pas les choses. Certains ont même suggéré qu'une autre personne de la société Namesys (gérée par Hans Reiser) s'occupe de dialoguer avec les développeurs du noyau en ce qui concerne l'incusion de ReiserFS. KernelTrap
propose également un résumé de la situation.
- Suite à l'article de la semaine passée concernant l'utilisation d'outils d'analyse statique de code, Christophe Lucas m'a fait remarquer que sparse et le standford checker étaient utilisés par de nombreuses personnes du projet Kernel Janitors, dont l'objectif est « go through the linux kernel sources, doing code reviews, fixing up unmaintained code and doing other cleanups and API conversion. It is a good start to kernel hacking. ». Sur le même sujet, David Mentré m'a indiqué l'adresse d'une liste d'outils de vérification formelle de code, qui comprend une section consacrée aux outils aidant à la vérification de « programmes réels ». Il y mentionne Why, CIL, Splint, CQual, CCured, Chic, Smatch, Sparse et Focal.
- Soeren Sandman a annoncé Sysprof 1.0, « a sampling, systemwide Linux profiler ». Sysprof prend la forme d'une module noyau, qui permet de profiler tous les processus en exécution. Une interface graphique simple permet de visualiser le temps passé dans chaque branche du graphe d'appel. Un des points mis en avant par le développeur est sa simplicité d'utilisation.
Plusieurs développeurs se sont montrés sceptiques, indiquant que cela ressemblait ni plus ni moins à ce que fait déjà
O'Profile. Pour défendre son outil, Soeren a
avancé plusieurs arguments: OProfile ne fonctionne pas en SMP, OProfile ne peut pas extraire de graphe d'appel sans recompiler le noyau, et OProfile dispose d'une interface graphique difficile à comprendre. Il a donc de nouveau mis en avant la simplicité de mise en oeuvre de son outil, mais ses arguments face à OProfile semblent un peu léger: il aurait sans doute été plus simple et plus constructif de contribuer à cet outil existant.
Les autres développeurs ont persisté à demander pourquoi avoir réimplémenté OProfile, et Soeren
a indiqué que le module noyau ne représentait que 296 lignes, et que ce n'était pas vraiment ce qui l'intéressait, mais plutôt le code d'analyse et l'interface graphique.
Certains ont donc suggéré de brancher l'interface graphique et le code d'analyse de
sysprof sur le module noyau
OProfile. Une discussion
a alors été démarrée sur la liste d'OProfile.
- Au cours de mes lectures de la LKML, je suis tombé sur un bug sympathique. Des utilisateurs de systèmes bi-Opteron ont reporté avoir des problèmes de Segmentation fault aléatoires, le genre de bug pas très sympathique. Au départ, c'est la fonctionnalité de « randomization » de l'espace virtuel qui a été incrimée, puisque le problème ne se produisait plus lorsque cette fonctionnalité était désactivée à l'aide de echo 0 > /proc/sys/kernel/randomize_va_space. Plusieurs utilisateurs ont indiqué que cela corrigeait le problème, et les recherches se sont orientées dans cette direction. Toutefois, un peu plus tard, un utilisateur a reporté avoir réussi à reproduire le problème, même avec la « randomization » désactivée. Un membre de l'équipe de PaX a alors résumé les diverses hypothèses plausibles. Et finalement, Linus Torvalds, qui n'était jamais intervenu sur ce bug, est arrivé avec un patch qui désactive une fonctionnalité des processeurs Opteron, car celle-ci est buggée dans les systèmes multi-processeurs ("TLB Flush Filter causes coherency problem in multiprocessor systems"). J'ai trouvé particulièrement intéressant de suivre le cheminement allant de la constatation du bug jusqu'à la découverte de l'origine du problème.
- Con Kolivas a annoncé plusieurs versions de son patch swap prefetch, la dernière annoncée étant la version 11. Ce patch implémente le swap prefetching, c'est à dire le fait d'aller chercher des données dans le swap avant qu'elles ne soient réellement nécessaires. Ce prefetching a lieu lorsque le sous-système de gestion de mémoire virtuelle ne fait pas grand chose et que de la mémoire physique est disponible. Voici un petit descriptif du fonctionnement de la bête, traduit du courrier électronique de Con Kolivas:
Le patch permet de maintenir une liste des pages swappées, dans une liste ordonnée de la plus récemment utilisée à la moins récemment utilisée et dans un
radix tree, une structure de donnée que nous avons
évoqué dans le compte-rendu d'une conférence du Linux Symposium 2005 concernant les performances du
page cache. En plus de ceci, le patch créé un thread noyau de faible priorité qui sera chargé d'effectuer le préchargement.
Une fois que des pages ont été ajoutés à la liste des pages swappées, un timer est démarré, testant toutes les 5 secondes si certaines conditions sont réunies pour permettre le préchargement de pages swappées. Les conditions sont relativement complexes (pas de déplacement de pages vers ou depuis le swap en cours, peu de mémoire « sale », une quantité suffisante de mémoire libre disponible, etc.), mais lorsqu'elles sont réunies, le thread va récupérer 128 Kb de données du swap toutes les secnodes, jusqu'à ce que les conditions précédemment listées ne soient plus valides. Les pages sont copiées en mémoire, mais sont conservées sur le disque, de manière à ce qu'elles puissent être libérées sans réaliser d'entrées-sorties si cela est nécessaire.
D'après Con Kolivas, ce patch améliore nettement le temps de chargement des applications qui ont été complètement swappées.
- Junio Hamano, le nouveau mainteneur de Git, a annoncé la sortie de la version 0.99.7. Certaines commandes ont été renommées pour plus de cohérence, et une commande git merge a été ajoutée, permettant d'utiliser d'autres algorithmes de merge que le classique three-way merge.
« Not a whole lot o' excitement, ye scurvy dogs, but it has t' ALSA, LSM, audit and watchdog merges that be missed from -rc1, and a merge series with Andrew. But on t' whole pretty reasonable - you can see t' details in the shortlog (appended). »
Comme prévu donc, pas de nouvelles fonctionnalités, seulement des correctifs. Comme je le disais plus haut, le déplacement de master.kernel.org a entraîné un délai assez important entre le moment où Linus a annoncé la sortie de cette version, le moment où elle était disponible via GIT et le moment où elle était disponible via kernel.org. Pour ma part, ce nouveau noyau tourne sur ma machine depuis 4 jours, sans que j'ai noté de problèmes particuliers.
- Andrew Morton a annoncé 2.6.14-rc2-mm1. Cette branche -mm est en quelque sort le bac à sable des nouveaux patches: Andrew Morton y intègre quasiment tout ce qui passe sur la liste, ce qui permet de tester de manière un peu plus intensive de nouvelles fonctionnalités ou de nouveaux correctifs. Une fois que les patches sont intégrés à la version officielle, Andrew les retire de sa branche -mm et sort une nouvelle version basée sur la nouvelle version officielle du noyau. Dans un prochain billet, j'évoquerai Quilt, l'outil développé à l'origine par Andrew Morton pour gérer des patches.
- Un certain John Richard Moser a proposé sur la liste une idée d'implémentation pour une fonctionnalité de « Hot-patching », qui permettrait de patcher un noyau binaire sans redémarrer la machine, en insérant des modules noyau contenant du code noyau qui ira remplacer le code noyau en exécution. Cette fonctionnalité avait déjà été discutée et de nombreux commentaires avaient été faits. La discution sur cette nouvelle proposition n'a donc pas été très loin. Un développeur a fait remarquer que ce n'est pas simple, puisque si les correctifs binaires introduisent un nouveau champ dans une structure ou de nouveaux bits d'état, alors ça ne pourra pas fonctionner.
- Thomas Gleixner a annoncé un patch contenant un nouveau sous-système pour la gestion du temps. N'étant pas un spécialiste du domaine de la gestion du temps, je n'apporterai pas plus que l'excellent descriptif réalisé dans son courrier électronique, ni à l'article de Jonathan Corbet publié sur LWN, dont je vous recommande la lecture. Le lecteur intéressé par le sujet pourra également lire le papier « We are not getting any younger. A new approach to time and timers » publié au Linux Symposium 2005 et disponible page 227 du premier volume des proceedings.
- Enfin, pour terminer, je voulais parler d'un petit outil fort pratique: Ketchup. Développé par Matt Mackall, également développeur de Mercurial, il s'agit d'un outil permettant de récupérer ou de mettre à jour ses sources du noyau Linux. Une page du Wiki donne quelques exemples d'utilisation. En se plaçant dans votre arbre des sources du noyau, vous pourrez le mettre à jour vers n'importe quelle version, que ce soit la dernière version officielle ou une branche -mm, -rc ou autre. Ainsi, si vous êtes en 2.6.10, plutôt que de retélécharger complètement une version 2.6.13.2, il suffit de faire ketchup 2.6-tip, et ketchup va récupérer et appliquer automatiquement les patches 2.6.10 -> 2.6.11, 2.6.11 -> 2.6.12, 2.6.12 -> 2.6.13 et 2.6.13 -> 2.6.13.2. Simple, mais fort sympathique !
La suite au prochain numéro !
