URL: https://linuxfr.org/news/sortie-du-noyau-linux-5-1
Title: Sortie du noyau Linux 5.1
Authors: Collectif
 bubar🦥, Arkem, ZeroHeure, Florent Zara, esdeem, palm123, gusterhack, 4fages, Davy Defaud, patrick_g et Fabrice Mousset
Date: 2019年03月18日T20:41:05+01:00
License: CC By-SA
Tags: noyau_linux, kernel, linus_torvalds, tensorflow, seccomp et lwn
Score: 85
La sortie de la version stable 5.1 du noyau Linux a été annoncée le 5 mai 2019 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site _kernel.org_ mis à jour le 6 mai. Le détail de quelques‐unes des évolutions et nouveautés se trouve dans la seconde partie de la dépêche.
----
[Le noyau, son site](https://kernel.org)
[La liste des nouveautés du noyau 5.1](https://kernelnewbies.org/Linux_5.1)
[Les noyaux précédents](http://linuxfr.org/wiki/depeches_noyau)
[Annonce de la sortie du noyau 5.1](https://lwn.net/Articles/787556/)
[Le noyau, sa documentation](https://www.kernel.org/doc/html/v5.1)
----
# Annonces des versions candidates par Linus Torvalds
## RC-1
[Annonce](https://lkml.org/lkml/2019/3/17/207) :
 > C’est dimanche, deux semaines se sont écoulées et tout paraît normal. Vous connaissez tous la procédure maintenant : la fenêtre de fusion est terminée et les choses sont supposées se calmer.> > La fenêtre de fusion m’a semblé franchement normale et, au vu des statistiques, rien de vraiment bizarre ne se profile. C’est une sortie de taille habituelle (c’est‐à‐dire grosse, évidemment, mais pas plus que d’habitude) et la majorité (un peu plus de 60 %) sont des pilotes, toutes sortes de pilotes. Celui qui sort du lot est le pilote de circuit d’accélération d’IA d’Habanalabs [N. D. T. : Habana Labs], mais je soupçonne que nous verrons ce genre de chose de plus en plus souvent. Il y a aussi les suspects habituels : processeurs graphiques, réseau, périphériques blocs, etc.> >Une évolution plutôt récente est la manière dont les mises à jour de `tools/testing/` ressortent ces derniers temps. Ce n’est pas une nouveauté de la fenêtre de fusion 5.1, ça dure depuis assez longtemps, mais il convient juste de mentionner que nous avons plus de nouveaux changements dans les auto‐tests que de mises à jour d’architectures, par exemple. Le sous‐répertoire `documentation` aussi est assez remarquable.> >Mais dans l’ensemble, il y en a vraiment un peu partout, y compris des mises à jour au cœur de [VFS](https://fr.m.wikipedia.org/wiki/Virtual_File_System), en plus des habituelles mises à jour.> >Comme toujours, le journal abrégé est beaucoup trop long pour être posté, avec plus de 11 000 _commits_ (12 000, avec les fusions). Voici donc mon « journal des fusions » habituel, qui liste les sous‐mainteneurs et un résumé des `git pulls` que j’en ai tiré...>>Allez‐y, testez.>>Linus
##RC-2
[Annonce](https://lkml.org/lkml/2019/3/24/487) :
 > Bien, la fin de la fenêtre de fusion est une semaine derrière nous, et voici la RC-2. Les choses semblent tout à fait normales, mais honnêtement, la RC-2 est généralement trop précoce pour se faire une idée. Les gens n’ont pas forcément eu le temps de constater des problèmes à ce stade, ce qui est juste un autre moyen de dire « s’il vous plaît, testez plus ».>> Rien de particulier n’apparaît. D’accord, nous avons eu des correctifs dans le nouveau code d’`io_ring` pour des problèmes qui ont été discutés au moment de le fusionner. Autrement, il faut noter que le plus gros des correctifs est d’ordre utilitaire, rien dans le cœur du noyau. En fait, à peu près deux tiers des correctifs ne concernent que le répertoire `tools/`, principalement à cause de récentes mises à jour d’outils de perfs. Les gens concernés promettent qu’ils ont fini.>> Si l’on met de côté les utilitaires, le reste est éparpillé un peu partout, et c’est plutôt petit. C’est en gros réparti de manière égale entre les mises à jour d’architectures, de pilotes et de systèmes de fichiers, mais c’est en partie dû à l’`io_ring` précédemment cité (qui fait ressortir sensiblement la partie système de fichiers). Il y a de légers bruits ailleurs aussi : la majorité du code dans `arch/` est une mise à jour tardive d’ARC, mais rien de tout cela n’est vraiment gros ou inquiétant.>> Journal abrégé ajouté pour un avant‐goût des détails (et vous remarquerez ici la dominance des perfs).>> À vos tests.>>Linus
##RC-3
[Annonce](https://lkml.org/lkml/2019/3/31/256) :
 >Rien de particulièrement inhabituel cette fois.>>La RC-3 est plus grosse que d’habitude, chose que je n’aime évidemment jamais voir, mais en même temps, c’est suffisamment tôt dans la série de RC pour ne pas me faire vraiment peur. Pour l’instant.>>Et même si c’est plus gros, rien de particulier n’apparaît. La seule et unique grosse rustine ici (et de loin, car ça représente près du tiers de l’ensemble de la publication) est simplement la suppression du pilote expérimental mt7621-eth, car le pilote Ethernet Mediatek standard gère maintenant ce matériel. En fait, en raison de la suppression de ce pilote, le correctif complet de la RC-3 retire plus de lignes qu’il n’en ajoute, ce qui fait toujours plaisir à voir (pour parler honnêtement, si l’on regarde l’ensemble de la version plutôt que seulement celle de cette semaine, ce n’est pas vrai du tout).>>Mais non, la suppression de ce pilote n’est pas la raison qui me fait dire que la RC-3 est plus grosse que d’habitude – ce n’est qu’un seul _commit_. Nous avons simplement plus de _commits_ que d’habitude à ce stade. J’espère que ce n’est qu’un cas unique – la mesure globale des « tailles de RC » tend à être sujette au bruit, et est dépendante du fait qu’une semaine particulière voit tous les principaux sous‐systèmes fusionner leurs correctifs ou pas. Cette fois, ça a été clairement beaucoup le cas.>>Si vous mettez de côté ce gros morceau de la RC-3 représentant la suppression de cet unique pilote, les changements sont assez largement éparpillés. À peu près un tiers sont des pilotes, un autre bon tiers sont des modifications d’outils et de documentation, et le dernier tiers est simplement du « divers » un peu partout (le réseau en est un gros morceau, mais il y a des mises à jour d’architectures, de cœur du noyau, de KVM, et j’en passe...).>>Le journal abrégé attaché donne un avant‐goût des détails, et je ne pense pas qu’il y ait quoi que ce soit d’important dedans. Juste beaucoup de petits détails.>>Espérons que les RC vont commencer à diminuer à partir de maintenant, mais je ne pense pas que nous verrons quoi que ce soit de mauvais se présenter.>>En avant, testez.>>Linus
##RC-4
[Annonce](https://lkml.org/lkml/2019/4/7/179) :
 >Une autre semaine, une autre RC. Plus petite que la RC-3, je suis content de l’annoncer. Rien de particulièrement gros ici, juste de petites choses un peu partout.>>Et il y en a vraiment de partout. Les pilotes représentent à peu près le tiers (réseau, périphériques de type bloc, processeurs graphiques, SCSI) et le reste est un mélange de mises à jour d’architectures, de systèmes de fichiers, de documentation, de cœur du réseau, d’utilitaires... Il n’y a donc pas de thème unique ici, juste de petits correctifs éparpillés de partout.>>Le journal abrégé est joint pour les personnes qui voudraient avoir un aperçu des détails.>>Linus
##RC-5
[Annonce](https://lkml.org/lkml/2019/4/14/265) :
 >Nous y revoilà... C’est dimanche après‐midi, ça signifier donc une autre RC du noyau.>>Nous avons des changements de partout, mais beaucoup ne sortent pas de l’ordinaire, et la plupart sont très petits. Si l’on regarde les stats, les mises à jour des pilotes audio ont tendance à ressortir, prenant presque le tiers du correctif (et presque le tiers des _commits_ aussi, ce n’est donc pas le résultat d’une unique grosse rustine). Mais rien de tout ça ne semble tellement effrayant.>>En dehors des correctifs audio, un autre tiers sont les autres pilotes (processeurs graphiques, RDMA, NVMe, MMC, couche bloc...) et la dernière chose est « divers ». Cela inclut des mises à jour d’architectures et d’utilitaires, et des corrections de code variées (réseau, systèmes de fichiers, modules de sécurité, et `/mm` dans le cœur du noyau).>>Rien ici ne me met mal à l’aise à propos de ce cycle de parution. Touchons du bois.>>Le journal abrégé est joint avec un résumé des détails, comme toujours.>>Linus
##RC-6
[Annonce](https://lkml.org/lkml/2019/4/21/78) :
 > C’est le dimanche de Pâques ici, mais je ne laisse pas des choses bénignes, comme l’arrivée d’un jour saint pour une religion majeure, interrompre le flot de mon travail sur le développement du noyau. Pour la promenade occasionnelle en plongée, d’accord, mais se réunir pour un repas traditionnel, non. Il faut avoir des priorités. Il y a juste tout ce [Memma](https://fr.wikipedia.org/wiki/M%C3%A4mmi) à manger, même si votre femme a dû le préparer depuis zéro parce que personne ne consomme ce genre de chose aux États‐Unis.>>En tout cas, la RC-6 est plus grosse que je l’aurais aimé, ce qui m’a fait revenir à l’historique, et curieusement ce n’est pas si inhabituel que ça. Nous avons récemment eu des pics similaires avec les 4.18 et 5.0.>>Donc, je ne vais pas m’inquiéter pour ça. Je pense que c’est juste un hasard de chronologie dans les demandes d’intégration, et sans doute au moins partiellement dû à la demande d’intégration réseau (avec un peu plus du tiers des changements relatifs au réseau, aussi bien dans les pilotes que dans la partie commune).>>À part le réseau, nous avons les habituelles mises à jour d’autres pilotes (`nvdimm`, I2O et processeurs graphiques sortent du lot), d’architectures (principalement x86 – les correctifs KVM ressortent) et les utilitaires (auto‐tests et perfs)>>Enfin, nous avons une collection d’autres changements variés : `mm` dans le cœur, des correctifs de systèmes de fichiers, l’ordonnanceur et du traçage.>> Mais malgré que la RC-6 soit un peu plus grosse que je l’aurais espéré, l’ensemble est plutôt petit, et je ne pense pas qu’il y ait quoi que ce soit d’inquiétant ici. En fait, une grande partie sont des choses vraiment triviales, dont certaines juste des corrections d’orthographe ou dans ce genre.>> Jetez un œil au journal abrégé ci‐joint pour les détails, si ça vous intéresse, mais surtout, faites le tourner et mettez‐le à l’épreuve...>>Linus
##RC-7
[Annonce](https://lkml.org/lkml/2019/4/28/270) :
 >Si la RC-6 était plus grosse que je l’aurais souhaité, ça semble bien dû à la chronologie des demandes d’intégration, car la RC-7 est très petite.>> Un peu moins de la moitié des correctifs sont des modifications réseau de différentes sortes : un mélange du cœur du réseau, de pilotes et d’auto‐tests pour Netfilter.>>Le reste est surtout constitué des habituels correctifs d’architectures, de systèmes de fichiers et autres pilotes (surtout RDMA et processeurs graphiques), et des changements divers (documentation, traçage, et des [_fixlets_](https://en.wikipedia.org/wiki/IBM_BigFix#Fixlets) mm).>>Mais tout cela est plutôt petit. De plus, à peu près 30 % des correctifs sont marqués comme stables, donc dans l’ensemble, la 5.1 semble en bonne voie pour une publication la semaine prochaine.>>Touchons du bois.>>Linus
# Les nouveautés
## Architectures
### x86 Intel & x86_64 AMD
Ajout de la plate‐forme Ice Lake Mobile dans la gestion d’intel_rapl [(_Running Average Power Limit_)](https://01.org/blogs/tlcounts/2014/running-average-power-limit-%E2%80%93-rapl).
 
Ajout de la plate‐forme Jacobsville dans la prise en charge d’intel_idle (Jacobsville est une plate‐forme basse consommation, descendant des premiers Atom, aujourd’hui famille 6 « _Atom Tremont_ », pouvant être utilisée dans des « micros‐serveurs » ou encore pour « l’Internet des objets »), et intel_idle leur permet de plonger en sommeil profond pour baisser la consommation électrique. L’intel_idle et les _c_state_ ont parfois causé pas mal de soucis sur certains PC portables, tels que le gel du système avec, et consommation électrique trop élevée sans. Et contrairement à l’ACPI standardisé, les _c_states_ peuvent changer d’un système monopuce (SoC) à un autre. L’ajout de cette prise en charge devrait régler ce problème pour ces systèmes monopuces (processeur + jeu de composants) _Jacobsville_.
 
Ajout de la prise en charge du matériel MSN3700C de Mellanox.
 
Prise en charge des diodes électroluminescentes (DEL/LED) et des boutons pour les APU v2 et v3 de chez [PCengines](https://pcengines.ch). 
### ARM
Comme d’habitude avec cette architecture, la prise en charge de nombreux nouveaux systèmes monopuces (_SoC_) est intégrée, et de nouveaux déclaratifs Device Tree font leur apparition. Entre autres choses on pourra citer :
 
- l’arrivée du MT7629 de chez [Mediatek](https://www.mediatek.com/), le tout dernier routeur Wi‐Fi de la marque, avec un double cœur Cortex A7 (et une prise en charge avec OpenWRT) ;
- l’entrée des Renesa R7/AM2 (puce spécialisée dans le traitement d’image) et RZ/G2E ; ne vous emballez pas, il s’agit « juste » du Device Tree, et pas d’une prise en charge complète (la seconde puce, par exemple, embarque un PowerVR à côté de son double cœur Cortex A53).
 
Et bien d’autres, cependant sans rien qui sorte spécialement du lot pour être mentionné, aussi vous pouvez aller lire la liste complète des nouveautés ARM sur [_Linux Kernel Newbies_](https://kernelnewbies.org/Linux_5.1#ARM). On notera juste l’arrivée d’une variante du Raspberry Pi, le 3 A+, pour laquelle le raffinement d’un contrôle Bluetooth séparé de celui du Wi‐Fi est ajouté.
### RISC-V
La prise en charge matérielle de [RISC-V](https://fr.wikipedia.org/wiki/RISC-V) arrive à maturité et des correctifs de noyau avancés doivent être testés et exécutés au moins sur la carte de développeur [HiFive Unleashed de SiFive](https://www.sifive.com/boards/hifive-unleashed).
### Autres
Prise en charge du système monopuce Bitmain en tant qu’A53 double cœur combiné à un seul cœur RISC-V, bien que seul le processeur ARM soit pris en charge pour le moment. Il existe également une nouvelle prise en charge pour ARM, notamment Socionext Milbeaut, NXP i.MX8QuadXPlus et quelques systèmes monopuces de Rensas.
## Identification des processus
Le bien connu système de PID souffrait d’un problème de réattribution d’un numéro d’identifiant pour un processus, pouvant _éventuellement_ mener à une situation de concurrence où un processus A envoyait un signal à un processus B, alors que ce dernier était stoppé et son numéro d’identifiant réattribué à un processus C. On peut lire [cette discussion](https://lkml.org/lkml/2019/3/31/5) pour constater que certains usages ont réellement rencontré ce qui ne semblait être qu’un problème théorique.
Après de nombreuses discussions et propositions correctrices sur plusieurs axes, cette affaire est maintenant close avec l’ajout d’un nouvel appel système, ``pidfd_send_signal``. Une [vidéo](https://asciinema.org/a/IQjuCHew6bnq1cr78yuMv16cy) sur _ASCII cinema_ en présente les principes.
## Gestion de la mémoire
### Mémoire vive non volatile
Une nouveauté particulièrement intéressante est l’introduction d’un nouveau mode d’usage pour la « mémoire persistante ». Pour rappel, NVDIMM ([_non‐volatile dual in‐line memory_](https://en.wikipedia.org/wiki/NVDIMM)) est un type de mémoire résistant à un arrêt électrique : son contenu est conservé comme sur un disque dur. Le noyau prenait en charge ce type de matériel comme un disque. Il est maintenant possible d’utiliser la NVDIMM comme une barrette mémoire, en utilisant l’API de gestion de mémoire du noyau. Des gains de performances sont donc attendus, et ces gains seront maintenus pendant toute la séquence de fonctionnement de la machine, sans perte de performance au fur et à mesure de l’usage. L’implémentation passe par un accès aléatoire du placement des nouveaux blocs. Comme le [souligne Kees Cook](https://lwn.net/ml/linux-kernel/CAGXu5jLRuWOMPTfXAFFiVSb6CUKaa_TD4gncef%2BMT84pcazW6w%40mail.gmail.com/) il est plaisant de voir qu’une fonctionnalité de sécurité améliore les performances !
 
Est-ce que la NVDIMM ressemble plus à [un fantôme](https://www.jedec.org/news/pressreleases/jedec-ddr5-nvdimm-p-standards-under-development) qu’à une réalité, le marché et les constructeurs ne proposant au mieux qu’un ajout d’une petite batterie sur la barrette ? Les choses semblent bouger, notamment chez les grands fournisseurs de « solutions en nuage » et constructeurs, tels que HP et Intel.
 
_En aparté, et à côté de la NVDIMM, il se trouve que l’implémentation de [DAX](https://www.kernel.org/doc/Documentation/filesystems/dax.txt), spécifique aux architectures x86, a été proposée (lors du dernier _2019 Linux Storage, Filesystem, and Memory‐Management Summit_ » du début d’année) pour être considérée comme terminée._
### Accélération du vidage de l’espace d’échange mémoire (swap)
Une autre nouveauté marquant cette version est la réduction de la complexité de l’algorithme derrière le mécanisme ``swapoff``, opération permettant de vider l’[espace d’échange mémoire](https://fr.wikipedia.org/wiki/Espace_d%27%C3%A9change) sur le stockage de masse afin de renvoyer son contenu en mémoire vive. Opération que l’on soupçonne complexe et qui vient d’être simplifiée. Les gains de performances impressionnent : on passe de 80 % de temps processeur et 8 min pour renvoyer 6 Gio de l’espace d’échange vers la mémoire vive, à 5 % de processeur et 3 min pour la même opération avec la nouvelle implémentation. Voir [ce courriel](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b56a2d8af9147a4efe4011b60d93779c0461ca97) pour en savoir plus. 
### Défragmentation des HugePages
Les _Transparent HugePages_ continuent de recevoir des améliorations. Cette fois, c’est pour leur gestion de la **dé**fragmentation, ce qui complète le travail [précédent](https://linuxfr.org/news/sortie-du-noyau-linux-5-0#toc-r%C3%A9duction-de-la-fragmentation-des-transparent-huges-pages) et permet maintenant d’améliorer leur allocation. Voir [ces explications](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c5fbd937b603885f1db3280ca212ed28add895bc), pour en apprendre plus. Le changement est noté comme « allocation proche de la perfection ». Vingt‐deux correctif constituent cette belle avancée.
### OOM Killer
L’_Out Of Memory Management_ reçoit une légère modification. Pour éviter une situation où un processus bogué consommant toute la mémoire vive et l’espace d’échange est tué, mais toujours relancé par le processus initial (PID 1), c’est maintenant le processus père qui sera tué pour protéger le fonctionnement du système et des services. Aucun doute que certains ici ont connu ce type de situation avec, par exemple, des outils « constructeurs » complètement bogués et tués dix fois par jour. Un voile de pudeur posé sur leur nom, on préfèrera mettre en lumière [ce correctif](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bbbe48029720d2c6b6733f78d02571a281511adb).
### Gestion des vidages mémoire (dumps) 
Vous avez des machines disposant de beaucoup de mémoire vive, elles portent des machines virtuelles et vous avez un besoin d’analyse de crashs ? Vous serez alors intéressé par l’exclusion des _balloon pages_ des vidages mémoire (_dumps_) du noyau, permettant de réduire (fortement ?) la taille de ces _dumps_. Au passage, elles ont aussi été exclues du processus d’hibernation. Pour rappel la technique du _ballooning_ permet, par exemple, à la machine hôte de réclamer de la mémoire vive à une ou des machines invités. Le premier correctif [explique](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4d3467e171f8a8ef8f1dd205769cf2f21fbc8e1e) en détails cette modification.
## Sécurité
### SafeSetID
On notera surtout l’arrivée d’un nouvel LSM (_Linux Security Module_) : SafeSetID. Il s’agit d’autoriser ou non la transition d’UID par une liste blanche d’approbation côté système et l’obtention de privilèges de type `CAP_SETUID`. Pour le moment, les appels système `SETUID` sont pris en charge, les `SETGUID` devraient suivre sous peu. Lisez la [documentation du noyau](https://www.kernel.org/doc/html/latest/admin-guide/LSM/SafeSetID.html) pour aller plus loin.
### eBPF
eBPF a le vent en poupe avec pas moins de quinze nouveautés. BPF, _[extended Berkeley Packet Filter](https://www.kernel.org/doc/html/latest/bpf/index.html)_ a trois axes : le réseau, la sécurité (seccomp, [landlock](https://landlock.io/)...) et l’instrumentation du noyau. 
Au menu des nouveautés, il y a, entre autres, la [création de rapports](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=492ecee892c2a4ba6a14903d5d586ff750b7e805) d’usage de BPF lui‐même, l’ajout possible des [en‐têtes IP](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e0bd37ce0e4a574df6d87a901e13bcb46e10301) encapsulés dans les paquets pour IPIP, IP/GRE, IP/GUE pour IPv4 et IPv6, et la gestion du type ``__int128`` sur les architectures AMD64 (_cf._ [ce _commit_ initial](https://git.kernel.org/linus/b1e8818cabf407a5a2cec696411b0bdfd7fd12f0)). Mais c’est la prise en charge de la concurrence qui retient le plus l’attention dans ces nouveautés, avec l’ajout d’un [verrou tournant](https://lwn.net/ml/netdev/20190131234012.3712779-1-ast@kernel.org/) (_spinlock_). Les discussions ne sont pas terminées quant aux évolutions futures possibles au sujet de la gestion de la mémoire dans ou avec eBPF, mais elles augurent de belles évolutions à venir.
 
Pour en savoir plus sur BPF, eBPF et l’outillage BCC, la lecture de [cette explication](http://www.linuxembedded.fr/2019/03/les-secrets-du-traceur-ebpf/) (en français) couvrant une partie de l’usage et avec des exemples pour BCC et Python, peut vous être utile.
## Bogue de 2038
L’an de grâce 2038 pourrait être l’année d’[un bogue comparable à celui de l’an 2000](/news/la-fin-dune-epoch) où des systèmes d’exploitation, des horloges matérielles, des systèmes de fichiers et des logiciels se retrouveront à afficher une date erronée (1901 au lieu de 2038, voir [cet article](https://fr.wikipedia.org/wiki/Bug_de_l%27an_2038#Les_syst%C3%A8mes_de_fichier_immunis%C3%A9s) sur Wikipédia). Ce problème concerne, entre autres, la représentation [[POSIX]] du temps, qui était limitée à 2 147 483 647 secondes (rapport entre le 1^(er) janvier 1970 et une représentation avec un entier signé de 32 bits) 
 
Le noyau compilé pour x86_64 est immunisé. Les architectures 32 bits pourront, avec ce noyau 5.1, disposer d’une structure ``time_t`` sur 64 bits. Une élégante et parfaite solution.
## Périphériques et pilotes
### Cartes graphiques
#### AMD
Du côté du pilote libre amdgpu, on a la prise en charge de BACO (_Bus Active, Chip Off_) pour les Vega 10 et 20, un mode d’économie d’énergie dans lequel la majeure partie du processeur graphique est éteinte pendant les périodes d’inactivité, afin de réduire considérablement la consommation d’énergie de la carte graphique.
 
Le [PowerPlay](https://en.wikipedia.org/wiki/AMD_PowerPlay) pour les Vega 10 et 20 s’expose maintenant à l’espace utilisateur, via [sysfs](https://fr.wikipedia.org/wiki/Sysfs), ``ppfeatures`` permettant d’en configurer certains aspects : l’horloge, avec ``pp_dpm_socclk`` et l’accélération du ou des ventilateurs pour les Vega10 et ``pp_dpm_fclk`` pour les Vega20. Ceci devrait ravir les _overclockers_ et être utile aussi pour maîtriser un peu plus la consommation d’énergie.
#### Intel
La protection [HDCP](https://fr.wikipedia.org/wiki/High-bandwidth_Digital_Content_Protection) (_High-Bandwidth Digital Content Protection_) en version 2.2 est prise en charge. Pour rappel, il s’agit d’un mécanisme évitant la copie de flux numérique passant par les connecteurs HDMI, DVI et DisplayPort.
 
Le mode _fastboot_ est maintenant actif par défaut. Ce mode permet d’éviter les multiples initialisations de la carte graphique et/ou de la résolution lors de la séquence de démarrage du système. C’est un bon complément pour une configuration en « amorçage silencieux ». Toutes les cartes au‐delà de la neuvième génération en bénéficient.
 
_Un exemple [en vidéo](https://www.youtube.com/watch?v=ud9cTqr9Eew) avec une carte graphique autre qu’une Intel, où le rendu graphique de la séquence d’amorçage est sans interruption depuis le BIOS jusqu’au bureau, mais sur lequel il reste un ajustement final ; le_ fastboot _activé par défaut pour les cartes Intel évite cet ajustement final)._
 
À noter aussi un petit correctif pour le « mode TV » : les fréquences 30 Hz, 50 Hz et 60 Hz en 1080p.
 
Quelques nouvelles déclarations de matériels, pour _Coffee Lake_ et _Ice Lake_, du nettoyage dans le débogage. Il y a également l’ajout de l’exposition à l’espace utilisateur de la configuration RPCS (SSEU) pour les cartes de la onzième génération, « Gen11 », uniquement (visiblement contre‐productif sur les autres générations). Lisez [ce rapport](https://bugs.freedesktop.org/show_bug.cgi?id=100899) initial pour en savoir plus sur un des constats et l’origine de la question.
### Cartes son 
Côté audio ce sont surtout les ASOC qui reçoivent des nouveautés, avec pas moins de vingt‐six nouvelles prise en charge, allant du simple ajout de la gestion du bouton de bascule vers un ensemble casque‐micro de tête pour les séries Broxton chez Intel, jusqu’à l’arrivée d’un nouveau codec, le [jz4725b](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e9d97b05a80f27d5ba7379b108db19b0d93cf267), en passant par une nouvelle carte prise en charge par le module [rt5651](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d306873589c5a4c13df7176cd73d66ebfa690064). C’est aussi l’arrivée de la prise en charge pour l’équipement [FireFace UCX](http://www.rme-audio.de/en/products/fireface_ucx.php) de chez RME.
 
Bien que peu excitant pour ce noyau 5.1, la prise en charge de l’audio par Linux continue son chemin. Les audiophiles préféreront peut‐être se pencher sur la nouvelle couche logicielle [PipeWire](https://pipewire.org/) en dehors du noyau, qui a pour ambition d’unifier audio et vidéo, et remplacer à terme Jack et PulseAudio, tout en préservant une compatibilité. 
### Réseau
Côté Mellanox, toujours beaucoup de nouveautés, avec de petites modifications vraiment atomiques, et des améliorations surtout pour l’[[Infiniband]] :
 
- gestion du 50 Gbit/s par voie (sur les liens 50 Gbit/s, 100 Gbit/s et 200 Gbit/s) ; à noter que la prise en charge de ces cartes est d’ores et déjà rétroportée dans les distributions majeures ;
- améliorations pour la série des cartes et adaptateurs InfiniBand de série 573xx de ce fabricant (incluant les 57500, Connect-x6, cartes de débit 200 Gbit/s).
C’est fait dans le cadre de l’[Open Fabric Alliance](https://www.openfabrics.org/) pour rapprocher les possibilités du pilote libre de leur pilote propriétaire. La cible principale est la meilleure adaptation du matériel au calcul haute performance. Les développeurs intéressés pourront consulter les manuels (au‐delà de Mellanox), [disponibles](https://ofiwg.github.io/libfabric/v1.7.1/man/) chez Open Fabric. L’effort de convergence, de code source ouvert et de partage ou mise en commun ne peut qu’être encore une fois salué.
 
Pour le grand public, côté Broadcom, des [améliorations mineures](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e665988be29ccea3584528967b432a5cfd801ca4) dans le module brcmfmac, pour coller au nouveau fonctionnement des derniers micrologiciels.
## Intelligence artificielle
[Intégration](https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/log/?h=char-misc-next&qt=grep&q=habanalabs) de la prise en charge de la carte « d’intelligence artificielle » de chez [Habana Labs](https://habana.ai/) de génération Goya. La génération suivante, Gaudi, est d’ores et déjà prévue. Habana Labs présente son propre calculateur spécialisé, la carte Goya est plus spécialement conçu pour l’analyse, tandis que la carte Gaudi sera plus spécialement prévue pour l’apprentissage et elles s’interfacent toutes deux avec les piles logicielles du secteur (telles que [[TensorFlow]]) et surtout Habana Labs nous fait le plaisir d’ajouter cette prise en charge avec du code libre directement chez _kernel.org_.
Ce secteur bouge beaucoup, [NVIDIA vient de se réinventer](https://www.nvidia.com/fr-fr/deep-learning-ai/) en « constructeur d’intelligence artificielle », tandis qu’Intel vient [d’annoncer](https://www.intel.ai/nervana-nnp/#gs.9lnlyn) ses premières puces spécialisées et les acteurs de l’informatique en nuage : Google et AWS travaillent sur leurs propres puces.
## Systèmes de fichiers et outillage
### IO_URING
IO_Uring fait son entrée officielle dans la branche stable avec cette 5.1. C’est une avancée majeure de ce noyau.
Il s’agit d’améliorer drastiquement les [entrées‐sorties asynchrones](https://en.wikipedia.org/wiki/Asynchronous_I/O), certes prises en charge depuis longtemps par Linux, mais dont l’implémentation recevait quelques critiques et méritait d’être améliorée. Cette nouvelle interface ``io_uring`` apporte la gestion du tampon pour ces entrées‐sorties asynchrones, et la gestion d’autres types d’entrées‐sorties asynchrones. [Cet article](http://kernel.dk/io_uring.pdf) en anglais est un bon choix pour aller plus loin.
### VFS
Le système de fichiers virtuels [[VFS]] permet d’utiliser différents systèmes de fichiers de manière transparente pour les applications. Cette coexistence via cette abstraction permet, entre autres, de s’affranchir des noms de volumes (problème bien connu de Windows) et constitue ce qui permet de gérer en « points de montage » avec l’appel système ``mount()``.
Bien que ``mount()`` ne souffre d’aucun problème, un nouvel appel système ``fsopen()`` voit le jour afin d’apporter une opération intermédiaire descriptive. Concrètement, là où aujourd’hui ``mount`` s’occupe de tout dans tous les cas, demain ``fsopen`` passera en premier et ``mount`` ne s’occupera que du strict nécessaire pour la cible. Il permettra à terme de nouvelles possibilités sur les systèmes de fichiers (remontage dans un espace de noms, par exemple. D’autres exemples et des descriptions des limitations actuelles, sont explicités dans [ce courriel](https://patchwork.kernel.org/cover/10820153/)).
Cependant, en lisant ces lignes, on peut se demander quels gains réels sont attendus. C’est également une des questions posées par certains mainteneurs du noyau, [dont Linus](https://lwn.net/ml/linux-kernel/CA+55aFzEjPUGZFk7PnM0T6YEn5uRrscgyCHyhc_cYz0m8ejdLA@mail.gmail.com/), concernés aussi par la taille de ce correctif sur un des systèmes centraux du noyau, et des possibles implications de sécurité que cela peut engendrer. Après des mois de révisions et d’améliorations, il semble bien aujourd’hui que ``fsopen()`` ait sa place dans le noyau. Nous aurons probablement l’occasion d’en reparler, peut-être bien à plusieurs reprises.
### AutoFS
AutoFS se voit doté d’une nouvelle option « ignore », il s’agit d’une requête initiale venant de Red Hat, afin de permettre à des applications le souhaitant de ne pas tenir compte de ces points de montage. Votre serviteur émet un doute quant à la pertinence de cette solution, d’autres identifications existent pour éviter d’exposer des points de montage AutoFS, mais il semble ne s’agir que d’un début, comme le [laisse entrevoir](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=60d6d04ca3abb34d5e89f030dbea440d9715a168) le commentaire du correctif. Donc, _wait and see_.
### XFS
XFS, ajoute un mode ``always_cow`` (pour le _copy on write_) permettant un débogage plus pertinent dans certaines situations et la prise en charge des matériels qui « ne permettent pas l’effacement de blocs » (zones déclarées en lecture seule). Un cas typique d’usage est un mécanisme de protection des données contre la corruption (coupure électrique, par exemple) : un second espace de métadonnées est alloué et dédié aux journaux jusqu’à ce que l’opération soit complète. Concrètement, il n’y aura jamais de réécriture d’un bloc déjà existant, mais une mise à jour à côté. Voir cette [petite documentation](https://github.com/hgst/dm-zoned-tools) sur ZBC et ZDAC pour le contexte initial (ainsi qu’une ancienne présentation de Damien Le Moal à [ce sujet](https://www.snia.org/sites/default/files/SDC/2016/presentations/smr/DamienLeMoal_ZBC-ZAC_Linux.pdf)).
 
_À noter que cette prise en charge était déjà effective dans le système de fichiers F2FS._
### NFS
[NFS](https://fr.wikipedia.org/wiki/Network_File_System) dépasse une limitation de la glibc pour la lecture du contenu d’un dossier en se dotant d’un cache spécifique. _En fait de limitation, il s’agit surtout de s’affranchir des problèmes des performances (observables avec des outils usuels tel que ``ls`` en shell ou ``os.listdir`` en Python, par exemple), causés par [``readdir``](http://man7.org/linux/man-pages/man3/readdir.3.html) alors que [``getdents``](http://man7.org/linux/man-pages/man2/getdents.2.html) existe, mais est absent de la glibc)_.
Ce correctif annonce des gains de performances de l’ordre de 70 % lors d’une énonciation du contenu d’un dossier (bémol : on parle là de dossiers contenant plusieurs centaines de milliers de fichiers).
### CIFS
De l’amélioration aussi, via du cache, chez [[CIFS]] : la réponse à ``stat /montage`` ne nécessitera plus d’opération réseau à chaque fois. Intéressant de noter que ce correctif est un travail collaboratif avec Microsoft — Samba/CIFS a fait du chemin depuis ses premières versions basées sur de la rétro‐ingénierie. 
### FSNotify / fanotify
À côté des systèmes de fichiers ou affiliés, fanotify reçoit _enfin_ [le nécessaire](https://github.com/amir73il/linux/commits/fanotify_dirent) pour la surveillance récursive. Celle-ci était auparavant source de consommations de mémoire (voire de temps processeur) car implémentée côté outils, ce n’est plus le cas et les outils pourront faire appel à ``dirent``. Il bénéficie également d’une série de correctifs améliorant les évènements du système de fichiers et son propre comportement.
### Autres
Ceph, plate‐forme de stockage distribué, continue de recevoir des améliorations, tandis qu’ExoFS se fait sortir du noyau. 
 
Enfin, il est maintenant possible, moyennant préparation, d’amorcer directement un périphérique déclaré via le _device-mapper_, donc sans initrd. Ceci ne concerne pas toutes les possibilités de _device-mapper_, seules six sont actuellement disponibles. Par exemple : amorçage direct sur une partition chiffrée, ou encore sur une partition « dm_verity ». Voir cette première [documentation](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/device-mapper/dm-init.txt?id=6bbc923dfcf57d6b97388819a7393835664c7a8e). L’amorçage sur un DM, sans initrd, ça se teste rapidement !
## LivePatch
La fonction « _live patch_ » reçoit le « remplacement atomique » permettant de jongler avec plusieurs correctifs en série cumulative. Concrètement, il est maintenant possible de retirer un correctif d’une série. Cette amélioration est utile lorsque plusieurs correctifs touchent à la même structure, la même fonction du noyau, mais également lorsqu’il s’agit de gérer des dépendances entre ces correctifs.
 
_Le sujet semble cependant toujours sensible malgré ces efforts de convergence (menant kgraft et kpatch vers un socle commun), car si certains acteurs (CloudLinux, par exemple) proposant leur solution ne sont pas vraiment un problème à terme, Microsoft en revanche, possède un brevet (aux États‐Unis) sur l’idée, faisant ainsi peser un risque sur la vie de ce projet, et ne semble pas avoir clarifié la situation et son objectif à ce sujet._
# Statistiques
Nous vous invitons simplement à lire les informations collectées par [Jonathan Corbet pour _LWN.net_](https://lwn.net/SubscriberLink/786638/32666bef6143ff6e/) pour la RC-6.
# Autour du noyau
La création du « CHIPS Alliance Project » a été annoncée pour accélérer l’adoption du modèle _Open Hardware_. Les membres actuels sont Esperanto, Google, SiFive et Western Digital. Pour lancer cette nouvelle alliance, Google a contribué à [UVM](https://en.wikipedia.org/wiki/Universal_Verification_Methodology) pour les RISC-V. Le projet est hébergé aussi sur [GitHub](https://github.com/google/riscv-dv). Plus d’information sur le [site de l’alliance](https://chipsalliance.org/).
 
Pas moins de quarante‐trois nouvelles sociétés [rejoignent](https://www.linuxfoundation.org/press-release/2019/04/43-new-members-join-the-linux-foundation-and-increase-their-participation-in-open-source-innovation/) la Fondation Linux, dont Wolkswagen AG.
</div><div class="naked_ctrl">
<form action="/index.cgi/contrast" method="get" name="gate">
<p><a href="http://altstyle.alfasado.net">AltStyle</a> によって変換されたページ <a href="httpS://linuxfr.org/news/sortie-du-noyau-linux-5-1.md">(-&gt;オリジナル)</a>
/ <label>アドレス: <input type="text" name="naked_post_url" value="httpS://linuxfr.org/news/sortie-du-noyau-linux-5-1.md" size="22" /></label> <label>モード: <select name="naked_post_mode">
<option value="default">デフォルト</option>
<option value="speech">音声ブラウザ</option>
<option value="ruby">ルビ付き</option>
<option value="contrast" selected="selected">配色反転</option>
<option value="larger-text">文字拡大</option>
<option value="mobile">モバイル</option>
</select>
<input type="submit" value="表示" />
</p>
</form>
</div>