Sortie de Linux 3.16

La sortie de la version stable 3.16 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
  •  Architecture
  •  Pilotes graphiques libres
  •  Réseau
  •  Sécurité
  •  Virtualisation
• La phase de test
  • RC-1
  • RC-2
  • RC-3
  • RC-4
  • RC-5
  • RC-6
  • RC-7
  • Version finale
• Les nouveautés
  • Architecture
    • Problèmes avec GCC 4.9
    • Unification de la hiérarchie des cgroups
    • Système mono‐puce ARM (SoC ARM)
    • MIPS
    • ARM64
      • big.LITTLE dans cpufreq
      • EFI Stub
      • AMD Seattle
    • x86 : Intel Broadwell dans P-State
  • Pilotes graphiques libres
    • DRM (Direct Rendering Manager)
    • Adreno (pilote msm)
    • AMD/ATI (pilote radeon)
    • Intel (i915)
    • NVIDIA (pilote nouveau)
    • Samsung (pilote exynos)
    • En vrac
  • Réseau
  • Sécurité
    • Liste non exhaustive des vulnérabilités corrigées :
    • Bit NX et chargement des modules
    • Compilation à la volée des filtres seccomp
    • IMA et EVM
    • LSM
      • SELinux
      • SMACK
  • Systèmes de fichiers
    • XFS
    • Btfrs
    • F2FS
    • Reiser4
    • NFS
  • Virtualisation
    • KVM
    • Xen
• Le bilan en chiffres
• Appel à volontaires

En Bref

 Architecture

• Unification de la hiérarchie des cgroups.

 Pilotes graphiques libres

• AMD : meilleure performance et consommation plus basse grâce à BAPM ;
• Intel : gestion des tampons graphiques alloués par malloc() ;
• Nouveau : changements de fréquence expérimental pour les processeurs graphiques Kepler.

 Réseau

• TCP Fast Open est maintenant disponible pour IPv6.

 Sécurité

• Le bit NX est maintenant utilisé plus tôt dans le chargement des modules.

 Virtualisation

• KVM permet de gérer Xen en virtualisation imbriquée.

La phase de test

RC-1

La version RC-1 est sortie le 15 juin 2014.

Cela fait deux semaines que la phase d’intégration a commencé et que la RC1 est prête. Par conséquent, la phase d’intégration est finie.

Cette phase a été un peu inhabituelle, car cela fait seulement une semaine que la version 3.15 est sortie, et la première semaine a chevauché la dernière -RC de la version précédente ; mais cela ne semble pas avoir eu beaucoup de conséquences sur le développement. Tout semble normal et, s’il y a quelque chose à noter, c’est que cette phase a été plus grosse que d’habitude. Ce n’était tout de même pas une phase d’intégration aussi grosse que la 3.15, mais cela n’en était pas loin.

Tout cela semble habituel du point de vue des statistiques : deux tiers des changements concernent les pilotes (et un tiers de ceux‐ci concernent staging), la moitié restante correspond à des mises à jour d’architectures (avec ARM en tête, principalement les fichiers DTS — mais il y a aussi du MIPS, PowerPC, x86 et ARM64).

Mises à part les mises à jour de pilotes et d’architectures, un mélange habituel de changements : systèmes de fichiers (principalement ReiserFS, XFS, Btrfs, NFS), réseau, parties du cœur (mm, verrous, ordonanceur, traçage) et outils (performance et alimentation, mais aussi quelques tests).

Comme d’habitude, le résumé court des changements est beaucoup trop long pour être utile et inclus dans cette annonce ; mais, naturellement, vous pouvez regarder le détail dans Git. Je poste les « changements fusionnés » comme d’habitude, ce qui donne, je pense, une meilleure vision générale. Et, comme d’habitude, cela ne reflète pas nécessairement les honneurs dus aux personnes qui ont écrit le code, mais aux mainteneurs des sous‐systèmes qui me les ont envoyés. Pour les vrais honneurs, allez voir dans l’arbre de Git.

En avant, testez,

Linus

RC-2

La version RC-2 est sortie le 21 juin 2014.

C’est un jour plus tôt que d’habitude, mais demain cela risque de ne pas être possible pour moi, car je serai sur la route une bonne partie de la journée, donc allons‐y. Ces temps‐ci, la plupart des personnes envoient leurs demandes d’intégration et leurs correctifs pendant la semaine, donc ne pas publier un dimanche ne fera pas beaucoup de différence. De plus, ce n’est pas comme si je n’avais pas assez de modifications pour publier la RC2.

Bon, assez d’excuses. La 3.16-rc2 a été publiée et contient l’assortiment habituel de correctifs répartis sur l’ensemble du code. Ce qui est inhabituel à ce stade est de constater à quel point les changements concernant l’architecture SPARC sortent du lot (presque 40 % des correctifs en vrac), mais ce ne sont que des nettoyages d’avertissements.

De manière similaire, quelques modifications du DRM de Nouveau ressortent du côté taille. Mais, encore une fois, c’est principalement dû à des petites corrections de bogues de micro‐logiciels qui ont changé les fichiers générés. Les vrais changements sont peu importants.

Si l’on ignore ces deux grosses modifications inhabituelles (en termes de lignes de code), le reste semble normal. Il y a des modifications de pilotes, des mises à jour d’outils (particulièrement perf) et diverses autres mises à jour d’architecture (ARM, s390, UNICORE32, x86…). Et juste des trucs divers un peu partout : rtmutex, Btrfs, bla bla bla.

Le résumé de publication n’est pas minuscule, mais suffisamment petit pour être inclus ici, donc vous pouvez voir les détails si vous êtes intéressés.

S’il vous plaît, testez‐le donc,

Linus

RC-3

La version RC-3 est sortie le 29 juin 2014.

Nous sommes de retour à un emploi du temps dominical de publication, et les choses semblent raisonnablement normales.

Il y a peut‐être relativement moins de mises à jour de pilotes que d’habitude, dont la plupart sont assez petites, mais c’est probablement juste dû à la planification (par exemple, Greg n’a pas envoyé ses changements USB en staging cette semaine, donc les changements de pilotes sont principalement ceux des processeurs graphiques, du réseau et du son).

De fait, les diverses mises à jour d’architectures (MIPS, PowerPC, x86, ARM) dominent dans les différences, et il y a quelques autres mises à jour diverses. Nous avons des mises à jour de systèmes de fichiers (AIO, NFS et OCFS2), un petit lot de corrections d’Andrew sur la gestion mémoire, quelques trucs réseau, etc.

Le résumé de publication donne une bonne idée des changements. Les plus visibles pour les utilisateurs sont probablement le « dé‐cassage » des accès en lecture des périphériques à accès bloc sur les cibles 32 bits, et quelques corrections de régressions sur vDSO x86 qui posaient problème. Le reste n’affecte probablement, au final, que peu de personnes, mais ce sont des corrections appropriées…

Linus

RC-4

La version RC-4 est sortie le 6 juillet 2014.

Les choses se sont gentiment calmées et tout semble parfaitement normal. Peut‐être que ce calme a été dû, en partie, aux gens qui commencent à décoller pour l’été et (aux États‐Unis) la semaine du 4 juillet, mais quelle qu’en soit la raison, à la fois les journaux et les statistiques sur les modifications des fichiers semblent sympathiques et raisonnablement petits.

La plupart des modifications concernent les pilotes (pilotes graphiques, USB, SCSI et son), les systèmes de fichiers (Btrfs, ext4) et les mises à jour d’architectures (principalement ARM). Avec une poignée de divers trucs épars. Mais cela reste relativement limité.

Allez le tester,

Linus

RC-5

La version RC-5 est sortie le 13 juillet 2014.

Les choses ont l’air normales et, comme d’habitude, j’aurais aimé qu’il y ait un peu moins d’agitation, puisqu’il commence à être assez tard dans le cycle des versions candidates. Mais, honnêtement, ce n’est pas comme s’il y avait quelque chose qui fasse réellement froncer les sourcils.

La plupart des modifications concernent les pilotes — avec ACPI et pilotes graphiques qui ressortent du lot. C’est vraiment assez varié (HID, moniteurs matériels, sous‐système IIO, capteurs de température, pilotes d’horloge, libata, pinctrl, etc.). Il y a les mises à jour d’architectures habituelles (principalement ARM et un peu de PowerPC), un peu de corrections pour la documentation DocBook et quelques corrections de systèmes de fichiers (F2FS, kernfs et ext4). Avec aussi une poignée de petites corrections du cœur (principalement les cgroups).

En avant, testez,

Linus

RC-6

La version RC-6 est sortie le 20 juillet 2014.

Semaine après semaine, nous nous dirigeons vers ce qui est supposé être la dernière RC, mais, franchement, les modifications ne se calment pas comme elles le devraient.

C’était déjà vrai pour la RC5 — plus grosse que la RC4. Cela ne m’avait pas inquiété outre mesure, parce que la RC4 était plutôt petite. Mais maintenant la RC6 est sortie, et elle est plus grosse que la RC5, et elle ne contient pas que des modifications triviales.

Ce n’est pas comme cela que c’est supposé se passer.

Quoi qu’il en soit, la RC6 n’est pas si grosse, donc je ne suis pas vraiment inquiet, mais j’en arrive au point où je vais commencer à insulter les gens et vous crier dessus, si vous m’envoyez des choses qui ne sont pas adéquates pour les dernières publications de RC. Ça ne veut pas dire que des gens l’ont fait : bien que la RC6 soit plus grosse que je le souhaitais, je ne pense pas qu’il y ait trop de choses manifestement frivoles dedans. Mais je vais continuer de garder un œil dessus, et je vais commencer à être grincheux (ou PLUS grincheux) si je remarque que les gens ne sont pas sérieux concernant le fait d’essayer de calmer les choses.

Malgré tout, la RC6, elle‐même, finit par avoir des changements à peu près partout : pilotes (le principal étant du réseau, mais il y a du processeur graphique, il y a InfiniBand, nommez‐le comme vous voulez), les systèmes de fichiers (corrections NFS tardives, XFS, FUSE, GFS2, Btrfs), du code réseau de base, etc, etc. Ci‐joint le rapport résumé pour ceux qui sont intéressés par (un aperçu) des détails.

Donc, allez récupérer la dernière RC et donnez un coup de pied dans les pneus, pour voir si rien ne passe entre les fissures. OK ?

Linus

RC-7

La version RC-7 est sortie le 27 juillet 2014.

Je suis content de dire que les choses se sont un peu calmées, et les choses semblent être sur la bonne voie.

Ce qui n’était, en fait, pas du tout le cas au début de cette semaine — nous avions ce qui semblait être des bogues au cœur du code vraiment vicieux et, en plus du fait que la RC6 était plus grosse que les précédentes RC, je ne sentais vraiment pas bien cette publication pendant un moment.

Mais les bogues les plus « méchants » n’étaient, au final, pas du tout des bogues du noyau. L’un venait en réalité d’une erreur de compilateur NdT : la version de GCC de Debian était en cause (ce qui est toujours très effrayant, difficile à déboguer et très ennuyeux), et qui avait même une solution de contournement assez simple ce qui fait que nous n’avons pas eu à mettre des compilateurs sur listes noires. Un autre s’est avéré n’être qu’un faux positif, car lockdep était un peu trop agressif.

Nous avons évidemment effectué diverses vraies corrections là‐dedans, mais aucune n’a l’air spéciale ou inquiétante. Et la RC7 est finalement sensiblement plus petite que les RC précédentes, donc nous sommes clairement en train de nous calmer. Donc, contrairement à mes précédentes inquiétudes, ce pourrait être la dernière RC ; nous verrons comment la semaine prochaine se passera.

En chiffres, la RC7 se compose d’environ un tiers d’architectures (Xtensa, PowerPC, x86, s390, Blackfin), un tiers de pilotes (pilotes graphiques, média, réseau) et un tiers de divers (réseau, gestion mémoire). Mais c’est assez petit. Journal résumé en pièce jointe.

Linus

Version finale

La version finale est sortie le 2 août 2014.

Alors, rien de spécialement intéressant ne s’est passé cette semaine, et la version 3.16 est arrivée.

Et comme d’habitude (la version précédente faisant figure d’exception), cela signifie que la fenêtre d’intégration de la version 3.17 est évidemment ouverte. Pour la troisième fois consécutive, le calendrier craint, car j’ai un voyage à venir pendant la seconde semaine de la fenêtre. De nombreux autres développeurs principaux seront aussi en déplacement, car c’est juste avant le Kernel Summit de Chicago.

Donc nous verrons comment se passera la prochaine fenêtre d’intégration, mais je ne vais pas m’en préoccuper outre mesure. Si finalement je n’arrive pas à venir à bout des intégrations, je pourrai retarder dans la semaine du Kernel Summit, mais j’espère terminer la pluplart des grosses intégrations la semaine prochaine, avant tout départ en voyage, alors peut‐être qu’on n’en arrivera pas là. Il s’agit juste d’une information sur le fait que la fenêtre d’intégration pourrait être allongée.

Quoi qu’il en soit, revenons aux changements depuis la RC7 : ce sont vraiment d’assez petits changements épars, avec un tiers de modifications d’architectures, un tiers de pilotes et un tiers de « divers » (principalement gestion mémoire et réseau). Les trucs d’architecture sont de petites mises à jour d’ARM (surtout DT), quelques corrections de Xen pour x86, et diverses petites choses pour PowerPC. Le journal résumé des changements donne une bonne idée de genre de truc que c’est, mais ça ne représente en réalité que 83 commits (plus les fusions et le commit de publication), et dont environ un tiers d’entre eux marqués comme stables.

Bien que la version 3.16 ait semblé un peu incertaine pendant un moment, les choses se sont gentiment clarifiées, et il n’y avait aucune raison pour faire une version candidate supplémentaire comme je le craignais il y a quelques semaines.

Linus

Les nouveautés

Architecture

Problèmes avec GCC 4.9

Un bogue assez pénalisant a été repéré au sein de l’ordonnanceur par des développeurs du noyau. Lorsque ce dernier était compilé en mode débogage, le compilateur gcc ne compilait pas correctement la fonction load_balance() au sein de l’ordonnanceur, ce qui entraînait des comportements complètement inexplicables. Il s’agit d’un problème datant de gcc 4.5 et qui se serait manifesté avec la sortie de gcc 4.9 et 4.9.1, suite à l’activation de certaines optimisations. Le problème est maintenant corrigé dans la version de développement de gcc. En attendant, une solution de repli a été trouvée, il s’agit de compiler le noyau avec l’option -fno-var-tracking-assignments, ce qui cache l’existence du bogue.

Pour plus de détails, consultez le commit.

Unification de la hiérarchie des cgroups

L’architecture actuelle des cgroups permet de créer plusieurs hiérarchies dans lesquelles on va pouvoir regrouper les processus et leur appliquer des restrictions lorsque ces hiérarchies sont spéciales, c’est‐à‐dire associées à des contrôleurs (options passées lors du montage). En pratique, cette hiérarchie est visible sous la forme d’un pseudo‐système de fichiers :

$ ls -l /sys/fs/cgroup
total 0
dr-xr-xr-x 2 root root  0 Aug  7 01:52 blkio
lrwxrwxrwx 1 root root 11 Aug  6 12:03 cpu -> cpu,cpuacct
lrwxrwxrwx 1 root root 11 Aug  6 12:03 cpuacct -> cpu,cpuacct
dr-xr-xr-x 2 root root  0 Aug  7 01:52 cpu,cpuacct
dr-xr-xr-x 2 root root  0 Aug  7 01:52 cpuset
dr-xr-xr-x 2 root root  0 Aug  7 01:52 devices
dr-xr-xr-x 2 root root  0 Aug  7 01:52 freezer
dr-xr-xr-x 2 root root  0 Aug  7 01:52 memory
dr-xr-xr-x 2 root root  0 Aug  7 01:52 net_cls
dr-xr-xr-x 4 root root  0 Aug  7 01:52 systemd

$ tree /sys/fs/cgroup/systemd
/sys/fs/cgroup/systemd
├── cgroup.clone_children
├── cgroup.procs
├── cgroup.sane_behavior
├── notify_on_release
├── release_agent
├── system.slice
│   ├── cgroup.clone_children
│   ├── cgroup.procs
│   ├── dbus.service
│   │   ├── cgroup.clone_children
│   │   ├── cgroup.procs
│   │   ├── notify_on_release
│   │   └── tasks
...
│   ├── home.mount
│   │   ├── cgroup.clone_children
│   │   ├── cgroup.procs
│   │   ├── notify_on_release
│   │   └── tasks
...
├── tasks
└── user.slice
    ├── cgroup.clone_children
    ├── cgroup.procs
    ├── notify_on_release
    ├── tasks
    └── user-1000.slice
        ├── cgroup.clone_children
        ├── cgroup.procs
        ├── notify_on_release
        ├── session-1.scope
        │   ├── cgroup.clone_children
        │   ├── cgroup.procs
        │   ├── notify_on_release
        │   └── tasks
        ├── tasks
        └── user@1000.service
            ├── cgroup.clone_children
            ├── cgroup.procs
            ├── notify_on_release
            └── tasks
...

Ici, la hiérarchie systemd n’est associée à aucun contrôleur, alors que les autres imposent des contraintes sur l’utilisation de la mémoire, du processeur…

Tout ceci est donc très flexible mais difficile à gérer lorsque l’on veut modifier de façon cohérente les restrictions appliquées à un groupe de processus ou ajouter des restrictions à un groupe qui n’en avait pas auparavant. Cette complexité est avantageusement masquée par systemd, qui se charge actuellement de la gestion des cgroups en proposant des options plus accessibles dans les fichiers d’unit pour les services (systemd.resource-control — Resource control unit settings).

Ainsi, il a été décidé de se débarrasser de cette séparation en plusieurs hiérarchies pour regrouper tous les contrôleurs dans une seule hiérarchie. Cela permet d’inclure dans l’architecture même de cette hiérarchie toutes les opérations que systemd fait actuellement afin d’éviter cette complexité.

Cette hiérarchie unifiée est disponible dans le noyau 3.16, mais elle n’est pas activée par défaut. Il faut monter le pseudo‐système de fichiers contrôlant les cgroups avec les options :

$ mount -t cgroup -o __DEVEL__sane_behavior cgroup <mount-point>

Il est pour l’instant possible d’utiliser les deux hiérarchies simultanément pour tester le comportement de la nouvelle version, mais cela ne sera bien entendu plus possible dans les prochaines versions.

Cette unification introduit aussi la notion de délégation : un processus privilégié (systemd) pourra déléguer le contrôle d’une partie de la hiérarchie à un autre processus, par exemple à un processus systemd dans un conteneur (LXC, Docker, systemd-nspawn), voire à un processus systemd pour la session d’un utilisateur.

Plus d’informations sont disponibles dans l’article de LWN (The unified control group hierarchy in 3.16), ainsi que dans la documentation officielle (Cgroup unified hierarchy) qui décrit notamment comment se servir de cette nouvelle hiérarchie.

Système mono‐puce ARM (SoC ARM)

Cette version intègre pas mal de nouveautés sur les plates‐formes ARM.

La carte de développement NVIDIA Jetson TK1 dispose désormais d’un début de prise en charge. Il s’agit d’une carte embarquée dotée d’un processeur graphique NVIDIA Kepler avec 192 cœurs CUDA, un processeur quadruple‐cœur basé sur l’ARM Cortex A15, 2 Gio de mémoire vive, USB 3, mini‐PCIe. Bref, une véritable machine de guerre. Les cartes NVIDIA Tegra Note 7 et Shield sont intégrées à l’arborescence matérielle Device Tree (DT) et disposent également d’une prise en charge initiale pour cette version.

La gestion multi‐plate‐forme des cartes Samsung Exynos est désormais en place. Il s’agit d’une spécificité des plates‐formes ARM au sein du noyau Linux qui permet à une même image noyau de pouvoir s’exécuter sur différents systèmes mono‐puces (SoC) d’une même famille de processeurs, ou à un même pilote de périphérique de pouvoir fonctionner sur différents matériels tout en gardant un cœur générique et indépendant de la machine ou de la carte embarquée sur laquelle il tourne. Cela évite de devoir mettre en dur dans le code des informations spécifiques au matériel. C’est notamment possible grâce à l’utilisation du Device Tree. Les familles de processeurs ARM qui disposent de cette fonctionnalité sont de plus en plus nombreuses, on peut notamment citer : Samsung Exynos, Freescale i.MX, NVIDIA Tegra, Texas Instruments OMAP ou encore ceux de Rockchip.

Parmi les nouveautés les plus marquantes, nous pouvons également noter la gestion du Symmetric MultiProcessing (SMP) pour les Marvell Armada 375/38x et les Allwinner A31, ainsi que l’arrivée de la prise en charge de nouveaux systèmes mono‐puces : Freescale i.MX6SX, LSI Axxia AXM55xx et Samsung Exynos 3250, 5260, 5410, 5420 et 5800. Pour plus de renseignements concernant les nouvelles fonctionnalités ARM pour cette version, je vous invite à regarder le commit plus en détail.

MIPS

Pas mal de nouveautés sont au rendez‐vous pour l’architecture MIPS. La para‐virtualisation fait son apparition au sein de Linux 3.16. Le nombre maximum de processeurs se voit augmenté de 64 à 256.
Il est maintenant possible d’éteindre la carte d’évaluation Malta, qui dispose d’un mode d’extinction logiciel (c’est‐à‐dire générique et non propre à la carte).

Un début de gestion de l’Octeon 3 a également été ajouté. L’Octeon 3 est le nouveau processeur de Cavium annoncé en fin d’année 2013. Il s’agit d’un processeur multi‐cœur basé sur les processeurs MIPS 64 bits, gravé en 28 nm et orienté calcul haute performance.

Pour plus de renseignements, lire la demande d’intégration.

ARM64

big.LITTLE dans cpufreq

Une nouveauté assez intéressante est l’ajout du mode big.LITTLE de la dernière famille de processeurs ARMv8 au sein du pilote CPUFreq. Le mode big.LITTLE est une nouvelle technologie dite « d’optimisation de gestion de l’énergie » qui permet au processeur ARM de disposer d’un maximum de performances lorsqu’il en a besoin, tout en préservant au maximum son énergie lorsque cette puissance n’est pas nécessaire. Pour ce faire, le système mono‐puce est doté de plusieurs cœurs destinés au calcul intensif (BIG) et d’autres qui consomment moins d’énergie qui sont destinés à faire tourner les tâches moins gourmandes en ressources (LITTLE). Le système mono‐puce fait connaître ses cœurs de processeurs BIG et LITTLE au système d’exploitation afin que les tâches puissent migrer à chaud d’un cœur de calcul à l’autre en fonction de la charge du cœur sur lequel il se trouve, mais aussi en fonction de son « historique » logiciel d’exécution, ce qui permet à l’ordonnanceur de pouvoir anticiper ses décisions.

Il ne s’agit là que d’une gestion au sein de CPUFreq lui permettant ainsi de décider quel cœur doit être activé et quel cœur doit être éteint, et ainsi gérer les « niveaux de puissance » (power states) en conséquence. Les futurs changements concernant l’ordonnanceur devraient voir le jour dans les prochaines versions.

EFI Stub

L’architecture ARM 64 bits dispose désormais de la gestion d’EFI stub. L’EFI stub de Linux permet à un système disposant d’un micrologiciel (U)EFI de démarrer l’image du noyau directement sans avoir à passer par un chargeur d’amorçage (tel que GRUB ou elilo). Ceci est notamment possible en ajoutant du code au début de l’image du noyau afin de faire croire au micrologiciel (U)EFI qu’il s’agit d’une image de type PE/COFF, de cette façon le noyau se fait passer pour un exécutable (U)EFI. Pour plus de renseignements, voir la demande d’intégration.

AMD Seattle

Le nouveau système mono‐puce ARM 64 bits Opteron A1100 d’AMD, baptisé Seattle, se voit pris en charge par cette nouvelle version du noyau. Il s’agit du premier système mono‐puce ARM de chez AMD, destiné à équiper les serveurs à basse consommation d’énergie dédiés à la gestion de données massives (ce qu’on appelle communément le « big data »). Cette puce comprend huit cœurs ARM Cortex A57 cadencés à plus de 2 GHz chacun, gère jusqu’à 128 Gio de mémoire vive, intègre la technologie ARM TrustZone, un bus PCIe doté de huit voies, deux ports Ethernet 10 Gbit/s, de co‐processeurs cryptographiques et de compression‐décompression. Selon AMD, La série A de Opteron irait jusqu’à deux à quatre fois plus vite que la série X et disposerait d’un bien meilleur rendement énergétique (rapport performance / consommation). Le meilleur étant, bien entendu, pour la fin : le prix !

x86 : Intel Broadwell dans P-State

La future génération de processeurs de chez Intel, baptisée Broadwell est maintenant prise en charge dans le pilote P-State.

Pour rappel, P-State est le nouveau pilote Intel au sein du noyau Linux qui permet de contrôler plus finement les tensions électriques et les fréquences des éléments du processeur, afin gérer plus efficacement la consommation énergétique (notamment comparé au pilote de CPUFreq).

Pilotes graphiques libres

DRM (Direct Rendering Manager)

Contrairement à Linux 3.15, le code commun aux pilotes graphiques libres (DRM) a reçu peu d’attention dans cette version. Les modifications les plus intéressantes dans l’immédiat sont une mise à jour de la documentation et la correction d’une situation de concurrence (race condition) dans le nommage des connecteurs et des encodeurs. Pour finir, la gestion des verrous a été revue en préparation du travail sur la gestion atomique du mode graphique.

Cette gestion atomique du mode graphique est un saint Graal en discussion depuis au moins 2012. Une présentation claire a été donnée au FOSDEM 2013 qui explique l’intérêt d’avoir une interface transactionnelle pour la gestion du mode graphique afin de respecter le mantra de Wayland, qui est que toute image doit être parfaite, même lorsque l’on modifie des plans d’affichage graphique.

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

Adreno (pilote msm)

Peu de nouveautés pour Adreno dans cette nouvelle version, si ce n’est l’ajout d’outils de débogage à destination des développeurs.

La nouveauté majeure est l’ajout d’une gestion très partielle des compteurs de performance, exposés dans debugfs. Les compteurs exposés sont le temps d’activité du processeur graphique, ALUACTIVE et ALUFULL.

Toujours dans debugfs, il est maintenant possible de récupérer les commandes envoyées avec les numéros de barrières (fences) associées. Il est aussi possible de connaître l’état des registres, afin de pouvoir retrouver quel groupe de commandes a planté le processeur graphique.

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

AMD/ATI (pilote radeon)

La nouveauté principale du pilote Radeon est l’ajout de la gestion du Deep Color. Au lieu d’utiliser 8 bits par composante (rouge, verte ou bleu), il est maintenant possible d’utiliser 10 ou 12 bits par composante pour les écrans qui le gèrent. Comme certains écrans disent, à tort, gérer cette fonctionnalité, celle‐ci a été désactivée par défaut jusqu’à ce que tous les bogues aient été corrigés. Si vous voulez tester cette fonctionnalité pour vérifier qu’elle n’ajoute pas de régression ou qu’elle fait ce qui est attendu, vous devez rajouter le paramètre noyau « deep_color=1 » pour le module radeon.

Une optimisation de la mémoire virtuelle pour la gestion des tampons graphiques situés dans le tableau de réadressage de la mémoire graphique (Graphics Address Remapping Table — GART) a été également été ajoutée à cette version pour les familles Southern Islands et Sea Islands. Le programme d’évaluation Unigine Tropics a mesuré un gain de performances jusqu’à 34 %.

Des corrections de bogues ont imposé l’activation permanente du BAPM (Bidirectional Application Power Management) pour certaines puces graphiques d’AMD. Le BAPM est une gestion de la consommation énergétique plus fine (plus granulaire) remplaçant l’ancienne DPM (Dynamic Power Management) aux seuils de déclenchement plus larges. BAPM est désormais activée implicitement. Ce système agit sur la fréquence de fonctionnement de la puce qui peut passer rapidement, par exemple, de 3,4 GHz à 1,4 GHz par des seuils plus fins qu’avec DPM. Plus la fréquence est basse, moins on consomme. Malgré son caractère expérimental, cette fonction indispensable pour les portables et mobiles est désormais activée en permanence sur les puces de type Trinity, car ces systèmes plantaient souvent lorsque le DPM était activé.
De même, le DPM classique activé (radeon.dpm=1) empêchait le démarrage des systèmes à base de puces compatibles ARUBA, même avec l’alimentation secteur, et principalement dans les APU. Non seulement, le BAPM a permis une meilleure gestion de l’énergie des puces ARUBA, mais il a également accru significativement leur performance.

Pour plus d’informations, vous pouvez consulter les demandes d’intégration Radeon [1] et [2].

Intel (i915)

La nouveauté principale du pilote Intel dans cette version est la possibilité pour une application de créer un tampon graphique à partir d’un tampon alloué avec malloc(). Cela permet d’éviter de faire des copies lors de transferts vers ou depuis le processeur graphique, et donc d’améliorer les performances en réduisant les latences. Jérôme Glisse a réagi et exprimé son mécontentement, car ce correctif change radicalement la gestion de la mémoire et est probablement peu sûr. Il a proposé une explication de comment une erreur pourrait se produire, mais le correctif a quand même été accepté. Celui‐ci devrait améliorer les performances des compositeurs graphiques en évitant la recopie des fenêtres exposées par mémoire partagée au compositeur.

Le pilote i915 continue sa transformation progressive vers la commutation atomique de page mémoire (atomic page flipping) et l’exposition de ses plans d’affichage graphique, sans que ce soit pour l’instant utilisable par les utilisateurs. Cependant, il est maintenant possible d’utiliser des curseurs de 256 × 256 pixels au lieu de 64 × 64, ce que les possesseurs d’écrans à haute densité de pixels, tels que le Retina d’Apple, devraient apprécier. Pour l’exploiter, il vous faudra utiliser une version Git de xf86-video-intel et l’architecture SNA.

Une première version de la gestion du Connected Standby (alias InstaGo) est maintenant disponible. Celle‐ci est équivalente à une mise en veille de la machine, mais les applications peuvent réveiller la machine sans intervention de l’utilisateur. Sous Windows, cette fonctionnalité désactive la possibilité de faire une mise en veille en mémoire ou sur le disque et nécessite à la fois un micro‐logiciel UEFI et une carte réseau compatibles. Les pré‐requis pour Linux ne sont pas encore connus.

Le pilote i915 a maintenant plus de chance de survivre à une situation où il manquerait de mémoire. Dans le cas où il survivrait, plus d’informations seront disponibles pour diagnostiquer la raison.

Une gestion préliminaire de la 3D pour les nouveaux systèmes mono‐puces Atom Cherryview, qui devrait sortir en septembre 2014, a été ajoutée. Son unité de rendu est basée sur les processeurs Broadwell (sortie prévue fin 2014), alors que le bloc d’affichage est une version améliorée de celui de la génération précédente, Valleyview. Mesa 3D a déjà été modifié afin de gérer ces nouveaux systèmes mono‐puces.

En parlant de Valleyview, celui‐ci a reçu beaucoup d’attention pour corriger de multiples bogues. Cependant, l’amélioration la plus importante est la gestion des écrans MIPI DSI. Cela permettra de faire fonctionner l’Asus T100 correctement, sans bidouille !

Les processeurs de la famille Broadwell gèrent maintenant l’eDRAM, qui sert à fournir 128 Mio de cache de niveau 4 pour les processeurs Iris Graphics basés sur Broadwell, la technologie boost, ainsi que le décodage vidéo matériel grâce au moteur VEBOX2.

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)

La nouveauté principale de Nouveau dans cette version est la réécriture de la gestion du DisplayPort, ce qui a permis de corriger énormément de bogues et permet enfin aux moniteurs de se mettre en veille et de pouvoir en sortir.

Le changement de fréquence manuel est maintenant activé par défaut pour les cartes des familles NV40 (GeForce 7), NVAA/NVAC (ION) et NVE0 (Kepler). Cette gestion est expérimentale et est à utiliser à des fins de test uniquement [commit]. Phoronix a fait quelques bancs de test utilisant cette nouvelle capacité. Toutes les cartes n’ont pas réussi à être re‐cadencées à leur vitesse maximale, mais quand elles l’étaient, les performances étaient améliorées la plupart du temps d’un facteur 4, et jusqu’à 5,8 pour OpenArena. Ce n’est cependant pas suffisant pour atteindre la vitesse du pilote propriétaire, puisque sur les puces de la famille Kepler, Nouveau n’atteint à fréquences égales que de 59 % à 80 % des performances du pilote NVIDIA.

La gestion du GK20A (processeur graphique intégré aux Tegra K1 basé sur Kepler) fait enfin son entrée dans Nouveau grâce au travail d’Alexandre Courbot de NVIDIA. Cette gestion est conditionnelle à l’utilisation des microcodes de NVIDIA pour la gestion des contextes graphiques, jusqu’à ce qu’un contributeur fasse le travail de rétro‐ingénierie ou jusqu’à ce que NVIDIA donne le droit à Nouveau de redistribuer le microcode.
En l’état actuel, il devrait donc être possible de créer un contexte graphique et faire du rendu dans une texture. Cette texture pourra ensuite être envoyée via Prime (dma-buf) au pilote host1x qui gère l’affichage, mais pas avant Linux 3.18. La gestion de la mémoire est actuellement expérimentale et est en train d’être améliorée par Alexandre. Côté espace utilisateur, il vous faudra attendre la sortie de la prochaine version de Mesa 3D qui devrait arriver aux alentours de la conférence des développeurs de X.Org XDC 2014, qui aura lieu à Bordeaux du 8 au 10 octobre 2014. D’après Alexandre, ce processeur graphique devrait être utilisable dès Linux 3.18.

En parlant de microcode de gestion des contextes graphiques, celui du jeu de puces GK208 a été corrigé afin de pouvoir gérer les unités (shaders) de géométrie.

Pour finir, les cartes GeForce GTX 780 Ti et Tesla K40 (GK110B) sont maintenant gérées par Nouveau grâce au travail d’un contributeur externe à Nouveau. Celui‐ci a également activé le décodage vidéo matériel sur les puces GK110, GK110B et GK208 [noms de code].

Samsung (pilote exynos)

Plusieurs corrections de bogues liés à la gestion de l’horloge et de la synchronisation verticale. Pour une liste plus détaillée des changements, vous pouvez consulter la demande d’intégration exynos.

Pour continuer sur la gestion des pointeurs utilisateur, Jérôme a proposé de désactiver complètement sa gestion, car son implémentation actuelle n’était pas sûre. Le mainteneur du pilote DRM Intel a approuvé. Espérons que cette gestion sera réécrite dans Linux 3.17 ou désactivée.

En vrac

• Aspeed (Ast) : Ajout de la gestion de l’AST2400.

• Freescale (ipuv3) : Le pilote ipuv3, pour les processeurs graphiques Freescale i.MX IPUv3, quitte la branche staging et intégre la branche /drivers/gpu/. Ce pilote ne respecte cependant pas le standard DRM, probablement parce qu’il ne propose pas d’affichage, comme Tegra.

• Tegra (pilotes host1x et tegra) : Ajout de la gestion des curseurs et du HDMI pour les Tegra 124 (K1).

  • Panels : Ajout de la gestion de plusieurs écrans.

Réseau

Le TCP Fast Open, ajouté dans Linux 3.13 pour l’IPv4, est maintenant disponible pour l’IPv6 [commit].
Pour mémoire, le TCP Fast Open permet de diminuer le temps de connexion à un service lorsque plusieurs connexions vers celui‐ci sont ouvertes. Avec TCP Fast Open, le serveur n’attend plus que le client émette l’acquittement final avant d’envoyer des données à l’utilisateur. D’un point de vue latence, cela permet d’ouvrir la connexion avec un seul aller, au lieu d’un aller, un retour et un nouvel aller. Cela peut être très efficace pour réduire drastiquement le temps des chargements des pages Web lorsque le réseau d’accès à Internet a une grosse latence.

Une émulation logicielle du TCP Segmentation Offload (TSO), c’est‐à‐dire du délestage de la segmentation TCP, a été ajoutée au noyau et permet à des systèmes mono‐puces d’augmenter leur débit maximal de 16 % à 54 %, tout en réduisant l’utilisation processeur de 40 % dans un test de performance basé sur HTTP (commits : 1 et 2). En principe, le TSO consiste à envoyer l’ensemble des données à transmettre à la carte réseau et laisser celle‐ci découper les paquets. Cela permet de limiter la consommation processeur sans perdre de performance.

AMD a ajouté la gestion d’une nouvelle carte Ethernet permettant d’atteindre 10 Gbit/s. Le pilote de cette carte s’appelle "amd-xgbe" et celle‐ci fera partie du système mono‐puce Seattle (commits : [1], [2], [3] et [4]).

Sécurité

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

• CVE-2014-0206 [correctif 1, correctif 2] ;
• CVE-2014-3534 [correctif] ;
• CVE-2014-4014 [correctif] ;
• CVE-2014-4171 [correctif] ;
• CVE-2014-4508 [correctif].

Bit NX et chargement des modules

Les zones mémoire utilisées pour stocker le code et les données d’un module sont protégées respectivement en lecture seule (RO) et en non exécution (NX) à l’aide de la technologie du bit NX présente dans les processeurs x86 modernes. Jusqu’à présent, ces protections étaient mises en place assez tard dans le chargement d’un module par le noyau. Elles sont maintenant activées avant que les arguments passés lors du chargement du module soient analysés, c’est‐à‐dire juste avant la première exécution de code appartenant au module en cours de chargement [correctif]. Cela améliore légèrement la sécurité, en diminuant l’impact d’une erreur dans le code analysant les arguments passés à un module.

Compilation à la volée des filtres seccomp

Les filtres seccomp peuvent maintenant profiter du compilateur à la volée (JIT — Just In Time) qui a été ajouté pour le langage BPF [correctif]. Ce langage ne servait au départ que pour le filtrage des paquets réseau, mais il a été étendu et est utilisé par plusieurs sous‐systèmes du noyau (voir BPF: the universal in‐kernel virtual machine et Extending extended BPF).

IMA et EVM

L’utilisation du mode O_DIRECT pour accéder aux fichiers contrôlés par une politique IMA — Integrity Measurement Architecture — pouvait provoquer un interblocage. Ce problème n’est pas encore complètement résolu, mais une solution temporaire a été trouvée pour autoriser un administrateur à désactiver dans la politique de sécurité le contrôle d’IMA pour certains fichiers lorsque le mode O_DIRECT est utilisé [correctif].

La méthode de calcul des signatures HMAC utilisées par EVM — Extended Verification Module — a été modifiée [correctif] pour permettre plus facilement l’ajout de nouveaux attributs étendus (par exemple ceux de SMACK) [correctif]. L’accès à l’attribut étendu qui stocke cette signature est maintenant restreint [correctif].

Un bogue pouvant provoquer des « kernel oops » lorsqu’IMA était utilisé avec AppArmor a été corrigé [correctif].

LSM

SELinux

Les informations présentes dans les messages d’erreur d’accès SELinux les AVC — Access Vector Cache — ne permettaient pas de savoir si l’accès avait été réellement bloqué ou s’il avait été autorisé parce que le système ou le type était en mode permissif. Un nouvel élément permissive= permet d’obtenir cette information [correctif].

Lorsqu’un processus fait appel à exec(), le contexte SELinux reste par défaut celui du père, mais il peut être changé si la politique le précise et que le contexte du fichier exécuté correspond (transition de domaine à l’exécution). Une troisième façon de définir le contexte d’exécution SELinux d’un processus à l’avance est d’utiliser l’appel setexeccon(). Dans le cas où un programme tentait un exec() d’un fichier dans un système de fichiers monté avec l’option nosuid, cette transition n’était pas effectuée, mais aucune erreur n’était retournée. Le code d’erreur -EACCES est maintenant retourné dans ce cas [correctif].

SMACK

Note : Si vous avez du mal à faire la correspondance entre les accès autorisés et les étiquettes SMACK, je vous conseille de vous référer à la documentation.

Pour rappel, SMACK — Simplified Mandatory Access Control Kernel — stocke les règles de contrôle d’accès aux objets représentés dans l’arborescence du système dans les attributs étendus (dans l’espace de noms security). Il n’est pour l’instant pas possible d’utiliser les attributs étendus avec les pseudo‐fichiers décrivant les cgroups. Ces pseudo‐fichiers sont donc étiquetés par défaut avec l’étiquette « * », ce qui signifie qu’aucun contrôle supplémentaire n’est effectué par SMACK (tous les accès sont autorisés par SMACK). Ce contournement est nécessaire pour faire fonctionner systemd avec SMACK (probablement dans le cadre du projet Tizen) [correctif].

Certaines opérations effectuées sur des descripteurs de fichiers ouverts en écriture seule peuvent être apparentées à des opérations de lecture. En effet, les appels système fstat() et lseek(), par exemple, permettent d’obtenir des informations sur l’état du fichier ouvert et peuvent donc être considérés comme des opérations de lecture. SMACK autorisait ces appels système si le descripteur de fichier était ouvert en écriture seule et que les étiquettes SMACK autorisaient l’opération write(). Ce comportement pouvait potentiellement mener à la création d’un canal d’information caché qui n’est pas contrôlé par SMACK. Il n’est donc plus possible d’ouvrir un descripteur de fichier en écriture si l’on ne dispose pas aussi des droits SMACK pour l’ouvrir en lecture (on peut par contre ne pas disposer des droits DAC en lecture) [correctif].

Une modification du même style avait été ajoutée à SMACK dans le noyau 3.13 (cf. Sortie de Linux 3.13 au paragraphe SMACK). Dans le cas précédent, une nouvelle opération avait été ajoutée pour gérer correctement le cas de figure, mais ici les appels système fstat() et lseek() ne sont pas contrôlés par les hooks LSM, donc ce n’est pas une solution possible actuellement.

Pour pouvoir envoyer une information par l’intermédiaire d’une communication inter‐processus (IPC), SMACK vérifie que le processus émetteur dispose du droit d’accès SMACK write sur le destinataire. Dans le cas des sockets UNIX (UNIX domain socket) la vérification est faite uniquement à la connexion et n’était faite que dans un sens (du processus ouvrant le socket vers le processus ayant créé le socket, et pas l’inverse). C’est maintenant corrigé [correctif].

Le retrait de l’attribut SMACK64TRANSMUTE d’un dossier n’avait pas l’effet désiré. C’est maintenant corrigé [correctif].

L’affectation d’une chaîne vide comme valeur à un attribut étendu ne provoque plus de panique du noyau [correctif].

Un utilisateur doit avoir la capacité CAP_MAC_ADMIN pour pouvoir enlever les attributs étendus SMACK d’un fichier. Il était possible, par erreur, d’enlever l’attribut étendu SMACK64MMAP. C’est maintenant corrigé [correctif].

Une entrée ptrace() a été ajoutée au pseudo‐système de fichiers permettant de contrôler le comportement de SMACK. Elle permet de régler le niveau de sécurité requis pour pouvoir utiliser l’appel système ptrace() [correctif]. Les vérifications liées à l’appel ptrace() ont été regroupées [correctif]. Un bogue inversant la vérification lors d’un appel à ptrace() a été corrigé [correctif].

Les vérifications effectuées lors de l’accès au trousseau de clefs stocké dans le noyau ont subi une correction. Elles étaient incorrectes car une clé avec une étiquette « _ » ne pouvait être lue alors qu’elle aurait dû être accessible par tout le monde [correctif].

Systèmes de fichiers

Le nettoyage et la réorganisation de code sont des points importants sur le long terme. Quelques fichiers concernant les couches en mode bloc de VFS passent ainsi de l’arborescence fs/ et mm/ vers le dossier fédérateur block/.

XFS

Du côté de chez XFS, Dave Chinner nous apprend que le code a subi un nettoyage et un peu de réusinage.

Btfrs

Le plus gros changement dans cette version est la refonte du calcul des quotas que Josef Bacik a effectuée et qui améliore le suivi en mémoire des opérations extent en attente.

Chris Mason a travaillé de son côté sur l’utilisation de la pile Btrfs, car il est devenu impossible d’effectuer les longs tests de charge avec slab(), lockdep() et pagealloc() en mode debogage, sans faire exploser la pile.

Enfin, il y a les habituelles corrections de bogues, le lot d’optimisation et de nettoyage de code.

Pour plus de détails, il est possible de consulter le rapport résumé.

Phoronix nous offre quelques tests de performances (ici et là), et le bilan est assez simple : il n’y a pas de changements statistiquement notables.

F2FS

Jaegeuk Kim nous indique que Samsung s’affaire toujours à améliorer ce système de fichiers.

Il prend en charge des partitions de taille supérieure à 2 Tio correctement, tout en améliorant la gestion du readahead. Pour rappel, cette lecture anticipée permet de précharger un fichier dans la mémoire vive pour diminuer les temps de latence par la suite.

Enfin, le flush() des fichiers a été amélioré.

Reiser4

Ivan Shapovalov a continué à travailler sur l’implémentation du mécanisme de discard (mise au rebut), aussi connu sous le nom de TRIM. Celui-ci permet d’informer un SSD que des blocs mémoire sont inutilisés et peuvent être effacés.

Ce travail devrait permettre d’améliorer les performances de Reiser4 avec les SSD.

NFS

Neil Brown a corrigé NFS afin que les montages locaux (sur la même machine) fonctionnent correctement dans tous les cas de figure. Par ailleurs, la gestion XDR (eXternal Data Representation) a été réécrite afin de pouvoir gérer de grosses listes de contrôle d’accès (Access Control Lists) faisant plus de 4 Kio. De même, la fonction readdir() renvoie aussi des résultats pouvant faire plus de 4 Kio, ce qui améliore les performances pour les dossiers ayant un très grand nombre de fichiers.

Virtualisation

KVM

Plus de 200 commits pour cette version, répartis un peu partout. Commençons avec x86, pour lequel on retrouve la virtualisation imbriquée pour Xen : c’est‐à‐dire qu’il est possible de faire tourner Xen dans une machine KVM tout en permettant la virtualisation matérielle de Xen. C’est une fonctionnalité principalement utile pour les migrations ou les tests.

Du côté des processeurs ARM, la publication des informations PSCI (Power State Coordination Interface) en version 0.2 est disponible avec les instructions ARMv8. Dans les noyaux précédents, seule la version 0.1 de PSCI était disponible. Ces instructions permettent d’améliorer la gestion de l’énergie, particulièrement quand plusieurs systèmes d’exploitation tournent sur un même système mono‐puce et qu’il faut qu’ils se coordonnent, par exemple pour savoir quand un processeur peut être éteint.

Dans le cas des processeurs POWER, la prise en charge de u-boot est disponible pour les systèmes embarqués, pour la version 8, la prise en charge des hôtes configurés en petit‐boutiste (Little Endian).

Et enfin, pour le S/390 (mainframe IBM), les principaux changements sont la prise en charge des migrations, ainsi que de débogueur GDB.

Pour la prochaine version, on attend un gros lot de commits pour le x86, et le retrait de l’architecture IA-64 (les Itanium).

Xen

Xen sous ARM gère désormais les deux fonctions suspend() et resume(). Côté réseau, l’interface virtuelle pour gérer le réseau prend désormais en charge le mode multi‐queue, ce qui améliore les performances réseau des machines virtuelles.

Le bilan en chiffres

En ce qui concerne les statistiques du cycle de développement de Linux 3.16, on peut se référer à la page dédiée du site remword.com qui compile des statistiques relatives au développement de Linux.

Le nombre final de correctifs incorporés dans cette version est de 12 802, soit légèrement en dessous des 13 720 correctifs de la précédente. Ces ajouts sont le résultat du travail d’environ 1 527 développeurs soit, là encore, une légère baisse par rapport aux 1 547 développeurs du noyau précédent.

C’est à nouveau Intel qui occupe la tête du classement des entreprises avec 10,52 % des correctifs, suivi de très près par Red Hat (10,37 %). Red Hat est, en revanche, l’entreprise qui signe le plus de correctifs, avec 11,85 % contre 10,25 % pour Intel.

Les hobbyistes occupent comme d’habitude la troisième place, avec 5,73 %, si l’on ne comptabilise pas les contributeurs dont l’affiliation est inconnue, qui représentent 18,01 % des contributions. Le développement de Linux est donc majoritairement sponsorisé par des entreprises, mais il reste encore de nombreux passionnés qui font ça pour eux.

Appel à volontaires

Jiehong, le mainteneur actuel de la partie Systèmes de fichiers va laisser sa place à une personne ayant plus de temps. Cette position est maintenant ouverte.

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

	Mainteneur	Contributeur(s)
La phase de test	Aucun	Mali, Julien Pecqueur
Architectures	Romain Perier	Mali, Timothée Ravier
Pilotes graphiques libres	Martin Peres
Réseau	Florent F.	Martin Peres
Systèmes de fichiers	Jiehong	Mali, Julien Pecqueur
Sécurité	Timothée Ravier
Virtualisation	Xavier Claude
Édition générale	Aucun	Martin Peres, 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. 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 (498 clics)
• Site officiel du noyau Linux (245 clics)
• LWN : The 3.16 merge window concludes (69 clics)
• Kernel-Log – Was 3.16 bringt (1): Storage & Netzwerk (66 clics)
• Kernel-Log – Was 3.16 bringt (2): Infrastruktur (32 clics)
• Kernel-Log – Was 3.16 bringt (3): Treiber (30 clics)
• Linux 3.16 sur kernelnewbies.org (206 clics)
• The Best Features Of Linux 3.16 (356 clics)
• The New Features To The Linux 3.16 Kernel (220 clics)