URL: https://linuxfr.org/news/sortie-du-noyau-linux-4-6 Title: Sortie du noyau Linux 4.6 Authors: Collectif Davy Defaud, Yves Bourguignon, M5oul, goernil, esdeem, Anonyme, Martin Peres, jcr83, alpha_one_x86, antistress, kp, BAud, palm123, Lucas, frederic, gusterhack, claudex, Benoît Sibaud, rogo, ZeroHeure, Frédéric Massot, Olivier Esver, romrom, bubar🦥, ariasuni et Loic P Date: 2016年04月16日T13:53:50+02:00 License: CC By-SA Tags: sortie_version, noyau_linux, coulisses, kernel, linus_torvalds et lwn Score: 84 La sortie de la version stable 4.6 du noyau Linux a été annoncé le dimanche 15 mai 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)). ---- [Dépêches des noyaux précédents](https://linuxfr.org/wiki/depeches_noyau) [Site officiel du noyau Linux ](https://www.kernel.org/) [La liste des nouveautés sur Kernelnewbies.org](http://kernelnewbies.org/Linux_4.6) [Liste des nouveautés 1/2 sur lwn.net ](http://lwn.net/Articles/680121/) [Liste des nouveautés 2/2 sur lwn.net](http://lwn.net/Articles/680566/) ---- # En bref Le noyau Linux 4.6 est dans l’ensemble une grosse version, qui comporte beaucoup plus de _commits_ que d’habitude. Cette version apporte le nouveau système de fichiers distribué [[en:OrangeFS]], la gestion de l’USB 3.1, des améliorations de l’efficacité du tueur de processus qui débordent sur la mémoire, ainsi que la gestion des clefs de protection de la mémoire pour les processeurs Intel, la connexion multiplexeur et le [chiffrement IEEE 802.1AE](https://fr.wikipedia.org/wiki/IEEE_802.1AE) de l’adresse MAC. De plus, le noyau gère la version cinq du [protocole B.A.T.M.A.N.](https://fr.wikipedia.org/wiki/BATMAN_%28protocole%29) (_Better Approach To Mobile Adhoc Networking_), le vérificateur en ligne de nœuds d’index pour le système de fichiers OCFS2, le _dma-buf_, la gestion des espaces de noms des _cgroups_ et la gestion de la couche pNFS SCSI. #Annonces des versions candidates par Linus Torvalds ##RC-1 La version [RC-1](https://lkml.org/lkml/2016/3/26/132) est sortie le samedi 26 mars 2016 :> Alors, je ferme la fenêtre d’intégration un jour en avance, d’une part parce que j’ai des voyages à venir, mais d’autre part parce que ce fut une des plus grosses fenêtres d’intégration depuis un moment et si quelqu’un planifiait de glisser une modification à la dernière minute, je ne veux vraiment pas en entendre parler. >> De manière globale, en dépit de la durée de la fenêtre d’intégration, ce fut principalement sans douleur. Il y a eu assez peu de conflits et la branche ARM, qui en compte traditionnellement le plus, fut l’une des plus faciles. Bon travail.>> Bien sûr, pour compenser ça, nous avons eu quelques problèmes inhabituels de système de fichiers, avec les demandes d’intégration de F2FS et Ceph nécessitant un rappel à l’ordre pour avoir désorganisé leur branche, dans les deux cas pour essayer de les rendre plus simples pour l’intégration, mais dans les deux cas, je souhaite vraiment, _vraiment_, que les gens ne se préoccupent que de leur propre code et non qu’ils fassent des changements pour s’adapter à ce qui se passe en dehors de leur branche.>> Mais il s’agissait principalement de problèmes de maintenance de _git_ et non du code en lui‐même... Et, tant qu’on parle de la partie système de fichiers, il est à noter que nous avons aussi un nouveau système de fichiers cette fois‐ci : [OrangeFS](https://en.wikipedia.org/wiki/OrangeFS). En fait, il était en attente depuis longtemps, la première demande d’intégration datant de fin août, mais il a été longtemps mis en attente à cause du travail d’Al qui a, je pense, rendu tout le monde plus heureux. La demande d’intégration en elle‐même est arrivée assez tard dans la fenêtre d’intégration, mais je suis content qu’elle soit enfin intégrée — les développeurs d’OrangeFS ont été très réactifs aux problèmes qui ont été soumis.>> Mais comme d’habitude, la _majeure partie_ des changements — de loin — est juste l’ensemble des diverses mises à jour de pilotes. Donc, malgré le travail sur le système de fichiers, les pilotes représentent environ 2⁄3 des changements. Il y en a partout : pilotes _staging_, réseau, DRM, RDMA, USB, média, son — ce que vous voulez.>> En dehors des pilotes, le plus gros des changements est, comme d’habitude, les mises à jour d’architecture : la branche ARM étant une grosse partie, mais il y a d’autres mises à jour ARM (et AMR64), combinées avec x86, PowerPC, S/390, Xtensa, et quelques m68k.>> Le reste est la partie générale du réseau, mises à jour des systèmes de fichiers (en plus des trucs déjà mentionnés sur OrangeFS, F2FS et Ceph, il y a aussi des mises à jour sur XFS, Btrfs, OCFS2, ext4 et la partie générique VFS). Et le travail sur la base du noyau, ainsi que des mises à jour de documentation et d’outillage.>> Donc, pas mal de travail partout. Le journal abrégé étant beaucoup trop gros à poster, j’ajoute simplement mon habituel « journal de fusion » qui montre de qui j’ai récupéré les modifications, avec une très courte description. Comme d’habitude, l’intégralité des crédits se trouve dans l’arbre _git_.>> Espérons qu’une fenêtre d’intégration raisonnablement indolore se transforme en une période d’accalmie encore plus indolore, bien que ce soit une assez grosse sortie.>> S’il vous plaît ?>> Linus ##RC-2 La version [RC-2](https://lkml.org/lkml/2016/4/3/148) est sortie le dimanche 3 avril 2016 :> Vous connaissez tous le refrain maintenant — une autre semaine, une autre RC. Je dirais que les choses ont l’air normales sur ce point : ce n’est pas une grosse RC-2, mais cela a été vrai récemment (les RC-3 ont tendance à être un peu plus grosses — probablement juste parce que ça prend du temps pour que les gens se rendent compte des problèmes). >> Les statistiques du correctif ont l’air plutôt normales aussi : environ la moitié sont des pilotes, environ le quart sont des corrections d’architectures, et le reste est principalement du réseau et des mises à jour de documentation. Mais il y a aussi quelques corrections au cœur du noyau, de la gestion de la mémoire, des systèmes de fichiers.>> Le journal abrégé est joint et donne une bonne idée des types de changements que nous avons.>> Allez‐y, testez, rien n’a l’air particulièrement effrayant ici.>> Linus ##RC-3 La version [RC-3](https://lwn.net/Articles/683327/) est sortie le dimanche 10 avril 2016 :> Le fait que la RC-3 est plus grosse que la RC-2 devient une tendance (mon explication est qu’il se passe un temps avant que les gens trouvent des problèmes, en plus de la pause qu’ils prennent après la fenêtre d’intégration), donc ce point n’est pas surprenant.>> Ce qui est surprenant, toutefois, est que la moitié du gros des correctifs de la RC-3 concerne du code de système de fichiers. Je ne me souviens pas d’une situation similaire, et cela m’a surpris — J’ai dû aller en chercher la raison. Il s’avère que bien que nous ayons effectivement des changements sur plusieurs systèmes (Btrfs, ext4, OrangeFS, F2FS), la grosse raison était simplement le remplacement de la macro `PAGE_CACHE_SIZE` par `PAGE_SIZE` partout. Et le code faisait grand usage de ce nommage reliquaire.>> De toute façon, une fois cette petite bizarrerie expliquée, les statistiques ont l’air assez normales, le reste étant essentiellement des pilotes. Le plus gros correctif est la résurrection du pilote _staging_ `olpc_dcon`, qui n’était pas si obsolète que ça, après tout. On a raté un truc là, puisque cette résurrection a raté Pâques d’une semaine. On fera mieux dans le domaine des dates rigolotes la prochaine fois, promis.>> Il y a également l’habituel saupoudrage de correctifs d’architectures, mais c’est assez léger.>> Dans l’ensemble, je trouve qu’on est bon. Il est assez tôt dans les RC, mais tout semble nickel. Allez‐y, testez.> > Linus ##RC-4 La version [RC-4](https://lkml.org/lkml/2016/4/17/329) est sortie le dimanche 17 avril 2016 :> Ce fut une semaine assez calme, et la RC-4 n’est pas si grosse que ça. Il n’y a rien de particulièrement effrayant.>> Des changements dans tout l’arbre, les pilotes (40 %) et des correctifs d’architectures (30 %) représentant le gros de la chose. Le reste est saupoudré autour, et c’est tout petit. En fait, les correctifs « VM » représentent plus de 5 % du correctif, mais c’est uniquement parce qu’on s’est débarrassé de la bidouille _conversion-time_, d’où quelques conventions d’appel différentes pour `get_user_pages()`.>> Donc, rien de particulièrement intéressant. C’est comme ça que j’aime les RC, espérons que ça reste ainsi.>> Le journal abrégé est joint à l’attention de ceux qui ont du mal à trouver le sommeil.>> Linus ##RC-5 La version [RC-5](https://lkml.org/lkml/2016/4/24/177) est sortie le dimanche 24 avril 2016 :> Les choses continuent à être tout à fait calmes : la RC-5 est plus grosse que la RC-4, mais la RC-4 était vraiment petite.>> Et, alors que nous sommes revenus cette fois à un nombre normal de changements pendant la fenêtre de sortie, les types de bogues trouvés restent très ordinaires : il n’y a absolument rien d’effrayant ici. Si l’on continue sur cette voie, ce pourrait être une de ces rares sorties qui n’ont pas besoin de six RC. Du moins, ça en a l’air pour le moment ; même si pour être honnête, je suspecte que, quand bien même les choses continuent de se calmer ainsi, je ferai une RC-7 normale, simplement parce qu’il n’y pas d’urgence, ni de raison de ne pas le faire.>> Un comportement qui est _très_ clair, c’est que les demandes d’intégration sont envoyées en fin de semaine. Plus de la moitié de toutes les intégrations ont été faites vendredi et particulièrement samedi. Je ne me plains pas, je pense que c’est juste un signe qu’il n’y avait rien de particulièrement urgent cette semaine, et donc les gens envoient leurs demandes d’intégration en fin de semaine de travail et/ou savent juste que la RC arrive.>> De toute façon, le gros des changements vient des pilotes, comme d’habitude (à environ 60 % — les pilotes Ethernet ressortent des statistiques de _diff_, mais c’est plutôt disséminé), avec le réseau et l’outillage pour la majeure partie du reste. Il y a quelques autres petits changements et vous pouvez avoir un aperçu des détails en survolant le journal abrégé en annexe.>> Allez‐y, testez. Ça a l’air robuste.>> Linus ##RC-6 La version [RC-6](https://lkml.org/lkml/2016/5/1/191) est sortie le dimanche 1^(er) mai 2016 :> Les choses continuent d’être plutôt calmes, même si je suis presque sûr de faire une RC-7 dans cette série.>> Il n’y a rien de particulièrement effrayant ici — il y a un correctif pour le problème récurrent des interfaces infiniBand, mais comme cela concerne du matériel spécifique, ça ne risque pas de toucher beaucoup de gens, et le contournement du bogue était assez simple. La majeure partie du reste est juste le bruit de fond normal. Les pilotes (son, pilotes graphiques et Ethernet principalement), les architectures (ARM, S/390, x86), le réseau en prenant la plus grande part.>> Le journal abrégé est joint pour votre édification.>> Linus ##RC-7 La version [RC-7](https://lkml.org/lkml/2016/5/8/122) est sortie le dimanche 8 mai 2016 :> Donc, voici la RC-7 parce que, bien que les choses aient été vraiment calmes pendant un bon moment, ça n’a pas été calme au point que je décide que ça ne vaille pas le coup de faire la traditionnelle dernière RC. Mais c’est ainsi, à moins que quelque chose de surprenant n’arrive. >> Il n’y a rien de particulièrement étrange ici et le journal abrégé joint est suffisamment petit pour le survoler et avoir un aperçu des détails. C’est principalement des petites corrections de pilotes et d’encore plus petites mises à jour d’architectures. Ajoutez du réseau, quelques correctifs du cœur du système de fichiers et du noyau et c’est à peu près tout.>> Rien de particulièrement effrayant et, plus de gens la testeront, plus nous pourrons être confiants que la 4.6 finale sera très bonne. Donc, s’il vous plaît, prenez un moment pour l’essayer,>> Linus ## Version finale La [version finale](https://lkml.org/lkml/2016/5/15/83) est sortie le dimanche 15 mai 2016 :> C’est une bonne chose de ne pas avoir clos le cycle des RC trop rapidement, puisque la semaine dernière s’est terminée avec un peu plus de correctifs que prévu, mais rien ne semble bizarre ou anormal. Donc, la version 4.6 est sortie comme prévu et ça signifie évidemment que je vais ouvrir la fenêtre d’intégration pour la 4.7 dès demain.>> Depuis la RC-7, il y a eu un peu de bruit un peu partout, les corrections de pilotes en représentant la plus grande partie, mais il y a du bruit plus léger un peu partout (outils de perf, réseau, systèmes de fichiers, documentation, quelques petits correctifs d’architectures...).>> Le journal abrégé joint vous donnera un aperçu de ce qui s’est passé durant la semaine écoulée. Le noyau 4.6 était dans l’ensemble assez gros — plus de correctifs que j’en ai eu depuis un moment. Mais, tout a semblé plutôt calme malgré tout.>> Linus #Les nouveautés ##Architecture ### Ordonnanceur L’introduction des files simples permet une autre gestion des processus et diminue la mémoire tout en augmentant les performances. Pour les systèmes [NUMA](https://en.wikipedia.org/wiki/Non-uniform_memory_access) (_multi‐socket_), une meilleure répartition des processus permet d’avoir plus de bande passante mémoire et donc de meilleures performances. L’option [NOHZ](https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt), qui permet d’économiser l’énergie en ne générant pas d’interruptions quand le processeur est à vide, est aussi plus performante. ### EFI Diverses améliorations de l’EFI ont été faites, particulièrement en isolant le contexte de l’EFI du reste du noyau, cela permet une meilleure sécurité. Le noyau peut désormais fonctionner avec un micrologiciel UEFI et les interruptions. Même si des améliorations sont à noter dans la partie x86, les architectures ARM 64 bits ne sont pas en reste. #### USB 3.1 Gestion du protocole SuperSpeed Plus (SSP) pour l’[USB 3.1](https://fr.wikipedia.org/wiki/Universal_Serial_Bus#USB_3.1) qui offre des vitesses de transfert pouvant aller jusqu’à 10 Gbit/s. ### Générique Plus de code assembleur a été porté en C, ce qui permet un code générique et réutilisable sur d’autres plates‐formes. Et cela permet aussi au compilateur de faire des optimisations spécifiques au processeur utilisé. L’outil [_objtool_](https://github.com/torvalds/linux/commit/442f04c34a1a467759d024a1d2c1df0f744dcb06) a évolué pour trouver plus facilement les bogues dans le code assembleur du noyau. ### Gestion d’énergie #### AHCI L’[AHCI](https://fr.wikipedia.org/wiki/Advanced_Host_Controller_Interface "Advanced Host Controller Interface") est une norme des contrôleurs SATA, une meilleure gestion de l’énergie, surtout via la mise en suspension, permet de gagner en énergie. #### FBC et PSR pour les cartes graphiques Intel La compression du tampon de trames (_Frame Buffer Compression_ — FBC) est maintenant activée par défaut, cela permet de transférer moins d’informations. Le _Panel Self Refresh_ (PSR) est aussi activé, cela permet de réduire la consommation en ne renouvelant pas l’image affichée si celle‐ci ne bouge pas. Le gain peut aller de 29 % à 85 %. #### CPUFreq et PState [[source sur la LKML](http://lkml.iu.edu/hypermail/linux/kernel/1603.1/05278.html?utm_source=anzwix)] Tout d’abord, la manière dont se déclenchent les mises à jour de la fréquence processeur est maintenant différente. Au lieu d’avoir à mettre en place et gérer une horloge programmée pour chaque processeur du système, pour évaluer et éventuellement modifier périodiquement sa fréquence, les régulateurs de _cpufreq_ demandent l’aide de l’ordonnanceur régulièrement (essentiellement lors des mises à jour d’utilisation). Les « anciens » régulateurs _on demand_ et _conservative_, font toujours tout leur travail dans le contexte du processus (bien que cela soit déclenché par l’ordonnanceur maintenant), mais _intel_pstate_ fait tout lors du rappel invoqué par l’ordonnanceur sans avoir besoin de tout traitement asynchrone supplémentaire. Bien sûr, ça élimine les surcharges liées à la gestion de tous ces minuteurs, mais ça permet aussi de simplifier un peu le code du régulateur de _cpufreq_. En outre, le code commun et les structures de données utilisés par les régulateurs _on demand_ et _conservative_ sont nettoyés et rendus plus simples. Et certains problèmes assez ennuyeux et qui perduraient sont traités. En particulier, la gestion des attributs du régulateur _sysfs_ est modifiée et le verrouillage associé est plus finement granularisé ce qui permet à certains problèmes d’accès simultanés d’être évités (notamment les blocages avec le code du cœur de _cpufreq_). En principe, le nouveau mécanisme de déclenchement des changements de fréquence permet de passer des informations d’utilisation de l’ordonnanceur à _cpufreq_. Bien que le code actuel ne fasse pas usage de celui‐ci, il y a en travaux un nouveau régulateur de _cpufreq_ qui prendra des décisions fondées sur les données d’utilisation de l’ordonnanceur. Cela devrait permettre à l’ordonnanceur et _cpufreq_ de travailler ensemble plus étroitement à long terme. ### ARM #### Systèmes monopuces gérés Des dizaines de nouveaux [systèmes monopuces](https://fr.wikipedia.org/wiki/Syst%C3%A8me_sur_une_puce) (_SoC_) sont gérés : Axis ARTPEC-6 (_artpec6_), TI Keystone K2G (_keystone-k2g_), Mediatek MT7623 (_mt7623_), Allwinner A83T (_a83t_), NXP i.MX6QP (_imx6qp_), ST Microelectronics STM32F469 (_stm32f469_), Annapurna Labs Alpine (_alpine-v2_), Marvell Armada 3700 (_armada-37xx_), Marvell Armada 7000/8000 (_armada-7xxx/8xxx_), Amlogic S905 (_meson-gxbb_), Qualcomm SnapDragon 820 (_msm8996_), Socionext UniPhier (_uniphier-ph1_), ARM Juno Development Platform (_juno-r2_), Allwinner A64 et Broadcom Vulcan (_vulcan_). Et beaucoup d’améliorations du côté de la prise en charge d’ARM 64 bits. ##Développement ##Pilotes graphique libres ### Direct Rendering Manager La principale nouveauté pour les utilisateurs de cette version du code commun des pilotes graphiques [DRM](https://en.wikipedia.org/wiki/Direct_Rendering_Manager) est la possibilité de sélectionner à chaud le processeur graphique sur lequel exécuter une application [pour les MacBook Pro pré‐Retina](https://lists.freedesktop.org/archives/dri-devel/2015-April/081515.html). La gestion des MacBook Pro Retina est en cours de développement et arrivera dans le futur. Une autre nouveauté importante est l’ajout d’une interface permettant de [tester la conformité des pilotes DisplayPort](https://www.spinics.net/lists/intel-gfx/msg53540.html). La gestion d’un nouveau panneau d’affichage ([ARM HDLCD](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0541c/CHDBAIDI.html)) fait également son apparition. Pour plus d’informations, vous pouvez consulter la [demande d’intégration](https://lkml.org/lkml/2016/3/20/283) faite par Dave Airlie. ### AMD (pilotes radeon et amdgpu) Le changement inclut des améliorations sur le coprocesseur audio, l’optimisation des contrôles d’entrées-sorties [[ioctl]] liés aux nuanceurs de calcul (_compute shaders_), l’optimisation de l’ordonnanceur, l’optimisation du processeur graphique virtuel (GPUVM), la gestion préliminaire de la réinitialisation du processeur graphique, une nouvelle interface PowerPlay (gestion d’énergie) et la correction de la virtualisation. Pour les possesseurs de processeurs graphiques AMD un peu anciens, aucune nouveauté du côté du pilote Radeon. Pour plus d’informations, vous pouvez consulter la [demande d’intégration d’AMD](https://lists.freedesktop.org/archives/dri-devel/2016-February/101139.html). ### Intel (pilote i915) La nouveauté principale pour le pilote Intel est la prise en charge du rafraîchissement automatique du panneau d’affichage, ainsi que la compression du tampon de trame (_framebuffer_) dans la majorité des plates‐formes. Elle aurait pris plus d’un an à deux ingénieurs, mais cela permet désormais d’économiser beaucoup d’énergie lorsque l’utilisateur utilise faiblement la machine, comme c’est le cas lors du visionnage de pages Web. Toujours concernant l’efficacité énergétique, les processeurs [[Skylake]] se rapprochent d’une gestion dynamique de l’horloge à destination des contrôleurs vidéo (CRTC). Du côté de la gestion atomique du mode graphique, le travail continue avec la conversion du code de détection des moniteurs et de celui des filigranes des tampons des contrôleurs vidéo (CRTC). Pour plus d’informations, vous pouvez consulter l’[article de _blog_ de Daniel Vetter](http://blog.ffwll.ch/2016/03/neat-drmi915-stuff-for-46.html), mainteneur du pilote _i915_. ### Nouveau Très bonne nouvelle pour le pilote _Nouveau_, NVIDIA a enfin rendu public à la fois les micrologiciels nécessaires à la prise en charge de la 3D pour la deuxième génération de processeurs graphiques Maxwell (sortie le 1^(er) juin 2015) ! Ces micrologiciels étant signés par NVIDIA, il était impossible pour les développeurs de _Nouveau_ de produire leurs propres micrologiciels, comme ils le faisaient pour les générations précédentes. Il aura donc fallu plus de six mois pour que NVIDIA rende ce code public, ce qui a ralenti les efforts de développement sur les processeurs Maxwell. Cependant, quelques jours à peine après la gestion expérimentale dans le noyau, la gestion des nouveaux processeurs graphiques est apparue dans Mesa 3D et est disponible dans Mesa 3D 11.2. Cependant, cette gestion n’est pas au niveau des [processeurs Kepler](https://fr.wikipedia.org/wiki/Kepler_%28architecture_de_carte_graphique%29) qui gèrent [[OpenGL]] 4.3 et [OpenGL ES](https://fr.wikipedia.org/wiki/OpenGL_ES) 3.1. Maxwell est, quant à lui, limité à OpenGL 3.3 à cause de l’absence de gestion des nuanceurs ([_shaders_](https://fr.wikipedia.org/wiki/Shader)) de [tessellation](https://en.wikipedia.org/wiki/Tessellation_%28computer_graphics%29) et de la gestion du chargement et de l’enregistrement direct d’image [_Image Load/Store_](https://www.opengl.org/wiki/Image_Load_Store). Cette gestion est cependant en cours de développement, ce qui devrait permettre à tous les processeurs graphiques qui le gèrent d’exposer OpenGL 4.5 et OpenGL ES 3.2 avant la fin de l’année ! Pour finir, les possesseurs de cartes graphiques de milieu et de haut de gamme peuvent désormais suivre la consommation énergétique de leur processeur graphique, chose qui n’est pas possible avec les pilotes officiels de NVIDIA. ### Raspberry Pi (pilote vc4) De nombreuses améliorations de la couche 3D du Raspberry _Pi_ ont été faites, tant du côté DRM (noyau) que VC4 Gallium3D (espace utilisateur). Grâce à l’amélioration du _pipelining_ et du rendu, certains tests gagnent jusqu’à 20 à 30 %, même si dans les jeux, cela est moins spectaculaire. Cela est fait via l’utilisation de fils d’exécution (_threads_) qui permettent de limiter les passages à vide. Pour plus d’informations, vous pouvez consulter la [demande d’intégration](https://lists.freedesktop.org/archives/dri-devel/2016-March/102793.html). ### Autres Le pilote [_Exynos_](https://fr.wikipedia.org/wiki/Exynos) (Samsung) reçoit dans cette version la gestion des systèmes monopuces 5420 et 5422. [[demande d’intégration](https://lists.freedesktop.org/archives/dri-devel/2016-March/102072.html)] Le pilote _msm_ (Qualcomm) [gère dorénavant](https://lists.freedesktop.org/archives/dri-devel/2016-March/102216.html) l’Adreno 430, ainsi que le HDMI pour les SnapDragon 820. ##Réseau ### Pilotes Divers ajouts et améliorations sur les puces Realtek. ### Coupe‐feu Ajout de nouveau type BFP, le filtre [BFP](https://en.wikipedia.org/wiki/Berkeley_Packet_Filter) est par exemple utilisé dans le coupe‐feu pour l’optimiser. ### Autre Traitement par fil d’exécution des entrées TCP et UDP, un multiplexeur pour les flux TCP, la gestion du [802.1AE MACsec](https://fr.wikipedia.org/wiki/IEEE_802.1AE), divers travaux de décharge de la couche réseau (par exemple, le calcul de la somme de contrôle en local). ##Sécurité ### MPK-PKeys Les clefs de protection mémoire ([_Memory Protection Keys_](https://en.wikipedia.org/wiki/Memory_protection#Protection_keys)) sont des mécanismes de protection de la mémoire. Elles associent une page mémoire à une clef, et lors d’un accès à cette page mémoire, la clef est vérifiée afin de s’assurer que seul le programme autorisé y accède. Ce mécanisme sera ajouté lors d’une prochaine version des microprocesseurs Intel. ### 32 bits Pour la sécurité des programmes 32 bits, la [distribution aléatoire de l’espace d’adressage](https://fr.wikipedia.org/wiki/Address_space_layout_randomization) est activée, cela permet de se défendre d’un attaquant qui essayerait d’injecter des données à une adresse déterminée à l’avance. ##Systèmes de fichiers ### ext4 Il y a beaucoup de corrections, d’optimisations lors du changement de position dans un fichier, une meilleure mise à l’échelle des attributs étendus (`xattr`) et diverses corrections de bogues. ### F2FS Il y a des changements pour la partie chiffrement, des améliorations des entrées‐sorties asynchrones (AIO — [Asynchronous I/O](https://en.wikipedia.org/wiki/Asynchronous_I/O)), des optimisations du changement de position dans un fichier. ### XFS Les nouveautés sont une meilleure gestion des erreurs pour les échecs d’entrées‐sorties directes (`O_DIRECT`), une nouvelle interface pour les quotas, des corrections de bogues, une réduction des informations dupliquées entre XFS et VFS (couche d’abstraction de système de fichiers du noyau), nettoyage des drapeaux du tampon. ###OrangeFS [OrangeFS](http://www.orangefs.org/) est désormais pris en charge par le noyau Linux. Il est principalement utilisé dans les grappes de serveurs présentes dans les universités, les centres de recherche et les entreprises. C’est, au même titre que CeFS ou [[GlusterFS]], un système de fichiers décentralisé réparti. Il a été en partie élaboré lors d’études de la NASA pour les schémas d’entrées‐sorties parallèles. Il gère la répartition entre plusieurs serveurs, les accès simultanés de plusieurs clients, et garde les données et méta‐données via les systèmes de fichiers locaux. ##Virtualisation ### Espaces de nommage pour les cgroups Ce petit code de seulement 600 lignes était en gestation depuis deux ans, il est utilisé pour faire le lien entre les [_cgroups_](https://fr.wikipedia.org/wiki/Cgroups) (pour gérer un bloc de processus) et l’espace de nommage (isolation et vue unique d’un groupe de processus). Ce correctif permet de virtualiser les _cgroups_ pour ne pas exposer d’informations globales et critiques dans un espace de nommage et permet d’améliorer la virtualisation de [[LXC]], [Docker](https://fr.wikipedia.org/wiki/Docker_%28logiciel%29) et [VServer](https://fr.wikipedia.org/wiki/Linux-VServer). ###Virtio L’interface [[Virtio]] bénéficie de plusieurs améliorations : entre autres, _virtio_net_. Ce correctif permet à l’utilisateur d’obtenir et modifier la vitesse et le duplex du dispositif réseau via _ethtool_. Avoir cette fonctionnalité est très utile pour simuler des environnements différents et c’est parfois nécessaire quand les paramètres appropriés en vitesse et duplex sont requis. ###Autres Diverses améliorations [pour Xen et KVM](http://kernelnewbies.org/Linux_4.6#head-fd2bdcb2f218ad638d1f8370176f7eb9017338fd). # Intégration dans les distributions Le noyau Linux 4.6 : - est intégré dans les distributions [Arch Linux et SparkyLinux](http://linux.softpedia.com/blog/arch-linux-and-sparkylinux-are-among-the-first-distros-to-offer-linux-kernel-4-6-504135.shtml) ; - sera intégré dans [Fedora 24 après sa sortie prévue pour mi‐juin 2016](http://news.softpedia.com/news/fedora-developers-discuss-if-fedora-24-should-ship-with-linux-kernel-4-6-or-not-504180.shtml). # Le bilan en chiffres Cette version du noyau 4.6 a donné lieu à la participation de 1 661 développeurs, ce qui est un nouveau record, en battant le nombre des 1 625 contributeurs de la version 4.3. Parmi eux, 283 de ces développeurs ont fait leur premier _commit_ au noyau au cours de ce cycle de développement. Les développeurs les plus actifs en nombre de modifications sont Arnd Bergmann (204), Chaehyun Lim (197) et Oleg Drokin (165). En nombre de lignes de code, Faisal Latif (28 327), Dennis Dalessandro (16 034) et Mike Marshall (15 434) ont été les plus productifs. Arnd Bergmann, développeur de longue date du noyau, est en tête de liste, principalement pour son travail en cours pour l’élimination des avertissements de compilation sur ARM. Faisal Latif est le premier contributeur en nombre de lignes pour l’ajout du pilote infiniBand _i40iw_. Parmi les entreprises les plus contributrices à ce noyau, c’est incontestablement Intel qui l’emporte loin devant Red Hat, Linaro et IBM. À noter, un nouveau venu parmi ces noms connus et habitués dans ce classement : Omnibond Systems, la société derrière OrangeFS. Plus de chiffres sur ces contributions sur [_LWN.net_](http://lwn.net/Articles/686697/). #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 | [goernil](http://linuxfr.org/users/goernil) **Arch** | | [Herman BRULE (alpha_one_x86)](//linuxfr.org/users/alpha_one_x86) **Développeurs** | | **Pilotes graphiques libres** | [Martin Peres](https://linuxfr.org/users/mupuf) | **Réseau** | Aucun | [Herman BRULE](//linuxfr.org/users/alphaonex86) **Systèmes de fichiers** | Aucun | [Herman BRULE (alpha_one_x86)](//linuxfr.org/users/alpha_one_x86) **Sécurité** | | **Virtualisation** | [Xavier Claude](//linuxfr.org/users/claudex) | **Édition générale** | Aucun | [Moul](//linuxfr.org/users/m5oul), [eggman](//linuxfr.org/users/eggman), [Yassin Philip](http://linuxfr.org/users/philippemc), [jcr83](//linuxfr.org/users/jcr83) 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 によって変換されたページ (->オリジナル) /