URL: https://linuxfr.org/news/le-noyau-linux-est-disponible-en-version-2638 Title: Le noyau Linux est disponible en version 2.6.38 Authors: patrick_g Benoît Sibaud Date: 2011年02月21日T21:07:59+01:00 License: CC By-SA Tags: kernel, linux, tpm, hugepages, noyau_linux, coulisses et linus_torvalds Score: 165 La sortie de la version stable 2.6.38 du noyau Linux vient d'être [annoncée par Linus Torvalds](https://lkml.org/lkml/2011/3/14/508). Le nouveau noyau est, comme d'habitude, téléchargeable sur les serveurs du site [_kernel.org_](http://kernel.org/). Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche (qui est sous [licence CC BY‐SA](http://creativecommons.org/licenses/by-sa/3.0/deed.fr)). PS : Merci infiniment aux bonnes âmes qui ont participé à la rédaction collaborative de la dépêche et qui ont ainsi traduit les annonces de RC de Linus. ---- [Le bilan des ajouts partie 1](http://lwn.net/Articles/422420/) [Le bilan des ajouts partie 2](http://lwn.net/Articles/423541/) ---- #La phase de test ### RC-1 La version [RC-1](https://lkml.org/lkml/2011/1/18/322) a été annoncée par Linus le 18 janvier : « _Cela fait deux semaines, la période de "merge" pour le 2.6.38 est donc fermée. Et ça a été une période d'intégration intéressante. Cette période de "merge" voit l'introduction de deux de mes fonctionnalités préférées :_ * _l'utilisation de l'ordonnanceur de groupes pour permettre une meilleure interactivité lors de tâches UNIX "traditionnelles" (c-à-d un terminal avec une charge lourde comme un "make -j8" ou similaire) en donnant un groupe à chaque session tty (la variable de configuration "SCHED_AUTOGROUP") ;_ * _la nouvelle (enfin, "nouvelle", c'est en préparation depuis longtemps) recherche de chemin basée sur le mécanisme RCU de Nick Piggin._ _La fonction "autogroup" est vraiment plus un gadget technique qu'autre chose, mais il fonctionne vraiment bien pour le genre de choses pour lequel il a été conçu. Si vous faites encore un "véritable travail" dans un terminal, vous l'apprécierez très certainement. Compiler en parallèle dans une fenêtre, regarder un film dans une autre, et la vidéo est vraiment fluide. C'est vraiment palpable dans les faits. Ce n'est pas la panacée, mais c'est agréable._ _La recherche de chemin basée sur le mécanisme RCU est à l'autre bout du spectre : l'anti-gadget absolu. C'est du bon travail sérieux qui se débarrasse du dernier gros verrou global qui avait réellement tendance à réduire certaines performances du noyau. Le verrou "dentry" n'est maintenant plus un gros problème de sérialisation. Ce qui est vraiment agréable, à ce propos, c'est que ça améliore aussi beaucoup les performances pour des tâches à simple thread (sur un noyau SMP), parce qu'on débarrasse d'une des parties les plus coûteuses de la recherche de composant du chemin, le "d_lock", sur tous les composants de la recherche. J'ai pu constater des améliorations de 30 à 50 % sur certaines tâches intensives de recherche de chemin. »_ ### RC-2 La version [RC-2](https://lkml.org/lkml/2011/1/21/530) est sortie le 21 janvier avec une perle de langage comme seul Linus sait les faire : « _Ça fait clairement moins d'une semaine, mais je pars pour la LCA demain, donc j'ai voulu (a) sortir une -rc avant ça et (b) vérifier que le portable que je vais prendre avec moi est complètement préparé avec les bonnes clés de signature et tous mes scripts de release, etc.. Donc, si vous voyez quelque chose de bizarre dans la release, braillez, car je peux encore, avec un peu de chance, corriger les problèmes de script/config que je suis susceptible d'avoir._ _En tout cas, la -rc2 est sortie et le seul motif expliquant sa taille si raisonnable c'est que le délai de sortie a été court. Quelques requêtes d'intégration que j'ai eues sont quand même un peu plus invasives que ce que j'aurais souhaité avoir. Je dois aussi vous prévenir que le portable que j'ai pris avec moi est pitoyablement lent. Je prévois de passer en mode "anal" et de n'intégrer aucune nouvelle branche, sauf si elles ont clairement vocation à faire partie d'une -rc. Autrement dit : n'essayez pas de me faire intégrer de gros patchs. Je ne les prendrai pas et ils peuvent attendre le 2.6.39 (ce n'est pas plus mal, nous avons déjà suffisamment de choses excitantes dans le 38)._ _Bien entendu, il est parfaitement possible que les choses restent calmes puisque de nombreux autres mainteneurs seront certainement aussi à la LCA ; donc, espérons que l'alerte "Linus passe en mode anal" était totalement superflue. »_ ### RC-3 La version [RC-3](https://lkml.org/lkml/2011/1/31/547) a été annoncée le 1^er février, soit 11 jours après la -rc2 en raison de la LCA (linux.conf.au) à Brisbane à laquelle Linus participait : _« À cause de la LCA, la -rc2 était disponible quelques jours en avance et, pour équilibrer les choses, la -rc3 est en retard de quelques jours. Nous retournons maintenant vers un cycle hebdomadaire, puisque j'en aurai bientôt terminé avec mon voyage (je suis actuellement sur la route du retour - à l'aéroport de Cairns, fuyant le cyclone Yasi). Rien d'extrêmement spécial dans cette -rc et je suis heureux de dire que la plupart des demandes d'intégration ont été de bonnes corrections de bogues et de régressions clairement identifiées. Merci à la plupart d'entre vous pour ça. Maintenant récupérez-la et testez-la. Il semble que nous fassions de bonnes choses durant ce cycle de release. »_ ### RC-4 La version [RC-4](https://lkml.org/lkml/2011/2/7/403) est sortie, comme prévu, le 7 février : _« Pas de voyage ou d'évitement de cyclone cette fois, donc comme promis, les -rc sont maintenant revenues à un cycle hebdomadaire normal. Il n'y a rien qui ressort du lot ici. Quelques mises à jour d'archi (ARM et PowerPC), l'habituelle mise à jour des pilotes : DRI (radeon, i915), cartes réseau, son, média, iSCSI, quelques mises à jour de systèmes de fichiers (CIFS, Btrfs), et certains trucs, un peu partout, pour compléter le tout (réseau, "watchpoints", "tracepoints", etc.). Assez petite, pour tout dire. J'aurais préféré évidemment qu'elle soit encore plus petite, et j'ai refusé dans cette -rc une ou deux requêtes d'intégration, mais pour une -rc4 ça n'a rien d'horrible. Tant que ça continue à diminuer, je suis content. »_ ### RC-5 La version [RC-5](http://lkml.org/lkml/2011/2/15/977) est sortie le 15 février accompagnée par un message de Linus soulignant le faible nombre de modifications : _« Nouvelle semaine, nouvelle -rc. Il n'y a pas grand chose à voir cette fois-ci : nous avons corrigé plusieurs régressions (y compris, j'espère, le bug que les développeurs d'Ubuntu ont rencontré et qui était causé par la nouvelle recherche de chemin via RCU) et d'autres choses relativement normales. La plupart des changements sont courts et seuls les pilotes graphiques (pour Radeon et i915) sortent un peu du rang. Il y a aussi plusieurs déplacements de branches sur la documentation des périphériques qui peuvent paraître importants au regard des patchs habituels, mais ce sont juste des déplacements de fichiers hors du répertoire "powerpc" (puisque globalement la branche de développement sur les périphériques est devenue générique). Globalement c'est une RC assez réduite.»_ Ce que Linus ne précise pas dans son message accompagnant la RC-5, c'est que le faible nombre de _patchs_ s'explique aussi par sa vigilance féroce. Il a l'habitude de scruter les _patchs_ et il n'hésite jamais à hurler en cas de problème. Prenez par exemple [cet e-mail du 11 février dernier](https://lkml.org/lkml/2011/2/11/332) et qui concerne de menues corrections dans _ext4_: _« C'est un patch absolument dégoûtant et il provoque des tas de "warnings". Ce n'est pas simplement un "oh, un warning !". C'est plutôt un exemple de "oh, CE CODE EST UNE MERDE TOTALE !". Nom de Dieu, ne m'envoyez pas de la merde aussi tard dans le cycle. Clairement, il n'y a eu **aucun** contrôle qualité. »_ Après [un _mea culpa_ contrit](https://lkml.org/lkml/2011/2/12/50) de Ted Ts'o le _patch_ a finalement été corrigé. ### RC-6 La version [RC-6](https://lkml.org/lkml/2011/2/21/433) est annoncée le 21 février par cette tirade de Linus au sujet de la clôture d'un bogue épineux : « _Hmm. Une nouvelle semaine, une nouvelle -rc. Celle-ci résout une corruption mémoire assez dérangeante (mais aussi très rare) avec laquelle nous nous battions depuis quelques semaines. Mais puisque je suspecte que seules deux personnes l'ont vu passer, je doute que la majorité d'entre vous en ait quelque chose à faire. C'était cependant un grand soulagement pour moi de voir ce bogue résolu ; je me permets donc de le mentionner_. » Par ailleurs, Linus précise qu'il n'y a pas beaucoup de gros changements à ce stade, ce qui semble le rassurer. ### RC-7 La version [RC-7](https://lkml.org/lkml/2011/3/1/407) est sortie le 1^er mars, accompagnée du commentaire de Linus : _« Il n'y a là pas grand chose à annoncer. Des mises à jour de pilotes (une ligne par‐ci par‐là, quelques mises à jour de codecs audio pour [SoC](http://fr.wikipedia.org/wiki/SoC "System on Chip — système sur puce") et d'encore plus petites mises à jour du DRI) et quelques mises à jour de systèmes de fichiers (en particulier le FIEMAP de Btrfs et la gestion d'ENOSPC), mais vraiment toutes petites pour la plupart. Des régressions corrigées, en espérant qu'aucune n'aura été ajoutée. »_ ### RC-8 Enfin, la version [RC-8](http://article.gmane.org/gmane.linux.kernel/1110126) a été annoncée par Linus le 8 mars : _« J'aurais pu sortir cette version comme le 2.6.38 final, mais je vais être absent quelques jours la semaine prochaine, j'ai pensé que ça n'avait pas beaucoup de sens d'ouvrir la fenêtre de merge maintenant. En plus, nous avons des régressions. J'espère que quelques-unes sont résolues dans cette RC-8, mais ça ne fera pas de mal d'ajouter une semaine de test. »_ #Les nouveautés ## Transparent Huge Pages Le nouveau noyau 2.6.38 permet maintenant le [support transparent des « huge pages »](http://lwn.net/Articles/423584/), c'est-à-dire l'utilisation des pages mémoires de grandes tailles par opposition au pages traditionnelles de 4 Kio. Les processeurs que nous utilisons tous les jours sont dotés d'une [unité de gestion mémoire](http://fr.wikipedia.org/wiki/Unit%C3%A9_de_gestion_m%C3%A9moire) qui leur permet d'établir une correspondance entre les pages de la mémoire physique (RAM) et les pages de la mémoire virtuelle manipulée par le système. Cette table de correspondance, la [_page table_](http://en.wikipedia.org/wiki/Page_table), est hiérarchique avec plusieurs niveaux d'indirections à traverser avant d'obtenir l'information voulue. Pour éviter de perdre du temps à interroger cette table de correspondance et ses multiples niveaux d'indirections, on se sert d'une mémoire cache, le [_Translation Lookaside Buffer_](http://fr.wikipedia.org/wiki/Translation_Lookaside_Buffer). Cette unité du processeur est importante pour les performances, et les constructeurs rivalisent d'imagination afin d'améliorer le TLB sur leurs puces. Héritage de l'architecture x86, la taille typique des pages mémoire de la plupart des processeurs est de 4 Kio, ce qui est vraiment insuffisant avec les tailles mémoire des machines modernes. Intuitivement, on voit bien que plus les pages mémoires sont petites et plus il faudra stocker d'informations dans la table de correspondance entre les pages physiques et les pages virtuelles. Évidemment, cela accroît la pression sur le TLB. Si j'ai un million de pages de 4 Kio, alors je dois « _mapper_ » plus de choses que si je n'ai que quelques milliers de pages de 1 Mio. Dans le premier cas, j'ai de fortes chances de rencontrer un défaut de cache du TLB, alors que dans le second cas, les défauts de cache seront rares. Encore plus important que la pression sur le TLB, les pages de 4 Kio obligent à traverser les multiples niveaux d'indirection de la « _page table_ » alors que des pages plus grandes permettraient un accès quasi direct. C'est donc pour résoudre ces deux problèmes que les _« huge pages »_ ont été inventées. Au lieu de se contenter de pages physiques de 4 misérables kilo-octets qui induisent une forte pression sur le TLB et qui nécessitent de traverser de multiples niveaux d'indirections dans la table des pages (_page table_), on peut, depuis le Pentium Pro, opter pour des pages de 2 Mio ou de 4 Mio. Pour les plus goulus d'entre vous, les machines x86-64 permettent même d'utiliser des _huge pages_ de 1 Gio, tandis que l'architecture POWER va jusqu'à 16 Gio ! Certaines applications, en particulier les bases de données, profitent pleinement de ces _huge pages_ et peuvent voir leurs performances augmenter de près de 10 %, comme c'est le cas avec Oracle ou DB2. Mel Gorman, dans sa magnifique série explicative sur les _huge pages_ ([1](https://lwn.net/Articles/374424/) - [2](https://lwn.net/Articles/375096/) - [3](https://lwn.net/Articles/376606/) - [4](https://lwn.net/Articles/378641/) - [5](https://lwn.net/Articles/379748/)) indique même que certaines applications scientifiques enregistrent [des gains de 45 %](https://lwn.net/Articles/378646/) ! Tout va donc pour le mieux dans le meilleur des mondes et les _huge pages_ sont disponibles pour ceux qui en ont besoin... Mais, il y a toutefois un petit problème. Certes, Linux supporte les _huge pages_ depuis fort longtemps (2003) mais leur support est contraignant et difficile à configurer. L'outil standard se nomme hugetlbfs et pour utiliser les _huge pages_ il faut typiquement allouer un gros espace mémoire au _boot_ et avoir des applications modifiées pour tirer parti de ce « réservoir » en passant par la fonction `« get_huge_pages() »`. Ce n'est pas très pratique et cette difficulté d'utilisation a d'ailleurs été soulignée par Mel Gorman à la fin de sa série d'articles :>_En dépit du fait que de nombreuses tailles de pages sont disponibles depuis plus d'une décennie, leur support sous Linux a historiquement été délicat à utiliser. Même les administrateurs systèmes doués évitaient de se lancer là-dedans._ L'idéal ce serait que Linux permette l'utilisation complètement transparente des _huge pages_ quand il le peut. Au lieu de devoir modifier péniblement toutes les applications existantes et devoir réserver un gros tampon au démarrage de la machine, il faudrait que le noyau soit suffisamment malin pour utiliser les pages mémoires de grandes tailles automatiquement. Coup de chance, c'est exactement le but du _patch_ d'Andrea Arcangeli qui a été intégré dans ce noyau 2.6.38 ! Première étape du _patch_ THP (_Transparent Huge Page_), il faut modifier le noyau pour lui permettre de gérer simultanément plusieurs tailles de pages. Alors qu'avant Linux présupposait que toutes ses pages avaient la même taille dans chaque région de l'espace d'adressage virtuel (les VMA pour _Virtual Memory Area_), il est maintenant possible de mixer des pages de 4 Kio avec des pages de 2 Mio. Lors d'une allocation mémoire, et si un espace contigu suffisamment grand est trouvé, le noyau 2.6.38 pourra fusionner plusieurs petites pages dans une seule _huge page_ (_coalescing_). En cas de nécessité de _swap_ alors le noyau relâchera automatiquement la _huge page_ qui se retransformera en une multitude de petites pages (_splitting_). Magique ! Pour augmenter les chances de pouvoir allouer des _huge pages_, il faut avoir ces fameux espaces mémoires non fragmentés disponibles au bon moment. Andrea a trouvé une solution ingénieuse, puisqu'un _thread_ noyau spécifique, nommé _« khugepaged »_, va s'occuper de ce travail en tâche de fond. Dès qu'il trouve un tel espace libre, alors il s'empresse de scanner la mémoire pour remplacer plusieurs petites pages de 4 Kio par une seule _huge page_. Le _patch_ actuel n'est pas encore tout à fait complet, puisqu'il ne permet d'exploiter que des _huge pages_ d'une taille de 2 Mio. De plus, il ne fonctionne que sur les pages anonymes, c'est-à-dire celles obtenues à la suite d'un `« malloc() »`. En dépit de ces limitations provisoires, les tests ont montré que les performances étaient au rendez-vous. Un gain allant jusqu'à 10 % a été mesuré par Mel Gorman dans [ce _benchmark_](http://article.gmane.org/gmane.linux.kernel.mm/56970). C'est un peu moins bien qu'avec _hugetlbfs_, mais on gagne énormément en facilité d'utilisation, puisqu'il n'y a rien à faire pour en profiter. On peut choisir d'activer cette nouvelle fonction en permanence et pour toutes les applications : ```text echo always>/sys/kernel/mm/transparent_hugepage/enabled ``` Mais il est également possible de n'activer les _huge pages_ que pour certaines zones mémoires spécifiques indiquées par la fonction « madvise() » : ```text echo madvise>/sys/kernel/mm/transparent_hugepage/enabled ``` Une [documentation complète](https://lwn.net/Articles/423592/) est disponible, qui explique en détail tout le mécanisme du _patch_ THP. Andrea Arcangeli a déjà indiqué qu'il allait continuer à travailler sur son _patch_, afin de gérer les pages de 4 Mio et 1 Gio, ainsi que la mémoire non-anonyme du cache de page. Pour nous, simples utilisateurs, le code actuel présent dans le noyau 2.6.38 nous permet déjà de mieux exploiter les unités MMU de nos processeurs et d'augmenter les performances de nos applications. ## Pathname lookup Selon Linus Torvalds la plus importante nouveauté de ce noyau 2.6.38 est [le _patch_ de Nick Piggin](http://lwn.net/Articles/419811/) qui optimise la fonction de résolution de chemin (*pathname lookup*) de [la couche VFS](http://fr.wikipedia.org/wiki/VFS). Ce code est extrêmement complexe et Linus s'est même senti obligé d'envoyer un e-mail de mise en garde en plein milieu de la période de _merge_ :>Je voudrais juste signaler le fait que j'ai intégré aujourd'hui le _patch_ effrayant (mais très impressionnant) de Nick à propos du _pathname lookup_. >C'est effrayant parce que c'est du code qui est vraiment au cœur de l'_OS_, et parce que le nouveau modèle de _lookup RCU_ est vraiment plus intelligent et subtil que le vieux _spinlock dentry_lock_. >Mais c'est aussi impressionnant et je voulais vraiment intégrer ce _patch_ parce que ses résultats en termes de performance sont étonnants. Par exemple, une recherche de type `« find . -size »` sur mon répertoire _home_ (ce qui revient à faire des _name lookups_ pour récupérer les stats sur chaque fichier récursivement) devient 35 % plus rapide. Et tout ça dans un contexte « non-threadé » ! >Ici, on n'a pas un truc de montée en charge réservée aux machines haut de gamme, il ne s'agit pas de binaires recompilés qui profiteraient d'une nouvelle fonction. C'est juste que le _pathname lookup_ est carrément plus rapide. Même si la tâche n'est pas facile, essayons donc de décrire ce fameux _patch_ que Linus lui-même trouve _« scary »_. Tout d'abord un peu de contexte. Quand un processus en cours doit agir sur un fichier, ce qui arrive assez souvent dans un système UNIX, vous en conviendrez, alors il envoie le chemin (_pathname_) de ce fichier à la couche VFS pour qu'elle en gère l'accès. Ainsi, chaque fois qu'est invoqué un appel système de type `« open() »`, `« read() »` ou encore `« rename() »`, il faut donc utiliser le VFS pour retrouver [l'_inode_](http://fr.wikipedia.org/wiki/Inode) du fichier sur lequel on va agir. En effet, c'est l'_inode_ qui, en tant qu'identifiant unique du fichier, va indiquer les droits d'accès et plus généralement toutes les métadonnées associées. Donc, le problème est clair : nous avons un chemin de fichier (_pathname_) et il nous faut trouver l'_inode_ correspondant. C'est ce que l'on nomme le problème du _« pathname lookup »_, c'est-à-dire la résolution du chemin. Comment allons-nous procéder ? Et surtout, comment faire pour que ça aille vite ? Le code du VFS effectue cette opération en séparant les différentes composantes du chemin. Après tout, quand on voit un chemin comme `« /home/patrick/linuxfr/2.6.38.txt »`, on comprend bien qu'il est possible de le découper en morceaux séparés par « / », puisqu'il s'agit d'une suite hiérarchique de répertoires qui aboutit à un fichier unique. On pourrait imaginer de parcourir le répertoire racine pour lire sur le disque tous les noms jusqu'à trouver le répertoire suivant, et recommencer ainsi de suite, jusqu'au fichier final. L'ennui, c'est que ce serait très long et qu'il vaut mieux stocker quelque part les relations hiérarchiques qui existent entre les répertoires, ainsi que les correspondances entre les _inodes_ et les noms de fichiers. La structure qui s'occupe de ça se nomme un _« dentry »_ (pour _directory entry_) et, outre l'_inode_ du répertoire, elle contient le nom du répertoire parent et les noms des répertoires enfants. Le _dentry_ est donc la structure qui est utilisée pour faire la correspondance tant désirée entre le nom du fichier et son _inode_. La fonction du VFS qui s'occupe de la tâche de résolution du chemin se nomme `« path_lookup() »` et elle va utiliser le _dentry_ pour faire son travail. Cette fonction s'occupe, en outre, de tous les horribles petits détails techniques à considérer quand on veut arriver au but (la vérification des droits d'accès, le problème des liens symboliques et le risque associé de références circulaires, les points de montage, etc.). On voit que la notion de _dentry_ est très importante, centrale même, et qu'il faut pouvoir lire les informations contenues le plus vite possible, pour que la résolution du chemin soit la plus véloce possible. Les _dentry_ sont des structures de données contenues en mémoire et non sur le disque, ce qui permet un accès rapide. Le noyau maintient ainsi un cache de ces _dentry_ (un cache de leurs empreintes) puisqu'il ne peut pas assurer la correspondance complète de la structure du système de fichiers dans la mémoire. Ce cache des dentry (le _dcache_) doit donc gérer les accès simultanés (on dit « concurrents ») des différents processeurs, et l'on voit bien que le contenu du cache va évoluer en permanence. Chaque fois qu'une composante d'un chemin n'est pas présente dans le cache des _dentry_, il faut demander au système de fichiers d'envoyer les informations permettant de le créer. Il y a aussi le cas où le chemin contient une composante qui n'existe pas dans le système de fichiers. Là aussi, on stocke dans le _dcache_ un « _dentry_ négatif », pour éviter de perdre du temps à rechercher ce répertoire ou fichier inexistant lors d'une prochaine recherche. Donc, si nous résumons ce que nous avons pour le moment : - pour résoudre les chemins, le noyau se base sur la notion de _dentry_ ; - ce _dentry_ fait la correspondance entre le nom du fichier qui est présent dans le chemin et l'_inode_ du fichier ; - afin d'aller le plus vite possible, un cache des _dentry_ est maintenu : le _dcache_ ; - le _dcache_ est sous la pression permanente des processeurs de la machine, et il faut optimiser son temps d'accès. La solution simple et lente pour éviter les conflits sur le _dcache_ est de poser un gros verrou dessus. Cela évite les problèmes du type retrait d'un _dentry_ du cache par un processeur, alors qu'un autre processeur en a besoin au même moment. Ce gros verrou, le « dcache\_lock », a été la première solution adoptée par Linux. Depuis les noyaux de développements de la série 2.5.x, les codeurs du noyau ont remplacé _dans certains cas_ le _dcache\_lock_ par un mécanisme optimisé. Pour s'assurer qu'un _dentry_ utilisé ne sera pas retiré inopinément, on va poser un _spinlock_ dessus, le _d\_lock_, et l'on va incrémenter un compteur (_refcount_) le temps d'utiliser ce _dentry_. L'idée, c'est de ne verrouiller les _dentry_ successifs des composantes du chemin que les uns après les autres, en séquence. Cet algorithme, nommé _« ref-walk »_, est, bien entendu, plus compliqué que le bon vieux verrou _dcache\_lock_, mais il est aussi plus efficace, puisque le blocage est bien plus fin. Comme souvent, quand un bond en performance est effectué, on découvre de nouveaux goulets d'étranglement qui étaient masqués par le code antérieur. Un problème qui subsiste ici, est que l'utilisation permanente des compteurs (_refcount_) va souvent invalider le contenu de la mémoire cache des processeurs, et va donc limiter fortement les performances sur des machines multiprocesseurs. C'est ici que commence le travail de Nick Piggin, puisqu'il incorpore un nouvel algorithme, nommé « _RCU-walk_ », qui va permettre de faire sauter le goulet d'étranglement qui existait avec l'algorithme _ref-walk_. L'opération de « [_Read-Copy-Update_](http://en.wikipedia.org/wiki/Read-copy-update) », initiée par l'appel à `« rcu_read_lock() »`, se fait maintenant sur **la totalité du chemin**, au lieu de s'effectuer sur chacun des composants du chemin. On fait le pari que tous les _dentry_ seront présents dans le _dcache_, et ce pari est payant la plupart du temps. De cette manière l'opération d'incrémentation du compteur _refcount_ ne se fait plus que sur le _dentry_ final, au lieu d'avoir lieu sur les composants successifs du chemin parcouru. Quand, par malheur, un _dentry_ n'est pas présent dans le _dcache_, alors l'algorithme _RCU-walk_ s'efface gracieusement et laisse opérer son prédécesseur _ref-walk_ comme avant. Nick Piggin s'est aussi occupé du cas où un _dentry_ est renommé par un processeur, alors que le chemin est parcouru. Le conflit est évité grâce à l'emploi d'un verrou spécial de type « [_seqlock_](http://en.wikipedia.org/wiki/Seqlock) ». Ce type de verrou ne bloque pas l'accès, mais permet de détecter qu'il y a eu un changement. En (très) résumé, le travail de Nick a donc consisté à changer _complètement_ la façon dont travaille le cache des _dentry_, afin d'optimiser ses performances. Il a également nettoyé tout le code de recherche de chemin d'accès (_pathname lookup_), en restreignant encore plus l'emploi du verrou _dcache\_lock_ qui était encore employé dans certaines zones. On retrouve également un verrou fin, le _dcache\_lru_lock_, qui est posé sur la liste des _dentry_ ([LRU](_Least Recently Used_)) et des changements sur l'interfaçage entre les systèmes de fichiers et le VFS. On voit donc bien que cette série de _patches_ est très complexe et touche de nombreuses zones de la couche VFS qui est au cœur du noyau. La promesse du travail de Nick Piggin c'est une amélioration des performances de montée en charge dans les opérations sur les fichiers. Par exemple, on peut imaginer que sur un gros serveur Web de nombreux processus tentent d'ouvrir des fichiers en même temps en se gênant les uns les autres. Dans ce cas de figure et dans bien d'autres, il est probable que le noyau 2.6.38 permettra d'améliorer sensiblement les performances. ## Trusted keys Le mécanisme « [_Trusted and encrypted keys_](https://lwn.net/Articles/408439/) », qui constitue une brique de base renforçant la sécurité et l'intégrité des systèmes GNU/Linux, a été intégré dans le noyau 2.6.38. Le développeur Mimi Zohar de la firme IBM travaille depuis plusieurs années sur [son _patch_ EVM](https://lwn.net/Articles/394170/) (_Extended Verification Module_) sans avoir pu le faire intégrer, jusqu'à présent, dans la branche principale du noyau. EVM est une protection cryptographique destinée à vérifier si une modification a eu lieu sur certains fichiers ou exécutables du système. Pour cela, [une empreinte](http://fr.wikipedia.org/wiki/Fonction_de_hachage) (un _hash_ [SHA-1](http://fr.wikipedia.org/wiki/SHA-1)) de ces fichiers est stocké dans les attributs étendus ([xattr](http://en.wikipedia.org/wiki/Xattr)) du système de fichiers. Linux possède déjà un mécanisme de vérification des fichiers et programmes qui a été intégré dans le noyau 2.6.30. Nommé IMA, pour _Integrity Measurement Architecture_, ce mécanisme ne permet une vérification efficace que contre les attaques en ligne (_online attacks_), puisqu'il effectue ses vérifications lors de l'ouverture des fichiers ou lors de l'exécution des programmes. Si un attaquant a un accès physique à la machine, alors il peut contourner la protection en démarrant sur un _live-CD_ et en changeant les attributs étendus (_offline attack_) avant de redémarrer la machine. Le mécanisme EVM, proposé par Mimi Zohar, a pour but de corriger cette faiblesse en générant une clé cryptographique qui va servir à signer les empreintes (_hashes_) des fichiers. Cette clé sera stockée dans le module de sécurité TPM (Trusted Platform Module) qui est un composant cryptographique matériel présent sur la carte mère de la machine. Si un petit malin ayant accès à la machine s'amuse à la redémarrer après avoir changé les _hashs_ présents dans les attributs étendus, il sera amèrement déçu. Lors du démarrage de la machine, la signature des hashs qui est présente dans le TPM sera vérifiée par la fonction `« evm_verifyxattr() »`, et le résultat indiquera clairement que les _hashs_ ont été modifiés et qu'une tentative d'entourloupe a eu lieu. En représailles, le noyau ne démarrera pas et le petit malin sera bien feinté. Pour que tout ceci fonctionne bien et qu'aucune faiblesse ne subsiste dans cette gymnastique cryptographique, il faut être certain que la clé maîtresse d'EVM ne sera jamais accessible depuis l'espace utilisateur. Cette objection a été soulevée sur les listes de diffusion, et c'est en partie ce qui explique le blocage d'EVM pour l'intégration dans la branche principale. Quand on veut faire intégrer un _patch_ en « _mainline_ », il ne sert à rien de se lancer dans des récriminations contre les opposants. Cela ne marche jamais, et il vaut mieux s'atteler à répondre à leurs objections techniques et à proposer des solutions. C'est ce qu'a fait Mimi Zohar en écrivant le _patch_ « [_Trusted and encrypted keys_](https://lwn.net/Articles/408439/) » qui entre dans ce nouveau noyau 2.6.38. Pour arriver au but à long terme qui est l'intégration d'EVM dans une prochaine version, il faut donc tout d'abord sécuriser les clés maîtresses. [Le _patch_ qui a été retenu](http://thread.gmane.org/gmane.linux.kernel.lsm/11721) ajoute deux nouvelles sortes de clés au [trousseau de clés](http://www.mjmwired.net/kernel/Documentation/keys.txt) du noyau Linux. La première, la « _trusted key_ », est générée par le TPM et elle est chiffrée avec la clé interne du module _« storage root key »_ RSA 2048 bits, de façon à la protéger (_sealing_). L'accès à la clé (_unsealing_) ne se fait que si la configuration complète de la machine n'a pas été modifiée, c'est-à-dire si le BIOS, le chargeur et le système d'exploitation, sont conformes à ce qui a été enregistré au sein du TPM dans son _« Platform Configuration Register »_. Bien entendu, une fois que la protection est déverrouillée par un utilisateur légitime, il est possible de changer le PCR pour mettre à jour sa machine. La seconde sorte de clé, « _encrypted key_ », ne repose pas sur les capacités du TPM, mais est tout simplement chiffrée avec [l'algorithme AES](http://fr.wikipedia.org/wiki/Standard_de_chiffrement_avanc%C3%A9) présent dans le noyau, ce qui est plus rapide que d'utiliser le TPM et son mode de chiffrage asymétrique à clé publique. Cette _encrypted key_ peut elle-même être chiffrée avec une clé maîtresse qui est souvent une clé de type « _trusted_ ». [L'e-mail envoyé](http://article.gmane.org/gmane.linux.kernel.lsm/11721) sur la liste de diffusion du noyau donne de nombreux détails au sujet de ces clés et explique comment les utiliser. Une [documentation complète](http://linux-ima.sourceforge.net/) du mécanisme d'intégrité du noyau est également disponible. Avec ces deux nouveaux types de clés protégées (activées par les options « CONFIG\_TRUSTED\_KEYS » et « CONFIG\_ENCRYPTED\_KEYS » lors du _build_), il est possible de tout garder en espace noyau et de ne faire passer aux applications qu'un « _blob_ » complètement opaque (ASCII hexa) qui n'augmentera pas la surface d'attaque. C'est une garantie que [le futur système EVM](http://linux-ima.sourceforge.net/#Enabling_EVM) ne sera pas sensible aux éventuels problèmes et défaillances se trouvant en espace utilisateur, et c'est donc un pas de plus vers son inclusion. ## Group scheduling Le _patch_ de [group scheduling](https://lwn.net/Articles/418884/), qui a tant fait parler de lui à la fin de l'année dernière, a été intégré dans le noyau 2.6.38. Ce _patch_ permet d'améliorer sensiblement l'interactivité dans certains cas particuliers, et il est très attendu par les utilisateurs ayant lu [l'article de Phoronix](http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1) qui a popularisé ce travail. Depuis [la dépèche LinuxFr](https://linuxfr.org/news/patch-pour-le-noyau-linux-am%C3%A9liorant-linteractivit%C3%A9-entre-les-a) de Victor en novembre dernier, le code de Mike Galbraith a été quelque peu modifié, mais l'idée générale est toujours la même. Si l'ordonnanceur du noyau Linux se nomme CFS ([_Completely Fair Scheduler_](http://fr.wikipedia.org/wiki/Completely_Fair_Scheduler)), c'est bien parce qu'il est _vraiment_ équitable. Il divise strictement le temps de processeur disponible entre tous les processus qui s'exécutent sur la machine. Imaginons que vous lanciez une grosse compilation en mode « -j64 » (c'est-à-dire avec 64 _jobs_ simultanés) et que vous ayez en plus un processus mplayer en train de s'exécuter, car vous regardez un film. L'ordonnanceur CFS va simplement diviser les ressources processeur en 65 morceaux, c'est-à-dire qu'il va choisir d'attribuer une tranche (_slice_) de temps processeur à mplayer, seulement une fois sur 65. Il y a fort à parier que mplayer ne va pas être content d'avoir si peu de ressources, et qu'avec cette méthode, l'interactivité de votre bureau Linux va souffrir. L'idée de Mike Galbraith, qui, en fait, lui a été soufflée par Linus, consiste simplement à utiliser la notion de « [cgroups](http://en.wikipedia.org/wiki/Cgroups) » (_Control Groups_) pour isoler certains processus. De cette façon, l'ordonnanceur CFS affectera équitablement les ressources de calcul entre les _cgroups_ et non pas directement entre les processus. Dans l'exemple évoqué ci-dessus, on aura un _cgroup_ pour les 64 jobs de _make_ et un autre _cgroup_ pour _mplayer_. Les besoins de votre lecteur vidéo auront bien plus de chance d'être satisfaits, puisque, à chaque attribution d'une nouvelle _slice_, _mplayer_ aura une chance sur deux d'être le gagnant. Cela ne veut pas dire qu'il va s'attribuer en permanence 50 % des ressources et ne jamais les relâcher ; c'est juste que chaque fois que _mplayer_ aura besoin d'avoir du temps processeur, il sera servi à égalité avec le _cgroup_ des _jobs_ lancés par _make_. À l'origine, le code de regroupement des cgroups se faisait en fonction des « TTY », c'est-à-dire des terminaux virtuels. Depuis [le code a évolué](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5091faa449ee0b7d73bc296a93bca9540fc51d0a) et il a été décidé de faire une ségrégation des _cgroups_ en fonction de l'identifiant de session des processus. Ces sessions se lancent classiquement avec l'appel `« setsid() »` et permettent de définir des groupes de processus. Par exemple, vous pouvez faire un petit `« ps axgj »` sur votre machine et la colonne « SID » vous indiquera les groupes de sessions qui existent. L'approche basée sur les TTY fonctionnait bien, mais elle semblait trop limitée puisque, pour la grande majorité des utilisateurs, ce sont les applications graphiques qui comptent et pas les terminaux virtuels. Avec le partage des ressources en fonction de l'ID de session, on a une solution un peu plus générale et donc potentiellement plus utile. Il faut quand même garder à l'esprit que cette nouvelle fonction, accessible via l'option « CONFIG\_SCHED\_AUTOGROUP », n'est que la configuration de base (et désactivée par défaut, qui plus est). Il est tout à fait possible, comme cela a été suggéré dans le [_monstro-thread_](http://thread.gmane.org/gmane.linux.kernel/1050575) de la LKML, d'effectuer une ségrégation des _cgroups_ selon d'autres critères. En dépit de toute la publicité qui lui a été accordée sur le web, ce _patch_ de « _group scheduling_ » avec le critère d'ID de session n'est pas d'une utilité transcendante pour les utilisateurs normaux. Certes, Linus [aime beaucoup le patch](http://article.gmane.org/gmane.linux.kernel/1063283), parce qu'il n'y a rien à configurer (_it just works!_) et parce que les gains sont réels pour son mode d'utilisation particulier. Ingo Molnar a lui aussi [chanté les louanges](http://article.gmane.org/gmane.linux.kernel/1084129) de ce _patch_ et l'a décrit comme étant : >_L'une des plus importantes et des plus visibles améliorations de l'interactivité qui a été incluse dans l'ordonnanceur de Linux._ On peut là-aussi s'interroger sur ce qu'Ingo considère comme une utilisation « typique » de son système d'exploitation : >_J'ai essayé quelques charges de travail typiques, comme faire un _build_ du _kernel_ avec "make -j20" tout en lançant le test _hackbench_. L'interactivité de Firefox n'a pas été affectée de façon mesurable._ Lennart Poettering de son côté [s'est empressé d'intervenir](http://article.gmane.org/gmane.linux.kernel/1063354) pour répondre à Linus et pour critiquer ce _patch_. Il propose une approche basée, vous vous en doutez, sur son nouveau démon d'_init_ « systemd » : >_Tout ça est complètement inutile pour les utilisateurs normaux. Le noyau porte ton nom, mais cela ne veut pas dire que ta propre utilisation soit typique ou qu'elle soit représentative pour plus qu'une poignée de _hackers_ comme toi.>J'ai juste préparé un _patch_ pour _systemd_ qui met tous les services et toutes les sessions utilisateur dans leurs propres _cgroups_. Si on active par défaut cette fonction dans _systemd_, alors cela voudra dire que les utilisateurs n'auront rien à configurer, parce que les distributions utilisant _systemd_ auront ce comportement par défaut._ Il semble évident que pour généraliser complètement la fonction de _« group scheduling »_ et pour la rendre vraiment utile aux utilisateurs classiques des interfaces graphiques modernes, il faudra en passer par la solution en espace utilisateur prônée par Lennart. En attendant, le noyau 2.6.38 permet déjà de bien s'amuser avec cette nouvelle fonction. ## Infrastructure LIO L'infrastructure de _Target iSCSI LIO_ ([_Linux-Iscsi.Org_](http://www.linux-iscsi.org/index.php/Main_Page)) fait son entrée dans le noyau 2.6.38, après une [longue compétition](https://lwn.net/Articles/420691/) qui l'a opposée à son concurrent SCST. Le protocole [iSCSI](http://fr.wikipedia.org/wiki/ISCSI) (Internet Small Computer System Interface) est une norme officielle de l'[IETF](http://fr.wikipedia.org/wiki/Internet_Engineering_Task_Force) qui permet d'encapsuler des commandes SCSI pour les faire passer dans un réseau TCP/IP. De cette façon, on peut relier une machine cliente (nommée « initiator ») à un périphérique distant comme un disque SAN (nommé « target »). Cette norme iSCSI est intéressante à utiliser parce qu'elle est moins coûteuse à mettre en œuvre que le [_Fibre Channel_](http://fr.wikipedia.org/wiki/Fibre_Channel) et qu'elle réutilise les réseaux _Ethernet_ classiques. Dans la plupart des cas, on se sert du code iSCSI présent dans le noyau quand on a besoin d'accéder au disque distant. On agit donc en tant qu'initiateur, et le code qui permet de jouer le rôle de cible (_target_) ne nous concerne pas vraiment. Néanmoins, dans certaines configurations particulières, il peut être utile d'installer un système GNU/Linux qui jouera le rôle de cible, et le noyau permet aussi cette configuration grâce à l'infrastructure TGT ([_Linux SCSI target framework_](http://stgt.sourceforge.net/)) et son option de configuration « CONFIG\_SCSI\_TGT ». Cette solution TGT existe depuis des années, mais, vivant en grande partie en espace utilisateur, elle n'est pas sans poser quelques problèmes, notamment [en termes de performances](http://thread.gmane.org/gmane.linux.iscsi.tgt.devel/219). Les développeurs de Linux étaient donc à la recherche d'un remplaçant crédible à intégrer dans le noyau, et ils ont évalué les deux projets les plus prometteurs. Dans le coin droit du ring, le champion SCST ([_SCSI target subsystem for Linux_](http://scst.sourceforge.net/)) qui propose une multitude de fonctions complexes et un grand nombre de pilotes. Dans le coin gauche, LIO ([_Linux-Iscsi.Org_](http://www.linux-iscsi.org/index.php/Main_Page)) qui est plus simple et possède moins de fonctions, mais dont le code est considéré comme un peu plus « propre ». La bataille a été âpre entre les deux compétiteurs, au point que [l'article de LWN](https://lwn.net/Articles/420691/) qualifie les discussions de « ugly », et [les comparaisons](http://scst.sourceforge.net/comparison.html) plus ou moins biaisées n'ont pas manquées. La tension est d'autant plus grande que les enjeux économiques ne sont pas négligeables. Derrière ces deux solutions, il y a, certes, l'_ego_ des développeurs, mais il y a aussi des entreprises qui voudraient bien que leur code entre dans la branche principale du noyau Linux. Pour SCST, on trouve le développeur Vladislav Bolkhovitin et la société [ID7](http://www.id-7.com/html/about.html) qui finance les développements, tandis que dans le cas de LIO, c'est le développeur Nicholas Bellinger qui est employé par la société [RisingTide Systems](http://www.risingtidesystems.com/). L'arbitre de cette dispute n'est autre que James Bottomley, le mainteneur du sous‐système SCSI dans le noyau Linux, qui s'est bien gardé d'entrer dans les querelles non techniques qui ont émaillées la saga du choix de la nouvelle infrastructure de _Target_ iSCSI. Finalement, la situation a fini par se décanter au fil des mois et des sommets du noyau et, après [une dernière passe](https://lkml.org/lkml/2010/12/16/518) de relecture et de nettoyage du code, James Bottomley a annoncé en décembre dernier que LIO allait [intégrer la branche principale](https://lkml.org/lkml/2010/12/17/183) :>_OK, je pense que nous avons atteint le point ou tout a été suffisamment rodé en dehors de la branche principale. Nous pourrons compléter les derniers items de la « todo list » directement sur le code intégré._ Même s'il manque encore quelques fonctions dans LIO qui arriveront [plus tard](http://article.gmane.org/gmane.linux.kernel/1106248), nous pouvons profiter [dès maintenant](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5) de cette nouvelle infrastructure moderne de _Target_ iSCSI (voir [le graphique](http://www.h-online.com/open/imgs/45/6/3/6/8/1/1/LIO_Architecture_KL2.6.38_Pt_4-2e01a19c8d08b509.png)) : - l'architecture est non-bloquante, complètement « multithreadée » et elle profite des unités vectorielles SIMD des processeurs ; - fonction de « [_persistent reservations_](http://www.linux-iscsi.org/wiki/Persistent_Reservations) » pour faire de l'isolation ([_fencing_](http://en.wikipedia.org/wiki/Fencing_%28computing%29)) au cas où un nœud se met à avoir des problèmes ; - mode d'accès [ALUA](http://www.linux-iscsi.org/wiki/Asymmetric_Logical_Unit_Assignment) (_Asymmetric Logical Unit Assignment_) pour choisir un chemin optimisé et performant vers les baies partagées sur le réseau de stockage ; - multiplexage des connexions et répartition de charge ([MCS](http://www.linux-iscsi.org/wiki/Multiple_Connections_per_Session)) ; - correction complète des erreurs ([ERL0, ERL1 et ERL2](http://www.linux-iscsi.org/wiki/Error_Recovery_Level)) ; - indépendance complète du média de stockage avec [différents « _backstores_ » adaptés](http://www.linux-iscsi.org/wiki/IBLOCK#Backstores). Malheureusement, comme cela arrive parfois dans le monde très darwinien du développement de Linux, la décision technique prise par un mainteneur de sous‐système n'a pas été appréciée par les promoteurs de l'infrastructure concurrente. Le choix de LIO a fait réagir Vladislav Bolkhovitin qui a immédiatement [crié au complot et demandé des explications](https://lkml.org/lkml/2010/12/17/225) :>_Est-ce que quelqu'un peut expliquer quels sont les avantages de LIO par rapport à SCST ? >LIO est évidemment inférieur, que ce soit en termes techniques (voir la comparaison http://scst.sourceforge.net/comparison.html), ou en termes d'utilisateurs et de taille de la communauté. Les tentatives frénétiques pour essayer de lui donner meilleure allure par rapport à SCST n'ont rien changé. Dans les échanges récents, combien de gens ont voté pour LIO ? Personne. Combien ont voté pour SCST ? Un paquet. Est-ce que des vrais utilisateurs de LIO ont participé aux échanges ? Pas un seul. >Est-ce tout ça ne compte pas pour toi ? Que le code soit le meilleur ne signifie plus rien pour la communauté Linux ? >Ou alors, il y a des raisons secrètes ?_ En dépit des accusations de Vladislav (« _Undercover games_ » que j'ai traduit maladroitement mais sans trouver mieux par « raisons secrètes »), James Botomley a pris les choses calmement et [a répondu point par point](https://lkml.org/lkml/2010/12/17/236) :>>>_voir la comparaison_>_Pour être honnête, je me fiche des comparaisons point par point sur les fonctions respectives. Chacun des produits a des fonctions spécifiques de niche que l'autre n'a pas. Les fonctions de base sont disponibles dans les deux cas et sont solides._>>_combien de gens ont voté pour LIO ?_>_Ce n'est pas une démocratie. Il s'agit de choisir le projet qui est le plus réceptif aux besoins de la communauté et qui est le plus maintenable et facile à adapter. Ces six derniers mois LIO a fait des effors sincères pour répondre aux besoins des utilisateurs, pour nettoyer son code et pour s'adapter aux autres projets qui vont s'interfacer au‐dessus et autour de l'infrastructure. De l'autre côté, tu as passé ton temps à te disputer avec le mainteneur de _sysfs_, en expliquant que c'était toi qui avait raison et lui tort._ Bien entendu, comme la personnalité de Vladislav le laissait soupçonner, le leader de SCST n'a pas été convaincu et a continué [à protester bruyamment](https://lkml.org/lkml/2010/12/17/298) :>_James, je suis désolé, mais ta position est absurde. En tant que mainteneur, tu es supposé choisir le code qui est DÉJÀ le meilleur, et pas celui qui promet de devenir le meilleur dans un futur indéterminé. Pourquoi ne pas comparer toi‐même, au lieu de te reposer sur les ~~mensonges~~ déclarations de « NicholasB » et de ses supporters ? Dans la communauté du noyau, il n'y a qu'une seule personne qui soutient LIO, c'est Christoph Hellwig. Il est autoritaire et les gens n'osent pas le contredire. Mais son avis est aussi biaisé ; il y a plusieurs années, il a préféré TGT au lieu de choisir SCST qui existait déjà._ Évidemment, ces arguments assez paranoïaques n'ont fait que renforcer l'opinion de James Bottomley. Comme cela a été souligné plusieurs fois par Linus Torvalds et par d'autres mainteneurs, ce n'est pas seulement le code qui compte, mais surtout la capacité à travailler au sein de la communauté. C'est [ce que lui a expliqué](https://lkml.org/lkml/2010/12/17/337) James Bottomley :>>>_En tant que mainteneur, tu es supposé choisir le code qui est DÉJÀ le meilleur._ >_Exactement ! Tant que le choix s'oriente vers le projet qui est le plus orienté vers la communauté, alors les manques techniques seront comblés. Inversement, il est possible de détruire complètement un projet simplement en s'aliénant la communauté. C'est pour ça que la communauté est plus importante qu'une liste de fonctions supportées. >Des tonnes d'améliorations potentielles du noyau ont échoué à cause de problèmes avec le mainteneur._ Nous avons là une sorte de cas d'école pour analyser le mode de développement très spécifique de Linux. Tout d'abord, comme le rappelle fermement James Botomley, il ne s'agit pas d'une démocratie ; les décisions des mainteneurs de sous‐systèmes et, en dernière analyse, les décisions de Linus, sont souveraines. Si un des gardiens du noyau vous indique qu'il faut modifier votre code pour qu'il soit accepté, alors il ne sert à rien de pester et de récriminer ; mieux vaut se retrousser les manches, car, en acceptant les remarques des autres, vous prouvez votre bonne volonté et votre intégration dans la communauté. D'autre part, en acceptant les changements et en assurant la maintenance de votre ensemble de _patches_ pendant des mois, vous donnez une indication que votre code ne sera pas abandonné à son sort après son intégration. Les mainteneurs de Linux ont encore en mémoire le système de fichiers _Reiser3_ qui a été complètement délaissé par Hans Reiser au profit du futur _Reiser4_. Ce cuisant souvenir explique le fait qu'ils exigent d'avoir l'assurance d'une maintenabilité correcte, et c'est un facteur très important dans leur choix d'une solution à long terme. Enfin, [cela va sans dire, mais cela ira mieux en le disant](http://dinoutoo.pagesperso-orange.fr/histo/tal1.htm), les personnalités « difficiles » et « abrasives », comme Hans Reiser ou Vladislav Bolkhovitin, sont difficilement compatibles avec le mode de développement collaboratif du noyau Linux. Quand on voit des complots partout, quand on refuse d'entendre les critiques et qu'on se dispute en permanence avec tout le monde, il est fort improbable de voir son code intégré dans la branche principale. #En bref ###Fitrim À la fin de [la section sur FITRIM](https://linuxfr.org/news/sortie-de-la-version-2637-du-noyau-linux#long2) dans la dépêche sur le noyau 2.6.37, il était précisé que cette fonction n'était activée que sur le système de fichiers Ext4. Rappelons que FITRIM permet d'informer le système de fichiers des pages qui ont été effacées sur un disque SSD, et cet effacement se fait en mode _batch_ (_batch discard_) plutôt qu'à la volée pour le TRIM classique (_on-the-fly_ TRIM). Le nouveau noyau 2.6.38 permet maintenant de profiter des avantages de FITRIM sur les systèmes de fichiers [Ext3](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b853b96b1dbdc05fc8eae141a595366d8172962b) et [XFS](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a46db60834883c1c8c665d7fcc7b4ab66f5966fc). Attention toutefois, car le lancement d'une passe globale FITRIM peut dégrader les performances et Christoph Hellwig [conseille plutôt](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a46db60834883c1c8c665d7fcc7b4ab66f5966fc) d'utiliser cette fonction en dehors des périodes d'utilisation normale de la machines (on peut configurer FITRIM au démarrage du sytème par exemple). ###Transmit Packet Steering Après le patch [Receive Packet Steering](https://linuxfr.org/news/nouvelle-version-2635-du-noyau-linux#long4) qui était entré dans le noyau 2.6.35, voici maintenant que les _hackers_ de Google ont réussi à faire intégrer leur nouveau _patch_ [_Transmit Packet Steering_](http://article.gmane.org/gmane.linux.network/176290). La première fonction découpait le flot de paquets réseau entrant (_receive queue_) pour les affecter à des processeurs particuliers, tandis que la nouvelle fonction ([_patch_ XPS](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1d24eb4815d1e0e8b451ecc546645f8ef1176d4f)) fait exactement l'inverse. Elle part d'un CPU spécifique et elle lui affecte une queue de paquets réseaux sortants. Cette affectation se fait par le biais d'un masque CPU pour chaque queue qui est stockée dans `« /sys/class/net/eth/queues/tx-/xps_cpus »`. Cette association entre un processeur et une queue d'envoi de paquets permet d'améliorer la « localité » des données et donc de mieux profiter des caches de chacun des processeurs. Tom Herbert a procédé à de nombreux tests, et il a démontré un gain assez sensible d'environ 20 % apporté par ce _patch_ de guidage de transmission des paquets (_Transmit Packet Steering_). Test _netperf TCP_RR_ avec carte de type _bnx2x_ sur machine 16 cœurs AMD : - sans le _patch_ XPS : 996 000 transactions/s avec 100 % d'utilisation des CPU. - avec le _patch_ XPS : 1 234 000 transactions/s avec 100 % d'utilisation des CPU. ###Améliorations de Btrfs Le système de fichiers _Btrfs_, qui a vocation à remplacer la série classique des Ext2/3/4, propose de nombreuses fonctions fort sympathiques. Parmi celles-ci, il existe la possibilité de compresser les données à la volée de façon transparente avec [l'algorithme « _deflate_ »](http://fr.wikipedia.org/wiki/Deflate) de la bibliothèque [_zlib_](http://fr.wikipedia.org/wiki/Zlib). Le _hacker_ Li Zefan, employé par la société Fujitsu, a écrit [un patch](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=261507a02ccba9afda919852263b6bc1581ce1ef) qui permet d'utiliser également [l'algorithme LZO](http://fr.wikipedia.org/wiki/LZO) avec Btrfs. Selon [ses tests](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a6fa6fae40ec336c7df6155255ae64ebef43a8bc), ce nouvel algorithme est un peu moins efficace en termes de compression de données, mais il est, en contrepartie, _beaucoup_ plus rapide. Comme nous sommes dans le cas d'une compression à la volée effectuée par le système de fichiers, cet argument de la rapidité est très important à prendre en compte. Voici, par exemple, les résultats d'une extraction d'une archive _tar_ des sources du noyau sur une partition Btrfs : - **Nocompress** : extraction en 66,6 secondes pour une taille finale de 381,21 Mio ; - **Compression zlib** : extraction en 94,4 secondes pour une taille finale de 132,36 Mio ; - **Compression LZO** : extraction en 70,1 secondes pour une taille finale de 193,80 Mio. ###Tracing L'infrastructure de traçage du noyau continue d'être améliorée, version après version. Cette fois-ci, on trouve la possibilité, [développée par notre ami Frédéric Weisbecker](http://thread.gmane.org/gmane.linux.kernel/1064271), d'utiliser les points de traçage sans être utilisateur privilégié. Cela s'effectue grâce à une macro `« TRACE_EVENT_FLAGS() »` qui est appliquée aux points de traçage. Actuellement, il n'existe qu'une sorte de drapeau (`TRACE_EVENT_FL_CAP_ANY`) qui est actif sur les appels système, mais d'autres sont envisageables. Toujours en ce qui concerne le _tracing_, on trouve [le _patch_ d'Arjan van de Ven](https://lwn.net/Articles/417772/) qui rend conditionnels les points de traçage. Alors qu'auparavant, un point de traçage était assez binaire (soit actif, soit inactif), il est maintenant possible de le faire travailler seulement si certaines conditions sont remplies. C'est un gros gain en termes de souplesse d'utilisation, mais l'objection qui vient immédiatement à l'esprit, c'est le coût en ressource de ces « IF » qui évaluent la condition. Pour éviter la surcharge (_overhead_), une nouvelle macro de définition des points de traçage a été créée. `« TRACE_EVENT_CONDITION() »` s'ajoute ainsi à la macro `« TRACE_EVENT() »` et elle permet de tester la condition sans que le point de traçage ne déclenche son mécanisme. Si la condition est remplie, alors le travail de traçage sera déclenché, mais si elle n'est pas remplie, ce sera comme si le point n'avait pas été activé du tout. ###LZMA dans SquashFS Le preux chevalier Phillip Lougher, [qui avait essuyé un échec cinglant](https://linuxfr.org/news/nouvelle-version-2634-du-noyau-linux#squashfs) lors du cycle du noyau 2.6.34, a enfin pris sa revanche sur le dragon cracheur de feu. Phillip avait essayé d'ajouter le support de l'algorithme de compression LZMA dans le système de fichiers _SquashFS_, mais son _patch_ incorporait tout le code directement dans le _header_ `« unlzma_mm.h »`. Après le refus horrifié de Linus, la seule solution a été de se remettre au travail et de proposer un _patch_ propre. Le noyau 2.6.38 [accueille donc](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=81bb8debd0d570dc67dc1e9d8b612632cb941893) maintenant cette nouvelle possibilité de compression ([algorithme XZ](http://fr.wikipedia.org/wiki/XZ_%28format_de_fichier%29)) qui est bien plus efficace que le classique _gzip_. Les développeurs de Fedora ont d'ores et déjà [annoncé](http://fedoraproject.org/wiki/Features/LZMA_for_Live_Images) qu'ils allaient utiliser ce mode par défaut pour leur _Live-CD_ Fedora 15. Une comparaison effectuée avec l'ancien système a montré un gain allant de 8 % (_game spin_) à 18 % (_desktop spin_), ce qui permettra de stocker plus de programmes dans l'espace limité du disque. ###Sécurisation du noyau L'effort de sécurisation renforcée du noyau continue avec cette version 2.6.38. Grâce au lobbying incessant de Kees Cook et de Dan Rosenberg plusieurs patchs, qui recouvrent souvent des fonctions présentes dans GRSecurity, ont trouvé leur chemin vers la branche principale. On peut citer l'affichage des adresses mémoire du noyau qui est maintenant [masqué par défaut](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=455cd5ab305c90ffc422dd2e0fb634730942b257). Alors qu'avant vous pouviez aller fureter librement dans /proc pour lire ces adresses mémoire, ce qui facilitait les tentatives de prise de contrôle, il vous faudra maintenant la (nouvelle) capacité [CAP\_SYSLOG](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ce6ada35bdf7) pour y accéder. Cette fonction se paramètre via /proc/sys/kernel/kptr\_restrict. Le nouveau noyau propose également un travail d'amélioration de l'option CONFIG\_DEBUG\_RODATA effectué par Ingo Molnar. Cette option permet de marquer en Read Only certaines pages mémoires du noyau et, avec le noyau 2.6.38, nous bénéficions maintenant d'une protection contre l'exécution sur les données. Le bit NX (No eXecute) est mis pour les sections [BSS](http://dev.fyicenter.com/Interview-Questions/UNIX/What_is_BSS_Block_Started_by_Symbol_.html) (Block Started by Symbol) et [un second patch](http://thread.gmane.org/gmane.linux.kernel.commits.head/276800) protège le chargement des modules noyau en mettant le bit RO/NX sur les données et le bit RO+X sur le code. Grâce à kptr\_restrict, au renforcement de l'option CONFIG\_DEBUG\_RODATA et à l'ajout de l'option CONFIG\_DEBUG\_SET\_MODULE\_RONX le noyau Linux 2.6.38 sera mieux à même de résister aux exploits et les différences qui existent avec GRSecurity vont en se réduisant. ###B.A.T.M.A.N Le protocole de réseau [B.A.T.M.A.N](http://fr.wikipedia.org/wiki/B.A.T.M.A.N.) (Better Approach To Mobile Adhoc Networking) est un type de [réseau ad hoc](http://fr.wikipedia.org/wiki/R%C3%A9seau_ad_hoc) qui a été intégré à la branche -staging lors du cycle du [noyau 2.6.33](https://linuxfr.org/news/nouvelle-version-2633-du-noyau-linux#batman). Ces réseaux qui s'auto-organisent sont très à la mode en ce moment du fait des menaces qui pèsent sur le contrôle d'Internet dans des pays non démocratiques. Techniquement il n'est pas certain que ces réseaux ad hoc pourront "passer à l'échelle" mais B.A.T.M.A.N est certainement très intéressant sur un plan conceptuel et pour expérimenter des solutions innovantes. Dans le noyau 2.6.38 ce protocole réseau a été considéré comme suffisament stable pour sortir de la branche -staging et [intégrer la pile réseau de la branche principale](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c6c8fea29769d998d94fcec9b9f14d4b52b349d3). Une [documentation complète](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/networking/batman-adv.txt;h=77f0cdd5b0dd4fc2352d8b0b590d1afe2a29881b;hb=c6c8fea29769d998d94fcec9b9f14d4b52b349d3) est disponible pour permettre aux utilisateurs d'expérimenter les avantages et les inconvénients de ce type de réseau. ###Sous-système NFC Toujours dans le domaine des réseaux [le pilote pn544](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/nfc/nfc-pn544.txt;h=2fcac9f5996e32386459c1c066c2447227d79a15;hb=0329326e85aaa30fb8d427828c718d565c287385) écrit par Nokia inaugure le nouveau répertoire _drivers/nfc_. Ce nouveau sous-système du noyau est destiné à accueillir les pilotes supportant la [norme de communication NFC](http://fr.wikipedia.org/wiki/Communication_en_champ_proche) (Near Field Communication). De nombreux téléphones sont équipés de ces puces qui permettent d'échanger des informations à très courte distance par exemple pour effectuer des micro-paiements ou pour échanger des cartes de visites. Bien entendu on ne peut que se réjouir de l'arrivée dans la branche principale de ce pilote libre pour le contrôleur NXP Semiconductors PN544 qui semble être la puce de référence choisie par Google pour ses smartphones Android. ###Device-mapper [Une nouvelle interface](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9d09e663d5502c46f2d9481c04c1087e1c2da698) permet au device-mapper (la couche qui est en charge de la gestion des volumes logiques) d'accéder au sous-système MD pour faire du RAID 4/5/6. [La documentation](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/device-mapper/dm-raid.txt;h=33b6b7071ac8d65e386aead1e4e6f6a916e9c502;hb=9d09e663d5502c46f2d9481c04c1087e1c2da698) écrite par Neil Brown explique comment utiliser cette nouvelle fonctionalité. D'autre part les performances de device mapper ont été améliorées par deux patchs de Mikulas Patocka ([1](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d9bf0b508ddfe19883b982b29a03c02ccbf53806) - [2](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8d35d3e37eed884ba15229a146df846f399909b4)) et les chiffres publiés sont très prometteurs. Toujours en ce qui concerne le [device-mapper](http://en.wikipedia.org/wiki/Device-mapper) on peut noter [le patch d'Andi Kleen](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c029772125594e31eb1a5ad9e0913724ed9891f2) qui modifie dm-crypt pour permettre l'utilisation de multiples liste de tâches (workqueues). Auparavant il n'y avait qu'une seule workqueue de chiffrage/déchiffrage par mapping dm-crypt et cela constituait un goulet d'étranglement. Avec ce patch il y aura une workqueue par processeur pour permettre de travailler en parallèle et d'augmenter les débits. Enfin, plus anecdotique, vous pouvez maintenant chiffrer les blocs de votre disque avec [des clés différentes](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d1f9642381847e2b94caa34c3533211cf36ffcf4). Cette capacité "multi-clés" est utilisé pour permettre un mode spécial de compatibilité avec Loop-AES qui est un patch bien connu vivant en dehors de la branche principale du noyau. ###AES-NI En parlant de l'algorithme de chiffrage symétrique [AES](http://fr.wikipedia.org/wiki/Advanced_Encryption_Standard) le noyau 2.6.38 propose une implémentation améliorée de [la fonction AES-NI](http://en.wikipedia.org/wiki/AES-NI) qui est présente dans les processeurs Intel récents et les futurs AMD Bulldozer. AES-NI est une extension de l'architecture x86 qui ajoute [sept nouvelles instructions](http://en.wikipedia.org/wiki/AES-NI#New_instructions) permettant d'accélérer considérablement les opérations de chiffrage/déchiffrage de l'algorithme AES. Alors qu'auparavant le support n'existait que pour les x86-64 le nouveau noyau apporte maintenant la compatibilité avec l'architecture traditionnelle x86 32 bits. Evidemment, comme à chaque fois qu'on peut profiter d'une accélération matérielle, le gain en performances est énorme. Le développeur Mathias Krause a posté le résultat de ses tests dm-crypt effectués sur une machine Core i7 M620 tournant à 2.67GHz : x86 | i586 | aes-ni | delta ------------|-----------|---------|---------- chiffrage ECB | 93.8 Mo/s | 123.3 Mo/s | +31.4% chiffrage CBC | 84.8 Mo/s | 262.3 Mo/s | +209.3% chiffrage LRW | 108.6 Mo/s | 222.1 Mo/s | +104.5% chiffrage XTS | 105.0 Mo/s | 205.5 Mo/s | +95.7% En plus de ce support des instructions AES-NI pour l'architecture x86-32 le code spécifique x86-64 a été optimisé et le débit des opérations de chiffrage/déchiffrage augmente un peu (voir le tableau des performances dans [le message de commit](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0d258efb6a58fe047197c3b9cff8746bb176d58a)). ###Hole punching Les systèmes de fichiers [XFS](http://fr.wikipedia.org/wiki/XFS) et [OCFS2](http://en.wikipedia.org/wiki/Ocfs2) possédent une caractéristique intéressante puisqu'il permettent de désallouer un espace se trouvant au beau milieu d'un fichier déjà existant. Cette fonction porte le nom très imagé de "creuser un trou" dans le fichier ([punching a hole](https://lwn.net/Articles/415889/)). Cela parait franchement bizarre de vouloir faire ça mais c'est utile dans certaines configurations virtualisées. Par exemple si le système invité (guest) est alloué globalement sur un espace discontinu alors le fait de désallouer les zones non utilisées au sein du fichier permettra de récupérer facilement de l'espace. Le développeur Josef Bacik, qui travaille pour Red Hat, a logiquement considéré qu'il n'était pas optimal de trouver cette fonction dans des systèmes de fichiers individuels. Pourquoi ne pas rendre le code plus générique afin que les autres systèmes puissent utiliser cette possibilité ? C'est le rôle [du patch](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=79124f18b335172e1916075c633745e12dae1dac) qu'il a proposé sur la LKML et qui a été accepté par Linus dans ce cycle 2.6.38. L'idée est simplement d'ajouter un mode FALLOC\_FL\_PUNCH\_HOLE à l'appel système [fallocate()](http://www.kernel.org/doc/man-pages/online/pages/man2/fallocate.2.html) qui sert déjà à manipuler l'espace disque des fichiers. Maintenant que cette option est disponible il est fort probable que les systèmes de fichiers Btrfs et Ext4 vont bientôt vous permettre de "creuser des trous" dans les fichiers ! ###Pilote graphique AMD En ce qui concerne les cartes graphiques AMD, le noyau 2.6.38 permet [la reconnaissance](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=958261d1e8755d1423beb0951ed0b9552c96f638) du coeur graphique présent dans les puces "[Fusion](http://fr.wikipedia.org/wiki/AMD_Fusion)" (en particulier le processeur Ontario). Du côté des cartes externes on trouve [le support](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9e46a48df24f9698b34d28385b320c529851e5f7) de la norme [PCI-Express 2.0](http://en.wikipedia.org/wiki/PCI_Express#PCI_Express_2.0) dans le pilote Radeon et surtout [l'arrivée du support](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2b2fd604bda01bfea9f1657ca468c134448e03a5) 2D/3D des cartes Radeon "Northern Islands" (ce sont les cartes série 6000 portant les noms de code Barts, Turks et Caicos). A partir de cette génération de cartes seul le fonctionnement via KMS (Kernel Mode Setting) sera possible et UMS (User-space Mode Setting) n'est plus utilisé. La carte Radeon HD 6970 (Cayman) qui est disponible depuis mi-décembre n'est pas encore supportée par le noyau Linux mais le travail est en cours et on peut s'attendre à la voir arriver dès le prochain cycle. ###Nouveau Le code de Nouveau, qui gère les cartes NVidia, a lui aussi été amélioré dans cette nouvelle version du noyau. On trouve le support des puces "Fermi" nvc0 (c'est à dire les GeForce 400/500). Le noyau 2.6.37 avait juste permis leut détection mais maintenant nous disposons d'une accélération 2D/3D avec un pilote mis à jour. Le point noir c'est que cette accélération dépend encore d'un [firmware](http://nouveau.freedesktop.org/wiki/NVC0_Firmware) qui n'est pas présent dans les sources du noyau. Pour les cartes un peu plus anciennes (c'est à dire la prolifique famille [NV50](http://en.wikipedia.org/wiki/NV50)) on trouve une [amélioration du code d'allocation mémoire](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a11c3198c9ba38d81e25b65e3908d531feba1372) ainsi qu'une [meilleure gestion](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=573a2a37e8648a3249426c816f51e7ef50f6f73e) de la mémoire vidéo. ###Pilote graphique Intel Dans le domaine des cartes Intel le noyau 2.6.38 apporte surtout des patchs permettant de mieux contenir la consommation et de gérer plus intelligement l'énergie. Jesse Barnes a indiqué que sur son laptop [le patch de rafraichissement mémoire](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b79d4990226defc3789f9ba492b27e9e56790857) (actif sur les puces Ironlake et Sandybridge) lui permettait d'économiser 0.5W par rapport aux anciens noyaux. On trouve également l'intégration du mode d'économie en [sommeil ultra-profond C6](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8fd2685911cb6c140e6d0588ac04990ce65d4537) et la possibilité [d'overclocker automatiquement](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a6044e23b784544fe567db75dbf9c4f684bd6d5b) le coeur graphique Sandybridge en cas de faible activité du processeur. Enfin Keith Packard, bien connu du monde du développement X.org, est l'auteur d'un patch qui permet de détecter automatiquement les changements d'écran (automatic hotplug detection) sans avoir à lancer de coûteuses interrogations en permanence (polling). ###Gestion des médias externes Puisque nous parlons du polling il est bon d'évoquer [le patch de Tejun Heo](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=77ea887e433ad8389d416826936c110fa7910f80) qui change la façon dont sont gérés les médias externes par le noyau Linux. Jusqu'à maintenant il n'y avait pas le choix et les applications en espace utilisateur devaient faire directment du polling pour savoir si un évènement était intervenu sur un périphérique (insertion ou éjection d'un disques optique ou d'une carte mémoire par exemple). Pour ça le périphérique en question était interrogé par la commande TEST\_UNIT\_READY mais cette façon de faire pose plusieurs problèmes. Tout d'abord l'interrogation depuis l'espace utilisateur est une opération lourde et coûteuse et il y aurait avantage à faire le travail directement dans le noyau. Ensuite les pilotes Windows utilisent la commande GET\_EVENT\_STATUS et le firmware des disques tend a être testé uniquement pour cette commande ce qui pénalise Linux qui passe par TEST\_UNIT\_READY. Enfin le polling depuis l'espace utilisateur est une opération risquée puisqu'il n'y a pas vraiment de moyen de savoir si l'interrogation ne va pas provoquer un conflit. Tejun signale que le polling durant une session de gravage de données peut provoquer une erreur. Pour résoudre tous ces problèmes d'un coup il a été décidé d'implémenter le polling des disques directement dans le noyau. L'avantage c'est que ce polling est bien plus léger (plus besoin d'ouvrir le périphérique) et _surtout_ qu'on peut retarder une interrogation pour qu'elle coincide avec un autre évènement pour que le coût soit encore plus dilué. Tous les pilotes vont devoir être changés et ils utiliseront désormais la fonction check\_events() au lieu de la fonction media\_changed(). Les "events" qui sont associés à cette nouvelle fonction sont au nombre de deux: DISK\_EVENT\_MEDIA\_CHANGE et DISK\_EVENT\_EJECT\_REQUEST. Il est possible d'indiquer la périodicité de polling en millisecondes dans "block.events\_dfl\_poll\_msecs". Actuellement la valeur est positionné à zéro ce qui signifie que la fonction n'est pas active et que les applications userspace actuelles vont continuer à fonctionner comme avant. C'est maintenant aux développeurs de ces applications de profiter de cette nouvelle fonction pour nous permettre d'économiser des Watts sur nos machines. ###V4L1 passe à la trappe L'infrastructure de gestion V4L2 ([Video4Linux](http://fr.wikipedia.org/wiki/Video4Linux) seconde génération) est présente dans le noyau depuis la série des 2.5.x. Une émulation était jusqu'à présent proposée pour gérer les périphériques qui utilisaient encore la vieille interface V4L1. Jugeant que la comédie avait assez duré il a été décidé qu'à partir du noyau 2.6.38 cette API d'émulation serait complètement retirée du noyau. Les applications V4L1 restantes devront soit passer par une bibliothèque en espace utilisateur pour les récalcitrantes, soit être convertie manu militari à l'API V4L2. Quelques pilotes V4L1 sans utilisateurs (cpia, stradis) ont été retirés du noyau 2.6.38. Les pilotes dépréciés ibmcam, konicawc et ultracam ont aussi été supprimés puisque ces derniers sont maintenant supportés par les pilotes GSPCA. ###BKL Le système de fichiers UDF ([Universal Disk Format](http://fr.wikipedia.org/wiki/Universal_Disk_Format)) est utilisé pour écrire des données sur divers média enregistrables de type DVD-R, CD-R, CD-RW, etc. Ce système de fichiers était l'un des derniers sous-systèmes assez importants du noyau à utiliser le verrou global (Big Kernel Lock) mais ce n'est plus le cas à partir de cette version 2.6.38. Un effort de nettoyage a été entrepris et Linus [a accepté d'intégrer](https://lkml.org/lkml/2011/1/11/360) la branche UDF libérée du BKL. Le développeur Arnd Bergmann a déjà annoncé son [plan à long terme](http://thread.gmane.org/gmane.comp.video.dri.devel/53755) pour en finir complètement avec le BKL même dans les recoins les plus obscurs et poussiéreux du noyau Linux. Certaines sous-parties jugés inutiles seront envoyées vers -staging puis carrément supprimés à partir du noyau 2.6.41. On peut citer [appletalk](http://fr.wikipedia.org/wiki/AppleTalk) ou [hpfs](http://fr.wikipedia.org/wiki/HPFS) qui sont promis à la disparition à brève échéance. D'autres secteurs de Linux seront nettoyés au karcher de leurs appels intempestifs au verrou géant (_Work around in an ugly way, but keep alive_). C'est le cas des par exemple d'[ufs](http://fr.wikipedia.org/wiki/Unix_File_System), du pilote [i810](http://en.wikipedia.org/wiki/I810) ou encore d'[IPX](http://fr.wikipedia.org/wiki/Internetwork_Packet_Exchange). Enfin un vrai travail de correction approfondi sera entrepris sur certaines parties qui le méritent (norme [adfs](http://fr.wikipedia.org/wiki/ADFS) ou protocole [X.25](http://fr.wikipedia.org/wiki/X.25)). ###Les ratés du noyau Enfin un dernier point qui n'a pas spécifiquement de rapport avec le noyau 2.6.38. Je voudrais signaler la remarquable présentation de Jon Corbet (éditeur du [site LWN](http://lwn.net/)) lors des dernières conférences Linux.conf.au et FOSDEM. Certes son accent est un peu difficile à comprendre mais les slides aident bien à la compréhension et puis ça vaut le coup puisque [la vidéo est passionnante](http://linuxconfau.blip.tv/file/4727307/) (lien vers [la version FOSDEM](http://video.fosdem.org/2011/maintracks/kernel-development.xvid.avi)). Au lieu de classiquement parler des réussites il a décidé d'évoquer les échecs, parfois retentissants, qui se sont produit lors du développement du noyau. Quels ont été les patchs rejetés, pourquoi ça n'a pas marché et _surtout_ quelles leçons en tirer pour les développements futurs. Hmm...finalement peut-être que cela à quand même un rapport avec le noyau 2.6.38 (cf la controverse LIO-SCST évoquée plus haut). Dans cette conférence vous entendrez ainsi parler des systèmes de fichiers Tux3 et Reiser4, de l'ordonnanceur deadline de Con Kolivas et de l'infrastructure de tracing SystemTap. Un véritable cimetière des éléphants des patchs noyau et une mine d'or de bons conseils pour éviter les embûches ! #Le bilan en chiffres En matières de statistiques ce noyau 2.6.38 retrouve des niveaux de contributions typiques par rapport à la déferlante qu'avait été [la version précédente](https://linuxfr.org/news/sortie-de-la-version-2637-du-noyau-linux#bilan). Comme d'habitude [L'article de synthèse du site LWN](https://lwn.net/Articles/429912/) permet de faire le point et on pourra également se reporter [site remword](http://www.remword.com/kps_result/) dédié aux statistiques du noyau Linux pour trouver les chiffres de ce cycle. En matière de patchs et de nombre de développeurs cette version est dans la moyenne avec l'intégration de 9 432 patchs écrits par 1 201 développeurs (chiffres du 10 mars). Red Hat est toujours la première entreprise en terme de patchs avec plus de 11% des contributions (mais derrière la catégorie fourre-tout des "hobbyists" qui ne sont pas payés pour coder le noyau et qui fournissent [plus de 15% des patchs](http://www.remword.com/kps_result/2_6_38_whole.html)). On trouve ensuite Intel, Novell et IBM qui sont des habitués du haut du tableau. Oracle est en douzième position avec 154 patchs et Canonical en vingt-deuxième position avec 101 patchs. Pour les curieux [la liste complète des entreprises](http://www.remword.com/kps_result/2_6_38_whole.html) est disponible sur le site remword. On y trouve même, en cherchant bien en bas de la liste, des noms assez inattendus comme General Electric et Volkswagen ou encore des amis sincères du libre comme Apple et Sony. Un chiffre toujours intéressant à regarder est celui des primo-contributeurs. Il s'agit des personnes postant un patch pour la toute première fois lors d'un cycle donné et ce depuis le 2.6.12-RC2 (date de l'import initial dans Git en avril 2005). Ces primo-contributeurs sont importants puisqu'ils représentent un apport de sang neuf dans l'écosystème du développement Linux. Bien entendu tous ne continueront pas à proposer des patchs mais certains d'entre eux deviendront sans doute des contributeurs réguliers du noyau. Voici le tableau des primo-contributeurs sur les 10 derniers cycles: Noyau 2.6.29 : [279 primo-contributeurs](http://www.remword.com/kps_result/2_6_29_ftc.html) Noyau 2.6.30 : [256 primo-contributeurs](http://www.remword.com/kps_result/2_6_30_ftc.html) Noyau 2.6.31 : [275 primo-contributeurs](http://www.remword.com/kps_result/2_6_31_ftc.html) Noyau 2.6.32 : [292 primo-contributeurs](http://www.remword.com/kps_result/2_6_32_ftc.html) Noyau 2.6.33 : [276 primo-contributeurs](http://www.remword.com/kps_result/2_6_33_ftc.html) Noyau 2.6.34 : [248 primo-contributeurs](http://www.remword.com/kps_result/2_6_34_ftc.html) Noyau 2.6.35 : [300 primo-contributeurs](http://www.remword.com/kps_result/2_6_35_ftc.html) Noyau 2.6.36 : [269 primo-contributeurs](http://www.remword.com/kps_result/2_6_36_ftc.html) Noyau 2.6.37 : [319 primo-contributeurs](http://www.remword.com/kps_result/2_6_37_ftc.html) Noyau 2.6.38 : [289 primo-contributeurs](http://www.remword.com/kps_result/2_6_38_ftc.html) Comme avec le nombre de patchs on voit que le cycle du 2.6.37 a été un peu exceptionnel avec pas moins de 319 primo-contributeurs. Le noyau 2.6.38 revient à des chiffres plus classiques mais toujours élévés. Très rares, pour ne pas dire inexistants, sont les projets libres qui voient arriver des patchs écrits par plus de 250 nouveaux venus tous les trois mois !

AltStyle によって変換されたページ (->オリジナル) /