Sortie du noyau Linux 3.18

La sortie de la version stable 3.18 du noyau Linux a été annoncée le lundi 7 décembre 2014 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.

Sommaire

• En bref
• Annonces des RC par Linus Torvalds
  • RC-1
  • RC-2
  • RC-3
  • RC-4
  • RC-5
  • RC-6
  • RC-7
  • Version finale
• Les nouveautés
  • Architecture
    • Prise en charge des nouvelles puces ARM
    • ACPI et gestion d’énergie
    • Gestion du bus PCI sur les processeurs ARM 64 bits
    • Mise en veille et réveil plus rapide
    • Architecture SPARC64
  • Développeurs
    • Mailbox
    • Correction de l’appel système fanotify_init()
    • Quelques fonctions variables par processeur marquées obsolètes
    • LLVM
    • Vidage mémoire des périphériques
    • Modules compressés
    • Paramètres de modules non sûrs
    • Résolveur de références au sein du device tree
    • Miniaturisation
    • Temps réel
  • Pilotes graphiques libres
    • DRM (Direct Rendering Manager)
    • AMD/ATI (pilote Radeon)
    • Intel (pilote i915)
    • NVIDIA (pilote Nouveau)
    • En vrac
  • Réseau
    • Transmission de paquets réseau en masse
    • Berkeley Packet Filter
    • Foo-over-UDP
    • DCTCP congestion control algorithm
    • Generic Network Virtualization Encapsulation (Geneve) protocol
  • Sécurité
    • Cryptographie
    • LSM
      • IMA & EVM
      • SELinux
      • SMACK
    • Trousseaux de clés
    • Liste non exhaustive des vulnérabilités corrigées
  • Systèmes de fichiers
    • F2FS
    • OverlayFS
    • NFS
    • Ceph
  • Virtualisation
    • KVM
    • Xen
• Le bilan en chiffres
• Appel à volontaires

En bref

• Architecture
  • Mise en veille plus rapide (100 ms par cœur)
• Développeurs
  • Amélioration de la gestion du compilateur Clang
  • Gestion des modules compressés
• Pilotes graphiques libres
  • DRM : unification des barrières TTM
  • ATI/AMD : meilleure gestion d’énergie
  • Nouveau : gestion du son avec les connexions DisplayPort ; amélioration du recadencement
• Réseau
  • Amélioration des performances réseau
  • Nouvel appel système : bpf()
  • Mise en place de tunnels génériques : Foo-over-udp
• Systèmes de fichiers
  • Ajout d’un nouveau système de fichiers : OverlayFS intégré
• Virtualisation
  • KVM améliore la gestion de l’imbrication de machines virtuelles, ainsi que la prise en charge de l’hyperviseur Jailhouse pour les processeurs AMD
  • Xen se prépare à XenServer 4.5

Annonces des RC par Linus Torvalds

RC-1

La version RC-1 est sortie le 19 octobre 2014 :

Quand j’avais publié la version 3.17, j’avais dit que j’étendrais la phase d’intégration à trois semaines en raison de déplacements. J’ai clairement menti. Parce que nous voilà, après les deux semaines habituelles, et j’ai déjà sorti la 3.18-RC1.

Ce qui s’est passé, c’est que non seulement j’ai activement intégré malgré les voyages — j’ai été privé de communication seulement pendant quelques jours (en grande partie, mais pas seulement, à cause des vols ; l’hôtel à Düsseldorf a aussi été privé d’Internet pendant un jour) —, mais, sans doute plus important, les gens semblent avoir massivement envoyé leurs demandes d’intégration, parce que la RC-1 en contient plus que linux-next n’en a produit les quelques jours après le 3.17… Donc, la retenir une semaine de plus semble inutile.

Cela dit, je me rends compte que les gens auraient très bien pu prendre mes déclarations au pied de la lettre, et prévoir en fonction. Je déteste quand je reçois des demandes en toute fin de la phase d’intégration, mais en l’ayant fermée selon le calendrier habituel, je comprends aussi que l’on ait pu prévoir d’envoyer des demandes d’intégration un peu plus tard. Ça va. Prosternez‐vous un peu et expliquez‐moi ce qui se passe, et vous pourrez presque à coup sûr me rendre coupable de certains trucs.

Aussi, ai‐je peut‐être tout simplement raté quelque chose en raison du décalage horaire (hum… oui, appelons ça « décalage horaire », ça sonne tellement mieux que « incompétence de base et mauvaise planification »), donc, si vous vous sentez injustement négligé, envoyez‐moi un courriel pour expliquer pourquoi je vous ai injustement lésé.

Il y a également au moins une demande d’intégration que j’ai l’espoir d’obtenir le plus vite possible et que je prévois toujours de récupérer : j’espère toujours ardemment voir overlayfs enfin intégré. Mais il y avait quelques questions de dernière minute d’Al. En supposant que tout fonctionne bien, c’est une intégration tardive prévue. Pas la peine de retarder la sortie de la RC-1 pour un traînard connu, cependant.

Donc, là vous l’avez. La fenêtre d’intégration est close, mais avec un espace [room] pour des excuses et les possibles demandes d’intégration oubliées. Comme d’habitude, le résumé des rapports de modifications est beaucoup trop long pour être posté (statistiques de base : en gros 74 % de pilotes, 10 % de mises à jour d’architecture ; le reste étant : du réseau, les systèmes de fichiers, le cœur du noyau , la documentation, les fichiers d’en‐têtes, des mise à jour des outils…), et la suite est mon « journal d’intégration » qui, comme d’habitude, mentionne ceux qui m’ont fait des remontées, qui ne sont pas nécessairement les mêmes que les gens qui ont écrit le code.

En avant, testez,

Linus

RC-2

La version RC-2 est sortie le 26 octobre 2014 :

Nouvelle semaine, nouvelle RC, et maintenant la phase d’intégration est définitivement fermée.
J’avais espéré que la sortie de la RC-1 signifierait que quelques traînards feraient rapidement surface, et que le reste de la RC serait plus normale. Mais non, j’ai eu le droit toute la semaine à des demandes d’intégration en pagaille et la RC-2 a été plus longue que je l’aurais voulu.
Tant pis. Ce n’est pas que je sois vraiment surpris, mais ça veut dire que je vais probablement être désagréable la semaine prochaine envers quiconque essaiera de me soumettre des choses dont je penserai qu’elles ressemblent plus à du « développement » plutôt qu’à des « correctifs ». Vous aurez été prévenus. Je vous ai en effet donné trois semaines complètes pour l’intégration, c’est maintenant le moment de la correction des bogues, et d’un autre brouhaha. D’accord ?

Et, pour être honnête, nous avons eu de plus longues RC-2 historiquement. Pas récemment, toutefois. Les 3.3 et 3.4 avaient toutes deux de grosses RC-2, et la 3.15 (qui était la plus grosse jamais vue, si j’ai bonne mémoire) s’en approchait.
Au moins une partie provient de l’intégration très longtemps retardée d’overlayfs, que j’ai déjà mentionné dans le message de publication de la RC-1 comme étant en attente. Voyons quelles sont toutes les retombées que tout cela génère, mais ça aura duré longtemps (entre autres, parce qu’il avait besoin de différentes choses dans les couches VFS pour être intégré proprement), et je pense que c’est en bonne voie. Touchons du bois.

Donc, au moins en partie en raison de l’intégration d’overlayfs, près du tiers du correctif est du système de fichiers. Mais ce n’est pas dû qu’à overlayfs, cependant ; il y avait une demande d’intégration tardive pour ext4 qui, je pense, est en fait plus grosse, en partie à cause d’un ré‐usinage de code.

Le reste correspond à des mises à jour de pilotes plus usuelles (thermique, watchdog, cible SCSI, ACPI & gestion de l’alimentation, mises à jour diverses) et des mises à jour d’architectures (ARC, BRAS, PowerPC, MIPS, x86). Un peu de documentation et des mises à jour de fichiers en‐têtes viennent compléter le reste.

Le résumé ci‐joint pour les détails, je crois qu’il respecte toujours les contraintes de taille de la liste de diffusion.

Linus

RC-3

La version RC-3 est sortie le 2 novembre 2014 :

Une autre semaine, une autre RC, et les choses ne s’affinent pas vraiment de la manière que j’aurais espérée…

Bien que le correctif lui‐même soit beaucoup plus petit que ne l’était la RC-2 (pas de nouveau système de fichiers dans cette RC !), il y a en fait plus de modifications et plus de fichiers concernés. Il y en a partout, en plus.

Cela dit, je ne pense pas qu’il y ait quoi que ce soit de particulièrement horrible ici. Beaucoup, beaucoup, de petits trucs, avec des pilotes qui représentent la majorité de ce vrac (à la fois en termes de nombre de modifications et de lignes de code), mais le réseau et le cœur du noyau sont également présents dedans. Rien de particulier ne se démarque.

Le résumé des rapports de modifications ci‐joint pour plus de détails, s’il vous plaît, allez le tester.

Linus

RC-4

La version RC-4 est sortie le 9 novembre 2014 :

Eh, finalement, les choses se calment. En fait, ça avait vraiment l’air calme jusqu’à hier, au moment où certaines personnes ont soudain réalisé : « Eh, je pourrais envoyer mes trucs à Linus pour qu’il les mette dans la RC-4 ». Du coup, un tiers de tous les changements est arrivé le dernier jour, mais malgré cela, les choses semblent enfin se mettre en place, et nous parviendrons à la stabiliser en fin de compte.
En espérant que la tendance se maintienne…

Les choses semblent assez habituelles. Un peu plus de la moitié concerne des pilotes, et près d’un tiers sont des correctifs d’architectures (ARM, MIPS, PowerPC et s390). Le reste est constitué de quelques mises à jour de systèmes de fichiers (principalement XFS) et des trucs divers.

Le résumé du journal des modifications permet de se faire une bonne idée des détails, et rien ne semble particulièrement effrayant ni étrange.

Linus

RC-5

La version RC-5 est sortie le 16 novembre 2014 :

Hum. Nous avons eu une RC-4 très calme, et j’aurais aimé pouvoir dire que les choses ont continué à se calmer, mais… Ouais, la RC-5 est nettement plus grande que la RC-4. Tant pis.

Ce n’est pas comme si ça dépassait les bornes, même si la RC-4 était vraiment petite. Et les changements ne sont pas particulièrement étranges ni effrayants : environ 55 % de pilotes (réseau, pilotes graphiques, crypto, thermique, son), 15 % pour l’architecture (Xtensa, x86, ARM[64], PA-RISC, SPARC), et le reste est principalement un mélange de mises à jour du réseau, des systèmes de fichiers, des machines virtuelles, de la documentation et du traçage.

Les modifications tendent à être assez petites et explicites, et environ un tiers d’entre elles sont déclarées stables. Donc, nous avons encore quelques questions en suspens, mais les choses semblent assez normales. Il nous reste encore quelques semaines avant le final, et plus vous pourrez tester, mieux ce sera.

Linus

RC-6

La version RC-6 est sortie le 23 novembre 2014 :

Des progrès constants nous amènent vers la version finale, même si nous avons encore un gros souci non élucidé dans une régression que Dave Jones a signalée et que nous n’avons pas encore résolu. Dans notre processus de traque, on a regardé un bon paquet de détails divers de bas niveau et cela a révélé quelques points litigieux, mais encore aucune preuve irréfutable. Mais cela explique certains des correctifs de la RC-6…

La bonne nouvelle est que les choses se calment dans l’ensemble, et la plupart des modifications sont ici des corrections d’assez petites régressions, avec une poignée de correctifs stables. Près de la moitié de pilotes (réseau, son, PCI, InfiniBand, etc.), avec des mises à jour d’architectures (x86, MPIPS, ARM), et le code réseau représentant environ la moitié du reste. Et le dernier quart est « divers » : corrections de systèmes de fichiers, documentation, ordonnanceur…

Il y a assez peu de code qui a changé, et s’il n’y avait pas le problème en suspens de DaveJ, je serais probablement parfaitement heureux. Nous verrons comment tout cela se déroulera ; mais en attendant, plus ceci pourra subir de tests, mieux ce sera.

Donc, allez‐y, secouez‐moi ça,

Linus

RC-7

La version RC-7 est sortie le 30 novembre 2014 :

Les choses se calment gentiment et tout semble assez normal. En fait, s’il n’y avait pas les questions en suspens avec les blocages étranges du watchdog (et peut‐être le RCU), je serais assez heureux. En soi, ce n’est pas une régression de la 3.17, mais c’est toujours très inquiétant.

En même temps, avec l’arrivée des vacances et le problème qui n’est pas une régression, je suppute que ce qui arrivera, c’est que je sortirai la version 3.18 à l’heure dans une semaine, parce que la retarder perturbera la phase d’intégration et les fêtes de fin d’année, ou alors je devrai beaucoup la retarder.

Nous verrons… Peut‐être que DaveJ pourra le résoudre par dichotomie, maintenant qu’on a montré que « la 3.17 était OK » était une fausse piste (en fait, il semble que le problème se soit glissé entre la 3.16 et la 3.17).

C’est ennuyeux, parce que, comme mentionné, le reste semble fonctionner correctement. Le correctif RC-7 semble tout à fait normal, les deux tiers étant des pilotes (un peu sur tout : USB, réseau, staging, thermique, pilotes graphiques, son…) et la moitié du reste concernant des mises à jour d’architectures (principalement MIPS, ARM et PowerPC). Le reste est principalement des corrections du réseau et des systèmes de fichiers (NFS et Btrfs).

Linus

Version finale

La version finale est sortie le 7 décembre 2014 :

Ce fut une semaine calme, et le correctif depuis la RC-7 est minuscule, donc le 3.18 est sorti.

J’aurais adoré annoncer que nous avons compris le problème qui empoisonne le 3.17 pour une poignée de gens, mais nous n’y sommes pas parvenus. En même temps, il n’y a absolument aucune raison que tout le monde se tourne les pouces pendant que quelques‐uns tentent ardemment de dichotomiser un ancien problème. Par conséquent, retarder la publication n’était vraiment pas pertinent. D’autant plus que ça aurait ensuite fait traîner les choses pendant toute la période des vacances.

La fenêtre d’intégration du 3.19 est donc ouverte, et espérons que DaveJ aura achevé sa dichotomie (ou au moins que les hypothèses soient suffisamment restreintes pour que l’on atteigne le moment du « Ahaa ! ») au cours de la semaine prochaine. Mais, en solidarité avec Dave (et aussi pour rendre ma vie plus facile ;), essayons d’éviter d’introduire tout nouveau méchant problème. D’accord ?

Linus

Les nouveautés

Architecture

La compilation à la volée des programmes de l’extended Berkeley packet filter (eBPF) est maintenant prise en charge sur l’architecture ARM64 (Cf. article sur le site LWN.net).

Prise en charge des nouvelles puces ARM

Cette nouvelle version inclut, comme d’habitude, la prise en charge de nouvelles puces ARM. Nous parlerons ici des plus importants, ainsi que des changements notables au niveau du device tree pour ARM.

L’Atmel SAMA5D4 dispose d’une prise en charge basique. il s’agit d’un système monopuce (SoC) basé sur le ARM Cortex A5, orienté haute performance et basse consommation énergétique. Il intègre un décodeur matériel pour l’affichage en 720p, un contrôleur mémoire DDR qui offre une bande passante allant jusqu’à 1 408 Mio/s, un co‐processeur pour le calcul flottant (FPU), un co‐processeur vectoriel NEON (SIMD), 3 ports USB high‐speed, deux contrôleurs réseau Ethernet 10/100 Mbit/s, un contrôleur vidéo LCD, une interface pour une caméra et bien plus. En consommation maximale, il est annoncé en dessous de 150 mW.

Du côté d’Allwinner, nous pouvons évoquer une première prise en compte des cartes Olimex A20-OLinuXino-LIME, ainsi que de la Merrii Hummingbird A20. La Olimex A20-OLinuXino-LIME est une carte de développement disposant d’un système monopuce Allwinner A20 double cœur ARM Cortex A7 cadencé à 1 GHz, de 512 Mio de mémoire vive DDR3, un processeur graphique ARM Mali 400, un connecteur SATA, un connecteur HDMI gérant des résolutions en HD 1080p.
La Merrii Hummingbird A20, quant à elle, dispose également d’un système monopuce Allwinner A20 double cœur ARM Cortex A7 cadencé à 1 GHz, de 1 Gio de mémoire vive, 4 Gio de mémoire Flash NAND interne, Ethernet Gigabit, un connecteur SATA, un lecteur de carte microSD…

Nous pouvons également mentionner quelques changements au sein de l’arborescence matérielle device tree. Quelques définitions de systèmes monopuces ont changé de licence, passant de la GPLv2 à une double licence GPLv2/X11, ce qui permet de faciliter leur réutilisation sans imposer d’héritage de licences.
Les prises en charge de l’horloge temps réel, d’un contrôleur DMA, ainsi que d’un contrôleur MMC ont été ajoutées à la définition du sun8i. Les contrôleurs MMC et i2c sont activés et utilisés sur les Ippo Q8H-V5 et bien d’autres. Je vous invite à voir les changements dans le commit de fusion.

Concernant les systèmes monopuces Rockchip, nous pouvons mentionner l’ajout de nouvelles horloges processeur au sein du pilote des horloges des Rockchip, il s’agit principalement de modifications pour la prise en charge des derniers RK3288.
Le pilote Ethernet arc bénéficie d’un pilote spécifique pour les systèmes monopuces RK3188 et RK3066 (que l’on peut trouver dans la Radxa Rock ou la Marsboard, par exemple). Ceci leur permet, d’intégrer la prise en charge de la couche physique Ethernet concernant la vitesse de communication entre le contrôleur EMAC et le contrôleur Ethernet, de gérer correctement les régulateurs de tensions, ainsi que les horloges MDIO.
Enfin, un pilote pour le circuit de gestion de l’énergie (PMIC) RK808 de Rockchip a été ajouté. Celui‐ci est notamment présent dans la carte d’évaluation du RK3288 ou certaines cartes qui possèdent cette puce.

Une prise en charge préliminaire pour les systèmes monopuces MesonX/Meson6 de chez Amlogic fait son entrée dans le noyau. Amlogic AML8726-MX (nom de code Meson6) est un microprocesseur haute performance destiné aux applications multimédia et aux appareils multimédia connectés à Internet (Multimedia Internet Devices — MID). Il intègre deux cœurs ARM Cortex A9 cadencés à 1,5 GHz, un co‐processeur SIMD NEON, un processeur graphique ARM Mali 400, un décodeur matériel permettant d’aider au décodage des vidéos en 1080p.

L’ordinateur Acer Chromebook 13 CB5 dispose d’une prise en charge au sein du device tree. Il s’agit d’un ultra‐portable équipé d’un NVIDIA Tegra K1 quadri‐cœur ARM Cortex A15 cadencé à 2,1 GHz, de 4 Gio de mémoire vive et d’une carte graphique à architecture Kepler. Il est livré sous ChromeOS.
Parmi les autres changements notables au sein du device tree pour Tegra, on peut citer l’ajout de la gestion SATA et PCIe pour les Tegra124, ainsi que leur activation sur la Jetson TK1 et l’activation du pavé tactile pour les Venise 2.

Les changements non évoqués sont consultables dans le commit de fusion, consultable ici.

ACPI et gestion d’énergie

Le principal changement dans la gestion de l’ACPI est sur les machines Apple : le microprogramme change de comportement selon que le système d’exploitation annonce être _OSI("Darwin") ou autre chose. Par exemple, il désactive les ports Thunderbolt, à moins que le système fonctionne sous OS X. Linux s’annonce donc maintenant comme Darwin sur ces machines.

Gestion du bus PCI sur les processeurs ARM 64 bits

Après onze versions de Linux, la gestion des bus PCI sur les processeurs ARM 64 bits vient d’être achevée. Il est maintenant possible d’utiliser cette fonctionnalité avec trois ponts PCI (AppliedMicro X-Gene, TI Keystone, Xilinx AXI).

Pour plus d’informations, vous pouvez consulter la demande d’intégration.

Mise en veille et réveil plus rapide

Ouah, on a gagné jusqu’à 100 ms par cœur de processeur lors du processus de mise en veille et de réveil. En effet, un temporisateur de 100 ms était utilisé pour attendre le réveil, et Lan Tianyu, d’Intel, l’a remplacé par un vrai signal. Ça n’a l’air de rien, mais sur un simple quadricœur on arrivait déjà presque à une seconde ; alors, pensons à ce joli serveur à 48 cœurs qui va pouvoir se réveiller en 5 secondes de moins !

Architecture SPARC64

La quantité de mémoire adressable sur l’architecture SPARC64 a été considérablement augmentée grâce à l’utilisation de tables de pages à quatre niveaux.

Développeurs

Mailbox

Une nouvelle API fait son entrée dans cette version pour utiliser les capacités matérielles de communication inter-processeurs. Pour un peu plus d’informations, vous pouvez consulter la documentation écrite à son sujet.

Correction de l’appel système fanotify_init()

L’interface de programmation fanotify met à disposition un ensemble de fonctions qui permettent d’être notifié et d’intercepter les événements de systèmes de fichiers. Surveiller un dossier hiérarchisé ou un fichier ciblé peut faire partie des cas d'utilisations.
fanotify_init est un appel système associé à cette interface. Il permet d'initialiser un groupe fanotify et retourne un descripteur de fichier correspondant à la file d’événements que l'on peut manipuler par la suite via l'interface de programmation correspondante, comme par exemple fanotify_mark.

Jusqu'à présent, cet appel système contenait une limitation. Lorsque les drapeaux leur étant passés en paramètre au travers de la variable flags contenait le drapeau O_CLOEXEC, celui ci était tout simplement ignoré. Reste à savoir s'il s'agit d'une action volontaire ou d'un oublie… Ce problème est désormais corrigé. Il est demandé à tout les développeurs dont les applications peuvent utiliser ce drapeau de façon silencieuse ou qui travaillent tout simplement avec cette interface de vérifier leur code afin de ne pas introduire d'effets de bords non désirés.

Quelques fonctions variables par processeur marquées obsolètes

Quelques fonctions qui permettent d’accéder à des variables locales au processeur ont été marquées obsolètes, il s’agit de __get_cpu_var() et de __this_cpu_ptr(). L’usage de ces fonctions est à remplacer respectivement par this_cpu_ptr() et raw_cpu_ptr(). Je ne décrirai ici que les nouvelles fonctions.

this_processeur_ptr() et raw_processeur_ptr() sont des fonctions qui permettent d’accéder à un pointeur qui est propre au processeur depuis lequel la fonction est appelée. Ceci est notamment possible grâce aux registres de segments sur les architectures x86 ou des registres internes spécifiques qui contiennent le début de la zone mémoire dédiée au processeur courant. Ces fonctions permettent d’ajouter un décalage à l’adresse de base par processeur contenue dans ces registres spéciaux, et encodent cette opération de calcul d’adresse directement dans l’instruction de l’opération d’accès à la variable par processeur.

Cela permet notamment de résoudre pas mal de problèmes d’atomicité d’accès à des données sensibles, entre le moment où l’adresse est calculée et où la donnée est modifiée. Cela est d’autant plus intéressant concernant la lecture ou l’écriture de ces variables. Bon nombre d’instructions sont garanties atomiques car le processeur signale par un verrou matériel sur le bus mémoire qu’il est en train d’écrire ou lire une donnée. L’usage de telles instructions évite d’avoir à utiliser des moyens de synchronisation (type mutex, spinlock…) car elles sont atomiques et non conflictuelles. En revanche, lorsqu’elles sont utilisées de façon assez agressive, elles ont tendance à provoquer de la contention sur le bus. L’utilisation des fonctions évoquées dans cette section est donc très intéressante, car, comme les données sont garanties uniques par processeur, il n’y a pas besoin de mettre un verrou matériel sur le bus. Ceci est très intéressant en termes de performances sur des machines qui disposent de plusieurs cœurs.

D’autres fonctions « this_cpu() » sont disponibles dans le noyau. Je vous invite à lire la documentation pour plus de détails.

LLVM

Vingt‐six correctifs ont été intégrés pour améliorer la prise en charge de LLVM/Clang, en partie pour l’architecture ARM64 et les modules de cryptographie.

Une partie des correctifs consiste à remplacer les tableaux de taille variable dans les structures (Variable Length Array In Struct ou VLAIS. Cf. présentation à la Linux Plumbers Conference 2013) par un équivalent valide dans le standard C99 (correctifs : [1], [2]…).

Vidage mémoire des périphériques

Les périphériques que nous utilisons sont en général pilotés par un pilote depuis le noyau. Certains ont toutefois un micrologiciel directement dans la mémoire du périphérique, qui permet de réaliser des tâches complexes côté matériel (si vous me permettez l’expression). Lors du chargement du pilote au sein du noyau si celui‐ci le demande, le noyau Linux peut charger à la volée un micrologiciel directement dans la mémoire du périphérique. C’est notamment à ça que sert le projet linux-firmware.

Il arrive toutefois, comme le code logiciel au sein des pilotes de votre noyau, que celui du micrologiciel soit bogué ou fonctionne mal. Ceci rend la tâche beaucoup plus complexe aux développeurs, car cela peut concerner des parties matérielles non couvertes par la fiche technique, et il est parfois difficile de savoir dans quel état le périphérique se trouve.

Une fonctionnalité de vidage mémoire (coredump) de périphérique vient d’être ajoutée à cette nouvelle version. Ceci permet de récupérer une image binaire de l’état dans lequel votre périphérique se trouve.

Il s’agit d’un mécanisme générique de récupération des données dans la mémoire du périphérique, et non d’une image ou d’un format en particulier (qui varie d’un matériel à l’autre). Ceci est exposé dans sysfs via l’interface /sys/class/devcoredump/devcd*/. Je vous invite à regarder le commit en question pour de plus amples informations.

Modules compressés

Il était déjà possible de manipuler des modules noyau compressés par l’intermédiaire de module-init-tools (gzip) ou de kmod (gzip, xz). Les développeurs de distributions, ainsi que les bidouilleurs du dimanche n’auront plus besoin de mettre en place des procédures de compression automatique durant un déploiement, ceci vient d’être ajouté à kbuild (le système de construction du noyau).

Ce correctif rajoute une option à kconfig dans la section Enable loadable module support, et vous propose le choix de compresser avec xz ou gzip.
Ainsi, dès lors que vous lancez la commande make modules_install, vos modules seront automatiquement compressés après installation. Il est toutefois suggéré d’utiliser gzip pour les périphériques embarqués, certes moins efficace en termes de compression, mais bien plus rapide comparé à son homologue xz.

Paramètres de modules non sûrs

Il arrive parfois que certains modules exposent des paramètres de débogage ou de test pour les développeurs, s’avérant peu utiles voire dangereux pour les utilisateurs. Il serait pour cela pratique que des messages d’avertissement retiennent l’attention de l’utilisateur lorsqu’il examine ses journaux noyau. Deux fonctions ont été ajoutées pour remédier à ce problème, il s’agit de _module_param_unsafe() et _module_param_named_unsafe().

Lorsque des paramètres module exposés au noyau par l’intermédiaire de ces fonctions sont manipulés depuis l’espace utilisateur, cela mettra le noyau dans un état spécial, de corruption, que l’on appelle dans le jargon linuxien : kernel tainted.

Il s’agit d’un état dans lequel le noyau peut se mettre lorsqu’un module propriétaire est chargé ou qu’une action qui n’a pas lieu d’être est utilisée. Cela peut bloquer certaines API ou fonctionnalités du noyau dans certaines conditions et permet aux développeurs noyau de savoir s’il s’agit d’une utilisation ou d’un bogue dont ils doivent se soucier. Cela permet également d’informer l’utilisateur si ce qu’il est en train de faire est pris en charge par la communauté en cas de problème.

Résolveur de références au sein du device tree

Le device tree est une fonctionnalité qui permet de décrire la topologie matérielle de la carte embarquée sur laquelle le noyau s’exécute et lui donne des informations précieuses concernant la façon dont les composants matériels sont configurés et comment les exploiter. Par exemple, quelles broches GPIO utiliser en tant qu’interruption pour un périphérique, ou encore quelle est l’adresse de base physique MMIO d’un contrôleur dans la mémoire. Ainsi, un grand nombre d’informations spécifiques à la carte embarquée se retrouve au sein de ce device tree, et permet en plus de donner du contexte au noyau pour se retrouver avec du code pilote beaucoup plus générique et beaucoup plus maintenable. En effet, avec un tel mécanisme, le code des pilotes se focalise sur le fonctionnement du périphérique lui‐même et n’a pas besoin de contenir des dizaines de variantes en fonction de la carte utilisée, ceci est maintenant factorisé et sorti du code (du moins quand cela est possible).

En général, cela se présente sous la forme d’un fichier ayant une extension .dts contenant la topologie matérielle sous forme d’arborescence dans laquelle chaque pilote de périphérique (device driver) contient un nœud, que l’on appelle un device node. Chaque nœud dispose de propriétés et peut contenir à son tour des sous‐nœuds. Ces définitions et descriptions représentent généralement l’architecture matérielle de la carte. Au sein de ce même fichier, les nœuds peuvent se référencer les uns avec les autres, ce qui permet d’exprimer des contraintes matérielles (par exemple, mon contrôleur de NAND à besoin du SPI 0). Ces référencements sont exprimés en attribuant le nom d’une variable du nœud cible à une propriété du nœud qui en dépend. On appelle une telle référence, un phandle, une adresse de device node au sein du device tree en quelque sorte.
Ce fichier est ensuite compilé en un device tree blob par le compilateur device tree compiler (appelé dtc, oh yeah !) et chargé par le noyau. C’est dynamiquement que celui‐ci est interprété par les pilotes qui en ont besoin, en utilisant la bibliothèque device tree prévue à cet effet. Je vous invite à consulter le site devicetree.org pour plus de renseignements.

Oui, mais… c’est certes très pratique, mais quand même très statique. Qu’en est‐il des cartes disposant de plusieurs cartes d’extension, ou de certaines à base de processeurs ARM contenant des FPGA et complètement programmables ? Doit‐on définir un device tree par carte et par configuration ? Cela deviendrait rapidement non maintenable. C’est la raison pour laquelle, les mainteneurs de ce composant au sein du noyau ont commencé à étudier le sujet sérieusement.
L’idée serait d’avoir un device tree de base, chargé par le noyau au démarrage et de pouvoir par la suite venir y greffer dynamiquement, soit la portion d’un device tree par dessus, soit venir changer ou modifier à chaud une partie de celui‐ci chargée en mémoire. Cela serait très pratique pour les développeurs qui souhaitent tester rapidement un changement sans avoir à tout recharger, ou pour commencer à répondre aux problématiques ci‐dessus (par exemple, une portion de device tree par carte d’extension, que l’on greffe par dessus celui de la carte de base).

Une première partie, consiste à intégrer un solveur de portions de device tree au sein du noyau. Vous rappelez‐vous des phandles dans le paragraphe précédent ? Un nœud est capable d’en référencer un autre, en fonction des besoins du pilote lui étant associé ; pour ce faire, le noyau doit être en mesure de résoudre ce référencement sur les portions de device tree insérées à chaud. Il s’agit d’un solveur de références au sein du device tree. Cette prise en charge vient d’être ajoutée au noyau 3.18. C’est le début d’une suite assez intéressante de fonctionnalités.

Miniaturisation

Aujourd’hui, le noyau Linux est capable de tourner sur à peu près n’importe quoi, allant de l’objet connecté et des cartes de développement de type BeagleBone Black jusqu’aux super‐calculateurs. Qu’en est‐il des vrais systèmes embarqués avec des contraintes de tailles et de ressources ? Par exemple, des cartes avec des systèmes monopuces STM32 ou EFM32 qui ne disposent que de 1 Mio de mémoire vive, voire de quelques kibioctets.

Le noyau Linux a vu son empreinte mémoire minimum augmenter au fil des versions, chose qui a rarement diminué avec le temps. Ceci rend la tâche difficile aux développeurs qui ne disposent que de quelques kibioctets pour faire tourner l’intégralité de leur système, ainsi que leurs applications. Dans des cas comme celui‐ci, ils peuvent se tourner vers des alternatives libres comme FreeRTOS ou Contiki, voire des systèmes propriétaires. Et c’est ici qu’est le problème. Pourquoi le noyau Linux, ne pourrait‐il pas répondre à un tel besoin ?
Outre le fait que Linux nécessite une unité de gestion mémoire (MMU) pour pouvoir fonctionner, des alternatives libres basées sur la branche principale du noyau ont vu le jour, c’est le cas de µCLinux.

Ce fut le sujet de l’une des présentations de Josh Triplett au Kernel Summit 2014. Même si certains développeurs ont l’air de suggérer d’utiliser un noyau 2.4, ceci n’est pas une vraie solution sur le long terme. Pourquoi ces plates‐formes ne pourraient‐elles pas bénéficier d’une prise en charge par le noyau actuel ?

C’est la raison pour laquelle le site tiny.wiki.kernel.org a été mis à disposition. Il regroupe toutes les modifications qui sont à faire afin de minimiser le noyau et contient des informations relatives à ce projet.

Cela n’a pas été mentionné, mais depuis la version précédente, la commande make tinyconfig a été ajoutée. Elle permet de compiler un noyau minimal et vous laisse ensuite la possibilité d’ajouter uniquement ce dont vous avez besoin. Malheureusement, ceci n’est pas encore suffisant. Beaucoup de choses peuvent être optimisées au sein du noyau, afin de réduire la taille de l’image et son empreinte mémoire.

Dans cette version, pas mal d’améliorations et de correctifs ont été acceptés à ce sujet. Vous pouvez suivre l’état des choses à faire directement sur la page du site du projet.

Temps réel

Il y a un an Thomas Gleixner, mainteneur et développeur principal du projet Linux temps réel (ou PREEMPT_RT), alertait sur le manque de soutien de la part des industriels l’utilisant. Un an plus tard, malgré les efforts de la Linux Foundation et de l’OSADL, la situation n’'ayant pas évolué, il annonce que la maintenance de ce correctif sera maintenant effectuée à titre de hobby.
Apparemment les industriels ont préféré jouer à « le premier qui bouge (paye) a perdu » mais au final, ils risqueraient bien d’être tous perdants.
Il est alors fort probable, au vu de la vitesse d’évolution du noyau que ce projet prenne rapidement beaucoup de retard et soit de plus en plus difficile à maintenir.

Pilotes graphiques libres

DRM (Direct Rendering Manager)

La modification la plus importante de DRM concerne la gestion de l’intervalle de suppression de trame (vblank). Auparavant, celle‐ci était désactivée quelques millisecondes après qu’aucun client n’ait demandé de synchronisation avec elle. Dorénavant, le comportement par défaut est de la désactiver immédiatement. Cela permet d’économiser de l’énergie en évitant de recevoir des interruptions non nécessaires. Ce comportement est possible pour tous les matériels possédant un horodatage matériel précis. Pour plus d’informations, vous pouvez consulter la demande d’intégration de cette série de correctifs.

David Herrmann et Daniel Vetter ont assaini les fichiers d’en‐tête de DRM, afin de mieux délimiter les fonctions préservées par souci de respect de l’API, mais qui ne devraient jamais être utilisées par un nouveau pilote. Ils ont également profité de cette opération de nettoyage pour exposer au pilotes DRM le moins possible des structures internes à DRM. Pour l’anecdote, lors de la relecture de ces correctifs, nous avons envoyé deux correctifs ([1] et [2]) triviaux pour corriger des erreurs dans les commentaires. Ces correctifs ont été fusionnés pour Linux 3.19. La morale est que si vous voyez des erreurs, même si elles sont triviales, envoyez des correctifs !

L’infrastructure commune s’améliore également sur la question de la gestion du mode d’affichage atomique. Cela inclut la prévention d’interblocages dans le tampon de trame Linux (fbdev) qui pouvaient déjà arriver avec les noyaux actuels, mais vont devenir bien plus courants lorsque plus d’applications vont demander des changements.

Du côté de TTM, le système de synchronisation par barrière a été revu et unifié à travers tous les pilotes utilisant TTM. Cela devrait améliorer la synchronisation entre plusieurs pilotes graphiques, comme cela est nécessaire pour les ordinateurs portables utilisant la technologie Optimus. Pour plus d’informations, vous pouvez consulter la demande d’intégration.

Pour plus d’informations sur les modifications apportées dans DRM, vous pouvez consulter la demande d’intégration DRM.

AMD/ATI (pilote Radeon)

La partie DRM du pilote Radeon fait encore de gros progrès, avec l’activation du décodeur vidéo matériel UVD pour le H.264 sur d’anciennes cartes (3xxx et 48xx).

Après avoir corrigé un problème avec la gestion d’énergie dans la famille Cayman dans Linux 3.17, un utilisateur a pu vérifier que les familles Nothern Island, Southern Island, Canary Island et BTC n’étaient plus touchées par ce problème (rapport de bogue). Ces puces gèrent maintenant mieux le DPM.

Pour finir, quelques correctifs pour la gestion du son via l’interface HDMI ont été proposés.

Pour plus d’informations, vous pouvez consulter la demande d’intégration Radeon.

Intel (pilote i915)

Le pilote DRM i915 a enfin reçu les derniers correctifs afin d’activer la gestion du PPGTT (Per‐Process Graphics Translation Table) qui permet d’isoler les différents clients graphiques dans différents espaces d’adressage. Du moins, c’était avant que plus de tests mettent en avant d’autres bogues, ce qui a conduit à sa désactivation. Ces bogues ont normalement été corrigés et espérons que la gestion du PPGTT sera enfin disponible dans Linux 3.19 !

Du côté de l’affichage, la gestion de la rotation de plans graphiques vient d’être ajoutée. La gestion du DRRS (dynamic refresh rate switching — commutation dynamique de fréquence de rafraîchissement) s’approche avec l’ajout des parties communes, le reste devrait arriver dans les noyaux suivants, ce qui devrait permettre de diminuer la consommation énergétique.

Du côté gestion du mode d’affichage, le code pour les puces i830M a été corrigé. La gestion de l’alimentation des panneaux eDP a également été revue et la gestion d’un nouveau mode d’établissement de lien DisplayPort a été ajoutée. Pour finir, plusieurs corrections de bogues ont été faites dans la gestion du HDMI, pour améliorer les résultats aux tests de conformité du standard.

Pour finir sur les modifications compréhensibles, la gestion de la commutation de pages a été améliorée pour mieux gérer les cas où le pilote ou le matériel a oublié un événement. Cela va permettre de ne pas voir son écran bloqué en attente d’un événement qui s’est déjà terminé !

Comme à son habitude, Daniel Vetter (mainteneur i915) a publié un compte‐rendu des modifications sur son blog, que vous pouvez lire pour plus d’informations. Vous pouvez aussi consulter la demande d’intégration i915.

NVIDIA (pilote Nouveau)

L’amélioration la plus visible dans Nouveau est l’ajout de la gestion du son avec les écrans DisplayPort (DP) (correctif). Cette fonctionnalité fait miroir à l’ajout du son sur HDMI, qui avait été ajouté dans le noyau 3.13.

Une autre amélioration visible dans Nouveau concerne les changements de fréquence d’horloge (reclocking — recadencement), notamment de la mémoire. Ce travail a été initié par Roy Spliet qui a travaillé pendant trois mois à plein temps durant l’été, dans le cadre du Google Summer of Code. Son travail a uniquement porté sur les puces GT21[568] (NVA[358]), mais il est maintenant possible de recadencer la majorité des cartes utilisant cette puce. Pour un compte‐rendu sur son projet, vous pouvez consulter sa présentation faite au XDC2014 qui s’est déroulée à Bordeaux en octobre. Grâce aux découvertes de Roy, Ben Skeggs a pu améliorer la gestion du recadencement dans la famille Kepler et, en outre, en a profité pour améliorer la gestion du recadencement de la mémoire.

Concernant la prise en charge de la première génération des processeurs graphiques Maxwell (puce GM107), celle‐ci s’améliore avec l’ajout de la gestion du ventilateur et de PDAEMON/PMU (système d’exploitation temps réel s’exécutant sur le processeur graphique ayant pour but de gérer l’énergie).

En vrac

Peu de changements du côté des pilotes DRM pour les systèmes monopuces.

La principale nouveauté est la gestion de la puce Samsung Exynos 3250 par le pilote exynos. Ce pilote a également changé son interface pour l’appel système mmap() et l’a remplacé par l’implémentation proposée par DRM. Pour finir, le pilote utilise maintenant la nouvelle interface DRM de gestion universelle des plans graphiques, afin d’exposer ses différents contrôleurs vidéo CRTC (partie du processeur graphique qui envoie les pixels à l’écran). Pour plus d’informations, voir la demande d’intégration exynos.

Du côté d’Adreno, la puce md4 se voit ajouter la gestion du protocole de communication LVDS, utilisé par les dalles LCD des ordinateurs portables. La gestion du panneau B101XTN01.0 a également été ajoutée. Pour finir, le pilote a commencé à être refactorisé, pour faciliter l’arrivée de la future famille de processeur Adreno. Pour plus d’informations, voir la demande d’intégration MSM.

Réseau

Transmission de paquets réseau en masse

Les améliorations de performance réseau dans cette version ont été fusionnées. Entre beaucoup d’autres choses, elles permettent à de relativement petits systèmes de gérer des interfaces rapides à leur vitesse réelle, même quand des petits paquets sont transmis. La performance des petits paquets a toujours été un problème pour Linux, c’est pourquoi c’est une amélioration importante.
Ce travail est limité en portée, en particulier, il ne va marcher qu’avec les files d’attente uniques. Éric Dumazet a regardé le correctif et a réalisé que cela pouvait être encore plus poussé : le processus de validation des paquets pour la transmission pouvait être déplacé complètement en dehors de la section critique de verrouillage de la file d’attente, ce qui améliore la concurrence dans le système. Les résultats du correctif ont des avantages qu’Éric décrit comme impressionnants : atteinte du débit théorique de l’interface de 40 Gbit/s, et ce, même en l’absence de gestion matérielle de la segmentation. De petits changements peuvent avoir de grands effets quand ils sont appliqués aux bons endroits.

Berkeley Packet Filter

Le nouvel appel système au Berkeley Packet Filter, bpf(), a été inclus. Il ne sert pour l’instant pas à grand chose, car il manque l’intégration aux sous‐systèmes de traçage et de filtrage de paquets notamment. Seul le cœur a été intégré, et consiste en une « machine virtuelle universelle » qui est maintenant disponible dans le noyau. Plus de détails sont disponibles dans l’article sur le site LWN.net [correctifs: [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], documentation dans les sources du noyau].

Foo-over-UDP

Le sous-système Foo‐over‐UDP a été fusionné. Il permet d’encapsuler arbitrairement n’importe quel protocole dans un tunnel UDP. Le choix s’est porté sur UDP, parce que beaucoup d’interfaces réseau disposent désormais d’une gestion matérielle pour UDP, qui gère notamment le calcul des sommes de contrôle des paquets. Le protocole UDP n’ajoute pas non plus trop d’informations, puisque seuls une adresse et un numéro de port sont nécessaires, ce qui n’augmente pas beaucoup la taille du paquet.

Il est aussi possible de faire fonctionner UDP avec le Receive Side Scaling (RSS) et l’Equal-cost multipath routing protocol (ECMP) (documentation du noyau : Scaling in the Linux Networking Stack), ce qui permet d’augmenter les performances dans certaines configurations (forte redondance des connexions entre deux systèmes, par exemple).

Les avantages des tunnels sur UDP sont si importants que certains développeurs pensent qu’ils vont devenir omniprésents dans les prochaines années. Plus de détails et un exemple de mise en place d’un tel tunnel sont disponibles dans l’article sur LWN.net.

DCTCP congestion control algorithm

Un nouvel algorithme de gestion de la congestion pour le protocole TCP a été intégré. Nommé Data Center TCP (DCTCP), il est, comme son nom l’indique, préposé à des cas d’utilisation fréquemment rencontrés dans les réseaux stables et fortement connectés des centres de données. Plus de détails sur le site Web dédié et le commit du correctif.

Generic Network Virtualization Encapsulation (Geneve) protocol

Le protocole Generic Network Virtualization Encapsulation (Geneve) est désormais pris en charge. Plus d’informations sont disponibles dans le brouillon IETF.

Sécurité

L’appel système prctl() gère une nouvelle opération PR_SET_MM_MAP, qui permet de définir l’agencement d’un certain nombre d’éléments essentiels d’un processus : l’endroit où sont localisés les données et le code, l’emplacement auquel démarre la pile, etc. Cette fonctionnalité est nécessaire pour le projet CRIU, lorsqu’il est utilisé en combinaison avec les espaces de noms [correctif].

Cryptographie

Le module effectuant les opérations cryptographiques peut tirer avantage des extensions matérielles permettant d’effectuer un même calcul sur plusieurs tampons simultanément. Pour commencer, l’infrastructure a été ajoutée, ainsi qu’une implémentation pour SHA1 utilisant les extensions AVX2 (correctifs : [1], [2], [3], [4], [5], [6]).

LSM

De nombreux bogues liés à l’utilisation de SMACK et de IMA & EVM simultanément sont corrigés dans cette version.
Comme les fonctions security_file_set_fowner(), f_setown() et __f_setown() retournaient toujours 0, elles n’ont maintenant plus de code de retour [correctif].

IMA & EVM

Les options liées à l’intégrité sont mieux présentées dans le menu Kconfig (correctifs : [1], [2]).

Un nouveau mode d’utilisation d’IMA a été ajouté : log. On l’utilise en précisant ima_appraise=log comme option au noyau. Les précédents modes (off, enforce et fix) n’étaient pas suffisants, car ils ne permettaient pas de voir l’ensemble des accès interdits sans les corriger automatiquement (mode fix). Le mode log laisse donc l’administrateur analyser le système en autorisant tous les accès, mais en écrivant toutes les erreurs dans le journal [correctif].

Une situation de compétition potentielle a été corrigée lors d’un accès à un même nœud d’index (inode) par deux processus simultanément [correctif].

Une nouvelle variable a été introduite pour permettre de gagner en performance dans certains cas [correctif].

Les violations d’intégrité faites à partir de correspondances mémoire d’un fichier sont maintenant correctement détectées dans tous les cas [correctif].

Correction de divers bogues (correctifs : [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22]).

SELinux

SELinux ne tient pas particulièrement compte des espaces de noms (namespaces) lors des vérifications de contrôle d’accès. Mais dans le cadre des espaces de noms réseau, une petite amélioration de la gestion du cache a été faite pour que les interfaces virtuelles soient proprement associées à une interface réelle [correctif].

Jusqu’à présent, un processus avec les attributs NO_NEW_PRIVS ou NOSUID ne pouvait pas changer de contexte SELinux. Il le peut désormais, uniquement si le contexte de destination est plus restrictif que le contexte courant [correctif].

Correction de divers bogues (correctifs : [1], [2], [3], [4], [5], [6]).

SMACK

Le développeur de SMACK (Casey Schaufler) a toujours refusé de créer un mode permissif ressemblant à ce qui est fait avec SELinux, par peur de se retrouver dans la même situation (les administrateurs exécutant systématiquement setenforce 0 ou passant la totalité du système en mode permissif, alors qu’une seule application pose problème).

Il a donc créé un mode « mise en place » (Bring‐up access mode) qui permet d’enregistrer l’ensemble des permissions nécessaires à une application pour son bon fonctionnement. L’objectif étant que ce mode ne sera pas disponible sur les systèmes en production, mais uniquement sur les versions de développement. Les détails de l’utilisation de ce mode sont dans le message du correctif.

Une étiquette SMACK vide ne causera plus de kernel panic ! [correctif].

Correction de divers bogues (correctifs : [1], [2], [3], [4], [5], [6]).

Trousseaux de clés

Il n’est plus possible de créer de clés avec comme type un nom commençant par un point [correctif].

Correction de divers bogues (correctifs : [1], [2], [3], [4], [5], [6], [7], [8]).

Liste non exhaustive des vulnérabilités corrigées

Touche principalement KVM et les espaces de noms utilisateur :

• CVE-2014-3610 [correctif] ;
• CVE-2014-3611 [correctif] ;
• CVE-2014-3646 [correctif] ;
• CVE-2014-3647 (correctifs : [1] et [2]) ;
• CVE-2014-7970 [correctif] ;
• CVE-2014-7975 (correctifs : [1] et [2]) ;
• CVE-2014-8480 [correctif] ;
• CVE-2014-8481 [correctif].

Systèmes de fichiers

F2FS

Le système de fichiers F2FS gère maintenant les écritures atomiques (où une série d’opérations réussissent ou échouent comme une seule action) via un ioctl() spécifique à F2FS. Il a aussi gagné la prise en charge de l’opération FITRIM (discard).

OverlayFS

Le système de fichiers OverlayFS (cousin de UnionFS) a été intégré au noyau. Ce n’est pas véritablement un système de fichiers au sens propre, mais il peut être vu comme une surcouche de ceux‐ci. Il faut l’appréhender comme un système de calques permettant de superposer différentes couches de fichiers.
Il est utilisé sur les périphériques amorçables et autres systèmes en mémoires mortes (OpenWRT). Il est très utile pour les machines virtuelles répliquées.

UnionFS (Union File System) est un service du système de fichiers de Linux qui permet de fusionner plusieurs points de montage appelés « branches » : c’est une union de montages. L’utilisation habituelle de ce système est de fusionner une partition système en lecture seule avec une partition en écriture permettant d’enregistrer les nouveaux fichiers et fichiers modifiés, le système UnionFS se chargeant de ne présenter que la dernière version de chaque fichier [source : Union File System].

Voici les liens vers la documentation dans les sources du noyau, le correctif principal et tous les correctifs liés.

NFS

Le système de fichiers réseau NFS gère maintenant l’opération SEEK de la spécification NFS 4.2 (encore en cours de développement), permettant l’utilisation des options SEEK_HOLE et SEEK_DATA de lseek(2). Ces options permettent de se déplacer dans des fichiers contenant des trous (sparse files) (voir SEEK_HOLE and SEEK_DATA for sparse files).

Ceph

Le composant Rados chargé de la gestion des périphériques en mode bloc dans le projet Ceph gère désormais les requêtes discard. Pour rappel, ces requêtes permettent d’augmenter les performances et la durée de vie des disques SSD (TRIM).

Virtualisation

KVM

La RC1 a introduit plusieurs nouveautés pour les architectures de processeurs prises en charge :

• l’architecture des ordinateurs centraux IBM (mainframes s390) se prépare à prendre en charge les grandes pages mémoire pour l’hôte ;
• pour les PowerPC, le débogage a été amélioré (à la fois à partir de l’invité, via des registres spécifiques, et à partir de l’hôte via gdbstub) ; il y a aussi la prise en charge de la virtualisation pour les processeurs e65000 ;
• du côté de chez ARM(64), c’est la mémoire en lecture seule qui fait son apparition ; ceci permet d’émuler un micrologiciel dans une mémoire Flash de type NOR ;
• et pour le x86(_64), outre les traditionnelles corrections, on retrouve des améliorations de la virtualisation imbriquée avec une meilleure gestion de celle‐ci pour les processeurs Intel sous Windows, et un début de prise en charge de l’hyperviseur Jailhouse pour les AMD ; le retrait de mémoire à chaud devrait aussi mieux fonctionner, et un bogue assez rare de la gestion du cache a été corrigé.

Avec la RC2, est aussi venue une correction assez grosse qui corrige un bogue pour la virtualisation imbriquée qui permettait à l’invité imbriqué de crasher l’hôte non imbriqué.

Xen

La RC1 a apporté les nouveautés suivantes :

• ajout de pilotes SCSI para‐virtualisés (PVSCSI) ;
• amélioration de la contiguïté mémoire pour la para‐virtualisation ;
• prise en charge des gros initrd pour les invités para‐virtualisés ;
• adaptation des invités PVH en préparation de Xen 4.5 ;
• les pilotes vont pouvoir utiliser les interruptions en multi‐thread.

Le bilan en chiffres

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

En nombre de modifications, on se situe à 11 186, soit environ 1 000 modifications de moins que la version précédente du noyau. Le nombre de contributeurs est, quant à lui, de 1 428. Ce nombre est resté relativement constant sur la dernière année.

Le développeur ayant écrit le plus de modifications est H. Hartley Sweeten (237) pour son travail de nettoyage des pilotes Comedi. Du côté des développeurs ayant le plus modifié de lignes, on trouve des mainteneurs tels que Greg Kroah‐Hartman, ayant supprimé des pilotes, ou d’autres, comme Martin Peres et Roy Spliet, qui ont modifié des microcodes, ce qui a généré beaucoup de lignes modifiées dans des fichiers d’en‐tête. Ce classement est donc à prendre avec des pincettes.

Environ 200 entreprises ont participé à l’élaboration de ce noyau. En tête, on retrouve Intel, qui a effectué 10,9 % des changements que l’on peut trouver dans cette nouvelle version. En deuxième place, Red Hat a contribué 7,6 % des changements. Il est cependant important de noter que les développeurs sans affiliation ont effectué 11 % des modifications, soit juste un peu plus qu’Intel, alors que les personnes non identifiées ont écrit 7,3 % des modifications. On peut donc dire, bien que le noyau soit majoritairement écrit par des employés d’entreprises, que les contributeurs indépendants sont toujours les bienvenus et sont même une majorité !

Appel à volontaires

Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition :

	Mainteneur	Contributeur(s)
La phase de test	Aucun	Davy Defaud
Arch	Romain Perier	Mali
Développeurs	Romain Perier
Pilotes graphiques libres	Martin Peres
Réseau	Aucun	Timothée Ravier BRULE Herman
Systèmes de fichiers	Aucun	Timothée Ravier
Sécurité	Timothée Ravier
Virtualisation	Xavier Claude
Édition générale	Aucun	Martin Peres, Mali, M5oul et Davy Defaud

Un peu de vocabulaire :

• le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie, il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer ;
• un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche, sans aucune forme d’engagement pour le futur.

Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps et de volontaires.

Nous sommes particulièrement à la recherche de mainteneurs pour les sections Systèmes de fichiers et Réseau, les précédents n’ayant pas donné de signes de vie pendant la rédaction des dernières dépêches.

Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les commits intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau !

Aller plus loin

• Les noyaux précédents (478 clics)
• Site officiel du noyau Linux (315 clics)
• LWN : 3.18 Merge window part 1 (116 clics)
• LWN : 3.18 Merge window part 2 (67 clics)
• LWN : 3.18 Merge window part 3 (65 clics)
• Heise : Die Neuerungen von Linux 3.18 (41 clics)
• Kernel Newbies : Linux 3.18 (333 clics)