Sortie officielle du noyau Linux 3.4

La sortie de la version stable 3.4 du noyau Linux vient d'être annoncée par Linus Torvalds. Le nouveau noyau est, comme d'habitude, téléchargeable sur les serveurs du site kernel.org.

Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche.

PS. : Merci à toutes les personnes qui ont aidé à traduire les courriels de RC quand cette dépêche était dans l'espace de rédaction: laurent wandrebeck, detail_pratique, khalahan, _PhiX_, Damien Szczyt, Akiel et Benoît.

Sommaire

• La phase de test
  • RC-1
  • RC-2
  • RC-3
  • RC-4
  • RC-5
  • RC-6
  • RC-7
• Les nouveautés
  • Architecture x32
  • dm-verity
  • Nouveautés pour l'architecture ARM
  • YAMA
• En bref
  • Maturation de btrfs
  • Simplifications dans ext4
  • fadump pour PowerPC
  • UFS dans le noyau
  • Camellia et CRC32
  • Discard pour « thin provisioning »
  • IRQ domains
  • Pilote virtio-scsi
  • Du côté de -staging
  • Pilote graphique Nouveau
  • Les autres pilotes graphiques
  • HSI
  • Sous‐système remoteproc
  • Chargement retardé des pilotes
  • Améliorations dans Perf
• Statistiques

La phase de test

RC-1

La version RC-1 a été annoncée par Linus le 31 mars 2012 :

Ok, cela fait deux semaines et la période de merge est terminée. Linux 3.4-rc1 a été envoyé vers les serveurs git, et l'archive tar ainsi que les patches sont en cours d'envoi alors que je tape ceci (cela sera probablement terminé le temps que je finisse).
Et oui, si vous avez compté, cela ne fait que 13 jours. Et si certains attendaient le dernier jour pour envoyer leur demande de merge, je suis persuadé qu'ils seront vraiment ravis d'attendre deux mois supplémentaires jusqu'à la prochaine fenêtre d'intégration. Yay !

Cela dit, il y a encore quatre demandes de merge dans ma boîte mail qui sont en attente et que je vais (probablement) inclure, mais je voulais d'abord obtenir confirmation d'autres mainteneurs. Elles ont donc été envoyées dans les temps, j'ai juste décidé de faire le choix de leur intégration un peu plus tard.
Les quatre requêtes restantes (et les gens dont je veux des commentaires) sont :

- HSI (High Speed Synchronous Serial Interface). Je prévois de l'inclure dans le 3.4, c'est dans ma liste, mais je voulais que ça se sache au cas où quelqu'un aurait des problèmes avec cette dernière. Ping ?
- pohmelfs. Le vieux pohmelfs a été supprimé de staging ; il y en a un tout nouveau en attente sur le banc de touche. Al était un peu mécontent de certains aspects, Evgeniy en a corrigé certains, et la discussion s'est tarie. À nouveau, il y a des chances que je l'incorpore, mais je voulais davantage de commentaires à ce propos.
- La prise en charge préliminaire de drm dma-buf. Dave Airlie m'a envoyé la demande d'incorporation mais n'a pas beaucoup insisté, c'est dans ma catégorie « ok, je peux encore l'inclure pour 3.4 si les gens des pilotes DRM me disent que ça leur facilitera la vie. » C'est donc dans le flou — je n'ai rien contre, mais je ne l'inclurai pas à moins que quelques personnes me disent « oui, s'il te plaît. »
- Le framework DMA-mapping. Ce code a dorénavant quelques confirmations supplémentaires, et se trouve essentiellement dans la même situation que HSI : je l'incorporerai probablement, mais je voulais vraiment avoir l'avis des personnes concernées.

Et c'est tout. Il y a donc quatre demandes d'inclusion en attente, mais à part ça, c'est terminé (à moins que vous ne puissiez démontrer m'avoir envoyé un mail, mais qu'à cause d'une erreur cosmique — impliquant probablement mon incompétence — je l'ai manqué. Hé, ça arrive).
Quoi qu'il en soit, assez parlé de « ce qui reste en attente ». Si vous voulez savoir ce qui a été incorporé, une approche assez lisible est la suivante :

git log --merges --author=Torvalds v3.3..

Parce que j'ai vraiment essayé de faire des messages compréhensibles, avec des informations venant des sous-mainteneurs. Et beaucoup d'entre vous m'en ont envoyé, merci.
Un point important à signaler est que le nettoyage des fichiers d'en-têtes était un truc à faire, mais j'espère qu'on n'aura plus à le refaire. En tout cas, pas avant une version ou deux. Ce nettoyage a provoqué beaucoup de conflits de merge et quelques autres ennuis et, bien que je sois OK pour les résoudre, c'était suffisamment pénible pour que je ne veuille pas recommencer de sitôt. Je sais que des sous-mainteneurs ont eux aussi été embêtés et s'en sont plaint auprès de moi.
Cela dit, je pense que c'était utile. Le découpage de asm/system.h (et à plus petite échelle les nettoyages de bug.h) a peut-être été douloureux, mais les choses sont vraiment plus propres. Je devine donc que nous ferons à nouveau ce genre de chose dans le futur, mais je veux juste oublier à quel point c'est pénible d'ici à la prochaine fois. Ok ?

Dans tous les cas, merci de tester et rapporter toutes régressions.

RC-2

La seconde version candidate du noyau est sortie le 7 avril 2012 :

Une autre semaine, une autre -rc. Cela m'a semblé plutôt calme, mais à en croire les chiffres, c'est une -rc2 assez typique, peut-être même avec un peu plus de modifications qu'à l'accoutumée.

Cela dit, il n'a pas l'air d'y avoir beaucoup de choses effrayantes. Une bonne partie des changements sont des correctifs (que j'espère quasi-finaux) pour les modifications des fichiers d'en-têtes, ainsi que les trois demandes d'inclusion mentionnées dans l'annonce de la -rc1 : HSI (High Speed Synchronous Serial Interface, les bases de dma-buf, et ce qui concerne DMA mapping. Ces trois-là ont été soutenues par plusieurs personnes braillant un « vas-y, envoie ». Pohmelfs n'a pas été mergé, pour la simple raison que personne ne l'a demandé.

En dehors des correctifs sur les fichiers d'en-têtes et les 3 incorporations retardées, il n'y a que les correctifs habituels. Je serai plus strict en ce qui concerne les inclusions à partir de maintenant car il y a eu beaucoup de « bruit » et pas uniquement des corrections. J'en suis en partie responsable : une série de modifications d'Eric Paris visant à grandement améliorer l'usage de la pile dans le contexte SElinux.
La plupart des changements concernent quelques architectures (arm, tile, powerpc, x86) et les pilotes (particulièrement le réseau, mais aussi regulator, drm et mmc), ainsi que quelques mises à jour sur la gestion de l'énergie.

J'espère que la -rc3 aura un résumé carrément plus court.

RC-3

C'est le 15 avril que la version RC-3 a été annoncée par Linus :

Bon, ça fait donc huit jours depuis la -rc2, principalement parce que j'ai passé du temps à courir après deux bugs que je pouvais reproduire plutôt que de rendre cette version disponible hier. L'un était un oops dans la couche de gestion d'erreur scsi, et l'autre un plantage étrange sur x86-32. Bug introduit par mes soins. Oops.

Enfin bref, un jour de retard, mais nous sommes maintenant plus stables du fait de la correction de ces problèmes dans la -rc3. Les deux étaient suffisamment obscurs pour ne pas toucher grand monde, mais je déteste annoncer des versions candidates avec des problèmes que je peux reproduire personnellement.

Ceci dit, je ne pense pas qu'il y ait grand chose de bien excitant dedans. Il s'agit principalement de mises à jour de pilotes, avec une poignée de correctifs d'architecture et de réseau. Les statistiques de modifications sont assez barbantes, exception faite de la mise à jour du pilote mtip32xx et d'un changement trivial dans kyrofb (remplacement des unsigned long par u32, afin que ça fonctionne correctement en 64 bits) — cette RC se résume en gros par un bon nombre de simples remplacements.

Et des statistiques barbantes sont une bonne nouvelle. Cela signifie simplement « beaucoup de petits trucs ». Je l'admets, cela aurait été encore mieux si cela avait été « à peine quelques petits trucs », mais nous sommes raisonnablement tôt dans la séquence des versions candidates, je ne m'inquiète donc pas trop.

RC-4

La version RC-4 est disponible depuis le 21 avril :

Tout semblait calme depuis un moment, mais ça a changé hier. Je pense que soit les gens envoient leurs requêtes juste avant que je ne rende disponible les -rc, soit c'est un problème de gens qui travaillent de lundi à vendredi et qui finissent la semaine en m'envoyant leurs requêtes.
Peu importe le pourquoi, cela signifie que mon « oh, les choses se calment » de jeudi s'est transformé en « Uhhuh, en fait pas encore » le vendredi, quand plus de la moitié des modifications de cette -rc ont débarqué.

Ceci étant dit, même avec la pointe du vendredi, je pense que les choses ont tout de même été assez calmes. Nous avons eu quelques modifications annulées et un peu de nettoyage, mais la majorité sont des petits correctifs triviaux. Presque tous se situent dans les pilotes, avec quelques mises-à-jour du côté des systèmes de fichiers (la plupart étant des corrections de boutisme venant de Al) qui se sont glissées. Le traditionnel (sans renommage) fichier de différence est dominé par le déplacement du logo de démarrage m68k, mais nous utilisons tous les fichiers de différence de Git maintenant, n'est-ce pas ? Auquel cas, c'est 50% de pilotes (usb, mfd, xen, mmc, gpu, media…), 20% archi, 15% fs et une poignée de trucs ici et là.

Mais rien de tout cela n'a vraiment l'air effrayant. Il semble que la sortie de la 3.4 soit dans les clous, mais n'hésitez pas à brailler si vous repérez des régressions.

Je serai sans connexion pendant quelques jours (classe de plongée sous-marine, etc.), mais si le modèle « les gens m'envoient leurs trucs le vendredi » se vérifie, je parie que cela ne changera rien pour personne. D'autant que j'aurai mon portable et mon environnement de travail, donc si un truc surgit, tout se passera bien. Je ne suis simplement pas autant en ligne que d'habitude.

RC-5

Huit jours après la RC-4, Linus a annoncé sur la liste de diffusion la sortie de la version RC-5 :

À nouvelle semaine, nouvelle -rc. Techniquement ça fait 8 jours — j'ai retardé la sortie d'une journée dans l'attente de quelques tests.
Tout comme la -rc4, une bonne partie des modifications sont arrivées vendredi (et quelques autres hier). Et cela ne s'est pas calmé, au contraire. -rc5 a presque 50% de modifications en plus que n'en avait -rc4. Ce n'est pas bon.

Ceci étant dit, je ne pense pas qu'il y ait quoi que ce soit de très effrayant là-dedans. C'est ennuyeux, certes (je hais vraiment les vilains problèmes d'ABI d'autofs avec lesquels je me suis battu ces derniers jours, par exemple), et j'aurais préféré que les choses fussent plus calmes, mais la plupart des changements sont assez petits et triviaux. C'est réparti de manière assez équitable : 50% de pilotes, 20% d'architecture, 15% de systèmes de fichiers (principalement btrfs et nfs), 5% de réseau, ainsi que du bruit aléatoire.

RC-6

La grande nouvelle de la journée du 6 mai 2012 a bien évidemment été l'annonce de la version RC-6 par Linus :

Une nouvelle semaine, une nouvelle -rc — et je pense que nous sommes proches de la 3.4 finale. Merci donc de tester.

Il y a toujours plus de modifications que je ne le voudrais — et j'apprécierais que les choses se calment davantage encore, mais globalement les changements restent petits et simples.
Environ la moitié des modifications sont dans les pilotes (et la partie réseau représente presque la moitié de ça), le reste provenant principalement de arch (PowerPC et ARM), système de fichiers (Btrfs et NFS), ainsi que du réseau (hors pilotes).
Mais tous les changements semblent vraiment triviaux, donc, au final, je le sens plutôt bien.

En avant pour les tests.

RC-7

Enfin la dernière version candidate a été annoncé 12 mai 2012 :

C'est quasi certainement la dernière -rc de cette série : les choses se sont vraiment calmées, et j'ai même envisagé de rendre disponible le 3.4 en cette fin de semaine, pour finalement conclure qu'une semaine de plus ne pouvait pas faire de mal.

Le résumé des modifications donne une bonne vision d'ensemble : il s'agit principalement de petites corrections ici et là pour des petits problèmes très précis. La plus grosse modification (et celle qui touchera probablement le plus de gens) est le changement i2c de Nouveau — il s'agit de la suppression de la dernière modification. Les routines i2c spécifiques ayant leurs propres problèmes et les routines génériques i2c-algo-bit ayant été corrigées, Nouveau utilise maintenant les génériques.
Le reste est principalement constitué de petites modifications dans diverses zones : pilotes (réseau, DRM, SCSI, son et md), mises à jour d'archi (ARM, PowerPC et x86) et divers autres endroits : cœur du réseau, un correctif de compatibilité, des choses comme ça. Rien d'effrayant.

Alors lancez‐vous et testez. Et ne m'envoyez aucune demande d'inclusion à moins qu'elle ne contienne que des correctifs pour de très vilains bogues. Je ne veux plus de ces stupides correctifs pour supprimer des warnings du compilateur, etc.

En plus de cette annonce sur la LKML, Linus a décidé, comme il le fait régulièrement, de poster un petit texte sur son compte Google+, afin d’inciter les gens à tester cette dernière version candidate :

Dernière -rc avant la sortie de 3.4 ! Dépêchez-vous avant épuisement des stocks !
Du fait de l'édition limitée de 3.4-rc7, et si vous voulez que votre maman soit fière de vous demain, vous feriez bien de vous dépêcher. Et si vous êtes une maman, montrez à vos enfants que vous êtes exceptionnelle, car vos machines n'utilisent que le plus récent et le meilleur.
Parce que vous le valez bien.

Et si vous êtes un développeur, rendez-nous tous fiers en n'envoyant pas davantage de « correctifs des warnings du compilateur » ou autres modifications sans intérêt. Si vous m'envoyez une demande d'inclusion ou un patch destiné à la version finale de 3.4, il vaudrait mieux que cela concerne une regression majeure, un oops ou un correctif de sécurité.
Compris ?

Les nouveautés

Architecture x32

Aux côtés de ses cousines x86 et x86-64, la nouvelle architecture x32 fait son entrée dans le nouveau noyau Linux 3.4.

On sait que l’architecture x86-64 est une modernisation profonde de la vénérable architecture x86. Les registres généraux passent de 32 bits à 64 bits et leur nombre double (16 registres au lieu de 8). La mémoire virtuelle n’est plus limitée à 4 Gio, le bit NX est implémenté.  L’appel système SYSCALL64 est très rapide et les instructions vectorielles disponibles sont au moins au niveau du SSE2.
Toutes ces nouveautés, et le fait que sa prise en charge est désormais mature, font qu’il est de nos jours presque absurde d’utiliser une distribution en mode x86.

Néanmoins, certains développeurs sont d’avis que l’architecture x86 garde quelques avantages. Par exemple, le fait de se limiter à 32 bits signifie que les pointeurs mémoires sont plus petits et induisent donc moins de pression sur les mémoires caches du processeur. C’est un point important, notamment pour l’embarqué, car le bon fonctionnement du cache est absolument crucial pour les performances du processeur.
C’est quand même dommage de devoir choisir entre les indispensables 16 registres de x86-64 et l’empreinte mémoire réduite de x86. Serait‐il possible de créer une nouvelle variante qui ne retiendrait que les meilleurs aspects de ces deux architectures ?

C’est précisément le but qu’avait en tête H. Peter Anvin quand il a posté sur la LKML les patches proposant l’architecture x32.
Les programmes compilés avec l’ABI x32 tourneront donc en profitant à plein des 16 registres 64 bits (comme sous x86-64) mais leurs pointeurs mémoires seront limités à 32 bits (comme sous x86). Bien entendu, ces programmes seront limités à un espace d’adressage de 32 bits (4 Gio), mais cela ne constitue pas vraiment un obstacle pour la plupart d’entre eux, en particulier dans l’embarqué.

D’après les premiers tests, postés sur le site spécialement dédié à x32, les performances semblent encourageantes.
Le test 181.mcf du banc d’essais SPEC CPU2000 a été utilisé car il est extrêmement dépendant de la mémoire, et il profite à fond d’une réduction de la pression sur le cache. Selon ce test, effectué sur un processeur Core i7, on obtient un gain de vitesse d’environ 32 % par rapport au mode x86-64. Comme prévu les performances sont très proches de celles de x86 (moins d’1 % d’écart).
Le gain induit par les pointeurs mémoire 32 bits est donc bien visible.

Si l’on regarde le test 186.crafty, on devrait cette fois mettre en évidence le gain induit par l’utilisation des 16 registres 64 bits, puisque ce test est très dépendant du processeur. Là encore, la nouvelle architecture tient ses promesses, puisque l’architecture x32 n’est que 5 % plus lente que x86-64, mais qu’elle enregistre un gain de 29 % par rapport à x86.

Les patches de H. Peter Anvin ont été assez bien accueillis sur la liste de diffusion du noyau, mais Linus a quand même grogné sur un point précis. À l’origine, les valeurs relatives à la gestion du temps (time_t, off_t ou timeval) devaient être en 32 bits, ce qui impliquait que l’architecture x32 serait soumise au bogue de l’an 2038 (débordement du nombre de secondes entre 1970, l’origine du temps UNIX, et l’année 2038).
Linus a été prompt à envoyer un Scud en soulignant que ce point était inacceptable :

J’ai eu des journalistes qui m’ont posé la question et j’ai toujours répondu qu’en 2038 nous utiliserions tous des processeurs 64 bits. Je pense que c’est une réponse tout à fait raisonnable.
Mais si ces processeurs 64 bits font en fait tourner un mode « rapide » 32 bits, alors cette réponse perd toute sa pertinence. À notre époque, c’est une erreur fondamentale que d’avoir off_t et time_t en 32 bits. Je détesterais d’avoir à introduire ça dans le noyau, ça me ferait gerber.

Ce point a été rapidement corrigé en introduisant une gestion du temps spécifique sur 64 bits pour l’architecture x32 (c’est la fonction COMPAT_USE_64BIT_TIME). D’autres objections ont été soulevées, mais les révisions successives des patches ont finalement convaincu Linus d’intégrer cette ABI x32 dans la branche principale du noyau.

Bien entendu, un tel changement mixant les caractéristiques de plusieurs architectures a des impacts bien au-delà du noyau Linux. La gestion de la nouvelle architecture x32 doit être ajoutée dans GNU binutils, dans la Glibc et dans le compilateur GCC. Les distributions binaires doivent décider d'utiliser ce mode et proposer des exécutables x32 dans leur dépôts.
C'est donc un travail de longue haleine qui commence et nous verrons dans les prochaines années si l'architecture x32 arrive à convaincre dans le monde de l'embarqué.

dm-verity

La couche du device‐mapper présente dans le noyau est une interface virtuelle servant à faire communiquer entre eux des périphériques blocs. Cette gestion des volumes logiques permet, par exemple, de faire du RAID logiciel ou du chiffrement de disques entre divers périphériques en mode bloc.
La couche device-mapper du noyau 3.4 accueille un nouveau module nommée dm‐verity, qui fera sans doute quelque peu polémique auprès des libristes les plus vigilants.

Le but de dm-verity est de vérifier l’intégrité des blocs de données d’un périphérique. Pour cela une empreinte est prise pour chaque bloc et chacune d’entre elles est mise en correspondance sur son bloc respectif via dm-verity. Comme le périphérique virtuel est monté en mode lecture seule, il n’est pas possible de changer l’empreinte, ce qui assure l’intégrité des données contre toute tentative de modification frauduleuse.
Bien entendu, pour que la chaîne de confiance soit absolue, il faut que la machine puisse avoir une phase d’amorçage protégée. Cela se fait en utilisant tboot ou TrustedGRUB, ou encore en démarrant à partir d’une clé USB ou d’un CD considérés comme sûrs. L’utilisateur de dm-verity va alors fournir au système l’empreinte de la racine, et cette information est la clé qui permettra de vérifier, de proche en proche, que les blocs du périphérique (et donc les exécutables) n’ont pas été modifiés. C’est la technique classique de l’arbre de hachage qui est ici utilisée (Merkle tree).
La documentation indique que la vérification se fait via l’outil veritysetup avec la syntaxe suivante :

veritysetup -a vroot /dev/sda1 /dev/sda2 hash_de_la_racine

Théoriquement à ce stade le lecteur attentif des dépêches noyau LinuxFr devrait se demander « Mais en quoi est‐ce différent du sous‐système EVM qui avait été décrit dans la dépêche Linux 3.2 ? ».
Excellente question cher lecteur attentif ! Eh bien, tout d’abord, EVM fonctionne obligatoirement avec une puce TPM (Trusted Platform Module), alors que dm-verity n’a pas cette dépendance. Il peut utiliser une puce TPM (via TrustedGRUB notamment), mais, comme nous l’avons vu plus haut, il peut aussi se contenter d’un amorçage à partir un périphérique externe qui aura été gardé en lieu sûr (clé USB ou CD).
Ensuite, la vérification des empreintes se fait seulement à la demande, quand le noyau à besoin de réellement accéder aux blocs sous‐jacents (lors d’un accès disque). Cela évite une coûteuse phase de vérification de toutes les empreintes lors du démarrage, ce qui améliore donc les performances.

Le développeur Mandeep Singh Baines a indiqué que dm-verity était déjà utilisé par Google dans son projet Chrome OS :

dm-verity fait partie de l'infrastructure de boot sécurisée de Chrome OS. Le module est utilisé pour vérifier l'intégrité du système de fichiers root lors du démarrage. Cette partition root est montée via un mapping dm-verity afin de vérifier, de façon complètement transparente, que chaque bloc correspond au hash qui a été passé lors du boot.

Une présentation de dm-verity a été effectuée lors du sommet Plumber 2011 qui s’est déroulé à San Diego en août dernier. Dans le fichier PDF de présentation, on apprend que la vitesse de vérification a été un facteur crucial lors du choix d’architecture de dm-verity. Certes, EVM est une solution plus complète, mais la nécessité de ne pas ralentir le démarrage d’une machine Chrome OS a conduit au développement de cette alternative. Avec dm-verity, il est ainsi possible d’amorcer en 1,2 seconde une partition root de 891 Mio.

Bien entendu, cette technique de vérification d’intégrité peut aussi être utilisée par des constructeurs peu scrupuleux qui voudraient bloquer l’accès des utilisateurs à leur machine. Il est particulièrement inquiétant de lire le courriel envoyé sur la LKML par Wesley Miaw qui travaille pour Netflix. Cette société américaine propose un service payant de diffusion vidéo. On comprend facilement qu’elle puisse chercher à bloquer l’enregistrement de ce flux vidéo sur les smartphones et tous les autres périphériques basés sur Linux :

Netflix voudrait que dm-verity soit incorporé dans le noyau Linux. Au cours de l'année écoulée, nous avons travaillé avec Google afin de porter dm-verity sur un certain nombre de périphériques électroniques grand public tournant sous une version embarquée de Linux.
La demande pour cette fonction a été importante et nous voyons pas mal de bénéfices à ce que dm-vérity fasse partie du noyau officiel.

Netflix a une politique de certification officielle des plates‐formes avant que l’utilisateur ne puisse accéder au flux vidéo (voir cet exemple avec les smartphones OMAP 4). On peut craindre que dm-verity ne soit utilisé pour bloquer toute tentative de changement des binaires, et que l’empreinte racine ne reste entre les mains du constructeur. Ce ne serait pas la première fois qu’une technologie potentiellement utile serait ainsi détournée pour asservir les utilisateurs.
Comme le résume Jonathan Corbet sur l’article de LWN dédié à ce sujet :

Certains vendeurs vont, sans aucun doute, choisir d'inclure des outils comme dm-verity sans donner aux utilisateurs la possibilité de le désactiver. Ce n'est pas une bonne chose, mais ce n'est pas non plus quelque chose de nouveau.

Nouveautés pour l'architecture ARM

L'architecture ARM a le vent en poupe en ce moment et le noyau Linux 3.4 accueille de nombreuses nouveautés qui améliorent sa prise en charge et ajoutent des fonctionnalités.

La première de ces nouveautés est l'unification de la gestion des horloges dans un nouveau sous-système dédié nommé « Common CLK ».
C'est un travail de longue haleine qui a été entrepris par Mike Turquette, Jeremy Kerr et Ben Herrenschmidt puisque la première version a été proposée sur la LKML il y a plus d'un an.
Auparavant le noyau Linux gérait de façon complètement séparée ce code de gestion des horloges matérielles. Chaque implémentation vivait dans des répertoires dédiés aux diverses architectures. Plutôt que cette solution inefficace d'un code spécifique pour chaque plateforme, le nouveau sous-système propose une gestion matérielle unifiée :

The common clk framework is an interface to control the clock nodes available on various devices today. This may come in the form of clock gating, rate adjustment, muxing or other operations. The net result is consolidation of many different struct clk definitions and platform-specific clock framework implementations.

La documentation indique que l'option de configuration COMMON_CLK doit être choisie lors de la compilation et que l'interface est divisée en deux parties bien distinctes. La première s'appuie sur le code commun (un struct clk unique ainsi qu'une API unifiée dans include/linux/clk.h) tandis que la seconde regroupe les callbacks spécifiques qui s'enregistrent avec clk_ops.
Maintenant que ce sous-système commun unifié est disponible on va sans doute assister à la conversion progressive des pilotes dans les prochaines versions du noyau.

Ce travail n'est pas vraiment spécifique à l'architecture ARM mais, étant donné la diversité qui existe sur cette architecture, c'est pour elle que ses effets bénéfiques vont se faire sentir avec le plus de force. Alors qu'avant il était impossible de compiler une image noyau identique pour deux plateformes ARM ayant des struct clk différentes, il devient maintenant envisageable, à moyen terme, d'avoir une image multi-plateforme unique pour ARM. Moins de duplication de code et, comme l'écrit Mike Turquette, le but est bien d'avoir « The One Image to Rule Them All » !

Outre cette infrastucture « Common CLK » le noyau 3.4 accueille également les patchs de DMA-mapping qui ont été écrits par Marek Szyprowski. Le DMA (Direct Memory Access) c'est la possibilité d'envoyer les données d'un périphérique directement dans la mémoire RAM, sans intervention du processeur. Bien entendu, cette technique doit tenir compte des particularités de l'architecture matérielle sous-jacente et une API unifiée est disponible dans le noyau Linux.
Le problème, c'est que les développeurs ARM n'utilisaient pas vraiment ce code commun et qu'une certaine « balkanisation » était observée dans l'arbre des sources. Marek a mis fin à cette anarchie et ses patchs simplifient la gestion des particularités de l'architecture ARM.

Encore une nouveauté ARM intégrée dans ce noyau 3.4, la fonction « jump label » est maintenant utilisable pour les machines ARM et Thumb-2.
Comme indiqué dans la dépêche du noyau 2.6.37 cette fonction « jump label » (d'ailleurs renommée depuis en « static keys ») permet de réduire drastiquement le coût des points de traçage, mais elle nécessite d'écrire un code assembleur adapté à chaque architecture. C'est Vincent Rabin qui s'est chargé de ce travail pour ARM et cette fonction est utilisable avec l'option de configuration HAVE_ARCH_JUMP_LABEL.

Le JIT (compilateur à la volée) qui permet d'accélérer le traitement des paquets réseau du filtre Berkeley Packet Filter, est maintenant disponible sur architecture ARM.
Cette fonction est utilisable via l'option HAVE_BPF_JIT et elle s'active avec un petit echo 1 > /proc/sys/net/core/bpf_jit_enable.

Enfin, du côté de la prise en charge du matériel, le développeur Peter De Schrijver a écrit un patch ajoutant la gestion de la plateforme Tegra3 avec son « processeur compagnon ». On voit ainsi que NVidia, société pour laquelle travaille Peter, souhaite améliorer la prise en charge native de ses SoCs dans la branche principale.
Le noyau 3.4 apporte également la prise en charge de la plateforme Exynos5 de Samsung. C'est le tout premier System on Chip à utiliser le nouveau coeur Cortex-A15.

YAMA

Après plus d'un an et demi d'hésitations et de débats, le module de sécurité YAMA a finalement été intégré dans le noyau Linux 3.4.
Cet ajout est une bonne occasion pour évoquer les controverses qui persistent entre les développeurs au sujet de la sécurité de Linux. Il a toujours été difficile de trouver un équilibre entre la sécurité à tout prix, au détriment même de la propreté du code et de sa maintenabilité, ou bien une approche plus pragmatique et mesurée.

Tout commence le 16 juin 2010 avec un mail de Kees Cook sur la liste de diffusion du noyau. Kees, qui était alors responsable sécurité chez Canonical, soutient que l'appel système ptrace est potentiellement dangereux et il propose un patch pour bloquer cette faille.
La commande ptrace est souvent utilisée pour les phases de déboguage car elle permet à un processus d'éditer l'espace mémoire d'un autre processus. D'après Kees Cook, un attaquant peut exploiter cette capacité afin d'élargir la surface d'attaque d'une compromission initiale :

Une faiblesse particulièrement troublante de l'interface des processus sous Linux est qu'un simple utilisateur peut examiner le statut et la mémoire de chacun de ses processus.
Par exemple, si une application (par exemple Pidgin) est compromise, alors il est possible pour un attaquant de s'attacher à un autre processus (par exemple Firefox, une session SSH, un agent GPG, etc.) afin d'extraire des informations sensibles additionnelles et continuer son attaque.

Le patch de Kees est simple puisqu'il se contente d'ajouter un sysctl (une interface de paramétrage) contrôlant le comportement de ptrace. Ce nouveau paramètre, nommé ptrace_scope, peut prendre les valeurs « 0 » ou « 1 ». Par défaut, c'est « 0 » qui est utilisé (mode « classic ») et cela signifie que le comportement de ptrace ne change pas par rapport à la situation actuelle. En revanche, quand ptrace_scope est à « 1 » (mode « restricted »), alors un processus ne peut lancer ptrace que sur ses processus fils et toute tentative d'examiner la mémoire des autres processus échouera.

On notera que le travail de Kees Cook s'inspire largement d'une fonction qui existe déjà dans Grsecurity. L'option CONFIG_GRKERNSEC_HARDEN_PTRACE interdit en effet de lancer ptrace sur des processus arbitraires et limite le choix aux processus fils.

Les réactions sur la LKML n'ont pas été d'un enthousiasme délirant et Alan Cox a été prompt à manifester son opposition au patch de Kees :

Les autres distributions font ça de façon rationnelle en utilisant des choses comme SELinux. Cela permet de décrire les relations de façon complète et on contrôle tous les chemins d'accès, pas seulement ptrace, pouvant être utilisés par un attaquant.
Même si tu t'en tapes d'utiliser les mêmes fonctions de sécurité que le reste du monde, de toute façon ton patch, et les autres trucs que tu as postés, tout ça doit aller dans un module de sécurité à part.
Donc NAK. Si tu veux réutiliser des morceaux de grsecurity alors, s'il te plaît, écris un module noyau grsecurity qui se basera sur les hooks qui existent. Arrête de pourrir le cœur du code. C'est aussi simple que ça. L'infrastructure existe alors utilise-là.

James Morris, le responsable de SELinux, a même souligné que son module de sécurité avait déjà un booléen, nommé allow_ptrace, et permettant de contrôler le comportement de ptrace. Pourquoi alors réinventer la roue ?
Le problème c'est que tout le monde ne veut pas utiliser SELinux. Les réfractaires sont nombreux et ils sont d'avis que SELinux est trop compliqué à utiliser. Même un hacker aussi réputé que Ted Ts'o avoue être découragé :

Il y a un bon nombre de gens qui n'utiliseront jamais SELinux. Tous les deux ou trois ans, je jette un nouveau coup d'œil sur SELinux, ma tête explose devant la complexité (non nécessaire ÀMHA) et je prends une nouvelle fois le large.

La situation paraît donc complètement bloquée entre les zélotes d'un module SELinux ultra-puissant mais complexe et les partisans d'une solution plus simple, même si elle est moins complète.
La solution régulièrement évoquée pour faire face à ce problème est « l'empilage des modules de sécurité » (LSM stacking). Avec cette solution, il devient possible d'avoir un « gros » module qui couvre le cas général (comme SELinux) et un ou plusieurs autres modules qui ne s'occupent que de fonctions bien précises sur lesquelles l'utilisateur veut avoir le contrôle.
Actuellement, le code LSM du noyau ne permet le chargement que d'un seul module de sécurité, à l'exclusion de tous les autres. Avec le LSM stacking cette limitation disparaîtrait et le noyau Linux offrirait plus de souplesse à ses utilisateurs.

En attendant que les développeurs se mettent d'accord sur une solution technique propre pour implémenter cet empilage des modules, Kees Cook a donc réécrit son patch afin d'isoler le code à l'intérieur d'un nouveau module de sécurité nommé YAMA.
En plus de la restriction d'utilisation de ptrace, on trouve dans le module des protections supplémentaires sur l'utilisation des liens symboliques (symlink) et des liens matériels (hardlink).

L'intégration du module YAMA a été proposée sur le LKML le 21 juin 2010… mais, dès le 2 août, Kees a posté un message indiquant qu'il était obligé de retirer le module puisque Christoph Hellwig avait posé un veto empêchant l'inclusion dans le noyau.
Les objections de Christoph se concentrent sur le fait que YAMA n'est pas un module de sécurité cohérent et qu'il n'est qu'une collection hétéroclite de divers patchs visant à bloquer des failles potentielles.

À ce stade de la situation on ne peut que comprendre la frustration de Kees :

Je commence à être fatigué de devoir porter mes patchs d'un côté ou de l'autre entre les sous-systèmes ou les modules de sécurité. Vous m'avez demandé de tout mettre dans un module et maitenant vous me dites que je ne devrais pas faire ça.
La situation est très simple. Soit vous me laissez mettre tout ça dans un module pour que les gens puisse choisir de l'activer. Soit vous m'aidez à améliorer les patchs, afin qu'ils intégrent directement les sous-systèmes.
Comme la seconde solution a été refusée à plusieurs reprises, il m'a été suggéré d'opter pour la première, ce que j'ai fait. L'option de tout abandonner n'est pas envisageable.

La flame war discussion a donc été relancée et certains développeurs ont tenté d’expliquer à Kees ce qu’ils reprochaient à ses patchs :

Tu n'évoques pas la solution que t'a suggérée Al : Il faut avant tout réfléchir au problème de façon approfondie au lieu de balancer des patchs qui ne s'occupent que d'un seul cas de figure.
Ici on ne bloque qu'un seul type spécifique d'attaque sans créer un modèle conceptuel de la menace. C'est la grande distinction entre SELinux, Tomoyo, Smack et puis tes patchs à toi. Ces modules de sécurité forment un modèle de ce qui est important à protéger et de comment le protéger. Ils ne se contentent pas d'appliquer des règles arbitraires pour empêcher certaines attaques.
Les gens s'inquiètent parce que ton module pourrait grossir en accumulant des tonnes de règles spécifiques qui créeraient une sécurité apparente sans vraiment procurer une sécurité réelle.

Kees Cook a tenté de faire valoir son point de vue et a souligné la situation impossible dans laquelle il se trouvait confiné :

Vous pouvez voir, comme moi, que la situation est un catch 22. « Nous n’avons pas besoin de la fonction d’empilage parce qu’il n’y a rien à empiler » et « nous n’avons pas besoin d’un micro‐module parce qu’il est impossible d’empiler les modules. »

Le blocage étant total, il a été décidé d’attendre la prochaine conférence sur la sécurité du noyau, afin que la situation se décante et que les protagonistes puissent se parler directement. C’est donc en septembre 2011 que James Morris et les autres développeurs responsables de la sécurité se sont retrouvés. Dans le programme, on peut voir que Kees Cook animait une discussion portant le titre suivant: « LSM Architecture: modularity, stacking ».
Le compte‐rendu que Paul Moore a fait du Linux Security Summit 2011 indique que le sommet a bien joué son rôle et que l’avis des développeurs a changé au sujet du l’empilement et de la concurrence entre les modules. Cette évolution s’est matérialisée en mars 2012 quand James Morris a officiellement accepté d’intégrer le module de sécurité YAMA dans sa branche destinée au noyau Linux 3.4. Le fait que ce code soit déjà en cours d’utilisation dans divers projets n’est sans doute pas étranger à cette inclusion :

Le principal ajout est le nouveau module de sécurité YAMA, écrit par Kees Cook, et qui a été discuté l'année dernière au sommet sur la sécurité. Son but est de rassembler divers mécanismes de sécurité DAC en un seul endroit. Cela marque également un changement de politique en ce qui concerne les modules LSM qui étaient auparavant tous des mécanismes complets de contrôle d'accès.
Chromium OS utilise YAMA et je crois qu'il y a des plans pour Ubuntu.

Kees a précisé qu'en fait Ubuntu utilisait déjà YAMA depuis octobre 2011 et il a également fourni un lien vers l'inclusion de YAMA dans Chromium OS.
Selon la documentation présente dans les sources du noyau, on voit que seule la restriction de ptrace a été implémentée pour l"instant dans YAMA (just ptrace restrictions for now). Il est fort probable que les autres restrictions, celles qui concernent symlink et hardlink, intégreront plus tard le module.

Un choix est donc désormais offert entre l'implémentation (souvent difficile) d'une politique de sécurité complète ou bien l'activation d'un module visant à regrouper divers patchs de renforcement de la sécurité.
Nous verrons dans les prochains noyaux si la solution idéale que constituerait le « stacking LSM » parviendra à s'imposer.

En bref

Maturation de btrfs

Les distributions de Novell (SuSE Linux Enterprise) et d'Oracle (Unbreakable Enterprise Kernel) veulent absolument se différencier par rapport à Red Hat. C'est pour ça qu'elles ont choisi de supporter officiellement (1 - 2) le système de fichiers btrfs, même si il est encore considéré officiellement comme « experimental » dans la branche principale du noyau.
Leurs patchs de fiabilisation arrivent maintenant dans le noyau 3.4 afin que tous les utilisateurs puissent en profiter.
On trouve donc un gros patch de Jeff Mahoney, employé par SuSE, qui améliore la gestion des erreurs. Auparavant, c'était un simple et rustique appel à la macro BUG_ON qui était souvent utilisé (on enregistre l'erreur et on arrête le système). Maintenant la plupart des erreurs bénéficient d'un traitement spécifique et le crash du noyau est évité. Comme le résume Chris Mason :

Nous avons mergé les patchs de gestion d'erreurs venant de SuSE. Ils sont déjà incorporés dans le noyau SLES et ils apportent à Btrfs la possibilité d'interrompre les transactions et de passer en mode lecture seule en cas d'erreur.

Le message de Chris récapitule les autres nouveautés concernant btrfs pour cette version du noyau. On peut voir notamment qu'un gros travail de performances a été effectué sur la gestion des métadonnées, sur la coopération avec le cache de page de Linux ou encore sur la réduction de l'empreinte CPU (voir par exemple les patchs de Josef Bacik).
En ce qui concerne les métadonnées du système de fichiers il est possible d'utiliser des blocs plus grands que 4 Ko. La limite est maintenant portée à 64 Ko et les tests montrent que l'optimum du gain de performances est atteint avec une taille de bloc égale à 32 Ko. Cette fonction s'active lors de la création du système de fichiers avec mkfs.btrfs -l 32K.

Tout ce travail d'optimisation des performances porte ses fruits si on compare les graphes postés par Chris Mason entre les versions 3.3 et 3.4 du noyau.

Simplifications dans ext4

En ce qui concerne le système de fichiers ext4, il n'y a pas de changements révolutionnaires, mais on trouve néanmoins plusieurs patchs de nettoyage intéressants.
Ted Ts'o, qui peste depuis plusieurs mois devant le nombre d'options présentes dans ext4, a procédé à diverses simplifications du code. Par exemple, l'option de montage journal=update, qui a été introduite il y a dix ans pour faciliter les migrations depuis ext3, a été retirée du noyau 3.4. C'est la même chose pour l'option resize permettant de changer la taille lors du mount. Après tout, on utilise resize2fs alors pourquoi avoir cette option redondante ?
Un autre patch utilise une table pour stocker les options de mount, ce qui, là encore, simplifie le code puisqu'on peut supprimer une centaine de lignes.
Ted a également proposé de retirer les options bsddf et minixdf qui conduisent l'outil df à se comporter comme sous BSD ou MINIX… mais les cris d'orfraie sur la LKML l'ont finalement dissuadé.
Pas découragé pour autant, il a fait remarquer qu'ext4 était le seul système de fichiers à proposer une option permettant l'activation ou la désactivation des attributs étendus lors du mount (options noacl et nouser_xattr). C'est fort peu utile, mais avant de supprimer ce code, il faut tout de même alerter la communauté. Son patch se contente donc pour l'instant de marquer ces options comme obsolètes (deprecated) et elles seront probablement retirées dès le prochain noyau.

fadump pour PowerPC

Dans cette version du noyau, l’architecture PowerPC a gagné un mécanisme de capture des données (dump) lors d’un éventuel crash de la machine. Ce nouveau système repose sur une coopération avec le micro‐logiciel, le firmware, ce qui explique son nom de fadump (firmware assisted dump).

Lors du démarrage initial, le noyau se sert du firmware Power pour sélectionner des régions de la mémoire et les réserver au stockage des données pour analyse post-mortem. Au moment du crash, c’est le firmware qui prend la main et qui sauve les données (ainsi que les registres système et les entrées dans la table des pages).
Après ces opérations, l’administrateur peut redémarrer normalement. Le noyau va noter qu’il y a eu un crash (puisqu’une entrée dump-kernel aura été créée) et il va soigneusement éviter de toucher les zones mémoire réservées. Un programme en espace utilisateur pourra ensuite être utilisé pour lire /proc/vmcore et récupérer ces données pour analyse ultérieure. Ensuite, il ne faudra pas oublier de faire un petit echo 1 > /sys/kernel/fadump_release_mem pour libérer la mémoire qui avait été réservée au stockage des données du crash.

La documentation de fadump écrite par Mahesh Salgaonkar explique les deux avantages de cette procédure par rapport aux classiques kexec et kdump. Tout d’abord, le système est réinitialisé proprement avec une version fraîche du noyau, et ensuite, aussitôt que la copie du dump est effectuée, la mémoire peut être réutilisée. Pas besoin d’un nouveau redémarrage.
Pour profiter des avantages de fadump, il vous faudra un noyau compilé avec l’option de configuration CONFIG_FA_DUMP.

UFS dans le noyau

Le titre de ce paragraphe peut prêter à confusion, puisqu’il ne s’agit pas du système de fichiers bien connu Unix File System, mais bien de la norme Universal Flash Storage.
C’est l’organisation de standardisation JEDEC qui s’est chargée de créer cette nouvelle norme destinée au stockage sur mémoire Flash dans les appareils mobiles (smartphones, tablettes ou encore appareils photo). De nombreuses sociétés de l’embarqué (Nokia, Sony Ericsson, Texas Instruments, STMicroelectronics, Samsung, etc.) ont travaillé à l’élaboration de la norme, afin qu’elle offre une plus grande vitesse et une moindre consommation que le standard actuel des cartes SD. L’architecture de communication utilisée est similaire à SCSI afin de profiter de la gestion des commandes multiples et d’offrir un modèle de programmation bien connu.

Les patchs de Santosh Yaraganavi ajoutent au noyau le pilote UFS pour le host controller. Selon la documentation, un peu de travail reste à faire en ce qui concerne la gestion de la consommation, mais on peut noter que les systèmes basés sur Linux sont les premiers à offrir la gestion de la norme Universal Flash Storage.

Camellia et CRC32

L’optimisation des algorithmes de chiffrement va peut‐être devenir un paragraphe récurrent des dépêches noyau. En effet, après les patches évoqués dans les dépêches du 3.2 et du 3.3, le développeur finlandais Jussi Kivilinna a frappé de nouveau.

Cette fois, c’est l’algorithme Camellia qui est concerné. Rappelons qu’il s’agit de l’algorithme de chiffrement symétrique 128 bits arrivé en tête lors du concours NESSIE de l’Union européenne.
Comme pour ses patches précédents Jussi a écrit une implémentation en assembleur optimisé pour l’architecture x86_64 (camellia-x86_64-asm_64.S). Le gain en performances est tout à fait notable par rapport au code C générique du noyau puisque, sur un processeur Core 2 T8100, on relève un écart s’échelonnant de 10 % à plus de 70 % (en mode ECB).

Jussi Kivilinna n’est pas le seul à traquer la performance, et le noyau Linux 3.4 incorpore également les patches CRC32 de Bob Pearson. Le contrôle de redondance cyclique (CRC pour Cyclic Redundancy Check) est utilisé partout afin de détecter les erreurs de transmission, et il est important que le code soit optimisé soigneusement.
Bob a modifié le fonctionnement de la routine lib/crc32.c afin de remplacer la boucle principale et la boucle rem_le par des compteurs à incrémenter. Selon les tests, on peut espérer un gain supérieur à 6 % sur architecture x86.
Comme le code semble dégrader les performances des PowerPC, il a été entouré de ifdef CONFIG_X86, afin de ne pas pénaliser les autres architectures.

Discard pour « thin provisioning »

Depuis le noyau 3.2, la couche device mapper permet de faire de l’allocation fine et dynamique (thin provisioning). Dans le cadre d’un SAN, plutôt que d’allouer vraiment tous les blocs à un client, on va les allouer à la volée pour économiser de l’espace. Chacun des clients aura un volume virtuel à sa disposition, mais ce volume n’occupera que l’espace réellement consommé.

Cette cible DM de « thin provisioning » est maintenant capable de gérer la fameuse fonction discard. Cette commande est très importante pour les disques de stockage de type SSD (à base de mémoire Flash), car elle permet au système d’exploitation d’indiquer au disque quels sont les blocs de données qui peuvent être effacés. Dans le cas du thin provisioning, un appel à discard provoquera la suppression des correspondances (mappings) et, si les blocs ne sont plus partagés, l’ordre de suppression sera envoyé au périphérique sous‐jacent.

Cette utilisation plus efficace du périphérique de stockage n’est pas la seule nouveauté intégrée dans la fonction de thin provisioning du noyau 3.4. On trouve également la possibilité d’utiliser des images en lecture seule comme origine. La lecture des blocs s’effectue sur cette image, tandis que les écritures se font sur un autre périphérique.
C’est très utile dans le cas des environnements virtualisés, puisque l’hôte peut ainsi accueillir les systèmes invités sur un volume géré par thin provisioning, tout en ayant l’image de base stockée sur un autre périphérique partagé entre les machines virtuelles.

IRQ domains

Une IRQ c’est une demande d’interruption (Interrupt Request) envoyée au processeur pour lui signaler que le matériel a besoin qu’une action urgente soit effectuée (entrée‐sortie, avancement d’une horloge, défaut matériel, etc.).
Linux se doit de gérer parfaitement les machines qui ont plusieurs contrôleurs d’interruptions et, pour atteindre ce but, un nouveau sous‐système nommé IRQ domains fait son entrée dans le noyau 3.4.

Auparavant c’étaient les fonctions irq_alloc_desc et irq_free_desc qui étaient utilisées afin d’éviter les collisions dans les assignations des numéros des interruptions.
Ce mécanisme ayant été jugé perfectible (pas de possibilité de faire du reverse mapping), un nouveau système propre et générique a été développé. Il s’inspire du code PowerPC et s’active avec l’option de configuration IRQ_DOMAIN.
Comme l’explique la documentation, ce mécanisme générique permet maintenant au noyau Linux de gérer proprement la correspondance entre les IRQ des divers contrôleurs (hwirq) et l’espace global des interruptions.

Pilote virtio-scsi

Virtio est une interface virtuelle qui permet au noyau de gérer efficacement les entrées‐sorties pour les systèmes virtualisés. C’est le pilote virtio-blk qui s’occupe des périphériques en mode bloc, mais, à partir de ce noyau 3.4, une alternative devient disponible. Elle prend la forme du pilote virtio-scsi écrit par Paolo Bonzini, un développeur Red Hat.

Ce pilote virtio-scsi propose le multiplexage (plusieurs unités de stockage logiques sur un seul port PCI), mais son auteur le définit surtout comme plus extensible que virtio-blk. Avec ce dernier, il est nécessaire de définir la liste des fonctionnalités du périphérique, et chaque ajout implique une mise à jour de cette spécification, de l’hôte QEMU, ainsi que des pilotes des systèmes invités.
Avec virtio-scsi, l’hôte fournit juste une couche de transport SCSI, et les ajouts de fonctionnalités se feront plus facilement (Paolo cite les fonctions discard, extended copy, ainsi que write same).
Les développeurs Linux n’aiment pas vraiment introduire du code qui fait doublon dans le noyau, et Paolo a dû batailler ferme pour convaincre James Bottomley de l’utilité de son pilote aux côtés de virtio-blk.
Pour profiter de ce pilote alternatif sur vos systèmes, il vous faudra un noyau compilé avec l’option SCSI_VIRTIO. Ce code est encore considéré comme expérimental pour le moment.

Du côté de -staging

Pas mal de mouvements dans cette branche -staging dédiée au code pas encore assez mature pour rejoindre la branche principale.
Par exemple, les mécanismes « zcache » et « zram », qui s’occupent de compresser les pages mémoire, bénéficient d’un nouvel allocateur mémoire. Auparavant, c’était l’allocateur xvmalloc qui était utilisé, mais un remplaçant plus efficace a été développé par Nitin Gupta. Ce nouvel allocateur se nomme zsmalloc et il est conçu tout spécialement pour stocker des pages RAM compressées et réduire la fragmentation.
Par ailleurs, le mécanisme de compression zcache utilise maintenant le sous‐système CRYPTO du noyau pour son algorithme de compression. Avant, c’était un code ad hoc qui était employé mais les développeurs Linux ont fermement indiqué qu’il fallait réutiliser le mécanisme standard. On peut choisir son algorithme au démarrage avec une syntaxe du type zcache=lzo ou zcache=deflate.
Greg Kroah-‐artman ayant indiqué qu’il n’accepterait plus aucun ajout de fonction, on peut penser que ces patches seront les derniers avant la sortie de -staging pour zcache et zram.

Toujours dans -staging les patchs écrits par Arve Hjønnevåg ajoutent la prise en charge des alarmes Android dans le noyau. Encore un petit pas vers la gestion intégrale d'Android dans la branche principale.

Le sous-système « RAMster », après un petit imbroglio initial, a également été intégré dans -staging (1 - 2). L’idée derrière RAMster est très intéressante, puisqu’il s’agit de permettre aux machines au sein d’une grappe de serveurs (cluster) de créer une sorte de réserve commune de mémoire vive. Ainsi, quand une machine est un peu juste en RAM et sur le point de devoir faire appel à la partition d’échange (le swap), elle va pouvoir envoyer ses données dans la RAM de sa collègue.
Le mécanisme est toutefois complexe (voir la documentation) et il faudra attendre sa stabilisation avant de le voir intégrer la branche principale.

Enfin, petit évènement, le dernier morceau du pilote de virtualisation Hyper-V écrit par Microsoft quitte enfin la branche -staging. Vous pouvez maintenant « profiter » de ce pilote en passant les options de configuration HYPERV et HYPERV_STORAGE lors la compilation.
C’est la fin d’une saga débutée en juillet 2009, et qui, du fait des atermoiements et des problèmes de qualité du code, n’aura pas redoré le blason de la firme de Redmond.

Pilote graphique Nouveau

Pour faire une habile transition avec la brève précédente consacrée à -staging, notons le patch de Ben Skeggs, qui transfère le pilote Nouveau de -staging vers drivers/gpu/drm. Jusqu’à présent, les développeurs considéraient que Nouveau était encore susceptible de changer son interface binaire et donc devait rester dans l’antichambre du noyau. Le passage en version 1.0 marque un engagement de stabilité et autorise maintenant une sortie de -staging.
Comme l’écrit Ben :

Il n’y a pas vraiment de raison de rester dans cette branche, de toute façon nous devons maintenir l’ABI pour éviter d’énerver les gens.

Ben a également ajouté le code permettant de faire fonctionner la toute récente carte de type Kepler (GeForce GTX 680). Attention toutefois, puisqu’il ne s’agit pas, pour l’instant, d’exploiter la puissance de cette carte, le patch n’ajoute que la gestion des modes d’affichage (mode setting), ce qui permet d’éviter d’avoir à se rabattre sur VESA.

Les autres pilotes graphiques

Le pilote DRM dédié au système mono‐puce (SoC) Samsung Exynos gagne une prise en charge de la norme HDMI 1.4 et un pilote virtuel permettant la gestion des écrans sans fil.

Côté AMD, on voit arriver la prise en charge des cartes Southern Islands (Radeon HD 7700, 7800 et 7900), ainsi que des processeurs Fusion de type Trinity. Les cartes Northern Islands reçoivent des patches écrits par Jérome Glisse et permettant la prise en charge du pavage (tiling) 2D.
Pour avoir une idée de la complexité du travail des développeurs de pilotes GPU, vous pouvez d’ailleurs aller lire cette publication de Jérome, dans laquelle il raconte la difficile traque d’un bogue affectant la sortie VGA des puces Llano.

Du côté d’Intel, le pilote i915 active enfin par défaut le mode d’économie d’énergie RC6 sur les puces Sandy Bridge. On trouve également la possibilité d’entrelacer les flux HDMI et SDVO en sortie, ainsi qu’une amélioration des performances d’environ 10 % grâce aux patches PGTT (Per-process Graphics Translation Table) et Swizzling.

HSI

Le noyau 3.4 accueille les patches de Carlos Chinea, qui travaille pour Nokia. Ils permettent la gestion du sous‐système HSI (High Speed Synchronous Serial Interface).
Il s’agit d’un bus série utilisé dans les téléphones mobiles et destiné à faire communiquer les « applications engines » (APE) avec le modem du mobile. HSI permet de multiplexer jusqu’à 16 canaux avec des latences faibles et une communication bidirectionnelle simultanée (full‐duplex).

Pour l’instant, aucun pilote n’utilise ce nouveau bus série, mais Carlos a indiqué qu’il travaillait sur le support d’une carte TI OMAP. D’autres développeurs ont manifesté leur intérêt auprès de Linus afin qu’il accepte ces patches (Several people piped up to say “yeah, we want this”).

Sous‐système remoteproc

Les systèmes complets sur une puce (SoC) contiennent souvent des cœurs de calcul très hétérogènes. Si l’on regarde par exemple le SoC OMAP 4 de Texas Instrument, on constate qu’il est constitué de deux processeurs Cortex-A9, de deux processeurs Cortex-M3 et d’un DSP de type C64x.
Comment faire dialoguer le plus proprement et le plus simplement possible ces divers cœurs de calcul ?

C’est ici qu’entrent en scène le nouveau sous‐système remoteproc et le mode de communication rpmsg qui ont été introduits dans le noyau 3.4.
Le sous‐système remoteproc permet au processeur principal de contrôler plus simplement les divers processeurs hétérogènes qui existent sur la puce SoC. C’est une sorte de couche d’abstraction du matériel, puisqu’il n’est plus besoin d’avoir des pilotes spécifiques pour gérer l’allumage (rproc_boot) ou l’extinction (rproc_shutdown) de ces processeurs spécifiques.
En plus de cette simplification qu’apporte remoteproc (voir la documentation), le bus rpmsg intégré permet au pilotes noyau de communiquer facilement avec les cœurs hétérogènes via une interface de type virtio. Un pilote d’exemple utilisant le bus rpmsg a été écrit par Ohad Ben-Cohen, afin de faciliter le travail des futurs utilisateurs.

Le résultat net de ces changements c’est que les SoC peuvent maintenant disposer d’un sous‐système générique de contrôle et de communication entre leurs divers cœurs hétérogènes de calcul. Au lieu d’avoir une prolifération de pilotes variés, il suffira maintenant d’utiliser remoteproc, en ajoutant juste un peu de code bas niveau spécifique à la plate‐forme.

Chargement retardé des pilotes

Un mécanisme amélioré de chargement des pilotes lors du démarrage a été ajouté dans ce nouveau noyau 3.4.
Dans les machines modernes, les périphériques sont devenus très complexes avec souvent plusieurs blocs fonctionnels interconnectés. L’ennui, c’est que dans ces configurations, il devient très difficile de déterminer l’ordre dans lequel les pilotes respectifs doivent être démarrés.
Grant Likely, l’auteur du patch, décrit ainsi le problème :

Une « carte son » typique consiste en plusieurs périphériques : un ou plusieurs blocs _codecs (souvent attachés via I²C ou SPI), un bus son (souvent I²C), un contrôleur DMA et une certaine quantité de code spécifique à la machine/architecture afin de tenir tout ça ensemble._
À l’heure actuelle, le code du noyau doit faire une vraie gymnastique afin d’enregistrer tous ces composants dans la couche son, et le pilote qui « tient tout ensemble » doit attendre que tous les autres pilotes soient chargés.

On voit donc qu’il s’agit là d’un problème de gestion des dépendances. Un pilote ne peut pas être chargé tant que les pilotes des autres composants ne sont pas déjà chargés. La solution semble donc simple : il suffit de déclarer une relation de dépendance entre les pilotes, comme on le fait pour les diverses options dans les fichiers Kconfig de Linux.
Le problème c’est que cette solution consistant à déclarer les dépendances ne marche pas dans le cas soulevé par Grant Likely et qui concerne les périphériques ayant plusieurs blocs fonctionnels interconnectés :

Considérez le cas où un pilote A dépend d’une ressource GPIO qui est apportée par un pilote B. En théorie, il faudrait indiquer que le pilote A dépend du pilote B, mais, en fait, le pilote A n’a aucun moyen de savoir de quel pilote B il s’agit, puisqu’il est différent pour chaque système.

Ces « périphériques » ne sont plus vraiment des entités matérielles bien distinctes. Il sont formés à partir de nombreux composants séparés au niveau matériel et ne sont réunis que par une « glu » logicielle. La conséquence, c’est que le noyau Linux n’a aucun moyen de savoir quelles sont les dépendances entre ces composants tant que ceux‐ci n’ont pas commencé à dialoguer.
Alors, comme dirait Lénine, que faire ?

La solution de Grant Likely n’est pas d’une élégance absolue, mais elle constitue un progrès indéniable par rapport à la très vilaine collection de bidouilles qui est utilisée actuellement. Le patch « driver probe deferral mechanism » permet tout simplement à un pilote de signaler qu’il n’a pas toutes les ressources nécessaires à son bon fonctionnement, et que son chargement doit être retardé afin d’être tenté à nouveau plus tard.
Par exemple, un pilote SDHCI peut avoir besoin de la collaboration d’un contrôleur I²C GPIO avant de pouvoir fonctionner correctement.
Si le pilote du contrôleur est déjà disponible lors du chargement du pilote SDHCI, alors tout se passe bien et on ne change rien au comportement précédent. En revanche, si le pilote du contrôleur I²C n’a pas encore été chargé, alors un message -EPROBE_DEFER sera envoyé pour signaler le problème, et le pilote SDHCI sera mis dans une liste d’attente (pending list). À chaque chargement réussi d’un pilote, le ou les pilotes en attente seront testés de nouveau pour voir si leurs dépendances sont satisfaites.
Comme indiqué dans le message d’annonce sur la LKML, c’est une approche « low‐tech », mais qui a l’avantage d’être simple et de fonctionner correctement.

Améliorations dans Perf

L’outil de traçage intégré dans le noyau, perf, a été mis à jour avec de nombreuses nouvelles fonctions.
Tout d’abord, les fonctions top, stat et record peuvent maintenant examiner des groupes de threads ou de processus. Il suffit de fournir la liste des numéros de processus (PID) séparés par une virgule de cette façon : perf top -p 21483,21485. On peut également filtrer par utilisateur avec l’option --uid. Pour que perf se contente d’afficher les tâches tournant sous mon utilisateur, il suffira donc de faire un petit perf top --uid patrick.

Une autre nouveauté est la possibilité de faire du profilage de précision au sujet des branches de code exécutées par le processeur. Cette fonction se base sur un module récent des processeurs Intel, le LBR (pour Last Branch Record).
D’après les explications présentes dans le message d’Ingo Molnar, il suffit d’activer la fonction avec perf record -b pour ensuite avoir la liste des branches qui sont exécutées le plus souvent par le processeur.

Enfin, la fonction report de perf dispose maintenant d’une interface graphique basique en GTK. Elle manque encore un peu de fignolage puisque, entre autres, il n’est pas possible de profiler un système KVM invité et qu’il n’y a pas de tri des colonnes, ni de code couleur pour les pourcentages. C’est toutefois un ajout bienvenu et qui va s’étoffer dans les versions suivantes du noyau. Le patch a été écrit par Pekka Enberg et la fonction s’active avec perf report --gtk.
Bien entendu, c’est une occasion unique et inespérée d’ajouter pour la première fois une nimage une copie d’écran dans une dépêche noyau :

Statistiques

En ce qui concerne les statistiques du cycle de développement du noyau 3.4, le site LWN a publié son traditionnel article récapitulatif.

En termes de patches, le total s’établit à 10 734 (au 11 mai), alors qu’il était de 10 449 pour le noyau précédent. Ce sont 1 271 développeurs différents qui ont contribué au moins un patch dans ce cycle et, comme la dernière fois, c’est Mark Brown qui est en tête de liste avec 284 patches.

Si l’on classe les développeurs non plus en termes de patches mais en termes de lignes modifiées, alors c’est Joe Perches qui occupe la première place. Il faut dire que Joe s’est attaqué à la remise en ordre du style de codage de nombreux fichiers, afin qu’ils respectent les conventions Linux. On trouve, parmi de nombreux autres, ce monstro‐patch de 10 000 lignes pour corriger les espaces et passer l’épreuve de checkpatch sans générer d’alertes : 314 files changed, 50359 insertions(+), 50455 deletions(-).
C’est un travail ingrat, mais qui est incontestablement utile, puisqu’il apporte de l’uniformité dans le code source du noyau.

Enfin, un coup d’œil sur le classement des entreprises montre une nouveauté assez étonnante. En effet, pour la toute première fois, Red Hat abandonne sa première place au profit d’Intel (seulement 960 patches contre 1 138 pour la firme de Santa Clara). Linux n’était pas menacé par la monoculture, mais c’est toujours réjouissant de voir que le classement des top contributeurs évolue.
Red Hat garde toutefois sa prééminence en termes de tags « Signed-off », parce qu’elle emploie de nombreux lieutenants de Linus.

Aller plus loin

• LWN 1: Les nouveautés du noyau 3.4 (1218 clics)
• LWN 2: Les nouveautés du noyau 3.4 (424 clics)
• LWN 3: Les nouveautés du noyau 3.4 (391 clics)
• Les nouveautés sur le site h-online (356 clics)