URL: https://linuxfr.org/news/sortie-du-noyau-linux-4-8 Title: Sortie du noyau Linux 4.8 Authors: Collectif superna, Davy Defaud, jcr83, Dring, BAud, M5oul, Anonyme, Benoît Sibaud, PolePosition, jlh, alpha_one_x86, tuorhuor, palm123, ZeroHeure, ariasuni, goernil, Tiwaz, romrom, Yves Bourguignon, Apichat, Martin Peres, Siosm et iouri Date: 2016年08月07日T20:00:25+02:00 License: CC By-SA Tags: sortie_version, noyau_linux et linus_torvalds Score: 61 La sortie de la version stable 4.8 du noyau Linux a été annoncée le 2 octobre 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 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)). ---- ---- #Annonces des RC par Linus Torvalds ##RC-1 La version [RC-1](https://lkml.org/lkml/2016/8/7/93) est sortie le dimanche 7 août 2016 : > Deux semaines se sont écoulées et la fenêtre de fusion de la version 4.8 est donc maintenant fermée.> > À cause de mon voyage de la semaine dernière, j’ai encore quelques demandes d’intégration en attente que je voudrais regarder de plus près auparavant, mais j’ai traité la majeure partie des demandes et je voulais être certain de ne pas en recevoir de nouvelles.> > Ça semble devenir l’une des plus grosses versions de ces derniers temps, mais attendons de voir comment ça se termine. La fenêtre d’intégration a été plutôt normale, bien que le correctif en lui‐même ait l’air plutôt inhabituel : plus de 20 % concerne des mises à jour de documentation, dues à la conversion de la documentation DRM et media depuis Docbook vers le format Sphinx. Il y a d’autres mises à jour de documentation, mais c’est le plus gros morceau.> > Si l’on met de côté le changement de format de documentation, tout semble plutôt normal, avec environ 60 % des modifications non relatives à la documentation sur des pilotes (pilotes graphiques, réseau, média, son, etc.) et environ 15 % sur des mises à jour d’architectures (ARM, POWER et x86 dominant, mais il y a aussi du MIPS et du S/390).> > Le reste est réparti : cœur de réseau, outillage (essentiellement _perf_), incluant les fichiers, le cœur du noyau, VFS et les systèmes de fichiers bas niveau (XFS exclus). Quelques zones épargnées :>> 10 787 fichiers modifiés, 612 208 insertions(+), 272 098 suppressions(-)> > En avant, testez. Les modifications et les journaux sont trop gros pour être postés, donc comme d’habitude pour une RC-1, j’ajoute seulement mon « journal d’intégration » pour une vue d’ensemble.> > Linus ##RC-2 La version [RC-2](https://lkml.org/lkml/2016/8/14/874) est sortie le dimanche 14 août 2016 : > Voici une semaine que la fenêtre d’intégration est fermée, et la version RC-2 est sortie. Testez‐la.>> Les statistiques de modifications de la RC-2 semblent inhabituelles, du fait qu’un sixième concerne les pilotes (normalement les pilotes représentent environ la moitié de l’ensemble des mises à jour). Au lieu de quoi, ce sont les mises à jour d’architectures qui dominent, ainsi que `fs/` et `mm/`. Mais ce n’est probablement que parce que les plus gros changements de pilotes n’ont pas commencé à arriver — la RC-2 a tendance à être une période calme après la folie de la fenêtre d’intégration.> > Et la raison pour laquelle `mm/` se distingue est principalement à cause d’une demande supplémentaire pendant la fenêtre d’intégration que j’ai repoussée après la RC-1, afin de pouvoir regarder ça plus attentivement.> > Donc, je m’attends à ce qu’on revienne à la normale la semaine prochaine.> > Rien de bien étrange ne semble être en cours ; donc, s’il vous plaît, allez la tester et rapportez tous les problèmes que vous rencontrerez. Évidemment, on est encore au début de la série de RC, mais je pense qu’il n’y avait rien de vraiment inquiétant durant cette fenêtre d’intégration, alors ne soyez pas timides.> > Linus ##RC-3 La version [RC-3](https://lkml.org/lkml/2016/8/21/378) est sortie le dimanche 21 août 2016 : > Après la semaine dernière caractérisée par des statistiques de modifications inhabituelles (seulement un sixième pour les pilotes), nous ne sommes toujours pas revenus à la normale avec la RC-3 et nous sommes dans la situation habituelle avec grosso modo 60 % des correctifs portant sur les mises à jour de pilotes. Cela s’étend encore, mais la plupart semblent tendre vers le réseau, les pilotes graphiques et le nouveau pilote EDAC. Mais tout ça est encore bien petit.> > En dehors du département des pilotes, on a du réseau, quelques mises à jour de systèmes de fichiers (principalement XFS, bien que dans les statistiques de changement AFS soit également visible, mais surtout pour des changements liés au réseau) et une touche de mises à jour un peu éparpillées : documentation, planificateur, quelques modifications mineures d’architectures, etc.> > Et quelques corrections sur les outils de perf.> > Tout ça semble plutôt sain, je ne vois rien de très effrayant ici. Allez tester ça.> > Linus ##RC-4 La version [RC-4](https://lkml.org/lkml/2016/8/28/223) est sortie le dimanche 28 août 2016 : > Nouvelle semaine, nouvelle RC.> > Tout semble normal et cela a été aussi un peu plus calme que la RC-3, donc espérons que nous sommes bien dans la phase « ça se calme ». Bien qu’avec les habituelles fluctuations relatives aux contraintes de temps (différents mainteneurs étalent leurs requêtes d’intégration différemment), il est difficile de déjà annoncer une tendance.> > En tout cas, tout ça semble plutôt petit. Je pense que le plus gros truc ici est une correction sur la gestion d’énergie pour Skylake ajoutée comme une partie de la mise à jour du pilote graphique, juste avant que je n’envisage de couper la version RC-4. Tant pis. L’autre changement plutôt imposant est un lot de corrections Btrfs.> > Mais dans l’ensemble tout ça ne semble pas effrayant et le reste est vraiment plein de mignonnes petites corrections éparses : divers pilotes de sous‐systèmes (son, RDMA, bloc), KVM et autres mises à jour d’architectures.> > Voir l’habituel journal résumé ci‐dessous pour les détails — il est petit et facile à parcourir pour sentir le goût des trucs qui se sont passés.> > En avant, testez.> > Linus ##RC-5 La version [RC-5](https://lkml.org/lkml/2016/9/4/212) est sortie le dimanche 4 septembre 2016 : > Donc, la RC-5 est sensiblement plus grosse que ne l’était la RC-4, et mon sentiment de la semaine dernière que nous commencions à nous calmer semble avoir été prématuré.> > Cela dit, la plupart des `diffstats` semblent plutôt plats (ce qui implique plein de petits changements triviaux plutôt que des gros invasifs). Il y a du boulot dans le pilote réseau Mellanox _mlx5_ et il y a du bruit côté NFS et OverlayFS, mais dans l’ensemble c’est juste un tas de petites corrections. C’est sans doute un peu _plus_ de petites corrections que ce que je préfère voir à ce stade, mais je suspecte que la RC-4 semblait si bien et si petite parce que de nombreuses corrections avaient été reportées à la RC-5.> > Non pas que tout ça semble inquiétant en tant que tel, mais si les choses ne commencent pas à se calmer maintenant, ça va finir par être une de ces versions qui ont besoin d’une RC-8. On verra.> > Cela dit, quand on regarde individuellement les statistiques de chaque _commit_, tout ça semble petit et simple, c’est juste qu’il y en a plus que je ne l’aurais souhaité.> > Le journal résumé est joint pour ceux qui veulent se faire une idée des trucs qui se sont produits.>> Linus ## RC-6 La version [RC-6](https://lkml.org/lkml/2016/9/11/188) est sortie le dimanche 11 septembre 2016 : > Les choses se sont calmées et tout semble très normal. Environ deux tiers de mises à jour de pilotes, la moitié du reste concernant des mises à jour d’architectures, et la seconde moitié des trucs divers (corrections de bogues liés à `fs/crypto`, etc.).> > Évidemment, quelques minutes après la sortie, David m’a envoyé la demande d’intégration pour le réseau, c’est peut‐être la raison pour laquelle la RC-6 semble plutôt petite. Tant pis. Je n’ai pas encore décidé si nous allions ou non faire une RC-8, mais je ne crois pas que je doive le faire maintenant. Rien ne semble particulièrement mauvais, et ça dépendra de ce que donnera la RC-7.>> Le journal résumé est joint — il est assez petit pour qu’on puisse le parcourir et avoir une idée de ce qui se passe.> > Linus. ## RC-7 La version [RC-7](https://lkml.org/lkml/2016/9/18/412) est sortie le dimanche 18 septembre 2016 : > Nouvelle semaine, nouvelle RC.> > Normalement la RC-7 est la dernière de la série avant la version finale, mais maintenant je suis pratiquement sûr que ça va être une de ces versions qui viennent avec une RC-8. Les choses ne se sont pas calmées autant que je l’aurais aimé, il y a encore quelques discussions en cours. Et il est improbable que je trouve que tout va bien et que nous sommes prêts pour une 4.8 finale dimanche prochain.> > Ceci dit, il n’y a rien de « gros » en cours, il y a juste plus de bruit que ce que je voudrais. Une partie de la RC-7 est, bien sûr, composée de corrections réseau qui ont manqué la RC-6 de quelques minutes, mais il y a aussi d’autres mises à jour de pilotes divers (RDMA, NVMe et quelques corrections PCMCIA — eh oui, ce n’est pas encore mort). Et un bon nombre de petites corrections d’architectures (les corrections _uaccess_ d’Al sont sorties, mais il y a aussi quelques corrections de _perf_, de KVM et d’autres choses variées en cours également).> > Le journal résumé n’est pas aussi court que je l’aimerais, mais il est joint et il n’est pas vraiment gros non plus — vous pouvez facilement le parcourir pour avoir une rapide idée des détails.> > Une autre chose qui me fait dire « tant qu’on y est, faisons une RC-8 » est qu’il ne semble pas que _linux-next_ soit si gros que ça, donc je n’ai pas l’impression d’une quelconque pression pour ouvrir la fenêtre d’intégration. Il y a bien quelques fonctionnalités qui semblent être planifiées pour une intégration dans la 4.9 et que j’attends, mais une semaine de plus ne nuira pas.> > Bien sûr, peut‐être que les choses iront *si* merveilleusement bien la semaine à venir que je vais décider que la 4.8 est prête. Il n’y a vraiment rien de particulier qui m’inquiète, mais voir ces corrections de corrections la semaine dernière me fait juste dire « Eh, des trucs sont encore en cours. »> > Mais s’il vous plaît, allez‐y, testez.> > Linus ## RC-8 La version [RC-8](https://lkml.org/lkml/2016/9/25/259) est sortie le dimanche 25 septembre 2016 : > Donc, comme déjà évoqué la semaine dernière (et envisagé comme une possibilité), voici la RC-8. Les choses ont en fait commencé à se calmer cette semaine, mais je n’ai pas trouvé inutile de faire une dernière RC, donc nous y voici. Je pense que la version 4.8 sera finalisée pour le week‐end prochain, sauf si quelque chose de vraiment inattendu se produit.> > Il y a quelques entrées éparses dans la liste de régression de Thorsten, mais rien qui me guide vers « on doit suspendre la 4.8 ». Et les choses ont été vraiment calmes, avec juste quelques corrections ici ou là. Regardez le journal résumé ci‐après, mais c’est vraiment plein de petites choses : essentiellement des pilotes, avec un peu d’architectures et de crypto, et des petites corrections de MM et de systèmes de fichiers. Et une tripotée de réseau.> > Linus ## Version finale La [version finale](https://lkml.org/lkml/2016/10/2/102) est sortie le dimanche 2 octobre 2016 : > Cette dernière semaine était plutôt calme, ce qui me fait penser que j’aurais peut‐être dû finalement ignorer la RC-8.> Peu importe, aucun mal n’a été fait.> > Ceci veut dire que la fenêtre de fusion pour le 4.9 est ouverte et j’apprécie les personnes qui m’ont déjà envoyé des demande d’intégration en avance pour des raisons de voyages ou autre. Je commencerais à les fusionner dès demain et on aura sûrement les développeurs les plus aguerris qui testeront la version 4.8 avant que la prochaine phase de développement ne commence. ;)> > Enfin, il y a quelques corrections d’importance mineure listées ci‐dessous : c’est un mélange de corrections d’architectures (ARM, MIPS, SPARC, x86), pilotes (réseau, _nvdimm_, graphique) et de code générique (aussi du réseau, un peu de systèmes de fichiers, _cgroup_ et de gestion de machines virtuelles).> > Finalement, c’est assez petit et il n’y en a pas beaucoup.> Allez le tester maintenant,>> Linus ## Version 4.8.1 La [version corrective 4.8.1](http://lkml.iu.edu/hypermail/linux/kernel/1610.0/00878.html), sortie le 7 octobre 2016 : > Je suis désolé d’avoir fusionné cette dernière série de correctifs d’Andrew juste avant de faire la version 4.8, parce qu’ils provoquent des problèmes et qu’ils sont maintenant dans le 4.8 (et que cette merde boguée est marquée pour la version stable aussi).> > En particulier, j’ai eu droit a :> > _kernel BUG at ./include/linux/swap.h:276_> > Et le résultat final était un noyau mort.> > L’erreur que le changement _22f2ac51b6d64_ (« _mm: workingset: fix crash in shadow node shrinker caused by replace_page_cache_page()_ ») avait pour but de corriger était apparemment présente depuis la version 3.15, mais la correction est clairement pire que l’erreur qui aurait dû être corrigée, car l’erreur originale n’a jamais tué ma machine !> > J’aurais dû réagir à cet ajout de lignes contenant un _BUG_ON()_. Je suppose que j’aurais dû enlever ce stupide concept de _BUG_ON()_ une fois pour toute, car il n’y a PAS DE P*TAIN D’EXCUSE pour consciemment tuer le noyau.> > Pourquoi diable n’était‐ce pas un _avertissement_ ?> > Oui, je suis grognon. Ceci est arrivé très tard dans le cycle de publications et je m’attendais à bien mieux de la part d’Andrew. Ajouter n’importe où des _BUG_ON()_ dans du code qui n’a pas vraiment été assez testé n’est pas acceptable. Et ce n’était clairement pas acceptable de me l’envoyer après la RC-8 sans que ce ne soit abondamment testé, ce qui n’a manifestement pas été le cas en l’occurrence. J’ajoute _stable_ en copie ici pour les prévenir.>> Linus #Les nouveautés ##Prise en charge des plates‐formes ###ARM/ARM64 ####ACPI - ARM64 : prise en charge de NUMA via ACPI ; - ARM64 : maintenant que l’ACPI supporte le mode « _idle_ » LPI (_Low Power Idle_), activation du mode ACPI_PROCESSOR_IDLE ; - ARM64 : prise en charge des bus PCI via ACPI. ####Xen - ARM : décrit comment utiliser l’ACPI de Xen sur des plates‐formes virtuelles ARM64. ####Divers ARM64 - prise en charge de [_kexec_](https://en.wikipedia.org/wiki/Kexec "kernel execution — exécution du noyau") ; - implémentation d’une fonction de contrôle d’intégrité (_checksum_) IP optimisée pour ARM64 ; - prise en charge de la compilation avec _kcov_. ####Broadcom - prise en charge du système monopuce BCM23550 avec SMP ; - prise en charge initiale pour le Raspberry _Pi_ 3 à base de bcm2835 ; - prise en charge de la carte BCM953012ER à base de BCM5301x ; - prise en charge du SoC bcm958625hr de la série NSP. ####Qualcomm Prise en charge de la carte Dragonboard avec le système monopuce Qualcomm APQ8060. ####Atmel - prise en charge de la carte Olimex SAM9-L9260 ; - prise en charge de la carte at91sam9260ek via l’arborescence matérielle (_Device Tree_). ####Freescale/NXP/(Qualcomm ?) - prise en charge de la carte Auvidea H100 à base de systèmes monopuces i.MX 6 ; - prise en charge de la carte Utilite Pro à base de systèmes monopuces i.MX 6s ; - prise en charge de la carte Toradex Colibri à base de systèmes monopuces i.MX 7S/iMX 7D ; - prise en charge de Creative X-Fi3 ; - prise en charge de SanDisk Sansa Fuze+. ####Allwinner - prise en charge de la carte Bananapi M1 Plus (systèmes monopuces sun7i) ; - prise en charge de Sinovoip BPI-M2+ (systèmes monopuces sun8i-h3) ; - prise en charge de la tablette Polaroid MID2407PXE03 (systèmes monopuces sun8i) ; - prise en charge de la carte inet86dz (systèmes monopuces sun8i). ####Renesas - ARM : prise en charge initiale du système monopuce R8A7792 ; - ARM : prise en charge de la carte « blanche » avec le système monopuce R8A7792 ; - ARM64 : prise en charge du système monopuce Renesas R8A7796 ; - ARM64 : prise en charge de la carte Salvator-X avec le système monopuce R8A7796. ####Divers - ARM : prise en charge de la carte de développement Cirrus Logic EDB7211 (système monopuce CLPS711X) ; - ARM : début de prise en charge de la carte Odroid XU (système monopuce Samsung Exynos) ; - ARM64 : prise en charge du système monopuce LG Electronics lg1313 ; - ARM64 : prise en charge du système monopuce Mediatek MT6755 ; - ARM : prise en charge initiale du système monopuce HiSilicon Hi3519. ###MIPS Prise en charge de l’ajout à chaud de processeurs de type MIPS R6. ##Pilotes graphiques libres ### AMDGPU Un ajout notable en ce qui concerne le pilote AMDGPU est la possibilité de surcadencer son processeur graphique grâce à la prise en charge d’OverDrive. Une fonctionnalité qui ravira joueurs et mineurs de tout poil. La méthode n’est pour le moment pas très conviviale, car elle consiste à modifier la valeur de certains fichiers en ligne de commande. Dans le détail, on a typiquement le fichier `/sys/class/drm/card0/device/pp_sclk_od` pour la gestion de la fréquence du processeur graphique et le fichier `/sys/class/drm/card0/device/pp_mclk_od` pour la mémoire. Les valeurs possibles vont de 0 à 20 par palier de 1 et représentent le pourcentage d’augmentation de la fréquence. ### Nouveau Début de prise en charge des processeurs graphiques GP100 et GP104. ##Réseau ### Wireless (802.11) Les _Beacon frames_ sont des trames de gestion du Wi‐Fi, leur gestion a été améliorée. Il y a maintenant la prise en charge de MU-MIMO _air sniffer_. Les opérations privilégiées de Netlink sont maintenant gérées depuis les espaces de noms (comme les conteneurs LXC, Docker, VServer). Une meilleure gestion interne des files d’attente logicielles via FQ/codel est introduite. ### IPv6 Gestion du [6LoWPAN](https://fr.wikipedia.org/wiki/6LoWPAN "IPv6 Low power Wireless Personal Area Networks") pour l’IPv6 en réseau personnel. Meilleure gestion de l’[[ICMP]] pour les tunnels [GRE](https://fr.wikipedia.org/wiki/Generic_Routing_Encapsulation "Generic Routing Encapsulation") en IPv6. ### Multi Protocol Label Switching (MPLS) Permet une gestion interne des routes plus efficace, elle propose l’IP sur IP, IP via tunnel [GRE](https://fr.wikipedia.org/wiki/Generic_Routing_Encapsulation). ### Bluetooth Amélioration des diagnostics pour l’authentification. ### NFC Gestion de l’attente des temps de réponse. ### infiniBand Ajout de l’émulation RDMA sur Ethernet. Gestion du pilotage de flux pour IPv6. ### BATMAN Le protocole de réseau maillé [BATMAN](https://fr.wikipedia.org/wiki/BATMAN_%28protocole%29 "Better Approach to Mobile Adhoc Networking") a reçu son lot d’améliorations ([multidiffusion](https://fr.wikipedia.org/wiki/Multicast "Multicast"), débogage...). ##Systèmes de fichiers ### ext4 Les codes de chiffrement ne sont plus spécifiques, ils ont été unifiés et mis en commun avec F2FS, cela permettra une meilleure maintenance. ### Blocs Diverses corrections au niveau de la gestion des blocs, cela va de l’ordonnanceur, à la gestion du bogue de l’année 2038. Pas mal de changements côté NVMe (qui permet une bien meilleure exploitation des SSD qu’AHCI) et particulièrement NVMeF, correction dans Bcache (qui permet de fusionner un disque dur et un SSD en un disque hybride). ### F2FS Le système de fichiers a moins de pression sur les verrous, ce qui permet une meilleure montée en charge, des optimisations sur les écritures et diverses corrections. ### NFS Un problème de performance dans le NFS a été trouvé et corrigé, une mise en cache plus agressive et davantage de code optimisé, permettent d’optimiser le client NFS. ### OrangeFS La mise en cache côté noyau permet d’optimiser OrangeFS, en améliorant les latences, augmentant le débit et soulageant le réseau. ### XFS Le _Reverse-Mapping_ a été inclus, cela permet de suivre le propriétaire d’un bloc. C’est le premier pas pour l’avancement sur un certain nombre de futures fonctionnalités (reflink, _copy-on-write data_, _dedupe_, _online metadata_ et _data scrubbing_) et une bien meilleure gestion de la récupération des données pour un système de fichiers endommagé ou corrompu. ### Btrfs En plus des habituelles corrections de bogues, pour ce noyau nous avons droit à une réécriture complète de la vérification de l’espace libre, qui était en gestation depuis des mois. Cela diminue fortement les latences et maximise le débit. #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** | Aucun | **Développeurs** | Aucun | **Pilotes graphiques libres** | Aucun | **Réseau** | Aucun | **Systèmes de fichiers** | Aucun | [Herman Brule](//linuxfr.org/users/alpha_one_x86) **Sécurité** | Aucun | **Virtualisation** | [Xavier Claude](//linuxfr.org/users/claudex) | **Édition générale** | Aucun | [Martin Peres](//linuxfr.org/users/mupuf), [yPhil](http://linuxfr.org/users/philippemc) 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 によって変換されたページ (->オリジナル) /