URL: https://linuxfr.org/news/sortie-du-noyau-linux-5-0 Title: Sortie du noyau Linux 5.0 Authors: bubarđŸŠ„ Julien Jorge, palm123, Davy Defaud et BenoĂźt Sibaud Date: 2019ćčŽ02月25æ—„T21:51:23+01:00 License: CC By-SA Tags: dreamworks, lwn, noyau_linux, kernel, linus_torvalds, libreoffice et spectre Score: 99 La sortie de la version stable 5.0 du noyau Linux a Ă©tĂ© annoncĂ©e le 4 mars 2019 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, tĂ©lĂ©chargeable sur les serveurs du site _kernel.org_. Linus a dĂ©cidĂ© de faire une RC 8, ce qui est relativement inhabituel. 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) [Le noyau, sa documentation](https://www.kernel.org/doc/html/v5.0/) [Les noyaux prĂ©cĂ©dents](http://linuxfr.org/wiki/depeches_noyau) [Annonce de sortie](http://lkml.iu.edu/hypermail/linux/kernel/1903.0/01288.html) ---- # En bref Pourquoi Linux 5.0 ? Rien Ă  dire de particulier, rien de remarquable, c’est juste un changement de version. # Annonces des versions candidates par Linus Torvalds ##RC-1 Annonce de la [premiĂšre candidate](https://lkml.org/lkml/2019/1/6/178), le 6 janvier. Note Ă  propos des vacances de fin d’annĂ©e, et du calme apparent. La quantitĂ© de modifications est jugĂ©e normale. Linus annonce Ă  cette occasion que la 4.21 deviendra la 5.0, et en donne l’explication : il n’y a pas de raison particuliĂšre, alors faisons‐nous Ă  l’idĂ©e, ou notre propre raison. ##RC-2 Annonce de la [seconde candidate](https://lkml.org/lkml/2019/1/13/146), tout est normal : la fenĂȘtre de fusion est respectĂ©e, sauf pour quelques cas pas plus nombreux qu’à l’habitude, le nombre des changements, leur rĂ©partition et la quantitĂ© de code sont eux aussi dans les standards habituels. Quelques amĂ©liorations du cĂŽtĂ© des outils de suivi des performances sont notĂ©es tout particuliĂšrement. ##RC-3 Annonce de la [troisiĂšme candidate](https://lkml.org/lkml/2019/1/21/257). Ici on y trouve une attention particuliĂšre sur la pile rĂ©seau elle‐mĂȘme, ainsi que sur les pilotes rĂ©seau. Quelques changements cĂŽtĂ© architectures, surtout MIPS et PowerPC. ##RC-4 La [quatriĂšme candidate](https://www.lkml.org/lkml/2019/1/27/170) a un cycle un peu excitĂ©. Linus signale que plus de demandes d’intĂ©gration sont survenues au dernier moment, et que certaines ont Ă©tĂ© refusĂ©es, mais rien d’anormal. ##RC-5 Le calme revient pour le cycle de cette [cinquiĂšme candidate](https://lkml.org/lkml/2019/2/3/484). Un tiers des changements a lieu dans les pilotes. Et Linus parle encore de vacances. ##RC-6 Pour la [sixiĂšme](https://lkml.org/lkml/2019/2/10/185), c’est toujours les pilotes rĂ©seau qui sortent du lot. C’est sur des rails que cette sortie se fait, une belle candidate de prime abord. ##RC-7 La [septiĂšme](https://lkml.org/lkml/2019/2/17/325) montre des statistiques avec presque la moitiĂ© des changements pour les pilotes. Et beaucoup de changements atomiques, petites modifications : on est vraiment dans la correction de bogues et les petites amĂ©liorations. ##RC-8 Surprise, la RC-7 ne suffira pas, un grand nombre de changements arrive d’un coup. Ce ne sera donc pas une version finale, elle sera estampillĂ©e [RC-8](https://lkml.org/lkml/2019/2/24/174), repoussant ainsi d’un cycle la sortie de cette 5.0. Cette candidate n’est pas Ă©norme mais propose plus de changements que la prĂ©cĂ©dente. Une semaine de calme sera bienvenue avant la sortie officielle. # Les nouveautĂ©s ## Des problĂšmes de performances ? [Michael Larabel](https://www.michaellarabel.com/) a constatĂ© de sĂ©vĂšres rĂ©gressions de performances avec ce noyau 5.0, [Ă  tous les niveaux](https://www.phoronix.com/scan.php?page=article&item=linux-50-sliding&num=6). Tellement qu’on peut lĂ©gitimement se demander s’il ne se serait pas tout simplement trompĂ© dans les options de compilation ? Notons que ces tests de performance ont Ă©tĂ© faits avant la sortie du noyau, avant mĂȘme les derniĂšres RC. ## Architectures ### x86 & x86-64, Intel et AMD Ajout de la prise en charge des extensions [QoS](https://community.amd.com/thread/231606) « QualitĂ© de Service de la plate‐forme » permettant d’avoir une surveillance de l’usage des consommations de certaines ressources, de les allouer et les limiter sĂ©parĂ©ment, pour la nouvelle gĂ©nĂ©ration des processeurs AMD, dite « EPYC ». Cette possibilitĂ© n’est pas seulement ajoutĂ©e, elle est mise en [coexistence](https://lkml.org/lkml/2018/12/23/69) avec le gestion du [RDT](https://www.intel.com/content/www/us/en/architecture-and-technology/resource-director-technology.html) pour les processeurs Intel. L’entrĂ©e RESCTL est une nouvelle structure accueillant Ă  la fois et [INTEL RDT et AMD QoS](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa7d949337ccad32c76740c88e0e0351c349053b). La gestion du cache est [Ă©galement](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a52fb43a5faa40507cb164a793a7fa08da863ac7) mise Ă  jour pour suivre cette Ă©volution. Toujours du travail pour ~~Ă©liminer~~ _empĂȘcher au mieux_ les failles de la famille « Spectre v2 », par exemple pour les multiples processeurs AMD ayant chacun des spĂ©cificitĂ©s avec leur [STIBP](https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf) (_Single Thread Indirect Branch Predictor_) Enfin, de nombreux ajouts pour les ordinateurs portables, des raffinements tels que les touches d’accĂšs rapide pour WMI chez Huawei ou encore le contrĂŽle visuel par [DEL](https://fr.wikipedia.org/wiki/Diode_%C3%A9lectroluminescente "diode Ă©lectroluminescente") (LED) lors de la dĂ©sactivation du micro pour les portables DELL, et l’équivalent pour les Lenovo. ### ARM Beaucoup de nouveaux systĂšmes mono-puces (SoC — _System on Chips_) sont intĂ©grĂ©s (NXP/Freescale i.MX7ULP, i.MX8 64 bits avec Cortex A3 et prise en charge de la vidĂ©o 4K, Qualcomm QCS404, Allwinner R40/T3, etc.), ainsi que seize nouvelles plates‐formes (nouveau [Linksys EA600](https://git.kernel.org/linus/03e96644d7a810916fc4997d572577e876908b18) par exemple, i.MX mtrion et i.MX 7D, Rockchip BQ edition, etc.). La grande famille ARM est Ă©galement touchĂ©e par « Spectre v2 » et a donc aussi son lot rĂ©gulier de correctifs pour cela. Cette version 5.0 intĂšgre les instructions dites « SB » (_speculation barrier_) pour la gĂ©nĂ©ration ARM v8.5. Voir le [_commit_](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f6795053dac8d4d2f90d4a98842dd6d2ccd544ad) initial. IntĂ©gration des algorithmes de chiffrement XChaCha12 et XChaCha20 pour tous, ainsi que la gestion de l’accĂ©lĂ©ration matĂ©rielle via [NEON](https://developer.arm.com/technologies/neon) pour NH[Poly1305](https://en.wikipedia.org/wiki/Poly1305). ARM64 bĂ©nĂ©fice aussi de la plupart de ces avancĂ©es, auxquelles il faut ajouter, entre autres, la [gestion](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=884143f60c89acf8f2d06de4113d5e3057791701) de [KASLR](https://en.wikipedia.org/wiki/Address_space_layout_randomization) et la vĂ©rification de signatures. Enfin, l’architecture particuliĂšre « [big.LITTLE](https://fr.wikipedia.org/wiki/Big.LITTLE) » reçoit une amĂ©lioration pour la consommation d’énergie dans l’ordonnanceur de tĂąches. Les tĂąches rĂ©veillĂ©es le sont toujours en prioritĂ© sur les cƓurs de processeur les moins gourmands en Ă©nergie dans cette architecture dissymĂ©trique. Son inclusion dans le noyau commence avec [ce correctif](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5bd0988be12733a42a1a3d50e3e2ddfd79e57518) et est maintenant complĂšte. Une architecture « big.LITTLE » sur ARMv8 propose jusqu’à quatre cƓurs de processeur LITTLE en Cortex A-53 (!) et jusqu’à seize cƓurs de processeur Cortex A-57, liĂ©s en diffĂ©rentes configurations : autant dire que « ça envoie du bois ». ### PowerPC Belle avancĂ©e pour le PowerPC, avec l’ajout de la gestion des _Huge Pages_ de 8 Mio (et celles de 512 Kio). Pour rappel, le processeur alloue par dĂ©faut de la mĂ©moire vive par page de 4 Kio. Plus il y en a et plus de temps processeur est pris pour trouver la bonne page Ă  la demande. Les _Huge Pages_ proposent donc des « _chunks_ » plus gros et des pages plus larges. Les applications qui en bĂ©nĂ©ficient sont surtout les bases de donnĂ©es, la virtualisation, et l’usage de diffĂ©rents procĂ©dĂ©s de cache mĂ©moire (_memcached_ par exemple). Un PowerPC a Ă©galement du travail pour [combattre « Spectre v2 »](https://lkml.org/lkml/2018/12/27/98) : le processeur NXP Book3E de chez Freescale. ### Autres Ajout d’une prise en charge prĂ©liminaire pour [Loongson 3A](https://fr.wikipedia.org/wiki/Loongson#Loongson_3A) R2.1 et amĂ©lioration du cĂŽtĂ© de [_ptrace_](https://en.wikipedia.org/wiki/Ptrace) pour les **[MIPS](https://fr.wikipedia.org/wiki/Architecture_MIPS)**. Du cĂŽtĂ© de **[[RISC-V]]**, la gestion pour l’audit est [lĂ ](https://git.kernel.org/linus/efe75c494f57890900caf6c8a0667db35bfaf56a). ## Gestion de la mĂ©moire Parmi les changements et amĂ©liorations dans la gestion de la mĂ©moire vive : ### RĂ©organisation du tableau de l’OOM Killer L’_OOM Killer_ (_out of memory management_) est un mĂ©canisme s’enclenchant lorsqu’il n’y a plus aucune mĂ©moire disponible : le noyau construit un tableau de victimes potentielles pour tuer celles prĂ©sentant Ă  la fois une forte consommation de ressources et ayant une fonction non essentielle. Le noyau prĂ©serve ainsi le systĂšme et les services rendus. Cas d’exemple : une fuite mĂ©moire dans un script Python utilisant _gdal_, au lieu de faire un Ă©cran bleu, ce script sera tuĂ© et le systĂšme continuera d’ĂȘtre opĂ©rationnel pour les autres — mais [cette rĂ©organisation](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ef8444ea01d7442652f8e1b8a8b94278cb57eafd) ne changera pas l’_OOM killer_ en l’adaptant pour les machines de bureau : il continuera de tuer joyeusement et avec bonne humeur votre LibreOffice. ### RĂ©duction de la fragmentation des Transparent Huges Pages Du cĂŽtĂ© des _Transparent Huges Pages_ (THP), la fragmentation a Ă©tĂ© rĂ©duite de 90 %, amĂ©liorant probablement leurs performances. Il ne s’agit pas d’une nouveautĂ© Ă  proprement parler mais de la suite d’un travail constant. Si discuter des Ă©vitements de fragmentations de la mĂ©moire vive dans un contexte d’usage des THP ne vous fait pas mal au crĂąne, ce [_commit_](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6bb154504f8b496780ec53ec81aba957a12981fa) explique en dĂ©tails les enjeux et les amĂ©liorations apportĂ©es dans cette version. ### Retours d’information des dĂ©faillances mĂ©moire Des amĂ©liorations sur les retours d’information en cas de dĂ©faillance d’une mĂ©moire, permettant de mieux identifier le problĂšme, voir ce [_commit_](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1c6fb1d89e73cd3bbfae7c400f1c615272aa435f). ### Option de dĂ©sactivation de kmemleak lors de l’amorçage Une nouvelle option permettant de dĂ©sactiver le _kmemleak_ Ă  l’amorçage du systĂšme a Ă©tĂ© ajoutĂ©e. Pour mĂ©moire, _kmemleak_ propose une façon pour identifier les fuites mĂ©moire des applications en espace utilisateur (d’autres mĂ©thodes existent, avec Valgrind par exemple). Ce procĂ©dĂ© scanne la mĂ©moire vive pĂ©riodiquement. [Offrir](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d53ce042277a94eadf9a8a31fc41fac54c67dec5) sa dĂ©sactivation permet d’allĂ©ger le processeur pour des environnements et systĂšmes oĂč le dĂ©bogage n’est pas ciblĂ© ou utilisĂ©. ## SĂ©curitĂ© ### Nouvelles commandes TPM2 De nouvelles commandes spĂ©cifiques Ă  [TPM2](https://trustedcomputinggroup.org/work-groups/trusted-platform-module/ "Trusted Platform Module") ont Ă©tĂ© intĂ©grĂ©es, conformĂ©ment au TCG 1.3x. ### SELinux Correction d’une erreur avec SELinux qui empĂȘchait par dĂ©faut le montage de sous‐volumes, alors que l’action sur le volume initial/principal a dĂ©jĂ  Ă©tĂ© vĂ©rifiĂ©e et autorisĂ©e. Ceci causait des problĂšmes avec l’auto‐monteur _automount_, AutoFS, et NFS. DorĂ©navant, lorsqu’un sous‐volume prĂ©sente un drapeau ``MS_SUBMOUNT``, SELinux autorise son montage. ### SECCOMP AmĂ©lioration pour le systĂšme SECCOMP : si un conteneur demande, par exemple, un ``init_module()``, alors SECCOMP va analyser l’image du module et charger le correspondant cĂŽtĂ© hĂŽte. Autre cas, autre exemple : un conteneur n’a pas accĂšs Ă  ``mknode()``, et personne ne veut d’un systĂšme de liste blanche pour des usages lĂ©gitimes (de type `/dev/null` ou `/dev/zero`) et ``mount`` a dĂ©jĂ  tout le nĂ©cessaire pour rĂ©pondre Ă  ce besoin. Une [_trap_ SECCOMP](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=db5113911abaa7eb20cf115d4339959c1aecea95) a donc Ă©tĂ© ajoutĂ©e pour l’espace utilisateur afin de notifier une autre tĂąche qu’un filtre SECCOMP particulier vient d’ĂȘtre dĂ©clenchĂ©. ConcrĂštement, SECCOMP peut donc maintenant dĂ©lĂ©guer des politiques en espace utilisateur. ### Chiffrement NHPoly1305, XChaCha12 et XChaCha20 Les algorithmes de chiffrement NHPoly1305, XChaCha12 (lĂ  surtout pour Adiantum) et XChaCha20 ont Ă©tĂ© intĂ©grĂ©s. Ce document (en anglais) sur [_cr.yp.to_](https://cr.yp.to/chacha/chacha-20080128.pdf), prĂ©sente assez simplement les informations sur ChaCha. La gestion de l’accĂ©lĂ©ration matĂ©rielle pour ces mĂȘmes algorithmes a Ă©tĂ© ajoutĂ©e dans le pilote CCAM (crypto\_dev\_fsl\_caam). ### Chiffrement AEAD pour le pilote Nitrox Ajout de l’algorithme AEAD pour le pilote Nitrox, utilisĂ© par exemple sur [certaine cartes Marvell](https://www.marvell.com/security-solutions/nitrox-security-adapters/), aussi dans une architecture « LiquidIO IPSec » (via Cavium) avec certaines cartes rĂ©seau du mĂȘme fabricant. ### ARM TrustZone CryptoCell L’ARM TrustZone CryptoCell 703, Ă©dition chinoise du 713, car n’intĂ©grant que les algorithmes validĂ©s par l’office chinois OSCCA, est intĂ©grĂ©. Sa version « complĂšte » 713 Ă©galement. Voir [cette ressource](https://developer.arm.com/products/system-ip/security-ip/cryptocell-700-family) pour une comparaison rapide. ### kexec kexec est une ancienne capacitĂ© de charger un second noyau en mĂ©moire vive, pour rĂ©amorcer le systĂšme dessus sans passer par les phases d’initialisation des BIOS, micrologiciels et EFI longues, trĂšs longues, de certaines machines. `kexec_load_file()` tient maintenant compte du nouveau trousseau de clefs nommĂ© `.plateform` de SecureBoot. Il est aussi utile pour d’éventuels modules de sĂ©curitĂ© qui peuvent utiliser ce nouveau trousseau pour vĂ©rifier, autoriser et interdire les images noyau chargĂ©es, demandĂ©es par un appel `kexec_load_file()`. ## Plaisirs d’administrateurs systĂšme Les administrateurs systĂšme bĂ©nĂ©ficient des nouveautĂ©s suivantes : - l’ajout de deux marques spĂ©cifiques dans le systĂšme _fanotify_ permettant de distinguer une exĂ©cution : `fan_open_exec` et `fan_open_exec_perm` — tous les administrateurs systĂšme utilisant ce sous‐systĂšme via des utilitaires tels qu’_inotify_, _incron_ et _audit_ en seront ravis ; - l’activation dans la hiĂ©rarchie par dĂ©faut d’un contrĂŽleur CPUSET, concernant la prise en charge des Cgroups version 2 ; introduit il y a plus de dix ans, mais optionnel et laissĂ© Ă  la discrĂ©tion des admins, il fait maintenant son apparition dans une configuration « de base », en options minimales — certaines de ses possibilitĂ©s pourraient Ă  l’avenir migrer dans le contrĂŽleur Cgroup de mĂ©moire ou le contrĂŽleur Cgroup de processeur ; - l’ajout d’une possibilitĂ© de configuration des informations affichĂ©es lors d’une panique, grĂące au nouveau _panic_print_. ## PĂ©riphĂ©riques et pilotes ### NVMe over Fabric L’implĂ©mentation du NVMe over Fabric ([[NVMe]] pour « mĂ©moire vive non volatile via bus PCI Express ») : concrĂštement il s’agit de s’affranchir des limites du port PCI Express en termes de distance physique, et de mettre Ă  disposition du systĂšme des NVMe lointains via les rĂ©seaux TCP/IP. ### Audio Du cĂŽtĂ© du son, dans le noyau, nouvelles prises en charge et amĂ©liorations habituelles dans la pile gĂ©nĂ©rique HD_AUDIO, ainsi que pas mal de boulot sur les systĂšmes monopuces (SoC) prĂ©sentĂ©s sur diffĂ©rents connecteurs, mais Ă©galement une gestion prĂ©liminaire du [AK4118](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bf897b441bd3afdd43e19605df4fb5a105678664) . ### Pilotes de cartes graphiques AMD et sa **Radeon VII**, semble bien ĂȘtre le meilleur choix pour les joueurs libristes et plus gĂ©nĂ©ralement de tous les joueurs sous GNU/Linux. Cette carte et son pilote libre _amdgpu_, accompagnĂ©e de Mesa 3D, accroche en performance une NVIDIA RTX 2080 avec son pilote propriĂ©taire. OK ? **OK !** #### AMD - gestion du [FreeSync](https://en.wikipedia.org/wiki/FreeSync), les frĂ©quences dynamiques de rafraĂźchissement d’écran (permettant d’éviter certains effets visuels indĂ©sirables et aussi d’allĂ©ger la consommation), dans sa version « FreeSync 2 HDR », pour le pilote AMDGPU, et aussi un correctif, supprimant un petit bogue, acceptĂ© en toute derniĂšre minute ; - la rĂ©initialisation du processeur graphique est fonctionnelle pour les CI, VI et Soc15, mais aussi sur les processeurs graphiques intĂ©grĂ©s aux cartes mĂšres (dGPU pour _discrete GPU_) ; si un traitement atteint un dĂ©lai de grĂące, le processeur graphique peut ĂȘtre rĂ©initialisĂ©, sans autre problĂšme ; - gestion pour l’espace utilisateur (via _sysfs_) de l’exposition des adresses mĂ©moire des pages dites « _BO doorbells_ » (un lien explicatif, bien qu’ancien et n’ayant pas de rapport direct avec cette nouvelle prise en charge, historique et [intĂ©ressant Ă  lire](https://lwn.net/Articles/605153/)) ; - gestion de la DCC (_Delta Color Compression_) : jusqu’à prĂ©sent ce n’était pas manipulable en espace utilisateur, ce correctif l’active et l’expose Ă  la fois pour la _libdrm_ et l’AMDGPUDM, et ceci sans ajouter d’appels `ioctl()` supplĂ©mentaires, ce qui devrait impacter favorablement les performances et la gestion de l’énergie ; - prise en charge des Vega 12 et Polaris 12 pour KFD (_kernel fusion driver_, issu de HSA/Compute) ; d’autres Vega, dont Vega 20, arrivent au pas de charge — lire cet ancien [_commit_](https://lists.freedesktop.org/archives/amd-gfx/2018-July/023673.html) pour en savoir plus, aussi sur la fusion de KFD dans AMDGPU ; - et quelques autres, dont une mise Ă  jour de micrologiciels SMU pour quelques variantes des GFX9, la gestion du PowerPlay pour les nouvelles Polaris, ajout de l’identifiant PCI pour les derniĂšres Vega M, mais aussi un raffinement correctif pour l’amorçage « _seamless_ » (un « amorçage du systĂšme silencieux et parfait visuellement ») avec les processeurs graphiques intĂ©grĂ©s aux cartes mĂšres (dGPU). #### Intel - ajout de l’identifiant PCI pour les derniĂšres _Amber Lake_ ; - gestion des espaces colorimĂ©triques [YCbCr](https://fr.wikipedia.org/wiki/YCbCr) 4:2:0 et 4:4:4 pour les puces LPSCon par le pilote [i915](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=668b6c176c33f443a50afd981cc9c0939e411b3b) et ajout de la transmission des informations AVI (la spĂ©cification semble si compliquĂ©e que de nombreux vendeurs de puces LPSCon le font chacun Ă  leur maniĂšre, nous avons donc lĂ  Ă  la fois un modĂšle gĂ©nĂ©rique et des subtilitĂ©s pour chaque marque de LPSCon) ; - et quelques autres petites amĂ©liorations, par exemple le [mĂ©lange du plan Alpha](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b20815255693733d06af788ea0b9dcd6271c3841), il pouvait y avoir des erreurs lors de l’usage d’une transparence totale ou _a contrario_ d’une opacitĂ© totale. #### NVIDIA et autres De nombreuses autres cartes graphiques bĂ©nĂ©ficient d’amĂ©liorations. _Nouveau_ ajoute le gestion initiale de la gestion des modes d’affichage (_modsetting_) pour la nouvelle gĂ©nĂ©ration des NVIDIA Turing 104 et 106. Les NVIDIA Tegra 186 et 194 bĂ©nĂ©ficient maintenant de l’audio via le port HDMI. Le Plan Alpha est intĂ©grĂ© aux Exynos. VMWGFX gĂšre maintenant la commutation de page (_page flipping_). Les Rockchips, MALI, Sun4Xi et Meson ne sont pas en reste. #### Autres amĂ©liorations - gestion de la compression de flux dynamique DSC (_dynamic stream compression_) des gĂ©nĂ©rations 10 et 11 des _displays ports_ et _external display ports_, selon la norme [VESA](https://vesa.org) [DP](https://www.displayport.org/) 1.4 ; - prise en charge gĂ©nĂ©rique Ă  un Ă©quivalent Ă  ci‐dessus, pour le port HDMI — voir [ce commit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ba1b0f6c73d4ea1390f0d5381f715ffa20c75f09) initial. ### RĂ©seau Pas moins de 36 pilotes reçoivent des correctifs et amĂ©liorations. Une vĂ©ritable tempĂȘte. On notera particuliĂšrement parmi ceux‐ci : - cĂŽtĂ© professionnel, les Mellanox gĂ©rĂ©es par mlx5 (carte ConnectX de 5^(e) gĂ©nĂ©ration) reçoivent seize amĂ©liorations : GRE, tunnels au travers de VLAN tc, amĂ©liorations du DEVX et de ses commandes spĂ©cifiques, implĂ©mentation de l’IBTA CapabilityMask2, etc. — notons que la configuration de ces cartes est aisĂ©e avec le paquet [mstflint](https://github.com/Mellanox/mstflint) et sa commande `msfconfig` ; - cĂŽtĂ© grand public, de nouvelles cartes sont dĂ©sormais gĂ©rĂ©es par `iwlwifi` : les 9461, 9462, 9560 et la sĂ©rie dite _killer_ ; les Broadcom sont Ă©galement de la partie, avec pas moins de neuf amĂ©liorations recensĂ©es par votre serviteur, dont la 4354 pour le brcmfmac (dont il est souvent question de nos jours : c’est fait) ; - l’arrivĂ©e de l’autonĂ©gociation pour la 5G (et la 2,5G) pour le PHY. Enfin, et ce n’est pas la moindre des amĂ©liorations, le protocole UDP reçoit le support du _Generic Receive Offload_ (GRO), voir ce premier [_commit_](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=60fb9567bf30937e6bedfa939d7c8fd4ee6a1b1c) pour cette sĂ©rie. Le sujet est ancien et a connu semble‐t‐il plusieurs propositions correctives. Cela impacte les performances du protocole UDP, dans un contexte gĂ©nĂ©ral d’augmentation de la bande passante disponible et d’augmentation de la puissance processeur, avec une MTU _par dĂ©faut_ ancestrale et/mais une [PMTU](https://fr.m.wikipedia.org/wiki/Path_MTU_discovery) ne fonctionne pas dans la plupart des cas pour cause de rĂ©ponse ICMP plus ou moins autorisĂ©e ou traitĂ©e, et oĂč la segmentation en paquets devient parfois et malgrĂ© tout un goulot d’étranglement. GRO semble supĂ©rieur au couple LSO‐LRO et est maintenant gĂ©rĂ© par de nombreuses cartes rĂ©seaux. ConcrĂštement, un ensemble de paquets UDP va traverser la pile en une seule unitĂ©, faisant ainsi une seule transaction pour l’espace utilisateur, et ceci sans modifier ni fusionner lesdits paquets UDP de l’ensemble. ## SystĂšmes de fichiers ### BinderFS On note l’arrivĂ©e de BinderFS, un pseudo‐systĂšme de fichiers dĂ©diĂ© pour l’IPC « _binder_ » d’Android. [Binder](https://source.android.com/devices/architecture/hidl/binder-ipc) est un dispositif ancien dans Android, et depuis Android _O_ (Oreo, en 2017) toute la communication avec la HAL (_hardware abstraction layer_) et le cadriciel Android se fait avec lui, et des amĂ©liorations importantes ont Ă©tĂ© apportĂ©es, notamment avec l’utilisation des [entrĂ©es‐sorties vectorisĂ©es](https://en.wikipedia.org/wiki/Vectored_I/O). « Qui contrĂŽle l’IPC contrĂŽle le Droid ». Le problĂšme avec Binder est qu’il n’existe pas en tant que module pour le noyau _vanilla_ (AOSP uniquement), d’une part, et d’autre part le nombre de _devices_ disponibles est fixĂ©... Ă  la compilation. L’objectif de BinderFS sur Linux est de permettre l’utilisation de Binder dans des espaces de noms d’IPC (_IPC namespace_), donc de pouvoir en avoir plusieurs en mĂȘme temps, isolĂ©s les uns des autres, et de permettre l’allocation dynamique du nombre de _devices_ disponibles. Pour mĂ©moire, _IPC namespace_ a apportĂ© la capacitĂ© d’utiliser des IPC (communications inter‐processus) Ă  l’intĂ©rieur d’un espace de noms, donc de les isoler pour y proposer un nombre restreint et privĂ© d’objets IPC. Le cas typique d’usage est l’utilisation de conteneurs. Chaque nouvel espace de noms d’IPC va ici pouvoir monter une nouvelle instance de BinderFS, disposant donc de son propre dispositif de contrĂŽle Binder ! Avec tout ce que propose ce fameux ``/dev/binder-control``, isolĂ© et sans limite fixĂ©e sur le nombre de _devices_. Il est ainsi possible de lancer plusieurs couches Android simultanĂ©ment, sur un mĂȘme noyau et _vanilla_. Sans couche de virtualisation, juste comme ça. « C’est fou ! » « Oui, mais vous aimez ». ### Adiantum [Adiantum](https://security.googleblog.com/2019/02/introducing-adiantum-encryption-for.html) fait son apparition, il s’agit de chiffrement pour des appareils ne disposant pas des instructions AES (typiquement les tĂ©lĂ©phones que l’on trouve dans les pays dit Ă©mergents). C’est une bonne nouvelle pour nos amis là‐bas ! ### Btrfs Btrfs dispose maintenant de la gestion de l’espace d’échange mĂ©moire (_swap_), et non [ce n’est pas une blague](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ed46ff3d423780fa5173b38a844bf0fdb210a2a7). ### CIFS/SMB Du cĂŽtĂ© de [CIFS](https://fr.wikipedia.org/wiki/Server_Message_Block), c’est l’arrivĂ©e du cache et du _failover_ (basculement) pour le DFS (_Distributed File System_, systĂšme distribuĂ© de fichiers sous CIFS), permettant aux clients de se reconnecter de maniĂšre transparente Ă  un autre serveur CIFS, servant le ou les mĂȘmes montages, si le premier serveur utilisĂ© n’est plus disponible. Pour mĂ©moire, il s’agit d’une des deux fonctions essentielles apportĂ©es par DFS, avec le balancement de charges entre serveurs. Le DFS (cĂŽtĂ© Windows) propose en plus une tambouille de liens symboliques pour prĂ©senter Ă  l’exportation une autre racine que la racine rĂ©elle (rendant ainsi la vue cĂŽtĂ© client diffĂ©rente d’un client Ă  un autre si l’administrateur le veut). Et CIFS, dans ses attributs Ă©tendus (_xattr_), dispose (enfin ?) d’un assemblage (_compound_), permettant ainsi de rĂ©duire la charge rĂ©seau (diminution des aller‐retours d’informations : on embarque tout dans une seule requĂȘte de plus grande taille) et d’amĂ©liorer les performances CIFS pour ce point. ### AutoFS Un changement qui devrait avoir toute votre attention concernant AutoFS : le retour de l’option ``strictexpire``. Elle rĂ©solvait un problĂšme lorsque les auto‐montages n’expirent pas, par exemple avec des accĂšs « agressifs » (comprendre : normaux) par les clients. Ce correctif a ensuite Ă©tĂ© retirĂ© car il entrainait, dans de larges environnements avec de nombreux clients, de nombreuses requĂȘtes inutiles de montage donc une charge importante pour le serveur (quand les clients Ă©taient laissĂ©s en configuration par dĂ©faut avec une valeur par dĂ©faut pour le temps sans accĂšs avant dĂ©montage). [Ce correctif](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f5162216b7dab0c07e070b8b7f98891a85047f59) marque le retour de cette option. ## Virtualisation CĂŽtĂ© Virtualisation on notera entre autres : - l’arrivĂ©e de la fonction « _Processor Trace_ » d’Intel dans KVM, pour ses machines virtuelles invitĂ©es ; la gestion d’[IPT](https://software.intel.com/en-us/blogs/2013/09/18/processor-tracing) date de plusieurs annĂ©es et permet de tracer l’activitĂ© (d’une application, par exemple) sans surcoĂ»t pour les performances, elle est maintenant mise Ă  disposition pour la virtualisation ; - pas mal d’amĂ©liorations pour [[VirtIO]] : - prise en charge de la configuration du _Large Receive Offload_ (LRO, approche similaire aux _Jumbos Frames_), l’ajout de la gestion du _discard_ (_trim_) sur le pilote [virtio_blk](https://github.com/oasis-tcs/virtio-spec) et l’activation lorsque le pĂ©riphĂ©rique dĂ©clare ces options, - l’ajout de la gestion l’EDID (petit binaire contenu dans chaque Ă©cran et envoyĂ© au systĂšme pour dĂ©clarer ses caractĂ©ristiques) pour le pilote _virtio_gpu_, - la modification du cĂŽtĂ© de la [synchronisation](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2cd7b6f08bc4cf06d1f00f8b42720a8457861ca1) avec un descripteur de fichier sync_file renvoyĂ© Ă  l’espace utilisateur, comprenant l’appel de fin de synchronisation reçu ; - l’ajout du « _[dirty log reprotect](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a31b9db153530df4aa02dac8c32837bf5f47019)_ » pour KVM : l’idĂ©e semble ĂȘtre de libĂ©rer le verrou _mmu_lock_ le plus tĂŽt possible, pour cela le _get_dirty_log_ n’envoie plus de page protĂ©gĂ©e en Ă©criture, c’est l’espace utilisateur qui se charge de nettoyer avant usage des nouvelles infos prĂ©sentĂ©es. # Statistiques Nous vous invitons simplement Ă  lire les [informations](https://lwn.net/SubscriberLink/780271/1c72a381ae6c478e/) collectĂ©es par Jonathan Corbet pour _LWN.net_ pour la RC-7. L’Europe arrive largement en tĂȘte. # Autour du noyau Du cĂŽtĂ© de la Fondation Linux, qui s’occupe de bien d’autres choses que du noyau, les nouvelles les plus rĂ©centes sont : - pas moins de [22 nouveaux](https://www.linuxfoundation.org/press-release/2019/01/the-linux-foundation-welcomes-22-new-members-from-cloud-energy-security-and-semiconductor-industries-2/) membres rejoignent la Fondation ; - le [Projet ELISA](https://elisa.tech/), _Enabling Linux In SAfety critical systems_, est lancĂ© ; un effort commun (BMW, Toyota, Linutroniks et KUKA viennent de rejoindre le projet) afin de simplifier le dĂ©veloppement d’applications critiques (oĂč la vie humaine peut ĂȘtre en jeu) basĂ©es sur le noyau Linux ; le but n’est pas une nouveautĂ© en soi, il s’agit d’une nouvelle alliance ouverte ; - Automotive Grade Linux, autre alliance ouverte, [publie une API](https://www.linuxfoundation.org/news/2019/03/automotive-grade-linux-releases-open-source-speech-recognition-apis/) pour la reconnaissance vocale ; - lancement de l’[_Academy Software Foundation_](https://www.aswf.io/) par la Fondation Linux et l’« _Academy of Motion Picture Arts and Sciences_ », comprenant entre autres Animal Logic, Autodesk, Blue Sky Studios, Cisco, DNEG, DreamWorks Animation, Epic Games, Foundry, Google Cloud, Intel, SideFX, The Walt Disney Studios, et Weta Digital. Que du beau monde ? ;-) Pour terminer ============= Un nouvel utilitaire permet la production d’un fichier ``configure_commands`` au format JSON. À l‘instar de _libtooling_ du projet Clang/LLVM et de ce que font des outils tels que CMake ou Bazel, cet utilitaire va chercher les \.o.cmd dans l’arborescence du noyau (contenant l’ensemble des informations nĂ©cessaires Ă  la compilation), en extrait ces commandes de compilation et produit un fichier en sortie unique ``compile_commands.json`` qui pourra ĂȘtre utilisĂ© Ă  loisir par tout outil basĂ© sur la _libtooling_. ``make config; make -j$(nproc); scripts/gen_compile_commands.py``.

AltStyle ă«ă‚ˆăŁăŠć€‰æ›ă•ă‚ŒăŸăƒšăƒŒă‚ž (->ă‚ȘăƒȘă‚žăƒŠăƒ«) /