Journée du 5 septembre

La session d'ouverture a été consacrée aux problèmes que rencontrent les mainteneurs des noyaux des diverses distributions. Tous les sujets ont été évoqués lors de cette discussion : Le long délai qui s'écoule entre la sortie d'une fonctionnalité en mainline et son intégration dans les noyaux des distributions d'entreprises, les rétroportages massifs rendus inévitables du fait du maintien par les distributions d'entreprise d'une interface binaire stable, etc. etc. Il a été rapporté que de plus en plus d'entreprises conduisent en interne des tests de non régression sur la branche principale du noyau afin de s'assurer une transition facile quand elles décideront de changer de version. Il serait souhaitable que ces tests s'effectuent également sur la branche expérimentale -mm. Le dernier sujet évoqué a été celui des pilotes de périphériques qui ne font pas partie de la branche principale. Peut-être que les exigences de qualité de Linux sont trop hautes ce qui provoque une perte de motivation de certaines entreprises qui renoncent à pousser leur pilote en mainline ? Quelle que soit l'explication, Linus Torvalds a exprimé l'idée que chaque fois qu'une entreprise distribue un pilote qui n'est pas intégré en mainline c'est un signe d'échec.

La session consacrée à la qualité du noyau a débuté avec les remarques acides d'Andrew Morton qui s'est demandé si le nombre de bugs augmentait ou diminuait avec chaque nouvelle version. Un développeur spécialement chargé de trier et router les rapports de bugs a été engagé par Google pour aider Andrew. Natalie Protasevich est donc en train de passer en revue les 1500 bugs ouverts qui existent dans le bugzilla du noyau. Le problème principal est que de nombreux rapports de bugs ne sont pas traités par les responsables des sous-systèmes concernés. Ted Ts'o a indiqué qu'il y a dix ans les développeurs du noyau prenaient beaucoup plus au sérieux les rapports de bugs et travaillaient vraiment pour aider les utilisateurs. Il lui a été répondu qu'il y a dix ans les utilisateurs de Linux possédaient un bagage technique plus important que maintenant et que les rapports de bugs étaient meilleurs (Alan Cox : Il y a dix ans chaque utilisateur avait un tournevis et la plupart d'entre eux n'avait pas de boitier entourant leur ordinateur).
La solution qui a été adoptée par les développeurs est d'augmenter la relecture du code avant qu'il n'intègre la branche principale. Un nouveau tag "relu par :" sera maintenant obligatoire pour avoir l'assurance qu'une relecture critique du code aura été effectuée avant intégration.

Une session spéciale a été dédiée aux divers sous-systèmes du noyau afin de présenter les conclusions de plusieurs mini-sommets. Len Brown a parlé de la mise en veille (suspend-to-RAM) pour conclure que la situation s'améliore mais qu'il manque des contributeurs et que quelqu'un doit prendre la responsabilité d'investir des ressources dans ce domaine. Parlant ensuite de l'hibernation (suspend-to-disk) Len a évoqué le projet TuxOnIce (anciennement Suspend2) qui n'est pas actuellement en mainline mais qui semble de meilleure qualité que le code actuel du noyau. Le mini-sommet sur la virtualisation s'est prudemment consacré à la question du support en mode invité (Guest mode) afin d'éviter les controverses entre les acteurs concurrents (VMware, Xen...) qui participaient à la discussion. Il a également été question du support des disques implémentant un système de fichier directement en matériel (object-based storage) et d'une technique permettant d'améliorer les allocations de mémoire.

L'écosystème général du noyau a été évoqué lors d'une session spécifique. Cela concerne tous les logiciels tournant en espace utilisateur mais indispensables au fonctionnement moderne de nos ordinateurs (udev, HAL, X, etc.). La difficulté d'utilisation et les fréquentes incompatibilités du système de fichier virtuel Sysfs ont été reconnues. Il est conseillé d'utiliser la couche d'abstraction HAL à la place. En ce qui concerne X, il est prévu d'intégrer les modes vidéos directement dans le noyau. Keith Packard a posté un texte expliquant les avantages de cette solution sur son blog. Enfin, l'ajout de nouveaux appels systèmes va être contrôlé encore plus sévèrement qu'avant et une partie des cas de tests du Linux Test Project va faire son entrée dans le noyau afin d'augmenter encore la robustesse du code.

La dernière session du 5 septembre a été consacrée au support matériel. Chris Schlaeger, le directeur du Operating System Research Center d'AMD, a annoncé l'ouverture des spécifications des cartes graphiques Radeon (R500 et suivantes). Cette annonce est liée au fait que les futurs processeurs d'AMD vont fusionner le c½ur graphique (GPU) avec le c½ur généraliste (CPU). Il serait donc absurde d'avoir un support du libre pour une partie et de maintenir le secret sur l'autre partie du processeur et cela condamnerait cette technologie. AMD va donc travailler avec la communauté pour développer un pilote 3D libre et va ainsi rejoindre Intel dans le camp des vendeurs de matériel aux spécifications ouvertes.

Journée du 6 septembre

La session des clients de Linux a vu l'intervention de trois orateurs qui ont expliqué l'utilisation qu'ils faisaient du noyau et les problèmes qu'ils rencontraient.

• L'intervenant de Dreamworks a indiqué que le rendu des films d'animation du studio se faisait la nuit avec des batchs automatiques mais qu'il y avait souvent des problèmes de saturation de la mémoire. Quand l'espace de swap est lui aussi saturé alors certaines applications sont "tués" par le gestionnaire mémoire pour libérer de la place. Diverses solutions ont été évoquées lors de la discussion qui a suivi (notamment d'usage de containers pour isoler les processus).
  
• Le représentant du Crédit Suisse a indiqué l'importance cruciale de l'ordonnanceur des processus et des fonctions de temps réel dans le noyau. Les performances de la pile TCP/IP impactent également beaucoup l'efficacité des applications du Crédit Suisse (à titre d'exemple, il a été indiqué qu'une simple congestion réseau de 40 millisecondes peut anéantir les profits d'un trader lors d'une transaction).
  
• Enfin Marcus Rex, au nom de la fondation Linux, a évoqué plusieurs fonctionnalités qu'il serait souhaitable, selon lui, d'inclure dans le noyau. Ainsi le sujet du tracing (avec l'outil SystemTap) est une fois de plus revenu sur le tapis mais la résistance des développeurs du noyau demeure vive et son intégration demeure incertaine.
  

Les problèmes de montée en charge (scalability) ont été évoqués lors d'une session très technique. Les performances des entrées/sorties d'un système multiprocesseur seraient grandement améliorées si le processeur initiant l'opération était également celui gérant sa conclusion. Diverses solutions ont été envisagées mais le problème semble difficile à résoudre. De même les performances d'un système devant gérer 20 000 disques durs ne sont pas actuellement optimales et il a été déterminé qu'une procédure de scannage asynchrone pourra accélérer le boot.

Une session sur le temps réel a été organisée afin de faire le point sur les pièces du puzzle qui restent à intégrer en mainline. En effet de nombreuses parties de la branche RT sont déjà présentes et, selon Ingo Molnar, la plus importante s'est révélée être l'outil de validation des verrous (kernel lock validator) qui a permis la détection de nombreux bugs. Il reste toutefois certaines fontions RT qui attendent encore l'inclusion. Par exemple la gestion des interruptions dans des threads séparés permettra au noyau de survivre à des bugs qui auparavant auraient provoqués des crashs du système.
La saga de l'inclusion d'un mécanisme d'entrées/sorties asynchrones s'est poursuivie lors de cette session. Depuis le début de l'année on assiste à une frénésie de propositions concurrentes pour implémenter cette fonction et cette réunion annuelle était l'occasion de faire le point. Cela avait commencé en début d'année avec l'idée de fibrils (lancée par Zach Brown) qui a été critiquée techniquement par Ingo Molnar et a provoquée de nombreux débats sur la LKML. Ensuite Linus a proposé un patch minimaliste en tant que concept et Ingo s'est investi dans le mécanisme des syslets (qui a été raffiné ensuite). Lors du sommet l'opinion majoritaire qui s'est dégagée est que cette fonction n'est pas encore assez mature. De nombreuses parties du noyau doivent êtres modifiées et la phase de test des performances n'a pas encore vraiment débuté. L'implémentation en mainline de ce mécanisme d'entrées/sorties asynchrones n'est donc pas pour tout de suite.

La session sur la gestion de la mémoire s'est consacrée principalement au problème de la gestion des tables de pagination de grande taille. Pour comprendre de quoi il s'agit, il faut savoir qu'un microprocesseur garde dans un cache la table de correspondance entre la mémoire réelle et la mémoire virtuelle. Utiliser un petit nombre de grandes pages dans cette table améliore les performances par rapport à un grand nombre de petites pages. L'ennui, c'est que le noyau actuel ne permet pas de gérer plusieurs tailles alors que certains processeurs modernes le peuvent (avec des tailles de page pouvant atteindre 1 Go). Une interface générique a été discutée avant d'être finalement écartée par Linus au profit d'implémentations différentes selon chaque architecture.

La question des containers a fait l'objet d'une session spécifique qui a fait le tour de tous les problèmes. La gestion des processus dans des containers est considérée comme presque mature et va rejoindre la mainline à brève échéance. En revanche la mise en container de toutes les ressources globales du noyau (en particulier de l'espace de noms) est un projet de plus longue haleine. Quand ce sera terminé Linux aura un système plus générique et plus puissant qu'OpenVZ ou les Zones de Solaris.

Le processus de développement du noyau a été examiné soigneusement et il a été relevé qu'étant donné le rythme de développement actuel, Linux a besoin d'encore plus de codeurs et de testeurs. Pour le noyau 2.6.22 il y avait pourtant eu plus de 900 contributeurs différents mais cela ne suffit pas. Pour éviter de décourager les nouvelles vocations, il faut que les listes de diffusion soient plus accueillantes et il a été demandé d'éviter de critiquer trop sévèrement (flaming) le patch d'un contributeur. De plus dans certaines parties du monde une critique technique acerbe est mal ressentie et peut même entrainer des conséquences professionnelles graves. Une invitation à adopter un ton plus poli a donc été lancée. En ce qui concerne le processus des releases candidates, Linus a renouvelé ses récriminations envers ceux qui soumettent des patchs invasifs en dehors de la fenêtre autorisée.

La session finale du sommet Linux 2007 portait sur le sommet lui-même. Le fait qu'il se déroule uniquement sur invitation est considéré comme une bonne chose car cela permet des discussions techniques plus approfondies. Le lieu du prochain sommet a été discuté et il existe une volonté d'aller en Chine ou en Inde afin de montrer que la communauté Linux est sérieuse quant à son désir d'accueillir plus de développeurs de ces régions. La sur-représentation des USA et de l'Europe est vue comme une anomalie à corriger. Bien entendu le problème est que le coût du transport sera plus élevé si le sommet se déplace en Asie et cette question doit donc être étudiée soigneusement.