Sortie du noyau Linux 3.1

Le commit marquant la sortie de la version stable 3.1 du noyau Linux vient d’être effectué par Linus Torvalds lors du sommet de Prague.
Les sources de ce nouveau noyau sont téléchargeables sur les serveurs du site kernel.org et le message d’annonce de Linus est lisible ici.

Cette version a été marquée par la détection d’une intrusion sur kernel.org et le passage provisoire à GitHub des sources de la branche de Linus. On peut également relever une proposition humoristique de changement ponctuel de logo (comme c’était le cas pour la version 2.6.29, voir la dépêche et le journal à 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).

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 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.

Sommaire

• La phase de test
  • • RC-1
    • RC-2
    • RC-3
    • RC-4
    • RC-5
    • RC-6
    • RC-7
    • RC-8
    • RC-9
    • RC-10
• Les nouveautés
  • OpenRISC
  • Nouvel outil cpupower
  • Xen
  • ptrace()
  • KVM
  • Write‐back
  • SPARC T3
  • Améliorations du VFS
  • SLUB
  • Améliorations de BATMAN
  • Un FITRIM plus intelligent
  • Systèmes de fichiers
  • NFC entre dans le noyau
  • LIO en version 4.1
  • Loop devices dynamiques
  • Module de sécurité TOMOYO
  • Gestion des blocs corrompus en RAID
  • Pilotes graphiques
  • JIT BPF sur PPC64
  • Wi‐Fi
  • Divemaster ou 3.1 ou 2.6 ?
• Statistiques
• Pour la suite
  • Native Linux KVM tool

La phase de test

RC-1

La version RC-1 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 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 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 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 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 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 (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 :

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 :

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 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 :

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 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 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 — (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 est sortie le 27 septembre :

« Autre semaine, autre RC sur :

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 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 — 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 :

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 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 le 18 octobre (le 17, pour lui) :

« Ok, nous sommes à une semaine du Kernel Summit, 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, issue de la communauté 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 », c’est‐à‐dire des unités logiques réutilisables. Ces dernières sont décrites dans un langage spécial adapté au matériel du type Verilog ou VHDL.

Divers projets sont en cours 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 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 tandis que la première implémentation de l’OpenRISC Reference Platform System‐on‐Chip et de son cœur OpenRISC 1200 est disponible sur circuit programmable FPGA en tant que softcore. La page 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, c’est‐à‐dire au circuit intégré classique. Selon les membres du projet :

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 ou Dynalith Systems.

Dans son annonce sur la LKML, 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). Cette nouvelle architecture est maintenant présente 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 ou LEON).
Le problème de tous ces projets est, bien entendu, la production des puces. La page de 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 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 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 ou encore AMD Cool’n’Quiet), 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 » (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) 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 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 à 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 :

xm pci-attach <guest> <pci device> <guest virtual slot number>

Il y a cependant des limitations pour les cartes graphiques : 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, qui réduit la charge processeur de l’hôte pour ce qui concerne la gestion du trafic réseau.
On trouve également la gestion du mode hyperviseur pour les processeurs IBM de type POWER 7, qui ont des instructions de virtualisation particulièrement sophistiquées. La gestion de la technologie SMEP 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 (Virtual-Machine 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) décrit le patch intégré dans le noyau 3.1, tandis que le fichier 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 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 du noyau, a reçu une nouvelle machine contenant un processeur T3 pour faire joujou. Le résultat de ses efforts est un patch 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 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 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 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, 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 qui permet de gagner un peu en performances.
C’est Linus Torvalds lui‐même qui s’est amusé à 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. 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 a été introduit dans le noyau Linux 2.6.22 pour constituer une alternative plus simple et plus extensible au traditionnel allocateur 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 patches 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 » (compare and exchange) et que le différentiel de performance avec SLAB n’est pas encore tout à fait comblé.

Améliorations de BATMAN

Le protocole réseau B.A.T.M.A.N. (Better Approach To Mobile Ad‐Hoc Networking) 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 pour le plus grand bénéfice de la latence et du taux de paquets perdus. Ensuite, le mécanisme d’itinérance (roaming) a lui aussi été repensé 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 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 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 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. 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 (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.
Enfin, le code Linux gérant le système de fichiers HFS+ (utilisé sur les machines Apple) peut maintenant gérer des volumes supérieurs à 2 Tio.

NFC entre dans le noyau

La technique de communication en champ proche (NFC, pour 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, ainsi qu’une interface basée sur des sockets (NFC_SOCKPROTO_RAW) pour les échanges avec l’espace utilisateur. La documentation incluse dans ce patch permet de mieux comprendre l’architecture choisie pour ce nouveau sous‐système NFC.

LIO en version 4.1

Après la grosse controverse ayant marqué l’entrée de l’infrastructure de Target iSCSI LIO dans le noyau 2.6.38, le code a été mis à jour 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 ;
• la gestion d’IPv6 pour les « Target Portal Groups » ;
• la possibilité de gérer finement l’ordonnancement de chaque connexion iSCSI ;
• l’accélération des calculs de parité CRC32 grâce aux instructions SSE 4 ;
• enfin, on trouve la gestion de la norme CHAP (Challenge Handshake Authentication Protocol) qui est décrite dans la RFC 1994.

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 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 de Nicholas Bellinger, l’auteur du patch.

Loop devices dynamiques

Un « 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 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 fait partie des modules de sécurité disponibles dans Linux aux cotés de SELinux, SMACK et AppArmor. Le développement 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 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, et ces enregistrements facilitent par la suite l’écriture des règles de sécurité (domain policy).
Depuis cette version, le module TOMOYO permet également de gérer les listes de contrôles d’accès (ACL) pour spécifier plus finement les restrictions de droits sur les fichiers.
On trouve aussi une compatibilité renforcée avec les conteneurs du type 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).
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, 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, 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 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 qui incorpore également les modifications (la branche devel-3.3 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 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.

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 entre le CPU et le GPU (+ 20 % d’images par seconde dans OpenArena), la gestion des variations de fréquence 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 des fonctions de calcul via le GPU (Compute Shader).
Enfin, toujours dans la branche « -staging », le pilote GMA500 (Poulsbo) gère maintenant les nouveaux processeurs Medfield, et Alan Cox continue d’exterminer gaillardement 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 (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 ajoute la compatibilité PPC64.
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 des périphériques Wi‐Fi USB dans le pilote Realtek rtl8192cu, la prise en charge de nouvelles cartes dans le pilote Ralink Rt2800, ainsi que l’activation par défaut des cartes rt35xx. Du côté du pilote Intel iwlagn, c’est la gestion de WoWLAN qui est ajoutée, ainsi qu’un module 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, 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 » 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 - 2).
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, Linus Torvalds a décidé de changer une nouvelle fois 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 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 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é pour le noyau. Son patch crée 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 a publié l’article récapitulatif 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. 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 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, 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 que la mayonnaise prenne avant une éventuelle inclusion.

Aller plus loin

• [LWN 1] Les nouveautés du noyau 3.1 (1058 clics)
• [LWN 2] Les nouveautés du noyau 3.1 (447 clics)
• Les articles récapitulatifs de h-online.com (114 clics)
• La liste des nouveautés sur kernelnewbies (405 clics)