Sortie du noyau Linux 4.1

La sortie de la version stable 4.1 LTS du noyau Linux a été annoncée le 21 juin 2015 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 se trouve dans la seconde partie de la dépêche.

Sommaire

En bref

Annonces des versions candidates par Linus Torvalds

RC-1

La version rc-1 est sortie le dimanche 26 avril 2015.

Cette fenêtre d’intégration a été normale et je publie, conformément au planning prévu. Mes quelques jours de voyage n’ont pas interféré, car j’avais toujours accès à Internet.

La fenêtre d’intégration est assez normale aussi par rapport à ce qui a été fusionné.
À juste regarder la taille, on se dit que ça va tout juste rentrer — alors que la 4.0 était un peu plus petite que d’habitude — la 4.1 semble pile dans la fourchette normale des deux dernières années. Et les statistiques des correctifs aussi ont l’air normales : le gros des changements concerne les pilotes (à peine moins de 60 % des correctifs), avec des mises à jour d’architecture autour de 20 % et le reste est disséminé un peu partout.

Aucune nouvelle fonctionnalité fracassante ne me vient à l’esprit, même si la prise en charge initiale de l’ACPI pour arm64 semble amusante. Selon vos intérêts, votre appréciation de « grande nouveauté » peut évidemment différer de la mienne. Il y a beaucoup de travail partout et certains points pourraient bien faire une grande différence selon vos usages.

Donc, allez-y, testez. Même une rc-1, aussi brute qu’elle puisse parfois être, a tendance à être de bonne qualité. Ce n’est pas si effrayant. Promis.

Linus

RC-2

La version rc-2 est sortie le dimanche 3 mai 2015.

Ces derniers temps, les rc-2 ont été plutôt petites — ressemblant plus à des rc tardives. Il fut un temps où je ne pouvais même pas poster le journal abrégé, parce qu’il était trop long. Ça n’a pas été le cas pour les quelques dernières versions.

Je pense que les gens ont tendance à prendre un moment de repos après la fenêtre d’intégration, parce que les rc-3 ont tendance à être un peu plus grosses à nouveau. Mais c’est peut-être aussi parce que je suis devenu meilleur à dire « la fenêtre d’intégration est terminée, je n’accepte pas les traînards » ou que les gens respectent mieux la fenêtre d’intégration. Quelle qu’en soit la raison, le temps des énormes rc-2 semble être heureusement révolu.

Donc, le cycle de développement de 4.1 correspond à ce nouveau modèle. Même si elle n’est pas aussi petite que, disons, la 3.19-rc2 ne l’était (elle était vraiment exceptionnelle), la 4.10-rc2 [sic] est plutôt petite et tout a été assez calme. Le diffstat est plutôt plat et propre, à l’exception notable du nouveau prng basé sur sha512 pour s390. Je suppose que j’aurais dû prendre aussi tout ça en main. Mais le reste a vraiment l’air de petits correctifs, pas de gros nouveaux morceaux de code.

Comme d’habitude, c’est un mélange de correctifs de pilotes, de mises à jour d’architectures (avec s390 se démarquant à cause d’un changement sur prng) et d’un peu de systèmes de fichiers et de réseau. Le journal abrégé ci-joint contient les détails, il n’y a rien de particulièrement inquiétant. Jusqu’à présent, la 4.1 a l’air plutôt normale.

Linus

RC-3

La version rc-3 est sortie le dimanche 10 mai 2015.

Et une version de dimanche de fête des mères pour vous, que vous soyez maman ou non. Car hé, c’est dimanche après-midi une fois encore et c’est juste comme ça que sortent mes versions -rc.

Rien de particulièrement effrayant ou inquiétant n’est à signaler, bien qu’il y ait de petites réparations un peu partout. Certaines sont les régressions de cette fenêtre d’intégration et d’autres sont plus vieilles. Et certaines sont si vieilles que j’ai presque pensé « si c’est cassé depuis 2011 et que tu le remarques seulement maintenant, ça aurait peut-être pu attendre la prochaine fenêtre d’intégration ». Vous vous reconnaîtrez (et les autres aussi, s’ils lisent les messages de commit — votre honte s’y trouve).

Le journal abrégé en annexe donne un aperçu honnête et il n’est pas trop gros. Comme vous pouvez le voir, c’est surtout des pilotes, avec une poignée de mises à jour d’architecture (surtout ARM). Et une poignée de trucs divers : outils de performances, documentation, systèmes de fichiers. La mise à jour d’infiniband est un morceau important des pilotes, on a eu des trucs retardés à cause de changements dans la maintenance.

Allez-y, testez. À la -rc3, les choses devraient être plutôt sans danger et ce serait le moment de vérifier que tout fonctionne correctement, si vous n’avez pas déjà testé un des noyaux de développement précédents.

Linus

RC-4

La version rc-4 est sortie le lundi 18 mai 2015.

Celle-ci a raté ma publication dominicale habituelle, parce que j’étais sorti presque toute la journée d’hier. De plus, il y avait une régression de la mise en veille qui semblait devoir recevoir un correctif imminent, donc ça ne me dérangeait pas de faire une publication tard dans la soirée, dans l’espoir d’une rustine supplémentaire.

Ça y est, correctifs de dernière minute et tout. Le patch rc-4 est un peu plus gros que les précédents, mais ça semble dû principalement à des aléas temporels normaux — simplement la fluctuation liée à l’arrivée de l’arborescence des sous-mainteneurs — et le fait que la rc-4 contienne les correctifs de Greg dans diverses arborescences de pilotes et les correctifs de Davem concernant le réseau, de sorte que la taille légèrement plus importante n’est pas représentative de soudains problèmes.

Bien que les pilotes et le réseau dominent les changements, il y a une poignée de changements épars : mises à jour des systèmes de fichiers (btrfs, nfsd), mises à jour d’architectures (principalement arm, arm64 et mips) et d’autres changements divers.

Allez-y et testez et avertissez chacun de la moindre régression trouvée.

Linus

RC-5

La version rc-5 est sortie le dimanche 24 mai 2015.

Je suis de retour à mon habituel calendrier dominical et la rc-5 est de retour à sa taille habituelle, après une légère augmentation de la rc-4.

Les choses semblent assez normales. Nous avons à peu près deux tiers de mises à jour de pilotes (gpu, infiniband, audio, réseau, scsi, température) et quasiment la moitié de ce qui reste est une mise à jour du réseau. Le reste est principalement des mises à jour d’architecture et quelques correctifs des systèmes de fichiers. Mais tout cela est plutôt restreint.

Donc, nous sommes dans les temps pour une 4.1 normale, si ce n’est que le calendrier de la prochaine fenêtre d’intégration semble se télescoper avec nos vacances familiales annuelles. Donc nous allons voir comment ça va marcher. Je pourrais finir par retarder la publication juste pour éviter cela (ou simplement retarder l’ouverture de la fenêtre d’intégration). Je n’ai pas encore décidé.

Mais s’il vous plaît, continuez à tester.

Linus

RC-6

La version rc-6 est sortie le dimanche 31 mai 2015.

Ça a été une semaine plutôt normale, bien que je ne puisse pas dire que les rc aient précisément déjà commencé à diminuer. Non, les rc n’ont pas été suffisamment grandes pour commencer un cycle de publication, et les choses ont été plutôt calmes, mais je serais plus heureux si l’on n’avait pas de bruit dans le RAID 5 et le device-mapper à cette étape.

Cela dit, ce n’est pas comme si la rc-6 était une grosse rc, et les choses paraissent normales. Il s’agit pour la moitié environ de pilotes (principalement des cibles SCSI, du réseau et du graphique, plus les modifications raid et dm mentionnées plus haut, avec d’autres corrections diverses.)

Le reste est assez également réparti entre les mises à jour d’architectures (alpha sort du lot), des mises à jour de systèmes de fichiers (xfs, cifs et overlayfs) et « divers » (réseau, l’outil de mise à jour de turbostat et la documentation).

La plupart des correctifs sont plutôt petits. Le journal abrégé est joint, il donne une bonne idée des choses que nous avons ici.

Linus

RC-7

La version rc-7 est sortie le dimanche 7 juin 2015.

Encore un dimanche, encore une rc.

Normalement, la rc-7 tend à être la dernière rc, et il n’y a pas grand-chose qui mérite notre attention ce coup-ci. Cependant, nous avons encore quelques régressions et, comme je l’ai mentionné la semaine dernière, mes vacances familiales annuelles arrivent. Nous aurons donc une rc-8 et une semaine supplémentaire avant que la rc-8 soit vraiment publiée.

Ça s’est agréablement calmé cependant et la rc-7 vaut certainement la peine d’être testée pour vérifier que tout fonctionne pour vous. Parce qu’on est sacrément proche de la rc finale et qu’elle devrait être assez sûre à tester. Les changements apparus la semaine dernière sont plutôt restreints. Le journal abrégé annexé devrait vous donner un aperçu de ce qui se passe. Beaucoup d’entre eux sont des correctifs d’une ligne, avec quelques patchs légèrement plus gros sur certaines architectures (des contraintes de performance sur x86, quelques mises à jour sur sparc) ainsi que des pilotes staging.

Linus

RC-8

La version rc-8 est sortie le dimanche 14 juin 2015.

Je suis en vacances, mais le temps ne s’arrête pas pour autant et c’est dimanche, donc le moment de sortir une rc que j’espère finale.

Il se trouve que je voulais faire traîner la publication d’un semaine de sorte à ne pas avoir la fenêtre d’intégration pendant mes vacances — nous avons encore quelques correctifs dans md. Comme Neil Brown l’a dit : « N’est-ce pas un bon cycle pour md 🙁 »

Les correctifs sont assez petits et j’espère que tout va bien maintenant. Mais une semaine supplémentaire pour tester ne va certainement pas faire de mal, donc une rc-8 est tout à fait convenable.

Il y a aussi diverses choses qui avancent, dont les correctifs MIPS, ainsi que de petites mises à jour ARM, s390 et x86.

Mais le gros est — comme d’habitude — les pilotes, et non, ça ne vient pas du camp md — ces correctifs sont très petits. Il s’agit principalement d’ethernet, de slave-dma, de spund, ainsi que des correctifs drm et d’autres choses.

Il y a aussi quelques correctifs de réseau et diverses petites choses.
Le journal abrégé est joint comme d’habitude, pour les personnes qui veulent un aperçu des détails.

Quoi qu’il en soit, c’est pas comme s’il y avait une tonne de correctifs. La plupart d’entre eux sont de petits correctifs, donc je ne pense pas que ce soit particulièrement inquiétant. C’est simplement que la rc-8 sort non seulement à cause de mon agenda, mais aussi à cause de petits détails qui surgissent sans cesse.

Faisons en sorte que la semaine prochaine soit vraiment calme. Le pouvons-nous ? Parce que je vais très activement éviter de lire mes courriels.

Linus

Version finale

La version finale est sortie le dimanche 21 juin 2015.

Bon, après une semaine très tranquille après la publication de la rc-8, la version 4.1 finale est maintenant publiée.

Je ne suis pas sûr que ce fût calme parce qu’il n’y avait aucun problème — touchons du bois — ou parce que les gens ont décidé d’épargner mes vacances, mais, quelle qu’en soit la raison, j’apprécie. Ça n’est pas comme si le cycle de sortie de la 4.1 avait été particulièrement pénible, espérons que la semaine supplémentaire de décantation ait permis d’en faire une meilleure version. Ça n’est pas une mauvaise chose, puisque la 4.1 est une version LTS.

Quoi qu’il en soit, depuis la rc-8, nous avons eu des changements vraiment petits, principalement quelques corrections finales de pilotes (le son HDA, le drm, le scsi target, la crypto) et quelques petits correctifs divers. Le journal abrégé ci-joint est probablement le plus petit jamais écrit. Je ne m’en plains pas.

Et cela signifie évidemment que la fenêtre de fusion de la 4.2 est maintenant ouverte.

Linus

Les nouveautés

Architecture

Gestion du matériel

Qualcomm MSM8916

Le Snapdragon 410 est la nouvelle famille de systèmes monopuce ARM 64 bits (ARM v.8) de chez Qualcomm. Le MSM8916 intègre un ARM Cortex A53 quad-cœurs, gravé en 28 nm, d’une fréquence de 1,4 GHz par cœur. Il adopte une architecture de type Harvard, en séparant les données et les instructions du cache de niveau 1. Il incorpore un GPU Adreno 306 et un DSP Hexagon QDSP6.

Il fait partie des nouveaux systèmes monopuces ARM64 à faire leur apparition dans Linux 4.1

Xilinx ZynqMP

Xilinx est un constructeur américain principalement connu pour ses périphériques et puces à logique programmable. Également connu comme étant l’inventeur du FPGA, il se focalise aujourd’hui sur la conception de systèmes monopuces programmables, combinant des cœurs ARM à des FPGA. Cela vous donne la possibilité de rerouter électriquement l’intégralité d’une carte de développement ou de développer n’importe quel périphérique à l’intérieur du FPGA intégré à la puce (un périphérique Ethernet PHY qui gère du PTP par exemple).

Parmi les deux puces les plus connues, nous pouvons citer le Zynq-7000 et le Zynq UltraScale MPSoC, aussi appelé ZynqMP. C’est à ce dernier que nous nous intéresserons.

Le ZynqMP est le premier système monopuce programmable 64 bits de chez Xilinx, il s’agit de la gamme puce haute performance qui dispose d’un processeur quatre cœurs ARM Cortex-A53, des coprocesseurs Cortex-R5 dits temps réels, un GPU ARM Mali 400MP, la gestion de la DDR4. Bref, vous l’aurez compris, c’est une véritable machine de guerre qui fait tout, sauf repasser votre linge :/

Linux 4.1 intègre la gestion de ce nouveau système monopuce. Restent maintenant à venir les cartes de développement et les kits d’évaluation.

L’ajout de la prise en charge de l’Intel Skylake continue

L’outil Turbostat est fourni avec le noyau Linux pour analyser statistiquement les performances des processeurs Intel récents. Il a été amélioré pour les spécificités des processeurs Skylake.

Intel Bay Trail & Cherry Trail

Ces processeurs obtiennent un changement de réglage par défaut, qui donnera de meilleures performances quand il faut de la puissance de calcul, tout en limitant la consommation supplémentaire. Celle-ci peut toujours être maîtrisée avec le profil « powersave ». Concrètement, le « setpoint » par défaut est passé de 97 à 60.

Meilleure gestion de l’énergie

Ce noyau a une meilleure gestion de l’énergie pour x86 et ARM avec une meilleure prise en compte de l’ACPI (ARM 64Bits inclus), gestion du futur matériel Intel, gestion des mises à jour pour les domaines de puissance : le noyau peut maintenant gérer plus finement les économies d’énergie, car il connaît la topologie de la dissipation des watts. Par exemple, si le CPU et le GPU sont sur le même die, c’est le même domaine de puissance.

L’architecture arm64 prend désormais en charge l’Advanced Configuration and Power Interface, aussi appelé ACPI. La prise en charge de l’ACPI pour l’ARM a été controversée par le passé : de nombreux développeurs préféreraient utiliser de façon universelle le mécanisme d’arborescence de périphériques pour la détection des périphériques sur cette architecture. L’ajout de l’APCI s’est fait tranquillement cependant et il semble très vraisemblable qu’il y ait des serveurs utilisant l’ACPI en vente dans un futur proche. Cela dit, il reste du travail : le commit de fusion précise que « nous n’allons prendre en charge aucun périphérique pour le moment, donc son champ d’application est assez limité ». Voir Documentation/arm64/arm-acpi.txt pour de plus amples informations à propos de l’ACPI sur ARM.

Voir l’article de LWN.net : ACPI for ARM?, [correctif de la demande d’inclusion], Documentation/arm64/arm-acpi.txt.

La prise en charge de Full DynTicks pour les invités KVM permet de ne plus réveiller le CPU à intervalle régulier et donc permet une meilleure économie d’énergie quand on a des machines virtuelles en fonctionnement.

AMD Bulldozer

Amélioration de l’entropie pour AMD Bulldozer, ce qui permettra d’avoir des nombres aléatoires de meilleure qualité pour les opérations de chiffrement.

Changement risqué pour x86

Beaucoup de changements ont été apportés aux appels système, interruptions, etc. pour x86. Un gros effort a été mené pour clarifier et remplacer du code spaghetti en assembleur, vieux d’une décennie, par du C, ainsi que ses dépendances en C. Le code est maintenant plus simple, plus clair, plus compact et donc maintenable.
En raison de la nature des changements sur ces parties critiques, des risques de problèmes peuvent apparaître.

Correction à chaud sur architecture S/390

Gestion préliminaire pour l’utilisation de correctifs à chaud du noyau pour l’architecture S/390. Suppression de la prise en charge du mode 31 bits autrefois nécessaire pour dépasser l’agaçante limite mémoire des 16 Mio.

Équilibrage de charge

La surveillance de la charge par l’ordonnanceur a été retravaillée pour que la charge par processus soit indépendante de la vitesse du processeur. Cela devrait permettre de meilleures décisions pour l’équilibrage de charge selon les changements de fréquence, et améliore la prise en charge des systèmes à processeurs asymétriques comme le récent big.LITTLE où plusieurs types de cœurs se retrouvent dans le même processeur. La technologie big.LITTLE permet de mixer des cœurs à très faible consommation avec des cœurs puissants s’activant à la demande en cas de forte sollicitation. Cela permet d’économiser de l’énergie.

MIPS

L’architecture MIPS prend dorénavant en charge l’adressage XPA. Cela permet aux systèmes 32 bits d’accéder à toutes les adresses de la mémoire physique (40 bits).

Développeurs

Utilisation de GCC 6

Le noyau Linux utilise actuellement un fichier d’entête compiler-gccX.h pour gérer efficacement les spécificités propres à chaque version majeure de GCC.

La possibilité de tout fusionner dans un seul compiler-gcc.h est discutée, pour ne pas créer un fichier par version de gcc dû au changement dans la politique de publication de GCC (une version par an). En effet, précédemment, chaque version majeure était due à une évolution marquante et pouvait fortement affecter le noyau.

La nouvelle politique pour GCC est plus pragmatique, avec des versions plus incrémentales et régulières, permettant de profiter des avancées du projets, sans forcément remettre en question de manière profonde le logiciel, et la manière de l’utiliser (raison première d’un fichier par version).

Il reste encore des changements à faire pour rendre le code compatible avec le compilateur LLVM/Clang et la norme C11.

AIO

Les méthodes aio_read() et aio_write() ont été supprimées de la structure file_operations. Les (relativement) nouvelles méthodes read_iter() et write_iter() devraient être utilisées à la place.

Débogage des systèmes de fichiers

Il y a une nouvelle cible « log writes » pour la carte des périphériques (device mapper) qui enregistre toutes les opérations d’écriture sur un périphérique bloc. Il est destiné au débogage des systèmes de fichiers. Voir Documentation/device-mapper/log-writes.txt pour les détails.

User mode Linux

Linux en mode utilisateur — User mode Linux — a vu la prise en compte du multitâche et de la gestion mémoire highmem supprimés. Aucune de ces fonctionnalités ne marchait correctement — voire ne fonctionnait tout court — et les deux étaient des fardeaux à maintenir.

GPIO

Le nouveau système d’« accaparement » du système d’entrées‐sorties à usage général GPIO peut être utilisé pour câbler facilement — et de façon permanente — l’état d’une ligne GPIO spécifique sans nécessiter de pilote. Voir la documentation du correctif pour les détails.

Outil perf

Comme d’habitude, l’outil de mesure de performance a vu une longue liste d’ajouts et d’améliorations ; voir le correctif de la demande d’inclusion pour les détails. Certaines des caractéristiques les plus importantes incluent la possibilité d’attacher des programmes BPF aux sondes noyau, la prise en compte de la fonctionnalité trace des processeurs Intel à venir (« un traceur matériel sous stéroïdes »), la prise en compte de la fonction à venir de surveillance de la qualité de service du cache d’Intel, etc. (Documentation Intel : Processor Tracing).

Suppression du « domaine d’exécution » noyau

Le « domaine d’exécution » a été retiré du noyau. L’idée qui sous‐tendait cette fonctionnalité était de permettre l’importation de caractéristiques étrangères à Linux — des interfaces logicielles de noyaux d’autres systèmes UNIX —, mais elle n’a jamais été très utilisée, et n’a même jamais très bien fonctionné.

Voir l’article de LWN.net : Remove execution domain support.

Minimisation de la taille du noyau

L’usage d’utilisateurs, de groupes et de « capabilities » est optionnel. Cette option de configuration à la compilation est destinée aux tout petits systèmes embarqués qui n’en faisaient déjà pas usage, et qui peuvent donc être allégés de 25 ko environ.

Voir l’article de LWN.net :Linux as a single-user system, [correctif].

Pilotes graphiques libres

Direct Rendering Manager

La nouveauté principale pour la partie commune de tous les pilotes graphiques libres est l’ajout d’un allocateur de mémoire graphique « virtuelle » (c’est-à-dire, utilisant la mémoire centrale de l’ordinateur au lieu d’utiliser de la mémoire graphique dédiée). Cet allocateur réutilise l’interface GEM qui est l’interface d’allocation utilisée par presque tous les pilotes graphiques libres. Cette approche a pour unique intérêt d’aider les pilotes de rasterisation logicielle tels que le pilote Mesa/Gallium LLVMpipe.

Grâce à la couche Virtual GEM, il devient possible à LLVMpipe de transférer avec DRI2 le résultat du rendu au serveur graphique X sans effectuer de copies. Cette couche devrait cependant être inutile dans le cas de Wayland et DRI3 qui préfèrent utiliser DMA-buf pour des raisons de sécurité et de simplicité. DMA-buf étant plus générique que GEM, il a toujours été possible de partager de la mémoire centrale avec plusieurs pilotes. Cependant, DRI3 n’est pas encore considéré comme stable actuellement, ce qui est probablement la raison pour laquelle Zach Reizner a décidé de ressusciter le projet d’Adam Jackson, empaqueteur de la pile graphique pour Red Hat, datant de 2012.

Le correctif original permettait également de gérer le partage de tampons graphiques via PRIME (DMAbuf), cependant, plusieurs ingénieurs ont trouvé que Google avait décidé de se servir de cette interface d’une autre façon qui n’est pas sûre vis-à-vis de la cohérence des caches, surtout sur les processeurs ARM. Le résultat de la discussion est que VGEM doit respecter son objectif initial qui est celui proposé par Adam en 2012, LLVMpipe sur DRI2. La gestion de PRIME a donc été supprimée.

Pour que cette fonctionnalité devienne utile, il reste cependant encore à modifier le pilote LLVMpipe pour enfin éviter les copies inutiles des images produites par LLVMpipe à destination du serveur graphique X qui sont particulièrement lourdes avec les résolutions actuelles de nos moniteurs.

Le reste des modifications de la partie commune des pilotes graphiques libres n’est pas aussi intéressant. Pour plus d’informations, vous pouvez consulter les demandes d’intégration DMA-buf, panels et DRM.

AMD/ATI

Pilote de rendu (pilote radeon)

Dans cette nouvelle version, le pilote radeon ajoute une gestion expérimentale du Transport Multiflux (MST) sur DisplayPort 1.2. Cela permet de faire transiter des flux (images, son et data) pour différents écrans via une seule sortie (et câble) DisplayPort. Cette gestion a été ajoutée par Dave Airlie (Red Hat) pour les processeurs CAYMAN et (en théorie), les processeurs plus récents. Pour activer cette gestion, vous devrez utiliser l’option noyau radeon.radeon_mst=1.

Une autre fonctionnalité intéressante a été ajoutée pour ceux d’entre nous qui connectent leur carte AMD à une télévision. Les télévisions sont en effet différentes des moniteurs pour ordinateurs, car elles ne reçoivent en théorie que des couleurs RVB dans la plage 16-235 au lieu de 0-255. Cela veut dire que les couleurs 0-16 seront toutes considérées comme absence d’une couleur et 235-255 seront considérées comme sa présence complète. Cette gestion a été demandée durant l’été 2014 par plusieurs utilisateurs. Si vous voulez essayer, il vous faudra invoquer xrandr de cette façon xrandr --output <sortie> --set output_csc tvrgb,

Le pilote radeon exporte désormais beaucoup plus d’informations concernant l’état du GPU. Ces informations sont destinées à être exposées par l’afficheur tête haute de Gallium ou les extensions OpenGL permettant d’exposer les compteurs de performance. Ces informations supplémentaires concernent les horloges mémoire et GPU, ainsi que l’état des différents moteurs d’exécution du GPU (3D/2D, décodage vidéo, DMA).

Pour plus d’informations sur les nouveautés du pilote radeon, vous pouvez consulter la demande d’intégration radeon.

Pilote HSA (pilote amdkfd)

Le pilote amdkfd, qui permet de faire communiquer plus rapidement le GPU et le CPU, permet désormais de gérer plusieurs pilotes graphiques en même temps. C’est nécessaire afin de gérer le futur pilote graphique qui sera prochainement intégré au noyau et qui sera l’unique pilote Linux capable de gérer les nouveaux APU d’AMD (Carrizo).

Pour plus d’informations sur les nouveautés du pilote amdkfd, vous pouvez consulter la demande d’intégration amdkfd.

Intel (pilote i915)

Peu de nouveautés visibles pour les utilisateurs du pilote i915. Les nouveautés principales concernent l’affichage. La première est la gestion dynamique de la fréquence de rafraîchissement (DRRS) pour les plateformes qui le prennent en charge. La seconde est la gestion matérielle de la lecture des tampons graphiques utilisant le Y-tiling avec une rotation de 90° et 270°, en plus des 0° et 180° déjà disponibles sur les plateformes avant Skylake.

Beaucoup de travail de réagencement du code est également en cours. Le travail principal continue sur la gestion atomique du mode graphique avec l’ajout de l’infrastructure qui va faciliter la migration de la gestion actuelle à la gestion atomique.

Du côté de PPGTT (mémoire virtuelle allouée par client graphique), beaucoup d’efforts sont faits afin de gérer des espaces d’adressage supérieurs à 32 bits (4 Gio). En effet, activer un espace d’adressage de 48 bits utiliserait beaucoup de mémoire rien que pour allouer la table de pagination. Du coup, Ben Widawsky travaille à faire l’allocation de cette table de façon dynamique. Espérons que Linux 4.2 apportera la gestion des grands espaces d’adressages qui permettront au GPU d’accéder à toute la mémoire d’un processus 64 bits sans avoir à copier inutilement des zones mémoires ou faire des opérations de réagencement des MMU). Si vous êtes intéressés par PPGTT, vous pouvez consulter les articles de Ben Widawsky sur le sujet qui expliquent en détail l’objectif derrière PPGTT (1, 2, 3 et 4).

Pour finir, les développeurs i915 essayent de fournir l’accélération graphique aux machines virtuelles Xen sans avoir à passer par une virtualisation complète. Les machines virtuelles auront un pilote (appelé XenGT) qui communiquera avec un autre pilote en DOM0 via des hypercalls afin de transmettre les différentes commandes. Le résultat devrait être très performant et proche de ce qu’essaye de faire Ben Skeggs pour le pilote Nouveau.

Si vous voulez en savoir plus, vous pouvez consulter l’habituel compte‐rendu détaillé des modifications de Daniel Vetter (mainteneur i915).

NVIDIA (pilote nouveau)

Du côté du pilote libre pour les processeurs graphiques NVIDIA, l’ingénieur d’NVIDIA Alexandre Courbot a ajouté la gestion de l’IOMMU pour les GPU GK20A que l’on peut trouver dans les systèmes-sur-puce Tegra K1.

Ben Skeggs a également écrit les microcodes nécessaires à la gestion matérielle des contextes graphiques pour la première version des processeurs Maxwell, le chipset GM107. Ces microcodes sont essentiels afin de prendre en charge l’accélération 2D, 3D et décodage vidéo. Les chipsets suivants ont également reçu des modifications afin de pouvoir charger ces microcodes, mais aucune version libre ne peut être écrite, car ces derniers nécessitent un microcode signé par NVIDIA. Ces derniers devraient redistribuer très prochainement les différents microcodes dans le projet linux-firmware.

Avec un peu de chance, NVIDIA redistribuera également les microcodes nécessaires à l’encodage et décodage vidéo ainsi que la documentation des interfaces, ce qui devrait réduire le temps de développement pour ajouter la gestion d’un nouveau chipset ! On se consolera comme on peut pour la perte de liberté et un travail d’audit du code sera encore nécessaire pour garantir qu’il n’y a pas de portes dérobées.

Pilotes graphiques pour systèmes monopuces

Qualcomm (pilote msm)

Le pilote msm pour les GPU Qualcomm gagne la gestion des liens DSI et double DSI ainsi que la gestion du vol de mémoire ce qui permet de faire une transition sans à-coups depuis l’animation de chargement — splash screen. La gestion des nouveaux GPU snapdragon 410 fait également son apparition.

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

NVIDIA (pilote tegra)

La nouveauté principale du pilote NVIDIA tegra à destination des systemes monopuces Tegra (2, 3 et 4) est la possibilité d’utiliser les compteurs matériels de suivi du rafraîchissement vertical grâce aux points de synchronisation proposés par le pilote et le bloc host1x. Cela devra permettre d’implémenter une gestion plus efficace du page flipping.

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

Renesas (pilote rcar-du)

Le pilote Renesas a reçu beaucoup de modifications de la part de Laurent Pinchart afin de gérer la gestion atomique du mode graphique!

Pour plus d’informations, vous pouvez consulter les demandes d’intégration rcar-du.

Autres

Les pilotes Samsung (exynos) et Texas Instruments (omap) ont tous les deux profité d’une révision de l’architecture du code et de corrections des bogues en vue de gérer la gestion atomique du mode graphique, mais le code n’est pas encore prêt.

Pour plus d’informations, vous pouvez consulter les demandes d’integration exynos et omap.

Sécurité

Lorsque le noyau essaie d’accéder à des adresses qui ne sont pas directement accessibles, la MMU génère une erreur de pagination — page fault exception — et exécute le gestionnaire d’erreur de pagination. Lors de l’accès à des zones mémoires contrôlées par un processus en espace utilisateur, ce gestionnaire vérifie que le code effectuant cet accès fait bien partie d’un tableau listant les parties dans le noyau qui ont effectivement le droit d’accéder à ce type de zone mémoire. Ce tableau contient donc principalement toutes les invocations des fonctions de type copy_*_user().

Ce mécanisme permet au noyau d’accéder de façon sûre aux données en espace utilisateur à l’aide d’une interface restreinte (les fonctions copy_*_user()) sans avoir à vérifier explicitement l’accès à tous les pointeurs avant de les déréférencer.

Chaque module contient son propre tableau listant ces exceptions. À partir de cette version du noyau, le chargeur de module vérifiera activement que toutes les entrées de ce tableau pointent bien vers du code inclus dans le module. Toute entrée pointant à l’extérieur générera une erreur [correctif], Documentation/x86/exception-tables.txt : Kernel level exception handling in Linux.

Audit

Une situation de compétition potentielle dans le code d’audit pouvait tronquer le rapport d’audit après le champ comm et donc provoquer la perte d’informations. Pour de plus amples informations, voir le correctif.

SELinux

La table de hachage contenant la politique SELinux dans le noyau a été convertie en « tableau flexible » (flex_array). Il utilise un nouvel algorithme de hachage produisant une meilleure répartition. Le nombre d’entrées par défaut a également été augmenté. Ces modifications devraient réduire l’impact de la recherche d’une règle dans la politique SELinux dans le noyau et donc réduire globalement l’impact de SELinux. Pour de plus amples informations, voir les correctifs 1, 2 et 3.

Certaines commandes netlink n’étaient pas mentionnées dans la table utilisée par SELinux à cause d’un oubli lors de leur introduction dans le noyau. Ces correctifs corrigent le tir et l’un d’entre eux ajoute une vérification à la compilation pour que la situation ne se reproduise plus. Pour de plus amples informations, voir les correctifs 1, 2, 3, 4, 5, 6, 7, 8 et 9.

SMACK

Les sockets ouvertes par des fils d’exécution dans le noyau sont correctement nommées. Pour de plus amples informations, voir le correctif.

L’appel système keyctl avec l’action KEYCTL_GET_SECURITY retourne maintenant le contexte de sécurité [correctif].

Le mainteneur du module de sécurité SMACK a ajouté à contre cœur un mode « mise en place » qui peut être utilisé pour déboguer la configuration et la politique SMACK. « C’est finalement disponible, c’est dangereux, mais il semble que beaucoup de développeurs ne sachent pas faire autrement, donc j’ai mis ça en place. J’ai essayé de rendre ce mode aussi sûr que possible, mais c’est de toute façon impossible vu que cela reste une tronçonneuse ». Pour de plus amples informations, voir le correctif.

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

Nouveau matériel pris en charge

  • Générateur de nombres aléatoires : Altus Metrum ChaosKey [correctif].

Réseau

eBPF

eBPF est un système universel dans le noyau de machine virtuelle, désormais utilisé pour la classification et le routage des paquets. Cela permet d’avoir plus de débit et moins de latence, particulièrement sur les routeurs.

Plus d’informations dans les correctifs (1, 2) et l’article de Phoronix.

Routage des paquets en utilisant le mécanisme « multiprotocol label switching » (MPLS)

Le mécanisme de routage MPLS (MultiProtocol Label Switching) est maintenant géré par Linux. Correctifs : 1, 2, 3.

Implémentation de la RFC 7217 (IPv6)

La RFC 7217 vient d’être implémentée dans Linux ce qui devrait permettre de garder une adresse IPv6 anonyme (l’adresse MAC n’est pas divulguée dans l’adresse IP) tout en gardant la propriété importante de stabilité de l’adresse lors de la mobilité. Pour plus d’informations, veuillez consulter la RFC 7217.

Systèmes de fichiers

Pilote pour les périphériques dits à mémoire persistante

Le pilote basique de mémoire persistante a été incorporé, améliorant la prise en compte dans le noyau des périphériques à mémoire non-volatile de grande taille.
Article LWN.net : Persistent memory support progress.

F2FS

F2FS dispose maintenant du cache en mémoire extent_cache. La fonctionnalité fs_shutdown permet de faire des tests de coupure d’alimentation pour fiabiliser le comportement en cas de coupure à chaud. Dorénavant, le chemin des liens symboliques est stocké inline, c’est-à-dire directement dans le nœud d’index (inode). F2FS permet déjà de stocker des petits fichiers directement dans ces derniers (voir Enable f2fs support inline data). Les liens symboliques étant un cas spécifique de petit fichier (fichier contenant un lien), ce traitement ne s’appliquait jusqu’alors pas à eux. On notera par ailleurs l’activation par défaut du stockage inline à partir de cette version.
Diverses améliorations côté gestion de l’énergie, point important vu l’utilisation de F2FS dans nos téléphones.

Pour plus d’informations, vous pouvez consulter l’article de Phoronix.

BLK-MQ

La gestion des multi-queues a été améliorée, surtout avec le multi-CPU.

EXT4

ext4 est maintenant capable de chiffrer directement les fichiers et dossiers du système de fichiers. Cette nouvelle fonctionnalité permet de se passer de dm-crypt ou eCryptfs, suivant les cas.

XFS

Lors d’un renommage, la source n’est plus supprimée mais remplacée par des blancs (RENAME_WHITEOUT). Cela devrait permettre son utilisation avec le système d’union de système de fichier overlayfs.

Nouveau aussi dans XFS, la prise en charge de l’option FALLOC_FL_INSERT_RANGE par fallocate(), permettant aux applications d’insérer des trous dans un fichier.

Les superblocs par CPU ont été remplacés par des compteurs génériques.

Nouveau verrou inode mmap sur les erreur de page.

Une réécriture de la soumission des I/O directes pour mieux faire attention aux corruptions de données lors des écritures

Amélioration du log des messages

Et les traditionnelles corrections de bogues et nettoyage.

RAID 5/6 pour le Raid Logiciel

Les blocs de 4K sont maintenant gérés. Le cache de bande est maintenant dynamique. Le raid6 peut maintenant faire des cycles lecture/modification/écriture avec de meilleures performances sur des grappes de 6 disques ou plus.

RAID 1

Le sous-système MD (RAID) peut dorénavant gérer les matrices RAID 1 de façon distribuée sur un cluster. Le code correspondant est actuellement marqué comme expérimental, mais il est de toute évidence proche d’un état de production.

Device mapper

Le gestionnaire de périphériques peut maintenant fonctionner comme un périphérique bloc à files multiples, augmentant les performances. Cette fonctionnalité est actuellement désactivée par défaut, mais peut être activée avec la variable de configuration CONFIG_DM_MQ_DEFAULT.

BTRFS

Les systèmes de fichiers de plus de 20 To n’étaient pas gérés correctement à cause d’un problème de gestion de l’espace libre, cela est maintenant corrigé. Des corrections pour la suppression de fichiers de plus de 3 To ont également été apportées.
Enfin, un bogue empêchant le passage d’un niveau de raid à un autre a de même été corrigé.

Tracefs

Steven Rostedt vient d’intégrer un nouveau système de fichiers : TraceFS. Certains administrateurs système ont remonté qu’il y avait un souci à être obligé d’utiliser Debugfs pour pouvoir activer les fonctionnalités de « tracing » du noyau. Pour des raisons de sécurité, certains interdisent simplement l’utilisation de Debugfs.

Tracefs apporte la possibilité d’utiliser les capacités de « tracing » sans l’utilisation de Debugfs et ceci sans casser la compatibilité avec les outils existants.

ZRAM

Le périphérique bloc « zram » peut maintenant effectuer la compression de blocs de données. Voir l’article LWN sur le sujet.

Meilleure gestion des erreurs pour les disques

Le standard ATA de commandes de gestion des disques a une nouvelle spécification ACS-4. Elle permet grâce à la commande NCQ Autosense d’obtenir le même niveau d’information sur les erreurs qu’en SCSI. Le noyau 4.1 implémente cette commande, qui n’est pour l’instant reconnue que par une poignée de nouveaux disques durs.

Virtualisation

KVM

Comme d’habitude, la demande d’intégration se fait en deux fois, une pour les PowerPC et une pour les autres architectures.

  • s390 (mainframe IBM) : prise en charge des instructions SIMD, le code de gestion des interruptions a été retravaillé afin de pouvoir récupérer la liste des interruptions et de pouvoir en définir avec des ioctl, ceci afin de permettre la migration d’invité d’un hôte à l’autre. Les clefs de stockage qui permettent de protéger l’accès aux données peuvent être maintenant définies et récupérés dans un invité via de nouvelles ioctl.
  • MIPS : prise en charge des instructions FPU et SIMD.
  • x86 : principalement des corrections de bugs, il y a eu un débat sur le fait que les développeurs KVM se sont permis d’aller mettre du code dans l’ordonnanceur, zone du noyau qui appartient à un autre mainteneur, qui plus est, ce dernier n’était pas du tout content du code. Finalement, le code a été écrit d’une autre façon pour qu’il n’y ait pas besoin de modifier autre chose que KVM.
  • ARM : des corrections pour la migration à chaud, prise en charge des irqfd (ce qui permet d’injecter des interruptions dans l’invité via un descripteur de fichier eventfd) et ioeventfd (qui permet de faire l’asynchrone pour certaines opérations d’entrée/sortie pour lesquelles une opération synchrone dans un invité est très coûteuse comme une demande d’opération DMA) ainsi que le « page aging ».
  • PowerPC : amélioration du débogage, légère amélioration des performances et nettoyage du code pour les processeurs de type Book3S.

Xen

  • Ajout d’un pilote APIC pour gérer plus de 255 processeurs virtuels dans les invités.
  • Amélioration des performances pour les opérations de migration, sauvegarde et restauration de l’état.
  • Prise en charge de la sauvegarde/restauration pour le pilote scsiback/front
  • Mise en place de l’infrastructure pour avoir le xenbus sur plusieurs pages.

VirtIO

Le sous-système virtio a un nouveau pilote virtio-input. Son travail est de collecter et faire suivre les événements des périphériques d’entrée vers un périphérique virtuel.

Le bilan en chiffres

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

En nombre de modifications, on se situe à 11 664, soit environ 1 500 modifications de plus que la version précédente du noyau, mais reste en dessous de la moyenne de ces derniers noyaux. Cette nouvelle version a ajouté 486 000 lignes de code alors qu’elle en a supprimé 286 000, ce qui a conduit à une augmentation nette de 286 000 lignes. Le nombre de contributeurs s’approche quant à lui au moins à 1 492 auteurs. Il est possible que lors de la sortie, plus de 1 500 auteurs aient contribué ce qui est un nouveau record !

Pour changer, le développeur ayant fait le plus de modifications travaille au nettoyage des pilotes Comedi. Cependant, ce n’est pas l’habituel Hartley Sweeten, mais Ian Abbott qui remporte la palme cette fois. Du côté des développeurs ayant le plus modifié de lignes, Jie Yang se retrouve sur la première marche par son travail de réorganisation du pilote audio Intel.

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

Appel à volontaires

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

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

Un peu de vocabulaire :

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

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

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

Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les commits intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. La page wiki Rédiger des dépêches noyau signale quelques possibilités pour aider à la rédaction et s’y impliquer (ce que tout inscrit peut faire, ne serait‐ce que traduire^Wsynthétiser les annonces de RC). Essayons d’augmenter la couverture sur les modifications du noyau !

Lire les commentaires

(Source: LinuxFr.org : les dépêches)

Étiquettes: