URL: https://linuxfr.org/news/sortie-du-noyau-linux-31 Title: Sortie du noyau Linux 3.1 Authors: patrick_g Date: 2011年09月06日T15:04:31+02:00 License: CC By-SA Tags: kernel, smack, apparmor, lwn, linux, noyau_linux et coulisses Score: 107 Le _commit_ marquant la sortie de la version stable 3.1 du noyau Linux vient [d’être effectué](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=c3b92c8787367a8bb53d57d9789b558f1295cc96;hp=6a0596583fadd15dca293736114abdea306d3d7c) par Linus Torvalds lors du [sommet de Prague](http://ksummit2011.kernel.org/). Les sources de ce nouveau noyau sont téléchargeables sur les serveurs du site [_kernel.org_](http://www.kernel.org/pub/linux/kernel/v3.0/) et le message d’annonce de Linus est lisible [_ici_](http://article.gmane.org/gmane.linux.kernel/1206934). Cette version a été marquée par la [détection d’une intrusion sur _kernel.org_](http://linuxfr.org/news/les-serveurs-de-kernelorg-ont-%C3%A9t%C3%A9-compromis) et le [passage provisoire à GitHub](http://linuxfr.org/users/crev/journaux/le-pragmatisme-%C3%A0-la-torvalds-ou-linux-sur-github) des sources de la branche de Linus. On peut également relever [une proposition humoristique](https://lkml.org/lkml/2011/9/10/24) de changement ponctuel de [logo](http://djwong.org/docs/31-tuxlogo.png) (comme c’était le cas pour la version 2.6.29, voir la [dépêche](https://linuxfr.org/news/sortie-de-linux-2629) et le [journal](https://linuxfr.org/users/dup/journaux/le-kernel-linux-22629-aura-sa-propre-mascotte) à ce sujet). 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)). _P.‐S. : Pour diverses raisons, j’ai eu fort peu de temps pour rédiger cette dépêche noyau et j’ai [sollicité toutes les bonnes volontés](http://patrickguignot.free.fr/linuxfr/help.jpg) pour contribuer à la rédaction. Je remercie donc chaleureusement toutes les personnes qui ont travaillé sur cette dépêche (en particulier la traduction **complète** des courriels de RC) en ajoutant leur pierre à l’édifice._ ---- [[LWN 1] Les nouveautés du noyau 3.1](https://lwn.net/Articles/452748/) [[LWN 2] Les nouveautés du noyau 3.1](https://lwn.net/Articles/453700/) [Les articles récapitulatifs de h-online.com](http://www.h-online.com/open/features/Linux-Kernel-3-1-Tracking-1319593.html) [La liste des nouveautés sur kernelnewbies](http://kernelnewbies.org/Linux_3.1) ---- #La phase de test ### RC-1 La version [RC-1](https://lkml.org/lkml/2011/8/7/102) a été annoncée par Linus le 7 août : _« Ça fait un peu plus de deux semaines, mais j’ai décidé de sortir cette version de chez moi plutôt qu’en vacances, alors, les gars, vous avez eu quelques jours supplémentaires pour la fusion. Et certains d’entre vous ont profité de cela. Tsss, tsss._ _Quoi qu’il en soit, la version 3.1 s’annonce être une version assez normale. Près de 75 % des patches sont des pilotes, 12 % sont des mises à jour d’architecture, et le reste de divers : système de fichiers, réseau et documentation._ _Pour les pilotes, environ 40 % viennent de_ staging, _20 % pour le réseau et 10 % pour le son. Avec SCSI, les médias, etc., qui ferment la marche. Une bonne partie d’entre eux est du nettoyage. Et la bonne nouvelle est que la majorité des changements venant de staging était des suppressions de code. La mauvaise nouvelle est que nous avons bien rattrapé ça à d’autres endroits. ;)_ _Ce qui est notable ? Ça dépend de ce qui vous intéresse. Le travail sur la synchronisation de la mémoire virtuelle avec le disque ? Vous l’avez. Et il y avait une certaine controverse sur le code cible iSCSI. Il y a des modifications du réseau, le reste de la gestion générique des listes de contrôle d’accès [ACL] est déplacé dans la couche VFS, cela simplifie le code des systèmes de fichiers qui dupliquait souvent, par copier‐coller, le code générique. Et nous sommes au passage plus rapides pour le faire._ *Et l’interface de la gestion d’énergie a été nettoyée.* _Mais il n’y a rien de **gros** ici. Cela ressemble à une version normale, comme je le dis. À moins que j’aie oublié quelque chose._ _Récupérez‐le et testez‐le. Oh, sauf qu’en ce moment, vous serez probablement mieux en gardant le débogage de SLUB désactivé, à moins que vous vouliez aider à le tester. »_ ### RC-2 La version [RC-2](https://lkml.org/lkml/2011/8/14/281) est sortie le 14 août : _« Eh, une jolie première semaine calme après la fenêtre de fusion. Bon boulot. Ou peut‐être les gens ont‐ils seulement été paresseux, et que tout le monde est en vacances. Peu importe. Ne me le dites pas. Je suis plutôt content, et je veux le rester._ _Cela dit, je serais content que ça se calme davantage. Plus de 300 commits pour -rc2, c’est bon, mais s’il vous plaît rendez‐moi encore plus heureux pour la -rc3 en m’envoyant UNIQUEMENT des vraies corrections. Imaginez ça comme "assez tard dans la série des RC", car je veux vraiment compenser la fenêtre de fusion qui a été assez chaotique. »_ ### RC-3 La version [RC-3](https://lkml.org/lkml/2011/8/22/333) est sortie et a été annoncée le 22 août : _« J’ai un jour de retard, j’étais trop affamé, fatigué après le cours de moniteur de plongée pour la sortir hier. Mais la voilà, toute neuve et toute fraîche._ _Et il y a des remerciements au menu : les choses se présentent bien. Les statistiques des différences semblent raisonnables (le plus gros ajout est dans la documentation), et même si j’aurais souhaité un peu moins de changements inutiles, je suis quand même content. Le [résumé des changements](http://martin.ankerl.com/2009/12/23/svn-shortlog-compact-beautiful-subversion-changelog/) des RC2 et RC3 est joint, et il me semble, dans l’ensemble, raisonnable et court. Ce qui ne veut pas dire que je n’espère pas que les choses vont se calmer encore davantage dans les RC suivantes ; mais au moins jusqu’à présent, je ne pense pas que j’aie eu beaucoup de raisons de me plaindre._ _D’autres remerciements vont à Intel : cette version a été remplie de voyages (heureusement tous terminés). Premièrement, il y a eu une semaine de vacances pendant la fenêtre de fusion, ensuite des week‐ends pour mes cours de DM et LinuxCon. Et le nouveau portable a rendu ça beaucoup moins douloureux, même pour des constructions "allmodconfig" pendant que j’étais sur la route. »_ ### RC-4 La version [RC-4](https://lkml.org/lkml/2011/8/29/8) a été annoncée par Linus le 28 août : _« Nous sommes revenus sur des publications hebdomadaires._ _Je ne sais que dire sur celle‐ci. La -rc3 a eu moins de nouveaux `commits` que la -rc4 en a eu, et je n’aime pas cette tendance. Je ne suis pas content de la taille de certains des changements (iSCSI Target, et certains autres pilotes), mais en même temps, je dois dire qu’absolument rien ici ne m’inquiète vraiment. La plupart des changements sont **vraiment** triviaux, et ceux qui sont un peu plus gros ont tendance à être dans des domaines assez ésotériques. Par exemple, [[SPARC]] apparaît dans les statistiques par répertoire comme l’un des plus grands changements, et c’est juste parce qu’il y a un assez gros changement pour le traitement de signaux pour corriger un test plutôt obscur. Mais pour ma part, je n’arrive pas à m’inquiéter à ce sujet._ _Ou que dire des changements de pilote Wiimote ? Ou de ceux des cibles iSCSI ?_ _En d’autres termes, la plupart des gens ne remarqueront rien — et les choses restantes sont vraiment petites et réparties ligne par ligne (surtout dans les pilotes). Si vous regardez l’ancien style — ne prenant pas en compte le renommage — des patches, les changements XFS paraissent énormes et effrayants, mais ce ne sont que des renommages de fichiers._ _Quoi qu’il en soit, soyez fous et, s’il vous plaît, testez. Le résumé des modifications en annexe donne un bon aperçu des changements, mais ils ne sont vraiment pas si importants._ _Donc vraiment j’**espère** que la RC5 sera plus petite. Mais en même temps, je continue d’être assez content de l’état du 3.1 jusqu’ici. Mais peut‐être est‐ce seulement mes médicaments qui fonctionnent enfin._ _Linus "Je ne pense pas que j’ai réellement engueulé quelqu’un cette semaine" Torvalds. »_ ### RC-5 ### La version [RC-5](http://lkml.org/lkml/2011/9/4/92) est sortie le 4 septembre : _« Alors c’est le début de la semaine, il est temps pour une nouvelle RC._ _Toutefois, `master.kernel.org` est toujours en maintenance, et il n’y a pas vraiment eu une tonne de développements en cours, alors j’ai envisagé de sauter une semaine. Mais bon, tout l’intérêt (enfin, l’**un** des intérêts) du développement distribué, est qu’aucun endroit particulier n’est vraiment différent des autres. Alors, comme j’ai un compte GitHub pour mon truc [_diveclog_](https://plus.google.com/102150693225130002912/posts/PVZDD2N3Tvi) (NdT : un logiciel en C/GTK pour afficher les profils de plongée dont le nom est (aussi) un jeux de mots, sauras‐tu, ami lecteur, le trouver ?), pourquoi ne pas voir comment il me supporte si j’y mets aussi tout mon dépôt du noyau ?_ _Alors, tant que `kernel.org` est H.S., voyons comment se porte GitHub :_ https://github.com/torvalds/linux.git _**N.B. :** une chose à regarder, lorsque vous voyez un nouvel hébergement à usage public comme ça, est de vérifier que c’est effectivement bien la personne à laquelle vous pensez. Alors, est-ce elle ?_ _Vous pouvez adopter différentes approches :_ 1. _zut, c’est open source, je me fous d’où je récupère, je veux juste un nouveau noyau et je n’ai pas de mises à jour de `kernel.org` depuis quelques jours, j’ai **vraiment** besoin de ma nouvelle correction du noyau. Je vais le prendre, parce que j’ai besoin de faire travailler mon processeur en compilant le noyau "randconfig". D’ailleurs, j’aime vivre dangereusement ;_ 2. _bien, l’adresse e‐mail semble être celle de Linus, et nous savons tous que SMTP ne peut être usurpé, alors ça doit être lui ;_ 3. _OK, je peux obtenir les sources et je sais que Linus signe toujours les tags, donc je peux vérifier le tag 3.1-rc5 avec la clé GPG publique de Linus. Si ça colle, je me contrefous de qui est la personne qui écrit ce courriel, je sais que Linus a signé l’arbre des sources ;_ 4. _je vais plutôt attendre que `kernel.org` aille mieux._ _Choisissez ce qui vous convient._ _Une chose à noter, si vous tapez simplement :_ ```text git pull https://github.com/torvalds/linux.git ``` _Vous n’obtiendrez probablement pas les tags, puisqu’il ne s’agit pas de votre branche originelle. Donc, utilisez aussi :_ ```text git fetch --tags <...> ``` _De façon à obtenir, en plus des changements, les tags signés que vous pouvez vérifier._ _De plus, je_ suggérerais _que vous effectuiez la récupération dans un dépôt existant, plutôt que de cloner une nouvelle copie. Je parie que les gens de GitHub apprécieront cela._ _Quelque chose de spécial concernant les changements eux-même ? Le résumé des modifications attaché parle pour lui‐même : il n’y a pas grand chose d’excitant sur le développement lui‐même._ _Maintenant, si vous voulez parler de logiciels d’analyse de plongée, c’est une toute autre sorte de poisson. »_ ### RC-6 ### La version [RC-6](http://lkml.org/lkml/2011/9/14/33) est sortie le 14 septembre : _« [Eh ! Quelque peu retardée, mais je n’avais absolument pas remarqué que tous mes courriels sortants me revenaient ces derniers jours, donc le revoici. À l’origine *destiné* à être envoyé lundi, apparemment jamais allé nulle part. Donc, quand je dis "j’aurais dû faire ça hier", ça *signifie*, en fait, dimanche. ;^]_ _Donc, j’aurais dû faire ça hier, mais j’ai été distrait. Donc, le voici avec un jour en retard :_ ```text git://github.com/torvalds/linux.git ``` _Avec seulement une centaine de commits. Ça a été assez calme._ _Quelques mises à jours sur ARM et [[OpenRISC]], de petites corrections diverses de pilotes (les corrections du DRM nVidia pourraient être les plus remarquables pour les gens), et quelques mises à jour de FUSE, [9P](http://kerneltrap.org/node/5339) et Btrfs, pour les systèmes de fichiers._ _Rien de vraiment remarquable. Prenez‐le, et faites savoir s’il y a des régressions notables. »_ ### RC-7 La version [RC-7](http://lkml.org/lkml/2011/9/21/468) est sortie le 21 septembre : _« J’étais supposé faire ça lundi, mais ça ne semblait pas extrêmement pressant._ _Non seulement parce que certains patches étaient sujets à discussion, il devient clair que je pourrais ne pas publier la 3.1 finale avant la fin de mes vacances, début octobre — sinon, la prochaine fenêtre de fusion serait un chaos total. Une fenêtre de fusion avec `kernel.org` indisponible ne fonctionnerait vraiment pas, et faire une sortie seulement pour avoir ensuite une espèce de fenêtre de fusion chaotique suivie d’un voyage, me semble une folie._ _Donc, nous y sommes, deux jours en retard, mais pas pressé._ _Nous avons en fait corrigé plusieurs régressions centrales. Elles n’étaient pas faciles à trouver (c’est pourquoi ça a pris autant de temps), mais nous avions une saleté de bogue sur les entrées de répertoires — [`dentries`](http://fr.wikipedia.org/wiki/Virtual_File_System#L.27objet_dentry) — (corrigé par le premier commit du résumé des changements ci‐dessous) qui, il est vrai, était seulement déclenchable avec NFS et quelques mouvements de dossiers bizarres. Mais il était toujours intéressant de voir quelque chose comme ça dans ces moments‐là. Quelques règles de comptage de références des `dentries` plutôt subtiles avaient résulté en un "nettoyage évident", cassant une règle subtile à propos des durées de vies des `dentries` parents, etc._ _Nous avions quelques autres choses "centrales" (perte de temps à boucler sur les entrées de pages d’échange disque [swap] dans `find_in_pages()`), mais comme vous pouvez le voir dans le résumé des modifications, la plupart ont terminé en étant plutôt périphériques. Essentiellement des corrections aléatoires dans les pilotes, ce qui est aussi corroboré par le `diffstat` : 60 % de pilotes, 8 % de réseau, 7 % d’architectures (ARM et UM), 7 % systèmes de fichiers, 5 % de gestion mémoire, quelques petits patches aléatoires pour le reste. »_ ### RC-8 La version [RC-8](https://lkml.org/lkml/2011/9/27/532) est sortie le 27 septembre : _« Autre semaine, autre RC sur :_ ```text git://github.com/torvalds/linux ``` _Et cette fois, c’est réellement notablement petit. Le `diffstat` est plutôt tout petit, avec quelques patches `coretemp` et `clock_ops` qui ressortent, ainsi qu’une petite mise à jour de `perf-tool`, tout le reste étant d’au plus quelques lignes. Et pas tant que ça en plus._ _Si vous êtes un utilisateur de l’auto‐monteur `automount` (soit de la variété `autofs`, soit de celle de NFS), testez le s’il vous plaît. Il y a eu quelques changements dans la logique d’`automount`. Ils sont petits et plutôt évidents, et je doute que quelqu’un le remarquera, mais je demanderai quand même aux gens d’automount de tester ça._ _Ceci mis à part, ça devient plutôt calme. Nous discutons_ toujours _de quelques problèmes de débranchement d’USB dans la couche bloc, mais il y a des patches qui circulent. Donc, si quelqu’un parvient à provoquer des problèmes, contactez Jens et mettez‐moi en copie, s’il vous plaît._ _À part ça, testez, s’il vous plaît, pour d’éventuelles surprises... »_ ### RC-9 La version [RC-9](http://lkml.org/lkml/2011/10/4/451) est sortie le 4 octobre : _« Une autre semaine, une autre -rc._ _Au niveau du noyau, il n’y a pas énormément de changements. Cela étant dit, à cette étape, c’est mieux ainsi — et cela ne m’aurait pas dérangé d’en avoir encore moins. Mais les corrections que l’on trouve ici sont généralement assez limitées, et les statistiques de changements ne sont pas si effrayantes — il n’y a vraiment aucun **gros** changement nulle part._ _Les choses qui sortent un peu du lot : quelques corrections sur le DRM (`radeon` et `i915`), divers pilotes réseau, quelques correctifs sur [Ceph](http://en.wikipedia.org/wiki/Ceph) — et d’autres petites choses diverses. Les mises à jour concernant SPARC sont minuscules (détection T4/T5), mais c’est aussi le cas pour les autres architectures, les choses ont vraiment été calmes à ce point._ _Le changement le plus visible ne concerne en fait pas du tout le code, c’est_ kernel.org _qui commence à remettre certains services en activité, ainsi vous pouvez maintenant retrouver les sources du noyau à leur place habituelle :_ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git _(Bien que j’aie mis aussi GitHub à jour, au cas où vous auriez cloné de là, afin que vous n’ayez pas **besoin** de changer)._ _Aussi, maintenant que j’ai une clef GPG plus forte, et que cette nouvelle clef est d’ores et déjà signée par plus de personnes que l’ancienne ne l’a jamais été (au moins des personnes que je **connais**), j’ai décidé que je devais changer pour celle‐ci. Donc, si vous êtes le genre de personne qui vérifie les étiquettes (tags), vous voudrez sûrement faire :_ ```text gpg --recv-keys 00411886 ``` _pour obtenir ma nouvelle clef, ainsi `« git verify-tag »` fonctionnera pour vous._ _Empreinte de la clef :_ `ABAF 11C6 5A29 70B1 30AB E3C4 79BE 3E43 0041 1886`. _Évidemment, afin de s’assurer que cette clef est réellement la mienne, au lieu de croire aveuglément en ce courriel qui pourrait facilement être falsifié par quelque envieux de Linux, vous voudrez sûrement la vérifier. Mais vu qu’elle est signée avec mon ancienne clef de signature des étiquettes, vous ne devriez pas avoir plus de souci d’authenticité que vous n’en aviez avec l’ancienne. Ou alors vous pouvez essayer de suivre la chaîne de confiance des autres signataires de la clef, certains d’entre eux ont bien plus de signatures que je n’en ai jamais eues, et sont plutôt bien connectés._ _Quoi d’autre de notable ? J’espère que les problèmes de PCIe avec les réglages du [MPS](http://en.wikipedia.org/wiki/MultiProcessor_Specification) sont tous derrière nous, pour la simple raison que nous les avons tout simplement désactivés pour le moment, et que nous y reviendrons pour la 3.2. Et les "oops" occasionnels lors du retrait d’un disque USB devraient être réglés une bonne fois pour toutes (touchons du bois). Tout le reste devrait être vraiment ésotérique et spécifique au matériel, vous pouvez prendre la température de tout cela dans le résumé des modifications._ ### RC-10 ### Une fois n’est pas coutume (!), une dixième version candidate est sortie pour cette nouvelle mouture du noyau. Linus a annoncé cette [RC-10](https://lkml.org/lkml/2011/10/18/2) le 18 octobre (le 17, pour lui) : _« Ok, nous sommes à une semaine du_ [Kernel Summit](http://ksummit2011.kernel.org/)_, et voici la dernière RC que j’ai prévu de faire._ _Il ne s’est vraiment pas passé grand chose, les petites mises à jour pour MIPS représentent toujours la majeure partie de cette RC, le reste n’est, grosso modo, que des petites corrections de pilotes. Oh, et quelques corrections de systèmes de fichiers (Btrfs and XFS) de dernière minute également._ _Le résumé des modifications est aussi explicite que possible. Il y a encore quelques discussions à propos d’une poignée de trucs secondaires que nous aimerions voir résolus, mais dans l’ensemble le 3.1 est attendu depuis longtemps, et pour le_ Kernel Summit, _je pense que tout le monde sera soulagé de le voir publié, et prêt à ouvrir la fenêtre d’intégration. »_ #Les nouveautés ##OpenRISC La nouvelle architecture [OpenRISC](http://fr.wikipedia.org/wiki/OpenRISC), issue de la communauté [OpenCores](http://en.wikipedia.org/wiki/OpenCores), fait son entrée officielle dans le noyau Linux 3.1. OpenCores est une communauté de _hackers_ qui cherche à produire des puces sous licence libre, plus exactement des « [_IP cores_](http://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core) », c’est‐à‐dire des unités logiques réutilisables. Ces dernières sont décrites dans [un langage spécial](http://fr.wikipedia.org/wiki/Langage_de_description_de_mat%C3%A9riel) adapté au matériel du type [Verilog](http://fr.wikipedia.org/wiki/Verilog) ou [VHDL](http://fr.wikipedia.org/wiki/VHDL). Divers [projets sont en cours](http://opencores.org/projects) chez OpenCores, notamment des contrôleurs Ethernet ou USB, des unités de chiffrement AES ou DES, ou encore des modules de codage vidéo. Le projet star du mouvement est l’[architecture OpenRISC](http://openrisc.net/) qui vise à permettre la création de processeurs généralistes 32 ou 64 bits. La définition de cette architecture, nommée OpenRISC 1000, est maintenant [complète et disponible sous licence LGPL](http://opencores.org/openrisc,architecture) tandis que la première implémentation de l’_OpenRISC Reference Platform System‐on‐Chip_ et de son cœur [OpenRISC 1200](http://openrisc.net/or1200-spec.html#_openrisc_1200) est disponible sur circuit programmable [FPGA](http://fr.wikipedia.org/wiki/FPGA) en tant que [_softcore_](http://fr.wikipedia.org/wiki/Processeur_softcore). La [page ORPSoC](http://opencores.org/or1k/ORPSoC) du site OpenCores détaille cette plate‐forme de référence et permet de télécharger des images FPGA pour des cartes de développement. L’ambition à plus long terme est de réunir suffisamment d’argent pour pouvoir passer du FPGA à l’[ASIC](http://fr.wikipedia.org/wiki/Application_Specific_Integrated_Circuit), c’est‐à‐dire au circuit intégré classique. [Selon les membres du projet](http://opencores.org/donation) :>La gravure de cette puce permettra à la communauté d’avoir un composant ASIC à bas coût, qui pourrait être utilisé pour développer des projets commerciaux sans aucune restriction et sans avoir à payer des redevances. Une carte de développement utilisant Linux sera également produite avec ces ASIC OpenRISC, ce qui permettra aux utilisateurs de créer des produits Linux complets et d’un excellent rapport qualité‐prix. Bien entendu, on comprend que la première itération de processeur, l’OpenRISC 1200, ne vise pas à concurrencer les monstres d’AMD ou d’Intel gravés en 32 nanomètres. La communauté OpenCores vise une gravure en 180 nanomètres, ce qui est censé permettre un fonctionnement à 300 MHz et une puissance de calcul 20 % supérieure aux autres compétiteurs de la même catégorie. Diverses entités commerciales utilisent déjà l’architecture OpenRISC, par exemple les firmes [Beyond Semiconductor](http://www.beyondsemi.com/page/) ou [Dynalith Systems](http://www.dynalith.com/doku.php). Dans son [annonce sur la LKML](https://lkml.org/lkml/2011/7/23/25), le développeur Jonas Bonn indique que l’inclusion dans le noyau Linux était devenue un but à atteindre depuis plusieurs mois : _« We want to be upstream ! »_. Les premiers correctifs s’appliquaient sur le noyau 2.6.35, mais il a fallu du temps pour que tout soit vraiment en place et d’une qualité suffisante pour demander à Linus d’accepter cet ajout. Le code a été soigneusement passé en revue avant d’être intégré dans le noyau (voir notamment tous les messages d’Arnd Bergmann sur [ce fil de discussion](http://thread.gmane.org/gmane.linux.kernel/1157086)). Cette nouvelle architecture est [maintenant présente](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ff0c4ad2c3a75ccfe6adca916e50804eb45bb2d9;hp=fcda12e7f6d58d61997681a9d41779e3fd2ffc94) sous `« arch/openrisc »` avec 90 nouveaux fichiers et presque 11 000 lignes de code en plus. Bien entendu, l’intégration dans le noyau Linux n’est pas un gage de succès et les développeurs d’OpenCores devront convaincre de la qualité de leur processeur. Le fait que l’architecture OpenRISC soit complètement nouvelle et ne s’appuie sur rien d’existant peut être vu comme un avantage (pas d’historique à traîner), mais comporte également des inconvénients (tout un écosystème à créer). D’autres initiatives de matériel libre existent déjà et s’appuient sur l’architecture SPARC (on peut citer [OpenSPARC](http://fr.wikipedia.org/wiki/OpenSPARC) ou [LEON](http://fr.wikipedia.org/wiki/LEON)). Le problème de tous ces projets est, bien entendu, la production des puces. [La page de donation](http://opencores.org/donation) pour la production de l’ASIC OpenRISC montre bien l’écart qui existe entre les sommes promises (moins de 20 000 $ USD, au moment où j’écris) et le coût réel de production d’un processeur moderne. ##Nouvel outil cpupower Un nouvel outil de gestion de la consommation nommé ``cpupower`` fait son entrée dans le noyau Linux 3.1, et vise à remplacer l’outil bien connu ``cpufrequtils``. Il peut paraître surprenant de voir faire mention de programmes en espace utilisateur, mais le répertoire ``« tools/ »`` de Linux contient divers programmes qui « gravitent » autour du noyau, et pour lesquels une distribution couplée avec le noyau a du sens. C’est Thomas Renninger, un développeur du noyau employé par Suse, qui avait [annoncé en mars dernier](http://article.gmane.org/gmane.linux.kernel.cpufreq/7041) la création de cet outil (initialement appelé ``cpupowerutils``). L’idée initiale de cet outil vient de la sophistication des processeurs modernes. En effet, les fonctions de gestion de l’énergie et d’_auto‐overclocking_ (états de sommeils profonds, mode _turbo/boost_, etc.) et l’ajout de nouvelles fonctionnalités au sein des processeurs (avec les [APU](http://fr.wikipedia.org/wiki/AMD_Fusion#APU) qui combinent un processeur graphique et un processeur généraliste) rendent de moins en moins pertinente la gestion de la consommation basée sur la fréquence du processeur. L’objectif de ``cpupower`` est de permettre de manipuler, suivre et déboguer la gestion de ces fonctionnalités des processeurs récents. On retrouve toutes les fonctions qui existaient dans `cpufrequtils`, mais la surveillance est maintenant étendue à tous les modes spécifiques des constructeurs ([_Enhanced Intel SpeedStep Technology_](http://fr.wikipedia.org/wiki/Intel_SpeedStep) ou encore _AMD [Cool’n’Quiet](http://fr.wikipedia.org/wiki/Cool%27n%27Quiet)_), ainsi que les modes d’endormissement profond, d’augmentation de fréquence Turbo, etc.. Pour l’instant, ce nouvel outil gère les processeurs Intel Nehalem et Sandy Bridge, ainsi que les AMD Liano et Ontario. ##Xen Après l’ajout du mode _Dom0_ dans la version 3.0, les _patches_ Xen, qui étaient depuis longtemps à l’écart du noyau, continuent d’être intégrés dans Linux. Il est désormais possible de faire du « [_self‐ballooning_](http://blog.xen.org/index.php/2008/08/27/xen-33-feature-memory-overcommit/) » (en ayant activé l’option `CONFIG_XEN_SELFBALLOONING` dans le noyau). Cette technique permet d’ajuster et d’optimiser la mémoire allouée aux systèmes invités. On peut ainsi accorder plus de mémoire par machine virtuelle que le système n’en possède réellement. Par exemple, si vous disposez de 4 Gio de RAM, cela permet de démarrer 4, 5 ou plus de machines. Xen va s’arranger (en se basant sur le mécanisme de [_cleancache_](http://linuxfr.org/news/le-noyau-linux-est-disponible-en-version%C2%A030#toc_10)) pour prendre de la mémoire là où elle n’est pas utilisée et pour la donner aux machines qui en ont besoin. Cette technique n’est donc pas recommandée si vos machines utilisent toute la mémoire que vous leur attribuez, mais permet de réduire la consommation de RAM totale avec des machines qui ont des besoins épisodiques de mémoire supplémentaire. Dans le même sujet, le pilote de _ballooning_ prend en charge l’ajout de mémoire à chaud. Un autre _patch_, appelé _frontswap-selfshrinking_, permet de libérer de la mémoire du _frontswap_ (un _swap_ en mémoire pour accélérer les machines virtuelles tout en évitant une trop grande consommation mémoire). Ce _patch_ va supprimer de la mémoire les pages qu’il contient, pour répondre à une demande d’utilisation importante de la mémoire. Il consiste, en pratique, à faire un `swapoff`. [Le message de _commit_](https://github.com/torvalds/linux/commit/a50777c791031d7345ce95785ea6220f67339d90) présent sur GitHub n’est pas très explicite, mais le mécanisme est correctement expliqué dans un long commentaire incorporé au code de `« drivers/xen/xen-selfballoon.c »`. Xen permet désormais d’[exposer directement les périphériques PCI](http://wiki.xen.org/xenwiki/XenPCIpassthrough) à la machine virtuelle sans passer par le système d’exploitation de l’hôte. Pour les machines complètement virtualisées, il faut disposer des instructions de virtualisation IOMMU (Intel VT-d ou AMD IOMMU) (ce sont des instructions supplémentaires par rapport aux instructions de virtualisation habituelles). L’utilisation est assez simple, soit il suffit de déclarer les périphériques PCI à exposer dans le fichier de configuration, soit il faut passer la commande suivante pour les monter à chaud dans une machine virtuelle en fonctionnement : ```bash xm pci-attach ``` Il y a cependant des limitations pour les [cartes graphiques](http://wiki.xen.org/xenwiki/XenVGAPassthrough) : seuls les hôtes complètement virtualisés peuvent utiliser la carte graphique de l’hôte, c’est‐à‐dire que les machines para‐virtualisées n’y ont pas accès. En outre, seule la carte principale, c’est‐à‐dire celle utilisée au démarrage de l’hôte, peut être exposée à l’invité ; il n’est pas possible, pour l’instant, de démarrer sur une carte et d’exposer une autre carte à la machine virtuelle. ##ptrace() Des nouvelles options ont été ajoutées à `ptrace()`, l’appel système qui permet d’insérer des sondes afin de superviser l’activité du noyau : - **PTRACE_SEIZE** s’utilise à la place de `PTRACE_ATTACH` et permet, contrairement à ce dernier, d’éviter la génération d’un signal `SIGSTOP` lors de l’appel à `ptrace()`, afin de ne pas perturber les signaux et états de contrôle de tâche ; - **PTRACE_INTERRUPT** s’utilise conjointement à `PTRACE_SEIZE` et permet de capturer un événement _ptracee_ sans envoyer de signal, afin de n’avoir aucun effet de bord sur les signaux et états de contrôles de tâche ; - **PTRACE_LISTEN** permet à _ptracer_ de surveiller l’état d’un groupe d’interruption sans que _tracee_ ne tourne. L’utilisation de PTRACE\_INTERRUPT met _tracee_ en événement STOP, déclenchant ainsi le LISTEN et ensuite WAIT pour attendre le groupe d’événement STOP suivant. Ces commandes sont encore en développement, et le drapeau PTRACE_SEIZE_DEVEL doit être utilisé pour y avoir accès, afin d’être sûr que l’utilisateur sait que le comportement de ces commandes peut changer. ##KVM L’outil de virtualisation KVM intégré au sein du noyau 3.1 gagne plusieurs nouvelles fonctions. Il y a tout d’abord le support expérimental de la fonction [_vhost TX zero copy_](https://lkml.org/lkml/2011/7/17/97), qui réduit [la charge processeur de l’hôte](https://lwn.net/Articles/439531/) pour ce qui concerne la gestion du trafic réseau. On trouve également [la gestion du mode hyperviseur](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=de56a948b9182fbcf92cb8212f114de096c2d574) pour les processeurs IBM de type POWER 7, qui ont des instructions de virtualisation particulièrement sophistiquées. La gestion de la [technologie SMEP](http://linuxfr.org/news/le-noyau-linux-est-disponible-en-version%C2%A030#toc_22) a été ajouté dans KVM, et permet maintenant de protéger les systèmes invités. Enfin, KVM permet dans cette nouvelle version de lancer une instance à l’intérieur d’une autre instance (mode _« nested »_, c’est‐à‐dire imbrication des systèmes invités). Concrètement, cela revient à donner au premier système invité la possibilité d’utiliser les instructions VMX (_**V**irtual-**M**achine e**X**tensions_) pour lancer et contrôler un autre invité. Pour se lancer dans une telle émulation imbriquée, il faut passer le paramètre `« nested=1 »` au module _kvm-intel_ et se limiter à un système invité de type Linux 64 bits. La documentation ([présente sur _kernel.org_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=823e396558e509b7c3225cd76806f3d6643ff5f8)) décrit le _patch_ intégré dans le noyau 3.1, tandis que [le fichier PDF](http://www.usenix.org/events/osdi10/tech/full_papers/Ben-Yehuda.pdf) _« The Turtles Project »_ de la conférence _Usenix 2010_ explique plus en détails ce mécanisme. ##Write‐back Le développeur Wu Fengguang, employé par Intel, travaille depuis de nombreux mois sur l’amélioration du code de _write‐back_ du noyau Linux. Ce terme de _« write‐back »_ désigne simplement la procédure qui consiste à écrire réellement les données sur le périphérique de stockage (le _« backing device »_). Pour que ce soit efficace, il faudrait que le noyau connaisse précisément les capacités en bande passante du périphérique. Cela lui permettrait d’optimiser ses envois sans saturer les disques lents et sans laisser laisser mourir de faim les disques rapides. [Le _patch_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e98be2d599207c6b31e9bb340d52a231b2f3662d) que Wu Fengguang a écrit pour le nouveau noyau commence par postuler une bande passante moyenne de 100 Mio/s pour le périphérique de stockage. Le code permet ensuite d’adapter dynamiquement le flux des données à la bande passante réelle du périphérique. Cette adaptation se fait par incrément avec un examen toutes les 200 ms, ce qui permet d’obtenir la valeur de la bande passante (`write_bandwidth`) de façon réaliste. Il y a aussi un lissage statistique qui est effectué sur une période de trois secondes pour parer les inévitables fluctuations (`avg_write_bandwidth`). Grâce à ce travail de fond, le noyau Linux 3.1 est maintenant capable de bien mieux utiliser les différentes sortes de périphériques de stockage qui peuvent être disponibles sur une machine. ##SPARC T3 David Miller, mainteneur de la branche [SPARC](http://fr.wikipedia.org/wiki/SPARC) du noyau, a [reçu](http://article.gmane.org/gmane.linux.kernel/1172588) une nouvelle machine contenant un [processeur T3](http://en.wikipedia.org/wiki/SPARC_T3) pour faire joujou. Le résultat de ses efforts est un [_patch_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4ba991d3eb379fbaa22049e7002341e97a673685) incorporé dans le noyau 3.1 qui permet la prise en charge de cette nouvelle version du processeur. Selon David, le travail a été facilité par le fait que le processeur T3 est seulement une évolution des T2 / T2+, avec des ressources doublées (128 threads par puce) et un module cryptographique qui gère plus d’algorithmes. Il est probable que le travail à fournir pour gérer le récent [SPARC T4](http://en.wikipedia.org/wiki/SPARC_T4) sera plus conséquent, car l’architecture a beaucoup évolué dans cette nouvelle génération. ##Améliorations du VFS La couche VFS (_Virtual File System_) de Linux propose une interface commune pour tous les systèmes de fichiers, et permet de factoriser le code en mettant en commun certaines fonctions. Le noyau 3.1 apporte plusieurs améliorations dans cette couche particulièrement critique. Comme signalé dans le message accompagnant la version candidate RC-1, le code de gestion des listes de contrôle d’accès — les ACL (_Access Control Lists_) — a été sorti de tous les systèmes de fichiers, et une implémentation générique est maintenant intégrée dans le VFS. On y gagne un tout petit peu en vitesse (c’est toujours bon à prendre), mais l’avantage se situe surtout au niveau de la simplification et de la centralisation du code. Le [message de _commit_ du _patch_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4e34e719e457f2e031297175410fc0bd4016a085) explique bien que les systèmes de fichiers utilisent maintenant la fonction `« get_acl() »` pour récupérer les listes de contrôle d’accès auprès du VFS, alors qu’auparavant, il leur fallait faire eux‐mêmes la vérification via un appel à `« fetch_acl() »`. Parmi les nouveautés, on trouve également [l’ajout](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=982d816581eeeacfe5b2b7c6d47d13a157616eff) des drapeaux `SEEK_HOLE` et `SEEK_DATA` dans l’appel système `« lseek() »`. Ce dernier est utilisé pour permettre de commencer la lecture ou l’écriture dans un fichier à un endroit bien précis. Les nouveaux drapeaux `SEEK_HOLE` et `SEEK_DATA` sont utilisés pour trouver des zones remplies de zéros (c’est une fonction bien utile pour les logiciels de sauvegarde ou de gestion de fichiers). À noter, comme l’explique fort bien [cet article de LWN](https://lwn.net/Articles/440255/), que Linux ne fait ici que se rallier à la méthode utilisée dans Solaris, après avoir proposé un autre mécanisme, `FIEMAP`, qui est plus sophistiqué, mais aussi plus complexe à utiliser :> _Il semble que FIEMAP soit un outil puissant aux arêtes acérées donné aux applications alors qu’elles avaient juste besoin d’un couteau à beurre._ Enfin, dernière amélioration notable de la couche VFS présente dans ce noyau 3.1, on trouve une optimisation du mode d’accès aux [_inodes_](http://fr.wikipedia.org/wiki/Inode) qui permet de gagner un peu en performances. C’est Linus Torvalds lui‐même [qui s’est amusé](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3ddcd0569cd68f00f3beae9a7959b72918bb91f4) à optimiser ainsi l’accès à ces structures de données. On sait qu’il avait particulièrement apprécié le travail effectué par Nick Piggin sur la recherche des chemins d’accès (_pathname lookup_), qui a été intégré [dans le noyau 2.6.38](https://linuxfr.org/news/le-noyau-linux-est-disponible-en-version-2638#toc_11). Linus continue donc de creuser la question et son _patch_, qui implémente plusieurs micro‐caches, permet de gagner entre 1 et 2 % de performances sur un noyau compilé avec `« make -j »`. ##SLUB L’allocateur mémoire [SLUB](http://www.mjmwired.net/kernel/Documentation/vm/slub.txt) a été introduit dans le noyau Linux 2.6.22 pour constituer une alternative plus simple et plus extensible au traditionnel allocateur [SLAB](http://en.wikipedia.org/wiki/Kernel_slab). La firme SGI avait conçu l’allocateur SLUB car il lui permettait d’économiser énormément de mémoire sur ses machines massivement multi‐processeur, au prix de quelques pourcents de performances en moins. [Divers](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=881db7fb03a77af0bcd460fd1de1f4062d5c18fe) [_patches_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b789ef518b2a7231b0668c813f677cee528a9d3f) de Christoph Lameter qui ont été intégrés au noyau 3.1 visent à regagner ces points de performances en supprimant les verrous qui existaient encore dans le code de SLUB. Les noyaux précédents avaient été nettoyés de leurs verrous dans le code du chemin rapide (_fastpath_) et, cette fois, c’est le chemin lent (_slowpath_) qui est remis à neuf. David Rientjes, qui travaille pour Google, a effectué de nombreux tests pour comparer les deux versions de SLUB avant et après l’application des _patches_ de Christoph. Sur une machine AMD à 16 cœurs et 64 Gio de RAM, les performances augmentent de 2,3 % sur un banc d’essai _netperf_. Il est à noter que ce code sans verrous n’est actif que sur les architectures qui possèdent une instruction de type « [cmpxchg](http://en.wikipedia.org/wiki/Compare-and-swap) » (_compare and exchange_) et que le différentiel de performance avec SLAB n’est [pas encore tout à fait comblé](http://article.gmane.org/gmane.linux.kernel.mm/66500). ##Améliorations de BATMAN Le protocole réseau [B.A.T.M.A.N.](http://fr.wikipedia.org/wiki/B.A.T.M.A.N.) (_**B**etter **A**pproach **T**o **M**obile **A**d‐Hoc **N**etworking_) a été sérieusement amélioré dans cette version 3.1 du noyau Linux. Tout d’abord, la fonction d’annonce des clients, critique sur un réseau ad‐hoc, [a été refondue](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a73105b8d4c765d9ebfb664d0a66802127d8e4c7) pour le plus grand bénéfice de la latence et du taux de paquets perdus. Ensuite, le mécanisme d’itinérance ([_roaming_](http://fr.wikipedia.org/wiki/Roaming)) a lui aussi [été repensé](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cc47f66e6b9ec7e7d465f74739a6fc9844593894) pour éviter de perdre des paquets inutilement. Dorénavant, un paquet `ROAMING_ADVERTISEMENT` sera envoyé par le nouveau point d’accès en direction de l’ancien, et il contiendra l’adresse MAC du client. De cette façon, le trafic en direction de l’ancien nœud sera routé plus facilement et avec moins de pertes. ##Un FITRIM plus intelligent L’appel système FITRIM est entré [dans le noyau Linux 2.6.37](https://linuxfr.org/news/sortie-de-la-version-2637-du-noyau-linux#long2) afin de permettre d’informer le disque quand une page a été effacée par le système. Le TRIM c’est cette fonction indispensable sur les disques à base de mémoire Flash, car, dans ces périphériques, il est impossible d’effacer les pages mémoire et seuls les blocs sont effaçables. Dans le 2.6.37, l’appel FITRIM permettait au système de fichiers d’informer d’un seul coup le disque sur toutes les pages effacées (mode _« batch discard »_), au lieu de faire du TRIM à la volée. Dans le nouveau noyau 3.1, le développeur Tao Ma a écrit un [_patch_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3d56b8d2c74cc3f375ce332b3ac3519e009d79ee) qui améliore le fonctionnement de FITRIM. L’idée est que le système de fichiers (ext4 en l’occurrence) garde en mémoire les blocs pour lesquels il a déjà demandé un TRIM la fois précédente et qui n’ont pas été modifiés entre‐temps. Un appel ultérieur à FITRIM pourra ainsi se contenter d’agir sur les blocs vraiment modifiés, au lieu d’itérer bêtement sur tous les blocs. Lors de ses tests, Tao Ma a constaté un gain substantiel après la première passe de FITRIM : - **Sans le _patch_** : - 1er essai : 5,505 s, - 2e essai : 5,359 s, - 3e essai : 5,228 s ; - **Avec le _patch_** : - 1er essai : 5,625 s, - 2e essai : 0,002 s, - 3e essai : 0,002 s. ##Systèmes de fichiers Outre l’amélioration de FITRIM pour _ext4_, le noyau Linux 3.1 incorpore également plusieurs petites nouveautés qui concernent les autres systèmes de fichiers. On trouve ainsi [l’activation par défaut des barrières](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=00eacd66cd8ab5fff9df49aa3f261ad43d495434) sur _ext3_, ce qui permet de garantir encore mieux la cohérence du système de fichiers en cas de crash (mais au léger détriment de la vitesse). Pour BTRFS, c’est toute la technique de verrouillage de méta‐données [qui a été réécrite](https://github.com/torvalds/linux/commit/bd681513fa6f2ff29aa391f01e413a2d1c59fd77). On passe ainsi à des verrous de type « lecture‐écriture », ce qui, d’après Chris Mason, est nettement plus rapide pour des types d’accès qui sont majoritairement en lecture (_« dramatically faster »_, selon Chris Mason). Le système de fichiers [pNFS](http://www.pnfs.com/) (_parallel NFS_), qui permet d’utiliser une grappe (_cluster_) de serveurs de fichiers avec un serveur de méta‐données pour paralléliser les transferts, est maintenant [compatible IPv6](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c9895cb69b07a4b17d8fdae26667f9a9fba5183b). Enfin, le code Linux gérant le système de fichiers [HFS+](http://en.wikipedia.org/wiki/HFS_Plus) (utilisé sur les machines Apple) peut maintenant [gérer des volumes supérieurs à 2 Tio](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c6d5f5fa658f2569a7baaff5acda261a1316cee9). ##NFC entre dans le noyau La technique de communication en champ proche (NFC, pour [_Near Field Communication_](http://fr.wikipedia.org/wiki/Near_Field_Communication)) est maintenant pleinement intégrée dans le noyau. C’est une technologie sans fil à courte portée (maximum 10 cm) qui permet, par exemple, de payer avec sa carte à puce sans contact, ou bien d’échanger des informations, comme des cartes de visites, en approchant simplement deux téléphones portables. Le sous‐système NFC de Linux offre une [interface unifiée pour les pilotes NFC](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3e256b8f8dfa309a80b5dece388d85d9a9801a29), ainsi qu’[une interface basée sur des _sockets_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=23b7869c0fd08d73c9f83a2db88a13312d6198bb) (`NFC_SOCKPROTO_RAW`) pour les échanges avec l’espace utilisateur. La documentation incluse dans [ce _patch_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=14205aa21c8041d7e940ee9bcde87824dc00a08a) permet de mieux comprendre l’architecture choisie pour ce nouveau sous‐système NFC. ##LIO en version 4.1 Après [la grosse controverse](https://linuxfr.org/news/le-noyau-linux-est-disponible-en-version-2638#toc_14) ayant marqué l’entrée de l’infrastructure de Target iSCSI [LIO](http://linux-iscsi.org/wiki/Main_Page) dans le noyau 2.6.38, le code a été [mis à jour](https://lkml.org/lkml/2011/7/23/156) dans cette nouvelle version 3.1. Le correctif est gros (plus de 600 Kio) et il amène Linux au niveau de la version 4.1 de LIO. On trouve dans la liste des nouveautés : * une prise en charge accrue des codes d’opération de la [RFC 3720](http://www.ietf.org/rfc/rfc3720.txt) ; * la gestion d’IPv6 pour les « [_Target Portal Groups_](http://linux-iscsi.org/wiki/Target) » ; * la possibilité de gérer finement l’ordonnancement de chaque connexion iSCSI ; * l’accélération des calculs de parité [CRC32](http://fr.wikipedia.org/wiki/CRC32) grâce aux instructions [SSE 4](http://fr.wikipedia.org/wiki/SSE4) ; * enfin, on trouve la gestion de la norme [CHAP](http://fr.wikipedia.org/wiki/CHAP) (_Challenge Handshake Authentication Protocol_) qui est décrite dans la [RFC 1994](http://tools.ietf.org/html/rfc1994). Sur ce dernier point concernant l’authentification CHAP, il y a eu une petite dispute sur la LKML puisque James Bottomley, le mainteneur du sous‐système SCSI, aurait préféré que le travail soit fait en espace utilisateur. Il a même menacé de refuser tout bonnement le correctif — le « NACKer », en langage Linux. C’est alors que [Linus est intervenu](https://lkml.org/lkml/2011/7/23/116) en soulignant les inconvénients d’un programme vivant en espace utilisateur (une interface figée, des problèmes de compatibilité, un code plus lent, etc.). La décision a donc été prise d’intégrer CHAP au noyau, pour [la plus grande joie](https://lkml.org/lkml/2011/7/23/143) de Nicholas Bellinger, l’auteur du _patch_. ##Loop devices dynamiques Un « [_loop device_](http://en.wikipedia.org/wiki/Loop_device) », c’est un pseudo‐périphérique qui permet à un fichier contenant un système de fichiers (par exemple une image ISO) d’être monté comme si c’était un périphérique en mode bloc. La gestion de ces _loop devices_ est assez statique, puisqu’ils sont associés à un numéro (entre 0 et 7) et qu’il faut vérifier que le _loop device_ est bien libre avant de pouvoir l’utiliser. [Le _patch_ de Kay Sievers](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=770fe30a46a12b6fb6b63fbe1737654d28e84844) change la donne, puisque le noyau Linux 3.1 propose maintenant de gérer tout cela dynamiquement via `« /dev/loop-control »`. L’allocation, l’attachement et le détachement se font maintenant à la demande. ##Module de sécurité TOMOYO [TOMOYO](http://en.wikipedia.org/wiki/TOMOYO_Linux) fait partie des modules de sécurité disponibles dans Linux aux cotés de [[SELinux]], [[SMACK]] et [[AppArmor]]. Le [développement](http://tomoyo.sourceforge.jp/) est très actif, et la version 3.1 du noyau apporte son lot de nouveautés et d’améliorations. Tout d’abord, une interface d’audit [a été ajoutée](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=eadd99cc85347b4f9eb10122ac90032eb4971b02) pour enregistrer les événements et les demandes d’accès aux ressources du système. L’interface `« /sys/kernel/security/tomoyo/audit »` est maintenant utilisée par des outils en espace utilisateur, comme le démon [_tomoyo-auditd_](http://tomoyo.sourceforge.jp/2.4/man-pages/tomoyo-auditd.html.en), et ces enregistrements facilitent par la suite l’écriture des règles de sécurité (_domain policy_). [Depuis cette version](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=32997144fd9925fc4d506a16990a0c405f766526), le module TOMOYO permet également de [gérer les listes de contrôles d’accès](http://tomoyo.sourceforge.jp/2.4/chapter-11.html.en) ([ACL](http://fr.wikipedia.org/wiki/Access_Control_List#ACL_sur_les_fichiers)) pour spécifier plus finement les restrictions de droits sur les fichiers. On trouve aussi une [compatibilité renforcée](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=bd03a3e4c9a9df0c6b007045fa7fc8889111a478) avec les conteneurs du type [LXC](http://en.wikipedia.org/wiki/Lxc) par le biais de ce qu’on nomme des _« policy namespaces »_. Cela signifie simplement que TOMOYO est capable d’appliquer des politiques de sécurité différentes selon les conteneurs sans risque d’interférences (voir [la documentation](http://tomoyo.sourceforge.jp/2.4/chapter-13.html.en)). Enfin, pour éviter des prises de contrôle malveillantes dès l’étape du démarrage du sytème, la nouvelle version de TOMOYO permet d’avoir une [configuration complètement intégrée](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=efe836ab2b514ae7b59528af36d452978b42d266), sans avoir à la charger depuis l’extérieur de façon trop tardive. Pour cela, diverses options de configurations ont fait leur entrée dans le noyau 3.1, et il suffira de le construire avec l’option `« SECURITY_TOMOYO_OMIT_USERSPACE_LOADER »` pour profiter de cette protection supplémentaire. ##Gestion des blocs corrompus en RAID Le pilote `md` (pour _Multiple Devices_) est le pilote qui est chargé de la gestion du [[RAID]] logiciel dans le noyau Linux. Lorsqu’un disque reportait une erreur d’écriture, celui‐ci était immédiatement considéré comme défectueux, et donc inutilisable. Cependant, avec la montée en capacité des disques durs, les chances de tomber sur un secteur défectueux augmentent, et il en est de même pour les temps de reconstruction de la grappe. À cela peuvent aussi s’ajouter des erreurs de lecture lors de la récupération d’une donnée, ce qui, le plus souvent, ralentit le processus. Neil Brown a donc implémenté, via [plusieurs _patches_](http://thread.gmane.org/gmane.linux.raid/34708), une gestion des blocs corrompus en mode RAID. Une zone réservée de 4 Kio est donc maintenant présente sur chaque disque composant la grappe, afin de stocker la liste des blocs corrompus au fur et à mesure que le noyau les détecte. En cas d’erreur, cela évite de devoir déclarer que tout le disque est corrompu. On peut se contenter d’ajouter le bloc défaillant à la liste, pour ne plus s’en servir et continuer d’utiliser le reste du disque. La liste des secteurs défectueux est exposée à l’espace utilisateur par l’intermédiaire des [méta‐données RAID](http://www.mjmwired.net/kernel/Documentation/md.txt#79) dans leur version 1.x et du [[_sysfs_]] dans un dossier nommé _« badblocks »_. La nouvelle fonction est compatible avec les modes RAID 1, 4, 5, 6 et 10, mais elle exige un programme de gestion [`mdadm`](http://en.wikipedia.org/wiki/Mdadm) qui incorpore également les modifications ([la branche _devel-3.3_](http://article.gmane.org/gmane.linux.raid/34883) a été créée à cet effet par Neil Brown). ##Pilotes graphiques En ce qui concerne le pilote _Nouveau_, on note que le micro‐code (_firmware_) d’origine NVidia n’est plus nécessaire dans bien des cas. Auparavant, il fallait extraire le micro‐code du pilote propriétaire avant de pouvoir utiliser Nouveau sur les cartes Fermi. Après le travail de rétro‐ingénierie de Marcin Koscielnicki, [les _patches_ de Ben Skeggs](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0411de854898a2402cf4bd915bed7ec9a6b76f9a) remplacent ce micro‐code par un FμC (_Fermi microcontroller_) complètement libre, qui devrait fonctionner sur les cartes de type [NVC0, NVC1, NVC3, NVC4, NVC8, et NVCE](http://nouveau.freedesktop.org/wiki/CodeNames#NVC0). Pour le pilote Intel, on trouve essentiellement des changements sur l’architecture SandyBridge (et donc par extension le futur IvyBridge) : l’activation par défaut de la fonction de compression du _[[frame buffer]]_, le _patch_ permettant de [partager la mémoire cache de niveau 3](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a18711120764dd96ed2ee6a4d436c448542bad77) entre le CPU et le GPU (+ 20 % d’images par seconde dans OpenArena), [la gestion des variations de fréquence](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c70c0cebd1295a42fec75045b8a6b4419cedef3) du bus en anneau (_ring bus_), ce qui permet de garder une fréquence mémoire maximum quand le GPU est très sollicité et que le CPU est au repos. Le pilote Radeon apporte, pour les cartes de type _Evergreen_, [une gestion préliminaire](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=033b5650010652c069494df58424c4b98412fe3b) des fonctions de calcul via le GPU (_Compute Shader_). Enfin, toujours dans la branche « -staging », le pilote GMA500 (Poulsbo) [gère maintenant](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a897854c30903bc77d919fc303009d17c1548b08) les nouveaux [processeurs Medfield](http://en.wikipedia.org/wiki/Mobile_Internet_device#Medfield_platform_.282011.29), et Alan Cox continue [d’exterminer gaillardement](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0ad91794cc243a73b3fc952a8b0a044a7a5cdff9) les items de sa _« TODO list »_. ##JIT BPF sur PPC64 Dans le noyau précédent, le filtre _Berkeley Packet Filter_ [avait reçu un compilateur à la volée](https://linuxfr.org/news/le-noyau-linux-est-disponible-en-version%c2%a030#toc_14) (JIT) pour lui permettre d’accélérer le traitement des paquets réseau. Comme le JIT utilise du code assembleur, il faut évidemment une implémentation spécifique pour chaque architecture de processeur. Dans Linux 3.0, c’était l’architecture x86_64 qui avait inauguré le JIT de BPF, mais maintenant [le _patch_ de Matt Evans](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0ca87f05ba8bdc6791c14878464efc901ad71e99) ajoute la compatibilité [PPC64](http://en.wikipedia.org/wiki/PowerPC). Sur un noyau compilé avec l’option de construction `HAVE_BPF_JIT`, il vous suffira d’un simple `« echo 1> /proc/sys/net/core/bpf_jit_enable »`, pour profiter des joies ineffables qu’apporte un filtrage BPF optimisé. ##Wi‐Fi La version 3.1 du noyau Linux apporte, comme d’habitude, plusieurs changements au sein des pilotes Wi‐Fi. On trouve, par exemple, [un nettoyage](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=03f18fa16cd805916a56d027b4ee52ba26e6d6ab) des périphériques Wi‐Fi USB dans le pilote Realtek `rtl8192cu`, [la prise en charge](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=872834dfb38edc6f72cfc783a5ce78f2a9f36ec5) de nouvelles cartes dans le pilote Ralink `Rt2800`, ainsi que [l’activation par défaut](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0f93c79404e1eaa5207f6d8a7aea14119808d382) des cartes `rt35xx`. Du côté du pilote Intel `iwlagn`, c’est la [gestion de WoWLAN](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c8ac61cf6e53fefb3b439fc58390fb65d2730e63) qui est ajoutée, ainsi [qu’un module](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f7538168915271083070a60ebb10def11fce0cb0) permettant de spécifier le niveau d’économie d’énergie qui est souhaité. Enfin, comment ne pas parler de la controverse Broadcom qui a agité les listes de diffusion lors de ce cycle ? En septembre 2010, la firme Broadcom a libéré son pilote [`brcmsmac`](http://linuxwireless.org/en/users/Drivers/brcm80211), qui gère les cartes Wi‐Fi de type `BCM43x`. Le pilote n’étant pas au niveau de qualité souhaité par les développeurs Linux, il a rejoint la branche « -staging » pour qu’il puisse être amélioré. Là se situe le nœud du problème, puisqu’il existait déjà un pilote libre, nommé « [`b43`](http://linuxwireless.org/en/users/Drivers/b43) » et incorporé dans le noyau Linux. Les développeurs Broadcom ont travaillé pendant un an pour répondre aux objections des _hackers_ du noyau et, à l’issue de ce marathon, ils ont demandé à ce que le pilote `brcmsmac` sorte de « -staging » et rejoigne la cour des grands. C’est alors que Rafal Milecki, mainteneur de `b43`, a signalé que cela allait faire doublon avec son pilote à lui. Depuis, c’est la foire d’empoigne et chaque camp reste campé sur ses positions. Les développeurs Broadcom se sentent trahis et craignent d’avoir travaillé un an pour rien, avec un pilote qui ne sera jamais sorti de « -staging ». Rafal et ses partisans soulignent qu’il aurait été bien plus efficace qu’ils améliorent b43, au lieu d’arriver comme des _cow‐boys_ avec leur solution à eux qui ne tient pas compte de l’existant. Le site LWN a, comme toujours, remarquablement résumé les débats dans deux articles fouillés ([1](https://lwn.net/Articles/456762/) - [2](https://lwn.net/Articles/457674/)). En définitive, il est probable que Broadcom ait définitivement perdu la main, car l’un de ses développeurs a fait une gaffe rédhibitoire lors des débats. Il a en effet laissé échapper que son employeur ne pouvait pas travailler sur `b43` et voulait absolument l’inclusion de `brcmsmac`, car ce pilote était _« aligné architecturalement sur les pilotes présents dans d’autres systèmes d’exploitation »_. En clair, cela signifie que le pilote `brcmsmac` n’est pas vraiment un pilote Linux, puisque les décisions sur son architecture dépendent d’un cœur multi‐plate‐forme devant tourner sur d’autres systèmes d’exploitation. Les développeurs du monde libre n’aiment pas dépendre ainsi d’une firme qui sera seule à pouvoir maintenir son pilote et qui prendra ses décisions selon des critères opaques. ##Divemaster ou 3.1 ou 2.6 ? Tout content d’avoir [réussi son examen de moniteur de plongée](https://plus.google.com/102150693225130002912/posts/QNVERmkygJc), Linus Torvalds a décidé de [changer une nouvelle fois](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c) le nom de code du noyau. La version 3.1 de Linux sera donc connue sous le nom de _« Divemaster Edition »_, pour fêter ce succès. À noter que Linus a également mis à profit la période de fermeture du site _kernel.org_, pour écrire un programme d’enregistrement de ses plongées sous‐marines. Il n’est pas certain que [Subsurface](https://plus.google.com/102150693225130002912/posts/Cepr6Gy3zps) rencontrera le même succès que Git ou Linux, mais son géniteur se préoccupe peu de ce genre de choses. Dans le plus pur esprit _« scratch your own itch »_, ce qui compte, c’est qu’il ne soit plus obligé d’utiliser les programmes du commerce complètement pourris. Le fichier [README présent sur GitHub](https://github.com/torvalds/subsurface/blob/master/README) mérite vraiment la lecture, avec son introduction toute en souplesse : _« I’m tired of Java programs that don’t work »._ ;-) Plus sérieusement, Andi Kleen est lui aussi préoccupé par les questions de nommage. Il a implémenté une nouvelle [personnalité](http://linux.about.com/library/cmd/blcmdl2_personality.htm) pour le noyau. Son _patch_ [crée](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=be27425dcc516fd08245b047ea57f83b8f6f0903) la personnalité `UNAME26`, dont la fonction consiste à faire croire aux programmes qu’ils tournent sur une version du type 2.6.x, au lieu de la nouvelle version 3.x. Bien entendu, ce n’est pas très beau ni élégant de « tricher » ainsi avec le numéro de version du noyau, et la vraie solution consisterait à corriger les programmes idiots qui exigent un « 2 » au début du numéro de version de Linux. Malheureusement, ce n’est pas toujours possible. Andi cite dans son message de _commit_ les outils d’administration serveur de HP (`hpacucli`, pour _HP Array Configuration Utility CLI_) qui refusent de s’exécuter en présence d’un noyau 3.x. Si vous devez absolument utiliser ce genre de logiciels, alors la personnalité `UNAME26` pourra peut‐être vous sauver la mise. #Statistiques Du côté des statistiques de ce cycle, le site [LWN](http://lwn.net/ "Linux Weekly News") a publié [l’article récapitulatif](https://lwn.net/Articles/460597/) pour le noyau 3.1. Bien évidemment, ce qui caractérise ce cycle, c’est l’interruption de service ayant affecté _kernel.org_ à la suite de [sa compromission](https://linuxfr.org/news/les-serveurs-de-kernelorg-ont-%c3%a9t%c3%a9-compromis). Du fait de la nature distribuée du développement sous Git, les conséquences ont été réduites et le travail a pu continuer ailleurs (sur le [dépôt GitHub](https://github.com/torvalds/linux) ouvert par Linus). Il n’empêche que le cycle du noyau 3.1 a été particulièrement réduit, avec seulement 8 465 patches intégrés au moment de la septième version candidate (pour un gain net de 125 000 lignes de code). Ces _patches_ émanent de 1 136 développeurs appartenant à 180 sociétés différentes. À la première place, on retrouve Takashi Iwai, le mainteneur du sous‐système audio, qui a posté 140 patches visant à améliorer ou restructurer les divers pilotes audio du noyau. Greg Kroah‐Hartman a passé en revue les pilotes dans la branche « -staging », qui n’avaient pas été améliorés ni maintenus depuis plusieurs cycles, et il a décidé de les supprimer. Le noyau Linux 3.1 est ainsi débarrassé de tout le code se trouvant sous `« drivers/staging/tty »`, `« drivers/staging/msm »`, `« drivers/staging/westbridge »` et `« drivers/staging/generic_serial »`, ce qui représente la bagatelle de 121 500 lignes de code ! Bien entendu, cela lui vaut la première place de ce cycle en termes de lignes de code modifiées. #Pour la suite ##Native Linux KVM tool KVM apporte la gestion de la virtualisation native au noyau Linux. Cependant, celui‐ci ne virtualise que le processeur et l’accès à la mémoire, or un système a besoin de beaucoup plus pour fonctionner. C’est pourquoi KVM est couplé à [[QEMU]], qui permet de virtualiser le matériel restant. Malheureusement, QEMU ne fait pas l’unanimité au sein des développeurs, certains trouvant son code trop complexe à comprendre et à maintenir, tandis que KVM, en étant un projet récent, possède un code bien plus clair. L’idée est donc d’étendre KVM, afin de lui permettre d’exécuter un système Linux de façon autonome. C’est ainsi qu’est né, à l’initiative de Pekka Enberg, le projet [_Native Linux KVM tool_](https://lkml.org/lkml/2011/3/31/406), qui permet de lancer le système Linux dans un environnement émulé minimal, en fournissant un accès au système via une liaison série. Le code actuel est propre, mais il est aussi très simple (seulement 5 000 lignes de C). En présentant son nouveau bébé, Pekka a fait preuve d’un humour dont se délecteront les initiés : _« Just a hobby, won’t be big and professional like QEMU! »_ Le but affiché pour l’instant n’est pas de concurrencer QEMU, et les cas d’utilisation restent encore flous, même si le projet suscite de l’intérêt. [Linus a donc décidé d’attendre](https://lkml.org/lkml/2011/7/27/397) que la mayonnaise prenne avant une éventuelle inclusion.

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