URL: https://linuxfr.org/news/sortie-du-noyau-linux-2639 Title: Sortie du noyau Linux 2.6.39 Authors: patrick_g Date: 2011年04月30日T07:07:09+02:00 License: CC By-SA Tags: kernel, linux, noyau_linux, coulisses, linus_torvalds, alan_cox et selinux Score: 118 La sortie de la version stable 2.6.39 du noyau Linux [vient d’être annoncée](https://lkml.org/lkml/2011/5/19/16) par Linus Torvalds. 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. PS : merci aux contributeurs qui ont participé à la rédaction collaborative de la dépêche en aidant à traduire les annonces de RC de Linus. ---- [Les nouveautés du noyau 2.6.39](http://www.h-online.com/open/features/What-s-new-in-Linux-2-6-39-1242910.html?view=print) [LWN : Le bilan des ajouts partie 1](https://lwn.net/Articles/433854/) [LWN : Le bilan des ajouts partie 2](https://lwn.net/Articles/434637/) [LWN : Le bilan des ajouts partie 3](https://lwn.net/Articles/435716/) ---- #La phase de test ## RC-1 La version [RC-1](http://marc.info/?l=linux-kernel&m=130143288811886&w=2) a été annoncée par Linus le 29 mars : _« Le 2.6.39-rc1 est dispo et la période d’intégration est terminée. J’ai encore à regarder le patch cleancache (je l’ai reçu largement dans les temps, mais j’ai décidé que j’allais le passer en revue une fois que la folie de la période merge serait terminée) mais à part ça tout est OK._ _Que dire à propos de cette phase d’intégration ? À première vue, on pourrait dire qu’il n’y en a que pour les pilotes, les systèmes de fichiers et le nettoyage des interruptions. Le diff confirme ce sentiment sur les pilotes (65 % des patches), mais il montre qu’il y a largement plus de mises à jour sur les architectures que sur les systèmes de fichiers (le gros du boulot est sur ARM ; il y a quelques modifications des interruptions, mais la majorité des patches ARM se font sur les diverses cartes)._ _Toujours à propos des architectures, nous avons le début de l’unification de `m68k` avec `m68knommu`, ce qui est sympa ; nous verrons bien ce que ça va donner sur le long terme. Oh, et il y a aussi la nouvelle architecture `unicore32`._ _Peut‐être un peu plus intéressant pour la majorité des gens de la communauté du noyau, est le nouveau modèle de branchement des périphériques en mode bloc. Ce branchement se fait maintenant par processus léger (thread), ce qui a permis de nettoyer considérablement le code. Cela permet aussi d’éviter pas mal de verrouillages sur le chemin critique, et ça devrait donc généralement être une bonne idée._ _Rien d’autre ? Je suis sûr d’avoir oublié quelque chose de vraiment excitant. Mais en gros, je pense que ce devrait être une de ces versions "solides et sans surprises"._ _Je touche du bois. J’aime quand c’est ennuyeux._ » ## RC-2 La version [RC-2](http://marc.info/?l=linux-kernel&m=130205524912683&w=2) a été annoncée le 6 avril, et Linus s’est félicité de l’absence de gros problèmes : _« Ça a été une -rc2 étrangement calme, ce qui devrait me rendre vraiment heureux, mais très honnêtement, ça me rend juste carrément méfiant. Vous me préparez un sale coup les gars, c’est ça ?_ _Bref, 35 % archi (ARM et gestion de l’énergie, quelques nettoyages sur unicore32), 35 % sur les pilotes (réseau, les entrées et quelques DRM), et 30 % divers (mises à jour de documentation, perf, réseau, btrfs)._ _Au final, pas tant de problèmes que ça. Ce qui, je l’espère sincèrement, est un signe que le 2.6.39 va être une version simple._ _Touchons du bois. Allez‐y, testez ! »_ ## RC-3 La version [RC-3](http://marc.info/?l=linux-kernel&m=130256884826679&w=2) est sortie le 12 avril : _« Encore une semaine d’un calme presque effrayant. D’habitude ce genre de tranquillité n’arrive que bien plus tard dans le cycle (vers la RC-7 ou la RC-8), mais bon, je ne vais pas me plaindre. Je suis juste en train d’attendre la mauvaise nouvelle._ _Et puis, il est possible que ce cycle reste tranquille jusqu’au bout. Nous n’avons certainement pas eu les changements révolutionnaires du cycle précédent, comme la résolution de chemin. Donc, je suis relativement confiant sur le fait que tout va bien se passer._ _Bref, non seulement ça a été calme, mais c’est aussi parfaitement dans la norme. Deux tiers des changements sont dans les pilotes et le reste est globalement réparti un peu partout. Espérons que le cycle continue comme ça. J’aime quand les gens semblent vraiment appliquer la règle des "gros changements uniquement pendant la fenêtre de merge"._ _Merci les gars. »_ ## RC-4 Bien entendu, ce calme idyllique était trop beau pour durer, et Linus, dans son e‐mail d’annonce de la version [RC-4](http://marc.info/?l=linux-kernel&m=130318911602029&w=2) du 19 avril, a expliqué les problèmes qui étaient apparus : _« Hélas, les choses n’ont pas continué à se stabiliser davantage. Nous avons eu plus de commits dans la RC-4 que dans la RC-3 et j’espère sincèrement que cette tendance à la hausse ne va pas continuer._ _Ceci dit, jusqu’à présent, le seul truc qui a vraiment causé des problèmes dans ce cycle, c’est le changement dans la couche de branchement des périphériques en mode bloc. Dans cette RC-4, les soucis que nous avons eus avec MD devraient être derrière nous. Donc, nous progressons dans ce domaine._ _Le code de branchement semble provoquer un bogue qui se manifeste pour les CD-ROM par un flux infini de notifications de changements sur le disque. Nous espérons que Jens va résoudre le problème bientôt. Dans l’intervalle, vous pouvez éviter le problème en étant en mode SMP ou en activant la préemption._ _Quoi d’autre ? Certes, on a eu un peu plus de commits que dans la RC-3, mais rien de vraiment dramatique. À part les corrections sur les blocs et MD, nous avons eu les mises à jour des systèmes de fichiers (Btrfs, CIFS et Ubifs) et des pilotes (la plus grosse partie étant la suppression de duplicata). De l’USB, un peu de KMS, rien de révolutionnaire. »_ ## RC-5 La version [RC-5](http://marc.info/?l=linux-kernel&m=130387868124845&w=2) du 27 avril a été l’occasion pour Linus de faire part des ses hésitations lorsqu’il s’agit d’accepter des patches importants : _« Nouvelle semaine, nouveau clavier détruit en reversant du café dessus... C’est la vie._ _Nous avons moins de changements que pour la RC-4, ce qui est bien. D’un autre côté, je dois réprimander quelques personnes pour avoir intégré des corrections de régressions assez invasives. Malheureusement, ces "personnes" que je dois engueuler, c’est essentiellement moi. La RC-5 contient ce qui est techniquement une régression, mais qui améliore aussi les performances. C’est donc un peu effrayant d’intégrer ça._ _Il s’agit des correctifs d’Andi (avec quelques changements par Eric) qui permettent la résolution de chemin par RCU même si SELinux est activé._ _Je me suis successivement botté les fesses pour l’avoir accepté et m’être réjoui que la résolution de chemin RCU fonctionne aussi en dehors des domaines non sécurisés... Je ne sais pas ce qui est le mieux._ _Les corrections sont toutes assez simples (il y a aussi un peu de nettoyage concernant les dentries que j’ai effectué après avoir analysé le profilage et le code généré), et elles améliorent vraiment les performances de façon importante. En même temps, j’aurais hurlé si quelqu’un d’autre avait tenté de me faire intégrer ce truc si tard. Donc, je vais me considérer comme dûment réprimandé._ _À part ça ? Nous devrions avoir corrigé tous les problèmes de branchement dans la couche bloc maintenant, et Tejun a corrigé le truc de notification infinie pour les CD-ROM. Donc, avec un peu de chance, c’est tout bon, et on n’en parle plus._ _Et puis, il y a tout le bruit de fond habituel dans les pilotes, quelques mises à jour de ecryptfs et ext2, et juste quelques petites corrections ici et là. Le diffstat a une bonne gueule, et il y a surtout des correctifs d’une ligne et des trucs comme de nouveaux identifiants de périphériques, etc.._ _Allez‐y, testez. »_ ## RC-6 La version [RC-6](http://marc.info/?l=linux-kernel&m=130447888603366&w=2) du 4 mai a marqué le retour au calme et la stabilisation grandissante du noyau : _« La plupart des correctifs intégrés sont des trucs que l’utilisateur normal ne remarquera jamais vraiment (comme la série des patches sur les kprobes d’ARM) et le reste ce sont les habituels correctifs mono‐lignes sur les pilotes._ _Mais nous avons quand même eu un bogue vraiment intéressant. Cela apparaissait comme une erreur RCU en mode mono‐processeur ; erreur qui s’est avérée être un problème lié à l’ordonnanceur, ce problème lui‐même étant en fait un souci d’initialisation de timer. C’était intéressant et plutôt obscur._ _Mais la plupart des changements sont juste des petits correctifs un peu partout. Quelques mises à jour de média, un peu de travail sur NFS, quelques corrections sur DRM, la documentation, etc.. Vraiment des petites corrections, et les bogues ont été véritablement obscurs dans l’ensemble. On est encore en train de chercher à résoudre quelques problèmes, mais je pense qu’on est bon pour cette RC-6. Ce ne sera pas la RC finale, mais elle ne semble pas être en mauvaise condition. Les gens qui ont envoyé des rapports de régression sont priés de vérifier à nouveau, et les gens qui n’ont pas envoyé de rapports sont priés de tester aussi. »_ ## RC-7 Enfin, la [septième et dernière RC](http://marc.info/?l=linux-kernel&m=130499582929922&w=2) a été annoncée par Linus le 10 mai : _« Bon, les choses ont été plutôt calmes, et à moins qu’un problème majeur surgisse, je pense que ceci sera la dernière RC._ _Il y a seulement une petite centaine de changements cette fois‐ci, et le gros des changements est dans "fs/hpfs", qui est marqué BROKEN depuis le début de la fenêtre de merge, à cause du retrait définitif du [verrou global](http://fr.wikipedia.org/wiki/Verrou_global_du_noyau). Donc, c’est la correction d’une régression. Ceci dit, je confesse avoir songé à simplement laisser HPFS cassé pour cette version 39, et repousser cette série de correctifs pour la prochaine fenêtre de merge. Qu’importe. Autant l’appliquer maintenant, puisqu’elle n’a pas d’impact en dehors de HPFS et donc qu’elle ne pouvait pas aggraver les choses._ _En dehors de ces patches HPFS, il n’y a pas eu grand‐chose d’intéressant. Quelques problèmes sur les points de traçage ptrace, quelques mises à jour CIFS et tous les minuscules correctifs habituels, surtout dans les pilotes. Rien qui ne sorte du lot, tout a été très calme._ _Mais testez s’il vous plaît, juste pour s’assurer que le 39 final sera vraiment bon. »_ #Les nouveautés ##Threaded interrupts Le noyau 2.6.39 permet de [forcer les interruptions à tourner dans des threads noyau](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8d32a307e4faa8b123dc8a9cd56d1a7525f69ad3). Cette fonction est utile, entre autres, pour obtenir de meilleures données de débogage en cas de crash du gestionnaire des interruptions. Tout d’abord, un peu de contexte. Quand votre ordinateur a besoin d’une action urgente de la part du système, alors il génère [une interruption](http://fr.wikipedia.org/wiki/Interruption_%28informatique%29), ce qui, comme son nom l’indique, interrompt le processeur dans son travail courant. Cela peut se produire dans le cas d’une opération d’entrée‐sortie, de l’avancement d’une horloge, d’une commutation entre deux tâches, d’un défaut matériel, etc.. Ce système des interruptions est extrêmement intéressant, car cela permet au processeur de faire son travail normal d’exécution d’une tâche sans s’occuper de tout le reste. Si un évènement requiert son attention, alors il sera automatiquement prévenu par une interruption. Cela lui évite de devoir vérifier en permanence l’état des périphériques (s’il faisait ça, ce serait du _polling_, et c’est un comportement bloquant et consommateur de ressources). Quand l’interruption est émise, alors la tâche en cours d’exécution est automatiquement suspendue et la main passe au gestionnaire d’interruptions (_interrupt handler_). Ce gestionnaire s’occupe de la tâche qui a été demandée par le périphérique et, une fois le travail terminé, il redonne la main à la tâche qui était suspendue. Nous avons vu quels étaient les avantages du système des interruptions... mais il faut reconnaître que ce mode de fonctionnement n’est pas sans défauts. Le plus important est la latence que cela induit dans l’exécution d’une tâche donnée. Imaginez que vous lanciez une tâche d’encodage qui nécessite une minute de temps CPU. Si cette tâche peut se faire interrompre en permanence à des moments non prévisibles, et si ces satanées interruptions s’emparent de vos précieuses ressources processeur, alors vous ne pouvez plus prévoir le moment ou votre encodage sera terminé. De plus, les interruptions peuvent elle‐mêmes se faire interrompre par d’autres, ce qui rajoute encore de la latence. En temps normal, ce comportement ne pose pas de gros problèmes, mais dans le cas d’un besoin de [temps réel](http://fr.wikipedia.org/wiki/Syst%C3%A8me_temps_r%C3%A9el), il faut absolument trouver un palliatif. Un système temps réel cherche à être le plus déterministe possible, et ce système des interruptions qui ajoute des latences imprévisibles est intolérable. Depuis plusieurs années, une version du noyau Linux adapté au temps réel est développée dans une branche à part. Dans cette version « -RT », les interruptions sont [intégrées à des _threads_ du noyau](https://lwn.net/Articles/302043/). L’_interrupt handler_ va juste s’assurer de l’origine de l’interruption (opération nommée _« quick check handler »_) et va ensuite informer le noyau qu’il faut invoquer un _thread_ spécifique pour traiter cette opération (`IRQ_WAKE_THREAD`). L’interruption est donc minimale, puisqu’après la vérification de l’origine, on repasse tout de suite la main au noyau. Ce _thread_ noyau peut ainsi être géré comme n’importe quelle tâche par l’ordonnanceur, et le code est plus simple et contient moins de verrous qu’une interruption classique. À cette réduction des latences s’ajoute un bénéfice annexe, puisque le plantage du gestionnaire des interruptions dans un _thread_ ne provoquera qu’un [_oops_](http://en.wikipedia.org/wiki/Kernel_oops) au lieu d’aboutir à un crash total du système. Ce _oops_ est bien plus intéressant quand on veut déboguer, puisqu’il permet d’avoir des données précises sur l’origine du problème. Thomas Gleixner a donc pris le code de _threading_ des interruptions qui existait dans la branche -RT et il a [soumis plusieurs patches](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8d32a307e4faa8b123dc8a9cd56d1a7525f69ad3) pour la branche principale du noyau. Évidemment, pour ne pas s’exposer à l’ire de ses collègues, il s’est assuré que son mécanisme était paramétrable. Il indique également que ce code sert surtout à déboguer les problèmes en empêchant un crash total de la machine, et il ne met pas l’accent sur la réduction des latences et le meilleur déterminisme des temps d’exécution des processus. Pour activer cette fonction, il faut passer _« threadirqs »_ en paramètre au noyau au moment du démarrage (et que le noyau soit compilé avec `CONFIG_IRQ_FORCED_THREADING`). De plus, même si l’option est activée, il est toujours possible de forcer certaines interruptions à _ne pas_ tourner dans un _thread_. Pour cela, il suffit de les marquer avec `IRQF_NO_THREAD` et elles se comporteront comme avant. Comme il faut souvent choisir entre débit maximum et latences réduites, Thomas a indiqué que ce _threading_ forcé des interruptions avait un certain impact sur le débit brut. Il a effectué des tests sur une machine à base de Core 2 Duo en lançant la commande `« time git grep irq_desc »`. Le résultat obtenu est rassurant : - Avant (sans _thread_) : 1 min 18,741 s ; - Après (avec _thread_) : 1 min 19,061 s. On voit que l’impact, au moins dans ce cas de figure, est minimal. Comme le dit Thomas Gleixner dans son message de commit :> C’est une pénalité raisonnable pour permettre de résoudre des problèmes dans le code des interruptions, puisque ça permet de ne pas planter complètement en cas de bogue. En plus de cette nouveauté importante que constitue le _threading_ des interruptions, on peut noter que Thomas a [largement nettoyé](http://article.gmane.org/gmane.linux.kernel.cross-arch/9099) toute la couche générique des interruptions. Parmi ces nombreux patches, on peut noter [la petite gueulante](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=dbec07bac614a61e3392c1e7c08cc6a49ad43f7a) qu’il pousse contre les développeurs qui essayent de traficoter la structure `« irq_desc »`. Selon lui, les statuts présents dans cette structure sont des informations internes qui ne devraient pas être modifiées. Pour résoudre ce problème irritant, il a opté pour un nom particulièrement explicite :>Le nom `« core_internal_state__do_not_mess_with_it »` est suffisamment clair, suffisamment embêtant à taper, et il est facile à retrouver avec `grep`. Les contrevenants seront traqués et fouettés avec des truites puantes. ##IP sets Le _patch_ réseau [_IP sets_](http://ipset.netfilter.org/), qui existait depuis longtemps en dehors de la branche principale, a été [officiellement incorporé](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a7b4f989a629493bb4ec4a354def784d440b32c4) au noyau Linux 2.6.39. Quand il s’agit d’établir un [pare‐feu](http://fr.wikipedia.org/wiki/Pare-feu_%28informatique%29), les systèmes GNU/Linux utilisent normalement le couple Netfilter / Iptables. [Netfilter](http://fr.wikipedia.org/wiki/Netfilter) est une infrastructure générale de manipulation des paquets réseau, tandis qu’[Iptables](http://fr.wikipedia.org/wiki/Iptables) est une application qui permet de configurer Netfilter. La simplicité d’utilisation n’est pas la caractéristique principale du couple Netfilter / Iptables, et l’objectif d’_IP sets_ est de faciliter un peu la vie des administrateurs de pare‐feux. David Miller, le responsable de la couche réseau de Linux, a même qualifié le projet de _« totalement génial »_ dans son [message sur la LKML](http://thread.gmane.org/gmane.linux.kernel.wireless.general/66509). Pour paramétrer _IP sets_, on définit des « ensembles » (des _sets_) qui peuvent regrouper des données très diverses, comme par exemple des adresses IP, des numéros de ports, des adresses MAC, etc.. Au moment de la création du _set_, on spécifie son type selon les besoins. Par exemple, **ipmap** pour des plages d’adresses IP, **iphash** pour des tables de hachage d’adresses IP, ou encore **nethash** pour des tables de hachage de taille d’adresse réseau, etc.. La [liste des types disponibles](http://ipset.netfilter.org/features.html) est présente sur le site du projet, et on voit qu’un large choix est mis à la disposition des utilisateurs. Cette définition précise des types est extrêmement utile, puisqu’elle permet d’utiliser des algorithmes de stockage des structures de données en mémoire qui sont spécialement optimisés pour chacun des types de fichiers. Ces _sets_ sont gardés en mémoire vive et ils sont administrés grâce à l’outil en ligne de commande `« ipset »`. On positionne ensuite une règle iptables _unique_ qui fait référence à ce _set_, et hop, c’est fini ! Si on est vraiment ~~vicieux~~ astucieux, on peut aussi assembler des _sets_ en positionnant des références qui s’enchaînent les unes les autres. [La page du manuel](http://ipset.netfilter.org/ipset.man.html) est très bien faite et explique parfaitement la syntaxe à utiliser pour créer ces _sets_ de types variés. Les avantages de ce système sont nombreux : par exemple, quand on veut changer les adresses IP ou les ports filtrés par le pare‐feu, on n’a pas besoin de toucher à la règle Iptables, puisque tout se fait dans le _set_. La modification est donc dynamique. On peut aussi citer un gros avantage en termes de performances, puisqu’une liste de plusieurs milliers d’adresses IP sera représentée par une seule ligne _ipset_ et que tout est gardé en mémoire vive. Le passage en revue des règles par le noyau (_matching_) sera donc extrêmement rapide. Bien entendu, la contrepartie est une occupation mémoire plus grande qu’avec des règles classiques. Comme le _patch_ _IP sets_ existe depuis déjà un certain temps, on le trouve intégré dans plusieurs distributions spécialisées dans les fonctions de pare‐feux. Il était également possible de « patcher » son noyau et d’installer le [paquet d’administration _ipset_](http://packages.debian.org/squeeze/ipset) pour l’utiliser dans une distribution généraliste. L’inclusion d’_IP sets_ dans la branche principale du noyau Linux, via l’option `IP_SET` lors de la compilation, va donc faciliter son utilisation et accroître son audience auprès des administrateurs réseau ayant besoin de contrôler facilement les règles de filtrage de leurs pare‐feux. ##Media-controller Le sous‐système « [_media controller_](https://lwn.net/Articles/415714/) », qui constitue un complément de l’[API](http://fr.wikipedia.org/wiki/Interface_de_programmation) classique [Video4Linux](http://fr.wikipedia.org/wiki/V4L), a été ajouté dans le noyau 2.6.39. Écrit par Laurent Pinchart, ce nouveau sous‐système ambitionne de simplifier le travail des applications qui utilisent les périphériques audio ou vidéo de la machine. En effet, il a été constaté ces dernières années que les puces devenaient de plus en plus complexes et qu’elles intégraient de plus en plus de fonctions. Ce sont maintenant de véritables SoC ([Systems-on-a-Chip](http://fr.wikipedia.org/wiki/System_on_Chip)) qui sont embarqués dans les _webcams_ ou dans les cartes d’acquisition et de sortie vidéo. L’API spécialisée Video4Linux (V4L) a déjà été réécrite au moment de la série des noyaux 2.5.x, afin de permettre de gérer — entre autres — la compression matérielle. Cette interface de programmation de seconde génération (V4L2) a fidèlement servi les auteurs de pilotes, mais elle commence — elle aussi — à montrer ses limites. [L’article de LWN](https://lwn.net/Articles/415714/) dédié au sous‐système _« media controller »_ cite l’exemple de la puce [OMAP 3430](http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?contentId=14649&navigationId=12643&templateId=6123) qui est utilisée dans les téléphones Nokia N900. Cette puce est en effet représentative de la complexité ahurissante qui caractérise les périphériques vidéo modernes. Outre le classique processeur ARM et les blocs spécialisés dans le codage / décodage matériel de divers formats, on y trouve également un ISP (_image signal processor_) très sophistiqué. Divers formats vidéo sont acceptés en entrée, et la compression JPEG, ainsi que la balance des blancs, se font à la volée directement dans la puce. Pour pallier les défauts des lentilles, qui sont souvent minuscules, un processeur spécialisé corrige les distorsions géométriques de l’image, etc.. Chacun de ces composants spécialisés constitue pour le noyau un périphérique qui doit être géré spécifiquement. De plus, la gestion de ces périphériques doit souvent être partagée avec d’autres sous‐systèmes (pensons à ALSA pour le son d’une _webcam_, par exemple) ce qui ajoute de la complexité. Toutes ces fonctions présentes sur les SoC devraient pouvoir être facilement accessibles par les applications résidant en espace utilisateur. Pour cela, le noyau doit être capable de présenter simplement les caractéristiques de tous les périphériques média... Mais cette contrainte devient de plus en plus difficile à tenir par l’API V4L2 qui n’a pas vraiment été conçue pour ça. Le sous‐système _« media controller »_ va donc permettre aux applications en espace utilisateur de découvrir et de contrôler les divers périphériques spécialisés présents sur la machine. Pour cela, ces périphériques sont représentés dans un [graphe orienté](http://fr.wikipedia.org/wiki/Graphe_orient%C3%A9) de tous les blocs média (nommés _« entities »_) et qui sont connectés par des relations (nommées _« pads »_). La nouvelle structure `« media_device »` accueille les diverses descriptions des _« entities »_ qui peuvent prendre la forme de périphériques audio, de processeurs de mise au point pour les images, de blocs vidéo, de capteurs [CCD](http://fr.wikipedia.org/wiki/Charge-Coupled_Device#Les_capteurs_CCD) ou [CMOS](http://fr.wikipedia.org/wiki/Charge-Coupled_Device#Les_capteurs_CMOS), de blocs [DMA](http://fr.wikipedia.org/wiki/Acc%C3%A8s_direct_%C3%A0_la_m%C3%A9moire), etc.. Ces _« entities »_ vont être connectées entre elles par des relations _« pads »_, et le flot de données transite simplement depuis un _pad_ de type « source » vers un _pad_ de type _« sink »_. On voit bien que cette architecture générale fait penser aux _pipelines_ de [[GStreamer]] qui utilisent, eux aussi, [ces notions de sources, _pads_ et _sink_](http://www.cin.ufpe.br/~cinlug/wiki/index.php/Introducing_GStreamer#Pads). La phase de découverte et de caractérisation de la topologie des périphériques se fait dynamiquement à chaud, et il est possible d’assigner un numéro de groupe à certaines des entités afin d’indiquer qu’elles fonctionnent ensemble. Par exemple, on peut indiquer que le capteur CMOS, la puce intégrée de correction d’image, ainsi que le microphone, qui sont tous les trois présents dans une _webcam_ font partie d’un même groupe. Laurent Pinchart a indiqué dans [ses e‐mails sur la LKML](http://article.gmane.org/gmane.linux.alsa.devel/81497) que les versions successives de ses _patches_ avaient été scrutées de près par les divers responsables du noyau :>Le code a été passé en revue en profondeur par la communauté V4L. Cette nouvelle version est la première à incorporer des commentaires issus de la communauté ALSA. Il n’y a pas de concurrence, puisque _« media controller »_ est complémentaire d’ALSA et de V4L2, et n’a pas du tout l’ambition de les remplacer. Pour l’instant — comme souvent avec l’introduction d’une nouvelle API — l’option de configuration `« MEDIA_CONTROLLER »` est encore [marquée comme expérimentale](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cf4b9211b5680cd9ca004232e517fb7ec5bf5316). La documentation détaillée est au format [[Docbook]] et se trouve dans `« documentation/DocBook/v4l/media-controller.xml »`. On trouve quand même une brève présentation dans [`« media-framework.txt »`](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/media-framework.txt;h=1844c3f10728c4c128cbdf00dcc99ee61f6352af;hb=176fb0d108f7495ccf9aa127e1342a1a0d87e004). Du côté des applications, il est bien sûr possible d’interroger finement le sous‐système _« media controller »_ pour se renseigner sur les capacités matérielles de la machine. Cela se fait via des appels [_ioctl_](http://en.wikipedia.org/wiki/Ioctl) aux noms explicites comme `« MEDIA_IOC_DEVICE_INFO »` ou `« MEDIA_IOC_ENUM_ENTITIES »` ou encore `« MEDIA_IOC_ENUM_LINKS »`. Les applications peuvent changer les liens entre les _« entities »_, via un appel à `« MEDIA_IOC_SETUP_LINK »`. Le premier pilote à utiliser ce sous‐système _« media controller »_ est l’ISP OMAP3, mais il ne fait aucun doute que de nombreux pilotes vont bientôt utiliser cette nouvelle infrastructure moderne présente dans le noyau Linux. ##Block device plugging La grosse nouveauté du noyau 2.6.39, c’est l’intégration du _patch_ « [_block device plugging_](https://lwn.net/Articles/438256/) » écrit par Jens Axboe, qui change considérablement le mode d’écriture des entrées‐sorties en mode bloc du noyau. Auparavant, à l’ère des dinosaures, tout était relativement simple dans le mode d’envoi des blocs de données vers les périphériques. Quand un processus avait des opérations d’entrées‐sorties à effectuer, le noyau mettait le périphérique cible dans un état dit « branché » (_plugged_). Ainsi, au lieu d’envoyer directement les données vers le pilote du périphérique pour lancer l’écriture, on peut accumuler les requêtes dans le « tuyau de branchement » (_plugged queue_). Quand le processus se met à attendre que les données soient écrites, alors il est temps de « débrancher » le périphérique (_device unplug_) et d’écrire effectivement les données. Cette méthode permet de fusionner des opérations d’écritures en une seule commande globale et elle améliore donc les performances. Malheureusement, ce code antédiluvien ne tenait aucun compte des machines multiprocesseurs, et l’opération de branchement impliquait un gros verrou qui limitait la montée en charge. En outre, le débranchement était lui aussi global (via la fonction `« blk_run_queues »`) ce qui provoquait un _« unplug »_ sur tous les périphériques, alors qu’il aurait été préférable de ne débrancher que le périphérique concerné. Ces limitations ont conduit Jens Axboe (déjà lui !) à modifier le code du noyau [en mars 2004](https://lwn.net/Articles/75233/). Avec les _patches_ de Jens, le débranchement pouvait se faire pour un périphérique spécifique (_per‐device unplug_) grâce à la fonction `« blk_run_queue »` (notez le « s » qui a disparu par rapport au nom de la précédente fonction). Ce changement a nécessité un _hack_ assez vilain dans le sous‐système de la mémoire virtuelle, mais la montée en charge en a été facilitée et les performances ont fait un bond important. Sept ans après ce travail, Jens Axboe s’est penché une nouvelle fois sur le code des entrées‐sorties du noyau en mode bloc. Il s’est rendu compte qu’en 2011, les compromis nécessaires ne sont plus les mêmes que ceux qui étaient pertinents en 2004. Par exemple, toute cette fonction de _« plugging »_ des périphériques est désactivée pour les disques SSD qui ont une fonction intégrée de mise en queue. Les périphériques rapides, qui sont de plus en plus répandus, imposent donc de réécrire le code de _« plugging »_. Jens a décidé de revoir complètement la logique présente dans le noyau Linux, et c’est ce travail qui arrive maintenant dans la version 2.6.39 du noyau. Le but que poursuit Jens est — comme toujours — de pouvoir faciliter la montée en charge (_scalability_) et d’augmenter les performances générales. Quels sont les problèmes du mécanisme actuel ? D’abord, il faudrait que le périphérique lui‐même ne soit plus bloqué par le _plugging_. En effet, un verrou est tenu sur la queue d’accumulation des données du périphérique, et ce verrou limite la montée en charge. Un autre problème est la nature asymétrique du mécanisme qui existait jusqu’à présent. On avait un branchement qui se faisait de façon implicite dès que des entrées‐sorties étaient soumises, mais le débranchement devait se faire de façon explicite via l’appel à la fonction `« blk_run_queue »`. La solution retenue est de ne plus accumuler les opérations d’entrée‐sorties dans un tampon vivant dans le contexte du périphérique (_shared state in the device_). Au lieu de ça, une structure est créée directement dans la [pile](http://fr.wikipedia.org/wiki/Pile_%28informatique%29) du processus qui soumet les données et cette structure, nommée `« struct blk_plug »`, va accueillir le tampon d’accumulation des entrées‐sorties. En résumé, maintenant, on ne branche plus un périphérique en particulier. On branche directement les processus qui veulent envoyer des données. Cette opération de branchement se fait explicitement avec la commande `« blk_start_plug »` et le débranchement s’effectue via `« blk_finish_plug »`. [Ce nouveau mode opératoire](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=73c101011926c5832e6e141682180c4debe2cf45) permet de corriger les deux défauts du précédent mécanisme qui ont été évoqués plus haut. Le plus important c'est qu'on n'accumule plus les données en tenant un verrou sur la queue de branchement du périphérique. Ainsi le chemin critique (_hot path_) est moins contraint par des verrouillages incessants et la montée en charge est bien plus facile. Les opérations de branchement et de débranchement sont maintenant complètement symétriques, ce qui réduit une source potentielle de bugs. Avant, il fallait utiliser des heuristiques pour débrancher quand un processus se mettait à attendre la complétion de ses opérations I/O. Maintenant, plus besoin d'heuristiques puisque le débranchement se fait explicitement avec un `blk_finish_plug` quand le thread qui soumettait des requêtes I/O à fini de les envoyer. Pour que la joie soit complète, la suppression de cette fonction de branchement implicite a permis de [retirer de nombreuses lignes](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7eaceaccab5f40bbfda044629a6298616aeaed50) de codes qui étaient devenues inutiles. Le changelog [a été qualifié par Jens](http://article.gmane.org/gmane.linux.kernel/1117424) de _tasty_ (succulent) car le nombre total de lignes est réduit dans le noyau (1520 lignes insérées et 2112 lignes supprimées). En outre, et pour que la joie soit _vraiment_ ultime, le hack assez moche qui avait été introduit en 2004 dans la fonction `sync_page` n'est plus nécessaire et il a été retiré (pour le plus grand soulagement des responsables du sous-système de la mémoire virtuelle). Linus ne s'y est pas trompé et ce nouveau mode d'écriture des entrées/sorties en mode bloc du noyau est le seul changement qui a droit à un paragraphe complet dans son mail d'annonce de la RC-1 :>Le nouveau modèle de branchement des périphérique en mode bloc se fait maintenant par thread et a permis de nettoyer considérablement le code. Cela permet aussi d'éviter pas mal de verrouillages sur le chemin critique et ça devrait donc généralement être une bonne idée. Bien entendu il y a eu des petits problèmes au début lors de l'inclusion et Linus a aussi évoqué ces _légers_ désagréments :>Ceci dit, le nouveau mécanisme s'est mis à manger les systèmes de fichiers XFS pour son petit-déjeuner, mais c'est corrigé et on espère que tout devrait être bon maintenant. Les dernières corrections ont été intégrées au moment de la RC-4 ce qui démontre quand même qu'il n'y a pas assez de gens qui testent les noyaux de développement (la branche -next par exemple) et qu'il faut attendre la fin de la période de merge pour que les utilisateurs se mettent soudain à couiner en cas de bugs. Quoi qu'il en soit ce nouveau mécanisme semble bien plus efficace que son prédécesseur et il constitue donc une avancée marquante du nouveau noyau. #En bref ###Transcendent memory Les patchs de « [Transcendent memory](https://lwn.net/Articles/340080/) » écrits par Dan Magenheimer sont entrés dans la branche -staging du noyau 2.6.39. L'idée derrière ce patch `Tmem` consiste à doter le noyau d'un moyen différent de gérer la mémoire du système. Ce code alternatif offre un réservoir de pages mémoire créé par la fonction `tmem_new_pool()` et l'idée ressemble un peu à celle de [memcached](http://fr.wikipedia.org/wiki/Memcached) puisqu'on va se servir de ce réservoir de mémoire pour éviter de coûteuses opérations d'entrées/sorties sur le disque. Selon Dan, cette technique et le mode de gestion particulier de cette mémoire sont notamment utiles dans le cas d'un système virtualisé. Aux côtés de ce patch de « Transcendent memory », on note également le mécanisme de compression du cache des pages mémoire « [zcache](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=daa6afa6d920a389015bb8f1ea519cef0636f528) » qui entre lui aussi dans -staging. Ce code utilise le mécanisme `Tmem` mais n'est pas encore fonctionnel puisqu'il nécessite une autre pièce du puzzle (le patch « cleancache ») que Linus a refusé lors de la période de merge. ###User namespaces Développé par Eric Biederman et Serge Hallyn, [le patch de « user namespace »](https://lkml.org/lkml/2010/12/17/181) est une extension du méchanisme des « [capabilities](http://en.wikipedia.org/wiki/Capability-based_security) » du noyau. Classiquement les capabilities sont utilisées pour donner à un processus des droits ayant une granularité plus fine que le classique, et fort dangereux, flag `setuid()`. Ici l'idée est de créer une sorte de conteneur où tous les processus auront l'illusion de tourner sur le système racine alors qu'en réalité, ils seront confinés dans leur espace de nommage (_namespace_) où chacun des conteneurs aura son ensemble d'[UIDs](http://fr.wikipedia.org/wiki/User_identifier). Jusque là, rien que de très classique...mais le but est de permettre à des utilisateurs normaux (non root) de créer ces conteneurs. Pour cela il faut contrôler de façon plus fine les capabilities des processus. Ainsi, un user non privilégié du système pourra utiliser l'appel `ns_capable()` pour gérer les capacités. Si ce user utilise cet appel système il ne pourra que positionner une capacité sur un processus dans son espace de nommage ou dans un espace de nommage qui descend du sien. Il lui sera interdit de « remonter » dans la hiérarchie des espaces de nommages. Le patch qui entre dans le noyau 2.6.39 n'est que le début d'un travail à long terme puisque le code a été conçu pour élargir progressivement les capabilities qui seront autorisées dans ces « user namespace » spéciaux. Pour l'instant, seuls trois appels système sont autorisés : `sethostname()` (si le user à la capacité `CAP_SYSADMIN`), l'appel `check_kill_permission()` (si le user à la capacité `CAP_KILL`) et enfin `ptrace()` (si `CAP_SYS_PTRACE` est positionné). [Une page du wiki Ubuntu](https://wiki.ubuntu.com/UserNamespace) coordonne l'avancement des travaux et, comme l'explique fort bien [cet article LWN](https://lwn.net/Articles/420624/), l'approche incrémentale a été choisie afin de pouvoir relire et tester plus longuement les fonctions de « user namespace » puisqu'il s'agit d'une fonction sensible concernant la sécurité. ###Système de fichiers pstore Le [système de fichiers spécialisé pstore](https://lwn.net/Articles/434821/), destiné à recueillir les derniers mots d'un système à l'agonie, a été intégré au noyau 2.6.39. L'idée derrière _pstore_ est simple. Quand le système se vautre, il est fort utile de connaître la raison du crash afin de pouvoir corriger le problème. Le moyen classique c'est de loguer les derniers messages du système sur le disque pour pouvoir les lire plus tard. L'ennui de ce schéma, c'est que le crash peut avoir empêché l'écriture des logs sur le disque ou bien tout simplement corrompu les données. Ce serait bien d'avoir une solution alternative qui n'utiliserait pas le disque et - bien entendu - cette option de la dernière chance ne devrait pas être spécifique à une architecture, mais plutôt conçue comme étant la plus générique possible. Il y a eu plusieurs faux départs puisqu'à l'origine, le code se basait uniquement sur la table ERST (_Error Record Serialization Table_) de la norme ACPI et l'interaction était réalisée via le système de fichiers virtuel [sysfs](http://fr.wikipedia.org/wiki/Sysfs). Après une [suggestion d'Alan Cox](http://article.gmane.org/gmane.linux.kernel.cross-arch/8280), il a été décidé de sauter le pas et de convertir pstore en un vrai système de fichiers. Par défaut, quand un Oops ou un panic se produit, les dix derniers kilo-octets de logs sont passés, à l'aide de `kmsg_dump`, au pilote pstore. [Avec cette solution en place](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/ABI/testing/pstore;h=f1fb2a004264bc6989a20d92ca333b436c7154d4;hb=ca01d6dd2d7a2652000307520777538740efc286), toutes les plates-formes qui disposent d'une petite quantité de mémoire non volatile pourront sauver les derniers messages du noyau. Après un reboot, il suffira de lancer `mount -t pstore - /dev/pstore` pour aller ensuite lire la sauvegarde de données. David Miller, le mainteneur de l'architecture Sparc64, [a déjà indiqué](http://article.gmane.org/gmane.linux.kernel.cross-arch/8275/) qu'il allait utiliser ce mécanisme pour implémenter la fonction sur son architecture de prédilection. ###Open by handle La fonctionnalité « Open by handle » qui est décrite dans [cet article LWN](https://lwn.net/Articles/375888/), a été incluse dans le noyau. Un _file handle_ c'est, en gros, un identifiant numérique qui est attribué par le système lors de l'accès à un fichier. C'est une donnée purement interne qui normalement n'est pas accessible par les applications vivant en espace utilisateur. [Le commit de Aneesh Kumar](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=becfd1f37544798cbdfd788f32c827160fab98c1) change la situation puisqu'il ajoute deux nouveaux appels système, qui sont réservés à l'administrateur de la machine, et qui vont permettre à certaines applications d'utiliser directement le _handle_ d'un fichier au lieu de passer par son nom. On va ainsi appeler la fonction `name_to_handle_at()` pour établir une correspondance entre un nom et le _handle_ et la fonction `open_by_handle_at` pour ouvrir le fichier en utilisant le _handle_. Les noyaux compilés avec `CONFIG_FHANDLE` permettront donc d'utiliser cette possibilité qui est très utile dans le cas d'un serveur de fichier qui tournerait en espace utilisateur. Le serveur, une [version spéciale de NFS](http://sourceforge.net/apps/trac/nfs-ganesha/) par exemple, va pouvoir trouver le _handle_ d'un fichier et le passer directement au système de fichiers sous-jacent qui pourra s'en servir ultérieurement. ###Améliorations de LIO L'infrastructure [LIO](http://www.linux-iscsi.org/index.php/Main_Page) qui permet de faire du Target iSCSI et qui est [entrée lors du cycle précédent](https://linuxfr.org/news/le-noyau-linux-est-disponible-en-version-2638#toc_14), a été améliorée par deux patchs assez conséquents. C'est tout d'abord le module [tcm\_ Loop](http://linux-iscsi.org/wiki/Tcm_loop) qui a été [intégré](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3703b2c5d041a68095cdd22380c23ce27d449ad7) par Nicholas Bellinger. Ce module permet d'émuler un périphérique SCSI à partir d'un « _raw device_ » c'est-à-dire d'un périphérique en mode bloc qu'on va attaquer directement sans passer par le système des caches de l'OS. Le [second patch](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=12d233842987d9972957419e427987b94f7bd7b4) ajoute à LIO la possibilité d'utiliser le système de fichiers virtuel configFS pour récupérer des statistiques sur le fonctionnement de l'infrastructure de Target iSCSI. [Le message de commit](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=12d233842987d9972957419e427987b94f7bd7b4) explique bien toutes les données, complexes, qui sont maintenant disponibles. ###Device mapper Le device mapper est la couche logique qui permet par exemple de faire du RAID logiciel ou du chiffrement de disques entre divers périphériques en mode blocs. La fonction de « _striping_ » (c'est à dire l'aggrégation de disques en mode [RAID 0](http://fr.wikipedia.org/wiki/RAID_%28informatique%29#RAID_0_:_volume_agr.C3.A9g.C3.A9_par_bandes)) a été complétée par l'ajout des "[merge methods](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=29915202006c2e7bafe81348eb498ff9a724ac61)" qui augmentent significativement les performances. Alors qu'avant, on pouvait avoir des cas où une seule page était envoyée dans une opération d'entrées/sorties, maintenant, le patch du noyau 2.6.39 prend soin d'utiliser la fonction `stripe_merge` pour assembler dans tous les cas une plus grande quantité de bios (bloc i/o). [Le message de commit](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=29915202006c2e7bafe81348eb498ff9a724ac61) indique que ces "merge methods" autorisent des gains en débit de données qui peuvent aller de 12% à 35%. Toujours en ce qui concerne le "device mapper", on peut citer la nouvelle cible DM nommée "[Flakey target](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3407ef5262b55ca5d7139d2b555ef792fe531eec)". Cette cible permet de générer des erreurs d'entrées/sorties avec des intervalles paramétrables (_up interval_ et _down interval_). C'est très utile quand on veut tester intensivement des périphériques et le code de gestion d'erreur présent dans le noyau. ###Swap MTD Un pilote générique de swap pour les périphériques MTD ([Memory Technology Device](http://en.wikipedia.org/wiki/Memory_Technology_Device)) a été écrit par Jarkko Lavinen. La couche MTD s'interpose entre le pilote matériel bas niveau des périphériques utilisant de la mémoire flash et les couches plus hautes du noyau Linux. Ces partitions MTD sont assez souvent utilisées dans le monde de l'embarqué. Le nouveau pilote mtdswap permet maintenant, avec l'option de configuration `MTD_SWAP`, d'utiliser le périphérique MTD comme si c'était un périphérique classique en mode bloc utilisé pour le [swap](http://fr.wikipedia.org/wiki/M%C3%A9moire_virtuelle#Swapping) du système. Comme le support des données est constitué de mémoire flash, une fonction d'étalement des écritures ([wear levelling](http://fr.wikipedia.org/wiki/Wear_levelling)) est incorporée dans le pilote mtdswap. ###Systèmes de fichiers Dans le domaine des systèmes de fichiers présents dans ce nouveau noyau Linux, on notera l'activation par défaut dans ext4 de la fonction « _direct bio layer_ » qui était [décrite dans la news du 2.6.37](https://linuxfr.org/news/sortie-de-la-version-2637-du-noyau-linux#long1). Cette fonction augmente significativement les performances, mais elle avait été désactivée à la suite d'un bug de corruption de données. Le fix [ayant été écrit](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d50bdd5aa55) par Curt Wohlgemuth, et les tests démontrant que le mécanisme était devenu d'une robustesse à toute épreuve, Ted Ts'o a décidé [d'activer par défaut](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6fd7a46781999c32f423025767e43b349b967d57) la fonction. En ce qui concerne btrfs, outre [l'ajout de points de traçage](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1abe9b8a138c9988ba8f7bfded6453649a31541f) et l'utilisation de [la commande FITRIM](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f7039b1d5c32241f87a513e33120db36bf30264d) qui permet d'optimiser l'utilisation des disques SSD (voir [l'explication](https://linuxfr.org/news/sortie-de-la-version-2637-du-noyau-linux#long2)), on peut relever la nouvelle possibilité de compression par fichier ou par répertoire. Avant ce patch, on pouvait uniquement positionner une option lors du montage du système de fichiers pour lui indiquer d'activer, ou pas, les fonctions de compression et de COW ([Copy-On-Write](http://fr.wikipedia.org/wiki/Copy-On-Write)). Le [travail de Liu Bo](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=75e7cb7fe0c391561bd3af36515be3f3c64a04c6) permet maintenant d'utiliser le flag générique `FS_IOC_SETFLAGS` pour spécifier si on souhaite activer la compression ou le COW pour un fichier ou un répertoire particulier. Enfin, le code de désallocation des blocs du système de fichiers pour clusters [GFS2](http://fr.wikipedia.org/wiki/Global_File_System) a été amélioré par Bob Peterson de façon à ne plus mettre à jour le fichier des quotas et le fichier des statistiques à chaque désallocation. Bob a testé son optimisation en créant 200 fichiers de 100 Mo chacun sur quatre machines en cluster. La suppression simultanée de ces fichiers stresse GFS2 puisqu'il y a compétition entre les ressources. Avec l'ancien code le travail était terminé en 118,6 secondes alors qu'il ne faut plus que 89,4 secondes avec [le patch](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4c16c36ad62fff8485215bd803d778eb2bd0b8bd). ###Appel système syncfs L'appel système `sync()` permet d'ordonner au système de vider tous les caches sur le périphérique de stockage. Grâce à lui on peut s'assurer qu'une donnée a bien été écrite sur le disque et ainsi ne pas se tourmenter pour la cohérence des données. Tout ça est bien joli, mais un inconvénient de `sync()`, c'est qu'il oblige à synchroniser _tous_ les systèmes de fichiers qui sont montés sur le système. On ne peut pas en choisir un et ne synchroniser que celui-là...ou plutôt si on peut, mais en rusant et en étant obligé d'avoir des droits root (par exemple en faisant un 'mount -o remount,rw' sur un système de fichiers pour forcer un sync). C'est [pour corriger cette limitation](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b7ed78f56575074f29ec99d8984f347f6c99c914) que Sage Weil a créé l'appel `syncfs()` qui prend en paramètre le système de fichiers qu'on désire synchroniser et qui, tout comme `sync()`, est un appel non privilégié qui n'est pas réservé à root. ###Unicore32 Comme l'a annoncé Linus dans son mail sur la première version candidate, une nouvelle architecture fait son entrée dans la branche principale du noyau. C'est le « [Microprocessor Research and Development Center](http://mprc.pku.cn/eng/intro.html) » de l'Université de Pékin qui a conçu cette puce [Unicore32](http://en.wikipedia.org/wiki/Unicore). Il s'agit d'un processeur RISC avec un jeu d'instructions mixte 16/32 bits qui vise l'embarqué et qui a été [intégré dans divers SoC](http://www.pkunity.com/english%20version/engintrcpu.htm) en Chine. On le retrouve même dans des mini stations de travail fanless comme [celle-ci](http://www.pkunity.com/english%20version/engncsp.htm). On peut certes considérer que cette architecture est extrêmement exotique et que [son ajout dans le noyau Linux](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=790edb61c0d87d1f1daafcaaa8f7c66b7b82bdad) n'est qu'une anecdote sans importance. Ce serait une erreur puisque cela reflète en réalité la montée en puissance de la Chine et de ses technologies. Qu'il s'agisse d'Unicore32 ou de la puce MIPS/[Loongson](http://en.wikipedia.org/wiki/Loongson) qui sera au coeur des [futurs superordinateurs chinois](http://en.wikipedia.org/wiki/Dawning_Information_Industry#Dawning_6000), il est clair que Pékin a de grandes ambitions et que cette volonté d'indépendance passe par Linux. ###Perf Comme d'habitude l'outil de tracing `perf` a fait l'objet d'une multitude de patchs améliorant son fonctionnement ou ajoutant des fonctions. C'est un sous-système du noyau qui est en évolution très rapide depuis plusieurs versions et les développeurs s'en donnent à coeur joie. En vrac on peut citer [le support](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4979d2729af22f6ce8faa325fc60a85a2c2daa02) des futurs processeurs AMD [Bulldozer](http://fr.wikipedia.org/wiki/Bulldozer_%28microarchitecture%29), la commande `evlist` qui [liste tous les évènements](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=43adec955edd116c3e98c6e2f85fbd63281f5221) enregistrés dans un fichier perf.data, la possibilité de [filtrer la liste des évènements](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=668b8788f497b2386402daeca583d6300240d41d#patch1) par catégorie alors qu'avant la commande `perf list` n'admettait pas d'arguments ou encore [l'amélioration du support](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f4929bd37208540c2c6f416e9035ff1938f2dbc6) des compteurs matériels des puces Nehalem. L'avancée la plus notable est sans doute [le patch](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e5d1367f17ba6a6fed5fd8b74e4d5720923e0c25) permettant de ne monitorer qu'un cgroup particulier au lieu de devoir examiner tout le système. Ce nouveau filtrage par cgroup marche avec `perf stat` comme avec `perf record` avec la nouvelle option -G et on peut surveiller plusieurs groupes en parallèle en listant leurs noms séparés par une virgule. ###Pilotes graphiques Le noyau 2.6.39 [intègre pour la première fois](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0867b42113ec4eb8646eb361b15cbcfb741ddf5b) dans sa branche -staging un pilote `psb_gfx` dédié à la puce graphique GMA500 (plus connue sous le nom de [Poulsbo](http://en.wikipedia.org/wiki/Poulsbo_%28chipset%29#Poulsbo)). Le pilote est développé directement par Alan Cox et, même s'il ne dispose pas encore de la 3D accélérée et n'utilise pas les moteurs vidéos matériels de la puce, le code gère le framebuffer ainsi que la 2D. Comme [l'explique Kristoffer Ericson](http://thread.gmane.org/gmane.linux.kernel/1130687) le pilote est stable et, si vous n'avez pas besoin de l'accélération 3D, il constitue une alternative tout à fait réaliste à l'ignoble [blob](http://fr.wikipedia.org/wiki/Binary_large_object) d'Imagination Technologies. Du côté d'AMD peu de nouveautés à noter hormis les patchs de prise en charge [des puces HD 6900](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b7cfc9fe921ddd1a926803711df63e1ea52a7563) (Cayman) et d'activation du [tiling](http://en.wikipedia.org/wiki/Tiled_rendering) pour les puces R600 qui entrent dans le noyau. Le pilote Nouveau [offre maintenant la z-compression](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8f7286f8e4e80f7b868ba3d117ae900f0d207cbe) c'est-à-dire que les données sur la profondeur sont stockées en mode compressé dans un tampon mémoire spécifique (le z-buffer). Cela permet de savoir si il faut vraiment afficher le pixel ou si ce n'est pas nécessaire parce qu'il est masqué. La [technique du « page flipping » est également ajoutée](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d7117e0d4e21034202833088e51fc21f8c8271f9) au pilote Nouveau du noyau 2.6.39. Avec [cette technique](http://download.oracle.com/javase/tutorial/extra/fullscreen/doublebuf.html) on utilise deux tampons pour la vidéo, l'un qui est affiché sur l'écran (_front buffer_) tandis que l'autre se remplit (_back buffer_). Au moment opportun, on bascule d'un tampon à l'autre avec un pointeur ce qui évite de copier des données (qui a pensé aux [sprites](http://fr.wikipedia.org/wiki/Sprite_%28jeu_vid%C3%A9o%29) ?). Enfin [la correction d'un problème de performance](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=bd35fe5a7930bf83ed56422ea4e4b6471ee6f739) permet de gagner d'un seul coup entre 10 et 30% [d'images par seconde](http://en.wikipedia.org/wiki/Frame_rate) en plus par rapport aux noyaux précédents. Pour en terminer avec les pilotes graphiques, en ce qui concerne Intel, on relève [plusieurs](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ccab5c82759e2ace74b2e84f82d1e0eedd932571) patchs [améliorant](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e8b2c3c47a53348aebbbeb5322e32937df958793) la gestion de la puce graphique présente dans le processeur Sandy Bridge (20% de performances en plus dans [Nexuiz](http://fr.wikipedia.org/wiki/Nexuiz)). Le pilote i855 a également été complètement revu et nettoyé. ###Xen Les développeurs de l'hyperviseur [Xen](http://fr.wikipedia.org/wiki/Xen) continuent leur combat pour essayer de rejoindre la branche principale du noyau en tant que Dom0 (c'est à dire en mode d'accueil de systèmes invités). Cette fois c'est le pilote réseau générique netback qui [entre dans le noyau](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f942dc2552b8bfdee607be867b12a8971bb9cd85). Ce pilote permet aux systèmes invités, plus précisément à leurs périphériques réseau paravirtualisés, de communiquer entre eux. C'est une étape importante mais le noyau Linux n'est toujours pas prêt à jouer le rôle d'hôte en Dom0 puisqu'il manque encore des pilotes cruciaux. La situation n'est pas près de changer puisque les hackers du noyau semblent considérer que les développeurs de Xen ~~sont des gorets~~ produisent un code trop invasif. On peut citer l'exemple du pilote générique en mode bloc qui [a été proposé sur la LKML](http://article.gmane.org/gmane.linux.kernel/1129246) par Konrad Rzeszutek Wilk qui travaille chez Oracle. La réponse de Christoph Hellwig [a été immédiate](http://article.gmane.org/gmane.linux.kernel/1129351) : >Tout ça devrait être en espace utilisateur. Et la dernière fois que cela a été discuté Stefano a indiqué que le backend Xen disk de qemu était tout aussi rapide que ce code noyau. Et encore il n'est même pas très optimisé.>Donc de ma part c'est un clair NACK pour l'ajout de tout ce bordel dans le noyau. Même si Xen Dom0 semble bloqué la partie DomU continue d'avancer régulièrement. Dans cette nouvelle version 2.6.39 on retrouve également le support Xenbus pour les « [PM Events](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c7853aea57d8e850b0979e7bdcbcabdcbbdd9e37) ». Cela permet aux systèmes invités (_guests_) de recevoir les notifications du sous-système de gestion de l'énergie comme par exemple les mises en veille, en hibernation, etc. ###KVM Toujours dans le domaine de la virtualisation, [KVM](http://fr.wikipedia.org/wiki/Kernel-based_Virtual_Machine) a corrigé un [problème de performance](http://thread.gmane.org/gmane.linux.kernel/1076542) ennuyeux. Rik van Riel a constaté que les systèmes invités, et en particulier Windows, souffraient dans certains cas d'une lenteur rédhibitoire ( _gigantic slowdown_). Auparavant, quand un thread d'un système invité était bloqué par un [spinlock](http://en.wikipedia.org/wiki/Spinlock), le processeur prévenait KVM de ce blocage et le code de KVM était conçu pour faire avancer d'autres processus extérieurs au guest. Il a été constaté que cette stratégie était finalement loin d'être optimale et qu'il valait mieux donner du temps de processeur au thread tenant le verrou. Ce renforcement de la priorité du thread s'effectue avec un appel à `yield_to()` et cela permet de [renforcer les chances de déblocage](https://lwn.net/Articles/419961/) au profit de tout le système. Un second patch KVM qui vaut la peine d'être evoqué est celui qui s'intitule « [asynchronous page faults processing](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0857b9e95c1af8bfe84630ef6747b9d4d61de4c6) ». Le message de commit est très abscons, mais l'idée est finalement assez simple. Normalement, quand le système invité rencontre un [défaut de page](http://en.wikipedia.org/wiki/Page_fault), l'hôte interrompt le fonctionnement du guest et s'occupe d'aller chercher la page mémoire requise. L'idée du patch est de ne plus suspendre l'exécution du guest et d'utiliser ce délai pour permettre au système invité de faire avancer un autre thread. Pour cela, l'hôte envoie un message de « _défaut de cache asynchrone_ » et l'invité endort uniquement le thread qui a demandé la page mémoire. Le guest peut donc continuer à faire tourner d'autres threads et n'est plus complètement bloqué. Quand l'hôte fournit la page, alors un signal de réveil est simplement envoyé au thread qui était suspendu. D'après les tests de Gleb Natapov, et qui sont résumés dans ce [fichier pdf](http://www.linux-kvm.org/wiki/images/a/ac/2010-forum-Async-page-faults.pdf), les gains sont très importants. Le protocole se base sur un hôte accueillant quatre machines virtuelles. Sur chacun des systèmes invités, un thread réalise des accès mémoire aléatoires tandis qu'un autre incrémente un compteur. Au bout d'une minute, on regarde le compteur pour voir la quantité de travail qu'a pu effectuer le thread d'incrémentation : Sans « `async page fault` » : 129 752 639 953 Avec « `async page fault` » : 258 846 142 585 Certes, le test est conçu pour bien mettre en évidence les changements induits par le patch...mais un doublement des performances c'est quand même assez spectaculaire ! ###DMI La norme DMI ([Desktop Management Interface](http://fr.wikipedia.org/wiki/Desktop_Management_Interface)) est une couche d'abstraction qui permet de décrire tous les composants matériels d'un ordinateur. Le noyau Linux contient un décodeur DMI et, grâce à lui et grâce aux infos de [SMBIOS](http://en.wikipedia.org/wiki/System_Management_BIOS), on peut lancer une commande qui va retourner une liste descriptive de la machine. La commande en question, c'est le bien connu `dmidecode` qui doit être lancé en root. Pour faciliter l'obtention de ces informations sur le matériel, le noyau Linux 2.6.39 implémente une nouvelle interface `/sys/firmware/dmi/`. Si le noyau est configuré avec l'option `DMI_SYSFS` alors un simple utilisateur pourra utiliser les informations présentes dans ce répertoire pour connaître tous les secrets cachés de son ordinateur. ###Fenêtre de congestion TCP Les réglages par défaut de la pile [TCP](http://fr.wikipedia.org/wiki/Transmission_Control_Protocol) du noyau ont été modifiés dans la nouvelle version 2.6.39. Le protocole TCP spécifie un algorithme spécial pour découvrir le débit maximum que supporte une connexion. Cet algorithme, nommé « slow start », va commencer par envoyer très peu de données et va progressivement augmenter la cadence jusqu'à la saturation du lien. C'est bien pratique d'avoir ainsi un fonctionnement qui s'adapte aux conditions réelles du réseau... mais les ingénieurs de Google ont récemment [signalé un problème](http://research.google.com/pubs/pub36640.html). Comme l'indique le nom « slow start », on va commencer en douceur et la fenêtre de congestion (_initial congestion window_) est très petite au début de la connexion. La limite est de quatre [segments](http://fr.wikipedia.org/wiki/Transmission_Control_Protocol#Structure_d.27un_segment_TCP), ce qui correspond environ à 4 Ko. Si la durée de connexion est courte, alors cela signifie qu'on n'aura jamais vraiment profité du débit de la ligne puisqu'on sera resté tout le temps en mode « 4 segments ». Cette limite est donc de nos jours un goulet d'étranglement puisque les réseaux permettent des débits plus importants qu'au moment où a été décidé la limite de congestion (en 2002 dans la [RFC 3390](http://tools.ietf.org/html/rfc3390)). Les tests de Google (voir [le pdf](http://research.google.com/pubs/archive/36640.pdf) de l'article `An Argument for Increasing TCP's Initial Congestion Window`) ont montré qu'un passage à une fenêtre de congestion à dix segments permettrait de réduire d'environ 10% le temps de latence moyen d'une requête HTTP. David S. Miller, le mainteneur de la couche réseau du noyau, a donc écrit [le patch](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=442b9635c569fef038d5367a7acd906db4677ae1) qui modifie [la taille de la fenêtre de congestion](https://lwn.net/Articles/427104/) et le noyau 2.6.39 est la première version à proposer ce nouveau réglage par défaut. ### Algorithmes CHOKe et SFB Toujours dans le domaine des réseaux, le noyau 2.6.39 accueille deux nouveaux algorithmes de [contrôle de la congestion](http://fr.wikipedia.org/wiki/Tcp#Contr.C3.B4le_de_congestion). En effet, quand un lien est saturé, il faut avoir une méthode pour réduire le débit et ce problème du contrôle de la congestion est encore un domaine de recherche actif pour trouver l'agorithme le plus efficace. [Le patch d'intégration de SFB](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e13e02a3c68d899169c78d9a18689bd73491d59a) (_Stochastic Fair Blue_) explique que la stratégie de cet algorithme ne se base plus sur la longueur des queues de paquets des routeurs pour déterminer qu'un engorgement du réseau est en cours. On va plutôt baser les heuristiques sur le nombre de paquets perdus et sur les périodes de veille du lien (_link idle events_), ce qui est perçu comme plus représentatif. [Le second algorithme intégré dans le noyau](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=45e144339ac59971eb44be32e1282760aaabe861) adopte une stratégie complètement différente. Portant un nom qui ne peut que faire plaisir au barbare sanguinaire qui sommeille en nous, l'algorithme [CHOKe](https://lwn.net/Articles/422477/) (pour « _CHOose and Kill_ ») va examiner les limites fixées à la longueur des queues de paquets des routeurs. Quand la taille paramétrée est dépassée, on compare le paquet entrant avec un paquet se trouvant déjà dans la queue et choisi au hasard (c'est le _CHOose_). Si ces deux paquets émanent du même flux, alors il y a une grande chance que le coupable de la saturation du lien soit identifié. On passe alors à l'étape _Kill_ en supprimant sans pitié les deux paquets. Bien entendu si les deux paquets ne sont pas membres d'un même flux, alors on se contente de tuer le paquet entrant. L'avantage de cette stratégie c'est que le routeur n'a pas a surveiller en permanence l'origine réelle des divers flux (ce qui est très coûteux) puisque l'heuristique pourra identifier le coupable avec une bonne précision en cas de problème. ###BKL: That's all folks Après l'annonce de la fin du « _Big Kernel Lock_ » dans [le noyau 2.6.37](https://linuxfr.org/news/sortie-de-la-version-2637-du-noyau-linux#long7) les derniers bouts de code obscurs qui l'utilisaient encore ont été impitoyablement traqués. Même si c'est plus pour la beauté du geste qu'autre chose, Arnd Bergmann a converti les derniers récalcitrants : les systèmes de fichiers [UFS](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=788257d6101d986ac8f2741aaa35974af47f574c) et [HPFS](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9a311b96c3065f362e3348cb5d7af1a57ca6bff9), les protocoles [X.25](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=77b2283604bdd7053494a97b0e2fee97148206c6), [IPX](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b0d0d915d1d1a0fe486849f3e41333c66df620c4) ou encore [Appletalk](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=60d9f461a20ba59219fdcdc30cbf8e3a4ad3f625) ont été modifiés pour supprimer toute référence au verrou global. Certes ce travail est sans doute un peu vain puisque les utilisateurs réels de ces sous-systèmes doivent se compter sur les doigts de la main d'un lépreux. Pourtant le fait de mettre un point final à cette épopée a une certaine valeur en soi. Psychologiquement, même si cela n'a pas de conséquences pratiques, il est important de ne pas laisser des parties délaissées du noyau dépendre du BKL. On peut sentir transparaître la satisfaction du devoir accompli quand on regarde [le message de commit d'Arnd](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4ba8216cd90560bc402f52076f64d8546e8aefcb). Qu'il s'agisse du fier « [That's all Folks](http://www.phrases.org.uk/meanings/350000.html) », du listing des contributeurs ayant participé à la traque ou encore du statut « _deleted file_ » appliqué au fichier `lib/kernel_lock.c`, c'est vraiment un commit historique que nous avons là et c'est une page du noyau qui se tourne avec la fin du BKL. #Le bilan en chiffres Du côté des statistiques de ce cycle, [l'article récapitulatif du site LWN](https://lwn.net/Articles/442229/) pour le 2.6.39 est disponible. On peut également consulter [le site remword](http://www.remword.com/kps_result/) dédié aux statistiques du noyau Linux pour trouver les principales données quantitatives de cette version (chiffres au 17 mai). Il est à noter que ce cycle a été particulièrement calme et court. Les régressions signalées sur la LKML ont été peu nombreuses et Linus a publié seulement 7 versions candidates avant de sortir le noyau 2.6.39 définitif. Entre le 14 mars et le 18 mai seulement 64 jours se sont écoulés, ce qui représente le cycle de développement le plus réduit depuis l'import initial dans Git en avril 2005 pour la version 2.6.12-rc2. En matière de patchs et de nombre de développeurs cette version est un bon cru puisqu'on relève l'intégration de [10 208 patchs](http://www.remword.com/kps_result/2_6_39_petop.html) écrits par 1 292 développeurs (9 432 patches et 1 201 développeurs pour le noyau 2.6.38). On peut noter qu'environ 670 000 lignes de code ont été ajoutées au noyau et 346 000 lignes supprimées et que le plus gros contributeur individuel est Thomas Gleixner (auteur des patchs sur le sous-système des interruptions évoqué plus haut). Une donnée toujours importante est celle des primo-contributeurs (les personnes postant un patch pour la toute première fois depuis la bascule vers Git en avril 2005). Ils sont cette fois [310](http://www.remword.com/kps_result/2_6_39_ftc.html) ce qui constitue le second plus grand total depuis plus de dix cycles. En termes de contributions par les entreprises, c'est toujours [Red Hat qui est en tête](http://www.remword.com/kps_result/2_6_39_whole.html), avec Intel en seconde position et Novell juste derrière. Dans [l'article de LWN](https://lwn.net/Articles/442229/) Jon Corbet indique que la position d'Oracle continue de décliner et il est peut-être intéressant de vérifier cette assertion en regardant de plus près les statistiques. Je me suis donc penché sur les chiffres relatifs aux contributions d'Oracle afin de voir comment évoluent la tendance depuis quelques années. Est-ce que la création d'« _Unbreakable Linux_ » a conduit au développement d'une solide expertise interne ? Est-ce que le nombre de patchs a varié depuis le rachat de Sun en janvier 2010 ? Est-ce que le niveau d'implication dans le noyau est toujours le même ? Regardons l'évolution depuis le noyau 2.6.27 d'octobre 2008 : ![Titre de l'image](http://patrickguignot.free.fr/linuxfr/oracle.png) Si on excepte le pic du noyau 2.6.29, qui s'explique par l'intégration de btrfs dans la branche principale, on constate que la tendance est plutôt à la baisse et qu'en termes de patches Oracle semble de moins en moins actif. En termes de rang parmi les autres entreprises contributrices le recul est également perceptible puisque Oracle était régulièrement dans les dix premiers contributeurs alors que depuis le noyau 2.6.33 l'entreprise s'enfonce lentement vers la vingtième place. Nul doute que ces données quantitatives, et la tendance qu'elles révèlent, sont à prendre en compte par les entreprises qui étudient une transition vers « _Unbreakable Linux_ ». #Pour la suite En ce qui concerne les futures nouveautés des prochaines versions du noyau, on peut se tourner vers [la page spécifique](http://www.linuxfoundation.org/en/Linux_Weather_Forecast) de la Fondation Linux. ## ARM : une solution en vue [Les récriminations](https://lwn.net/Articles/439314/) de Linus Torvalds au sujet de la branche ARM ont été suffisamment sonores pour inquiéter sérieusement les mainteneurs de cette architecture. Quand on lit des phrases comme « [Je suis à _deux doigts_ de ne plus accepter aucun patch de certaines personnes à moins que les choses ne s'améliorent](http://article.gmane.org/gmane.linux.ports.arm.kernel/113895) » c'est qu'il est grand temps de s'activer afin [d'améliorer la situation](http://linux-foundation.org/weblogs/lwf/2011/05/14/whats-up-with-arm/) dans les futurs noyaux. C'est pour réfléchir à la meilleure stratégie que [Linaro](http://en.wikipedia.org/wiki/Linaro), l'organisation à but non lucratif qui rassemble les entreprises intéressées par ARM, a organisé [un sommet des développeurs](http://summit.linaro.org/uds-o/) à Budapest au mois de mai. Paul E. McKenney a résumé les échanges dans plusieurs posts successifs sur son blog ([1](http://paulmck.livejournal.com/25785.html) - [2](http://paulmck.livejournal.com/26362.html) - [3](http://paulmck.livejournal.com/26599.html)). Il semble que les développeurs ARM vont essayer de migrer le maximum de sous-architectures vivant dans `/arch/arm/*` vers le répertoire `/drivers/*`. Cela permettra de fusionner plusieurs pilotes quasi-identiques et de partager davantage de code entre les divers SoC. Un travail de fond pour consolider le code des sous-architectures est également lancé. Qu'il s'agisse de la gestion des horloges, de cpufreq ou cpuidle, de l'unité de gestion de la mémoire ([IOMMU](http://en.wikipedia.org/wiki/IOMMU)), des gestionnaires d'interruptions, etc. Chacun de ces points a été examiné soigneusement pour ne plus dupliquer le travail et le code. Quelques patchs d'unification vont rejoindre le noyau dès la version 2.6.40 mais c'est vraiment à partir du 2.6.41 que les choses vont s'accélérer avec la mise en place d'un « [device tree](http://devicetree.org/Device_Tree_Usage#Basic_Concepts) » descriptif pour les cartes ARM et les SoC. Un dépôt Git spécifique va être mis en place avec des accès pour les principaux responsables ARM (Arnd Bergman, Nicolas Pitre, Marc Zyngier, Thomas Gleixner et Russell King) et des branches pour chacune des sous-architectures. Cela permettra de proposer à Linus des branches propres à importer vers le noyau. Selon Paul E. McKenney cette nouvelle organisation n'est certainement pas la solution ultime au problème ARM mais elle montre que les développeurs Linux sont conscients du problème et ont [commencé à s'y attaquer](http://paulmck.livejournal.com/25785.html) :>Il y a une quantité de code incroyable dans le répertoire ARM de Linux, et une quantité effrayante qui est générée chaque jour : plus d'un quart de million de lignes par an selon certaines estimations.>Il serait trop facile de conclure que la situation actuelle est un désastre complet. Au contraire, ceux d'entre nous qui sont là-dedans depuis un certain temps verront ça comme une grosse amélioration par rapport à la période maudite où les développeurs de l'embarqué gardaient leurs patchs pour eux. Nous dans la communauté du noyau Linux nous leur avons demandé de soumettre leurs patchs et ils ont commencé à le faire. Il est donc temps pour nous de comprendre comment nous allons pouvoir boire à cette lance à incendie ;-)

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