URL: https://linuxfr.org/news/sortie-du-noyau-linux-4-7 Title: Sortie du noyau Linux 4.7 Authors: Collectif Davy Defaud, jcr83, Tiwaz, M5oul, Yves Bourguignon, goernil, Anonyme, Xavier Vello, BAud, esdeem, alpha_one_x86, ZeroHeure, palm123, Benoît Sibaud, rpnpif, Adrien Dorsaz, superna, David_5.1, Albert_, Olivier Esver, leowzukw, guitou, Nils Ratusznik, gusterhack, patrick_g, Christophe, Dreamkey, david.g, romrom, Chris K. et rogo Date: 2016年05月14日T23:41:27+02:00 License: CC By-SA Tags: noyau_linux, coulisses, sortie_version, linus_torvalds et lwn Score: 61 La sortie de la version stable 4.7 du noyau Linux a été annoncée le dimanche 24 juillet 2016 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site [_kernel.org_](http://kernel.org). Le [noyau a fêté ses 25 ans le 25 août 2016](//linuxfr.org/users/jylog/journaux/le-noyau-linux-a-25-ans) \o/. Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche (qui est sous [licence CC BY-SA](http://creativecommons.org/licenses/by-sa/3.0/deed.fr)). ---- [Dépêches des noyaux précédents](https://linuxfr.org/wiki/depeches_noyau) [Site officiel du noyau Linux](https://www.kernel.org) [Les nouveautés du noyau 4.7](https://kernelnewbies.org/Linux_4.7) ---- # TL;DR - gestion du processeur graphique Radeon RX 480 (nouvelle architecture d’AMD appelée *Polaris*) ; - Nouveau gestionnaire de fréquence dynamique du processeur (*schedutil*) ; - lecture en parallèle du contenu des répertoires, avec un gain de performance dans quelques rares situations ; - amélioration des outils de contrôle et surveillance (histogrammes d’événements dans `ftrace`, pile d’appels dans `perf trace`, *tracepoints* dans [BPF](https://fr.wikipedia.org/wiki/BSD_Packet_Filter)) ; - intégration du mécanisme `sync_file`, issu d’Android, qui permet une synchronisation explicite avec l’espace utilisateur. # En bref Les grandes nouveautés du noyau Linux 4.7 sont la gestion du processeur graphique Radeon RX 480 d’AMD, qui, bien sûr, a été directement implémentée dans le pilote AMDGPU, un nouveau module de sécurité appelé `LoadPin`, qui s’assure que les modules chargés par le noyau sont tous originaires du même système de fichiers, et la gestion des contrôleurs de périphériques USB virtuels USB/IP. De plus, il s’agit de la première version du noyau à être prête pour le mécanisme de clôture `sync_file` utilisé dans les systèmes d’exploitation mobiles Android, qui permet au programme Berkeley Packet Filter (BPF) de s’attacher aux points de dépistage (_trace points_), aussi bien que le longuement anticipé gestionnaire de fréquence dynamique du processeur _schedutil_, qui promet d’être plus rapide et plus précis que les existants. Les nouvelles fonctionnalités sont les suivantes : gestion de la consultation parallèle des répertoires, possibilité de créer un histogramme des évènements avec l’interface `ftrace`, gestion des appels en chaîne avec l’outil de traçage `perf` et gestion de la mise à jour du micrologiciel en utilisant le mécanisme EFI « Capsule ». Comme d’habitude, de nombreux pilotes ont été mis à jour et de nombreux bogues ont été résolus. À noter l’ajout dans le noyau de la gestion des manettes de la Xbox One de Microsoft et du Thunderbolt d’Apple/Intel (Interface qui combine PCI Express et [[DisplayPort]]). # Annonces des versions candidates par Linus Torvalds ## RC-1 La version [RC-1](https://lkml.org/lkml/2016/5/29/77) est sortie le 29 mai 2016 :> Habituellement, je ferme la fenêtre d’intégration le dimanche après‐midi, mais je suis connu pour être embêté par les traînards et tout fermer un jour en avance. Cette fois‐ci, pour mettre un peu de piment, j’ai tout simplement décidé de publier un dimanche matin à la place.>> [Et, oui, avant que vous ne me le demandiez, ma vie est vraiment ennuyeuse, si c’est ça « mettre un peu de piment ».]>> Cette publication matinale est en partie due au fait que je n’ai rien en attente, que je sache (et s’il y avait quelqu’un qui avait prévu d’envoyer ses changements de dernière minute cinq minutes avant l’habituelle publication de l’après‐midi, ça m’est égal). Et en partie parce que je pense que cela a été une bonne fenêtre d’intégration et que nous avons beaucoup de nouveau code pour la fermer.>> Et je ne dis pas ça parce que la fenêtre d’intégration de la 4.7 est particulièrement grosse — elle a l’air plutôt normale et résolument plus petite que ne le fut la 4.6. Nous avons toutes les habituelles mises à jour de pilotes, cependant cette fois‐ci nous avons un assez gros changement dans la couche VFS qui autorise les systèmes de fichiers (s’ils adoptent cette façon de faire) à utiliser `readdir()` et la recherche en parallèle des éléments du chemin d’accès dans le même répertoire.>> C’est probablement le plus gros changement conceptuel de VFS que nous ayons eu depuis que nous avons commencé à faire la résolution de chemin d’accès en cache en utilisant [RCU](https://en.wikipedia.org/wiki/Read-copy-update "Read Copy Update").>> Cela dit, les changements de _code_ pour tout ça sont plutôt petits et ils sont éclipsés par toutes les habituelles mises à jour de pilotes. En fait, aucune des mises à jour des systèmes de fichiers ne pointe dans les habituelles « statistiques de répertoires » (parce que les stats de répertoires de `git` coupent les trucs à 3 %). Donc, quand on arrive au gros du travail, nous avons l’habituelle distribution : environ deux tiers des pilotes (processeurs graphiques et réseau dominent, mais il y en a d'autres) et le reste est principalement des mises à jour d’architectures, de la documentation et du « divers » (où se cachent les changements de VFS).>> Même si ce n’est pas une énorme publication, elle est certainement assez grosse pour que même le journal abrégé soit beaucoup trop gros pour le poster ou le lire afin d’avoir une vue d’ensemble, je joins donc mon habituel résumé des intégrations. Et, en tant que tel, souvenez‐vous que les gens crédités sont les gens pour qui je pousse les demandes de changements, ce qui n’est pas forcément le cas de tous les gens qui ont véritablement écrit le code.>> Juste pour donner aux gens une idée de la disparité entre la liste de mainteneurs ci‐dessous et le nombre de gens soumettant des correctifs, il y a environ 1 400 auteurs en tout pour les trucs qui sont arrivés pendant la fenêtre d’intégration.>> Bref, assez de bla‐bla. Allez‐y, testez. Et, en particulier, si vous êtes une personne du système de fichiers bas niveau ou impliquée d’une autre manière dans la recherche d’éléments de chemins d’accès (couche de sécurité, etc.), allez‐y, testez si tout a l’air OK. Et si votre système de fichiers n’est pas un de ceux qui font déjà des recherches ou des lectures de répertoires en parallèle (à cause de problème de blocage), jetez‐y un œil aussi.>> Linus ## RC-2 La version [RC-2](https://lkml.org/lkml/2016/6/5/351) est sortie le 5 juin 2016 :> C’est dimanche après‐midi, c’est donc le moment d’une version candidate !>> Les choses semblent assez normales et il y a des corrections partout, avec du code pour les pilotes et les architectures qui mènent la charge comme d’habitude, mais il y a des trucs épars dans tous les coins, y compris les systèmes de fichiers, le réseau, MM, les bibliothèques de simplification [_helper libraries_], etc., etc.>> Il y a quand même une régression NFS en cours, mais personne, en dehors de certains tests de résistance explicites, ne l’a remarquée, donc j’ai fait une RC-2 malgré la connaissance du problème. Je recevrai une demande d’intégration d’Al plus tard et on réparera ça pour la RC-3. En attendant, je compte sur les rares personnes qui auraient rencontré le problème pour faire du test de résistance sur les systèmes de fichiers et pour d’ores et déjà tester le correctif.>> Il y a une non‐correction en retard que j’ai prise bien que la fenêtre d’intégration soit fermée, parce que je la voulais depuis un moment. Je doute que quiconque remarque le résultat effectif d’un nettoyage/changement de PTY, ce qui signifie que notre vieille et dégoûtante option de configuration du noyau `DEVPTS_MULTIPLE_INSTANCES` a disparu, parce que le nettoyage fait qu’elle n’est plus nécessaire. Nous étions dans une situation où certaines distributions voulaient cette option désactivée pour des raisons historiques et d’autres la voulaient activée pour un comportement moderne. Le comportement de notre `/dev/ptmx` a été nettoyé et corrigé de sorte que ça _juste marche_TM dans les deux cas, et cette vilaine verrue a simplement disparu. De plus, le code est de toute façon plus propre.>> Je mentionne cette non‐correction probablement essentiellement parce que je me sens un peu coupable de l’avoir intégrée, puisque j’aurais probablement crié sur un des sous‐mainteneurs qui aurait tenté d’appeler ce nettoyage un correctif retardataire. _[Quod licet Iovi](https://en.wikipedia.org/wiki/Quod_licet_Iovi,_non_licet_bovi)_, et tout le toutim... Mais en réalité, pas d’excuses, à part « en définitive ».>> Peu importe, il y a donc un peu de tout et c’est suffisamment petit pour que vous puissiez éplucher le journal résumé ci‐joint pour les détails.>> Linus ## RC-3 La version [RC-3](https://lkml.org/lkml/2016/6/12/124) est sortie le 12 juin 2016 :> Vous connaissez tous la rengaine, alors chantez maintenant : « nouvelle semaine, nouvelle RC ».>> Rien de particulièrement notable cette semaine. Comme promis, la RC3 contient le correctif pour le problème NFS qui était en suspens dans la dernière RC, que personne ne semble avoir remarqué (comme prévu également).>> Les statistiques de modifications semblent plutôt normales et inoffensives. Il y a plus de composants de systèmes de fichiers que d’habitude, mais ce sont majoritairement des ajouts de tests de btrfs et, si vous ignorez cette partie, ce sont tous les trucs habituels : les pilotes dominent (processeurs graphiques et réseau en constituent la majeure partie, mais il y a de l’[I2C](https://fr.wikipedia.org/wiki/I2C "Inter‐Integrated Circuit"), du [RDMA](https://en.wikipedia.org/wiki/Remote_direct_memory_access "Remote direct memory access")...) avec quelques mises à jour d’architectures et du code réseau général. Et les habituels trucs épars partout. Mais tout cela est assez petit. Le journal abrégé est joint pour les gens qui aiment avoir un rapide aperçu des détails.>> Linus ## RC-4 La version [RC-4](https://lkml.org/lkml/2016/6/20/5) est sortie le 19 juin 2016 :> Ça a été une semaine assez normale et la RC-4 est sortie. Allez la tester.>> Les statistiques ont l’air très normales : environ deux tiers de pilotes et le reste est constitué pour moitié des mises à jour d’architectures et pour l’autre moitié de « divers » (petites mises à jour des systèmes de fichiers, un peu de documentation et une poignée de corrections par ailleurs).>> Le gros des mises à jour de pilotes sont pour l’USB et les pilotes graphiques, mais il y a aussi l’[IIO](https://wiki.analog.com/software/linux/docs/iio/iio "Linux Industrial I/O Subsystem"), les [DEL](https://fr.wikipedia.org/wiki/Diode_%C3%A9lectroluminescente "Diode électroluminescente"), les pilotes de plates‐formes, le [DMA](https://fr.wikipedia.org/wiki/Acc%C3%A8s_direct_%C3%A0_la_m%C3%A9moire "Direct Memory Access — Accès direct à la mémoire"), etc.>> Les mises à jour d’architectures sont surtout destinées aux machines ARM, mais il y a aussi quelques petites corrections pour x86.>> Mais tout ça est assez petit, rien de particulièrement inquiétant.>> Le journal abrégé est joint pour les gens qui veulent avoir un aperçu du genre de choses qui se sont passées.>> Linus ## RC-5 La version [RC-5](https://lkml.org/lkml/2016/6/26/350) est sortie le 26 juin 2016 :> Nouvelle semaine, nouvelle RC.>> Hum. Je pense que ça se calme, bien qu’avec deux tiers des modifications arrivés à partir de vendredi matin, cela ne semble pas le cas — mes vendredis finissent par être très occupés. Mais à bien regarder les chiffres, nous en sommes là où nous sommes habituellement à ce stade des RC.>> Les statistiques sont tout à fait normales : une moitié de pilotes, un quart de mises à jour d’architectures et le reste de divers : systèmes de fichiers, ordonnanceur, gestion de la mémoire, etc.>> Les mises à jour de pilotes concernent surtout les pilotes graphiques, mais aussi RDMA, hwmon, Xen, [GPIO](https://fr.wikipedia.org/wiki/General_Purpose_Input/Output "General Purpose_Input/Output") et son.>> Du côté des architectures, PowerPC, x86, un peu d’ARM64, et un peu de bruit un peu partout dû au nettoyage de la gestion de la mémoire.>> Allez‐y, testez. Avec la RC-5, nous devrions commencer à être pratiquement prêts.>> Et, s’il vous plaît, si Thorsten Leemhuis suit une de vos régressions, pouvez‐vous vérifier et revérifier si elle demeure ? C’est plaisant de disposer à nouveau d’un suivi des régressions, mais il serait bien également de s’assurer que celles qui sont réglées soient fermées.>> Linus ## RC-6 La version [RC-6](https://lkml.org/lkml/2016/7/4/40) est sortie le dimanche 3 juillet 2016 :> Hum... Une autre semaine, une autre RC.>> J’aimerais vraiment dire que ça se calme et que l’on se rapproche, mais ce serait un mensonge. >> Ce n’est pas comme si c’était une énorme RC, mais elle est vraiment plus grosse que les RC précédentes. Je ne pense pas que ce soit réellement un gros problème, car il semblerait que ce soit plutôt dû au calendrier. Nous venons d’avoir des fusions en provenance de la plupart des sous-systèmes (par exemple, le réseau de Davem et tous les sous‐systèmes de pilotes de périphériques habituels de Greg, sans parler des mises à jour des pilotes graphiques et de tous les autres mainteneurs de sous‐systèmes). Mais le réseau (à la fois les pilotes et le code principal) est la partie la plus notable. >> Les détails sont, comme d’habitude, dans le journal résumé ci‐joint.>> Attendons de voir comment ça se passe la semaine prochaine. Un pur hasard ou l’émergence d’une mauvaise tendance ?>> Linus ## RC-7 La version [RC-7](https://lkml.org/lkml/2016/7/10/219) est sortie le dimanche 10 juillet 2016 :> Nous avons eu une semaine bien calme, ce que j’attendais — la dernière RC était plus grosse uniquement en raison de problèmes d’aléas de calendrier et non un changement inquiétant à ce moment du cycle de sortie. Ouf.>> Quoi qu’il en soit, il y a quelques régressions encore en cours d’observation, mais à moins que quelque chose de bizarre ne survienne, ce sera la dernière RC. Cependant, en raison du calendrier de mes voyages, je ne ferai pas la version finale 4.7 la semaine prochaine et les gens auront deux semaines pour rapporter (et corriger) les bogues restants.>> Oui, c’est votre chance. Mon calendrier de travail ne va pas mettre le bazar, voyez plutôt cela comme si vous aviez une SEMAINE DE BONUS ! Ouais !>> Bon d’accord, mon calendrier de travail _va_ probablement mettre le bazar pour quelqu’un et je m’en excuse d’avance. Mais, bon, même ce délai bien planifié peut évidemment changer, si quelqu’un trouve un vrai bogue tueur. Mais ça ne semble pas du tout le cas, vu que le cycle de sortie n’a pas été particulièrement gros ou effrayant.>> Mais, allez donc le tester. Le journal abrégé donne les détails sur ce qui s’est passé durant cette calme semaine, mais globalement tout est très normal : deux tiers de pilotes (réseau, son, GPIO et divers), avec le reste partagé à peu près équitablement entre des corrections d’architectures et du « divers » (en l’occurrence, principalement le cœur du noyau, du réseau et _eCryptfs_). Mais tout cela est plutôt petit.>> Linus ## Version finale La [version finale](http://lkml.iu.edu/hypermail/linux/kernel/1607.3/00150.html) est sortie le dimanche 24 juillet 2016 :> Donc, après un léger retard dû à mes voyages, je suis de retour et la version 4.7 est sortie.>> Bien que la RC-7 soit sortie il y a deux semaines, les correctifs [finals](https://fr.wiktionary.org/wiki/finals) n’étaient pas si conséquents que ça et la majorité d’entre eux étaient triviaux — souvent d’une ou quelques lignes. Il y a eu quelques pilotes réseau qui ont reçu plus d’attention. En annexe, le journal des modifications depuis la RC-7, pour les personnes intéressées : c’est plutôt varié, avec du réseau, des correctifs sur le processeur graphique Intel Kabylake pour les plus notables. Il y a également eu de petites retouches un peu partout.>> Et, bien entendu, ça signifie que la fenêtre d'intégration pour la version 4.8 est ouverte. D’après le contenu de `linux-next`, ça va être une plus grosse version que l’actuelle (la version 4.7 a été vraiment calme, la faute en revient au moins en partie à l’été dans l’hémisphère nord).>> Linus # Les nouveautés ## Architecture #### CPUFreq et PState Le noyau 4.7 ajoute une nouvelle option de gestion de fréquence (_schedutil_) plus « intelligente », qui utilise des informations plus précises et permet une latence plus faible en cas de modification de charge pour effectuer ses changements de fréquence. Malgré sa relative simplicité, ce mode propose déjà des résultats encourageants. Le travail effectué ici pose les bases pour des traitements futurs plus efficaces. ### Gestion de la mémoire Les tâches de compression _async_ ont vu leurs latences réduites, ce qui est utile sur les systèmes n’ayant plus assez de mémoire et cherchant à optimiser la mémoire allouée. Dans cet ordre d’idée, l’OOM (_Out of Memory killer_), a été amélioré pour être plus fiable (_cf._ [explications en anglais sur _LWN.net_](https://lwn.net/Articles/668126/)). L’ordonnanceur SLAB dispose d’une nouvelle option _CONFIG_SLAB_FREELIST_RANDOM_ pour améliorer la sécurité en ajoutant de l’aléatoire pour les allocations. Cela permet de rendre moins prédictibles ces dernières, et ainsi de compliquer la tâche d’exploitation des débordements de pile. ### ARM #### Nouveaux systèmes monopuces gérés : - Oxford Semiconductor OX810SE (comme discuté [_ici_](http://linuxfr.org/users/superna/journaux/tentative-d-upgrade-d-un-vieux-nas-sous-arm-linux-episode-2)) ; - Qualcomm IPQ4019. #### Nouvelles cartes gérées : - Aspeed ast2500/ast2400 ; - TI dra72-evm rev C (SR2.0) ; - Western Digital _My Book World Edition_ (basé sur OX810SE) ; - Amazon _Kindle Fire_ (première génération) _codename_ kc1 ; - Arrow Electronics DB600c (basé sur Qualcomm APQ8064) ; - Embest MarS, Ka-Ro _MB7_ + modules + TXUL, pico-hobbit (basés sur i.MX6) ; - Nitrogen6_MAX QP / Nitrogen6_SoloX (basés sur i.MX6) ; - Baltos IR2110/IR3220 ; - ICEv2 basé sur AM33X ; - MPS2 AN385/AN386/AN399/AN400 ; - Linksys EA4200v2/EA4500 ; - KuroBox-Pro (basé sur orion5x) ; - MiQi de mqmaker (basé sur Rockchip) ; - Samtec VIN|ING ; - tablettes Dserve DSRV9703C, Difrence DIT4350, Colorfly e708 q1, Polaroid MID2809PXE4 (basés sur systèmes monopuces Allwinner) ; - carte de développement ZII ; - IPQ4019 DK01 ; - [Google Pixel C](https://pixel.google.com/pixel-c/). #### Allwinner - A13/R8 : gestion du moteur d’affichage (DE) ;: - A10/A20 : prise en charge du [S/PDIF](https://fr.wikipedia.org/wiki/S/PDIF) ; - A31/A23/H3 : Amélioration de la gestion de l’audio ; - H3 : gestion de l’USB ; - tablettes : [Dserve DSRV9703C](https://nl.hardware.info/product/157078/dserve-dsrv-9703c/reviews), Polaroid MID2809PXE4, [Colorfly e708 q1](http://www.androidetvous.com/2014/01/23/test-colorfly-e708-q1-tablette/), [Difrence DIT4350](http://www.difrnce.nl/products-page/tablets/4-3-tablet-tablets/difrnce-dit4350-tablet/) ; - cartes : [Olimex A20 OLinuXino LIME2](https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXIno-LIME2/open-source-hardware), [_Orange Pi 2_](http://www.orangepi.org/orangepi2/), [_Orange Pi One_](http://www.orangepi.org/orangepione/), et l’[_Orange Pi PC_](http://www.orangepi.org/orangepipc/). #### Rockchip - cartes : [_Geekbuying GeekBox_](http://www.geekbuying.com/item/GeekBox-Open-Source-Cross-TV-BOX-Android-Ubuntu-Dual-Boot-4K-RK3368-Octa-Core-2G-16G-AC-WIFI-1000M-LAN-BT4-1-HDMI2-0-OTG-358067.html), [RK3399 _Evaluation Board_](http://www.minimachines.net/actu/deux-nouveaux-soc-ultrahd-chez-rockchip-rk3229-et-rk3399-37302), [mqmaker MiQi SBC](http://liliputing.com/2016/04/miqi-is-a-35-single-board-computer-with-rockchip-rk3288.html). #### Amlogic - carte : [Hardkernel ODROID-C2](http://www.hardkernel.com/main/products/prdt_info.php). #### Samsung - pilote générique Exynos de gestion de la fréquence du bus ; - prise en charge du [ARTIK5](https://developer.trustonic.com/blog/artik5-firstlook) ; - ajout d’un régulateur pour la eMMC/SD des cartes [ODOID XU3 et XU4](http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825) ; - corrections et nettoyages divers. #### Qualcomm - ajout de la gestion du BQ27541 du Nexus 7 ; - meilleure prise en charge du [96Boards HiKey](http://www.96boards.org/product/hikey/) (Kirin 620) dans le DT ; - ajout du Qualcomm IPQ4019 (« _Internet processor_ ») ; - gestion des cartes [_Arrow DragonBoard 600c_](http://www.cnx-software.com/2016/05/08/qualcomm-dragonboard-600c-96boards-development-board-includes-ethernet-and-sata/) de [_96boards_](http://www.96boards.org/) (Snapdragon 600). #### Mediatek - pilotes graphiques pour Mediatek MT8173 (DRM). ### MIPS - ajout de la gestion de la délocalisation du noyau, permettant ainsi de passer outre la limitation de 1 Mio ; - ajout du KASLR grâce à la gestion de la délocalisation ; - ajout des compteurs de performances (_perf counters_) ; - gestion de la ligne de commande étendue ; - ajout de la prise en charge de DPT-Module, Dragino MS14 (Dragino 2) et Onion Omega ; - ajout de la gestion de BCM6358, Whirlwind (BMIPS5200) et BCM63268 ; - ajout d’un essai préliminaire pour les Loongson 3A ; - ajout de la prise en charge des CN73xx, CN75xx et CN78xx ; - ajout de la prise en charge du D-Link DSR-1000N ; - ajout de la détection du DSP v3, et du MIPSr6 (processeur virtuel) ; - gestion de l’envoi de SIG_SYS à l’espace utilisateur 32 bits depuis un noyau 64 bits. ## Développement ### USB/IP [Ce projet](http://usbip.sourceforge.net) déjà mature, est enfin intégré comme système à part entière dans le noyau. Il permet de partager de manière générique des périphériques USB à travers le réseau. Techniquement, cela n’est qu’***une*** encapsulation des trames d’entrées‐sorties dans des trames TCP. Il y a deux parties à ce projet, une côté serveur qui permet de mettre à disposition les périphériques USB connectés à l’hôte, et l’autre, côté client, qui permet de se connecter au serveur et de connecter des périphériques USB comme s’ils étaient en accès direct. Si le serveur est pour le moment réservé à Linux, le client est également disponible pour Windows, permettant ainsi à ce dernier l’accès à des périphériques présentés par le serveur. Cette fonction vient avec deux outils : *usbip* et son _daemon_, *usbipd* : - usbip attach remote=host ; - usbip detach port=port ; - bind --busid=<_busid_> ; - unbind --busid=<_busid_> ; - list --remote=host ; - list --local ; ### Hist Trigger Cette nouvelle fonctionnalité de traçage permet d’ajouter la création d’histogrammes de manière efficiente et personnalisée. [Le _blog_ de Brendan Gregg](http://www.brendangregg.com/blog/2016-06-08/linux-hist-triggers.html) explique bien cette fonctionnalité et son fonctionnement. Le répertoire `/sys/kernel/debug/tracing/events/` contient un ensemble d’éléments qu’il est possible de tracer : - `probe_libc/malloc/` va par exemple permettre de tracer la fonction `malloc()` ; - `raw_syscalls/sys_enter/` va, par exemple, permettre de tracer l’ensemble des appels système. Pour activer les histogrammes sur ces exemples, positionner le déclancheur correctement, `hist:key=common_pid.execname`, par exemple. Cela permet pour la durée du traçage, de récupérer le nombre d’appels pour chaque numéro de processus et nom d’exécutable. Cette fonction, qui a pour nom **CONFIG_HIST_TRIGGERS** n’est pas activée par défaut. ## Pilotes graphique libres ### AMDGPU Ajout de la prise en charge des processeurs graphiques _Polaris_ dans _amdgpu_, notamment avec la prise en charge de sa première implémentation, la carte [Radeon RX 480](http://www.amd.com/fr-fr/products/graphics/radeon-rx-series/radeon-rx-480). _cf._ . ## Réseau ### Pilotes Le pilote _w5100_ prend désormais en charge le mode série (SPI) pour les cartes réseau basées sur les contrôleurs Wiznet W5100 et W5500. ### Bufferbloat Le _bufferbloat_ est défini comme l’excès de mise en tampon (_buffering_) des paquets, ce qui conduit à de fortes latences, une surconsommation processeur et un faible débit réseau. La méthode `fq_codel_drop()` n’est pas optimale, elle effectue un balayage sur 4 Kio pour trouver un _fat flow_ au lieu de supprimer un simple paquet. Sur une charge engorgée (_flood_) de 900 Mbits, nous passons d’une consommation processeur de 88 % à moins de 10 %. ### Autre #### Partial segment offloading [_explications_]( https://patchwork.ozlabs.org/patch/599734/) L’idée est d’élargir la GSO à une gamme plus large de périphériques, d’avoir des en‐têtes fixes et de faire en sorte que le matériel gère seulement la segmentation de l’en‐tête interne. #### TCP préemptible La couche réseau TCP est maintenant préemptible, ce qui permet de la mettre en pause sur l’opération potentiellement bloquante et de récupérer du temps processeur, pour essayer de lutter contre les « pics de latence fous ». #### RPS et RFS Le protocole _Stream Control Transmission Protocol_ ([SCTP](https://fr.wikipedia.org/wiki/Stream_Control_Transmission_Protocol)) prend en charge le RPS (_Receive Packet Steering_) et RFS (_Receive Flow Steering_) pour améliorer la montée en charge sur plusieurs processeurs. ### Socket Optimisation du bit _ASYNC_ pour les _sockets_. ## Sécurité ### LoadPin Un nouveau module de sécurité a été introduit dans cette version. Ce dernier permet de restreindre la provenance des fichiers chargés par le noyau (micrologiciels, modules...). Il s’assure que tous les modules viennent d’un même et unique système de fichiers et que ce dernier est intègre et inaltérable. ### Clefs de chiffrement - ajout de fonction en espace utilisateur pour l’accès aux calculs de Diffie‐Hellman via l’appel système _KEYCTL_DH_COMPUTE_ ; - ajout d’aide pour une gestion simplifiée des clefs, avec une plus grande facilité de définition des règles de vérification ; - les grandes clefs sont désormais stockées avec chiffrement. ### Divers - ajout d’un champ *tty* à l’événement d’ouverture de session (_LOGIN_). Cela permet ainsi de savoir depuis quel terminal la tentative d’ouverture de session est effectuée. ## Systèmes de fichiers ### Recherche parallèle dans les dossiers Cette optimisation permet d’accélérer la recherche de tâches concurrentes pour trouver plusieurs dossiers sur le disque ; les performances et la consommation processeur devraient être meilleures sous forte charge (passage de _mutex_ à des sémaphores lecture‐écriture). La plupart des systèmes de fichiers sont concernés. ### ext4 Pas mal de corrections dont un crash potentiel quand un fichier journalisé a une mauvaise allocation différée et qu’elle n’a pas encore été écrite. Correction de problèmes lors du manque d’espace disque. Correction pour DAX (_direct access_ : supprime la copie supplémentaire en lisant et écrivant directement dans le périphérique de stockage). La lecture de grands répertoires avec de nombreux blocs vides prenait du temps et agaçait avec les longs temps d’attente. Désormais, l’utilisateur ou l’ordonnanceur pourront interrompre le processus de lecture. ### F2FS Diverses corrections de sécurité, de bogues et améliorations des performances (surtout du côté des allocations). ### XFS Correction, nettoyage, améliorations mineures (_cf._ _Système de blocs_ ci‐dessous). ### Btrfs Beaucoup de corrections, surtout pour les différents systèmes de synchronisation qui permettent aux applications d’être sûres que l’écriture a été faite sur le disque. La compatibilité avec OverlayFS est enfin réalisée, grâce à la prise en charge des opérations de renommage _RENAME_EXCHANGE_ et _RENAME_WHITEOUT_. ### NFS Depuis le noyau 4.5, la copie de fichiers par morceau (_copy_file_range_) était prise en charge. Désormais, la copie d’un fichier en entier sera prise en charge directement par le noyau, mais de façon synchrone seulement, _a priori_. ### Système de blocs Dans le système de blocs, l’ajout de _async discard_ permet de ne plus bloquer les autres couches et de travailler pendant ce temps‐là. Après adaptation des systèmes de fichiers pour l’exploitation de cette fonctionnalité, les performances devraient être meilleures. Pour l’instant, seuls XFS et le pilote NVMe en profitent. Des corrections, nettoyages d’interface et quelques optimisations ont été faits. Maintenant le _blk-mq_ (_Device Mapper multiple queue_) se fait sans verrou, ce qui permet une meilleure exploitation en multiprocesseur, surtout dans le cas de processeurs sur des puces différentes (_multi‐socket_), le gain en cas de multiples cœurs sur une même puce étant moindre. ## Virtualisation ###KVM Création d’un répertoire _debugfs_ et des fichiers _stat_ pour chaque machine virtuelle, nommés d’après leur numéro de processus (PID). Ce répertoire contient la même chose que le répertoire KVM précédent, mais avec des stats spécifiques pour chaque machine virtuelle. ###virtio Ajout d’outils de mesures. # Le bilan en chiffres ## Le noyau Pour le noyau, l’évolution moyenne du nombre de lignes de code par RC est globalement stable pour cette version 4.7, comme le montre le graphique suivant : ![Évolution du nombre de lignes de code à travers les RC de la version 4.7](http://damballa.alwaysdata.net/evol-4.7rc.png) Si on regarde l’évolution du nombre de lignes de code par version, on constate que le noyau 4.7 est dans la moyenne de la série des 4._x_ : ![Évolution du nombre de lignes de code par version depuis le noyau 4.0](http://damballa.alwaysdata.net/linux_evol4.7.png) Nombre de _commits_ Git par utilisateur : ![Nombre de commits Git par utilisateur](http://damballa.alwaysdata.net/contributor_changeset_47.png) Nombre de lignes modifiées par utilisateur : ![Nombre de lignes modifiées par utilisateurs](http://damballa.alwaysdata.net/contributor_change_lines_47.png) Origine des contributions : ![Origine des contributions](http://damballa.alwaysdata.net/contribution_by_origin_47.png) Origine des contributeurs du noyau : ![Origine des contributeurs du noyau](http://damballa.alwaysdata.net/contributor_by_origin_47.png) ## La dépêche La rédaction de cette dépêche s’est étendue sur quatre mois (du 14 mai au 19 août), avec plus de 410 éditions et 25 contributeurs). **N. D. M. :** en fait plus de 500 éditions, jusqu’au 28 septembre. ![Contribution à la dépèche 4.7](http://damballa.alwaysdata.net/people_linuxfr_kernel47_290916.png) # 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 | **Arch** | ~~[Romain Perier](//linuxfr.org/users/rperier)~~ | [Tiwaz](//linuxfr.org/users/tiwaz) **Développeurs** | ~~[Romain Perier](//linuxfr.org/users/rperier)~~ | [Tiwaz](//linuxfr.org/users/tiwaz) **Pilotes graphiques libres** | ~~[Martin Peres](//linuxfr.org/users/mupuf)~~ | **Réseau** | Aucun | [BRULE Herman (alpha_one_x86)](//linuxfr.org/users/alpha_one_x86) **Systèmes de fichiers** | Aucun | [BRULE Herman (alpha_one_x86)](//linuxfr.org/users/alpha_one_x86) **Sécurité** | Aucun | **Virtualisation** | [Xavier Claude](//linuxfr.org/users/claudex) | **Édition générale** | Aucun | [M5oul](//linuxfr.org/users/m5oul), [jcr83](//linuxfr.org/users/jcr83), [Davy Defaud](//linuxfr.org/users/davy78) 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 _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. Essayons d’augmenter la couverture sur les modifications du noyau !

AltStyle によって変換されたページ (->オリジナル) /