Jour 4, Samedi 23 Juillet: Conférences

Le samedi, dernier jour de conférences, avec moins de présentations que les autres jours : la première démarre à midi, et la dernière termine à 18h, sans ateliers en soirée après le repas.

NPTL Stabilization project

Ce sont deux français de chez Bull, Tony Reix et Sébastien Decugis, qui ont présenté le NPTL Stabilization project. En réalité, mon collègue et moi avions déjà rencontré Sébastien Decugis les jours précédents, il était venu avec nous au spectable son et lumière du Parlement. Cela nous a permis d'apprendre que Bull était une société toujours vivante, et que près de 400 développeurs travaillaient à Grenoble dans le département Recherche et Développement. En réalité, je savais déjà que Bull travaillait sur NPTL et sur NFSv4, mais je ne savais pas qu'il y avait encore autant de R&D. Bonne nouvelle, car nous manquons de grandes entreprises européennes dans le domaine de l'informatique !

NPTL, Native POSIX Thread Library est la nouvelle bibliothèque de thread remplaçant LinuxThreads. Le projet de stabilisation de Bull a pour objectifs de réduire le nombre de bugs dans cette bibliothèque, d'augmenter la couverture des tests, de rendre les tests plus simples à réaliser, et de permettre de tracer les évènements ayant lieu au sein de la bibliothèque.

Tests

Pour la partie test, ils ont tout d'abord analysé des logiciels utilisant la NPTL, comme Apache, Squid ou des applications HPC (High-Performance Computing). À partir de cette étude, ils ont classé les primitives de la NPTL en 4 sous-ensembles: les fonctions complexes et très utilisées (threads, mutexes notamment), les fonctions complexes moins utilisées (semaphores, conditions), les primitives peu utilisées (barrières) et les primitives très simples (attributs, appels systèmes). Cette classification a permis de déteminer les priorités sur les groupes de fonction à tester.

L'ambassade des États-Unis

Pour implémenter leurs tests, ils ont utilisé la méthode du projet Open Posix Test Suite. Pour chaque primitive, ils ont tout d'abord étudié le standard POSIX afin de déteminer quelles sont les caractéristiques et les assertions que doivent vérifier chaque fonction. Pour certaines primitives, des clarifications ont été demandées afin que les prochaines versions de la norme soient plus précises. Ils ont donc écrit des tests de trois types : des tests de conformité (vérifier que la norme est respectée), des tests de scalabilité (mesurer le temps d'exécution d'une primitive) et des tests de stress. Ils ont détaillé sur leur forum leurs travaux fonction par fonction. Ces nouveaux tests ont été soumis au projet Open Posix Test Suite.

Pour faciliter l'analyse du résultat des tests, l'équipe de Bull a développé un outil appelé TSLogParser. Il s'agit d'une interface Web en PHP utilisant une base de données MySQL dans laquelle les résultats de tous les tests sont enregistrés. Grâce à cet outil, il est possible de comparer différentes exécutions de la suite de tests, voir quels tests ont réussi alors qu'ils échouaient avant et vice-versa. Cet outil est disponible sous licence GPL.

Grâce à ces tests, ils ont trouvé 22 bugs dans la Glibc, un bug dans le noyau, et 6 problèmes de clareté de la norme POSIX.

Outil de trace

Lorsque l'on développe des applications multi-threadées, on fait souvent face à des bugs assez délicats à résoudre, car ils sont liés à l'exécution en concurrence de plusieurs threads. De plus, l'ordonnancement des threads changeant à chaque exécution, les bugs disparaissent et apparaissent, rendant le déboguage cauchemardesque pour le développeur. D'autre part, le standard POSIX concernant les threads est assez délicat à comprendre, ce qui rend l'utilisation des bibliothèques comme NPTL peu aisée.

Pour aider le développeur, l'équipe de Bull a développé un outil permettant de tracer tous les évènements ayant lieu à l'intérieur de la bibliothèque NTPL. L'outil s'appelle PTT, Posix Thread Trace Tool, et est disponible sous licence LGPL sur SourceForge.
Le but est donc d'enregistrer les opérations de la bibliothèque au niveau de l'application et éventuellement d'enregistrer les appels internes de la NPTL. L'outil ne modifie pas le comportement de l'implication, et a un impact limité sur les performances. Il permet de réaliser des exécutions longues et de récupérer un grand volume de traces, sans en perdre.

L'outil se base tout d'abord sur une NPTL patchée à divers endroits pour intercepter les divers évènements (exécution d'un thread, prise d'un objet de synchronisation, etc.). Les traces sont enregistrées dans un buffer qu'un démon vient récupérer périodiquement. Le démon génère alors un fichier binaire, qui est exploitable soit au travers d'une interface en ligne de commande, soit au travers d'une interface graphique préexistante, Pajé. Le site de PTT donne un exemple, ainsi qu'une capture d'écran de Pajé. Les deux présentateurs ont réalisé une démonstration vraiment convaincante de cet outil: on visualise vraiment avec précision tout ce qu'il se passe, les prises de sémaphores, de mutex, l'ordonnancement des threads, etc.

À l'heure actuelle, PTT utilise un buffer par application. L'algorithme d'ajout d'une trace consiste à 1) réserver de l'espace dans le buffer de manière atomique, 2) écrire les données de la trace (de manière concurrente) et 3) marqué l'espace comme écrit de manière atomique. Cet algorithme est simple, robuste et efficace sur SMP. En revanche, il n'est pas suffisamment scalable sur des machines plus grosses, et le démon de récupération des traces peut de temps à autre bloquer les threads. L'amélioration de la scalabilité du système fait partie des évolutions à venir de l'outil.

Actuellement, PTT propose trois niveaux de trace: pas de trace, des traces seulement en entrée et sortie des primitives de la NPTL ou les traces complètes. Lorsque l'on utilise la NPTL patchée pour PTT, mais sans les traces, l'impact est minime (de l'ordre de 2%). Si l'on utilise les traces complètes sur une application à 128 threads, l'impact est plus important, de l'ordre de 25%.

Pour l'avenir de l'outil, les deux présentateurs ont parlé de :

• intégrer dans de plus nombreuses distributions (actuellement Debian, Fedora Core 3 et 4), et surtout intégration dans la Glibc (de manière à ne plus avoir besoin de patcher la NPTL)
• améliorer la scalabilité sur SMP et NUMA
• mettre des points de trace dans toutes les routines de la NPTL
• nommer les objets NPTL en récupérant des informations du code source. En effet pour l'instant, les sémaphores, mutexes et threads sont nommés “Mutex 1”, “Semaphore 3”, etc. ce qui est peu pratique
• disposer de timestamps pour les machines NUMA
• ajouter un mécanisme pour mesurer la contention (sur les sémaphores, les mutexes, etc.)
• ajouter des tests de conformité POSIX de l'application, pour déterminer si la NPTL est correctement utilisée par l'application

Globalement, la présentation était plutôt convaincante. Le travail de test réalisé donne vraiment une impression de rigueur, et a permis de trouver quelques bugs. L'outil de trace, PTT, a l'air réellement utilisable et peut sans doute vraiment aider le développeur d'une application multithreadée.

Mercurial Tutorial

Le samedi matin, dans la petite salle réservée aux tutoriels, un tutoriel sur l'API NetPoll était prévu, ce qui m'intéressait moyennement. Finalement, à la sortie de la conférence sur NPTL, le programme avait été modifié, et c'est un atelier sur Mercurial qui avait lieu. Mon collègue et moi y sommes quand même allés, bien que nous ayons raté la première heure. J'ai trouvé un peu dommage d'avoir raté le début, car c'est vraiment un outil que j'aurai aimé maîtriser.

Une vue d'Ottawa depuis Gatineau, au Québec

Pour ceux qui ne connaissent pas, Mercurial est un système de gestion de version distribué, comme Monotone, Arch, Svk, Darcs ou bien d'autres listés sur Wikipédia. À l'opposé de Subversion ou CVS, les systèmes de gestion de version centralisé dans lesquels toutes les opérations se réalisent à partir d'un dépôt unique des sources, les systèmes de gestion de version distribués permettent de créer de multiples dépôts, un peu partout. Cette propriété est vraiment intéressante lorsque l'on est plusieurs à travailler sur un projet, de manière décentralisée.

Le soucis, c'est que les outils sont très nombreux et je n'ai jamais donc décidé d'en tester un. D'autre part, les concepts sont un peu plus évolués que pour la gestion centralisée, et je n'avais pas eu le temps de me pencher sur la question. Un tutoriel sur un de ces outils était donc le bienvenu... mais j'ai du prendre le train en route.

L'orateur semblait être un des développeurs de Mercurial, et maîtrisait vraiment bien les outils, ses possibilités, ses limitations et les idées de développement futures. Lorsque nous sommes arrivés dans la salle, c'est surtout des échanges entre l'orateur et le public qui avaient lieu, mais ces échanges étaient constructifs et amenaient l'orateur à faire quelques démonstrations intéressantes.

Je ne vais pas détailler ici l'utilisation de Mercurial, car j'aimerais faire plus tard un billet plus complet sur son utilisation. En attendant, vous pouvez aller faire un tour du coté du tutoriel disponible sur le Wiki de Mercurial.

Précision importante: je ne soutiens aucunement que Mercurial soit LE système de gestion de version distribué. C'est simplement que c'est celui qui a été présenté. Peut-être que Darcs, Svk, Monotone ou d'autres sont plus aboutis, plus simples à utiliser, je ne sais pas. Vous pouvez aller faire un tour du coté de cette comparaison des différents système de gestion de version (centralisé ou distribué)... mais il n'y a pas Mercurial ;-)

The sysfs filesystem

Patrick Mochel avec sa jambe dans le plâtre a réalisé une présentation de sysfs.

Sysfs est un système de fichiers basé sur ramfs qui offre une interface utilisateur/noyau simple. Il permet de rendre visible à l'utilisateur différents objets du noyau, leurs attributs et leurs relations. Il est organisé selon une hierarchie stricte et offre une vue toujours à jour des objets. Tous les fichiers sont au format ASCII avec une valeur par fichier. Ces fichiers sont créés dynamiquement, et le système est prévu pour fonctionner avec les modules (chargement et déchargement) et pour fonctionner correctement en multi-thread.

Historiquement, le projet se nommait au départ ddfs, dont l'objectif était de permettre à l'utilisateur de visualiser l'arbre des périphériques disponibles sur la machine. À mesure que le modèle des pilotes de périphérique s'enrichissait, il est apparu nécessaire de pouvoir visualiser les bus, les classes de périphériques ainsi que les pilotes. À ce moment là, le projet s'appelait driverfs.

Finalement, d'autres sous-systèmes ont été intéressés par cette approche: driverfs ne servait plus seulement à représenter des périphériques, mais également des objets d'autres sous-systèmes. Il a alors été renommé sysfs, son nom actuel.

Dans le noyau, dès lors qu'une structure de type struct kobject est enregistrée, un répertoire apparaît dans sysfs. Ainsi dans sysfs, les répertoires représentent les objets du noyau, les fichiers représentent les attributs de ces objets et les liens symboliques représentent les relations entre les objets.

Prenons un exemple: mon interface réseau eth0. Dans /sys/class/net/eth0/, on trouve différents fichiers reprenant les propriétés de l'interface comme par exemple l'adresse MAC (dans /sys/class/net/eth0/address). On trouve également deux liens symboliques: device, qui pointe vers le périphérique PCI qui est en réalité la carte réseau utilisée pour l'interface eth0, ainsi que driver qui pointe vers le module noyau gérant cette carte PCI: 8139too :


Sysfs a été intégré au noyau dès le 2.5.1 et est requis par udev. Il est également utilisé par lspci, cpufreq ou la modification des paramètres des périphériques bloc.

Patrick a ensuite listé quelques-uns des apports de sysfs :

• Facile à utiliser pour les sous-systèmes
• Facile à utiliser pour les applications utilisateur
• Une porte ouverte à d'autres projets, tels que debugfs ou configfs
• Sain d'un point de vue conceptuel

En revanche, Patrick a noté un certain nombre de problèmes :

• la structure kobject est un peu un bazar, mais je n'ai pas retenu ses arguments exacts et le papier ne semble pas en parler
• il trouve parfois problématique qu'il faille systématiquement un kobject pour chaque répertoire
• il trouvé également que sysfs est difficile à utiliser dans sa forme la plus simple, ce qui me semble contradictoire avec ses précédents dires, mais je n'ai peut-être pas tout compris
• du point de vue de l'accès par les applications utilisateur, Patrick regrette qu'il n'existe pas encore de bibliothèque correcte (libsysfs ne semble pas lui donner entière satisfaction) ou d'outils pour visualiser et manipuler les entrées de /sys. D'autre part, il pense que l'approche n'est pas humainement scalable: les informations dans sysfs sont très nombreuses et il y en aura de plus en plus. Enfin, il a mentionné le problème de l'absence de verrouillage de type transactionnel.

Dans le futur, le développeur aimerait répondre aux attentes de catégories spécifiques d'utilisateurs :

• les utilisateurs de systèmes embarqués qui n'ont pas besoin de sysfs
• les utilisateurs de clusters qui aimeraient bien avoir un sysfs agrégé entre tous leurs noeuds
• les utilisateurs de virtualisation, qui aimeraient bien pouvoir accéder depuis l'OS client à des propriétés de l'OS hôte

À la fin de cette présentation, le développeur de sysfs a donné une liste des tâches à réaliser, en les classant en niveau de difficultés. Je n'ai pas noté ces tâches, mais il semblerait qu'il y ai des choses à faire et à améliorer du coté de sysfs.

À noter que le papier de Patrick Mochel ne résume pas exactement sa conférence: il s'agit plus d'un guide de programmation sysfs, qui peut être une documentation très intéressante si vous avez besoin de bricoler avec ce système de fichiers.

Sur la forme, la présentation de Mochel était très vivante, ponctuée de quelques blagues. Le genre de conférences auquel on s'intéresse même si a priori le sujet ne vous passionne pas forcément.

Keynote Address

J'ai rédigé le compte-rendu de cette conférence près d'un mois après l'évènement, et j'avais seulement pris quelques notes. Je regrette un peu de ne pas l'avoir fait plus tôt, car il va manquer beaucoup d'informations sur cette conférence passionante. Il y a quelques jours, j'ai demandé à l'orateur si il avait prévu de mettre ses transparents en ligne, j'espère qu'il pourra le faire.

Andrew Morton et Dave Jones

La Keynote Address est la dernière conférence du symposium, elle est l'unique conférence programmée à ce moment-là, et clotûre le congrès. Une tradition veut que l'orateur de la Keynote de l'année précédente introduise l'orateur de cette année, et qu'à la fin de la Keynote soit annoncé l'orateur de l'année suivante.

Cette année, c'est Andrew Morton, le mainteneur de la très importante branche -mm du noyau qui introduisait l'orateur. C'est donc au milieu d'un concentré de blagues et de jeux de mots relativement incompréhensibles pour un francophone moyen qu'il a introduit Dave Jones. Dave Jones est le mainteneur des noyaux des distributions RedHat. Sa présentation était sous-titrée « The need for better bug reporting, testing, and tools », ce qui laissait présager une conférence très intéressante.

Il a commencé par une petite introduction avec des citations assez amusantes. Tout d'abord :
c'est ce que lui avait dit son professeur d'informatique une quinzaine d'années auparavant. Comme il l'a dit: « Tout le monde peut se tromper ». Et il poursuit avec 6 ou 8 citations de Linus. Ça commence en 1996, avec Linus qui dit que bientôt, plus rien d'excitant ne se passera au niveau du noyau, que ce sera devenu une commodité sans intérêt. Et Dave continue en citant Linus, au fil des années, de 1997 à 2005, on voit sa position qui évolue, pour finalement arriver à dire complètement l'inverse de ce qu'il avait dit 10 ans plus tôt : il se passe des choses excitantes au niveau du noyau aujourd'hui. « Tout le monde peut se tromper ». Le travail des recherches des citations est impressionant, et la façon de les amener une à une rendait la chose vraiment amusante.

Ensuite, il a plus sérieusement entamé sa présentation, visant à détailler en quoi le mode de développement du noyau affecte RedHat et la maintenance de ses noyaux. C'est donc un point de vue un peu différent de celui d'un développeur noyau pur qu'a donné Dave Jones pendant ce keynote.
Le première problème qu'a évoqué Dave est le problème des interfaces qui changent entre deux versions du noyau (même des versions “mineures”). Par exemple, l'interface ALSA a changé en 2.6.11, il y a des problèmes avec l'interface Ipsec ou l'interface pour le wireless. Ces changements d'interface multiplient les problèmes que peuvent rencontrer les utilisateurs.

Le second problème évoqué est celui des drivers, pour lesquels il n'y a pas suffisamment de test de regression selon Jones. Il a souvent rencontré des cas de drivers qui fonctionnaient, puis qui subitemment ne fonctionnent plus, sans que personne ne s'en soit aperçu. Comme il l'a expliqué, le soucis c'est que les drivers sont très difficiles à tester, car cela nécessite d'avoir le matériel disponible, et ce type de test prend beaucoup de temps. Ainsi, lorsqu'il y a un changement de l'API interne du noyau qui nécessite des modifications dans les drivers, les modifications sont réalisées à l'aveugle: on modifie le driver, on vérifie que ça compile... et on ne teste pas, parce que le matériel n'est pas disponible. Il a également indiqué que la vitesse d'intégration des patches s'était accrue pour atteindre parfois 4000 changesets par mois, et que certains n'étaient sans doute pas relus.

À l'heure actuelle, des tests de stress, des fuzz tests et des tests de performances sont réalisés sur le noyau, mais il n'y a pas de tests de régression, de tests des chemins de traitement d'erreurs ou des tests de couverture de code. D'après Jones, trop peu de gens testent les versions -rc des noyaux, et du coup, les problèmes ne sont remontés par les utilisateurs que lors de la sortie de la version officielle.
À propos de la remontée des problèmes par les utilisateurs, Dave Jones dispose d'une bonne expérience, puisqu'il doit gérer tous les bugs remontés sur les noyaux de la distribution RedHat. Durant la conférence, il a dressé un profil psychologique assez amusant de quelques reporteurs d'anomalies :

• il y a ceux qui croient que leur bug est le plus important. Pour cela, Jones aimerait bien disposer d'une priorité “privée” et d'une priorité visible seulement par l'utilisateur, pour lui faire croire que son bug est bien classé en priorité haute
• il y a ceux qui ne disent pas la vérité, par exemple mentent sur les modules chargés ou pas
• il y a ceux qui ne répondent pas aux demandes d'information, et reviennent en râlant violemment lorsque le bug est fermé
• il y a ceux qui donnent pas d'informations ou de fausses informations sur le problème
• il y a ceux qui ne veulent pas mettre à jour pour corriger le problème

Pour donner une idée du problème, Jones a donné quelques chiffres pour la Fedora Core 2. Il restait 612 bugs sur la Fedora Core 2 concenrant le noyau. Dave les a tous fermés en demandant si le problème était toujours présent, seuls 10 bugs ont été réouverts. Pour donner un ordre d'idée, il avait le jour de la conférence environ 960 bugs concernant le noyau sur Fedora Core 3 et 4.

D'expérience, Dave Jones a pu dire que la plupart des bugs rencontrés sont des bugs upstream, c'est-à-dire qu'ils ne sont pas liés au packaging, mais qu'ils sont bien présents dans le noyau lui-même. Il y a alors de grandes chances que les utilisateurs des autres distributions rencontrent les mêmes problèmes.

Dans le cas où le bug concerne upstream, le processus pour partager le bug est manuel, mais Dave Jones aimerait bien un système où les bugs pourraient être remontés automatiquement upstream, tout en gardant l'historique du bug. Bref, des Bugzilla qui communiquent, par exemple avec XML-RPC.

La salle est comble pour ce keynote

C'est intéressant, car c'est une problématique que j'avais déjà soulevé dans un billet au mois de janvier, et j'en avais reparlé un peu plus tard, car Canonical, la société derrière Ubuntu avait lancé un projet appelé Malone, qui est justement un bug-tracker collaboratif. C'est une problématique qui a également été discutée récemment au sein de Debian, comme l'évoque les nouvelles hebdomadaires du 16 août. Ce débat a fait suite à l'affichage d'un message lors du report d'une anomalie sur Mozilla Firefox. Ce message indiquait que dans le cas d'une anomalie non liée au packaging, il fallait reporter soi-même l'anomalie dans le Bugzilla de Mozilla et dans le bugtracker de Debian. Le débat montre que le problème de communication des bugs entre le niveau “distribution” et le niveau “upstream” existe bien, et que des outils comme Malone seraient nécessaires. Quid de leur mise en place ?

Personnellement, J'ai fait part par courrier électronique de l'existence de Malone à Dave Jones puisque cela semblait répondre à ses besoins, mais je n'ai jusqu'ici pas eu de réponse. Mon courrier électronique a vraisemblablement dû se perdre dans les milliers de bug-reports qui doivent innonder sa boîte aux lettres.

Dave Jones, très en contact avec les utilisateurs par son travail de mainteneur, a noté que l'utilisation des drivers binaires étaient en baisse, mais que l'utilisation de helpers comme ndiswrapper, ndisulator ou driverloader. Pour Dave Jones, l'utilisation de ce type de solutions est contre-productif. D'un coté, ça incite moins les développeurs à développer des pilotes libres, et de l'autre coté, ça dilue le message qu'on essaie d'envoyer aux constructeurs en demandant la publication des spécifications ou des pilotes libres. Malheureusement, les distributions commencent à distribuer en standard ce type d'outils, dont l'utilisation risque de se généraliser.
Dans la dernière partie de sa présentation, Dave Jones a dit qu'il trouvait nécessaire de disposer de plus d'outils de tests, et de les utiliser plus massivement. Il pense par exemple à valgrind, oprofile ou à l'analyse statique de code. D'après Dave, Le problème avec l'analyse statique de code, c'est que les outils comme lclint/splint ne marchent pas out-of-the-box et du coup, personne ne les utilise. De plus, lclint génère beaucoup de faux-positifs, Dave citant l'exemple d'un code de 43.000 lignes générant 50.000 lignes de sortie lclint. Il y a beaucoup de travail manuel à réaliser qui complique l'utilisation de lclint et rebute les développeurs. L'autre outil d'analyse de code est sparse, développé par Linus, mais Dave trouve qu'il est encore trop complexe à utiliser. Il a bien évidemment cité les outils de Coverity qui ont détecté quelques vrais problèmes dans le noyau, mais Jones regrette que ces outils ne soient pas libres.

La soirée de cloture

Personnellement, j'ai trouvé cette conférence vraiment excellente: le point de vue d'un mainteneur, en contact avec les utilisateurs, est très intéressant, et montre qu'il y a beaucoup à faire pour améliorer les choses, aussi bien sur les tests que sur la gestion des anomalies. Même si mon compte-rendu ne rend peut-être pas bien compte de l'intérêt de cette conférence, j'ai trouvé que c'était l'une des plus intéressantes de tout le symposium.

Soirée de cloture

Le samedi soir avait lieu la soirée de cloture, dans un bar d'Ottawa. L'occasion de réunir tout le monde autour d'un bar ouvert (boissons gratuites à volonté). Comme toujours, ces pendants ces moments-là que des contacts se font, qu'on commence à discuter avec du monde. Ça m'a vraiment fait regretter de n'avoir pu aller à la première soirée, avant le symposium, car elle aurait permis de connaître un peu plus de monde dès le départ.
Cette soirée fût l'occasion de quelques discussions avec un développeur de LTSP, un ingénieur s'occupant des tests autour du noyau Linux chez IBM, d'un administrateur système norvégien ou d'un ingénieur en Linux embarqué du Canada.