Sortie du noyau Linux 2.6.24

Après un cycle de développement inhabituellement long la sortie de la vingt-cinquième version stable de la branche 2.6 du noyau Linux vient d'être annoncée. Le code source du noyau est maintenant téléchargeable sur les serveurs du site kernel.org.

• Cette version 2.6.24 se caractérise essentiellement par l'ampleur des changements, en terme de lignes de codes, avec la version précédente. Le 23 octobre, dans son mail d'annonce de la RC-1, Linus écrit :

  Cela doit être l'une des plus grosses versions candidates de tous les temps. C'est monstrueux. D'habitude, pour la RC-1, la taille du fichier compressé des différences est de l'ordre de 3 à 5 Mo. Certains sont plus petits que ça et on a occasionnellement des pointes à 6 Mo. Celle-ci fait *onze* méga-octets.
  En bref nous avons juste eu un grand nombre de merges, et pas seulement pour x86 mais aussi des tonnes de nouveaux pilotes (surtout pour le wifi mais pas seulement - dvb, réseau classique, mmc..etc) ainsi qu'une bonne quantité de travail sur les diverses architectures, les systèmes de fichiers, le réseau etc.
  Donc il y a juste beaucoup de nouvelles choses.

• En dépit de ces nombreux changements le cycle des versions candidates n'a pas été excessivement douloureux. Le 6 novembre Linus a annoncé la RC-2 :

  Ouais, ne m'en parlez-pas - c'est en retard. Il n'y a rien eu de particulier pour retenir cette version aussi longtemps. J'ai juste simplement oublié de faire une RC-2 la semaine dernière. Il n'y a pas beaucoup de trucs vraiment excitants ici. Des mises à jour d'architectures : MIPS, arm, blackfin, x86, sparc64, sh, s390. Également des mises à jour de pilotes : libata, IDE, réseau, DVB. Rien de vraiment révolutionnaire dont je puisse me souvenir. La liste des modifications est encore trop grosse pour la limite de la liste de diffusion mais, franchement, ce n'est pas du Tolstoï. Si vous avez des problèmes pour vous endormir vous pouvez essayer de l'imprimer et de la prendre au lit avec vous.

• La RC-3, apparue le 16 novembre, a vu, en plus de beaucoup de petites corrections, la touche finale au processus de fusion des branches i386 et x86-64 qui constitue l'une des grandes nouveautés du noyau 2.6.24 :

  En plus des autres mises à jour il y a également le dernier nettoyage du patch d'unification. Le reste peut attendre après le 2.6.24 mais avec ce dernier patch la configuration x86 est vraiment fusionnée et les architectures i386 et x86-64 sont vraiment juste des cas spéciaux de l'architecture globale "x86" lors de la configuration.

• La RC-4 n'a été annoncée que le 3 décembre par Linus :

  Nous devrions avoir seulement une semaine entre chaque version candidate mais, à l'occasion de Thanksgiving, j'étais parti pour une semaine (comme certains autres développeurs du noyau) ce qui fait que celle-ci est un peu en retard.

  Comme d'habitude, c'est devenu rituel lors des cycles de développement, il a ensuite protesté devant le grand nombres de patchs qui continuent d'arriver alors que le noyau devrait être en mode stabilisation :

  La différence par rapport à la RC-3 est de presque de 36000 lignes (...) Je vais blâmer la période de deux semaines qui s'est écoulée mais, même en tenant compte de ce délai, c'est un peu décourageant. J'espère vraiment que nous allons ralentir et que la RC-5 ne sera pas aussi grosse. Ceci dit aucun des changements n'est vraiment excitant ou vraiment effrayant.

• Une semaine pile après la version candidate précédente voici la RC-5 :

  Cela fait une semaine et comme j'ai promis d'être un bon garçon et d'essayer de suivre mes propres règles de sortie, voici la version candidate suivante.
  Les choses ont ralenti mais je mentirais si je disais que nous avons toutes les régressions bien en main et sous contrôle. C'est en cours de résolution et la liste diminue mais, si je devais deviner, nous ne pourrons certainement pas avoir un 2.6.24 avant Noël sauf si le père Noël met un peu plus d'elfes pour travailler sur ces régressions.
  Donc pour tous les elfes là dehors, merci de continuer à bosser.

• Malheureusement le père Noël n'a pas été coopératif et Linus, dans l'annonce de la RC-6, a reconnu que la nouvelle cible était début janvier :

  La liste des régressions continue à se réduire donc nous sommes dans les clous pour une sortie du 2.6.24 début janvier... en supposant que nous ne fassions pas trop d'excès de boustifaille pendant les vacances et que les gens continuent à bosser. Mais nous savons tous que les vacances sont le moment où on peut couper avec l'ennuyeux "travail réel" et enfin passer 24 heures sur 24 à hacker le noyau n'est-ce pas ?

• Après le break des vacances Linus a annoncé la sortie de la version RC-7. Cette dernière consiste principalement en de multiples petites corrections et le changement par rapport à la RC-6 n'est pas énorme. Linus l'a expliqué à sa façon à lui :

  Je vais être charitable et prétendre que c'est parce que les choses se stabilisent et pas parce que nous avons tous été perdus dans les brumes de l'alcool durant les vacances

• La seconde hypothèse s'étant révélée être la bonne il a été nécessaire d'ajouter une RC-8 pour corriger divers petits problèmes de dernière minute :

  Je déteste faire des RC pendant si longtemps, mais je déteste encore plus annoncer une sortie quand je sens que les choses n'ont pas mitonné suffisamment.

Vous trouverez plus de détails sur les nouveautés dans la suite de cette dépêche.

• La fonction d'ordonnancement de groupe, qui a été évoquée lors de la sortie du précédent noyau, est maintenant intégrée dans cette version. Cela permet à l'ordonnanceur de nouvelle génération CFS de gérer plus finement l'allocation des ressources de calcul aux différents processus s'exécutant sur la machine. Avec l'ordonnancement de groupe on peut diviser à volonté le temps processeur selon deux politiques : Soit entre les utilisateurs soit entre les groupes de tâches.
  
  • La première option (sélectionnable avec CONFIG_FAIR_USER_SCHED) divise le temps processeur entre les différents utilisateurs d'une machine. Celui qui lance 30 processus ne sera plus avantagé par rapport à celui qui n'en lance qu'un seul et chacun des deux utilisateurs aura équitablement la moitié du temps de calcul. Un avantage additionnel relevé par Ingo Molnar est que cela limite drastiquement les risques de Fork Bomb.
    
  • La seconde option (sélectionnable avec CONFIG_FAIR_CGROUP_SCHED) divise le temps processeur entre différents groupes de tâches. La documentation décrit très bien cette nouvelle fonction : on peut par exemple créer le groupe "multimédia" et le groupe "bureautique" et décider que le premier groupe aura 75 % du temps de calcul alors que le second n'aura que 25 %. L'administrateur a ainsi a sa disposition un outil très souple pour créer tous les groupes qu'il désire et y rattacher les processus à volonté.
    
  En plus de cet enrichissement fonctionnel apporté par l'ordonnancement de groupe, CFS a également été amélioré sur le plan de la taille du code et de la rapidité. L'empreinte mémoire du code compilé a été réduite puisqu'on passe de 29 145 octets à 26 666 octets (-8,5 %) sur un système multiprocesseur et de 15 633 octets à 13 379 (-14,4 %) sur un système mono-processeur. Cette réduction de taille est cruciale pour le monde de l'embarqué ou Linux est devenu un système incontournable. Diverses micro-optimisations ont également permis de réduire les latences de l'ordonnanceur. Ingo Molnar a mesuré ces latences à l'aide de l'outil lmbench : le noyau 2.6.22 (ne contenant pas CFS) atteignait 0,64 microsecondes. Le noyau 2.6.23 (contenant la première version de CFS) avait régressé à 0,72 microsecondes (+12 %). Le nouveau noyau 2.6.24 et son code optimisé permet de redescendre à 0,62 microsecondes (soit -3 % par rapport à l'ordonnanceur non équitable d'ancienne génération). On voit donc que le caractère complètement équitable et extrêmement robuste du nouvel ordonnanceur CFS n'aura rien coûté en performances.
  
  
• Pour permettre, entre autre, l'ordonnancement de groupe le noyau 2.6.24 propose l'infrastructure Control Group. Elle permet de définir de façon très générique des groupes de contrôle (ou cgroups) afin de gérer les ressources disponibles de la machine et de définir des quotas d'utilisation. L'administrateur utilise les cgroups pour créer des hiérarchies de processus au travers, comme c'est l'habitude sous Linux, d'un système de fichier virtuel se trouvant dans /dev/cgroup. Ces cgroups associent des listes de tâches avec des listes de paramètres pour les divers gestionnaires des ressources (les processeurs, les utilisateurs, les disques, le réseau, etc.).
  Pour simplifier évoquons un exemple (tiré directement de la documentation) : l'administrateur du serveur d'une université désire gérer finement les ressources de sa machine. Il crée donc deux cgroups, l'un pour les professeurs et l'autre pour les étudiants. Une fois que c'est fait l'administrateur peut utiliser la nouvelle infrastructure Control Group afin de définir des quotas et des limites pour chaque groupe. Par exemple, 50 % de la mémoire pour les professeurs, 30 % pour les étudiants et le reste pour le système. Observez sur le schéma ci-dessous l'application d'une hiérarchie des quotas pour les ressources réseau. La navigation web a une allocation de 20 % de la bande passante qui est elle-même divisée inégalement entre professeurs et étudiants.
  

             /         \
  
  
      cgroup1    cgroup2
  
  
         |              |
  
  
     (Profs)         (Etudiants)
  
  
  Mémoire : Profs (50%), étudiants (30%), système (20%)
  
  
  Disques : Profs (50%), étudiants (30%), système (20%)
  
  
  Réseau : navigation web (20%), accès par NFS (60%), autre (20%)
  
  
                     /        \
  
  
          Prof (15%) étudiants (5%)

  
  Cette nouvelle infrastructure de quotas et de groupes de contrôle est utilisée par CFS pour l'ordonnancement de groupe des processus évoqué plus haut. Ainsi CFS évite de dupliquer du code et profite du mécanisme générique se trouvant dans le nouveau noyau.
  
  
• L'unification des architectures i386 et x86-64 est réalisée pour la première fois au sein du noyau 2.6.24. Quand on regarde le code source de Linux on constate que le répertoire arch contient le code spécifique aux divers processeurs qui sont supportés par le noyau (PowerPC, i386, ARM, SPARC, etc.). Ce nombre de sous-répertoires est important (plus de 25 architectures différentes) et les développeurs ont intérêt à essayer de fusionner au maximum ce qui peut l'être afin de partager le plus de code possible. Comme il existe de nombreuses ressemblances entre les i386 et les x86-64 (essentiellement l'architecture passe de 8 à 16 registres et ces registres passent de 32 à 64 bits) un projet de fusion a vu le jour. Actuellement une correction de bug sur l'une des branches doit être dupliquée sur l'autre. Quand une nouveauté est introduite, il faut l'incorporer à l'autre branche, etc. Ce processus de double maintenance est très lourd et provoque de nombreuses erreurs. La décision a donc été prise de faire comme pour l'architecture PowerPC : les variantes 32 et 64 bits ont fusionné à l'occasion de la sortie du noyau 2.6.15 et, avec le recul, cela s'est avéré être une très bonne décision.
  Thomas Gleixner et Ingo Molnar, dans un mail très argumenté, ont donc proposé un méga patch (près de 2 000 fichiers sont impactés) qui renomme tous les fichiers spécifiques avec le suffixe _32 ou _64 et les déplace dans le nouveau répertoire unifié x86. C'est une sorte de "Big Bang" au niveau des répertoires de arch mais cela ne change rien au niveau du code lui-même. De cette façon le travail d'unification, qui a déjà commencé, peut se faire progressivement (en fusionnant les fichiers toto_32.C et toto_64.c en un unique toto.c) avec chaque nouvelle version du noyau.
  Cette décision a néanmoins provoqué une controverse car Andi Kleen, le mainteneur de la branche x86-64, n'était pas d'accord avec l'unification. Il a défendu son point de vue sur la liste de diffusion :

  Vous connaissez ma position à ce sujet. Je pense que c'est une mauvaise idée car cela signifie que nous ne pourrons jamais plus nous débarrasser des vieilleries. La branche arch/x86_64 est significativement plus propre et plus simple que arch/i386 et je voudrais préserver cela. [...] Ce n'est pas vraiment la même plate-forme : l'une est une architecture PC remontant à la nuit des temps et contenant des zillions de bugs, l'autre est une plate-forme PC moderne avec bien moins de bugs et de bizarreries.

  Linus n'était pas de cet avis:

  Je pense qu'il est *bien* plus difficile de gérer ce genre d'héritage dans un vieux répertoire que presque personne n'utilise (ce n'est probablement pas vrai à l'heure actuelle mais, pour la plupart des développeurs, je parie que cela sera vrai dans un an). Spécialement si ce vieux répertoire se contente de dupliquer 99% du boulot. Il n'y a pas tant de vieilleries que ça. Il y a certes des choses bizarres ici et là, mais chaque fois que j'entends l'argument (théorique) selon lequel nous économiserions du temps et des efforts en ayant ce code dupliqué ailleurs je pense à tout le temps que nous perdons réellement en corrigeant le même bug deux fois (et je m'inquiète pour les fois ou nous ne le faisons pas).

  Andi n'a pas été convaincu par Linus et il a décidé de ne pas assurer la maintenance de la nouvelle branche fusionnée x86. Les nouveaux mainteneurs sont donc Thomas Gleixner, Ingo Molnar, et H. Peter Anvin.
  
  
• Un changement concernant les entrées/sorties de type scatter/gather a provoqué quelques soucis dans le nouveau noyau. La technique de scatter/gather permet d'utiliser un seul appel système pour écrire séquentiellement des données depuis plusieurs tampons mémoires ou pour lire des données dans plusieurs tampons mémoires. Ce mécanisme, qu'on pourrait traduire imparfaitement par Rassemblement/Dispersion, élimine l'obligation de copier les données dans un seul gros buffer et permet d'utiliser beaucoup de petits tampons dispersés. Cela permet d'augmenter les performances et d'éviter d'avoir à créer un gros buffer d'une seule pièce (ce qui est parfois difficile). La technique scatter/gather est très efficace et pratique puisqu'une seule instruction permet de faire plusieurs choses simultanément. Cela explique pourquoi cette technique est aussi connue sous le nom d'entrées/sorties vectorielles. La liste des multiples tampons est présente dans un tableau mais celui-ci ne peut pas excéder la taille d'une page mémoire. Afin de faire sauter cette limitation contraignante le noyau 2.6.24 a introduit la possibilité de chaîner ces listes. Le but est d'augmenter encore les performances d'entrées/sorties mais ce changement a été douloureux et a provoqué le dysfonctionnement de plusieurs pilotes. Jonathan Corbet a même indiqué que

  le chaînage des listes scatter/gather a sans doute été le changement le plus problématique du noyau 2.6.24, en dépit du fait qu'il s'agit d'un nombre réduit de lignes de code

  L'API scatter/gather doit aussi encore être améliorée afin de simplifier son utilisation. Deux directions sont envisagées pour inclusion dans le noyau 2.6.25 afin d'avoir une API qui permette d'écrire plus facilement à l'avenir du code haute-performance.
  
  
• Le support de l'espace de noms pour les processus fait son entrée dans le nouveau noyau.
  Cette fonction est liée à la problématique de la création de conteneurs afin de pouvoir exécuter des applications dans des boites virtuelles séparées. Le concept est similaire aux Jails de FreeBSD ou aux Zones de Solaris et cela permet de renforcer la sécurité en élevant des barrières étanches entre les divers processus tournant sur une machine. Pour cela il est nécessaire de masquer toutes les ressources globales du noyau (systèmes de fichiers, identifiants des processus, interfaces réseaux etc.) derrière une couche d'abstraction. Ainsi chaque conteneur pourra avoir sa propre vue des ressources globales et il s'exécutera normalement, c'est à dire sans conflit avec les autres conteneurs. Le noyau 2.6.24 propose ainsi un espace de noms qui permet d'attribuer le même identifiant (le PID) à des processus qui sont dans différents conteneurs. Il devient alors facile de migrer ce conteneur d'un ordinateur à l'autre sans rencontrer des problèmes de conflit d'identifiants.
  Pour créer un nouvel espace de noms on utilise l'appel système clone avec le flag CLONE_NEWPID. Comme l'espace de nommage est hiérarchique le premier processus à se lancer aura le PID 1 et quand ce premier processus se terminera alors tout l'espace de nommage se terminera également (en fait il joue un peu le rôle d'init sur une machine classique). Le pseudo-système de fichier procfs devra être monté autant de fois qu'il y a d'espaces de noms et on pourra ensuite utiliser la commande ps à l'intérieur de ces instances de procfs pour lister les processus tournant dans le conteneur.
  Il est à noter que ce travail de masquage des ressources globales du noyau n'est pas encore terminé. Le support de l'espace de noms pour les interfaces réseaux, qui s'utilise avec le flag CLONE_NEWNET et qui permet aux conteneurs d'avoir chacun une vue différente de la pile réseau, a fait son entrée dans ce noyau 2.6.24 mais toutes les fonctions ne sont pas implémentées. De même ce support de l'espace de noms pour les processus est pour l'instant encore marqué comme "expérimental" afin de prévenir les développeurs que l'interface de programmation est susceptible de changer. La finalisation définitive de l'API est prévue pour la version 2.6.25 et elle pourrait bien annoncer le début de la fin pour les patchs externes du type Vserver. Quand tout ces mécanismes de gestion de conteneurs seront inclus dans la branche principale, Linux possédera une solution plus puissante et plus générique que ses concurrents. On peut noter à titre d'exemple que les Zones de Solaris ne possèdent pas d'espace de noms pour le réseau.
  
  
• L'interface Virtio qui permet de proposer aux différentes solutions de virtualisation une couche commune pour gérer les entrées/sorties a été développée par Rusty Russell et le patch a été inclus dans le nouveau noyau Linux. Comme il existe plusieurs solutions de virtualisation utilisables avec Linux (Xen, Lguest, KVM, etc.) il est apparu nécessaire de chercher à mutualiser une partie du code et à proposer une couche d'abstraction pour éviter une divergence des outils. Virtio est une interface virtuelle qui permet de gérer les entrées/sorties et évite ainsi la prolifération anarchique des pilotes virtuels. Interrogé sur l'utilité réelle de Virtio, Rusty a répondu que :

  personne ne veut maintenir cinq pilotes virtuels différents pour le réseau, cinq pilotes virtuels différents en mode bloc, etc. En fait à un moment la communauté du noyau va se rebeller [...] Nous pouvons donc au moins simplifier pour chaque technologie de virtualisation le fait d'implémenter le nouveau périphérique XYZZY.

  Virtio reste volontairement simple car la technique de virtualisation des entrées/sorties change rapidement et il ne faut pas que cette nouvelle interface devienne un facteur limitant par la suite...ou comme le dit plus brutalement Rusty:

  Of course, the new interface must not suck.

• La gestion dynamique des tranches de temps pour l'architecture x86-64 et pour l'architecture PPC fait maintenant partie du code du noyau Linux. Cette technologie est apparue dans le noyau 2.6.21 mais elle était jusqu'à présent réservée aux processeurs i386 et aux SPARC64. Elle permet (quand on utilise l'option CONFIG_NO_HZ) d'éviter d'avoir une fréquence fixe de "réveil" du processeur et donc de le laisser plus longtemps dans des modes d'économie d'énergie. Cela se traduit par moins de chaleur dissipée et plus de durée d'utilisation pour les ordinateurs portables (c'est également intéressant pour la gestion des machines virtuelles). Les nombreux utilisateurs de distributions x86-64 peuvent donc maintenant découvrir les bienfaits d'un noyau "tickless".
  
  
• le support de la norme Secure Digital Input Output fait son entrée au sein du code permettant de gérer les cartes mémoires MMC et SD. Cette modification autorise le branchement sur un port SD de divers gadgets: Récepteurs GPS, adaptateurs Wi-Fi ou Bluetooth ou Ethernet, Lecteurs de code-barre, Tuners FM ou TV, Appareils photos, etc.
  Pierre Ossman, qui est le mainteneur officiel du sous-système MMC/SD, a annoncé que trois pilotes SDIO étaient déjà inclus dans le noyau et que le travail continue pour inclure de nombreux autres pilotes. Néanmoins il tient à avertir les développeurs que son implémentation de SDIO force à écrire proprement le code des pilotes :

  Cette implémentation oblige à une stricte séparation des couches et masque tous les détails du protocole. Cela pourra en ennuyer certains qui voulaient porter plus facilement les pilotes entre différentes implémentations mais je crois que le résultat final sera un système bien plus robuste au lieu de n'être qu'une collection de hacks et de bidouilles.

• L'infrastructure Kernel Markers est maintenant en place dans le noyau 2.6.24. Depuis plusieurs mois les développeurs ont entrepris d'améliorer les fonctions de tracing, c'est à dire d'enregistrement d'informations lors de l'exécution de la machinerie interne de Linux. Ce "tracing" est très important pour diagnostiquer d'éventuels problèmes et pour régler finement les performances du noyau. La société Sun propose l'outil Dtrace dans son système d'exploitation Solaris et la sophistication de cet outil a provoqué un très grand intérêt dans le monde informatique au point que le projet FreeBSD a décidé de porter Dtrace vers son propre environnement. La puissance du logiciel de Sun a provoqué un sentiment d'envie chez les développeurs Linux qui, pour revenir à parité, ont accéléré leurs efforts. Le premier résultat est Kernel Markers qui permet d'insérer des points de contrôles statiques dans le noyau. Le fait que ces points soient statiques est important car cela leur permet d'être insensibles aux modifications de code qui les rendraient obsolètes à très court terme et cela rend négligeable leur impact sur les performances. Maintenant que cette infrastructure est en place les outils concurrents de Dtrace (comme SystemTap ou LTTng) vont pouvoir s'appuyer dessus pour devenir compétitifs.
  
  
• Une autre nouveauté de ce noyau est le mécanisme d'autorisation des périphériques USB. Dans un futur proche la nouvelle norme Wireless USB (c'est à dire le branchement des périphériques par ondes radio) va faire son apparition. Cela pose évidemment un problème de sécurité nouveau qu'il faut résoudre dès maintenant. Actuellement quand un utilisateur branche par exemple un disque dur USB le noyau suppose que ce périphérique est autorisé et il est automatiquement configuré et rendu disponible. Avec le WUSB et ses connexions sans fil à distance il faut mettre en place un mécanisme d'authentification similaire au WPA qui existe pour les réseaux Wi-Fi. La spécification WUSB a pris en compte ce problème et le noyau 2.6.24 implémente maintenant ce mécanisme qui permettra d'éviter que votre voisin puisse se connecter sur votre disque dur WUSB tout neuf. Pour entrer un peu plus dans les détails la partie authentification est laissée à un programme en espace utilisateur alors que la partie autorisation relève du noyau. Cela permet de bien séparer les fonctions et d'éviter de faire entrer dans le noyau un grand nombre de lignes de code qui peuvent tout aussi bien rester à l'extérieur. Maintenant chaque périphérique USB a trois flags supplémentaires: wusb, authorized, et authenticated et l'administrateur de la machine peut changer librement la valeur de ces flags. On voit immédiatement le profit pour la gestion des périphériques USB classiques qui peut être tiré de cette infrastructure introduite pour accueillir le Wireless USB. Par exemple maintenant un administrateur peut décider que les souris et les claviers sont autorisés (en leur passant le flag authorized à 1) alors que les imprimantes et les périphériques de stockage sont interdits (valeur 0 dans leur flag). Ce mécanisme d'autorisation introduit donc beaucoup de souplesse dans la gestion fine des périphériques sous Linux.
  
  
• Le patch permettant le réglage intelligent de la vitesse d'écriture a été intégré au noyau. Avant ce patch l'écriture sur un disque se passait de la façon suivante: Une application voulant écrire des données utilise la fonction write() et le noyau copie ces données dans la mémoire vive en mettant un flag "dirty". Ce flag signifie que ces pages mémoire ne doivent pas être réutilisées tant que le disque dur n'aura pas effectivement écrit toutes les données. Le danger c'est que l'application continue d'écrire dans la mémoire plus rapidement que le disque ne peut absorber. La conséquence c'est que de plus en plus de pages mémoires deviennent "dirty" ce qui peut, dans des cas extrêmes, mettre en danger la stabilité de la machine qui n'aurait plus assez de mémoire vive. Pour éviter cette fâcheuse situation le noyau contrôle en permanence la quantité totale de pages "dirty" et, en cas de besoin, il force le processus à écrire directement sur le disque (ce qui est lent) au lieu d'écrire dans la mémoire. Jusqu'à présent ce mécanisme de contrôle n'était pas intelligent et il forçait tous les processus à ralentir ! Ainsi une clé USB très lente, ne pouvant donc pas absorber assez vite les pages "dirty", va entraîner le déclenchement par le noyau du processus de contrôle ce qui va ralentir tous les processus écrivant sur des périphériques.
  Peter Zijlstra a donc proposé un patch qui permet un contrôle pour chaque disque (et non plus global). Ainsi quand le contrôle de vitesse se déclenche pour le processus écrivant sur la clé USB, les autres processus, ceux qui écrivent sur des disques rapides, peuvent continuer à remplir des pages "dirty" dans la mémoire vive. Bien entendu la partie difficile de cette solution est d'arriver à déterminer le moment exact où doit se déclencher le contrôle autoritaire. Pour bien faire les choses un processus écrivant sur un disque rapide devrait avoir droit à plus de pages "dirty" qu'un autre écrivant sur un périphérique lent et le contrôle ne devrait pas se déclencher avec le même seuil. Pour prendre ces décisions délicates Peter Zijlstra a introduit la bibliothèque "Floating Proportions". Cette dernière permet de suivre le nombre d'écritures effectives sur chaque disque et d'accorder des quotas de pages "dirty" en fonction de ces résultats. Ce réglage intelligent de la vitesse d'écriture permet ainsi d'améliorer les performances et la robustesse des entrées/sorties sous Linux.
  
  
• Outre les nouveautés décrites ci-dessus, une multitude d'autres nouveautés sont présentes dans ce noyau.
  
  • De très nombreux pilotes Wi-Fi utilisant la nouvelle pile mac80211 (introduite dans le 2.6.22) entrent enfin dans la branche principale. Cela représente 2,3 Mo de code source ce qui donne une indication du nombre de pilotes. On trouve notamment celui de la carte Intel PRO/Wireless 3945ABG/BG ou encore de la carte Broadcom BCM43xx.
    
  • Après la correction de quelques problèmes de jeunesse le nouvel allocateur de mémoire SLUB, inclus dans le noyau 2.6.22, a été optimisé par Christoph Lemeter. On observe un gain de 10 à 20% quand l'allocation est de la même taille que la page mémoire et de 50% quand la libération est de la même taille que la page mémoire.
    
  • Pour des raisons de sécurité il n'est plus possible de charger des modules à chaud par l'intermédiaire de l'interface LSM. Les modules de sécurité devront donc être inclus lors de la compilation du noyau (ce qui va évidemment poser des problèmes aux firmes diaboliques qui utilisaient LSM pour brancher leurs modules propriétaires).
    
  • Toujours dans le domaine de la sécurité l'algorithme de chiffrement symétrique SEED, très répandu en Corée, est inclus dans le noyau.
    
  • L'allocation de port pour les protocoles UDP et SCTP se fait maintenant de façon non prévisible comme c'était déjà le cas avec TCP et ce afin de renforcer la sécurité.
    
  • Les disques SATA utilisent désormais par défaut la gestion de l'économie d'énergie par ACPI (même si le commentaire lapidaire et humoristique du commit laisse craindre le pire ;-)
    
  • Le patch LRO (Large receive offload) permet d'agréger les multiples paquets TCP reçus en un seul gros paquet ce qui permet de réduire le travail de la pile réseau et donc d'augmenter les performances de la machine. Les pilotes réseau seront modifiés progressivement pour tirer partie de cette nouvelle fonction.
    
  • L'API de la couche d'abstraction des systèmes de fichiers (VFS) a été modifiée afin d'éviter un risque d'interblocage. Les mainteneurs de systèmes de fichiers qui ne sont pas dans la branche principale de Linux vont devoir, à moyen terme, adapter leur code.
    
  • Le système de fichiers CIFS inclus dans le noyau devient compatible avec les listes de contrôle d'accès (ACL).
    
  • Il est maintenant possible d'utiliser la fonction de multiplicateurs de ports de la norme SATA. Cela permet à plusieurs disques d'utiliser simultanément le même port SATA.
    
  La liste détaillant toutes les nouveautés (réseaux, systèmes de fichier, pilotes disques, cartes son, vidéo, Bluetooth, etc.) est disponible sur le site de Kernelnewbies.
  

Comme c'est devenu l'usage le site Linux Weekly News propose un article résumant les multiples contributions durant ce cycle. On apprend ainsi que le plafond des 10000 patchs a été dépassé (seulement 6200 patchs pour le 2.6.23) et que le nombre de contributeurs a été de 950 contre 860 pour le noyau précédent. Si on regarde le bilan global de l'année 2007 ce sont plus de 1900 développeurs qui sont intervenus sur le noyau en produisant plus de 30000 patchs (ce qui représente 5000 modifications de lignes de code par jour).
De nombreuses autres statistiques très intéressantes sont également présentes dans cet article et la conclusion est rassurante à lire :

L'image qui résulte de tous ces chiffres est celle d'une communauté de développement saine et diversifiée. Le noyau est vraiment une ressource commune avec littéralement des milliers de personnes qui travaillent pour l'améliorer. Et il ne montre aucun signe de ralentissement de sitôt.

Pour la suite...
En ce qui concerne le futur du noyau Linux on peut se tourner vers la page spécifique maintenue par Jonathan Corbet.

• L'outil de tracing utrace, qui était pressenti pour faire son entrée dans le 2.6.24, a été retardé mais il devrait être présent dès la prochaine mouture de Linux.
  
• Le module de sécurité SMACK (Simplified Mandatory Access Control Kernel), qui est développé par Casey Schaufler, pourrait entrer en mainline et faire concurrence à SELinux en proposant moins de fonctions mais une configuration bien plus simple. Casey propose régulièrement des mises à jour de version qui intègrent la branche de test -mm sans problèmes ce qui est de bon augure pour le futur de ce module.
  
• Le système de fichier de nouvelle génération ext4 continue sa phase de développement et il incorpore de nouvelles fonctions. Cette fois-ci c'est UBG (uninitialized block groups) qui est annoncé. Cela consiste à contrôler si un bloc disque a été initialisé ou pas. Si le bloc n'a jamais été utilisé alors le programme fsck n'aura pas besoin de le vérifier lors de son passage suivant. Cela permet potentiellement de gagner beaucoup de temps lors du boot (entre 2 et 20 fois plus rapide) quand on doit procéder à l'examen d'un disque.
  
• Le support des bus de données de type CAN (Controller Area Network) est en cours de développement par des ingénieurs de la société Volkswagen. Cette nouvelle infrastructure PF_CAN devrait faire son entrée dans le noyau 2.6.25 ou 2.6.26 et faciliter ainsi l'utilisation de Linux au sein de l'industrie automobile .
  
• Enfin le vieux serpent de mer du débogueur interactif intégré au noyau refait surface. Selon les prévisions de Jon Corbet il y a une chance non nulle qu'en dépit de la mauvaise volonté de Linus, qui n'aime pas les débogueurs intégrés (voir le fameux post "because i'm a bastard"), le patch KGDB puisse faire partie du prochain noyau 2.6.25.

Aller plus loin

• Les nouveautés du noyau 2.6.24 (38 clics)
• Le bilan des ajouts partie 1 (3 clics)
• Le bilan des ajouts partie 2 (6 clics)
• Les prévisions pour le futur de Linux (8 clics)