La version candidate RC-1 a été annoncée le 28 juillet par Linus qui a souligné la taille impressionnante de cette version : " Cela fait deux semaines (et un jour) et la période des modifications est terminée. Je ne sais pas pourquoi mais j'ai l'impression que cette période aura été sacrément active. La taille du patch de la RC-1 soutient ce sentiment puisqu'avec 12 Mo il est environ 50% plus gros que le patch 2.6.26-RC-1.

Cette taille me rend un peu nerveux. C'est vrai cela signifie que nous sommes vraiment bons pour inclure toutes les nouveautés mais je dois dire que je me demande parfois si nous n'incluons pas trop de choses à la fois et si notre cycle de sortie (déjà court) n'est pas en fait trop gros. Mais bon cette discussion est pour une autre fois.

Il y a une tonne de nouveaux trucs là-dedans mais pour moi les choses les plus intéressantes sont la traque du verrou global et peut-être l'introduction de la fonction get_user_pages_fast() sans verrou.

D'autres trucs ? Le chargement des firmwares, le travail de fusion des branches x86 qui continue. De plus en plus de code qui devient générique. Le support des machines de 4096 processeurs, etc.

Allez sur kernelnewbies ou sur Linux Weekly News pour plus de détails. Moi je vais dormir pendant 24 heures ;) "





" Une semaine après cette première version candidate Linus a annoncé la version RC-2 :" Il y a plein de changements divers là-dedans et j'espère que nous allons commencer à ralentir un peu les choses. Il y a quand même un truc particulier qu'il est peut-être bon de souligner du fait des conséquences éventuelles : un certain nombre d'architectures ont utilisé "l'accalmie" après la RC-1 (Hah!) pour effectuer le renommage include/asm- nom-de-l'architecture => 'arch/ nom-de-l'architecture /include/asm. (...) Sinon il y plein d'autres petits changements mais rien qui ne puisse provoquer un « Wow! ». Notez qu'à l'étape RC-2 il ne devrait de toute façon pas y avoir ce genre de truc donc je ne me plains pas. "





" Les versions candidates RC-3 et RC-4 ont vu l'inclusion du pilote ath9k pour les cartes wifi basées sur des puces Atheros, le support du trackpad des nouveaux portables Apple ainsi que des corrections sur les systèmes de fichiers XFS et UBIFS.





Le 28 août c'est la version RC-5 qui a été annoncée : ­­« Nouvelle semaine (mes semaines semblent avoir 8 jours, c'est très bizarre) et nouvelle version candidate. Cette RC-5 comporte (...) un grand nombre de petits changements qui, je l'espère, corrigent pas mal de régressions. Le plus excitant (du moins pour moi — apparemment ma vie est ennuyeuse au-delà du concevable) est que nous avons eu des débordements de la pile (stack overflow) qui ont totalement corrompu les structure de données des threads. C'est excitant parce que nous n'avions pas eu cela depuis pas mal de temps. Bien sûr ce bug aurait impacté uniquement les gens un peu trop aventureux et ayant sélectionné l'option de configuration 4096 processeurs ! ».





». Les versions candidates RC-6 et RC-7 sont apparues respectivement le 9 et le 21 septembre, avec le Kernel Summit et la Linux Plumber Conference dans l'intervalle ce qui a un peu ralenti le rythme.





La version RC-8 a été annoncée par Linus le 29 septembre : « Celle-ci devrait être la dernière. Nous ne sommes pas à court de régressions mais, en même temps, je dois faire un choix à un certain moment et dans l'ensemble les régressions ne semblent pas _trop_ effrayantes. Et évidemment la RC-8 en corrige la plupart. ».

Il est à noter que le bug vicieux qui affectait le pilote e1000e des cartes réseau Intel n'est plus dangereux mais que Linus n'en pense pas moins : ­­­« Le _vrai_bug est dans la conception du matériel qui permet de foutre en l'air ces cartes sans même avoir un bit de sécurité. J'espère qu'Intel ne va pas traiter ça comme étant juste un bug logiciel. Certains concepteurs de matériel devraient vraiment réfléchir à propos du genre d'orifice dans lequel ils ont mis leur tête ».





». Il est à noter que le bug vicieux qui affectait le pilote e1000e des cartes réseau Intel n'est plus dangereux mais que Linus n'en pense pas moins : ». Linus a finalement décidé de sortir une version RC-9 afin de bénéficier d'une petite période de test supplémentaire : « Je sais, je sais, j'avais dit que la RC-8 serait la dernière et que le noyau serait disponible ce weekend. J'ai menti. Faites-moi un procès. J'ai inclus deux corrections pour des bugs subtils aujourd'hui et, bien qu'ils semblent parfaitement corrects et aient été testés par les gens en charge des régressions, je n'ai pas pu me décider à leur coller le label "v2.6.27" sans faire un peu plus de tests. J'ai aussi pensé que c'était une bonne idée d'avoir une version candidate contenant les patchs qui devraient corriger la corruption du pilote e1000e ».





Dans le domaine des gestionnaire de mémoire pour les cartes graphiques il est probable que GEM va faire son entrée (dès la version 2.6.28 ou la suivante) et que TTM a perdu la bataille de l'intégration dans la branche principale. La comparaison entre les deux solutions qui a été effectuée par les développeurs Linux fait apparaître que TTM est une solution plus complexe, difficile à utiliser et ayant une API en partie conçue pour satisfaire les besoins spécifiques des pilotes propriétaires (ce qui évidemment ne plait à personne). C'est donc GEM qui a la faveur des développeurs (Jesse Bernes a annoncé qu'il allait proposer l'inclusion de GEM dans la branche Linux-next) et cela a provoqué l'émoi de ceux qui voient cette solution comme étant trop liée à Intel. Le futur est donc, provisoirement, encore ouvert mais les opposants à GEM ont intérêt, s'il n'est pas déjà trop tard, à proposer très rapidement une alternative crédible.





le travail continue sur le système de fichiers btrfs et la version 0.16 a été annoncée par Chris Mason le 5 août dernier. Btrfs (prononcer butter fs ) a l'ambition de devenir le système de fichiers de nouvelle génération des systèmes GNU/Linux et introduit beaucoup de nouveautés déjà décrites dans une dépêche précédente. Cette nouvelle version 0.16 fait disparaître le verrou global de btrfs au profit de nombreux petits verrous locaux afin de tirer parti des machines multiprocesseurs. Dans la même veine les tâches d'arrière plan diverses (comme le calcul des sommes de contrôle) sont maintenant exécutées par des threads séparés. La version 0.16 apporte également le support des attributs étendus (ACL) et un nouveau système de cache pour la gestion des snapshots. Le dépôt du code source est passé à Git afin de faciliter la future intégration dans la branche principale et continuer le développement directement en mainline. Andrew Morton a proposé une intégration rapide dans la branche linux-next en vue d'une entrée dès le noyau 2.6.29. Btrfs se positionne de plus en plus comme LA solution Linux pour avoir un système de fichiers de nouvelle génération.





) a l'ambition de devenir le système de fichiers de nouvelle génération des systèmes GNU/Linux et introduit beaucoup de nouveautés déjà décrites dans une dépêche précédente. Cette nouvelle version 0.16 fait disparaître le verrou global de btrfs au profit de nombreux petits verrous locaux afin de tirer parti des machines multiprocesseurs. Dans la même veine les tâches d'arrière plan diverses (comme le calcul des sommes de contrôle) sont maintenant exécutées par des threads séparés. La version 0.16 apporte également le support des attributs étendus (ACL) et un nouveau système de cache pour la gestion des snapshots. Le dépôt du code source est passé à Git afin de faciliter la future intégration dans la branche principale et continuer le développement directement en mainline. Andrew Morton a proposé une intégration rapide dans la branche linux-next en vue d'une entrée dès le noyau 2.6.29. Btrfs se positionne de plus en plus comme LA solution Linux pour avoir un système de fichiers de nouvelle génération. Néanmoins tout le monde n'est pas de cet avis et Daniel Phillips a posté le 3 juillet un long mail sur la mailing list du noyau afin d'expliquer les grandes lignes du design d'un système de fichiers alternatif nommé Tux3 (" Comme tout le monde semble bien s'amuser a développer des nouveaux systèmes de fichiers en ce moment j'ai pensé que je pourrai me joindre à la fête ").

Le but de Tux3 est d'implémenter les idées originales de Daniel Phillips sur le versionning, on trouve par exemple les informations sur les versions dans le feuilles des arbres B alors que btrfs et ZFS choisissent de créer un arbre par version. Cela permettrait à Tux3 de faire une économie de place lors du stockage des méta-données par rapport à ses deux concurrents. Il est à noter que Matt Dillon, qui dirige le développement de DragonFlyBSD, a échangé plusieurs mails avec Daniel Phillips afin de comparer son système de fichiers HAMMER et Tux3.

Les deux systèmes partagent de nombreuses idées et la conversation, bien que très technique, a sans aucun doute été mutuellement enrichissante. Matt a toutefois gentiment prévenu Daniel qu'il s'embarquait peut-être dans un projet plus complexe que ce qu'il pensait : " Il semble que Tux3 utilise pas mal d'idées similaires à ce que je fais dans HAMMER. Je pense que tu est sur la bonne voie. J'ajouterai quand même un mot d'avertissement, venant de mon expérience lors de l'implémentation de HAMMER, parce que je pense que tu va être confronté aux mêmes problèmes. J'ai passé 9 mois sur le design d'HAMMER et 9 mois pour l'écrire. Durant l'implémentation j'ai fini par jeter l'équivalent de 80% de ce qui était dans le design original. Une bonne part de ce que j'ai du abandonner lors du passage du projet à la réalité était dans le but de diminuer la complexité. (..) Si j'ai une inquiétude à propos de ton implémentation cela serait dans le secteur de la complexité algorithmique. "

Si les idées de Tux3 sont innovantes il n'en est toutefois absolument pas au même stade de développement que btrfs. Daniel Philips l'a exprimé avec humour dans un mail daté du premier septembre : " Les derniers patchs ont permis d'amener Tux3 jusqu'au point ou il commence indéniablement à se comporter comme un système de fichiers: On peut écrire des fichiers, partir un moment et, quand on revient, ces fichiers sont toujours là et on peut les relire. " Le chemin est donc encore long avant de pouvoir envisager l'inclusion dans la branche principale du noyau.





"). Le but de Tux3 est d'implémenter les idées originales de Daniel Phillips sur le versionning, on trouve par exemple les informations sur les versions dans le feuilles des arbres B alors que btrfs et ZFS choisissent de créer un arbre par version. Cela permettrait à Tux3 de faire une économie de place lors du stockage des méta-données par rapport à ses deux concurrents. Il est à noter que Matt Dillon, qui dirige le développement de DragonFlyBSD, a échangé plusieurs mails avec Daniel Phillips afin de comparer son système de fichiers HAMMER et Tux3. Les deux systèmes partagent de nombreuses idées et la conversation, bien que très technique, a sans aucun doute été mutuellement enrichissante. Matt a toutefois gentiment prévenu Daniel qu'il s'embarquait peut-être dans un projet plus complexe que ce qu'il pensait : " " Si les idées de Tux3 sont innovantes il n'en est toutefois absolument pas au même stade de développement que btrfs. Daniel Philips l'a exprimé avec humour dans un mail daté du premier septembre : " " Le chemin est donc encore long avant de pouvoir envisager l'inclusion dans la branche principale du noyau. Enfin, preuve du bouillonnement actuel dans le domaine des systèmes de fichiers, un concurrent de plus vient d'apparaître. Répondant au doux nom de NILFS (New Implementation of a Log-structured File System) ce système se propose d'enterrer tous les autres systèmes en se basant sur la technique d'écriture des données « en flux » (sous forme de log) sans avoir à se préoccuper d'optimiser l'écrire les données les unes à coté des autres (ce qui prend beaucoup de temps). L'idée est que les lectures de données se font très souvent à partir de la RAM et qu'il est donc plus rationnel d'optimiser l'écriture plutôt que la lecture. Le code a été soumis sur la liste de diffusion et un fichier pdf comparant NILFS avec d'autres systèmes de fichiers est disponible.

NILFS semble particulièrement adapté aux nouveaux disques SSD et il constitue donc, aux cotés de LogFS, une alternative possible au tout nouveau UBIFS (quand l'accès direct à la mémoire flash sous-jacente sera possible).

L'inquiétude d'Andrew Morton sur le manque de travail des développeurs face à la vague future des disques SSD semble donc étonnante : "Il me semble entendre un silence assourdissant au sujet du support de ces périphériques SSD. J'ai la vague inquiétude que nous allons assister à une diffusion massive de ces SSD et que Linux y fera face avec le pantalon sur les chevilles."

Andrew Wilcox a été prompt a lui rétorquer qu'au contraire la situation était plutôt bonne et qu'il n'y avait pas de souci à se faire : "Je travaille (et je poste des patchs) sur le support des SSD Intel. Honnêtement nos pantalons évoluent actuellement dans la zone de l'aine."



Aller plus loin

Un peu plus de deux mois et demi après la version précédente Linus Torvalds a annoncé la sortie de la version 2.6.27 du noyau Linux.Comme d'habitude le code source de ce nouveau Linux stable est téléchargeable sur les serveurs du site kernel.org Pour un bilan en chiffres (analyse statistique issue de cet article du site LWN ) le noyau 2.6.27 aura incorporé plus de 10604 patchs (10100 pour les noyau 2.6.26). Cela représente un gain net de 218000 lignes (+826000 et -608000).On peut noter que le français Jean-François Moine est le troisième contributeur en terme de lignes de code du fait de son important travail sur l'intégration et le nettoyage du pilote de webcam GSPCA Ces plus de dix mille patchs viennent de 1109 développeurs différents (1065 pour le noyau 2.6.26) travaillant pour plus de 150 entreprises.