Sortie du noyau Linux 3.15

La sortie de la version stable 3.15 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.

Sommaire

• En bref
• La phase de test
  • RC-1
  • RC-2
  • RC-3
  • RC-4
  • RC-5
  • RC-6
  • RC-7
  • RC-8
  • Version finale
• Les nouveautés
  • Architecture
    • Gestion du mode mixte EFI
    • AVX-512
    • Améliorations de l’ordonnanceur
    • Abandon des anciennes plates-formes x86
    • Instruction RDSEED
    • Systèmes mono-puces ARM
    • ACPI
    • Changement de la taille de la pile du noyau
  • Pilotes graphiques libres
    • DRM (Direct Rendering Manager)
    • Adreno (pilote msm)
    • AMD/ATI (pilote radeon)
    • Samsung (pilote exynos)
    • Intel (pilote i915)
    • NVIDIA (pilote nouveau)
    • Poulsbo (pilote gma500)
    • Tegra (pilotes host1x et tegra)
    • VMware (pilote vmwgfx)
  • Réseau
    • À la recherche des performances
      • Une horloge plus fine
      • Réécriture de l’interpréteur interne BPF
      • Mettre à jour la somme de contrôle tout simplement
      • Protection contre les dénis de service
    • Sécurité réseau
      • cgroups et réseau
      • IPsec
      • Bluetooth
      • Commentons avec nftables
  • Sécurité
    • Audit
    • Gestion de l’Intel Trusted Execution Environment
    • LSM
      • SELinux
  • Systèmes de fichiers
    • Code commun
      • VFS
      • SATA
    • Ext3/4
    • XFS
    • Btrfs
    • F2FS
    • kernfs
    • ZRAM
    • En vrac
  • Virtualisation
    • KVM
    • Xen
• Le bilan en chiffres
• Appel aux volontaires

En bref

• Pilotes graphiques libres :
  • DRM : interface unifiée pour la gestion des plans graphiques ;
  • Radeon : gestion de l’encodage vidéo matériel et d’une nouvelle puce unifiée avec processeur graphique intégré (APU) ;
  • Nouveau : gestion initiale de la famille Kepler et meilleure gestion des ventilateurs.
• Réseau :
  • amélioration forte des performances ;
  • affectation de règles iptables à un cgroup.
• Systèmes de fichiers :
  • réduction du temps de réveil après une mise en veille en mémoire vive ;
  • nouvel appel système pour échanger les noms entre deux fichiers de façon atomique ;
  • verrous POSIX par fichier ;
  • ajout de la gestion de l’algorithme de compression LZ4 pour zram.

La phase de test

RC-1

La version RC-1 est sortie le 13 avril 2014.

Ça fait deux semaines que la 3.14 a été livrée et la 3.15-rc1 est maintenant étiquetée et publiée ; les correctifs et les archives tar » sont — au moment où j’écris ces lignes — en train de passer dans les compresseurs de kernel.org. Ce qui veut dire que la fenêtre de fusion est fermée et que les gens doivent m’envoyer uniquement des corrections de bogues.

Et franchement, il était temps. Cette version ne contient pas vraiment de choses bizarres, mais elle est grosse. Bien sûr, nous avons déjà eu des versions avec plus de lignes et de fichiers modifiés (3.7-rc1 et 3.11-rc1, notamment), mais celles-ci ont tendance à avoir quelque chose de particulier dedans (3.7-rc1 a vu la désintégration largement automatisée du fichier d’en-tête UAPI et la 3.11 a vu la fusion de la correction des bogues de Lustre).

En comparaison de ces grosses versions, 3.15-rc1 est seulement grosse. Pas de gros changement unitaire, mais seulement énormément de correctifs. Effectivement, il y a eu quelques intégrations de nouveaux pilotes (rtl8723au, notamment). Mais, même s’ils étaient gros, ils ne représentent pas la majorité des changements. Il y a seulement énormément de changements.

En fait, nous avons le plus grand nombre de correctifs dans l’histoire récente (peut-être depuis toujours), à un peu plus de 12 000 correctifs hors fusions (et environ 800 fusions).

Et il y en a vraiment un peu partout. L’essentiel concerne les modifications de pilotes, ce qui représente environ trois quarts des modifications. Le staging se démarque, mais c’est vraiment sur tout ​​le périmètre des pilotes, avec le réseau, le son, les médias, les pilotes graphiques, les pilotes de blocs…

Mais il y a aussi des tonnes de trucs qui ne concernent pas les pilotes. En dehors du sous-répertoire des pilotes, les mises à jour d’architecture comptent environ pour la moitié des changements (avec en tête ARM, principalement dû aux « device-tree descriptors ». Mais il y a aussi IPS, x86, PowerPC, s390, Blackfin…). Et le reste est aussi assez varié, avec le cœur du réseau, la documentation, le noyau, mm, les outils, etc.

Ainsi, alors que les modifications de pilotes et d’architecture représentent l’essentiel, nous avons aussi beaucoup de changement du cœur.

Quoi qu’il en soit, encore plus que d’habitude, la RC-1 est beaucoup trop grande pour inclure un résumé du rapport de toutes les publications. Mais le résumé du rapport des fusions que j’ai fait peut donner à minima une vue d’ensemble de tous les changements. Comme d’habitude, les personnes citées dans le rapport de fusion sont les mainteneurs depuis que j’ai récupéré les changements, et non les développeurs qui ont écrit le code. Vous pouvez voir ça dans les journaux complets de git.

Quoi qu’il en soit, comme la RC-1 est déjà sacrément grosse, je ne veux pas entendre de « désolé j’ai raté la fenêtre, puis-je encore me faufiler ? ». Corrections uniquement.

La seule exception concerne deux choses en cours qui sont arrivées pendant la fenêtre de fusion, mais qui ont été explicitement retardées. Nous avons donc en attente un mouvement de fichier fbdev (je ferai le mouvement du fichier après la RC-1, simplement pour que les choses soient plus simples à voir dans l’historique et ne pas mélanger les mouvements avec les développements). Et il y avait une demande de fusion sur les espaces de noms et montages que je n’ai pas intégrée, mais que je ferai probablement après quelques améliorations ou commentaires supplémentaires. Ça retardera probablement la 3.16, mais nous verrons de combien de lignes de code ce truc a besoin…

Linus

RC-2

La version RC-2 est sortie le 20 avril 2014.

« Et le septième jour la RC est ressuscitée, conformément aux Écritures du Kernel summit de l’année 2004. »

Cela fait une semaine, donc voici une nouvelle RC. Et alors que la RC-1 était de mémoire une des plus grosses RC, la RC-2 a l’air tout à fait normale. Nous avons eu quelques erreurs tenaces corrigées, mais ce n’était pas réellement quelque chose de pire que d’habitude. C’est peut‐être un peu plus gros que la plupart des RC-2, mais attendons de voir après la RC-3 quelles choses sont vraiment plus actives que d’habitude. La RC-2 est régulièrement plus calme que la RC-3, car il faut plus d’une semaine pour que certaines anomalies surviennent.

Quant à ce qu’il s’est passé au cours de la semaine dernière, le gros du correctif RC-2 est, en fait, la suppression du pilote RTL8187SE de staging, car il y en a maintenant un bon en dehors de staging. C’est vraiment un peu plus de la moitié du correctif en lui‐même. Mais, même si vous ignorez tout simplement cette sortie, les autres changements de pilotes représentent environ les deux tiers du reste (pilote graphiques, réseau, renommage des fichiers fbdev, IPMI, InfiniBand, pin control… Nommez votre pilote préféré). La partie concernant le DRM est probablement la plus remarquable.

En dehors des pilotes, nous avons les mises à jour habituelles d’architectures (principalement x86 et s390, un peu de PA-RISC) et quelques mises à jour de documentation. Quelques corrections pour le réseau et des mises à jour de système de fichiers (CIFS, sysfs, XFS). Et quelques trucs d’outillage.

Testez, s’il vous plaît,

Linus

RC-3

La version RC-3 est sortie le 27 avril 2014.

Nouvelle semaine, nouvelle RC. Jusqu’à présent, pas de grosses craintes et la RC-3 est adéquatement plus petite que la RC-2 ne l’était, nous sommes donc sur la bonne voie.

Les statistiques semblent relativement normales, avec une moitié de pilotes (pilote d’entrées, USB, pilotes graphiques, ACPI, régulateur…) et un tiers de mises à jour d’architectures (la majorité portant sur les fichiers DTS pour ARM, mais aussi d’autres mises à jour sur ARM et user-mode). Le reste est varié, mais principalement concentré sur les mises à jour des systèmes de fichiers (Btrfs et ext4).

Linus

RC-4

La version RC-4 est sortie le 4 mai 2014.

Rien de particulièrement exceptionnel en cours. 45 % de pilotes (DRM, son, [md](http://en.wikipedia.org/wiki/Mdadm "multiple device), pin-control, ACPI, etc.), 40 % d’architecture (principalement powerpc/powernv, mais aussi x86 et ARM), 15 % de divers (outillage de performance, mises à jour documentaires et code du noyau). Le rapport simplifié ci‐joint donne un bon aperçu des détails sans être trop gros.

Il y a encore quelques trucs en cours (par exemple, une correction en attente pour une intéressante corruption de la liste des « entrées de répertoires » (dentry) — même si une utilisation normale aura peu de risque d’être affectée). Mais, dans l’ensemble, c’est relativement calme et il n’y a rien d’horriblement effrayant. Nous sommes au milieu de la période d’apaisement, donc c’est comme je l’aime.

Mais, plus nous avons de tests, mieux c’est ; donc, s’il vous plaît, essayez-la.

Linus

RC-5

La version RC-5 est sortie le 9 mai 2014.

Oui, je suis conscient que c’est en avance de deux jours. Le programme normal était pour moi de faire des versions dominicales, mais, cette fois j’ai une combinaison de voyage (ce qui aurait avancé la version à samedi matin depuis l’aéroport comme c’est souvent mon habitude quand je voyage) et il se trouve que la RC-5 avait déjà suffisamment grossi pour être plus grosse que les RC-3 et RC-4 ne l’étaient.

Donc, au lieu de publier ça à la dernière minute avant que j’embarque dans un avion et que je sois hors ligne pour une semaine, j’ai décidé qu’il n’y a absolument aucune raison pour ce genre de livraison sur le fil. Je préfère faire une livraison tranquillement un vendredi après‐midi, plutôt qu’une précipitée un lendemain matin avant de disparaître pendant une semaine.

Peu importe, assez d’explications. La RC-5 est sortie et, bien que j’eusse été plus joyeux si ça avait été aussi petit que la RC-4, ça semble n’être que des corrections solides (fameux derniers mots). L’intéressante corruption de la liste dcache, que j’avais mentionnée comme reliquat de la RC-4, est dedans ; et ce serait adorable si vous aviez un test de charge pour la couche VFS qui interagit avec la consommation de mémoire. Mais, le jeu en valait la chandelle, la correction nettoie pas mal de choses et retire plus de lignes qu’elle n’en ajoute, donc je la sens bien.

Exceptée cette intéressante modification véritable du cœur (où « véritable du cœur » est défini comme « un domaine auquel je tiens particulièrement », et ne signifie rien de plus ;), tout semble ennuyeusement familier : 55 % de pilotes, 20 % de mises à jour d’architectures et 25 % de divers (systèmes de fichiers, cœur du réseau, machines virtuelles, etc.).

Et, bien que cette RC-5 soit peut‐être plus grosse que les RC-3 et 4 ne l’étaient, ce n’est pas comme si c’était inquiétant. Cette période de fusion était plus grosse que la moyenne, et le fait que la RC-5 est donc un peu plus grosse que la moyenne n’est pas quelque chose qui m’inquiète plus que ça. Et comme la RC-4 était plus petite que d’habitude, tout s’égalise.

Mais je serai réellement entièrement non joignable toute la semaine prochaine, donc faites vos tests, parce que l’arborescence git sera très calme.

Linus

RC-6

La version RC-6 est sortie le 22 mai 2014.

À cause des voyages et du manque d’accès à Internet, des publications de RC n’ont pas suivi le cycle normal de publication dominicale, et, comme j’ai pris connaissance de ce qu’il s’est passé pendant que j’étais hors ligne, plutôt que d’attendre jusqu’à dimanche prochain pour revenir à un cycle normal, je publie en conséquence la RC-6 en milieu de semaine depuis Tokyo.

Avec la RC-5 qui était en avance de quelques jours et la RC-6 qui est en retard, nous avons presque deux semaines entre elles. La taille du résultat n’est pas deux fois plus grosse cependant. En partie parce qu’heureusement on a avancé dans la série des RC et que les choses sont censées se calmer, mais aussi parce que certains sous‐mainteneurs n’ont pas envoyé leurs demandes d’intégration car ils savaient que j’étais hors ligne. Quelle que soit la raison, c’est pas mal.

La distribution du correctif à l’air normale aussi. Principalement des pilotes (ACPI, son, média, pilote graphique i915, horloge clk, PCI…), avec le gros du reste qui correspond à diverses mises à jour d’architectures (notamment MIPS, mais aussi ARM et PA-RISC). Et une poignée de trucs divers dans les systèmes de fichiers et le code du cœur du noyau.

De toute façon, en fonction de ce qui est en cours, je rallongerai un peu la RC-7 pour revenir à une planification dominicale et, en fonction de comment les choses se passent d’ici là, ça pourrait être ne pas être la dernière RC.

Mais, s’il vous plaît, testez ça,

Linus

RC-7

La version RC-7 est sortie le 25 mai 2014.

… cette sortie dominicale se recale sur le calendrier habituel.

La RC-6 a seulement quelques jours, mais, comme prévu, du travail m’attendait à la maison. Cette version est donc normale, la RC-6 ayant juste été décalée par mon voyage.

Le contenu est en grande partie composé de changements concernant le réseau (principalement les pilotes), puisque les autres branches avaient été mises à jour pour la RC-6. Il y a aussi d’autres petits changements (DRM, ordonnanceur, perf, NFS, AFS, etc.).

Linus

RC-8

La version RC-8 est sortie le 1^er juin 2014.

J’ai vraiment espéré que la RC-7 serait la dernière RC, mais la réalité a encore conspiré contre mes super plans bien établis, et me force donc à faire une RC-8. Ce n’est pas comme s’il y avait beaucoup de changement, mais une correction de dernière minute de dcache me fait penser que cela ne serait pas complètement sain de sortir la version définitive sans une semaine de test supplémentaire.

De tout de façon, normalement, une RC-8 n’est pas vraiment un énorme changement — la 3.15 est une des plus grosses (si ce n’est la plus grosse) version depuis bien longtemps, et nous faisons des RC-8 assez régulièrement. Ça pourrait ne pas être le cas de toutes les versions, mais je pense que nous avons 50 % de chances de faire une RC-8 à chaque version. Aussi je ne suis pas très fâché, et sûrement pas surpris.

Non, la véritable raison pour laquelle j’avais espéré que nous n’aurions pas besoin de faire une RC-8 pour la 3.15, c’est que c’est la fin des classes dans deux semaines et nous devons prendre nos vacances en famille juste après. Je déteste avoir encore un « Linus voyage pendant la fenêtre des fusions ». Normalement, je suis plus chanceux que ça durant dans mes voyages.

Certes, j’aurai Internet, et je pourrais faire la fenêtre des fusions pendant mes vacances en famille. Je préférerais juste ne pas à avoir le faire.

Aussi, essayons de voir comment cela va marcher — les dernières semaines de versions consistent généralement à regarder et être sûr que rien de grave ne se passe, par conséquent, le développement devrait fonctionner. Peut‐être que si cela fonctionne bien, nous finirons par continuer comme cela, même s’il n’y pas de conflit de calendrier qui me fait vouloir démarrer la fenêtre des fusions avant que je sois 100 % satisfait de la version précédente.

Ce n’est pas comme si je pensais que la RC-8 était cassée de quelque façon que ce soit. Je ne me sentais simplement pas faire une version 3.15 sans un petit peu plus de temps pour que les gens testent le correctif pour le dentry.

Quoi qu’il en soit, en dehors du changement dcache, il y a plein de petites choses éparpillées. Un changement d’une ligne est particulièrement intéressant : Minchan Kim avait trouvé un cas de figure qui remplissait entièrement la pile du noyau sur l’architecture x86-64 ; et, bien que cela soit quelque chose que je repoussais depuis longtemps, ce changement étend la pile à 16 Kio. Je pense que toutes les autres architectures 64 bits avaient cela depuis longtemps, aussi cela n’est pas très choquant, mais c’est, quelque part, assez fondamental sur une des architectures principales pour être mentionné.

Linus

Version finale

La version finale est sortie le 8 juin 2014.

Je me suis donc résigné à faire une RC-8, parce que j’étais un peu inquiet des corrections de dernière minute sur dcache, mais il s’est avéré que personne ne semble avoir remarqué quoi que ce soit. Malgré tout, nous avons eu d’autres problèmes pendant la semaine, aussi cela n’était pas plus mal. Les corrections de verrous futex et les nettoyages se démarquent, mais comme d’habitude il y a diverses autres corrections un peu partout réalisées depuis la RC-8, principalement les pilotes (DRM, réseau, son, USB, etc.), le réseau, l’ordonnanceur et les outils de mesure de performance.

Mais cela a été dans l’ensemble raisonnablement petit et calme, ce qui doit être, bien entendu, dû au fait que la semaine dernière était également la première semaine de la période de fusion pour la 3.16. Cela a pu distraire certains développeurs. Je ne suis pas complètement convaincu d’avoir apprécié le chevauchement, mais il semblerait que cela ait fonctionné correctement. Et, à moins que les gens crient très fort (« S’il te plaît ne refais plus jamais cela ! ») et qu’ils donnent de bonnes raisons pour cela, je pourrais refaire un chevauchement des fenêtres de fusion dans le futur, si cela peut aider pour certains problèmes de délai.

Ceci dit, je ne pense pas que cela ait été une expérience grandiose au point que je refasse un chevauchement à chaque fois, sans une bonne raison spécifique pour cela. C’était assez agréable d’être productif la dernière semaine de la RC (qui est généralement plutôt ennuyeuse et morte), mais je pense que cela pourrait représenter une distraction quand les gens devraient s’inquiéter de la stabilité de la RC.

Bien sûr, il se pourrait que le chevauchement aboutisse à moins de bruit pendant la dernière semaine de stabilisation, et que cela aide réellement. Cela pourrait aussi produire l’inverse. Je serais intéressé d’entendre l’avis des autres personnes, mais je soupçonne que la plupart n’ont aucune opinion particulière sur le sujet.

Quoiqu’il en soit, avec la version 3.15 publiée, ma branche « master » a déjà été fusionnée avec ma branche « next » sur ma machine locale, et je vais démonter la branche « next » une fois que j’aurai dégagé tout ça. Après cela, les futures fenêtre de fusion se feront sur la branche « master » et nous reviendrons au modèle normal de branche unique pour mon arbre.

Linus

Les nouveautés

Architecture

Gestion du mode mixte EFI

Certaines machines ont un micrologiciel EFI 32 bits, les noyaux 64 bits ne pouvaient du coup pas démarrer simplement dessus. Le mode mixte EFI (EFI mixed mode) ajouté à cette version 3.15, permet maintenant d’y remédier. Un exemple concret est la possibilité pour l’ASUS Transformer Book T100TA de démarrer sur un tel micrologiciel.

Le mode mixte EFI est un mode qui permet aux micrologiciels EFI 32 bits de démarrer sur des noyaux 64 bits, à condition que le chargeur de démarrage gère le protocole EFI handover. La plupart des chargeurs de démarrage populaires comme GRUB, SYSLINUX ou EFILINUX le gèrent, il sera donc possible de disposer de cette fonctionnalité très simplement à condition d’activer l’option CONFIG_EFI_MIXED depuis les options de configuration du noyau Linux.

AVX-512

Les premiers processeurs proposant le jeu d’instructions AVX-512 ne seront commercialisés qu’en 2015, avec la génération Knights Landing des processeurs Intel. Toutefois, leur prise en charge est déjà disponible dans cette version 3.15.

AVX-512 (Advanced Vector Extensions), extension directe de AVX-256, est un jeu d’instructions SIMD (Single Instruction Multiple Data). Il s’agit d’un jeu d’instructions qui permet d’appliquer une même opération arithmétique sur plusieurs données en parallèle. Par opposition aux instructions habituelles de type SISD, pour Single Instruction Single Data, SIMD permet d’appliquer une même opération d’addition, de multiplication sur plusieurs éléments d’une structure très régulière, comme c’est par exemple le cas sur des tableaux ou des matrices. AVX-512 permet, entre autres, d’agrandir la taille des registres AVX à 512 bits, ou encore va donner la possibilité aux compilateurs de vectoriser plus de boucles efficacement, grâce aux instructions Conflict Detection Instructions (CDI) qui, comme leur nom l’indique, permettent la détection des conflits.

Améliorations de l’ordonnanceur

L’ordonnanceur subit un travail de préparation qui vise à permettre une meilleure intégration avec le choix des états de veille du processeur, pour économiser l’énergie. Cela ne sera disponible que dans de futures versions du noyau [commit de fusion].

Il y a aussi eu plusieurs améliorations liées à l’usage des cgroups, notamment lors du changement de contexte entre deux processus d’un même cgroup [1, 2, 3].

Abandon des anciennes plates-formes x86

Je vais faire pleurer ceux d’entre vous qui ont des enfants qui jouaient à Jill, Linux 3.15 ne gère plus ces systèmes excitants introuvables que sont les SGI Visual Workstations, Sequent Computer Systems NUMAQ, IBM Summit/EXA et autres Unisys ES7000.

Instruction RDSEED

À partir du noyau 3.15, /dev/random utilisera les nouvelles instructions RDSEED des futures générations Broadwell de chez Intel [demande d’intégration].

À partir de cette génération, les processeurs Intel proposent une nouvelle instruction RDSEED. Il s’agit d’une instruction de génération de bits aléatoires. Comparée à son homologue RDRAND, qui fut introduite avec la génération Ivy bridge, elle est destinée à être utilisée par les logiciels qui disposent déjà d’un générateur de nombres pseudo-aléatoires (PRNG), en tant que « graine » (seed), c’est-à-dire une source d’entropie de nombres aléatoires. RDRAND, quant à elle, est une instruction de génération de nombres pseudo-aléatoires.

Systèmes mono-puces ARM

La plate-forme ARM est toujours très active, au point que les développeurs songent à mettre l’arborescence des périphériques dans un arbre Git dédié.

Parmi les nouveautés, on peut noter :

• l’ajout de la carte de développement A10-OLinuXino-LIME ;
• l’ajout du Freescale l’i.MX35 ;
• l’ajout des dérivés Freescale i.MX51 , i.MX25 et i.MX35 de chez Eukréa ;
• un ensemble d’améliorations au niveau des systèmes mono-puces i.MX de chez Freescale ;
• pas mal d’améliorations au niveau des systèmes mono-puces de chez ATMEL.

ACPI

Avant Linux 3.15, l’événement envoyé lors de l’appui sur une touche « augmenter la luminosité » ou « baisser la luminosité » pouvait signifier deux choses pour un environnement de bureau :

1. notification comme quoi la luminosité a été modifiée ;
2. touche de modification de luminosité pressée, « débrouille-toi ».

La plupart des environnements de bureau interprètent cet événement comme le cas numéro 2, ce qui causait des problèmes : changement de luminosité effectué deux fois — une fois par le noyau, une fois par l’environnement de bureau — ou changement de luminosité non détecté, et donc notification non affichée, etc. En effet, le scénario numéro 1 est très difficile à détecter en espace utilisateur.

Désormais, la grosse majorité des ordinateurs portables seront dans le cas numéro deux, ce qui rend la gestion de la luminosité plus simple et plus cohérente et résout les cas cités ci-dessus [commit].

Changement de la taille de la pile du noyau

La pile du noyau pour l’architecture x86_64 voit sa taille passer de 8 Kio à 16 Kio. Ce changement a été effectué par Minchan Kim [commit].

Pilotes graphiques libres

DRM (Direct Rendering Manager)

Le code commun aux pilotes graphiques libres (DRM) a reçu plus d’attention que d’habitude pour cette nouvelle version, notamment afin de préparer la venue de nouvelles fonctionnalités dans les versions futures. Il n’y a donc rien de visible pour le moment pour l’utilisateur final.

Le premier gros changement est la gestion universelle des plans d’affichage (display planes). Jusqu’à présent, le DRM n’exposait que les plans de type sprites et superposition (overlay) vidéo. Les plans pour curseurs étaient, eux, exposés via des appels ioctl() dédiés, alors que les plans primaires n’ont jamais été exposés. Désormais, tout client exposant la capacité DRM_CLIENT_CAP_UNIVERSAL_PLANES pourra accéder à l’interface de plans universelle (universal plane) et à la liste complète des plans proposés par le matériel. Ce client pourra dès maintenant changer des paramètres tels que la mise à l’échelle (scaling) ou désactiver l’affichage, sans avoir à effectuer de changement de mode graphique au niveau du contrôleur vidéo (CRTC). Cependant, l’intérêt de cette nouvelle interface ne sera clair que lorsque le travail de changement atomique du mode graphique et du commutation de pages (page flip) du noyau sera terminé. En attendant, si vous voulez plus d’information, vous pouvez consulter ce message ou l’article récapitulatif de la gestion du mode graphique de Pekka Paalanen (développeur Wayland).

Le deuxième changement important est la mise en commun du code gérant le canal auxiliaire de communication du DisplayPort (DP). Cela va permettre la gestion du Multi-Stream Transport (MST) proposé par le DisplayPort, qui permet de multiplexer plusieurs liaisons vidéo à travers le même câble DP. Voici la demande d’intégration de cette nouvelle infrastructure. La gestion du MST devrait, quant à elle, arriver dans Linux 3.16 ou 3.17.

La gestion des nœuds maîtres, mineurs et de contrôles a été revue dans cette version, notamment sur la gestion des verrous. En parlant de verrous, les symboles DRM vérifient maintenant activement que les bons verrous ont été pris avant l’appel, au lieu de simplement le marquer dans la documentation. Mais le changement le plus important vient mettre fin à une bidouille pour l’allocation d’un espace d’adressage pour le périphérique. En effet, il est impossible d’allouer un espace d’adressage sans avoir de nœud d’index (inode) disponible. Du coup, DRM attendait que le premier client ouvre un nœud vers un processeur graphique avant d’allouer l’espace d’adressage. Cette technique était clairement une bidouille, et Al Viro (mainteneur VFS) a conseillé d’utiliser une autre méthode qui a été appliquée.

Pour finir, la documentation DRM a été corrigée et nettoyée.

Adreno (pilote msm)

Dans cette nouvelle version, le pilote msm gagne la possibilité de diffuser du son via la prise HDMI [correctif] et devient plus économe en énergie en activant le clock gating après 66 ms d’inactivité [correctif].

Après un article de LWN sur comment gérer proprement des drapeaux inconnus dans les ioctl() ou les appels systèmes, Rob Clark a vérifié à nouveau son code et trouvé quelques problèmes qu’il a corrigés [correctif]. Ces modifications cassent la compatibilité binaire, mais Rob se justifie en disant qu’il n’y a presque aucun pilote en espace utilisateur et que, si une application venait à être cassée par ce changement, il reviendrait partiellement sur son correctif.

Le pilote msm utilise maintenant les plans d’affichage universels qui viennent juste d’être introduits, au lieu de l’ancienne interface de programmation [correctif].

Pour finir, une option noyau a été ajoutée afin d’afficher l’état des registres lorsque le processeur graphique se bloque [correctif]. Cela devrait aider pour l’écriture de rapports de bogues.

Pour information, le pilote freedreno (accélération 3D pour Adreno) utilisant le pilote msm vient de recevoir la prise en charge d’OpenGL 2.1. Celui-ci prenait en charge OpenGLES 2.0 depuis quelque temps, mais ne gérait pas quelques extensions nécessaires pour la version « bureau » d’OpenGL. Ce code devrait être disponible dans Mesa 3D 10.3 qui sortira en août.

AMD/ATI (pilote radeon)

La principale nouveauté concernant le pilote radeon est la prise en charge de l’encodeur vidéo matériel VCE afin d’accélérer la conversion de vidéos au format H.264. Ce noyau permet l’utilisation de cet encodeur à travers le standard OpenMAX, du groupe Khronos. Ce n’est pour l’instant possible qu’avec la version VCE 2.0 du matériel, la prochaine version de Mesa 3D (10.3) [correctif] et le greffon GStreamer gst-omx.

Cette nouvelle version apporte également la prise en charge complète d’un petit dernier dans la famille des processeurs APU Kaveri, le Mullins, qui est sorti le 29 avril 2014.

Pour finir, radeon a laissé tomber sa gestion spécifique du canal de communication auxiliaire du DisplayPort, afin d’utiliser la nouvelle version proposée par DRM [correctif]. Beaucoup d’autres bogues ont également été corrigés, notamment dans la gestion des horloges.

Samsung (pilote exynos)

Un gros travail de réorganisation du code a été mené sur le pilote exynos, avec notamment le déplacement du pilote DisplayPort depuis video/ vers drm/, afin de gérer correctement le branchement à chaud et le changement de mode graphique [correctif]. Il est également à noter l’ajout de la gestion des ponts LVDS, ainsi que des écrans à interface parallèle (remplacée par l’interface DSI).

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

Intel (pilote i915)

Aucune nouvelle fonctionnalité activée par défaut pour le pilote i915 dans cette version, mais un énorme travail de fond a été effectué.

La gestion des Per-Process Graphics Translation Tables (PPGTT, tables de traduction graphique par processus) fait son apparition, mais est désactivée par défaut à cause de quelques bogues trouvés à la dernière minute. PPGTT est une fonctionnalité des processeurs graphiques inclus dans les processeurs Intel Ivy Bridge, Haswell, et Broadwell qui permet l’isolation des tâches du processeur graphique, ce qui améliore la sécurité en fournissant un contexte et un espace d’adressage par descripteur de fichier et client de ressources graphiques. Pour en savoir plus sur GTT et GEM, un cours d’introduction a été écrit par Ben Widawsky, un ingénieur de chez Intel.

Par le passé, la gestion du power gating et du clock gating par le matériel Intel a surtout été gérée automatiquement. Désormais, les nouvelles architectures requièrent l’intervention du pilote afin, notamment, de sauvegarder et restaurer le contexte. Donc, il est nécessaire de préparer une infrastructure permettant de représenter les domaines énergétiques, de suivre leur état et de gérer les changements d’état. Comme les domaines énergétiques sont très dépendants de l’architecture et sont amenés à évoluer dans le futur, une couche d’abstraction est proposée par l’infrastructure. Cette infrastructure devrait commencer à être utilisée dans Linux 3.16.

Du côté de l’affichage, la gestion expérimentale du démarrage rapide et sans clignotement a été améliorée afin de pouvoir hériter du mode graphique qui a été mis en place au démarrage par le micrologiciel EFI. Encore un peu de travail est nécessaire pour rendre sa gestion parfaitement fiable, ce qui explique pourquoi l’option n’est pas activée par défaut bien que toute l’infrastructure soit maintenant en place. Si vous voulez l’essayer malgré tout, vous pouvez ajouter l’option i915.fastboot=1 à votre ligne de commande noyau.

Concernant l’affichage, la prise en charge des liens DisplayPort à 5,4 GHz, nécessaire pour piloter des écrans à ultra haute définition (4K), est disponible. Malheureusement, les écrans 4K actuels exposent généralement deux écrans, via le Multi-Stream Transport (MST), afin de proposer la 4K. En parlant de MST, le pilote i915 utilise maintenant la gestion du canal auxiliaire du DisplayPort proposée par DRM, ceci afin de pouvoir plus tard gérer les écrans accessibles via MST. Enfin, la gestion des grands curseurs a été ajoutée afin de mieux gérer les curseurs sur les écrans à haute densité de pixels.

La prise en charge des processeurs Broadwell a reçu beaucoup de modifications, mais elle reste encore incomplète. D’autres devraient suivre dans Linux 3.16.

Pour plus d’informations, vous pouvez consulter le billet de blogue de Daniel Vetter dédié à Linux 3.15.

NVIDIA (pilote nouveau)

La nouveauté principale côté du pilote nouveau est la gestion expérimentale de la nouvelle famille de cartes NVIDIA Maxwell, sortie le 18 février 2014. Cette gestion se limite actuellement au mode graphique [correctif] et à l’accélération 3D [correctif] en utilisant le microcode de NVIDIA. Ce microcode sera remplacé dans le futur par une version entièrement libre, quand les fonctionnalités basiques s’exécuteront en espace utilisateur. En effet, cette nouvelle famille de cartes a introduit un nouveau jeu d’instructions qu’il a fallu étudier et intégrer à Mesa 3D [correctif]. Il manque cependant les modifications nécessaires au pilote X.Org xf86-video-nouveau pour pouvoir utiliser l’accélération 2D et 3D sur processeur graphique Maxwell avec un serveur X.

Une première version d’un système de reprise sur panne a également été intégrée pour Kepler, afin de ne pas bloquer tout le système lorsque l’unité de gestion mémoire ne connaît pas la correspondance entre une adresse virtuelle et une adresse physique. Le pilote nouveau devrait également mieux gérer les cas où le microcode de changement contexte se bloque.

La gestion automatique de la ventilation s’améliore avec la correction de multiples bogues, et, surtout, l’ajout de la gestion de deux nouveaux types de ventilateurs couramment trouvés dans la famille Kepler. Si vous avez encore des problèmes de ventilateur dans cette version, vous êtes invités à écrire un rapport de bogue. De multiples bogues concernant la lecture du BIOS vidéo ont également été corrigés, en partie grâce à l’aide de NVIDIA.

Parmi les modifications apportées dans Linux 3.15, l’une d’elles se distingue particulièrement, pour deux raisons :

• elle prépare nouveau afin de pouvoir gérer le processeur graphique ARM Tegra K1, qui n’est pas accessible via un bus PCI, AGP ou PCIe ;
• elle est écrite par un nouvel employé de NVIDIA, Alexandre Courbot.

Ce n’est pas la première fois que NVIDIA contribue à nouveau puisque Aaron Plattner l’avait déjà fait en février 2013, mais c’est cependant la première fois que la gestion d’un nouveau jeu de composants est écrite par un employé de NVIDIA, français, qui plus est. Alexandre Courbot est, en effet, actif sur l’IRC et les listes de diffusion de nouveau et ajoute la gestion du Tegra K1 (nom de code GK20A) au noyau, tel que nous le rapportions sur LinuxFr.org en février. La majorité des contributions sont encore à venir, notamment dans Linux 3.16. La gestion de l’accélération 3D en espace utilisateur n’a pour l’instant nécessité que -8 / +21 changements ! Plus d’information dans un futur proche, mais, en attendant, voici une petite démonstration de l’avancement.

Poulsbo (pilote gma500)

Le pilote gma500 du tristement célèbre processeur graphique à basse consommation Poulsbo évolue doucement, avec la prise en charge d’un nouveau type d’unité de gestion mémoire et de gestionnaire d’interruptions (SGX).

Tegra (pilotes host1x et tegra)

Les choses ont bien bougé du côté de host1x qui reçoit une infrastructure pour l’allocation de contextes, la synchronisation des moteurs d’exécution et la gestion du moteur de rendu 2D. La gestion de la 3D est en cours d’écriture. Bien que ce travail ait été testé durant plusieurs semaines par de multiples contributeurs, les contrôles d’entrées-sorties introduits pour tegra sont actuellement considérés comme staging (branche git dédié à la mise en œuvre) de façon à permettre un changement plus tard, si l’interface venait à ne pas être adaptée. La gestion de la 2D et de la 3D a été testée avec le pilote grate. Pour rappel, host1x est la partie des processeurs Tegra qui gère les transferts DMA, ainsi que l’affichage et l’envoi asynchrone de commandes au processeur graphique et autres systèmes multimédias. Le processeur graphique Tegra est, lui, séparé, à la fois dans la puce et dans le code, et se charge de l’accélération 2D et 3D.

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

VMware (pilote vmwgfx)

Le pilote vmwgfx, pour l’accélération graphique dans les machines virtuelles VMware tournant sous Linux, a revu sa politique de sécurité afin de pouvoir gérer les nœuds de rendu (render nodes).

Réseau

À la recherche des performances

La recherche de gain en performance est une tâche courante dans le noyau Linux, et la partie réseau n’est pas en reste pour cette nouvelle version. Petit tour de ces nouveautés.

Une horloge plus fine

Dans les arcanes du très populaire TCP, l’estimation du RTT est importante pour certains algorithmes de gestion de la congestion. L’unité de cette estimation était la milliseconde, avec une bidouille immonde pour les cas inférieurs à cette valeur. Concrètement, cette bidouille dépendait de la fréquence de réveil de votre noyau (déterminée à la compilation). Cette fréquence étant à 1 000 Hz par défaut sur les architectures x86, l’estimation la plus fine utilisait des pas de 125 µs.

Sur des réseaux modernes très performants, ces 125 µs sont beaucoup trop imprécises. Le nouveau noyau compte donc désormais en microsecondes, mais reste compatible avec les anciens outils de l’espace utilisateur en exportant toujours les données en millisecondes. Une mise à jour de la commande ip sera nécessaire pour voir les changements.

Réécriture de l’interpréteur interne BPF

Que ne serait pas un nouveau noyau sans travail du côté du filtrage de paquets ? Le cœur de l’interpréteur a été réécrit dans cette version, avec pour objectif une amélioration des performances. Le correctif est accompagné de tests de performance prometteurs, et d’une promesse de faire encore mieux bientôt en adaptant le compilateur à la volée (Just In Time) de BPF.

Mettre à jour la somme de contrôle tout simplement

Pour limiter l’utilisation du processeur sur des réseaux à très forte capacité, un mécanisme courant est de déléguer une grande partie du travail à la carte réseau. L’idée est de faire « comme si » on envoyait et recevait des très gros paquets du côté noyau, pendant que la carte réseau se charge de découper/rassembler les paquets réels, bien plus petits. Pour en savoir plus, vous pouvez consulter un très bon article sur LWN.

C’est en utilisant ce mécanisme qu’un développeur de Google a détecté une forte utilisation du processeur pour le calcul de la somme de contrôle de ses paquets, avec près d’un pour cent du processeur dédié à cette simple tâche. Cette somme de contrôle a de bonnes propriétés mathématiques, elle est notamment incrémentale : quand on modifie un champ d’un paquet, on n’est pas obligé de tout recalculer, il suffit de calculer la différence induite par la partie réécrite.

L’analyse détaillée a donc conduit à identifier le coupable : la fonction csum_replace2(). Cette fonction prend une somme de contrôle, deux mots de 16 bits (l’ancien champ et le nouveau champ réécrit du paquet), et retourne la nouvelle somme de contrôle.

Cette fonction ne faisait pas réellement le travail, en délégant la tâche à la fonction csum_replace4(), prenant comme arguments des mots de 32 bits. Qui peut le plus peut le moins, mais le fait moins vite. csum_replace4() appelle, elle-même, une fonction générique encore plus complexe.

Cette mise à jour de la somme de contrôle est pourtant une tâche simple pour des mots de 16 bits, bien documentée depuis longtemps dans la RFC 1624. Davil Miller a signalé cette référence, et Éric Dumazet de chez Google a donc modifié la fonction pour utiliser cette méthode simple et rapide. Comme cette fonction est utilisée à d’autres endroits de la partie réseau, d’autres cas d’utilisation devraient profiter de ce gain.

Protection contre les dénis de service

Les dénis de service, consistant à surcharger un serveur par un nombre impressionnant de connexions, sont très courants sur Internet. Parmi ceux-ci, un grand classique est le bon vieux SYN flood. Sur un pare-feu à états, chaque paquet ajoutera une connexion à suivre, et il faut être capable de les gérer.

Chez Linux, ce suivi est effectué par la table conntrack. Cette table était protégée par un verrou central pour les insertions et les suppressions. Et ce verrou devenait avec le temps un énorme frein (un peu comme le Big Kernel Lock, à échelle très réduite).

Le nouveau noyau introduit donc un verrouillage plus fin, avec 1 024 verrous et une table de hachage pour savoir quel verrou utiliser. L’amélioration de performance est spectaculaire, si vous avez le matériel qui va avec. Avec un bon processeur et un réseau à 10 Gbit/s, le testeur est passé d’une gestion de 810 405 connexions par seconde à 2 233 876, soit une amélioration d’un facteur de presque trois.

Sécurité réseau

cgroups et réseau

C’est une modification triviale, mais il est désormais possible d’attacher une règle iptables à un cgroup pour du trafic entrant. Cela permet notamment de compter le trafic entrant d’une application.

Toujours du côté des cgroups, une refonte assez importante a supprimé la possibilité de compiler le contrôleur cgroup net_prio en tant que module. C’était le seul qui utilisait cette possibilité.

IPsec

Dans un paquet IPsec, il est possible d’ajouter un compteur de paquets pour se protéger des attaques par rejeu (en refusant des paquets dont le compteur est inférieur aux valeurs déjà reçues). Ce compteur est historiquement de 32 bits, ce qui permet d’envoyer un certain nombre de paquets.

Ce nombre est cependant insuffisant pour les réseaux modernes, et une extension existe dans le standard depuis 2005 pour utiliser un compteur à 64 bits. Linux permettait de le faire pour le protocole ESP d’IPsec (intégrité et authentification) et, à partir de cette version, l’autorise également pour le protocole AH (intégrité et confidentialité).

Depuis sa version 3.6, le noyau permet de gérer le routage à travers un tunnel, avec les vti (Virtual Tunnel Interface, nom venant de Cisco), pour gérer plus facilement et plus dynamiquement le routage à travers un tunnel IPsec. Ces VTI sont uniquement une abstraction des règles IPsec existantes dans le noyau. Pour ces VTI, ce noyau ajoute la possibilité de configurer un espace de noms et de faire passer de l’IPv6 dans un tunnel IPv4.

Bluetooth

Ce noyau introduit la gestion du niveau 4 (le plus élevé) de la sécurité en Bluetooth. Concrètement, ce mode de sécurité force l’utilisation de clefs de chiffrement plus fortes, mais ne sera compatible qu’avec les équipements utilisant la norme Bluetooth 4.1. Il n’y a pas de compatibilité pour ce mode avec le matériel plus ancien.

Commentons avec nftables

Avec le pare-feu de nouvelle génération nftables, on peut désormais ajouter des commentaires arbitraires associés à une règle. Cela permettra à l’administrateur pressé de répondre à la question « Mais, pourquoi ai-je bien pu ouvrir le port 22 ? ».

Sécurité

Audit

La valeur de proc/<pid>/cmdline (nommée proctitle) fait maintenant partie des informations remontées par le sous-système d’audit [correctif]. Cette chaîne de caractères peut être changée par le processus avec la fonction setproctitle(), et ne peut donc pas être considérée comme « de confiance » d’un point de vue sécurité.

En revanche, elle sera particulièrement utile pour le débogage sur Android notamment, car les applications ne sont pas lancées à l’aide d’un classique fork() + exec(). En effet, pour accélérer le lancement, les applications Java utilisent une instance (processus) préparée à l’avance par la machine virtuelle Java Dalvik et la spécialisent en chargeant les classes de l’application. Ceci évite notamment d’avoir à charger systématiquement les classes des paquets de base pour chaque nouvelle application lancée, et permet donc de profiter de la propriété de copie sur écriture (Copy-On-Write) de l’appel système fork(). Lorsque la machine virtuelle Java (JVM) lance une application, elle change la valeur de proctitle pour la faire correspondre à son nom et cela apparaîtra désormais dans les journaux d’audit.

La prise en charge de l’audit des appels système a aussi été étendue pour gérer les appels 32 bits sur une architecture 64 bits [correctif].

Gestion de l’Intel Trusted Execution Environment

Une série de correctifs [1, 2, 3, 4 et 5] ajoute la gestion du périphérique Intel Trusted Execution Environment à l’Intel Management Engine Interface (IMEI). L’IMEI est une interface IPMI faisant partie de l’Intel Active Management Technology qui est présente dans les processeurs avec la technologie Intel vPro. Elle permet de gérer un système en discutant directement avec une puce dédiée, sans passer par le système d’exploitation (out‐of‐band management).

LSM

Diverses corrections de bogues et améliorations mineures sont listées dans le message de demande d’intégration des correctifs.

SELinux

La mise en correspondance de zones mémoire proches de l’adresse 0 peut poser des problèmes de sécurité (cela simplifie principalement l’écriture d’exploitations de failles du noyau). Ainsi, une limitation arbitraire avait été ajoutée (vm.mmap_min_addr, configurable à l’aide de sysctl) pour réduire ce risque. Les processus souhaitant mettre en correspondance une zone mémoire inférieure à mmap_min_addr doivent disposer de la « capacité » (capability) CAP_SYS_RAWIO.

Pour le noyau 2.6.30, Eric Paris avait choisi de placer la vérification effectuée par SELinux (MAC) avant la vérification classique de « capacité » (DAC) [correctif]. Ce comportement était un cas exceptionnel, car les vérifications effectuées au niveau des appels système suivent toutes l’ordre DAC puis MAC (cf. un exemple complet pour le contrôle d’accès à un fichier).

Cette inversion a eu pour principale conséquence la mise en avant d’un cas d’erreur courant et géré sans aucun problème par les programmes (notamment Wine et QEMU) dans la majeure partie des cas. En effet, lorsque qu’un programme essayait d’effectuer un mmap() au‐dessous de mmap_min_addr, il se voyait refuser l’accès par SELinux en premier, ce qui générait un AVC qui était affiché à l’utilisateur (par setroobleshoot) avec un message du type :

SELinux is preventing /usr/bin/wine-preloader from 'mmap_zero' accesses on the memprotect.

L’utilisateur croyait alors à tort qu’il y avait un problème de sécurité. Si l’application échouait, ce n’était pas non plus nécessairement la faute de SELinux. Et, si c’était effectivement le cas, il fallait non seulement autoriser ce programme dans la politique SELinux, mais également lui donner la capacité CAP_SYS_RAWIO pour qu’il puisse fonctionner.

Ayant causé plus de soucis que de bénéfices potentiels (détection de programmes malveillants), cette inversion MAC/DAC a été corrigée (cf. l’article de Daniel Walsh sur le sujet) [correctif].

Un autre bogue a été corrigé : des nœuds d’index (inodes) dans /proc pouvaient être laissés avec une étiquette de sécurité (label) attribuée par défaut au lieu de celle indiquée dans la politique de sécurité. Cela se produisait si un programme y accédait avant que la politique ne soit chargée [correctif].

Systèmes de fichiers

Code commun

VFS

L’appel système renameat2 a été ajouté afin de permettre d’échanger les noms de deux fichiers de façon atomique. Avec cet appel système, il devient donc possible de remplacer un dossier par un lien symbolique sans risque qu’une opération arrive durant l’opération et ne réussisse pas ! Vous pouvez consulter l’article de LWN sur le sujet, ainsi que la page de manuel de l’appel système, afin d’obtenir plus d’informations.

Une autre modification importante est l’ajout de nouveaux verrous équivalents aux verrous POSIX, mais associés aux fichiers et non plus aux processus. La différence semble être peu importante, mais elle permet de rendre ces verrous utiles pour la synchronisation de plusieurs fils d’exécution à l’intérieur d’un même processus.

Avec les verrous POSIX classiques (qui n’ont pas été remplacés), si deux fils d’exécution (threads) d’un même processus ouvraient le même fichier, un verrou posé en écriture par un fil serait remplacé par un autre verrou en écriture posé par l’autre fil. De plus, si le fichier est ouvert plusieurs fois (utile pour paralléliser la lecture de données dans plusieurs fils) les verrous posés par un fil sur un fichier sont enlevés lorsqu’un autre fil ferme son descripteur de fichier. Il est très difficile de se prémunir contre ça sans rajouter beaucoup de verrous internes à l’application et s’assurer que les chemins des fichiers sont uniques (pas de lien dur ou symbolique).

Cependant, si les verrous sur un fichier ne sont plus associés à l’identifiant du processus (PID) mais sont associés aux descripteurs de fichier, le noyau ne fera plus de distinction entre deux tentatives de verrouillage venant de deux fils d’exécution d’un même processus ou de deux processus séparés ! Pour plus d’information, vous pouvez lire l’article dédié sur LWN.

SATA

La vitesse de sortie de veille a été augmentée en autorisant le contrôleur de disque SATA à se réinitialiser en tâche de fond pendant que le reste du noyau se réveille puis rend la main à l’espace utilisateur. Ce n’est pas un problème, car même si une application utilisateur ou le noyau essaient de relire un fichier pendant que le contrôleur SATA se réveille, le processus ou le module sera bloqué et la requête mise en file d’attente en attendant que le contrôleur ait fini son travail. Le résultat est un temps de réveil de 7 à 12 fois plus rapide sur les machines de son développeur et une faible complexité du code (1 et 2). Plus d’informations sont disponibles sur LWN.

Ext3/4

Le système de fichiers par défaut de nombreuses distributions se stabilise encore et toujours, mais peu de nouveautés à se mettre sous la dent.

XFS

Idem du côté de XFS, la période est relativement calme. À noter que le sous‐système XFS n’est plus maintenu par SGI mais désormais par Dave Chinner (Red Hat). Celui‐ci remercie au passage grandement SGI pour le boulot réalisé depuis les débuts de XFS. Les modifications les plus significatives concernent la gestion de O_TMPFILE, ainsi que l’option de l’appel système fallocate (COLLAPSE_RANGE et ZERO_RANGE).

Btrfs

Suite à l’embauche de Chris Mason chez Facebook, puis au déploiement sur une ferme de serveurs de test de Btrfs, ce système de fichiers a le vent en poupe. Btrfs se voit amélioré considérablement, avec une bonne salve de corrections et d’améliorations de performance qui ne semblent cependant pas visibles dans les tests de Phoronix.

Le temps semble être à la stabilisation de Btrfs.

F2FS

Ce système de fichiers qui s’entend bien avec les mémoires Flash (Flash‐Friendly File System) se voit doté d’une amélioration des performances sous certaines charges de serveur, ainsi que d’une gestion des dossiers de taille importante.

kernfs

Le pseudo‐système de fichiers kernfs a été tout juste introduit dans la version 3.14. Il reprend la logique de sysfs pour la rendre plus utile aux différents sous‐systèmes ayant besoin d’un système de fichiers virtuel. Il continue d’être amélioré, en particulier par Tejun Heo, auteur de la majorité des correctifs.

ZRAM

Ajout de la gestion de l’algorithme de compression LZ4 pour zram. zram est un système de d’échange de mémoire (swap) compressé tournant en mémoire vive, afin d’améliorer les performances des machines qui en manquent.

En vrac

Par manque de temps, tous les changements n’ont pu être résumés. Voici quelques informations complémentaires :

• Reiser4 : [1], [2], [3] ;
• SquashFS : [1].

Virtualisation

KVM

Les nouveautés tirées de la demande d'intégration :

• pour les architectures ARM, il y a quelques corrections pour les caches ;
• du côté du PowerPC, les invités peuvent profiter de la mémoire transactionnelle (disponible avec le POWER8) ;
• MIPS profite de quelques corrections de bogue, mais d’autres devraient arriver avec la prochaine version, car QEMU va avoir droit à KVM avec MIPS ;
• pour les x86 :
  • des optimisations dans les registres de débogage utilisés par certains jeux pour Windows,
  • de manière générale, les invités Windows profitent de plusieurs corrections de bogues,
  • pour tous les invités, les instructions des processeurs Intel Broadwell sont maintenant exposées, ainsi que les instructions MPX développées par Intel pour protéger les accès mémoire,
  • pour les invités OS X, il y a un contournement avec le minuteur de préemption pour la virtualisation imbriquée, et quelques modifications de l’horloge présentée par KVM ;
• pour l’architecture s390 (les ordinateurs centraux d’IBM), les erreurs de page asynchrones sont implémentées, et des améliorations des interruptions font que les périphériques virtio sont plus rapides.

Xen

Aucune nouveauté du côté de Xen pour cette version.

Le bilan en chiffres

Une fois n’est pas coutume, LWN n’a pas encore publié son article sur les statistiques des contributions à cette nouvelle version de Linux.

Nous avons profité de ce délai de leur part pour améliorer la qualité de cette dépêche, mais nous ne pouvons pas la retarder infiniment. Nous rajouterons cette partie dans un commentaire quand l’article de LWN sera disponible.

Appel aux 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	Julien Pecqueur, Albert_
Architecture	Romain Perier	Sébastien Chauvel
Pilotes graphiques libres	Martin Peres
Réseau	Florent F.
Systèmes de fichiers	Jiehong	Martin Peres
Sécurité	Timothée Ravier
Virtualisation	Xavier Claude
Édition générale	aucun	Martin Peres, Davy Defaud, rogo

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. Il n’y a 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. 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 correctifs 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 (354 clics)
• Site officiel du noyau Linux (222 clics)
• Le détail des nouveautés sur kernelnewbies.org (463 clics)
• The Top Features Of The Linux 3.15 Kernel (402 clics)