Nouvelle version 2.6.32 du noyau Linux

Posté par  . Modéré par patrick_g.
Étiquettes :
92
3
déc.
2009
Kernel
La sortie de la version stable 2.6.32 du noyau Linux vient d'être annoncée par Linus Torvalds. Le nouveau noyau est, comme d'habitude, téléchargeable sur les serveurs du site kernel.org.
Ce noyau 2.6.32 est particulièrement important car il sera intégrée dans la prochaine version Ubuntu avec support à long terme (Ubuntu 10.04 LTS) et dans la prochaine version Debian 6.0 "Squeeze".

Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche (placée sous licence libre CC BY-SA).

Le sommaire...


La phase de test (↑)

RC-1

La sortie de la RC-1 a été annoncée par Linus le 27 septembre :

« Cela fait deux semaines (et même un peu plus – mais la semaine dernière c'était la conférence Linux et ensuite la Plumber conf donc j'ai rallongé de quelques jours) et comme d'habitude cela signifie que la période de merge est terminée. La RC-1 est disponible donc essayez-là.
Qu'est-ce que je peux dire ? 67% des changements concernent les pilotes (avec le plus gros concernant la branche staging mais il y a d'autres changements dans tous les sens), 10% les micrologiciels, 10% sont spécifiques aux diverses architectures (avec une domination de ARM mais aussi du MIPS, Power, SH, x86 et aussi la nouvelle architecture SCore), 5% de documentation et le reste réparti sur tous les autres trucs (systèmes de fichiers, noyau, réseau, etc).
Pour une fois je ne pense pas que nous ayons de nouveau système de fichiers… mais nous avons des mises à jour des systèmes existants (ocfs2, btrfs, nfs, nilfs, xfs, gfs2, ext4 – autant que vous voulez).
Certains des changements les plus intéressants (mais c'est peut être juste moi) concernent les machines virtuelles (le retour de ZERO_PAGE) et le travail de Jens et des autres sur le writeback.
Précipitez-vous, testez et informez-nous de chaque régression que vous trouvez ».

RC-3

Linus s'est un peu loupé sur le processus de sortie de cette RC-1 puisqu'il y avait dans le makefile, par erreur, la mention "RC-2" au lieu de "RC-1". Une fois informé, il a d'abord gémi :

« Oh nnooooooooooooo-(reprise de respiration)-ooooooooooooonnnn...
Putain. Je n'avais pas réalisé. Je suis vraiment un crétin ».

Puis, il a ensuite décidé de sauter l'étape RC-2 pour éviter les risques de confusion. Le 4 octobre, c'est donc directement une RC-3 qui a été annoncée :

« Oui, c'est vraiment la RC-3 parce que j'ai pris la décision de sauter la RC-2 complètement.
Enfin, pas complètement car, comme beaucoup de gens l'ont remarqué, j'ai été un peu négligent et la version RC-1 portait le nom RC-2 dans son fichier makefile. Le résultat, c'est que maintenant je ne veux pas faire une version RC-2 car les rapports de bugs seraient accueillis avec pas mal de confusion : "Est-ce que vous parlez de la RC-2 du makefile (c'est-à-dire la RC-1) ou de la vraie RC-2 ?".
Donc, j'évite complètement cette confusion et je considère que la RC-1 était aussi la RC-2 et donc, une semaine plus tard, nous voilà à la RC-3. Espérons que je ne vais plus avoir de "moment d'absence" comme ça. Quoique je suis certain de pouvoir saloper une livraison de beaucoup de façons différentes.
Bon, en ce qui concerne les changements cela a été assez calme. Le plus gros changement a été effectué sur le pilote réseau e1000 mais il y a aussi des mises à jour DRM (sur le nouveau pilote Radeon expérimental) et d'autres trucs.
Une chose qui mérite d'être mentionnée (même si c'est très petit) est qu'il y a eu des réglages sur la latence des entrées-sorties dans la couche en mode bloc (l'ordonnanceur CFQ). J'espère que cela constituera un changement notable et que les gens constateront un meilleur temps de réponse ».

RC-4

Le 11 octobre la RC-4 est apparue sur les serveurs :

« Nouvelle semaine, nouvelle RC. Environ 60% du patch se concentre dans un seul pilote SCSI Fibre channel gros et bouffi (ouais j'ai été a deux doigts de ne pas l'inclure du tout) et si vous regardez tous les pilotes et le répertoire arch/blackfin cela représente environ 97% du total des changements depuis la RC-3.
La prochaine RC sera vraiment plus petite, non seulement parce que je vais vraiment refuser ces pilotes-sortis-de-l'enfer mais, plus important, parce que cela va être une "petite semaine". Le sommet annuel du noyau s'approche et je ne veux pas sortir une version depuis Tokyo quand je serai abruti par le décalage horaire. ce sera donc certainement une RC-5 le jeudi ».

RC-5

C'est donc dès le 15 octobre, juste avant de s'envoler, que Linus a annoncé la sortie de la version candidate RC-5 :

« Comme mentionné dans les notes de la RC-4, cela a été une petite semaine pour cette version car je pars demain matin pour le sommet annuel du noyau. Évidemment beaucoup de mainteneurs sont déjà partis ou bien vont le faire sous peu donc je m'attends / j'espère que la semaine prochaine sera aussi calme.
90% des changements sont dans les pilotes avec en particulier deux nouveaux pilotes réseau (stmmac and vmxnet3). À part ça il y a environ 300 commits et la plupart sont des changements d'une ou de quelques lignes : (ARM, powerpc, x86), systèmes de fichiers (surtout btrfs), la documentation, le réseau, etc.
Quelques régressions de corrigées et, on l'espère, pas de nouvelle régression introduite ("Ouais, comme si ça n'arrivait jamais") ».

RC-6

Du fait de ces conférences lointaines dans des pays exotiques, il a fallu attendre un peu plus longtemps que la normale pour la RC-6 pointe le bout de son nez :

« Cela fait plus de deux semaines depuis la RC-5, en partie parce qu'il y a eu une semaine très tranquille car de nombreux développeurs (dont moi) étaient à Tokyo pour le sommet annuel du noyau. Il y a eu aussi un ennuyeux problème de corruption sur le système de fichiers ext4 après une extinction brutale.
Il s'est avéré que ce problème était "juste" parce que les sommes de contrôle avaient été activées en test sur les transactions du journal (en mode restauration). La correction a consisté à désactiver à nouveau cette fonction. Les développeurs ext4 vont maintenant passer une loooongue et dure période pour comprendre ce qui a causé ce problème sans même générer un printk d'alerte.
Merci beaucoup à Eric Sandeen qui a bissecté ce bug difficile à reproduire et à tous les gens qui ont aidé pour les tests. Une fois que cela a été identifié, la correction a été triviale mais les problèmes de corruption des systèmes de fichiers me rendent toujours très nerveux.
Il y a aussi de mises à jour d'architectures (powerpc, arm, ia64 et mips) et le reste consiste en petits changements, surtout dans les pilotes mais aussi dans la documentation ».

RC-7

Le 12 novembre, après une traque au bug haletante, Linus a annoncé que la version RC-7 était disponible sur les serveurs de kernel.org :

« Cette fois j'ai un peu retenu la RC car j'avais peur d'une horrible régression dans la fonction de sortie de veille sur laquelle Rafael était en train d'enquêter. Finalement au lieu d'être quelque chose de vilain et de fondamental cela s'est révélé être un bug trivial de pilote (ici "trivial" signifie "vilain et difficile à détecter mais n'impliquant pas le cœur du code").
Donc maintenant c'est corrigé ainsi que pas mal d'autres petites régressions ».

RC-8

Après une ultime version RC-8 de stabilisation Linus a publié le noyau 2.6.32 définitif.

Les nouveautés (↑)

Écriture des données par BDI

Après plusieurs mois de travail Jens Axboe a incorporé son travail permettant l'écriture des données par BDI.

Dit comme ça, cela semble assez ésotérique, mais si on se penche sur les détails de cette série de patchs alors on comprendra mieux les tenants et les aboutissants des efforts de Jens.

Quand les applications s'exécutant au dessus du noyau veulent écrire des données alors Linux place ces données dans un cache nommé "page cache". Au fur et à mesure que les données sont mises dans une queue d'entrées/sorties allant conduire à l'écriture sur le périphérique elles sont marquées par un indicateur dirty. Enfin les données étant vraiment en train d'être écrites sur le périphérique sont identifiées comme étant en writeback.

Vous pouvez voir ce qui se passe sur votre noyau à un moment donné en faisant un simple cat /proc/meminfo. Par exemple voici le résultat de cette commande sur ma machine (pour faciliter la lisibilité je n'ai laissé que les lignes qui nous intéressent) :
patrick@laptop:~$ cat /proc/meminfo
MemTotal: 2067360 kB
Cached: 1170880 kB
Dirty: 6496 kB
Writeback: 0 kB

Ma mémoire totale est de 2 Go, j'ai 1,17 Go en cache et il y a 6,5 Mo qui sont marqués comme dirty, c'est à dire qu'ils sont en chemin pour être écrits sur le disque. Enfin aucune écriture ne se fait en ce moment.

On comprend bien que ces données dirty et writeback sont donc très transitoires et qu'un cat /proc/meminfo s'effectuant quelques secondes plus tard donnera un autre résultat.

Pour passer de l'état dirty à l'état writeback les données doivent commencer à être effectivement écrites. Au temps du noyau Linux 2.4 c'était un seul processus, nommé bdflush, qui s'occupait de cette tâche.

Le noyau 2.6 a apporté une belle innovation avec pdflush puisqu'au lieu d'un processus unique on est passé à une architecture basée sur des processus légers noyau (entre 2 et 8) qui se chargent d'écrire les données. La règle est de commencer avec deux et d'attendre une seconde. Si les deux processus légers pdflush sont occupés alors un troisième est créé… et on continue ainsi jusqu'à huit. Si au bout d'une seconde un processus léger est resté inactif alors on le supprime et on peut ainsi redescendre jusqu'à deux.

Pour voir combien vous avez de processus légers pdflush s'exécutant actuellement sur votre machine faites donc un petit cat /proc/sys/vm/nr_pdflush_threads.

Bien qu'elle représente un progrès par rapport à l'antique bdflush du noyau 2.4, cette technique a également des limitations. Par exemple le groupe de processus légers (thread pool) est commun à tous les périphériques en mode bloc. Comme il doit donc travailler pour tous les périphériques en même temps, il ne lui est pas permis de bloquer sur l'un d'eux et il y a des situations où il ne peut satisfaire tout le monde (request starvation). Il existe également des périphériques très rapides qui voudraient qu'un groupe de processus légers leur soit entièrement dédié.

C'est ici qu'intervient le travail de Jens Axboe qui propose, au lieu d'un bête groupe commun de processus légers noyau, qu'il y ait un groupe de processus légers par périphérique (ou plutôt par BDI ce qui signifie Backing Device Info et qui représente une sorte d'abstraction au dessus des périphériques réels). Pour faire bonne mesure on monte à 32 le nombre de processus légers pouvant être créés dans les groupes affectés à chacun de ces BDI.

Avec cette nouvelle solution, il n'y a plus de risque de ne plus satisfaire les périphériques et les écritures peuvent s'effectuer plus rapidement puisque chaque processus léger (ou groupe de processus légers) d'un BDI peut se bloquer sur lui sans impacter les autres.

Jens Axboe, outre ses messages sur la liste de diffusion du noyau, a présenté son travail lors de la dernière Linux Plumber Conference et il existe également un fichier PDF très détaillé sur ce patch.

Le gain en performance apporté par cette technique d'écriture des données par BDI est assez important. Chris Mason a ainsi posté des graphiques concernant cinq disques SATA en LVM et formatés avec le système de fichiers XFS. Lors des écritures on passe de 277 Mo/s à 388 Mo/s. Jens indique que ses tests indiquent une amélioration de 8% pour un simple disque SATA et de 25% pour un ensemble de dix disques formatés en Btrfs.

Changements dans l'ordonnanceur CFS

Le noyau 2.6.32 propose de nombreux changements dans l'ordonnanceur CFS qui touchent les options par défaut et qui corrigent des dysfonctionnements. En effet l'arrivée du concurrent BFS, proposé par Con Kolivas, a provoqué une soudaine activité de tests et de comparaisons ce qui a permis d'améliorer CFS et l'ordonnancement des processus dans le noyau Linux.

Le premier changement concerne l'option CHILD_RUN_FIRST qui est maintenant à false. Cette option contrôle le comportement de l'ordonnanceur CFS juste après un fork, c'est à dire juste après la création d'un nouveau processus par un processus parent. Auparavant CFS passait la main le plus vite possible au processus fils, ce qui explique le nom de l'option CHILD_RUN_FIRST, et ce comportement avait été choisi à l'époque lointaine du noyau 2.4.4 (le patch date de 2001) avec l'idée que quand on fait un fork c'est pour exécuter un certain travail donc le processus fils doit passer devant.

Avec ce changement de comportement par défaut introduit dans le noyau 2.6.32 c'est maintenant le processus père qui garde la main ce qui, au vu des tests, améliore substantiellement les performances. Cela s'explique, entre autres, par le fait que le processus parent s'exécute déjà dans le processeur et que vider les caches (le TLB) pour faire de la place au processus fils prend du temps. Cela pouvait avoir du sens au moment du noyau 2.4.4 sur une machine simple processeur mais maintenant, à l'ère des double et quadri-cœurs, il vaut mieux garder le processus père sur le premier processeur et envoyer directement le fils sur un autre processeur et les tests montrent que c'est plus efficace.

L'opération "grand ménage de printemps" sur l'ordonnanceur a continué avec la désactivation par défaut de l'option NO_NEW_FAIR_SLEEPERS qui donnait un petit crédit de temps à un processus juste après son réveil. Ce changement améliore grandement l'interactivité des applications.

Un vilain bug de CFS sur des machines multi cœurs, évoqué dans ce journal Linuxfr, a également été corrigé grâce à Jason Garrett-Glaser qui est un développeur du codec x264. Celui-ci avait remarqué que BFS, le bébé de Con Kolivas, pouvait avoir jusqu'à 80% de performances en plus sur un codage x264 par rapport à CFS. Ce comportement pathologique ne pouvait s'expliquer que par un bug et il a donc posté sur la liste de diffusion du noyau un compte-rendu et une procédure pour reproduire le bug. Dès le lendemain un patch corrigeait le bug et améliorait les performances de CFS d'environ 70%. Dans les jours qui ont suivi un autre gain supplémentaire de 10% a été obtenu pour la plus grande joie de Jason (mais aussi des autres applications comme PostgreSQL ou MySQL ainsi que le démontre ce benchmark de Mike Galbraith).

Enfin, le dernier changement notable dans le code d'ordonnancement du noyau 2.6.32 concerne la gestion des phases de repos du processeur.

Actuellement, cette gestion est déléguée à un "gouverneur" qui détermine quand et comment le processeur doit s'endormir, changer de fréquence, se réveiller, etc. On croit souvent que l'algorithme de gestion d'un tel gouverneur est assez simple (pas de travail à faire : on s'endort ; du travail à faire : on se réveille et on monte la fréquence), mais en réalité c'est loin d'être le cas.

Il faut tenir compte du coût en énergie et en temps des transitions entre les nombreux états possibles des divers processeurs. Par exemple un processeur Intel de type T7300 met 100 nanosecondes à sortir de l'état de sommeil C2 et revenir à l'état normal C0. L'avantage c'est qu'en phase C2 il ne consomme que 30% de ce qui est consommé en C0. Si vous voulez économiser encore plus alors le processeur peut entrer en phase C4 ou la consommation est réduite à seulement 2% mais le désavantage est qu'il faut 160000 nanosecondes pour repasser en phase C0.

On voit donc que la politique à appliquer se doit d'être subtile et bien adaptée car, en réalité, le processeur n'a aucun moyen de savoir la quantité de travail qu'il va devoir effectuer à l'instant suivant. Le gouverneur est donc éternellement condamné à tenter de deviner, par des heuristiques ou des statistiques, ce qu'il y aura à faire à l'instant T+1.

Jusqu'à présent le code marchait "assez bien" mais le processeur Intel Nehalem, avec sa gestion de l'énergie particulière, a permis de mettre en évidence des problèmes dans ce code.

Après avoir réfléchi à la question et procédé à de longs tests, Arjan van de Ven a proposé un patch complexe destiné à améliorer les performances du gouverneur du noyau 2.6.32. Le code de ce patch est très commenté afin de permettre de comprendre comment se fait vraiment le calcul.

En résumé, Arjan est parti de l'idée que si le processeur ne peut pas deviner le futur, il peut au moins savoir à quel moment va avoir lieu la prochaine interruption programmée. Son algorithme calcule donc la différence entre ce qui avait été programmé (la borne supérieure donc) et l'interruption réelle ayant eu lieu parce qu'il y avait soudain du travail à faire. Le code d'Arjan maintient ainsi des statistiques à propos de cet écart moyen et il intègre aussi un facteur multiplicateur en fonction des entrées/sorties en cours ou en fonction de la charge de travail des processeurs. La formule donnant ce coefficient multiplicateur est "1 + 20 fois la charge moyenne du processeur (load_average) + 10 fois l'attente moyenne des entrées/sorties (iowait_count)".

Ce coefficient multiplicateur est alors appliqué à une table qui recense les temps de latence qui affectent les différents types de processeurs pour sortir de leurs différents états d'endormissement. Le résultat de tout ce calcul est alors comparé aux statistiques obtenues précédemment et le gouverneur d'Arjan prend finalement la décision d'endormir ou non le processeur en fonction de ce résultat.

Tout ceci peut sembler bien compliqué mais le résultat brut est très impressionnant puisque le benchmark fio utilisé par Arjan sur une machine à base de Nehalem donne ceci :

# Aucune gestion de l'énergie
1 disque 107 Mb/s
2 disques 215 Mb/s
12 disques 590 Mb/s

# Gouverneur actuel du noyau Linux
1 disque 85 Mb/s
2 disques 123 Mb/s
12 disques 320 Mb/s

# Gouverneur amélioré d'Arjan
1 disque 105 Mb/s
2 disques 209 Mb/s
12 disques 585 Mb/s

On voit bien que le gouverneur amélioré permet, tout en conservant les économies d'énergie de l'ancien gouverneur, de retrouver quasiment les mêmes performances qu'une machine qui tourne en permanence à la fréquence maximum ce qui constitue donc une belle avancée.

HWPOISON

Dans le contexte d'une gestion améliorée des barrettes de mémoire RAM défectueuses une solution technique innovante, le patch HWPOISON, a été incorporée au nouveau noyau.

Ce code permet d'aller au delà de la protection qui est permise par la technique ECC. Avec une mémoire protégée par ECC la protection n'est que très relative puisque cela permet de corriger une erreur quand elle affecte un seul bit mais qu'on doit se contenter d'une détection l'erreur, sans correction possible, quand l'erreur concerne deux bits. Comme cette double erreur est très susceptible d'entraîner un crash de la machine, la motivation des développeurs du noyau était forte pour essayer d'améliorer la situation.

L'idée générale est qu'une défaillance devrait tout au plus provoquer une invalidation de certaines zones mémoires et pas un horrible crash. De cette façon, l'erreur est contenue et ne peut plus affecter le reste de la machine.

Andi Kleen a donc travaillé sur le patch HWPOISON afin d'implémenter cette idée qui marche de la façon suivante (si le noyau a été compilé avec l'option MEMORY_FAILURE) : le processeur détecte une erreur non corrigible et, au lieu d'envoyer une demande de seppuku au noyau, se contente de mettre un indicateur sur cette zone mémoire afin de se souvenir qu'elle n'est plus fiable (d'où le nom du patch, la page mémoire est considérée comme "empoisonnée"). La machine peut ainsi continuer à fonctionner normalement, jusqu'à ce qu'un processus quelconque veuille lire ou écrire dans cette zone mémoire empoisonnée. On évite ainsi le crash qui était inévitable auparavant.

Quand un processus réclame l'accès à la page mémoire empoisonnée, c'est le code HWPOISON qui intervient afin de décider ce qu'il faut faire. Il peut introduire un délai afin de voir si l'erreur mémoire n'était que transitoire (ce qui arrive assez souvent) et réessayer plus tard. Il peut aussi essayer d'isoler la page mémoire en erreur pour protéger les applications et recharger les données si une copie non modifiée existe sur le disque. Enfin, le code HWPOISON peut prendre la difficile décision, pour sauver le système d'exploitation, de tuer les processus affectés par l'erreur mémoire (assassinat précoce, si on utilise l'option vm.memory_failure_early_kill et assassinat après un délai de grâce, si on utilise l'option vm.memory_failure_recovery).

Une limitation de HWPOISON est que cette technique nécessite une coopération entre le noyau et le processeur sous-jacent. Seuls des processeurs dotés de fonctions spéciales de détection et d'isolation, MCA pour Machine Check Abort, pourront donc en profiter (le très récent Intel Nehalem-EX fait partie de la liste). Actuellement le patch n'est compatible qu'avec les machines x86 et x86-64 mais comme les processeurs SPARC et IA-64 sont dotés des mêmes raffinements techniques il est fort probable qu'ils profiteront eux-aussi bientôt de HWPOISON.

Gestion dynamique de l'énergie

Une grosse nouveauté introduite dans le noyau 2.6.32 est le patch de gestion dynamique de l'énergie (runtime power management) proposé par Rafael Wysocki.

Selon Rafael, on peut considérer la mise en veille de la machine comme un problème résolu et, en ce qui concerne les phases de travail de l'ordinateur, la gestion d'énergie du processeur est très efficace...alors que reste-il à faire dans ce domaine ?

L'idée derrière son patch est de s'attaquer, par un code unifié, aux divers périphériques d'entrées/sorties qui jusqu'à présent ne bénéficiaient pas d'une bonne gestion de l'énergie.

Rafael a implémenté une infrastructure centralisée de gestion de l'énergie qui permettra de mettre en veille et de rallumer à la volée les divers périphériques d'une machine afin de gagner en consommation d'énergie. Ce travail de fond a été tout particulièrement scruté par les développeurs du noyau puisqu'il y a eu plus de 17 révisions depuis la proposition initiale de Rafael. La nouvelle infrastructure est décrite en détail dans la documentation technique et elle consiste à ajouter, pour chaque type de bus d'entrées/sorties, des fonctions que va pouvoir utiliser le noyau et les pilotes des périphériques. Un appel à la fonction runtime_suspend() basculera le périphérique en mode veille et il ne reviendra à la vie qu'à la suite d'un runtime_resume()/

Il est à noter que ce travail sera sans doute complété dans les noyaux suivants par une réécriture et une adaptation des divers pilotes afin de profiter pleinement de cette nouvelle infrastructure de mise en veille à la volée.

Gestion d'intégrité TXT

Le mécanisme de gestion d'intégrité TXT d'Intel a été ajouté dans le noyau 2.6.32.

Cette fonction ne doit pas être confondue avec l'architecture de contrôle d'intégrité (IMA pour Integrity Management Architecture) qui a fait son entrée dans le noyau 2.6.30 et qui s'occupait de faire vérifier par le noyau que des fichiers ou des exécutables n'avaient pas été modifiés. Mais évidemment IMA, en tant que mécanisme faisant partie du noyau, repose sur la confiance qu'on accorde au noyau lui-même quand il procède à la vérification. Comment être certain que le noyau n'a pas été compromis ?

C'est ici qu'entre en scène la nouvelle gestion d'intégrité basée sur TXT (Trusted Execution Technology). L'idée d'Intel est d'interposer un petit hyperviseur entre le noyau et le matériel. Cet hyperviseur se nomme tboot (pour Trusted Boot) et il constitue le cerbère qui va vérifier toutes les étapes de lancement du noyau Linux. Son fonctionnement est détaillé dans ce message de Joseph Cihula mais l'idée générale est la suivante : Grub lance tboot comme si c'était le noyau normal et tboot vérifie ensuite que le matériel gère bien la technologie TXT de gestion d'intégrité. Si ce n'est pas le cas, le noyau est lancé sans plus aucun contrôle. Si TXT est bien présent sur la carte mère, alors tboot vérifie toute la chaine logicielle depuis le BIOS, les micrologiciels, etc jusqu'à ce que le noyau soit effectivement lancé. Cette vérification de tous les maillons de la chaîne de confiance se fait par comparaison avec des empreintes (hash) présentes dans la puce de stockage sécurisée (TPM pour Trusted Platform Module). Il est également possible, à l'aide d'un fichier indiquant les préférences de l'utilisateur (user-defined launch policy), de modifier le comportement de tboot.

tboot refait surface lors des mises en veille ou en hibernation, car il fait des signatures cryptographiques des prises d'empreintes (hash) de la mémoire. Cela permet d'éviter une attaque sur le noyau qui serait effectuée durant ces phases d'hibernation de la machine.

La gestion d'intégrité basée sur TXT peut certainement constituer une couche de protection intéressante pour certains utilisateurs, mais il est probable que tout le monde ne sera pas ravi de l'utiliser. Le pilote de la carte compatible TXT est un binaire signé par Intel (Q35_SINIT_17.BIN) et le code gérant le matériel à très bas niveau (system management mode ou SMM) n'est lui non plus pas disponible, ce qui inquiétera les plus paranoïaques d'entre nous.

devtmpfs

Un ajout assez controversé au noyau 2.6.32 est celui de devtmpfs par les développeurs Kay Sievers et Greg Kroah-Hartman.

Aux temps anciens et vénérables (avant 2003), le noyau Linux utilisait un mécanisme nommé devfs qui était chargé d'énumérer, dans un système de fichiers spécial, tous les périphériques d'entrées/sorties présents sur la machine. Devfs était vu comme un progrès par rapport à un répertoire /dev statique, mais il n'était pas sans poser - lui aussi - des problèmes épineux. Outre sa grande complexité, avec devfs chaque périphérique avait un nom différent (non persistant) en fonction de son ordre de détection, la politique de nommage faisait partie du noyau, devfs ne respectait pas la norme LSB et enfin de nombreuses situations de compétition (race conditions) venaient fragiliser le système.

Pour sortir de ce guêpier, il a été décidé de ne plus utiliser devfs et de s'en remettre à un démon en espace utilisateur nommé udev développé notamment par Greg Kroah-Hartman. Avec lui, on peut répondre a toutes les déficiences de devfs puisque la lourde politique de nommage est sortie du noyau, que les noms sont persistants quel que soit l'ordre de détection, que la norme LSB est complètement respectée, que le démon, puisqu'il vit en espace utilisateur, peut être mis en swap, etc.

La situation avec udev était donc bien meilleure qu'avant… c'est pourquoi l'annonce d'une sorte de retour de devfs dans le noyau a surpris tant de monde et a provoqué tant de chaudes discussions sur les listes de diffusion !

Alors, comment fonctionne devtmpfs et quel est le raisonnement qui a poussé ses auteurs a écrire leur code ? Selon l'explication donnée par Kay Sievers, et comme on peut facilement le deviner en voyant son nom, devtmpfs s'appuie en fait sur un fichier temporaire tmpfs qui n'est utilisé que pour l'énumération des périphériques le plus tôt possible par le noyau, lors de l'amorçage. L'avantage est que pour les environnements embarqués et, tout en gardant le caractère dynamique de /dev, il n'y a pas de nécessité d'attendre le lancement d'un lourd démon en espace utilisateur. Comme en plus, udev peut reprendre la main à la suite de devtmpfs et profiter de son travail, les utilisateurs normaux vont profiter d'une amélioration du temps d'amorçage.

C'est d'ailleurs cette dernière qualité qui a été mise en avant par Greg Kroah-Hartman quand Andrew Morton, après avoir accueilli le patch initial d'un ironique "Lol, devfs", lui a demandé quelle était la justification de devtmpfs : « Boot speed, boot speed, boot speed. Oh, et aussi réduction de la complexité des scripts d'init et épargner aux systèmes embarqués le fait de devoir implémenter correctement un /dev dynamique ».

En dépit des objections de Christoph Hellwig et d'Eric Biederman le code de devtmpfs a été incorporé dans le nouveau noyau par Linus. Outre les contre-arguments présentés par Greg il est probable que Linus a été sensible au fait que les distributions semblaient intéressées par cette fonction (SuSE l'utilisant même depuis longtemps en tant que patch externe) et que le code était sans aucun impact sur le reste du noyau et tout petit (à peine 300 lignes de code).

Devtmpfs est donc loin d'être le retour du cauchemar qu'avait fini par représenter devfs pour les développeurs du noyau. C'est plutôt une nouvelle possibilité, propre et non intrusive, qui est offerte aux utilisateurs de Linux.

Kernel Shared Memory

La fonction KSM (pour Kernel Shared Memory) a été ajoutée au noyau 2.6.32 et va permettre de réduire la consommation mémoire des machines utilisant la virtualisation KVM.

L'idée de départ de ce travail est simple à comprendre. Sur une machine hôte qui héberge de nombreuses instances virtuelles KVM, il est fort probable – pour ne pas dire certain – que les instances invitées vont utiliser de nombreuses pages mémoires pour stocker des données identiques. Cette duplication des données est un gaspillage et les développeurs du noyau ont décidé de s'y attaquer.

La première idée a été de prendre une empreinte (hash) des pages mémoires et, au cas ou plusieurs pages se révèlent identiques, de les fusionner en mode copy-on-write afin qu'elles n'occupent plus qu'une fraction de l'espace précédent. Bien entendu dès qu'une instance virtuelle modifie une page alors une séparation automatique a lieu (d'ou l'utilité du copy-on-write).

Cette première approche posait deux problèmes. En premier lieu, si une collision de hash pouvait être générée par un attaquant alors l'hôte des machines virtuelle ne pourrait plus garantir leur séparation totale. Le second problème est que la société VMWare, en dépit du fait que cette technique existait auparavant en tant que patch externe au noyau 2.2.9, avait déposé un brevet sur la technique de comparaison par prise d'empreintes visant à fusionner les pages mémoires.

Plutôt que de se lancer dans une longue bataille juridique, propre à engraisser des bataillons d'avocats, les développeurs de KSM ont décidé de changer leur fusil d'épaule et de ne plus utiliser de prise d'empreintes. De cette façon, pas de risque de collision et pas de risque non plus d'avocats scandaleusement engraissés.

La nouvelle technique utilise deux arbres binaires de recherche, plus spécifiquement deux arbres bicolores, où sont stockées les informations qui vont permettre la fusion des pages. Le premier, l'arbre instable, est utilisé pour lister les pages susceptibles d'être fusionnées (on utilise la fonction memcmp pour comparer les données) et le second arbre, le stable, stocke les pages effectivement partagées entre les instances virtuelles.

Ce partage est complètement transparent pour les processus car c'est un partage dynamique qui scanne périodiquement les pages mémoire afin de reconstruite l'arbre instable. L'arbre stable de son côté est… hem… stable et il n'est donc pas reconstruit régulièrement. Le noyau se contente de le mettre à jour quand une séparation de page est nécessaire.

Si on veut profiter du Kernel Shared Memory en dehors du cas d'une virtualisation, par exemple parce que de nombreux processus partagent les mêmes données, il est possible à une application de faire un appel direct à KSM afin de lui demander d'activer sa fonction de fusion de pages.
En outre, précision importante pour les gens qui n'ont pas l'utilité de cette fonction, l'ajout de KSM n'a aucun impact sur les performances si le code n'est pas activé. Comme expliqué dans l'annonce du patch cette activation s'effectue avec un simple echo 1 > /sys/kernel/mm/ksm/run.

Les développeurs de KSM ont écrit un article de présentation détaillée, disponible au format pdf, pour le dernier sommet Linux. Dans cet article on apprend que le CERN utilise déjà KSM pour la grille de calcul qui a été mise en place afin d'analyser les données du LHC (Large Hadron Collider). Comme les jobs d'analyse et de reconstruction des collisions de protons partagent de nombreuses données, il est intéressant d'activer KSM afin d'économiser la mémoire.

Quand deux jobs de 2 Go sont lancés, il est possible de partager 750 Mo de données avec KSM (seulement 250 Mo sans KSM). Les ingénieurs du CERN signalent ainsi que sur une machine typique ayant 4 Go de RAM, on peut faire tourner 3 jobs au lieu de 2 en temps normal. Un gain significatif quand on connaît le déluge de données que va générer le LHC !

API des pilotes réseau

Enfin, dernière nouveauté détaillée ici, l'API des pilotes réseau a été modifiée afin de permettre d'unifier les codes retour. Ce changement n'est pas très important ni très intéressant en lui même et il n'a strictement aucune conséquence sur les performances… alors pourquoi en parler ?

En réalité ce commit de Stephen Hemminger est une belle illustration de la puissance du modèle du logiciel libre et c'est pour cette raison qu'il mérite qu'on s'y attarde.

La fonction ndo_start_xmit() est utilisée par la pile réseau du noyau pour passer un paquet au pilote de la carte réseau et il ne devrait y avoir que deux résultats possibles en retour. Soit un NETDEV_TX_OK pour dire que tout s'est bien passé et que le paquet a été accepté par le pilote, soit un NETDEV_TX_BUSY pour signifier au noyau que le pilote était occupé ailleurs et qu'il va falloir songer à renvoyer le paquet.

Le problème c'est que le type du code retour a été défini en int et donc que certains pilotes utilisent, vicieusement, cette possibilité pour renvoyer des codes erreurs barbares au noyau alors que celui-ci attend juste un OK ou un BUSY.

La solution, dans le monde du logiciel libre, est très simple. On change le type int en type enum qui contient juste les codes retour attendus par le noyau. Ensuite on change tous les pilotes réseau présents dans le noyau afin de prendre en compte cette modification. Comme les pilotes sont libres et font directement partie du noyau un tel changement est certes fastidieux mais facile à faire.

Dans le monde propriétaire, où les pilotes ne sont bien souvent pas dans le système d'exploitation de base et doivent être téléchargés sur le site du constructeur de la carte réseau, un tel changement serait impossible ou bien exigerait d'immondes hacks au détriment de la simplicité et de l'élégance du code.

Pour Greg Kroah-Hartman, qui s'exprime dans un entretien publié sur le site "How Software is Built", c'est cette optimisation permanente des API qui explique la qualité du code Linux et la vitesse de son évolution :

« Notre pilote pour Linux représente seulement un tiers de la taille du pilote Windows donc, même avec un tel taux de changement, écrire un pilote pour Linux, c'est moins de travail que ça ne l'est pour les autres systèmes d'exploitation.
Dans Linux, nous avons réécrit la pile USB trois ou quatre fois. Windows a fait la même chose, mais ils doivent garder toutes les vieilles piles USB et aussi un paquet de vieux code, afin que les anciens pilotes puissent fonctionner. Donc leur charge de maintenance ne fait qu'augmenter avec le temps, alors que ce n'est pas le cas pour la nôtre ».

Encore une illustration de la salubrité de ce modèle de développement libre choisi par les développeurs Linux et une occasion de relire le fameux texte de Greg Kroah-Hartman sur l'inanité des API stables.

En bref (↑)

  • Le système de fichiers Btrfs, qui représente le futur du monde Linux, continue d'être amélioré dans cette nouvelle version du noyau. Par exemple la fiabilité des réservations d'espace est meilleure, la rapidité des suppressions d'instantanés (snapshots) est radicalement améliorée (la suppression se fait maintenant en parcourant le btree au lieu d'utiliser un bête rm -rf). On note aussi que la vitesse d'écriture, qui était bloquée à 400 Mo/s jusque là, peut maintenant dépasser le Go par seconde (il vous faudra toutefois une belle collection de disques pour atteindre un tel chiffre ;-)

  • Le système de fichiers virtuel sysfs, utilisé pour présenter des informations sur les périphériques aux applications vivant en espace utilisateur, prend maintenant en charge les labels de sécurité. Comme ces labels sont le coeur des modules de sécurité SELinux et SMACK il est donc possible de se servir de ces modules pour implémenter des restrictions fines sur le contenu de ce systèmes de fichiers virtuel.

  • La pile Wi-Fi mac80211 du noyau Linux 2.6.32 est désormais capable de faire du balayage (scanning) en tâche de fond. Le patch, qui est également évoqué par Dan Williams dans son blog, permet au noyau de faire un balayage de tous les point d'accès (AP) sur environ 30 secondes en revenant à chaque instant (selon le résultat de SCAN_DECISION) sur l'AP connecté afin de ne pas impacter le trafic actuel. Cette nouvelle fonction, qui génère donc une liste actualisée des points d'accès potentiels, est utile aux services de géolocalisation mais elle va surtout permettre d'améliorer l'itinérance (roaming). Grâce au balayage en tâche de fond on peut plus facilement basculer sur un nouveau réseau, ou sur un nouvel AP au sein du même réseau, car la liste est toujours mise à jour.

  • Afin de faciliter la compilation du noyau Linux il est maintenant possible de faire un "make localmodconfig" et le nouveau noyau compilé reprendra les modules qui sont actuellement chargés dans le noyau local. Si on préfère tout construire en dur il suffit d'utiliser "make localyesconfig" et les modules du noyau actuel seront compilés dans le nouveau noyau.
    Il devient plus facile que jamais d'essayer un noyau amont afin de rapporter les bugs sur la liste de diffusion !

  • Jens Axboe a modifié l'API des périphériques en mode bloc. Maintenant, comme pour la pile réseau, il est possible de travailler sans s'appuyer sur des interruptions mais en utilisant uniquement le polling (qui consiste a vérifier en permanence l'état du périphérique). Le polling, pour qu'il soit une stratégie efficace, nécessite que du travail soit en permanence à faire dans la pile des entrées/sorties. Si c'est le cas, comme pour les lecteurs SSD qui sont capables de générer des dizaines de milliers d'IOPS, alors se passer des interruptions et utiliser le polling est une stratégie gagnante. La fonction s'active quand le périphérique fait un appel à blk_iopoll_enable et Jens rapporte les résultats d'un benchmark ou le nombre d'interruptions passe de 76000/s à seulement 55000/s.

  • La couche AHCI, qui permet de communiquer avec le contrôleur de bus SATA, peut maintenant exporter vers les applications différentes informations sur les capacités des périphériques. Le commentaire du patch mentionne ainsi le fait qu'il devient possible de signaler facilement, par l'intérmédiare de sysfs, qu'un port est utilisable à chaud ou pas, qu'il est utilisable pour les périphériques eSATA ou encore qu'il est conforme à la norme d'économie d'énergie ALPM (Aggressive Link Power Management).

  • L'ordonnanceur des entrées/sorties CFQ a été quelque peu modifié afin d'améliorer l'interactivité des processus. Comme l'explique Jens Axboe dans son commentaire sur le site LWN ce changement est effectué, un peu contre-intuitivement, en empilant "moins agressivement" les écritures asynchrones. De cette façon les applications sont moins affectées par les écritures qui se déroulent en arrière plan et leur réactivité s'en trouve améliorée.

  • Une nouvelle option de configuration du noyau, nommée MULTICORE_RAID456, permet de distribuer la gestion des disques RAID entre différents processeurs. Par exemple en mode RAID 5, où les volumes sont agrégés par bandes (stripe), il est maintenant possible d'affecter une bande par processeur de façon à répartir la charge. Comme l'indique le commit ce code est encore considéré comme expérimental.

  • Le travail d'optimisation du systèmes de fichiers ext4 se poursuit dans le noyau 2.6.32. Ted Ts'o a introduit la possibilité de faire des opérations de writeback de plus de 4 Mo. Cette limitation venait du fait qu'ext4 avait une limite de writeback à 1024 pages de 4 Ko. L'exemple d'XFS, qui peut faire des writeback par morceau de 16 Mo, a montré que cette limitation à 4 Mo était néfaste. Après plusieurs tests et benchmarks Ted a introduit une nouvelle option dans le système de fichiers afin de choisir la taille du writeback. L'option est nommée max_writeback_mb_bump et elle est paramétrée par défaut sur 128 Mo.

  • La fonction fcntl() qui sert à manipuler un descripteur de fichiers a été étendue par deux nouvelles options. Alors que F_GETOWN et F_SETOWN servaient respectivement à obtenir ou a forcer l'identifiant d'un processus recevant des entrées/sorties, le noyau 2.6.32 propose maintenant des options supplémentaires F_GETOWN_EX et F_SETOWN_EX. Avec ces opérations on peut maintenant obtenir ou forcer les entrées/sorties dans un thread particulier au sein d'un processus multithread. Bien entendu ces options sont également présentes dans la GNU libc maintenue par Ulrich Drepper.

  • Toujours dans les options nouvelles offertes aux développeurs pour créer des applications optimisées, on relève des changements dans les fonctions d'horloge et de temps du noyau Linux 2.6.32. En plus des horloges classiques CLOCK_REALTIME (qui est configurable) et CLOCK_MONOTONIC (qui n'est pas configurable) on a maintenant CLOCK_REALTIME_COARSE et CLOCK_MONOTONIC_COARSE. Comme "coarse" signifie "grossier" ou "peu précis" on se doute déjà de ce qu'apportent ces nouvelles horloges. Les applications qui ont besoin très rapidement d'une information de temps (au détriment de la précision) peuvent faire appel à ces horloges. On évite ainsi tout accès au matériel et même, en utilisant VDSO, tout appel système coûteux. Comme le dit John Stultz qui est l'auteur du patch: « Avec cette méthode les applications peuvent choisir au cas par cas le compromis approprié entre la précision et la vitesse ».

  • La développeuse allemande Stefani Seibold a soumis un patch qui complète et améliore la présentation des données incluses dans le système de fichiers virtuel procfs. Les changements sont listés dans le message de commit et, parmi eux, on relève qu'il est maintenant possible de voir la consommation mémoire de la pile d'exécution (stack usage) en allant lire la dernière ligne d'une commande "cat /proc/PID_du_processus/status".

  • Le tampon mémoire chargé d'empiler les écritures lors de l'examen poussé d'un noyau (tracing) a été entièrement réécrit. L'ancien ring-buffer était handicapé par des verrous qui faussaient en partie les statistiques sur les écritures se déroulant dans le noyau. Le nouveau tampon est complétement débarrassé des verrous (lockless ring-buffer) et le tracing du noyau est désormais bien plus fiable. Ce travail très complexe (prenez un double doliprane avant d'aller lire la documentation) a donné lieu à un dépot de brevet par Steven Rostedt qui travaille chez Red Hat. La politique de cette compagnie étant claire sur ce sujet on peut considérer que ce brevet est maintenant une arme de rétorsion en cas d'attaque sur les logiciels libres.

  • L'impressionnant outil graphique timechart, développé par Arjan van de Ven, a été incorporé au noyau. Cet outil se base sur perfcounters et, un peu comme bootchart, permet de générer des fichiers SVG pour mieux visualiser des situations complexes se déroulant sur la machine. Avec timechart, il est possible de zoomer à l'infini dans le SVG pour augmenter le niveau de détail et comprendre l'origine des latences dans de nombreuses situations.

  • Le mode KMS (Kernel Mode Setting) qui était entré dans le noyau 2.6.31 pour les modèles anciens est maintenant compatible avec les cartes Radeon de type R600 et R700 (c'est essentiellement le même type de carte avec juste des petites améliorations pour les R700). Attention cette prise en charge est assez préliminaire et il faudra sans doute attendre les noyaux suivants pour que les choses se stabilisent vraiment.

  • Les machines dotées de plusieurs cartes en interface VGA peuvent maintenant coopérer avec de multiples serveur X afin d'offrir un environnement multi-sièges de meilleure qualité. Cela s'effectue par l'intermédiaire d'un arbitre VGA (VGA Arbiter) qui s'occupe de router les informations vers chacun des serveurs X. Cette fonction, importante par exemple pour les écoles ayant des machines anciennes, nécessite un serveur X au moins en version 1.7.

  • Toujours dans le domaine graphique le pilote Intel i915 permet maintenant de réduire dynamiquement la fréquence de la carte graphique quand la charge de travail est réduite. Si on ajoute à ça la compression automatique du framebuffer (qui selon Jesse Barnes fait gagner un demi watt sur la consommation de la carte), on a un belle avancée pour les ordinateurs portables à base de processeur graphique Intel.

  • La seconde version de l'API vidéo du noyau Linux, sobrement nommée Video4Linux2, gère maintenant grâce à ce commit, les normes de télévision numérique ISDB-T et ISDB-S. Ces normes sont utilisés notamment au Japon et en Amérique du sud (Brésil, Argentine, Chili, etc.) et leur intégration dans le noyau va permettre l'utilisation dans ces pays des cartes de réception TV ISDB.

  • La version 4.0 de la norme de gestion de l'énergie ACPI prévoit la possibilité de mettre au repos forcé un processeur en cas d'urgence (surchauffe en dépit d'une réduction de la fréquence ou autre).
    La norme (attention gros pdf !) intitule cette fonction "Processor Aggregator Device" et il faut reconnaitre que c'est une façon bien plus intelligente de faire face à un évènement inattendu que d'obliger le serveur à s'éteindre. Attention il ne s'agit pas de retirer complètement de la circulation le processeur par un appel à la fonction hotplug. Ici on veut pouvoir reprendre le travail qui était en cours avant la surchauffe et il faut donc simplement que le processeur cesse de travailler (se mette dans l'état idle).
    Le développeur Len Brown à commencé par proposer une modification de l'ordonnanceur CFS pour implémenter cette fonction mais il a été renvoyé dans ses buts car c'est un changement trop complexe à insérer dans CFS pour une fonction qui sera peu utilisée. La solution adoptée est de créer un pilote ACPI spécialement dédié à cette fonction. Ce pilote va, en cas de surchauffe, générer un processus léger temps-réel (priorité maximum et ordonnancement SCHED_RR) qui va passer devant tous les autres pour prendre la main sur le processeur afin de le mettre au repos. Une fois l'alerte thermique passée le processus léger s'éclipse et le processeur se remet à travailler comme avant. Cette solution du pilote ACPI dédié a fait lever quelques sourcils mais Linus a apprécié le pragmatisme de l'approche : "Pourquoi diable devrions-nous ajouter une logique complexe comme ça dans l'ordonnanceur ? Tel qu'il est le pilote est indépendant et il n'affecte aucun autre sous-système".

  • La puce Qualcomm MSM/QSD du smartphone Android HTC Dream (ou HTC G1) est maintenant prise en charge par le noyau Linux officiel. Divers autres pilotes destiné au HTC Dream, par exemple pour l'appareil photo ou la puce DSP ou encore l'écran tactile, entrent également dans le noyau 2.6.32. Ce code est intégré par des développeurs employés par Google et c'est une bonne chose de voir que la coopération avec la branche principale s'améliore… cependant, on note que ces derniers pilotes font seulement partie de la branche -staging et qu'il reste donc du travail pour les amener aux standards de qualité du reste du code.

  • Après l'arrivée dans le noyau 2.6.29 de la technique du Read-Copy update hiérarchique (Tree RCU) il a été décidé que l'ancien code (RCU classique et RCU preempt) n'avait plus de justification réelle et pouvait être retiré du noyau. Le même sort funeste a été réservé au code des "kernel markers" qui n'est plus utilisé depuis que tracepoints est utilisé à la place.
    Et hop, quelques milliers de lignes en moins, c'est important aussi de faire le ménage !

  • Vous serez sans doute heureux d'apprendre que votre mainframe IBM S390 a maintenant la possibilité d'envoyer un dernier cri d'agonie en cas de crash du noyau. En effet, ces machines ont une spécificité matérielle qui leur permet de signaler un kernel panic en envoyant une notification (et une trace complète du crash) au service client IBM avec lequel vous avez un contrat. Cette fonction, astucieusement nommée "Call home", est activable sous Linux par l'option de configuration CONFIG_SCLP_ASYNC.

  • Dans l'océan de modifications concernant l'architecture ARM on peut noter que le jeu d'instruction Thumb-2, une mise à jour du jeu d'instruction dense Thumb, est maintenant complètement pris en charge par le noyau 2.6.32. The Thumb-2 est notamment utilisé dans tous les processeurs ARM modernes comme le ARMv7 ou le Cortex-M3. Contrairement à Thumb qui se limite à des instructions sur 16 bits pour économiser au maximum la mémoire, le Thumb-2 permet aussi d'utiliser des instruction 32 bits. Selon ARM on obtient ainsi le meilleur des deux mondes en conciliant les performances et la densité du code.

  • En ce qui concerne les architectures SPARC, la grande nouveauté du noyau 2.6.32 est la prise en charge complète des processeurs LEON. Ces processeurs sont à la norme SPARC V8 mais il sont très particuliers, car ce sont des processeurs sous licence libre (plus exactement leur description en VHDL est sous une licence libre, la GPL pour le LEON3). Ces processeurs LEON ont été conçus par l'Agence Spatiale Européenne afin de pouvoir embarquer sur les satellites et les sondes de l'ESA. Une version LEON3-FT (Fault Tolerant) est ainsi disponible et si votre sonde doit s'aventurer dans un environnement à haute radiation comme autour d'Europe, la très fascinante lune de Jupiter, alors vous pouvez compter sur le LEON3FT-RTAX pour survivre jusqu'à 3000 Gray.
    Linux: To infinity and beyond !


Le bilan en chiffres (↑)

Côté statistiques, l'habituel article récapitulatif du site LWN est disponible et on pourra également se reporter au site dédié aux statistiques du noyau Linux.
Pour le noyau 2.6.32 le nombre de patchs était de 10 944 au 2 décembre (10 814 pour le 2.6.31). C'est donc un cycle tout à fait typique qui a eu lieu ces trois dernier mois.
Il faut tout de même se forcer à garder à l'esprit que le rythme de changement de Linux est incroyablement rapide et sans commune mesure avec ses concurrents quels qu'ils soient. En effet un rapide calcul prenant en compte le nombre de jours nous séparant de la sortie de la version précédente (83 jours) et le nombre de lignes modifiées dans le noyau 2.6.32 (1 785 732) aboutit au chiffre ahurissant de 15 changements de lignes de code noyau par minute et ce 24h sur 24 et 7 jours sur 7.

Le nombre de développeurs ayant contribué au nouveau noyau s'établit à 1 240 (en augmentation par rapport aux 1 151 du noyau 2.6.31) et on voit sur le graphique du bas que sur le long terme la croissance reste soutenue. Une nouveauté intéressante disponible sur la page des contributeurs est l'indication de leur nationalité (la colonne de droite). Selon ce classement le premier contributeur français est Éric Dumazet...mais on peut s'interroger sur la fiabilité de cette classification quand on voit que Paul Mundt, un canadien vivant au japon, est considéré comme japonais.

Une petite polémique a débuté entre les lecteurs de l'article Linux Weekly News à propos du classement par entreprise. Si le haut du classement reste stable, avec juste un petit recul relatif de Red Hat, on peut constater que Microsoft fait son entrée dans la liste des contributeurs du noyau. C'est bien entendu l'inclusion des quelques 20 000 lignes du pilote Hyper-V dans la branche -staging qui fait ainsi entrer Microsoft en dix-septième position de la liste. Cette entrée est utilisée par certains commentateurs pour se moquer de la faible contribution de Canonical au noyau (trentième position en nombre de lignes). D'autres intervenants soulignent le fait que Canonical contribue plus dans les couches hautes de l'écosystème du libre (dans Gnome par exemple) et qu'il vaut mieux une seule ligne de code noyau utile plutôt que 20 000 lignes pour faire tourner des instances Linux sur un système d'exploitation propriétaire.

En tout cas, le contrôle du noyau est toujours fermement entre les mains des mêmes personnes puisque la répartition des tags "signoffs" (les tags qui autorisent ou pas l'entrée du code dans la branche principale) reste la même. Les cinq principales entreprises qui emploient les auteurs des tags "signoffs" restent Red Hat, Novell, Intel, Google et IBM. Si on compte ces autorisations d'intégration de patchs, on constate que ces cinq firmes majeures représentent environ 72% des autorisations (68,5% dans le noyau 2.6.31).

Pour la suite (↑)

En ce qui concerne les futures nouveautés des prochaines versions du noyau on peut se tourner vers la page spécifique de la Fondation Linux.

fsnotify

L'infrastructure de notification fsnotify, qui avait fait son apparition dans le noyau 2.6.31, a toujours été conçue par son développeur comme devant déboucher sur un module de scan de fichiers nommé fanotify. En dépit des patchs d'Eric Paris il ne lui a pas été possible d'intégrer fanotify dans le noyau 2.6.32, mais on peut parier qu'il tentera à nouveau sa chance lors de l'ouverture de la prochaine fenêtre de merge. Il est cependant à noter que fanotify ne déchaîne pas l'enthousiasme des foules en délire. Beaucoup de développeurs considèrent que que le scan de fichiers, utilisé comme technique de sécurité, est fondamentalement une mauvaise solution. La guerilla est donc rude sur ce sujet et comme en plus il existe d'autres critiques techniques, il va falloir qu'Eric se montre très convaincant s'il veut que son bébé intègre le noyau.

AppArmor

AppArmor, le module de sécurité basé sur le chemin que l'on croyait mort et enterré depuis le licenciement de ses développeurs par Novell, a refait une apparition sur la LKML. L'arrivée de TOMOYO dans le noyau 2.6.30 a démontré qu'il était possible à un module de sécurité basé sur le chemin (pathname-based) d'entrer dans la branche principale et que la vie ne se restreignait pas à SELinux et Smack. AppArmor est réputé plus simple à utiliser que les modules basés sur des labels et cela explique peut-être son intégration dans la distribution Ubuntu. Canonical a donc intérêt à ce qu'AppArmor intègre officiellement Linux car cela fera un patch externe de moins à maintenir (et cela redorera son blason de contributeur au noyau). C'est donc John Johansen, employé par Canonical, qui a proposé une série de 12 patchs sur la LKML afin de tâter le terrain et de voir quelles sont les perspectives à ce sujet. Pour l'instant les réactions sont peu nombreuses mais nul doute qu'une fois de plus le combat pour l'intégration va être rude.

Aller plus loin

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.