URL: https://linuxfr.org/news/le-noyau-linux-est-disponible-en-version-30
Title: Le noyau Linux est disponible en version 3.0
Authors: patrick_g
 
Date: 2011年06月25日T08:20:49+02:00
License: CC By-SA
Tags: kernel, linux, grsecurity, selinux, lwn, btrfs et noyau_linux
Score: 157
La sortie de la version stable 3.0 du noyau Linux [vient d’être annoncée](http://article.gmane.org/gmane.linux.kernel/1170070) par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site [_kernel.org_](http://kernel.org/).
Ce [changement de numérotation](http://linuxfr.org/users/patrick_g/journaux/linux-30-en-approche) du noyau est l’occasion de tirer un coup de chapeau aux 176 extralucides du [sondage _LinuxFr_ de janvier 2010](http://linuxfr.org/sondages/linux-30-sortira) qui avaient deviné que ce noyau 3.0 sortirait cette année. Bravo à eux !
Le détail des évolutions et des nouveautés se trouve dans la seconde partie de la dépêche.
PS : Merci à [Michel Barret](https://linuxfr.org/users/barmic) pour avoir contribué à cette dépêche en ajoutant la référence au sondage Linux 3.0.
----
[[LWN 1] Les nouveautés du noyau 3.0](https://lwn.net/Articles/444288/)
[[LWN 2] Les nouveautés du noyau 3.0](https://lwn.net/Articles/445066/)
[Les articles récapitulatifs de h-online.com](http://www.h-online.com/open/features/Linux-Kernel-3-0-Tracking-1258972.html)
[Liste des nouveautés sur kernelnewbies.org](http://kernelnewbies.org/Linux_3.0)
----
#La phase de test
###RC-1
la version [RC-1](https://lwn.net/Articles/445222/) a été annoncée par Linus :
« _Yeah ! Allons‐y pour les interminables discussions à propos de la numérotation du noyau (encore une fois)._
_J’ai décidé de sauter le pas et de nommer la prochaine version « Linux 3.0 ». Elle sera disponible à une date assez rapprochée de l’anniversaire des 20 ans, pour que je puisse utiliser ça comme excuse. Mais bon, honnêtement, la vraie raison, c’est que je ne suis plus vraiment capable de compter jusqu’à 40._
_Nous avions discuté de cette nouvelle numérotation lors des derniers sommets annuels du noyau, et il y avait un plan pour en discuter à nouveau cette année. Mais bon, soyons réalistes, à quoi cela sert-il d’être aux commandes si je ne peux pas prendre une décision sans organiser un référendum ?_
_Donc, je vais juste me mettre en mode mâle dominant et re‐numéroter le truc. Vous allez adorer ça._
_D’un autre côté, ma dominance ne s’étend malheureusement pas sur tous les scripts et les `Makefiles`, donc le noyau résiste et il s’intitule lui‐même « 3.0.0-rc1 ». Nous aurons les 6 ou 7 semaines habituelles pour arriver à le soumettre et pour nettoyer les scripts de façon à ce que la version finale soit juste « 3.0 ». L’équipe en charge de « -stable » pourra utiliser le troisième chiffre pour ses versions._
_Alors, quels sont les grands changements ?_
_RIEN DU TOUT. Absolument rien du tout. Le 3.0 est **juste** là pour re‐numéroter, et ici nous ne faisons pas un truc à la KDE 4 ou à la GNOME 3. Pas d’incompatibilités, pas de nouvelles fonctions effrayantes, rien de tout ça. Nous avons fait des sorties basées sur des dates depuis plusieurs années maintenant et cela n’a rien à voir avec des nouvelles fonctions. Si vous voulez vraiment une excuse pour cette re‐numérotation vous devriez vous baser sur les dates (20 ans) et pas sur autre chose._
_Pas de changement d’[[API]], pas de changement d’[[ABI]], pas de nouvelles fonctionnalités magiques. Juste la lente et laborieuse progression habituelle. En plus des modifications de pilotes, nous avons quelques nettoyages du [[VFS]], des corrections sur la mémoire virtuelle, un début de consolidation de l’[[architecture ARM]] (yeah !) et en général tout ceci est supposé être un cycle très classique et normal._
_En fait, je pense que ça va être une version du type « Linus est vraiment super ch*ant », et je vais être très strict sur ce que j’accepte pendant la période de stabilisation. C’est parce que je vais voyager la semaine prochaine avec un portable [Atom](http://fr.wikipedia.org/wiki/Intel_Atom) tout lent et que vous aurez intérêt à **vraiment** me convaincre de l’intérêt de votre patch, puisque ce genre de machine n’est pas le truc le plus impressionnant qui ait jamais été construit. On peut s’en sortir avec le workflow git habituel, mais pour ce qui est de compiler, ce n’est pas vraiment ce à quoi je suis habitué._
_Donc, soyez sympas avec moi et envoyez‐moi uniquement des patches importants. Comme ça, la prochaine version n’aura pas simplement un numéro flambant neuf, mais ce sera également un bon noyau._
_Ok ? Alors allez-y testez ! »_
###RC-2
C’est le six juin dernier que Linus a décidé de faire paraître la version [RC-2](https://lwn.net/Articles/446243/) :
_« Vous connaissez tous la procédure maintenant : nouvelle semaine, nouvelle -RC._
_Tout a été relativement calme, bien que la mise à jour de [[Btrfs]] soit plus grosse que ce que j’espérais. À part ça, il y a surtout des corrections de pilotes, aussi quelques patches pour [[UBIFS]] et également une poignée de marche arrière, du fait de certaines régressions._
_J’espère que les choses vont rester calmes. Bien entendu, ce calme est peut‐être dû au fait que les gens ont, eux aussi, beaucoup voyagé. Donc, on verra, et autant espérer que tout ira bien._
_En plus, je n’ai pas été super pressé de répondre à toutes les demandes d’intégration, donc j’ai encore des requêtes dans ma boîte e‐mail. »_
###RC-3
Après [ses problèmes de réseau](http://article.gmane.org/gmane.linux.kernel/1150777) lors de son voyage de retour de la convention Linux au Japon, c’est le 13 juin que la [troisième version candidate](https://lwn.net/Articles/447327/) a été annoncée par Linus :
_« Qu’avons‐nous là‐dedans ? Plus de trucs que dans la RC-2. Je ne suis certainement pas le seul à être allé au Japon pour la LinuxCon, ou alors il y a un autre truc qui a soudainement réveillé les gens._
_Il s’agit surtout de corrections d’une ligne, mais il y a quelques trucs un peu plus gros : pilotes vidéo Radeon, mise à jour [DRI](http://fr.wikipedia.org/wiki/Direct_Rendering_Infrastructure), Btrfs, correction de la gestion Sparc [[LEON]] (et gestion PCI). D’autres petits trucs concernant [[NILFS2]] et [Ceph](http://en.wikipedia.org/wiki/Ceph), et aussi [ESA/390](http://en.wikipedia.org/wiki/ESA/390) (S/390) et ARM._
_À part cela, ce sont juste des mises à jour de pilotes un peu partout._
_Comme d’habitude, je demande aux gens de bien tester tout ça. »_
###RC-4
Réglé comme une horloge, Linus a envoyé son courriel d’annonce de la [RC-4](https://lwn.net/Articles/448557/) le 20 juin :
_« Encore une fois, il y a surtout de petites corrections d’une ligne et quelques changements dans [DRM](http://fr.wikipedia.org/wiki/Direct_rendering_infrastructure) (et md)._
_Et aussi des patchs pour des régressions de performances : [RCU](http://en.wikipedia.org/wiki/Read-copy-update) n’a pas besoin de threads (et ne pas les utiliser corrige certains problèmes de performances sous des charges spécifiques) et la conversion des &quot;spinlocks&quot; en &quot;mutexes&quot; pour anon_vma a provoqué des soucis de montée en charge et a dû être corrigée. »_
###RC-5
La version [RC-5](https://lwn.net/Articles/449507/) a été annoncée par Linus le 27 juin :
_« Pas grand chose d’excitant là‐dedans._
_Le truc le plus notable est peut‐être le fait que seulement un quart des changements concernent les pilotes. Les systèmes de fichiers représentent plus que ça (40 %) : Btrfs, CIFS, ext4, [JBD2](http://en.wikipedia.org/wiki/JBD2), [NFS](http://fr.wikipedia.org/wiki/Network_File_System), ils sont tous là._
_Et on trouve aussi tous les petits changements un peu partout. Comme, par exemple, des corrections d’échecs de compilation (pour être honnête vous devez activer quelques options ésotériques et désactiver [[NUMA]] pour rencontrer ce bogue, mais bon). Il y a encore quelques soucis en « staging » avec des correctifs en attente d’intégration. »_
###RC-6
Le 4 juillet, jour de la fête de l’indépendance aux États‐Unis, Linus a rendu disponible la version [RC-6](https://lwn.net/Articles/450179/) du noyau :
_« Joyeuse fête de l’indépendance pour tous les américains qui bossent sur le noyau là dehors._
_Il n’y a pas grand chose à dire sur cette RC-6. La plus grosse partie, et de loin, c’est l’inclusion du pilote Intel [isci](http://lwn.net/Articles/433392/). J’ai un peu hésité à son sujet, mais bon, ce n’est pas comme si ça allait causer des régressions pour des utilisateurs de Linux, donc pourquoi pas.
Et puis, franchement, Christoph Hellwig a dit des choses flatteuses sur ce pilote à **deux** reprises, ce qui est très inhabituel. Cela peut vouloir dire que ce pilote est génial. Bien entendu, il est bien plus probable que des aliens venus de l’espace soient juste en train de tester secrètement leur drogue euphorisante sur Christoph. Ou alors, il s’adoucit avec l’âge.
À part ce pilote isci, le reste est juste constitué de petites corrections. On en arrive au point où je commence à songer à sortir le noyau 3.0, parce que tout est vraiment calme et que les correctifs n’ont pas été révolutionnairement excitants. Quelques trucs sur le DRM (Radeon et Intel) seront peut‐être remarqués par plus de gens, mais le reste tend à être assez ésotérique._
_Bon, maintenant, je me barre pour faire [des &quot;s’mores&quot;](http://linuxfr.org/forums/g%C3%A9n%C3%A9ralhors-sujets/posts/traduction-dune-expression-am%C3%A9ricaine-myst%C3%A9rieuse). »_
###RC-7
Linus, après avoir hésité, a finalement décidé de sortir [une ultime version candidate](https://lwn.net/Articles/451245/) le 11 juillet dernier :
_« J’avais dit que la RC-6 serait sans doute la dernière. J’ai menti.
Les choses ont été assez calmes, mais il y avait quand même suffisamment de trucs pour que je veuille une autre RC. Et puis nous avons quelques soucis avec les changements dans le RCU qui posent des problèmes quand l’ordonnanceur n’a pas été complètement initialisé. Donc, voici la RC-7, même si elle n’a peut‐être pas encore été répliquée sur les miroirs au moment ou j’écris.
Il n’y a pas grand chose à en dire. Des mises à jour de pilotes (nous sommes revenus au ratio habituel avec deux tiers pour les pilotes), quelques changements dans media et CIFS, et aussi des améliorations de détail sur vmscan. »_
###Un léger retard
Alors que Linus avait prévu de sortir le noyau 3.0 le lundi 18 juillet, il a finalement préféré attendre un peu en raison de problèmes de dernière minute.
C’est d’abord Hugh Dickins qui a trouvé un bogue difficile à mettre en évidence et [assez compliqué à corriger](https://lwn.net/Articles/452117/) dans la fonction de résolution de noms. Une fois cela résolu, c’est Paul McKenney qui s’est manifesté sur la LKML et qui a signalé avoir découvert plusieurs dysfonctionnements dans le code RCU du noyau.
Le temps pour Linus d’intégrer [les _patches_ proposés](https://lkml.org/lkml/2011/7/19/300) et de demander aux gens de tester [via son nouveau compte Google+](https://plus.google.com/u/0/102150693225130002912/posts/cvn6ZD9gqnG) rutilant, le planning soigneusement orchestré était bon à jeter aux orties.
Ces retards auront un impact sur le prochain noyau, puisque Linus avait prévu de partir en vacances juste après la fin de la période d’intégration des nouveautés du futur Linux 3.1. Il a [envoyé un e‐mail récapitulatif](https://lkml.org/lkml/2011/7/20/371) pour expliquer la situation et laisser entendre qu’il sera particulièrement féroce envers les malheureux qui n’enverront pas leurs _patches_ assez tôt.
#Les nouveautés
##Cleancache
Le _patch_ _cleancache_, qui repose sur le mécanisme [_Transcendant memory_](https://linuxfr.org/news/sortie-du-noyau-linux%C2%A02639#toc_14) évoqué dans la dépêche du noyau précédent, a été intégré dans Linux 3.0.
Pour bien comprendre le rôle de _cleancache_, il faut d’abord jeter un très bref regard sur la gestion de la mémoire.
Il y a en premier lieu une division entre la mémoire physique — la RAM — et la [mémoire virtuelle](http://fr.wikipedia.org/wiki/M%C3%A9moire_virtuelle) qui présente aux applications un espace d’adressage qui leur est propre. Comme les deux sortes de mémoires sont divisées en _pages_, il faut des tables de correspondance entre une page physique et une page virtuelle. Ces tables sont nommées, de façon fort originale, des _page tables_.
On peut marquer les pages mémoires en mettant des drapeaux particuliers. Par exemple, si le drapeau _« dirty »_ est appliqué, cela signifie qu’une application a voulu écrire des données et a utilisé la fonction `write()`. Le noyau a copié ces données dans des pages mémoire en leur mettant un drapeau _« dirty »_. Ces pages ne doivent donc pas être réutilisées tant que les données n’auront pas été effectivement écrites sur le disque dur.
Évidemment, à l’inverse, les pages ayant le drapeau _« clean »_ sont disponibles pour être utilisées à tout moment.
Quand la pression mémoire est trop importante, alors les pages en statut _« clean »_ peuvent être « enlevées » de la mémoire physique. Ce mécanisme d’éviction (_memory reclaiming_) va enregistrer les pages dans leur espace de stockage particulier. Cet espace, nommé _backing store_, c’est tout simplement le disque ou la partition d’échange (_swap_) de la machine.
C’est ici qu’intervient le _patch_ _« cleancache »_ écrit par Dan Magenheimer. En cas d’éviction d’une page mémoire _clean_ par [l’algorithme dédié](http://en.wikipedia.org/wiki/Page_replacement_algorithm), alors le mécanisme _cleancache_ va jouer le rôle d’un [_victim cache_](http://www.irisa.fr/master/COURS/CAPS/CoursCD/HTML/Architecture/MecanismesDeBase/VictimCache.htm), c’est‐à‐dire qu’il va accueillir les pages retirées de la mémoire pour les stocker dans un espace à accès plus rapide que le _backing store_ sous‐jacent.
Maintenant, on comprend mieux ce nom de _« cleancache »_, puisqu’il s’agit simplement d’un mécanisme de cache pour les pages ayant le drapeau _« clean »_ ;-).
Alors évidemment, une première question se pose : si on stocke les pages victimes d’éviction dans un cache, cela signifie qu’on a de la place disponible, non ? Alors, pourquoi ont‐elles été choisies par le mécanisme de _memory reclaiming_ qui n’intervient qu’en cas de manque de mémoire ?
La réponse est que _cleancache_ n’utilise pas la mémoire classique. L’idée est de se servir d’un espace de stockage intermédiaire, n’importe lequel, puisque _cleancache_ est agnostique envers son réservoir sous‐jacent. Le noyau Linux 3.0 permet ainsi d’utiliser la mémoire de l’hyperviseur si on tourne avec Xen, ou bien encore le mécanisme [_zcache_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=daa6afa6d920a389015bb8f1ea519cef0636f528) de mémoire compressée. D’autres mécanismes sont en cours de développement, comme par exemple un SSD qui se place entre la RAM et le disque dur. Ce SSD servirait ainsi pour stocker les pages de _cleancache_ afin de pouvoir y accéder bien plus rapidement qu’en cas d’appel au très lent disque dur.
Si on regarde [la documentation](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/vm/cleancache.txt;h=36c367c730843df95200eaa4223842ff2ad8a536;hb=4fe4746ab694690af9f2ccb80184f5c575917c7f), on voit que _cleancache_ a été conçu pour s’interfacer avec le mécanisme [VFS](http://fr.wikipedia.org/wiki/Virtual_File_System). Les systèmes de fichiers qui veulent utiliser ce mécanisme doivent effectuer un appel à `cleancache_init_fs()` lors du montage initial. À l’heure actuelle, les systèmes de fichiers ext3, ext4, Btrfs et OCFS2 peuvent utiliser _cleancache_ (évidemment, dans le cas où l’option `CONFIG_CLEANCACHE` a été choisie lors du _build_).
Lors de l’éviction d’une page par le noyau, la fonction `cleancache_put_page()` sera appelée pour entreposer la page dans la zone de cache spéciale de _cleancache_. Si par la suite il s’avère que le noyau a besoin de cette page, il va, avant de lancer une coûteuse requête vers le disque dur, effectuer une recherche rapide via `cleancache_get_page()`. En cas de succès, c’est‐à‐dire si la page était toujours présente dans le cache, on peut gagner un temps précieux et augmenter largement les performances.
Comme l’indique Dan Magenheimer :> En réalité, _cleancache_ remplace des opérations d’entrées‐sorties qui impactent le disque par des opérations de copie mémoire qui impactent le processeur. Sur des vieux systèmes ayant un seul processeur et une mémoire lente, cleancache ne sert pas à grand chose. Sur les nouvelles machines multi‐cœurs, spécialement dans un environnement virtualisé, le mécanisme a alors une grande utilité.
Afin de garder un œil sur cette fonction et de vérifier son apport en termes de performances, diverses statistiques sont accessibles dans le répertoire `« /sys/kernel/mm/cleancache »`. On y trouve :
* **succ\_gets**, le nombre d’appels à `cleancache_get_page()` ayant réussi (la page était dans le cache) ;
* **failed\_gets**, le nombre d’appels à `cleancache_get_page()` ayant échoué (la page n’était pas dans le cache) ;
* **puts**, le nombre d’appels total fait à `cleancache_put_page()` pour déposer une page dans le cache ;
* **flushes**, le nombre d’appels total fait à `cleancache_flush_page()` pour retirer une page du cache.
_Cleancache_, en association avec le _patch_ _Transcendant memory_, est un mécanisme très générique et adaptable, et il est probable que nous commençons à peine à profiter de ses bénéfices dans le noyau Linux 3.0.
L’arrivée dans les prochaines années des [RAM non‐volatiles](http://en.wikipedia.org/wiki/ReRAM) (qu’elles soient à base de [_memristors_](http://fr.wikipedia.org/wiki/Memristor) ou de [verre de chalcogénure](http://fr.wikipedia.org/wiki/Phase-Change_Random_Access_Memory)), permet d’imaginer un espace de stockage intermédiaire plus lent que la RAM, mais plus rapide que les disques (même SSD). Ce serait certainement une situation idéale pour la technique _cleancache_ introduite dans ce noyau.
##Améliorations de Btrfs
Après la décision de Fedora [d’utiliser Btrfs par défaut](https://lwn.net/Articles/446925/) dans sa prochaine version 16, il est peut‐être temps de réaliser un point de situation global sur ce très moderne système de fichiers. L’occasion est belle car, [selon Chris Mason](http://article.gmane.org/gmane.linux.kernel/1146911), les _patches_ Btrfs intégrés dans le noyau Linux 3.0 sont les plus importants depuis le début du développement du système de fichiers.
C’est en juin 2007 que Chris [a annoncé sur la liste de diffusion](http://lkml.org/lkml/2007/6/12/242) la naissance de Btrfs. L’idée était de créer un nouveau système de fichiers ultra‐moderne et profitant de toutes les dernières idées, sans être contraint par un quelconque souci de rétro‐compatibilité avec l’existant. C’est sans doute l’aiguillon de [ZFS](http://fr.wikipedia.org/wiki/ZFS), disponible dans Solaris à partir de 2005, qui a poussé les développeurs Linux à lancer l’écriture d’un système de fichiers plus avancé que la série des ext2/3/4, et plus pérenne que [[ReiserFS]].
Si l’on en croit [l’excellent historique de Btrfs](https://lwn.net/Articles/342892/) écrit par Valérie Aurora, tout est parti d’une idée du chercheur Ohad Rodeh, qui a trouvé un moyen élégant de combiner les avantages des « [_arbres B_](http://fr.wikipedia.org/wiki/Arbre_B) » (_B‐trees_) et du « [_Copy‐On‐Write_](http://fr.wikipedia.org/wiki/Copy-On-Write) » (COW). Les arbres B sont un moyen de représenter les données d’un système de fichiers ou d’une base de données dans un arbre dont chaque nœud possède plus d’une clé. C’est une technique très efficace, mais, jusqu’à la percée théorique de Rodeh, les arbres B ne pouvaient pas être combinés avec la technique d’optimisation connue sous le nom de _Copy‐On‐Write_. Avec le COW, si des données sont écrites sur un bloc mémoire, alors les nouvelles données seront enregistrées sur une copie au lieu de l’être sur l’original. Ensuite, les méta‐données pointant sur le bloc sont modifiées de manière atomique, afin de prendre en compte les nouvelles données. On a ainsi un mécanisme transactionnel efficace et tellement rapide qu’on peut même abandonner la technique de « [journalisation](http://fr.wikipedia.org/wiki/Journal_%28syst%C3%A8me_de_fichiers%29) ».
Le problème de mixage des arbres B avec le COW est que dans un arbre B les « feuilles » sont liées entre elles. Quand l’emplacement de la première feuille change suite à une opération d’écriture (puisque le COW implique la copie du bloc à un autre endroit), alors la feuille adjacente doit changer son lien, ce qui implique via COW une copie à un autre endroit... et _bis repetita_ avec toutes les feuilles de l’arbre ! Bien entendu, comme vous pouvez l’imaginer, ce n’est pas très bon pour les performances de devoir réécrire tout l’arbre du système de fichiers à chaque modification d’une feuille...
L’idée d’Ohad Rodeh (décrite dans [ce fichier PDF](http://www.usenix.org/event/lsf07/tech/rodeh.pdf) de la conférence USENIX) est d’utiliser un [_B+tree_](http://en.wikipedia.org/wiki/B%2Btrees) à la place d’un classique _B‐tree_. Les feuilles ne sont plus liées irrémédiablement entre elles, et on peut inventer des algorithmes astucieux pour traverser l’arbre. Rodeh ajoute des techniques comme la _« fusion et séparation pro‐active des nœuds »_, et on obtient au final ce que Valérie Aurora qualifie de :>« structure de données simple, robuste et générique qui prend en compte de façon très efficace les _extends_ (groupes de blocs de données contigus) dans un système de fichiers COW. »
Chris Mason a été frappé par la puissance et l’élégance de ce concept, et il a décidé de baser toute l’architecture de Btrfs sur cette idée. Il a choisi d’implémenter l’intégralité des « objets » du système ([[inodes]], données des fichiers, répertoires, _bitmaps_) comme étant des nœuds ou des feuilles de l’arbre B. De cette façon, on n’écrit qu’un seul code qui est utilisé partout, et on peut avoir toutes les fonctions utiles (sommes de contrôle, _snapshots_, compression, etc.) qui s’appliquent à ce code unifié. On peut également profiter d’avantages en termes d’efficacité de stockage et de temps d’accès. Les autres systèmes stockent un seul type d’objet par bloc, ce qui est peu efficace, puisqu’on perd de la place dans le bloc et qu’on doit consulter plusieurs blocs pour avoir toutes les méta‐données. La stratégie de Btrfs rassemble tout dans une structure qui optimise l’espace disque et le temps d’accès.
Valérie Aurora a travaillé plusieurs années sur ZFS dans l’équipe de développement de Sun. Elle est donc particulièrement bien placée pour émettre un jugement solide en comparant ces deux systèmes de fichiers. [La citation](https://lwn.net/Articles/342892/) est un peu longue, mais elle a le mérite de la franchise :>« La conception de Btrfs est d’une grande élégance et d’une belle généricité [...] Les gens me posent souvent des questions au sujet de ZFS et Btrfs. D’un certain point de vue, les deux systèmes sont très similaires : ce sont des systèmes de fichiers COW avec sommes de contrôles, gestion de périphériques multiples et des instantanés (_snapshots_) accessibles en écriture.>Selon un autre point de vue, ils sont extrêmement différents : Btrfs organise tout sur le disque en termes d’_extents_ dans un arbre B qui contient toutes les données. ZFS organise tout sur le disque en termes d’arbres de pointeurs vers les blocs, avec des tailles de blocs en fonction de la taille de l’objet.>Donc la liste des fonctions des deux semble très similaire, mais les implémentations sont complètement différentes. C’est un peu comme le cas de l’évolution convergente entre les marsupiaux et les mammifères. Une souris marsupiale et une souris mammifère semblent complètement identiques vues de l’extérieur, mais leur implémentation interne est quelque peu différente !>À mon avis, l’architecture de base de Btrfs est mieux adaptée au stockage de données que celle de ZFS.>Un des problèmes majeurs de l’approche de ZFS à avoir un ensemble de blocs de tailles différentes, concerne la fragmentation. Chaque objet ne peut contenir que des blocs d’une seule taille. On peut facilement se retrouver avec un fichier formé à partir de blocs de 64 Kio qui doit grossir d’un bloc, alors qu’il n’y a plus de blocs de 64 Kio disponibles (alors qu’il y en a encore beaucoup de 512 octets, de 4 Kio, de 128 Kio, etc.).>Pour résoudre ce problème, nous (les développeurs de ZFS) avons inventé des façons de créer des gros blocs à partir de plus petits (_gang blocks_), et beaucoup d’autres contournements assez vilains. Pour notre défense, à cette époque, les arbres B et la technique COW semblaient radicalement incompatibles.>Par contraste, l’approche Btrfs qui place tous les items dans l’arbre B est extrêmement flexible et efficace en termes d’espace de stockage. »
Depuis sa présentation initiale en 2007, le système de fichiers Btrfs a beaucoup évolué, et il propose de nombreuses fonctions modernes parmi lesquelles on peut citer :
* notion de « sous‐volumes » qui permet, au sein du système de fichiers, d’avoir un arbre séparé contenant des répertoires et des fichiers. Les instantanés (_snapshots_ en anglais, une photographie à un instant donné du système de fichiers) sont simplement des sous‐volumes accessibles en écriture via COW ;
* sommes de contrôle des données et méta‐données ;
* agrandissement et réduction de taille des volumes ;
* ajout et suppression de volumes ;
* fonctions de compression transparente ;
* fonctions RAID intégrées.
Pour le noyau Linux 3.0, Chris Mason [a décrit les changements](http://article.gmane.org/gmane.linux.kernel/1146911) présents dans sa branche de développement. Il y en avait tellement qu’il a dû envoyer [une nouvelle bordée de _patches_](http://article.gmane.org/gmane.linux.kernel/1150247) au moment de la RC-2 (ce qui lui a valu [la traditionnelle engueulade](http://article.gmane.org/gmane.linux.kernel/1154012) de la part de Linus).
Une des modifications les plus importantes est [le _patch_ de Miao Xie](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=16cdcec736cd214350cdb591bf1091f8beedefa0) qui réécrit la fonction d’insertion des méta‐données dans les _inodes_. Intitulé _« Delayed Inode Items Operation »_, ce _patch_ vise à améliorer les temps de création et suppression de fichiers. L’insertion de méta‐données dans le _B+tree_ étant coûteuse, le nouveau code introduit une double liste qui stockera les opérations au lieu de bloquer, et ensuite le travail sera effectué par un _thread_ spécifique (_worker_). 
Selon le banc d’essai passé par Miao Xie :
* création de 50 000 fichiers :
 * avant le patch : 1,096 108,
 * après le patch : 0,932 899 (soit un gain d’environ 15 %) ;
* suppression de 50 000 fichiers :
 * avant le patch : 1,510 403,
 * après le patch : 1,215 732 (soit un gain d’environ 20 %).
On peut également citer [le _patch_ de Li Zefan](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=581bb050941b4f220f84d3e5ed6dace3d42dd382) qui implémente un cache pour les numéros d’_inodes_, afin de ne pas risquer d’en tomber à court sur les machines 32 bits.
Il y a aussi le _patch_ d’Arne Jansen qui ajoute la prise en charge des fonctions de [_scrubbing_](http://en.wikipedia.org/wiki/Data_scrubbing). En gros, cela va permettre d’ordonner au noyau (via un [_ioctl_](http://fr.wikipedia.org/wiki/Ioctl)) de vérifier les sommes de contrôles des _extents_ et des superblocs présents sur le volume de stockage. En cas d’erreur (perte d’intégrité), une copie saine sera recherchée dans les volumes sauvegardés et une correction automatique sera effectuée. Selon [les commentaires présents dans le code](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=fs/btrfs/scrub.c;h=70f9fa772ee9593c7938c1e12fd4752c42844744;hb=a2de733c78fa7af51ba9670482fa7d392aa67c57), ce travail sera complété dans une prochaine version pour ajouter des fonctions de _« readahead »_ plus avancées (meilleures performances) et des fonctions de rapport en cas d’erreur irréparable.
[Chris Mason a écrit un _patch_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4cb5300bc839b8a943eb19c9f27f25470e22d0ca) qui permet l’auto‐défragmentation de fichiers en cas d’accès aléatoires en écriture. Le _patch_ permet de détecter ces accès particuliers et s’occupe de mettre les fichiers dans la liste pour une défragmentation automatique. Cette fonction s’active via `« mount -o auto_defrag »` et elle est décrite comme particulièrement adaptées pour des fichiers de taille réduite comme on peut en trouver dans des base de données du type [[SQLite]] ou [[Berkeley_DB]].
Si on ajoute à ça [la gestion de _cleancache_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=90a887c9a2e25bcb1fc658fad59dfbc6fb792734), le gros travail de nettoyage de code de David Sterba (17 patches pour 310 lignes en plus et 3 253 lignes en moins) et les efforts d’optimisation des performances entrepris par Josef Bacik et listés dans [le courriel de Chris Mason](http://article.gmane.org/gmane.linux.kernel/1150247), on comprend que le système de fichiers Btrfs présent dans le noyau Linux 3.0 a été grandement amélioré. La seule pièce manquante pour le choix définitif de Btrfs par défaut dans Fedora 16 ne concerne pas vraiment le noyau, puisqu’il s’agit d’ajouter un programme de vérification du type `fsck`. [Selon Josef Bacik](https://fedorahosted.org/fesco/ticket/594), cet outil est déjà écrit et il est en phase de vérification intensive :>L’outil de `fsck` est presque prêt. Une partie des raisons pour lesquelles cela prend autant de temps, c’est qu’il est très bien testé. Donc, quand il sera rendu disponible, il aura vérifié plusieurs centaines de systèmes de fichiers corrompus afin de s’assurer qu’il fonctionne correctement.
##POSIX Alarm timer
Deux nouvelles interfaces d’accès à [l’horloge RTC](http://en.wikipedia.org/wiki/Real-time_clock_alarm) du BIOS [font leur entrée](https://lwn.net/Articles/429925/) dans le noyau Linux 3.0.
Cette horloge RTC est bien pratique, puisqu’elle permet de réveiller automatiquement la machine quand elle est [en veille ou en hibernation](http://fr.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface#Global_states.C2.A0.2F.C2.A0Sleep_states_.28.C3.A9tats_du_syst.C3.A8me_et_sommeil.29), par exemple pour faire une sauvegarde au milieu de la nuit ou pour enregistrer une émission. Pour cela, il suffit à une application d’écrire dans `« /sys/class/rtc/rtc0/wakealarm »` pour indiquer la date et l’heure du réveil souhaité. L’horloge RTC reste à l’heure même si l’ordinateur hiberne et, juste au moment voulu, elle génère un signal pour réveiller la machine et passer la main au programme utilisateur.
L’ennui c’est qu’il s’agit d’une interface bas niveau et qu’une seule application peut programmer le réveil de l’ordinateur. C’est le premier arrivé qui gagne ! Si l’on veut à la fois programmer une sauvegarde, **puis** l’enregistrement d’une émission, alors il faut ruser. On peut s’en sortir en faisant coopérer les applications et en jouant avec `cron`, mais ça devient beaucoup plus compliqué.
L’idéal ce serait que les applications signalent simplement leurs besoins dans une sorte de file d’attente (_timerqueue_), et que le noyau s’occupe tout seul du travail consistant à réveiller la machine au moment spécifié le plus proche dans le temps. Le programme en espace utilisateur envoie un `rtc_timer` dans la queue au lieu de parler directement à l’horloge RTC. Cette fonction si pratique de « virtualisation » de l’horloge RTC (puisqu’on passe par une couche intermédiaire) est entrée dans le noyau à partir de la version 2.6.38.
Maintenant il faut s’attaquer à la partie visible par les applications. Comment leur proposer une interface simple qui cache tous les horribles petits détails bas niveau comme, par exemple, les désynchronisations entre l’horloge RTC et l’heure système ? Quelle est la meilleure solution pour donner suffisamment d’informations aux applications, tout en ayant une API robuste et sûre ?
C’est une question délicate, car toute interface vers des applications en espace utilisateur devient, une fois publiée, absolument intangible. Si l’on fait du mauvais travail au début, il est très difficile de corriger les choses par la suite, puisque cela risque de casser la compatibilité avec les applications.
Dans ces cas‐là, il est toujours utile de regarder autour de soi pour voir quelles sont les solutions adoptées par les autres systèmes.
Par exemple, l’équipe d’Android a déjà développé plusieurs nouvelles interfaces d’horloges pour son système (un téléphone se met souvent en veille automatique, et il a besoin de sortir de cet état à des moment bien précis). Pourquoi ne pas réutiliser ce travail ?
Malheureusement, au lieu de participer au développement dans la branche principale, ils ont codé dans leur coin des choses assez peu orthodoxes du type `ANDROID_ALARM_RTC` ou `ANDROID_ALARM_SYSTEMTIME`, ou encore `ANDROID_ALARM_ELAPSED_REALTIME`. Ces interfaces n’utilisent pas du tout `« /sys/class/rtc/* »`, elles passent par un tout nouveau périphérique en mode bloc `« /dev/alarm »` et envoient des commandes via un [ioctl](http://fr.wikipedia.org/wiki/Ioctl).
Évidemment, pour rajouter un peu de bonheur dans le cœur des développeurs Linux, certaines de ces interfaces réinventent la roue et reprennent en partie des concepts qui existent déjà dans le noyau (`CLOCK_REALTIME` et `CLOCK_MONOTONIC`). Seule l’interface `ANDROID_ALARM_ELAPSED_REALTIME` est intéressante et nouvelle, puisque non seulement elle compte le temps qui s’est écoulé depuis le démarrage du système, mais surtout, elle tient compte des phases de veille et d’hibernation dans son calcul. C’est un avantage par rapport au classique `CLOCK_MONOTONIC` qui compte le temps à partir de zéro depuis le démarrage du système, mais qui s’arrête de compter quand la machine hiberne.
Le développeur John Stultz s’est donc inspiré du travail intégré dans Android, et il a codé [deux nouveaux types d’horloges](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9a7adcf5c6dea63d2e47e6f6d2f7a6c9f48b9337) pour Linux 3.0.
La première, `CLOCK_REALTIME_ALARM`, étend la classique `CLOCK_REALTIME`, qui ne faisait que donner l’heure RTC, et ajoute la possibilité de réveiller l’ordinateur. La seconde horloge se nomme `CLOCK_BOOTTIME_ALARM` et elle copie les fonctions d’`ANDROID_ALARM_ELAPSED_REALTIME`. On a donc un compteur qui s’incrémente depuis zéro à partir du démarrage du système et qui ne s’interrompt pas lors des phases de veille et d’hibernation.
Ces horloges sont implémentées par dessus le mécanisme de virtualisation qui avait été introduit dans le 2.6.38, et, contrairement au code d’Android, elles utilisent l’interface classique [[POSIX]] et parlent à l’horloge RTC sous‐jacente en utilisant les évènements `rtc_timer` décrits plus haut.
C’est donc une belle avancée pour Linux, mais cela ouvre également des perspectives pour les développeurs d’Android. Ils avaient développé des interfaces dans leur coin parce que le noyau ne leur proposait pas ce dont ils avaient besoin. Maintenant que `CLOCK_REALTIME_ALARM` et `CLOCK_BOOTTIME_ALARM` sont dans la branche principale, pourquoi ne pas simplement les utiliser, puisqu’elles offrent les mêmes fonctions que le code spécifique d’Android ?
John Stultz [a parlé](https://lwn.net/Articles/431540/) aux développeurs de Google, et, selon lui, il semble qu’une simplification et qu’un large partage de code soit devenu maintenant possible.
##Suppression de prefetch
Les appels à la fonction `prefetch()` qui parsemaient le noyau ont été en grande partie [retirés dans cette version 3.0](https://lwn.net/Articles/444336/). Le travail de nettoyage va sans doute se poursuivre dans les versions futures, car les tests ont montré que les gains en performances qui étaient espérés avec cette fonction ne sont pas au rendez‐vous.
La fonction `prefetch()` est ce que l’on nomme une « micro‐optimisation ». C’est‐à‐dire que son rôle est d’améliorer à la marge les performances du noyau en complexifiant un petit peu le code. Bien entendu, chaque micro‐optimisation est le résultat d’un calcul coût‐bénéfice assez spéculatif : est‐ce que le gain en performances justifie la complexité qui est ajoutée dans le code et qui risque d’introduire des bogues et de la charge de maintenance ?
Les développeurs du noyau savent parfaitement que les performances d’une machine dépendent de façon cruciale de la mémoire cache (voir [l’article d’Ulrich Drepper](https://lwn.net/Articles/252125/) sur ce sujet). La différence de temps d’accès entre une mémoire cache gravée sur le processeur et une barrette de [RAM](http://fr.wikipedia.org/wiki/M%C3%A9moire_vive) externe est tellement gigantesque, que tout défaut de cache réduit de façon importante les performances. Il faut donc que le code du noyau fasse le maximum pour que la gestion du cache soit la plus efficace possible.
Pour cela, des appels à `prefetch()` ont été ajoutés dans plusieurs endroits du noyau. Par exemple, quand des [listes chaînées](http://fr.wikipedia.org/wiki/Liste_cha%C3%AEn%C3%A9e) sont utilisées, on va utiliser `prefetch()` pour charger en avance l’item suivant de la liste. Le processeur sera toujours en train de traiter l’élément _n_ de la liste, mais, grâce à ce chargement anticipé, l’élément _n + 1_ aura été appelé en avance de phase et sera, soit sur le chemin vers le processeur, soit déjà au chaud dans la mémoire cache. On perd ainsi moins de temps à interroger la RAM et à se rouler les pouces en attendant sa réponse.
Les macros existantes dans le noyau Linux, comme `list_for_each` par exemple, incorporent donc un appel à cette fonction de pré‐chargement en tant que micro‐optimisation permettant d’accélérer le traitement des listes chaînées.
La fonction `prefetch()` est, on le voit, une idée simple, naturelle et non controversée. Le problème c’est qu’en réalité il s’avère qu’elle dégrade les performances !
Tout cela vient du fait que les processeurs modernes sont des monstres d’ingénierie, avec un « budget transistor » absolument indécent. Pour augmenter les performances, les têtes pensantes des labos d’AMD, Intel ou IBM ont bien compris qu’optimiser le chargement de la mémoire cache était crucial. Tous les CPU modernes incorporent donc des unités matérielles de pré‐chargement des données. Ce _prefetcher_ matériel observe donc les accès mémoire et il arrive à distinguer des schémas récurrents (_patterns_) qui vont lui permettre de pré‐charger les données en avance de phase. Chaque constructeur garde jalousement le secret sur le fonctionnement exact de ces unités matérielles de _pre‐fetch_ ([la documentation](http://software.intel.com/en-us/articles/optimizing-application-performance-on-intel-coret-microarchitecture-using-hardware-implemented-prefetchers/) est très succincte), mais le résultat est là : le processeur fait du bon travail et parvient de lui‐même à optimiser le fonctionnement de la mémoire cache en pré‐chargeant efficacement les données.
À ce stade un problème se profile à l’horizon : si le processeur est déjà capable de faire du pré‐chargement, alors à quoi est‐ce que ça sert d’ajouter des appels à `prefetch()` partout dans le code ? On risque plutôt de perturber les flux de données en interférant avec le délicat travail du processeur.
C’est cette réflexion qui a conduit Andi Kleen, dès septembre 2010, à proposer [son _patch_ de nettoyage](http://thread.gmane.org/gmane.linux.kernel/1033281) des appels à `prefetch()`.
Andi s’est penché sur cette question pour évaluer l’apport réel du pré‐chargement codé dans le noyau. Il a parlé avec des ingénieurs CPU, et la conclusion est sans ambiguïté :>Le retour de la part des concepteurs de CPU, c’est qu’ils n’aiment pas quand nous utilisons des appels explicites à `prefetch()`, à moins qu’il n’y ait une très bonne raison de le faire.
Si l’on ajoute le fait que les appels de pré‐chargement augmentent la pression sur les registres du processeur et que le code généré par les compilateurs est souvent de moins bonne qualité quand il y a des appels à `prefetch()`, alors le résultat du calcul coût‐bénéfice change du tout au tout.
L’ennui c’est que le _patch_ d’Andi de septembre dernier n’a pas suscité une réaction d’enthousiasme démesurée sur la liste de diffusion du noyau. En fait, il n’y a pas eu de réaction du tout, à part [un e‐mail de Paul Moore](http://article.gmane.org/gmane.linux.kernel/1033338) disant en substance : « Ouais, pourquoi pas ? ».
Il ne faut pas oublier que la LKML se caractérise par un déluge de courriels, et il n’est pas rare de voir ainsi des propositions rester sans suite. C’est au développeur qui a créé le _patch_ d’insister et de défendre son travail inlassablement pour obtenir une réaction de ses pairs. Dans le cas d’espèce, Andi n’a pas insisté et son nettoyage des appels à `prefetch()` n’a pas été intégré dans la branche principale du noyau.
Tout change le 19 mai 2011 avec un e‐mail de Linus intitulé « [_Software prefetching considered harmful_](http://thread.gmane.org/gmane.linux.kernel.cross-arch/9810) ». Avec son style fleuri habituel, le leader du noyau détaille les tests qu’il a effectués et tout le bien qu’il pense de la fonction de pré‐chargement :>J’ai passé un peu de temps ces derniers jours à regarder les performances du noyau sur une tâche que j’effectue en permanence : `« make »` sur un répertoire qui est déjà complètement « buildé ». Donc, il n’y a pas le coût de la compilation, juste le coût de \_vérification\_ de ce qui doit être compilé.>Il s’avère que `« make »` est franchement lent comme un goret (quoi de neuf là‐dedans ?), mais que cette charge est assez intensive pour le noyau. On passe un bon paquet de temps à faire de la résolution de noms. Et nous sommes bons en matière de résolution de nom... sauf si je veux activer SELinux sans perdre les avantages de la résolution via [RCU](http://en.wikipedia.org/wiki/Read-copy-update). Dans ce cas de figure, SELinux suce des fœtus d’ânes à travers une paille.>Quoi qu’il en soit la fonction la plus consommatrice est celle qui utilise le _prefetch_ logiciel pour les listes de [[hachage]]. Le profil montre clairement que l’instruction de _prefetch_ est de loin la plus grande coupable.>Et ce n’est pas à cause des défauts de cache. En réalité, la suppression du prefetch AUGMENTE LES PERFORMANCES.>Je ne blague pas. C’est juste une merde. C’est une immonde merde qui nous coûte 0,5 % de performance sur un simple banc d’essai de « make » du noyau sur l’un des processeurs les plus communs qui existent.
Sérieusement.
Le _patch_ qui accompagne le courriel indigné de Linus supprime donc la fonction de pré‐chargement des listes de _hashes_ (_hlist_) et relance l’intérêt pour mener des investigations sur la fonction `prefetch()`. Ingo Molnar s’est engagé dans une phase de test intensive à l’aide de l’outil `perf` pour comprendre clairement ce qui se passait.
Le résultat de ses investigations a été résumé dans [un message très détaillé](http://article.gmane.org/gmane.linux.kernel.cross-arch/9813) dont j’extrais la conclusion :>\- Depuis des années, les gens ajoutent des instructions de _prefetch_ à l’aveuglette, sans tester et sans prouver qu’il y a vraiment un gain. Nous devrions réexaminer tout cela soigneusement.>\- Le processeur est fondamentalement plus efficace que le logiciel dans le domaine du pré‐chargement. Nos fameuses instructions se révèlent *diminuer* les performances.>\- Les tests, via les _perf‐events_, sont la voie à suivre. Ils se sont révélés *très* utiles pour moi, afin d’analyser la situation. Et je n’ai même pas eu à me préoccuper de quel modèle de CPU était utilisé lors des tests. C’est un énorme avantage à mon avis.
Après la diatribe de Linus et les analyses d’Ingo (qui va jusqu’à dire que « les pré‐chargements sont absolument toxiques »), il était clair que la fonction `prefetch()` du noyau n’allait pas en sortir indemne. En septembre 2010, Andi Kleen avait été un précurseur incompris, mais aujourd’hui la nécessité d’agir est devenue évidente.
Dans le nouveau noyau Linux 3.0, la fonction `prefetch()` a donc été retirée des [listes de _hashs_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=75d65a425c0163d3ec476ddc12b51087217a070c) et des [listes chaînées](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e66eed651fd18a961f11cda62f3b5286c8cc4f9f). Les pilotes [commencent également](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=70c71606190e9115e5f8363bfcd164c582eb314a) à être nettoyés eux aussi.
Le gain induit par ces changements est marginal (entre 0,5 et 1 %), mais là n’est pas l’important. Ce qui compte, c’est que le code est maintenant plus simple, plus maintenable et que la taille d’une image noyau est un peu réduite (Andi Kleen avait chiffré le gain à 10 Kio). Ce qui compte **surtout**, c’est que les outils de diagnostic intégrés au noyau (`perf` et ses amis) permettent maintenant de se pencher efficacement sur les micro‐optimisations du noyau et d’évaluer leur apport **réel**.
Ingo Molnar, l’un des auteurs de `perf`, n’est évidemment pas neutre quand il défend son bébé. Mais il a raison [de souligner les gains](http://article.gmane.org/gmane.linux.kernel.cross-arch/9819) que cela permet :>Durant ces dix dernières années, nous avons souffert d’un niveau d’aveuglement croissant en ce qui concerne l’analyse des performances x86. Nos outils se sont lentement détériorés, les processeurs sont devenus de plus en plus intelligents et parallèles, et c’était de plus en plus difficile de comprendre ce qui se passait.>Mais nous avons maintenant de meilleurs outils (clin d’œil :) et un modèle de supervision plus performant (clin d’œil :), et les gens recommencent à se plonger dans les petits détails. Je pense que nous avons de bonnes chances d’améliorer encore les performances du noyau et de les maintenir à ce niveau.
##Un JIT pour BPF
Le code de la pile réseau du noyau Linux 3.0 contient désormais un [compilateur à la volée](http://fr.wikipedia.org/wiki/Compilation_%C3%A0_la_vol%C3%A9e) (JIT) qui permet d’accélérer le traitement des paquets réseau du filtre [_Berkeley Packet Filter_](http://fr.wikipedia.org/wiki/BSD_Packet_Filter).
Le filtre BPF (_**B**erkeley **P**acket **F**ilter_), [présenté à la conférence USENIX de 1993](http://www.tcpdump.org/papers/bpf-usenix93.pdf), est un outil qui permet à un logiciel en espace utilisateur de spécifier, via des filtres, les paquets pour lesquels il éprouve un intérêt. BPF a été rapidement intégré directement dans le noyau Linux qui y a gagné la possibilité de filtrer en amont les paquets du réseau et de n’envoyer vers l’application que le strict nécessaire dont elle a besoin.
Ainsi, on gagne en performances car on bloque les paquets inutiles dans le noyau dès le début, avant d’avoir à les envoyer vers l’espace utilisateur.
Parmi les logiciels qui reposent sur BPF, on peut citer [`ngrep`](http://en.wikipedia.org/wiki/Ngrep), [Wireshark](http://www.wireshark.org/) ou encore [`tcpdump`](http://en.wikipedia.org/wiki/Tcpdump), qui servent à capturer et analyser des paquets réseau. Ils utilisent BPF en positionnant un filtre précis qui ne va laisser passer que ce qui est intéressant. Ces logiciels reçoivent ainsi un flux « propre » puisque débarrassé de tous les paquets qui ne correspondent pas à leurs critères de recherche.
Évidemment, on comprend que les performances de BPF dans le noyau sont assez critiques, puisqu’il va devoir examiner les paquets un par un et déterminer s’ils correspondent ou pas aux conditions paramétrées dans le filtre.
Pour Linux 3.0, l’idée d’Éric Dumazet a consisté à ajouter au code de BPF (lisible dans « [`net/core/filter.c`](http://lxr.free-electrons.com/source/net/core/filter.c) ») un mécanisme de génération de code à la volée (_Just‐in‐time compilation_). Chaque instruction du filtre va être transformée en [assembleur](http://fr.wikipedia.org/wiki/Assembleur), et le programme qui en résulte traite chaque paquet réseau pour voir s’il correspond aux conditions de test.
Si vous prenez la peine de regarder le code de BPF, vous verrez (ligne 190) que c’est essentiellement un gros [`switch()`](http://fr.wikipedia.org/wiki/Switch_%28instruction%29) qui énumère tous les cas possibles d’instructions. Cette organisation du code rend plus facile son remplacement par un JIT. Le _patch_ d’Éric va permettre de remplacer chaque instruction du filtre BPF désiré par une séquence d’instructions x86. Le programme résultant, qui utilise une zone mémoire spéciale, est alors appelé pour analyser à pleine vitesse chaque paquet réseau.
Par défaut, ce compilateur JIT de BPF est désactivé, et il vous faudra faire un petit `« echo 1>/proc/sys/net/core/bpf_jit_enable »`, si vous voulez profiter de ses bienfaits. Précisons que l’implémentation, comme tout code en assembleur, est dépendante de l’architecture du processeur. Pour l’instant, seule l’architecture x86_64 est supportée par le compilateur JIT, mais il est possible (probable ?) que les futurs noyaux verront arriver un code gérant d’autres architectures.
Éric Dumazet [a testé](http://article.gmane.org/gmane.linux.network/191119) le gain potentiel qu’apporte son _patch_ en regardant ce qui se passe quand `tcpdump` doit analyser dix millions de paquets UDP avec un filtre très basique (commande `time /root/udpflood -f -l 10000000 10.2.2.1`).
La machine est un quadri‐cœur Intel E5540 cadencé à 2,53 GHz, voici les temps obtenus :
- sans `tcpdump` : **7,941 s** ;
- avec `tcpdump`, mais sans le JIT : **10,165 s** ;
- avec `tcpdump` et le JIT activé : **9,615 s**.
On gagne donc 0,55 secondes sur un traitement de dix millions de paquets, ce qui se traduit par un gain d’environ 50 nanosecondes par paquet. Et encore, ce n’est que pour un filtre ultra-basique (voir [l’e‐mail d’Éric](http://article.gmane.org/gmane.linux.network/191119)), et les gains devraient être supérieurs quand la complexité du filtre augmente.
Éric Dumazet étant un très gros contributeur de la pile réseau du noyau Linux, j’ai profité de l’entrée de ce _patch_ pour lui poser quelques questions (micro‐entretien datant du 14 juin dernier) :
**LinuxFr.org : Bonjour Éric. J’ai vu que ton _patch_ ajoutant un JIT pour BPF allait faire partie des nouveautés de la version 3.0, et je voudrais savoir si tu pouvais répondre à quelques questions pour les lecteurs de LinuxFr.**
**Éric Dumazet :** Je suis à Toronto en ce moment pour [la _Netconf 2011_](http://vger.kernel.org/netconf2011.html), je profite d’une pause café pour te répondre. ;)
**LinuxFr.org : Es-tu es le seul _hacker_ du noyau chez SFR ? Es‐tu es payé à plein temps pour travailler sur la branche principale ?**
**Éric Dumazet :** À ma connaissance je suis le seul « hacker chez SFR », mais je ne suis pas payé pour cela.
Je travaille chez _SFR Business Team, Services Hébergés_, pour des clients entreprise qui ont des problématiques générales, et il m’arrive d’utiliser mon expertise Linux dans des cas particuliers.
**LinuxFr.org : C’est un peu surprenant que tu ne sois pas payé par SFR pour travailler sur le noyau. Pourtant quand on regarde les articles de statistiques de [LWN](https://lwn.net/Articles/409256/) ou de [_remword_](http://www.remword.com/kps_result/all_petop.html), on voit que tes _patches_ sont portés au crédit de SFR.**
**Bizarre. Je me demande comment ils choisissent de compter les contributions des entreprises ?**
**Éric Dumazet :** C’est très simple : quand un particulier a une adresse « générique », en `@gmail.com`, et qu’il contribue de façon significative à Linux, il reçoit un e‐mail lui demandant pour quelle entreprise il travaille. ;)
Il se trouve que je suis en effet un gros contributeur Linux, et donc j’ai eu des demandes pour préciser ce point. Par exemple, SFR finance mon déplacement à Toronto, donc mon employeur participe, lui aussi, à l’effort commun qu’est Linux. ;)
**LinuxFr.org : Est‐il est prévu d’étendre le JIT pour d’autres architectures ? Serait‐ce facile à faire ?**
**Éric Dumazet :** Pour le moment rien n’est prévu, mais ce serait assez simple. Il suffit d’une connaissance assez basique du jeu d’instructions du CPU, je dirais que quelques jours de travail par architecture devraient suffire. Il faut, bien entendu, une machine pour les tests, et un peu de savoir‐faire.
**LinuxFr.org : Ce mécanisme de JIT n’est-il envisageable que pour BPF, ou bien est‐ce que cela aurait du sens de faire la même chose pour `iptables` ?**
**Éric Dumazet :** J’ai l’intention de [parler de ce sujet demain](http://vger.kernel.org/netconf2011_slides/edumazet_netconf2011.pdf), justement. La boucle principale d’`iptables` peut en effet profiter du JIT, qui peut ensuite appeler des _helpers_ externes (pour les _matches_ ou _targets_ qui contiennent du code qui ne nécessite pas de faire de l’_inline_).
Le gros intérêt de JIT pour `iptables` serait d’éviter d’avoir une copie de la table par CPU, comme c’est le cas actuellement, car le « code `iptables` » est mélangé avec les compteurs _bytes/packets_ par règle.
**LinuxFr.org : D’après les commentaires sur LWN, il semble que FreeBSD utilise une technique de JIT similaire pour BPF. Est‐ce que tu t’es inspiré de ça pour ton code ? De manière générale, est‐ce que tu regardes les systèmes BSD pour les comparer avec Linux ?**
**Éric Dumazet :** Je suis au courant, mais je ne regarde pas le code de FreeBSD : je préfère que les développements Linux soient _« self contained »_, pour éviter des contaminations pouvant poser problème de droits d’auteur.
**LinuxFr.org : Sur quoi travailles‐tu pour les prochaines versions du noyau ?**
**Éric Dumazet :** Je travaille actuellement (et de façon générale) sur des optimisations.
Par exemple, les prochaines machines pourront disposer de 40 cœurs et 80 threads, et des problèmes de contention surviennent souvent. Par exemple, cette semaine, j’ai proposé un _patch_ qui améliore les performances sur une machine de ce type, dans un contexte « memcached » haute performance.
[Ce _patch_](http://git2.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commit;h=4b9d9be839fdb7dcd7ce7619a623fd9015a50cda) a permis une augmentation d’au moins 200 % des performances sur un prototype d’Intel.
**LinuxFr.org : Merci pour tes réponses, et merci surtout pour tes contributions au noyau.**
#En bref
###Appel système sendmmsg
L’appel système classique `recvmsg()` permet de recevoir un message sur un [_socket_ réseau](http://fr.wikipedia.org/wiki/Socket#Socket_r.C3.A9seau). Comme pour tous les [syscalls](http://fr.wikipedia.org/wiki/Appel_syst%C3%A8me), franchir la séparation entre espace utilisateur et espace noyau est une opération coûteuse, et les développeurs cherchent à optimiser cette opération. Dans le noyau 2.6.33, le développeur Arnaldo Carvalho de Melo a eu l’idée de créer un nouvel appel système (nommée `recvmmsg()`) permettant de recevoir plusieurs messages d’un seul coup, au lieu d’être limité à un unique message. Avec cette solution, on peut effectuer plus de travail à chaque franchissement de la barrière noyau-espace utilisateur.
Nous voyons maintenant arriver dans Linux 3.0 la contrepartie de ce _patch_, puisqu’[Anton Blanchard a pris la peine](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=228e548e602061b08ee8e8966f567c12aa079682) d’écrire la même variante dopée aux stéroïdes de l’appel système `sendmsg()` habituel. Le nom est explicite et vous avez déjà compris que `sendmsg()` sert à envoyer des messages sur un _socket_ réseau, au lieu d’en recevoir. Le nouveau noyau accueille donc le nouvel appel `sendmmsg()` qui n’est plus limité à l’envoi d’un seul message à la fois (_mm_, c’est pour **m**ultiple **m**essages).
Cela permet de réduire les coûts des appels systèmes (_syscall overhead_), et le gain en performances est très notable, puisque, [selon les tests d’Anton](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=228e548e602061b08ee8e8966f567c12aa079682), on peut aller jusqu’à + 20 % de débit sur des paquets UDP et + 30 % sur des paquets bruts (_raw socket_).
###Commande ping
Puisque nous sommes dans les paquets réseau, on peut noter que le noyau Linux 3.0 permet maintenant d’utiliser `ping` sans avoir les droits `root`. Il s’agissait à l’origine d’un _patch_ implémenté par la distribution [Openwall](http://www.openwall.com/Owl/fr/) dans sa valeureuse quête d’un monde sans binaires à changement d’utilisateur [`setuid`](http://fr.wikipedia.org/wiki/Setuid) (_set user id_) dangereux. Selon [Solar Designer](http://en.wikipedia.org/wiki/Solar_Designer), cet ajout est le résultat d’[un examen attentif des alternatives](http://article.gmane.org/gmane.linux.kernel/1079773) et il a été finalement décidé que la meilleure solution était d’ajouter au noyau un nouveau type de _socket_ nommé `IPPROTO_ICMP`.
Le nom est un peu trompeur, puisqu’il n’est pas question de prendre en charge tout le [protocole ICMP](http://fr.wikipedia.org/wiki/Internet_Control_Message_Protocol). En réalité, le _socket_ est extrêmement restreint et, dans cette implémentation, la seule chose qui peut passer, ce sont les messages de type `ECHO` (c’est‐à‐dire qu’il ne peut qu’envoyer des messages de type `ICMP_ECHO` et recevoir des réponses `ICMP_ECHOREPLY`).
[Le _patch_ de Vasiliy Kulikov](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c319b4d76b9e583a5d88d6bf190e079c4e43213d) (qui est un des résultats de [l'initiative visant à renforcer la sécurité de Linux](https://linuxfr.org/users/patrick_g/journaux/renforcer-la-s%C3%A9curit%C3%A9-du-noyau)) détaille fort bien la problématique derrière cet ajout et indique que, pour des raisons de réduction de la surface d’attaque du noyau, cette option est désactivée par défaut.
Si une distribution choisit d’utiliser cette possibilité, alors, avec ce _socket_ `IPPROTO_ICMP` et un binaire `ping` « patché » [comme ici](http://openwall.info/wiki/people/segoon/ping), il deviendra possible d’utiliser `ping` sans avoir des droits superutilisateur.
Hop, un binaire `setuid` de moins !
###Pilotes graphiques
Dans le domaine des pilotes [DRM](http://fr.wikipedia.org/wiki/Direct_rendering_infrastructure) du noyau, on note assez peu de changements en ce qui concerne Intel. Les nouveautés concernent essentiellement le cœur graphique des futures puces [_Ivy Bridge_](http://fr.wikipedia.org/wiki/Sandy_Bridge#22_nm) qui est d’ores et déjà supporté dans cette version Linux 3.0 ([1](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=246d08b8f94a5545077611ab5bfb9d47014ede75) - [2](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b1f14ad01ab09f5e22fb1240a6a158a23527ff14)). De la même manière, le [PCH](http://en.wikipedia.org/wiki/Platform_Controller_Hub) (_Platform Controller Hub_) de type _Panther Point_, le successeur des _Cougar Point_ de l’architecture Nehalem, est lui aussi [pris en charge](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c792513bd1760c364b36391028512fbf2a4eb903) par le noyau.
Le pilote spécifique destiné aux puces GMA500 (Poulsbo) continue d’être amélioré par Alan Cox. Cette fois, c’est [son architecture même qui change](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f20ee24445b54be28cae8609c4194fb400377c63), puisqu’il se base sur [GEM](http://fr.wikipedia.org/wiki/Graphics_Execution_Manager) et non plus sur [TTM](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=aea74b6567997bbb670357caa57aff39c8c390a5). Après cette réorganisation, Alan estime que le pilote GMA500 est [d’une qualité suffisante](http://article.gmane.org/gmane.linux.kernel/1163714) pour quitter la branche _staging_ dès le prochain noyau 3.1.
Côté AMD, c’est la nouvelle [architecture Fusion](http://fr.wikipedia.org/wiki/AMD_Fusion) de type _Llano_ qui [arrive dans cette version](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4df64e65025dfa493bf75fddf50d83bba069e1eb). On trouve également [plusieurs](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=224d94b1445e2a836cd3790ff29f1866c052de4d) [_patches_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=eac4dff6d3edc0aea1941db16c03ae19aa628a3c) écrits par Alex Deucher, afin de nettoyer le code et d’améliorer le support de la norme [DisplayPort](http://fr.wikipedia.org/wiki/DisplayPort).
Enfin, en ce qui concerne le pilote _Nouveau_, on trouve le [début du support de pmpeg](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c0924326c8306249aaae27016b80f3c07bb51705) sur les puces NV40 ([série GeForce 6](http://en.wikipedia.org/wiki/GeForce_6_Series)) et NV84/G84 (cela permet d’utiliser le cœur graphique pour le décodage des flux MPEG). Dave Airlie [continue également de travailler](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f19467c509e36e5ba3498efd7d4072d3581a1d6c) sur la technologie [Optimus](http://fr.wikipedia.org/wiki/Optimus_%28NVIDIA%29), afin de pouvoir basculer entre une puce graphique intégrée et la carte graphique externe au processeur.
###Ext4 creuse des trous
[Dans sa version 2.6.38](https://linuxfr.org/news/le-noyau-linux-est-disponible-en-version-2638#toc_26), le noyau Linux avait gagné la possibilité de « creuser des trous » au sein des fichiers (_hole punching_). Cette désallocation d’une partie de l’espace d’un fichier est utilisée dans divers scénario de virtualisation. Par exemple, au démarrage, un système hôte alloue un espace contigu à son système invité (_guest_) pour ensuite, en cas de besoin, récupérer les zones non utilisées au sein du fichier en faisant appel à `FALLOC_FL_PUNCH_HOLE`.
Alors que cette fonction n’était jusqu’à présent utilisable que sur les systèmes de fichiers [XFS](http://fr.wikipedia.org/wiki/XFS) et [OCFS2](http://en.wikipedia.org/wiki/Ocfs2), le nouveau noyau 3.0 ajoute la compatibilité avec [ext4](http://fr.wikipedia.org/wiki/Ext4). Les _patches_ d’Allison Henderson ([1](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e861304b8ed83fe43e36d46794d72641c82d4636) - [2](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e861304b8ed83fe43e36d46794d72641c82d4636) - [3](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d583fb87a3ff0ca50befd2f73f7a67fade1c8c56) - [4](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=308488518dfcbe3be250085cd582f5b0c1ce72a9) - [5](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=55f020db66ce187fb8c8e4002a94b0eb714da450)) sont plus complexes que ce qui avait été initialement prévu, et il a fallu sept versions successives pour obtenir l’assentiment des sourcilleux gardiens du noyau. L’avantage, quand on se casse la tête et qu’on teste **tout** pour satisfaire un cerbère grognon, c’est que, par le plus bienheureux des hasards, on peut trouver des vieux bogues. Allison a pu ainsi ajouter à son tableau de chasse la [correction d’une fonction](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9b940f8e8c32456c8a6428fa4313a4bcca7b4fcb) qui s’est révélée donner de faux résultats et [l’éradication](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6976a6f2acde2b0443cd64f1d08af90630e4ce81) d’un dangereux [déréférencement de pointeur NULL](http://www.bases-hacking.org/null-pointer-dereference.html).
###Ordonnanceur réseau QFQ
Un nouvel algorithme d’ordonnancement des paquets réseau a été ajouté à [la longue liste](http://www.kernel.org/pub//scm/linux/kernel/git/jejb/storage-tree/net/sched/Kconfig) de ceux déjà présents dans le noyau Linux. Ces ordonnanceurs sont là pour implémenter une politique de traitement des paquets un peu plus subtile que le très bourrin premier‐arrivé‐premier‐servi (`NET_SCH_FIFO`).
On peut, par exemple, privilégier l’équité (_Fair Queueing schedulers_) entre les flots de paquets, mais cela se fait au détriment de la vitesse de traitement. On peut aussi choisir la rapidité (_Priority based schedulers_), mais alors la garantie de service ne s’appliquera qu’aux flots ayant la plus haute priorité, et les autres seront laissés pour compte.
Le petit nouveau se nomme « [_Quick Fair Queueing_](http://info.iet.unipi.it/~luigi/qfq/) » et il ambitionne d’être équitable, tout en étant rapide. [L’article](http://info.iet.unipi.it/~luigi/papers/20100127-qfq-full.pdf) des chercheurs italiens [Fabio Checconi](http://retis.sssup.it/~fabio/), [Paolo Valente](http://algo.ing.unimo.it/people/paolo/) et [Luigi Rizzo](http://info.iet.unipi.it/~luigi/) donne tous les détails sur ce nouvel algorithme et affirme qu’il est entre 2,5 et 3 fois plus rapide que les algorithmes existants qui ont les mêmes garanties de service.
C’est le développeur Stephen Hemminger qui, en se basant sur un code antérieur de Fabio Checconi, a écrit [le patch](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0545a3037773512d3448557ba048cebb73b3e4af) qui est finalement entré dans le noyau 3.0.
À noter que l’ordonnanceur QFQ (`NET_SCH_QFQ`) est déjà présent dans le pare‐feu de FreeBSD nommé [_ipfw_](http://en.wikipedia.org/wiki/Ipfw) (voir [la présentation](http://info.iet.unipi.it/~luigi/doc/20100513-bsdcan10dn.pdf) issue de [BSDCan2010](http://www.bsdcan.org/2010/)).
###Xen
Les derniers _patches_ permettant au noyau Linux d’être parfaitement fonctionnel en mode _Dom0_ sous l’hyperviseur [Xen](http://fr.wikipedia.org/wiki/Xen) ont été intégrés dans la branche principale.
Konrad Rzeszutek Wilk [explique clairement sur son _blog_](http://blog.xen.org/index.php/2011/06/14/linux-3-0-how-did-we-get-initial-domain-dom0-support-there/) que cette intégration a été une tâche de très longue haleine. Xen a adopté une licence libre en 2002 et la première version publique est sortie en 2004, mais pendant des années les développeurs n’ont pas vraiment travaillé pour rejoindre la branche principale du noyau. La priorité était de fournir des offres commerciales en choisissant une certaine version du noyau, et en ne proposant qu’une compatibilité spécifique avec cette version. Si l’on ajoute le fait que les développeurs Linux poussaient les hauts cris en voyant le code de Xen et ne voulaient pas entendre parler d’un _monstro‐patch_, on comprend que la fusion dans la branche principale n’était pas à l’ordre du jour.
Au fil des années, les auteurs de Xen se sont quand même rendus compte que leur modèle devenait intenable et qu’ils passaient un temps infini à réadapter leur _patch_. Il valait mieux chercher à intégrer le noyau pour que cette compatibilité ne soit plus un problème. En plus, les développeurs Linux avaient [intégré dès le 2.6.20](https://linuxfr.org/news/sortie-de-linux-2620) la machine virtuelle KVM, qui était reconnue comme étant beaucoup plus propre et simple. Cette concurrence de KVM (voir [l’excellent article](http://www.h-online.com/open/features/Xen-lets-KVM-overtake-1262171.html) de _Heise Online_) a provoqué un déclin d’intérêt pour Xen, et ses développeurs ont décidé qu’il était devenu indispensable de finir l’intégration dans la branche principale.
Il leur a donc fallu accepter les critiques des mainteneurs Linux (corriger, entre autres, les monstrueux `« #ifdef LINUX_VERSION_2_4_3 »` ou `« #ifdef LINUX_VERSION_2_6_18 »` qui parsemaient le code) et aussi découper proprement leurs _patches_.
Le mode invité de Xen (_DomU_) a pu être intégré à partir du 2.6.23, mais il manquait encore le mode hôte (_Dom0_), et il a fallu continuer de corriger patiemment tous les défauts signalés sur la LKML.
[Depuis la version 2.6.37](https://linuxfr.org/news/sortie-de-la-version-2637-du-noyau-linux#bref12), il est devenu possible de démarrer le système en _Dom0_ sous Xen, mais il manquait encore les indispensables pilotes génériques qui permettent à Xen de fonctionner réellement.
Le pilote réseau générique _netback_ [est entré dans le 2.6.39](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f942dc2552b8bfdee607be867b12a8971bb9cd85) et, finalement, le pilote générique en mode bloc [rejoint la branche principale](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4d05a28db56225bbab5e1321d818f318e92a4657) à l’occasion de cette version 3.0.
Les développeurs de [[Citrix]] ont alors pu pousser des cris de joie et célébrer dignement ce succès sur leurs _blogs_ ([1](http://blog.xen.org/index.php/2011/06/02/xen-celebrates-full-dom0-and-domu-support-in-linux-3-0/) - [2](http://blogs.citrix.com/2011/05/30/xen-celebrates-the-final-step-of-a-four-year-odyssey/) - [3](http://blog.xen.org/index.php/2011/06/14/linux-3-0-how-did-we-get-initial-domain-dom0-support-there/)). La stratégie consistant à envoyer des _patches_ courts, propres et pas trop invasifs a fini par payer.
Maintenant, il va falloir continuer le travail, puisque cette intégration s’est effectuée au prix d’une réduction des fonctions qui existent dans les produits commerciaux Xen (pas de mise en veille, par exemple, ni de flux USB envoyés aux systèmes invités).
###SMEP
Dans le même esprit que le fameux [bit NX](http://fr.wikipedia.org/wiki/NX_Bit) (qui marque les pages accessibles en écriture, afin qu’elles ne soient pas exécutables), les futurs processeurs Intel auront un bit de sécurité nommé SMEP. Cette fonction _« Supervisor Mode Execution Protection »_ (évoquée dans [ce journal _LinuxFr_](https://linuxfr.org/users/mat_/journaux/supervisor-mode-execution-protection)) va générer [une erreur](http://en.wikipedia.org/wiki/Fault_%28computing%29) quand le noyau essaiera d’exécuter du code depuis une page marquée avec le bit _user_. [Les _patches_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=de5397ad5b9ad22e2401c4dacdf1bb3b19c05679) du développeur Intel Fenghua Yu permettent d’activer ou de désactiver à volonté cette fonction pour les processeur ayant le drapeau `X86_FEATURE_SMEP` (il suffit de passer `« nosmep »` en paramètre lors de l’amorçage du système).
Le bit SMEP vise à rendre la vie plus difficile aux vils pirates informatiques qui parviennent à dévier le flux d’exécution du noyau vers une page en espace utilisateur contenant leur code de prise de contrôle (_payload_). Avec cette sécurité supplémentaire qu’offre SMEP, il ne sera plus possible d’exécuter ce code se trouvant en espace utilisateur.
Dan Rosenberg, spécialiste de la sécurité du noyau, [explique bien sur son _blog_](http://vulnfactory.org/blog/2011/06/05/smep-what-is-it-and-how-to-beat-it-on-linux/) que SMEP reprend en partie les fonctions du module `PAX_UDEREF`, qui fait partie du _patch_ « [grsecurity/PaX](http://grsecurity.net/) ». Bien entendu, `PAX_UDEREF` utilise une autre technique — la segmentation — qui est purement logicielle. Cela veut dire qu’il y a un impact sur les performances et que le code n’est pas prêt de rentrer dans la branche principale, car il est très invasif. SMEP est un petit peu moins complet que `PAX_UDEREF`, mais le fait qu’il s’appuie sur une fonction intégrée dans les processeurs à venir lui permet d’être très simple et complètement transparent du point de vue des performances.
###Namespace
Le _patch_ d’Eric Biederman [améliorant la gestion des espaces de nommage](https://lwn.net/Articles/407495/) (_name spaces_) a été accepté dans le nouveau noyau. Ce travail vise à améliorer la gestion des conteneurs, c’est‐à‐dire des groupes de processus qui ont leur propre vue privée sur les ressources du noyau, le réseau ou bien encore les systèmes de fichiers.
D’habitude quand on parle de conteneurs, le problème consiste à les isoler au maximum, chacun dans son propre espace de nommage distinct. Pour ce _patch_, c’est le contraire, puisqu’Eric a créé un mécanisme pour permettre à d’autres processus, extérieurs au _namespace_ du conteneur, d’interagir avec cet espace de noms.
Il a expliqué [dans un e‐mail](http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/35465) quelle utilité cela pouvait avoir ; par exemple, pour avoir des [_démons_](http://fr.wikipedia.org/wiki/Daemon_%28informatique%29) qui écoutent via des _sockets_ dans plusieurs espaces de noms à la fois.
Pour cela, il est maintenant possible d’interagir avec un _namespace_ particulier en le désignant via le fichier `« /proc/self/ns »` et en affectant un processus à un espace de noms avec l’appel `setns()`.
Eric s’est prévalu de l’accord des développeurs travaillant sur les conteneurs et a expliqué que ses _patches_ allaient faciliter leur travail en permettant une meilleure administration des espaces de noms.
La seule petite alerte s’est déroulée quand, le 21 juin dernier, Eric a envoyé à Linus une « [demande de _pull_](https://lkml.org/lkml/2011/6/21/382) » pour corriger quelques erreurs dans son _patch_ précédent. Comme l’objet du courriel était _« nsfd fixes »_, [Linus a été déconcerté](https://lkml.org/lkml/2011/6/21/456) et s’est demandé ce que venait faire le serveur NFS là‐dedans. Une fois le problème élucidé (il ne s’agissait pas de n**FS**d mais bien de n**SF**d comme dans _Name Space File Descriptors_), il a eu à endurer le courroux du mainteneur du noyau :>OK, c’est encore plus dingue que ce que je croyais.>Eric, merci d’arrêter d’utiliser des combinaisons aléatoires de lettres qui n’ont aucune signification **pour personne** à part toi. OK ?>Si tu ne veux pas te donner la peine d’écrire quelques lettres de plus et de rendre les choses lisibles, pourquoi est‐ce que tu devrais t’attendre à ce que les autres passent du temps à lire tes e‐mails ?
La [contrition](http://fr.wiktionary.org/wiki/contrition) silencieuse étant l’une des meilleures défenses face à un Linus grognon, c’est la stratégie qu’a choisie Eric pour faire passer son _patch_.
###Attributs étendus dans tmpfs
[`tmpfs`](http://fr.wikipedia.org/wiki/Tmpfs) (_Temporary File System_) est un système de fichiers particulier et simplifié qui n’existe que de façon temporaire en mémoire. Tout ce qui est stocké dessus disparaît lors d’un redémarrage de la machine. Fedora utilise par exemple intensivement `tmpfs` pour sa procédure de construction (_build_) de paquets RPM, et c’est à cette occasion qu’un souci est apparu. Depuis quelque temps, la tendance est d’utiliser les [capacités POSIX sur les fichiers](http://fedoraproject.org/wiki/Features/RemoveSETUID) (_POSIX file capabilities_) pour augmenter la sécurité de certains paquets. Ces capacités reposent sur les [attributs étendus](http://fr.wikipedia.org/wiki/Attributs_%C3%A9tendus) (`xattr`) des systèmes de fichiers, puisque c’est là que sont stockées [les capacités POSIX](http://www.friedhoff.org/posixfilecaps.html) des fichiers. Les responsables Fedora ont donc simplement voulu introduire ces capacités sur les fichiers dans leur procédure de construction qui utilise `tmpfs`.
À ce stade, vous commencez certainement à soupçonner l’horrible vérité : `tmpfs` ne gère pas les attributs étendus, donc les capacités non plus, et par conséquent, il n’est pas possible de l’utiliser pour construire les paquets qui nécessitent ces capacités. Le drame...
Le développeur Eric Paris s’est donc retroussé les manches [pour coder la gestion des attributs étendus](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b09e0fa4b4ea66266058eead43350bd7d55fec67) nécessaires (uniquement ceux appartenant aux espaces de noms `security.*` et `trusted.*`) et a placer ça sous l’option de configuration `CONFIG_TMPFS_XATTR`.
À partir de ce noyau Linux 3.0, il est donc maintenant parfaitement possible de gérer les capacités POSIX sur un système de fichiers `tmpfs`, et les responsables du _build_ de Fedora ont retrouvé la paix de l’esprit et la sérénité de l’âme.
###Unification ARM
Le noyau Linux 3.0 intègre le tout début du travail visant à mieux unifier le code de l’[[architecture ARM]].
Depuis [la polémique](https://linuxfr.org/news/sortie-du-noyau-linux%C2%A02639#toc_34) et les menaces proférées par Linus [en avril dernier](http://article.gmane.org/gmane.linux.ports.arm.kernel/113895), la décision a été prise de rationaliser le code de l’architecture ARM, qui était devenu un joyeux dépotoir. Les développeurs du marché de l’embarqué sont connus pour avoir des pratiques ~~sataniques perverses~~ différentes par rapport au reste de la communauté du noyau. Les variantes entre les plates‐formes sont légions, tandis que le délai avant la mise sur le marché (_time to market_) est un facteur absolument crucial. Cela implique que les « bonnes pratiques » de réutilisation du code et de factorisation des développements sont assez peu respectées, et que les doublons de pilotes prolifèrent. Après que Linus eut [sifflé la fin de la récréation](https://lwn.net/Articles/439314/), il fut décidé de mettre en place une structure de données dédiée (un _device tree_) pour décrire chaque carte ARM et chaque [SoC](http://fr.wikipedia.org/wiki/System_on_Chip) (système mono‐puce).
Les _patches_ intégrés jusqu’à présent sont modestes (préparation du _device tree_ [1](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9eb8f6743b076b67f00776cda4330c802e157b41) - [2](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ede338f4ce2fb5ee99d18751df32fbd3b10df268) et regroupement du code [1](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0f7b332f9777819a39a3b325690379a7efef89d1) - [2](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7e3819d820c9aa3536d15fe7310c054bef1f5f04) - [3](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4fcd3f374a928081d391cd9a570afe3b2c692fdc)), mais les prochains noyaux verront [l’intégration du gros du travail](http://paulmck.livejournal.com/25785.html).
En tout cas, les foudres _torvaldiennes_ ont été détournées, puisque [Linus a signalé dans son entretien avec Greg Kroah‐Hartman](https://lwn.net/Articles/445687/) qu’il était content d’avoir gueulé un bon coup et de constater que cela avait porté ses fruits.
###WoWLAN
Le « [_Wake on LAN_](http://fr.wikipedia.org/wiki/Wake-on-LAN) » (WoL), c’est tout simplement la possibilité de réveiller son ordinateur à distance en lui envoyant un message spécifique via le réseau. C’est une fonctionnalité fort utile, puisqu’on peut ainsi économiser de l’énergie en laissant une machine distante profondément endormie [en veille ACPI S3](http://fr.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface#Global_states.C2.A0.2F.C2.A0Sleep_states_.28.C3.A9tats_du_syst.C3.A8me_et_sommeil.29). Dès qu’on en a besoin, il suffit de lui envoyer [le paquet magique](http://fr.wikipedia.org/wiki/Wake-on-LAN#Paquet_magique) (une trame [[Ethernet]] contenant `« FF FF FF FF FF FF »` suivi par seize répétitions de l’[adresse MAC](http://fr.wikipedia.org/wiki/Adresse_MAC) de l’ordinateur cible) pour qu’elle sorte de son sommeil, telle une Cendrillon moderne.
Dans cette nouvelle version 3.0, le noyau Linux offre une prise en charge basique de la nouvelle fonction WoWLAN dans la pile Wi‐Fi générique. Rien à voir avec [_World of Warcraft_](http://fr.wikipedia.org/wiki/World_of_Warcraft), puisqu’en réalité, le [WoWLAN](http://wireless.kernel.org/en/users/Documentation/WoWLAN) (_Wake on Wireless LAN_) fait la même chose que le _« Wake on LAN »_ classique, mais sans les fils !
Les _patches_ de Johannes Berg ([1](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ff1b6e69ad4f31fb3c9c6da2665655f2e798dd70) - [2](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=eecc48000afe2ca6da22122d553b7cad294e42fc)) introduisent plusieurs « déclencheurs » (_triggers_) pour le réveil, car un réseau sans fil est plus complexe qu’un classique réseau Ethernet. Outre le traditionnel réveil avec le paquet magique (`NL80211_WOWLAN_TRIG_MAGIC_PKT`), on peut aussi utiliser la fonction de réveil automatique en cas de déconnexion (`NL80211_WOWLAN_TRIG_DISCONNECT`) ou en cas d’envoi de plusieurs paquets selon un schéma bien spécifique (`NL80211_WOWLAN_TRIG_PKT_PATTERN`).
###Pilote Kinect
Une version préliminaire d’un pilote [[Kinect]] a été intégrée dans le noyau 3.0 dans le sous‐répertoire « [`gspca`](http://git.linuxtv.org/jfrancois/gspca.git?a=blob_plain;f=Documentation/video4linux/gspca.txt) » qui accueille les _webcams_.
Kinect est un périphérique construit par Microsoft et destiné à être utilisé en complément de la console de jeu [[Xbox_360]]. Il permet la détection des mouvements et offre donc une interaction qui n’est plus basée sur l’utilisation d’une manette de jeu, mais sur les gestes du joueur.
La détection visuelle s’effectue via deux capteurs complémentaires : un capteur CCD couleur classique et un capteur CMOS monochrome renforcé par un laser infrarouge. Le laser a une résolution très grossière, mais il est juste utilisé pour évaluer [la profondeur de la scène](http://en.wikipedia.org/wiki/File:Kinect2-deepmap.png) (_depth map_).
[Le pilote présent dans Linux 3.0](http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-2.6.git;a=commitdiff;h=6612155a1dce344fb609c9487a879c693150ebb1) est écrit par Antonio Ospite qui s’est basé sur du code issu du projet [OpenKinect](http://openkinect.org/wiki/Main_Page). Il permet de gérer le flux vidéo du capteur CCD couleur, ainsi que le flux vidéo du capteur CMOS monochrome. En revanche, il ne permet pas encore de récupérer les informations venant du laser IR, et il est donc pour l’instant incapable de générer une _depth map_.
Les futures versions du noyau verront l’intégration des fonctions manquantes une fois que le code OpenKinect aura été suffisamment nettoyé et mis aux normes strictes de Linux.
###Redémarrage et UEFI
Le noyau 3.0 embarque plusieurs modifications concernant le redémarrage du système et la compatibilité [[UEFI]]. C’est Matthew Garrett (alias [_mjg59_](http://mjg59.livejournal.com/137313.html)) qui s’est attaché à revoir en détail ce code sensible, afin de minimiser les conséquences de l’incurie des constructeurs. Bien souvent, ces derniers ne testent que pour Windows, et un redémarrage effectué sous Linux risque de ne pas se dérouler correctement. [Dans son _patch_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=660e34cebf0a11d54f2d5dd8838607452355f321), Matthew explique qu’il a réordonné la séquence de redémarrage afin qu’elle corresponde à l’ordre de Windows, et que cette modification corrige des soucis de redémarrage avec, par exemple, certains portables Thinkpad.
Dans sa courageuse quête, _mjg59_ s’est également plongé dans le monde merveilleux de la compatibilité UEFI. Vous connaissez sans doute cette norme d’Intel destinée à remplacer le bon vieux [BIOS](http://fr.wikipedia.org/wiki/Basic_Input_Output_System) de nos machines... Mais connaissez‐vous l’origine du nom ?
Réponse de Matthew dans [son _commit_ Git](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=916f676f8dc016103f983c7ec54c18ecdbb6e349) :> UEFI veut dire _« Unified Extensible Firmware Interface »_ et on peut l’interpréter ainsi : _firmware_ est un ancien mot africain signifiant _« Pourquoi faire un truc de qualité, quand on peut le faire tellement pourri que les enfants pleureront et que les adultes se recroquevilleront devant vous ? »_, tandis que _UEI_ est la version celtique de _« Le [[DOS]] nous manque, alors on l’a gravé dans votre ROM »_.
Le nouveau noyau accueille plusieurs _patches_ visant à corriger les dysfonctionnements d’une couche UEFI [mal écrite](http://mjg59.livejournal.com/132477.html) par le constructeur de la carte mère. Auparavant, le code du noyau Linux s’en tenait strictement à la norme, mais il a fallu ajouter des rustine correctrices, car, pour reprendre encore une fois les mots de Matthew :> Nous avons été d’une naïveté charmante en croyant que la spécification avait une quelconque importance dans le monde réel.
Savoir si encore plus de _patches_ vont être intégrés dans les futures versions est assez difficile à deviner. Linus Torvalds [a l’air de penser](http://article.gmane.org/gmane.linux.kernel/1152467) qu’il faut se contenter d’interagir le moins possible avec UEFI. Quand _mjg59_ a suggéré qu’UEFI mangeait 1 Mio à l’amorçage et qu’il devrait être possible d’écrire des _patches_ permettant de récupérer cette mémoire, [Linus a été clair](http://article.gmane.org/gmane.linux.kernel/1152459) :> **Peu importe** si cette mémoire est difficile à récupérer. Nous n’avons qu’à la laisser où elle est. UEFI est une abomination aux yeux de Dieu, et je suis foutrement sûr que nous ne devrions pas nous mettre en quatre pour corriger toutes ses stupidités.> Putains de co#%ards qui croient que nous voulons une interface extensible, alors que ce que nous voulons c’est l’interface **la plus réduite** possible et pas cette folie qu’est UEFI !
###Optimisations de perf
Le développeur Lin Ming, qui travaille chez Intel, a introduit une optimisation dans le code de l’outil de profilage [`perf`](https://perf.wiki.kernel.org/index.php/Main_Page). C’est la commande `« perf probe »` qui est concernée, celle qui permet d’insérer des sondes (_kprobe_) au sein du code noyau pour l’instrumenter et évaluer les flux de données. Le fonctionnement précédent pouvait être lent quand il s’agissait de retrouver les noms de fonctions à sonder. Le nouveau chemin rapide de recherche (_fastpath_) permet de retrouver le nom en interrogeant directement la section `« debug_pubnames »` du format [DWARF](http://en.wikipedia.org/wiki/DWARF).
Avant d’accepter le _patch_, Ingo Molnar, toujours curieux, [a demandé](https://lkml.org/lkml/2011/3/24/84) une quantification du gain, pour voir si l’ajout de ce _fastpath_ en valait la peine. Les résultats sont assez impressionnants, puisque Lin Ming a annoncé les chiffres suivants pour la fonction `find_probes()` [dans son message de _commit_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cd25f8bc2696664877b21d33b7994e12fa570919) :
- avant application du patch : 848 490 844 cycles pour 0,355 secondes ;
- après application du patch : 205 684 469 cycles pour 0,086 secondes.
###Compilation et Warnings
Pour les milliards de barbus parmi vous qui méprisent les paquets pré‐compilés de leur distribution et qui préfèrent se mitonner un noyau aux petits oignons, il est bon de savoir que le `Makefile` du noyau Linux 3.0 [a été modifié](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=28bc20dccadc610c56e27255aeef2938141a0cd3) par Sam Ravnborg.
Auparavant, les fous qui osaient passer l’option `« W=1 »` lors du _build_ (pour pouvoir voir tous les _warnings_ émis par GCC) étaient submergés par un tsunami d’alertes diverses et variées. C’est, certes, assez comique de lire qu’il y a eu 92 919 alertes lors de la compilation, mais le charme s’émousse très rapidement. Après tout, quand on passe `« W=1 »`, c’est pour voir s’il n’y aurait pas quelque chose à corriger, alors il vaudrait mieux pouvoir filtrer les alertes non significatives et se concentrer sur les choses importantes.
C’est précisément l’objet [du _patch_ de Sam](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=28bc20dccadc610c56e27255aeef2938141a0cd3) qui introduit une hiérarchie dans ce qui n’était auparavant qu’une soupe indifférenciée. Il y a maintenant trois niveaux différents qui donnent les résultats suivants :
- avec `« W=1 »` : 4 859 alertes (les alertes qui _pourraient_ éventuellement être importantes) ;
- avec `« W=2 »` : 1 394 alertes (les alertes moins importantes) ;
- avec `« W=3 »` : 86 666 alertes (les alertes ésotériques et probablement sans la moindre conséquence).
Le détail des options GCC de chaque niveau est [visible ici](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=28bc20dccadc610c56e27255aeef2938141a0cd3#patch2). Sam Ravnborg a annoncé que son _patch_ allait lui permettre de compiler systématiquement en mode `« W=1 »` et de creuser un peu les alertes, alors qu’avant il était découragé par le « bruit » que générait cette option.
Bien entendu, pour les masochistes nostalgiques, il est toujours possible de passer à `« W=123 »` pour retrouver le comportement précédent.
###Belette strike back
Enfin, _last but not least_, avec ce passage en version 3.0, Linus a décidé qu’il était temps de changer également [le nom par défaut](http://en.wikipedia.org/wiki/List_of_Linux_kernel_names) du noyau. Après le célèbre _« Flesh‐Eating Bats with Fangs »_ (Chauves‐souris mangeuses de chair avec des crocs) du noyau 2.6.36, il va maintenant [falloir s’habituer](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=55922c9d1b84b89cb946c777fddccb3247e7df2c) à _« Sneaky Weasel »_ (Belette sournoise) comme nom de code de Linux 3.0.
Cette bestiole est effectivement d’une sournoiserie peu commune, puisque c’est la seconde fois qu’elle fait son apparition, après la peu ragoûtante _« Pink Farting Weasel »_ (Belette rose péteuse) du 2.6.23-rc4.
#Statistiques et regard rétrospectif sur la série 2.6.x
Avec le passage à Linux 3.0, c’est une page de l’histoire du noyau qui se tourne.
Certes, ce changement de numérotation a été effectué uniquement pour simplifier les choses. Certes, le préfixe _2.6_ n’avait plus guère de sens. Certes, le mode de développement de Linux reste ce qu’il était auparavant, et aucune technique révolutionnaire n’est intégrée. Il n’empêche que le passage à la version 3.0 est symbolique, et que cela représente une occasion de se retourner et de mesurer le chemin parcouru.
En ce qui concerne [le cycle particulier du noyau 3.0](https://lwn.net/Articles/451243/), il faut bien dire qu’il n’a pas grand chose de remarquable. _Boring_ à souhait, comme les aime Linus. Tout juste un peu plus calme que d’habitude, puisqu’on compte un peu plus de 9 000 _patches_ écrits par 1 110 développeurs, pour un gain net d’environ 113 000 lignes de code dans l’arbre des sources. La seule spécificité un peu notable de ce cycle est le fait que le développeur le plus prolifique [s’avère être employé par Microsoft](http://www.dwheeler.com/blog/2011/07/14/#microsoft-linux-author) : K. Y. Srinivasan a posté sur la LKML pas moins de 343 patches de nettoyage et de correction du pilote de virtualisation [[Hyper-V]] !
Comme le souligne avec un brin de perfidie Jonathan Corbet : « C’est impressionnant de voir combien de _patches_ sont nécessaires pour nettoyer un pilote qui fait moins de 15 000 lignes de code. »
Même si la métrique du nombre de _patches_ est [criticable](https://plus.google.com/104175436979387006170/posts/SmvtEE1xB7T), j’ajouterais que le pilote Hyper-V de Microsoft, au moment de rentrer dans la branche _staging_ en 2009, avait déjà subi [une vigoureuse phase de nettoyage](http://www.unixwiz.net/techtips/review-hv-patches.html) de plus de 200 patches écrits par Greg Kroah‐Hartman pour le rendre conforme au style de codage Linux.
Toujours est‐il que, pour ce cycle, la conséquence de cette incongruité statistique, c’est qu’en termes de _patches_, Microsoft apparaît en cinquième position des firmes ayant contribué à ce noyau Linux 3.0.
Toutefois, l’honneur est sauf, puisque Red Hat, Intel, Novell et IBM restent devant. :-)
Si l’on prend un peu de recul et qu’on regarde les statistiques de la série complète des 2.6.x, alors les chiffres deviennent plus intéressants. En lisant [le document ODS](https://github.com/gregkh/kernel-history/blob/master/kernel_stats.ods?raw=true) de statistiques globales réalisé par Greg Kroah‐Hartman, on peut mieux se rendre compte de l’évolution quantitative qui s’est déroulée durant cette période.
La sortie officielle du noyau 2.6.0 a été annoncée par Linus le 18 décembre 2003. À cette époque lointaine et héroïque, il y avait dans l’arbre des sources seulement 15 007 fichiers pour un total de 5 929 913 lignes. Le noyau 2.6.39, dernier représentant de la glorieuse série des 2.6.x, est apparu sur les serveurs de _kernel.org_ le 18 mai 2011. Ce beau bébé faisait 14 533 662 lignes réparties dans 36 706 fichiers.
En près de sept ans et demi, le noyau Linux a donc **plus que doublé** le nombre de ses fichiers (<span class="naked_sign">×</span><span class="naked_aural">ばつ</span> 2,44), et il a également **plus que doublé** le nombre de ses lignes de code (<span class="naked_sign">×</span><span class="naked_aural">ばつ</span> 2,45).
Et encore, ces chiffres émanent du document de Greg et ne prennent pas en compte le cycle du noyau 3.0, ni même les nombreux noyaux 2.5.x qui peuvent être considérés comme des versions candidates du 2.6.0. Si l’on adopte ce point de vue, plus large que la stricte limitation aux noyaux ayant le préfixe 2.6.x, alors les statistiques sont encore plus frappantes : 291 664 patches contribués par 8 078 développeurs différents et, en 9 ans et demi, un ajout d’environ 10,5 millions de lignes de code par rapport au noyau 2.4 !
Ces chiffres reflètent l’incroyable succès du modèle de développement progressivement choisi pour le noyau Linux dans la série 2.6.x. Le remplacement des simples courriels envoyés à Linus par l’utilisation de [[BitKeeper]], puis de [[Git]]. La fin des version quasi‐figées, comme le 2.4.x, et le choix d’une progression rapide, avec des nouvelles versions stables qui sortent tous les trois mois. Tout ceci fonctionne très bien et représente un grand progrès par rapport au modèle précédent.
Au fil des années, le processus s’est même affiné : nous avons maintenant des versions spécifiques du noyau qui sont maintenues à long terme, la fameuse branche _stable_ de Greg Kroah‐Hartman. Pour résoudre le problème récurrent des pilotes qui vivent en dehors de la _mainline_, la solution d’une antichambre spéciale a été retenue : c’est la fameuse branche _staging_, qui est également maintenue par Greg Kroah‐Hartman.
Tiens, je m’aperçois qu’entre [son document ODS de statistiques](https://github.com/gregkh/kernel-history/blob/master/kernel_stats.ods?raw=true) et ses diverses tâches de mainteneur, on retrouve souvent le nom de [Greg Kroah‐Hartman](http://fr.wikipedia.org/wiki/Greg_Kroah-Hartman) dans ce texte. Afin de finir dignement cette dépêche, pourquoi ne pas en profiter pour lui poser quelques questions ? Après tout, il fait partie des chevaliers de la table ronde de Linux, puisqu’il a été identifié dans [un article de LWN](https://lwn.net/Articles/451243/) comme étant l’un des très rares contributeurs ayant envoyé au moins un _patch_ dans chaque version depuis le 2.6.0.
Mais un pico‐entretien alors, parce que Greg a une charge de travail absolument colossale !
**LinuxFr.org : Bonjour Greg. J’écris un article sur le noyau pour le site _LinuxFr.org_. Est‐ce que tu es OK pour que je t’interroge rapidement au sujet du modèle de développement ?**
**Greg Kroah‐Hartman :** Tu peux toujours poser tes questions, n’hésite pas.
**LinuxFr.org : De nos jours, avec la puissance de Git, cela semble incroyable que les anciennes versions du noyau aient pu sortir sans aucun gestionnaire de code. Comment était‐ce à l’époque ? Est‐ce que tu peux décrire cet âge des ténèbres du noyau ?**
**Greg K‐H :** Ce n’était pas du tout « l’âge des ténèbres », et ce mode de développement marchait très correctement. C’est juste qu’à l’époque nous ne réalisions pas que nous aurions pu aller encore plus vite que ce que nous faisions alors. :)
**LinuxFr.org : Est‐ce que tu peux nous décrire la situation actuelle du [_Linux Driver Project_](http://www.linuxdriverproject.org) que tu as créé ? Est‐ce que c’est un succès ?**
**Greg K‐H :** Je pense que c’est un succès du fait qu’il n’existe pas, à l’heure actuelle et à ma connaissance, de périphérique sans pilote Linux. Il s’est avéré que nous n’avions pas réellement de nouveaux pilotes à écrire pour ce projet, juste des tonnes de pilotes qui existaient en dehors de la branche principale et que nous devions intégrer proprement. Donc, nous avons réorienté notre effort vers la partie _staging_, qui contient les pilotes qui n’ont pas la qualité « normale » des autres parties du noyau. Ils restent là, et après qu’ils ont été nettoyés, ils peuvent enfin migrer vers leur « vraie » section dans le noyau. Si tu regardes l’effort de développement qui est consacré à cette portion du noyau, tu verras à quel point c’est actif (des milliers de _patches_ par version).
**LinuxFr.org : Si tu devais résumer tout le cycle 2.6.x, que dirais‐tu ? Quelle est la principale réussite ?**
**Greg K‐H :** Tu veux que je te résume huit années en quelques phrases ? Eh, désolé, mais ça ne va pas être possible. :)
Que penses‐tu de : « Nous faisons maintenant des sorties à périodicité fixe, avec un nouveau noyau stable tous les trois mois, et nous avons une procédure en place pour assurer le maintien des vieux noyaux, tandis que le nouveau est développé en vue de la prochaine version. » ?
En résumé, notre modèle de développement est bien meilleur maintenant, notre rythme d’intégration des changements est incroyable et nous continuons à augmenter le nombre de contributeurs à chaque version.
**LinuxFr.org : Après Git, après la branche _staging_, quelle est la prochaine étape pour encore améliorer le mode de développement du noyau ?**
**Greg K‐H :** Qu’est‐ce qui ne va pas dans notre mode de développement actuel et qui a besoin d’être amélioré ? Sérieusement, j’aimerais le savoir. Nous évaluons en permanence notre façon de travailler et nous faisons des changements en fonction des problèmes que nous rencontrons.
**LinuxFr.org : En dépit des réussites du cycle 2.6.x, les systèmes à base de noyau Linux n’ont pas percé sur le bureau. Est‐ce que la communauté de développement du noyau peut y faire quelque chose, ou bien est‐ce une question qui relève essentiellement de l’espace utilisateur ?**
**Greg K‐H :** C’est essentiellement un problème lié aux constructeurs. À part quelques exceptions, ils ne veulent pas fournir Linux sur leurs machines pour leurs clients, et cela pour des raisons économiques plutôt valables.
Cela va simplement prendre du temps, mais je ne suis pas inquiet, nous ne sommes pas près de disparaître. :)
**LinuxFr.org : Pour finir, une question personnelle. Tu es le mainteneur du sous‐système USB, du sous‐système _« driver core »_, de `sysfs`, etc.. Tu es aussi responsable de la série _stable_ et de la branche _staging_. Tu donnes de nombreuses conférences sur le noyau. Comment est‐il possible de faire face à autant de tâches à la fois ?**
**Greg K‐H :** Oh, n’oublie pas que j’ai aussi un vrai travail à faire en même temps. :)
Je ne sais pas comment c’est possible. Une bonne gestion du temps peut‐être ? Est‐ce qu’un oiseau peut expliquer aux autres comment il est possible de voler ? C’est juste une réponse naturelle à ce qu’il a besoin de faire.
**LinuxFr.org : OK Greg, merci pour tes réponses et bon vol pour toi et pour les noyaux 3.x. ;-)**
</div><div class="naked_ctrl">
<form action="/index.cgi/contrast" method="get" name="gate">
<p><a href="http://altstyle.alfasado.net">AltStyle</a> によって変換されたページ <a href="httpS://linuxfr.org/news/le-noyau-linux-est-disponible-en-version-30.md">(-&gt;オリジナル)</a>
/ <label>アドレス: <input type="text" name="naked_post_url" value="httpS://linuxfr.org/news/le-noyau-linux-est-disponible-en-version-30.md" size="22" /></label> <label>モード: <select name="naked_post_mode">
<option value="default">デフォルト</option>
<option value="speech">音声ブラウザ</option>
<option value="ruby">ルビ付き</option>
<option value="contrast" selected="selected">配色反転</option>
<option value="larger-text">文字拡大</option>
<option value="mobile">モバイル</option>
</select>
<input type="submit" value="表示" />
</p>
</form>
</div>