URL: https://linuxfr.org/news/sortie-du-noyau-linux-4-3 Title: Sortie du noyau Linux 4.3 Authors: jcr83 Davy Defaud, esdeem, Florent Fourcot, Tiwaz, Martin Peres, M5oul, ariasuni, Christophe, Benoît Sibaud, claudex, med, palm123, BAud, cosmocat, Jarvis, rogo, Strash, Creak et ʭ ☯ Date: 2015年09月14日T15:19:37+02:00 License: CC By-SA Tags: sortie_version, noyau_linux, coulisses, kernel, linus_torvalds, fedora et lwn Score: 113 La sortie de la version stable 4.3 du noyau Linux a été annoncée le 1^(er) novembre 2015 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 se trouve dans la seconde partie de la dépêche, publiée sous [licence CC BY-SA](http://creativecommons.org/licenses/by-sa/3.0/deed.fr), Attribution — Partage dans les Mêmes Conditions. **Note** : Tout le monde peut participer à la [[[rédaction]]] de cette dépêche. Vous pouvez même vous proposer pour des [sections qui vous intéressent](https://linuxfr.org/redaction/news/sortie-du-noyau-linux-4-3#appel-%C3%A0-volontaires) et il y a même de [l’aide pour ceux qui voudraient s’y mettre et n’osent pas franchir le pas](//linuxfr.org/wiki/rediger-des-depeches-noyau). ---- [Dépêches des noyaux précédents](https://linuxfr.org/wiki/depeches_noyau) [ Site officiel du noyau Linux](https://www.kernel.org/) [Die Neuerungen von Linux 4.3](http://www.heise.de/open/artikel/Die-Neuerungen-von-Linux-4-3-2860564.html) ---- #En bref * Suppression du code d’ext3 étant donné qu’ext4 peut gérer ces partitions. * Mécanisme anti *fork-bomb* avec `cgroup_pids`. * Meilleure migration à chaud de machines virtuelles grâce au passage des *page faults* en espace utilisateur. * Adressage d’un réseau local IPv6 par *Identifier Locator Addressing*. #Annonces des RC par Linus Torvalds ##RC-1 La version [RC-1](https://lkml.org/lkml/2015/9/12/243) est sortie le samedi 12 septembre 2015 :> _Aujourd’hui, cela a été plutôt calme (ce qui est normal : en général, il y a un petit surplus d’activité le dernier vendredi de la fenêtre d’intégration, mais la fin de semaine est plus calme) et j’ai décidé de ne pas tenir compte de tout ce qui pourra arriver demain, de fermer tout de suite la fenêtre d’intégration et de publier la RC-1._> > _Je m’attendais à ce que la version 4.3 soit plutôt petite après les gros changements apportés par la version 4.2, mais ce n’est pas vraiment le cas – sa taille est plutôt moyenne, en fait. En effet, tout paraît normal, avec des modifications réparties à 70 % pour les pilotes, 10 % pour les mises à jour des architectures et les 20 % restants éparpillés (systèmes de fichiers, réseau, outils, documentation, gestion de la mémoire et mises à jour du « cœur » du noyau, etc.)._> > _Du côté des pilotes, les pilotes graphiques en constituent une grosse part, en partie à cause des mises à jour de Nouveau qui n’avaient pas pu être intégrés dans la 4.2, donc il y a là en fait une mise à jour qui en vaut deux. Mais il y a aussi des mises à jour de pilotes dans la plupart des autres sous‐systèmes : réseau (filaire et sans‐fil), recette ([_staging_](http://www.kroah.com/log/linux/linux-staging-update.html "The Linux Staging Tree, what it is and is not"))_ [N. D. T. : branche de mise au point centralisée avant intégration à la branche principale]_, média, cryptographie, contrôleur de broches (pinctrl), pour n’en nommer que quelques‐unes._>> _Les mises à jour d’architectures sont pour moitié sur ARM (notamment les mises à jour de l’arborescence matérielle [devicetree]), avec l’autre moitié éparpillée (x86, MIP, ARM64, PowerPC, s390)._> > _Du côté des systèmes de fichiers, le gros du changement (en lignes de code) est la suppression du système de fichiers ext3 (ext4 assurant encore la prise en charge du ext3 — mais le code spécifique à ext3 a disparu). Mais il y a aussi des mises à jour diverses un peu partout : F2FS, Btrfs, NFS, XFS, UFS, GFS2, proc..._> > _Comme d’habitude, l’historique complet des changements est trop gros pour être publié, par conséquent je joins mon historique de fusion qui donne une idée des changements intégrés et de l’ensemble de la situation..._> > _Allez‐y, testez,_> > _Linus_ ##RC-2 La version [RC-2](https://lkml.org/lkml/2015/9/20/159) est sortie le dimanche 20 septembre 2015 :> _Nous revenons au calendrier dominical habituel, voici donc la RC-2. Comme c’est la tendance depuis un moment maintenant, la RC-2 est assez petite, probablement parce qu’il faut un bout de temps avant que les rapports de régression ne commencent à arriver peu à peu (et certaines personnes attendent probablement délibérément la RC-2 pour ne serait‐ce que commencer à tester — vous, vous êtes des trouillards)._>> _Quoi qu’il en soit, tout semble plutôt normal. Il y a quelques perturbations un peu partout dans l’arborescence à cause du ménage effectué dans le gestionnaire de flux des interruptions_ [IRQ flow-handler] _qui a enlevé le paramètre redondant de numéro d’interruption. Mais à part ce changement ponctuel, c’est plutôt calme et succinct — nous verrons si ça va continuer. Touchons du bois._>> _Sinon, c’est le mélange habituel de corrections d’architectures et de pilotes, avec une pincée d’autres choses (les mises à jour de l’outillage de performances sortent du lot, par exemple). Je n’ai rien vu de particulièrement alarmant et le résumé ci‐joint, donne tous les détails plutôt ennuyeux._>> _Donc, si quelqu’un n’a pas osé faire la mise à jour juste après la fin de la période d’intégration, qu’il se lance. On a besoin de gens pour tester et remonter les problèmes._>> _Linus_ ##RC-3 La version [RC-3](https://lkml.org/lkml/2015/9/27/42) est sortie le dimanche 27 septembre 2015 :> _Et comme d’habitude, la RC-3 est de fait plus grosse que la RC-2 (les corrections commencent à affluer), mais rien de particulièrement alarmant ne sort du lot._>> _Tout paraît normal : l’essentiel concerne les pilotes (un peu partout, mais les pilotes graphiques et le réseau sont les parties les plus importantes), ainsi que les mises à jour d’architectures. Il y a aussi des mises à jour du réseau et des systèmes de fichiers, accompagnés de documentation._>> _Allez la récupérer,_>> _Linus_ ##RC-4 La version [RC-4](https://lkml.org/lkml/2015/10/04/128) est sortie le dimanche 4 octobre 2015 :> _Vous savez tous comment ça se passe maintenant. C’est dimanche, et il y a une nouvelle version candidate._>> _Tout semble plutôt normal. Nous avons notablement moins de modifications que dans la RC-3 (qui était particulièrement grosse) et je ne vois rien d’exceptionnellement alarmant. Les statistiques semblent également tout à fait normales : un peu moins de la moitié des modifications concernent des pilotes (DRM continue à être notable, mais il y aussi InfiniBand, MMC, la couche d’entrées, etc.). À peu près un quart est constitué des mises à jour d’architectures (m68k, MIPS, x86) et le dernier quart est complètement varié (mise à jour de la documentation, outils, scripts, ordonnanceur, gestion de la mémoire...)._>> _La liste des changements jointe donne une idée des détails._>> _Linus_ ##RC-5 La version [RC-5](https://lkml.org/lkml/2015/10/11/132) est sortie le dimanche 11 octobre 2015 :> _Le cycle de publication de la 4.3 se poursuit en douceur — touchons du bois. Il n’y a rien de particulièrement inquiétant ici : on a eu quelques retombées ennuyeuses provenant de la nouvelle fonction `strscpy()` (elle n’est pas encore_ réellement _utilisée, mais on a eu des erreurs de compilation sur certaines architectures) et un changement dans la couche VFS qui a révélé un problème ancien et fascinant sur ext[3-4] ; mais dans l’ensemble, tout semble plutôt normal. C’est l’habituel « plein de petites corrections sur le code des pilotes et des architectures, saupoudrées de quelques mises à jour des systèmes de fichiers en guise de diversité ». Le résumé ci‐joint donne un aperçu des détails._>> _L’activité semble également se calmer gentiment, bien que, comme il n’y a pas eu de récupération de code réseau cette semaine, on pourrait bien en trouver un paquet dans la prochaine RC._>> _Quoi qu’il en soit, si vous n’avez pas testé un noyau récent dernièrement, n’hésitez pas à vous lancer dès maintenant — ça a l’air pas mal du tout._>> _Linus_ ## RC-6 La version [RC-6](https://lkml.org/lkml/2015/10/18/303) est sortie le dimanche 18 octobre 2015 :> _Cela continue à être calme, et même de plus en plus calme. J’en suis vraiment heureux, bien que ma nature suspicieuse cherche quelque chose à critiquer. Les gens se comportent‐ils de leur mieux en raison du_ [Kernel Summit](http://events.linuxfoundation.org/events/linux-kernel-summit "Linux Kernel Summit 2015") _qui approche, tout le monde cherchant à se montrer sous son meilleur angle ?_>> _Ou peut‐être est‐ce simplement l’une de ces rares et indolores versions où rien de mauvais n’arrive ?_>> _Ce serait adorable._>> _Qu’importe la raison, il n’y a rien de bizarre ou d’effrayant en vue, et le journal résumé ci‐joint est agréable et court. La quasi-totalité concerne les pilotes, avec notamment les correctifs sur InfiniBand et les pilotes graphiques. Mais même là, le plus gros correctif (et de loin) consiste simplement en une clarification du message de copyright dans InfiniBand, qui à lui seul forme un tiers de l’ensemble du correctif. Car le reste est vraiment mineur._>> _En dehors des corrections de pilote, il y a quelques toutes petites mises à jour d’architectures (le plus gros étant quelques corrections de KVM sur x86 pour l’émulation SMM, mais même ces dernières ne sont en aucun cas énormes). Et une poignée de corrections d’une ligne concernant la gestion mémoire._>> _Autrement dit, tout a l’air vraiment bien. Touchons du bois._>> _Linus_ ## RC-7 La version [RC-7](https://lkml.org/lkml/2015/10/25/2) est sortie le dimanche 25 octobre 2015 :> _Il est possible qu’il soit encore samedi chez moi, mais grâce au_ [Kernel Summit](http://events.linuxfoundation.org/events/linux-kernel-summit "Linux Kernel Summit 2015") _à venir en Corée, j’ai pris une longueur d’avance avec un fuseau horaire de +9 h, et ici c’est dimanche. Donc c’est le jour de la publication._>> _Cette RC casse la tendance de « réduction agréable et d’accalmie », principalement en raison au fait que nous avons intégré les corrections réseau en RC-7 (mais pas en RC-6). Il y a aussi quelques autres intégrations un peu plus grosses (corrections de systèmes monopuces ARM, pilotes graphiques, couche bloc et média) et évidemment toutes les corrections de pilotes divers, etc. Mais les changements réseau sont la raison pour laquelle cette RC a l’air quelque peu différente des précédentes._>> _Et malgré cette petite augmentation de taille, rien n’a l’air particulièrement inquiétant et ce cycle de publication continue à se dérouler en douceur. Comme déjà évoqué auparavant, la semaine prochaine est celle du_ [Kernel Summit](http://events.linuxfoundation.org/events/linux-kernel-summit "Linux Kernel Summit 2015") _et, avec un grand nombre de mainteneurs principaux occupés à Séoul, je présume que les choses resteront calmes et, à moins que quelque chose de bizarre ne survienne, je sortirai la 4.3 finale dimanche prochain (d’ici là, je serai de retour dans mon fuseau horaire habituel)._>> _Le journal résumé ci‐joint est disponible pour les gens qui veulent inspecter les détails._>> _Linus_ ## Version finale La [version finale](https://lkml.org/lkml/2015/11/1/202) est sortie le dimanche 1^(er) novembre 2015 :> _Alors, la dernière semaine de la série des RC semblait chargée au point que je commençais à m’inquiéter pour la publication finale. Mais, les chiffres montrent qu’en réalité il ne s’agissait que d’une impression subjective de ma part, probablement due au_ [Kernel Summit](http://events.linuxfoundation.org/events/linux-kernel-summit "Linux Kernel Summit 2015") _et au voyage de retour de la Corée à chez moi. Ce n’était pas vraiment une semaine particulièrement chargée, c’est juste que les demandes d’intégration ont été plus importantes dans les tout derniers jours._>> _On a eu une mise à jour du code réseau et une correction tardive pour un bogue du mode vm86 sur x86 introduit par les nettoyages de vm86, mais à part ça c’est juste un ensemble de petites corrections d’une ligne un peu partout. OK, le truc sur le mode vm86 était également une correction d’une ligne, mais il s’agissait d’une chose un peu plus angoissante, car ça avait l’air plus effrayant que ça ne l’était en réalité, jusqu’à ce que quelqu’un (Andy) comprenne ce qu’il se passait._>> _Les changements depuis la RC-7 sont dominés par les trucs réseau, mais comme vous pouvez le voir sur le journal résumé ci‐joint, il n’y a rien de particulièrement inquiétant._>> _Donc, dans l’ensemble, ça reste un cycle de publication assez calme jusqu’à la fin. Et avec la sortie de la 4.3, la fenêtre d’intégration pour la 4.4 est évidemment ouverte, et gardons les doigts croisés pour que ce soit une publication tout aussi tranquille. Tout spécialement depuis que Greg a décidé, par anticipation (c’est une expérience amenée par une discussion lors du_ [Kernel Summit](http://events.linuxfoundation.org/events/linux-kernel-summit "Linux Kernel Summit 2015")_) que la 4.4 serait une autre version LTS_ [N. D. T. : _Long Term Support_ — maintenance à durée étendue].>> _Linus_ #Les nouveautés ##Architecture Plusieurs améliorations ont permis de diminuer le temps de démarrage du noyau sur système x86. Len Brown, d’Intel, continue à travailler sur l’optimisation du démarrage sur x86. Son travail porte principalement sur quatre correctifs [[plus de détails sur _Phoronix.com_](https://www.phoronix.com/scan.php?page=news_item&px=Linux-x86-Boot-4.3)]. Nous avons ainsi un gain de 700 μs sur trois correctifs et un peu d’élimination de code mort. ###Une meilleure analyse de performance sur certains processeurs `perf` est un outil déjà très puissant pour l’étude des performances sous Linux. Avec certains processeurs Intel, cette analyse pourra désormais être encore plus précise grâce à la récupération d’informations par `perf` directement sur la puce avec le [_processor trace_](https://software.intel.com/en-us/blogs/2013/09/18/processor-tracing) (PT). Parmi les promesses de ce matériel, on a notamment un meilleur suivi des applications avec plusieurs fils d’exécution (_threads_). C’est bien entendu des développeurs d’Intel qui ont proposé l’ajout des modifications en plusieurs parties. On a ainsi dans le détail [un décodeur pour PT](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f4aa081949e7b6b01e711229c5a47ee3482a169c), le [code pour gérer le PT](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=90e457f7be0870052724b2d9c2c106e5847f2c19), l’ajout du [nécessaire dans `perf`](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5efb1d5489520ce72232bbc28e9156f0ebddc44e), un script d’[exemple de suivi de performance de PostgreSQL](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4b715d24f4f14731c7b553cbb8604fe865cb8d3c). ### Prise en charge ARMv8.1 Linux 4.3 prend désormais en charge l’architecture ARMv8.1 (disponible avec le [Tegra X1](http://www.cnx-software.com/2015/01/05/nvidia-tegra-x1/), par exemple). Cette dernière est une mise à jour mineure de la spécification ARMv8, qui apporte principalement la prise en charge des processeurs 64 bits dans le monde ARM. Les nouveautés implémentées pour ARMv8.1 sont le PAN, le LSE et la prise en charge de DBM. Le PAN est un acronyme en anglais pour _Privileged Access Never_ — aucun accès privilégié — et représente la solution ARM pour empêcher les déréférencements dans le noyau. LSE, _Large System Extension_ — extension système large — est utilisé pour construire des verrous et des opérations atomiques utilisables à grande échelle. Enfin, DBM — _[Dirty Bit Management](https://en.wikipedia.org/wiki/Dirty_bit)_ — est le système de gestion du bit « sale » qui sert principalement à la mise à jour propre et automatique des entrées dans la table des pages de la mémoire virtuelle paginée ([PTE](https://fr.wikipedia.org/wiki/M%C3%A9moire_virtuelle#M.C3.A9moire_virtuelle_pagin.C3.A9e)). [Article de CNXSoft : [_Linux 4.3 Release — Main Changes, ARM and MIPS Architectures_](http://www.cnx-software.com/2015/11/04/linux-4-3-release-main-changes-arm-and-mips-architectures/)] ### Amélioration de la prise en charge des systèmes monopuces ARM - Nouvelle prise en charge des systèmes monopuces 64 bits ARM suivants : 1. Broadcom North Star 2 (pas encore disponible) ; 2. Marvell Berlin4CT (pas encore disponible) ; 3. Mediatek MT6795 (la réponse de Mediatek au SnapDragon 810 et sa volonté de venir sur le marché du haut de gamme) ; 4. [Rockchip RK3368](https://fr.wikipedia.org/wiki/Rockchip_RK3368) disponible par exemple [_ici_](https://plus.google.com/+charbax/posts/1EWmUYjnw9i). C’est sans doute la carte ARM 64 bits la moins chère du marché. - Plus de 23 000 lignes de code pour l’arborescence matérielle _DeviceTree_. Cela permet de prendre en charge dans le noyau principal les [Chromebooks Rockchip](http://liliputing.com/2015/03/google-introduces-low-cost-chromebooks-for-education-with-rockchip-processors.html), la [carte d’évaluation i.MX6UL](https://community.freescale.com/thread/376844), les modules [Gumstix Overo](https://store.gumstix.com/coms/overo-coms.html) et le matériel [UniPhier](http://pdf.directindustry.com/pdf/panasonic-industrial-robot-welding/panasonic-integrated-platform-digital-appliances-uniphier/29315-566484.html). - Nouveaux pilotes Qualcomm SMM/SMD pour communiquer avec les coprocesseurs de certaines plates‐formes, ainsi que des ajouts pour Tegra (Tegra X1 et Denver). ### MIPS n’est pas mort Ajout de la prise en charge du processeur 64 bits [MIPS I6400](http://blog.imgtec.com/mips-processors/mips-i6400-the-leading-64-bit-cpu-revealed-coverage-roundup) et amélioration de la prise en charge des Octeon Cavium CN68xx. ###s390 Ajout intéressant, la prise en charge de la NUMA ([architecture mémoire non unifiée, introduite par AMD dans son architecture Bulldozer](https://fr.wikipedia.org/wiki/Non_Uniform_Memory_Access "Non Uniform Memory Access")) pour s390. Enfin, la prise en charge d’une fausse NUMA, ou une NUMA purement logicielle, pour distribuer la mémoire sur les différents processeurs. Il semblerait que sous certaines circonstances, cela améliore les performances du système, et/ou sa latence. ###AMD Carrizo Linux 4.3 rend désormais disponibles, via le sous‐système `hwmon`, les informations énergétiques communiquées par les processeurs de la génération Carrizo d’AMD (les [APU](https://fr.wikipedia.org/wiki/Accelerated_processing_unit "Accelerated Processing Unit") A10 par exemple). ## IPC KDBUS a reçu de [nombreuses modifications](https://www.phoronix.com/scan.php?page=news_item&px=KDBUS-Big-Updates). [Il était déjà utilisé dans Fedora _Rawhide_](https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Rawhide-Kernel-KDBUS) (la branche instable) depuis le 30 juillet, mais a été [retiré récemment](https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Drops-KDBUS). Certains aspects de KDBUS pourraient être repensés, ce qui signifie que l’intégration officielle de KBDUS dans Linux a peu de chances d’avoir lieu pendant le cycle de la version 4.4. Pour rappel, l’intégration de KDBUS avait été [proposée pour Linux 4.1](https://www.phoronix.com/scan.php?page=news_item&px=KDBUS-Missing-Linux-4.1) et a été [reportée durant le cycle de la 4.2](https://www.phoronix.com/scan.php?page=news_item&px=KDBUS-Not-In-Linux-4.2). ##Développement - Introduction d’une nouvelle structure logicielle (_framework_) pour les pilotes de périphériques à mémoire non volatile qui devrait être utilisée lors de la sortie de la technologie [Intel 3D XPoint](https://fr.wikipedia.org/wiki/3D_XPoint). La [documentation de NVmem](https://www.kernel.org/doc/Documentation/nvmem/nvmem.txt) (pour _Non Volatile memory layer_) est disponible sur le site _kernel.org_. - L’appel système `membarrier()` a enfin été intégré. C’est un correctif qui est en gestation depuis au moins 2010. Il permet de forcer la synchronisation entre processeurs, mais uniquement sur les processeurs qui font fonctionner l’application qui requiert cette synchronisation. Consultez l’[article de _LWN.net_](https://lwn.net/Articles/369567/), en anglais, pour plus de détails. - La gestion des erreurs d’entrées‐sorties bloquantes a été simplifiée. Il y a désormais un nouveau champ `bi_error` dans la structure _bio_ qui sert à stocker un code d’erreur. L’utilisation de `bi_end_ui()` a été supprimée. - Changement dans l’interface `static-key`, qui provoquait des confusions de nommage. - Le module de signature utilise désormais [PKCS#7](https://tools.ietf.org/html/rfc2315), ce qui nécessite d’avoir _openssl-devel_ disponible pour construire le noyau avec ce module. ##Pilotes graphiques libres ### Direct Rendering Manager Rien de bien intéressant dans le code commun des pilotes graphiques libres, si ce n’est des corrections de bogues dans la partie liée à la gestion atomique du mode graphique. Plusieurs nouveaux contrôleurs d’affichage sont maintenant [gérés par Linux](http://lists.freedesktop.org/archives/dri-devel/2015-August/088489.html). Pour plus d’informations, vous pouvez consulter la [demande d’intégration de DRM](https://lkml.org/lkml/2015/9/4/698). ### AMD/ATI #### Pilote de rendu nouvelle génération (pilote amdgpu) Les cartes graphiques haut de gamme AMD R9 _Fiji_ sont maintenant partiellement gérées par Linux. Cette famille a été commercialisée dès la fin du mois de juin 2015. Autre nouveauté, l’ajout d’un ordonnanceur pour le processeur graphique. Son rôle est de répartir de manière plus juste les ressources de calcul du processeur graphique, mais aussi de donner la priorité aux applications les plus importantes. C’est notamment le cas du compositeur qui utilise le processeur graphique pour composer l’image à l’écran. Il a besoin de produire de façon prédictible la prochaine image avant la synchronisation verticale de l’écran, sous peine d’avoir à jeter les images qui ont été calculées, mais jamais affichées. Pour plus d’informations, vous pouvez consulter [les](http://lists.freedesktop.org/archives/dri-devel/2015-August/088642.html) [demandes](http://lists.freedesktop.org/archives/dri-devel/2015-August/089261.html) [d’intégration](http://lists.freedesktop.org/archives/dri-devel/2015-September/089813.html). #### Pilote HSA (pilote amdkfd) AMD ajoute la gestion des processeurs à unité graphique intégrée ([APU](https://fr.wikipedia.org/wiki/Accelerated_processing_unit "Accelerated Processing Unit")) Carrizo, sortis en juin 2015, au pilote _amdkfd_, qui permet de faire communiquer plus rapidement le processeur graphique et le processeur central. Pour plus d’informations, vous pouvez consulter la [demande d’intégration](https://www.spinics.net/lists/dri-devel/msg86504.html). ### Intel (pilote i915) L’unité graphique des processeurs Intel Skylake _Gen9_ est maintenant gérée par défaut et ne nécessite plus de passer d’argument au noyau. Les autres nouveautés sont plus cachées, mais restent importantes. La plus notable est la gestion du mode graphique classique qui utilise maintenant le code de la gestion atomique, ce qui permet de tester ces parties de code un peu plus avant qu’elles puissent être activées par défaut. Toujours du côté de l’affichage, la gestion des profondeurs de couleur de 12 bits par composante est maintenant disponible et activée par défaut pour le HDMI et les écrans compatibles. Du côté de la gestion d’énergie, la fréquence de l’horloge du contrôleur d’affichage est maintenant dynamique, ce qui permet d’économiser de l’énergie lorsque des écrans à basse ou haute résolution (non 4K) sont présents. La gestion de la compression du tampon de trame (_framebuffer_), ainsi que la gestion du mode d’auto‐rafraîchissement de l’écran avancent encore, mais restent désactivées par défaut, car elles provoquent des blocages de l’écran sur certains systèmes. Le code de suivi des requêtes, qui permet de savoir si une tâche soumise de façon asynchrone au processeur graphique a été exécutée ou pas encore, a été revu afin de prendre en charge la synchronisation entre plusieurs processeurs graphiques, mais également pour la venue éventuelle d’un ordonnanceur (voir la partie AMD). Ce travail n’est cependant pas encore terminé, la suite dans la prochaine dépêche noyau ! Pour plus d’informations, vous pouvez consulter l’[article de blog du mainteneur i915](http://blog.ffwll.ch/2015/09/neat-drmi915-stuff-for-43.html). ### Matrox (pilote mgag200) Le pilote Matrox, qui n’avait pas reçu de modification depuis deux ans, vient de bénéficier de la gestion d’une nouvelle famille de processeurs graphiques, ainsi qu’une variante dans la famille précédente. Pour plus d’informations, vous pouvez consulter les [deux](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm?id=6d857c18aefdec782ba1db578a390fbac5145107) [_commits_](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm?id=e829d7ef9f17d7b84d4c3d110ecd4b7b2bcba865). ### NVIDIA (pilote nouveau) Nouveau n’avait pas reçu de changement dans Linux 4.2, car un gros changement était en cours. Il fait son entrée dans Linux 4.3 et modifie la façon dont les différents modules sont initialisés et utilisés, afin que le compilateur puisse plus facilement détecter des erreurs d’accès. Le code qui en résulte est, de plus, bien plus simple à lire et modifier. Ben Skeggs en a également profité pour revoir l’interface NVIF. Cette dernière a pour but d’exposer à l’espace utilisateur ou à des machines virtuelles les objets internes à Nouveau. Cette interface n’a encore jamais été utilisée. Ce changement n’est donc pas problématique. NVIDIA, par le biais d’Alexandre Courbot, a ajouté le code de gestion préliminaire pour les processeurs Tegra basés sur l’architecture Maxwell ([GM20B](http://nouveau.freedesktop.org/wiki/CodeNames/)). Cette gestion est cependant inutilisable, car elle [requiert un microcode signé par NVIDIA](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm?id=8539b37acef73949861a16808b60cb8b5b9b3bab) qui n’a pas encore été rendu public. Ce processeur est maintenant facilement accessible aux passionnés grâce à la carte de développement [Jetson TX1](http://www.nvidia.com/object/jetson-tx1-module.html). Samuel Pitoiset a retravaillé le code de configuration et lecture des compteurs de performance globaux avant d’ajouter la gestion des compteurs qu’il a effectuée en rétro‐ingénierie pour les familles [NV50](http://nouveau.freedesktop.org/wiki/CodeNames/#nv50familytesla) et [NVC0](http://nouveau.freedesktop.org/wiki/CodeNames/#nvc0familyfermi). Pour l’instant, peu de signaux sont reconnus pour la famille NVC0, mais le travail de rétro-ingénierie devrait reprendre, quand l’infrastructure au complet sera en place. À cette fin, il manque une bibliothèque en espace utilisateur pour accéder à l’interface NVIF [introduite dans Linux 3.17](http://linuxfr.org/news/sortie-de-linux-3-17#nvidia-pilote-nouveau) pour Nouveau et modifiée dans Linux 4.3. Il restera ensuite à modifier [Mesa 3D](https://fr.wikipedia.org/wiki/Mesa_3D) pour exposer ces compteurs via l’interface OpenGL [`GL_AMD_performance_monitor`](https://www.opengl.org/registry/specs/AMD/performance_monitor.txt) et l’afficheur tête haute de [[Gallium3D]] [`GALLIUM_HUD`](http://www.mesa3d.org/envvars.html). Ces modifications sont le fruit d’un travail de longue haleine de la part de Samuel. Il a commencé à travailler sur ce sujet lors du _Google Summer of Code 2013_. Une page détaillant l’[état d’avancement](http://nouveau.freedesktop.org/wiki/PerformanceCounters/) de l’implémentation de la gestion des compteurs de performance est en cours de construction. Roy Spliet a ajouté la gestion du recadencement manuel pour les cartes [NVA0](http://nouveau.freedesktop.org/wiki/CodeNames/) et l’a activée par défaut. Pour plus d’informations, vous pouvez consulter la [présentation récapitulative de l’état du pilote](https://www.youtube.com/watch?v=dnG0X0uwLuY) faite au [XDC2015](http://www.x.org/wiki/Events/XDC2015/ "X.Org Developer’s Conference 2015") par Alexandre Courbot (NVIDIA) et Martin Peres (hobbyiste) ou sa [transcription faite par _LWN.net_](http://lwn.net/Articles/659391/). ### VMware (pilote vmwgfx) Le pilote _vmwgfx_ de VMware a reçu d’importantes modifications ayant pour but de pouvoir exposer OpenGL 3.3 dans les machines virtuelles. Les modifications apportées sont l’utilisation d’une nouvelle interface de programmation pour la gestion des tampons de trame (_frame buffer_), un nouveau mécanisme d’envoi de commandes qui remplace l’ancien tampon circulaire et la gestion d’un nouveau périphérique virtuel appelé DX qui permet d’obtenir la gestion d’OpenGL 3.3. Les modifications apportées à [Mesa 3D](https://fr.wikipedia.org/wiki/Mesa_3D) (pilote 3D en espace utilisateur) nécessaires pour atteindre OpenGL 3.3 sont actuellement disponibles dans la branche de développement de Mesa 3D et devraient être disponibles prochainement, dans Mesa 3D 11.1. Pour plus d’informations, vous pouvez consulter la [demande d’intégration _vmwgfx_](http://lists.freedesktop.org/archives/dri-devel/2015-August/088455.html), ainsi que le [courriel d’annonce de la fonctionnalité](http://lists.freedesktop.org/archives/dri-devel/2015-August/088246.html). ### Pilotes graphiques pour systèmes monopuces ####Qualcomm Snapdragon (pilote msm) * prise en charge des cartes de développement DragonBoard 410c (les puces ADV7533 nécessitant encore du travail) ; * prise en charge initiale des MSM8x94 (Snapdragon 810) ; * prise en charge des MSM8x74v1 (ajoutée à celle de la v2 existante) ; * prise en charge des plans DMA sur les MDP5 (plans additionnels ne pouvant pas être rééchelonnés) ; * ajout de nouveaux formats d’espace colorimétrique [[YUV]] aux MDP5 (simple plan VYUY, UYVY, YUYV et YVYU ; double plan NV16 et NV61 ; et triple plan YUV420 et YVU420) ; * prise en charge de la rotation pour les MDP5 ; * prise en charge initiale de la protection anticopie [[HDCP]] ; * corrections diverses, etc. ####Freescale Nouveau pilote _fsl-dcu_ prenant en charge la gestion des modes d’affichage du DCU (_Display Controller Unit_) des systèmes monopuces de Freescale. ##Réseau ### Prise en charge initiale des VRF Derrière l’idée des VRF, ou _Virtual Routing and Forwarding_, se cache le fait d’avoir plusieurs tables de routage, afin de se comporter différemment selon l’environnement. Le premier exemple est un équipement en production dont on planifie des changements dans son routage. Grâce aux VRF, l’administrateur pourra conserver la configuration actuelle dans une table et préparer la table à déployer dans un autre VRF. Un autre exemple serait une [application spécifique qui doit utiliser une règle de routage différente](http://linuxfr.org/forums/linux-general/posts/faire-passer-uniquement-le-trafic-d-un-logiciel-par-un-vpn). Cette fonctionnalité s’insère de façon peu intrusive pour qui veut l’utiliser. En effet, il y a déjà des fonctionnalités avancées de routage dans le noyau (notamment configurables avec `ip rule`), qui permettent de faire du routage en fonction de l’adresse IP source, d’un marquage du pare‐feu, etc. Et pour les applications, on peut utiliser l’option `SO_BINDTODEVICE` (`ping -I` par exemple) pour choisir l’interface. On a déjà presque tout : il faut juste lier le domaine de routage (la VRF) à une interface virtuelle (et donc la créer) et gérer les quelques détails (l’isolation [ARP](https://fr.wikipedia.org/wiki/Address_Resolution_Protocol "Address Resolution Protocol") entre les différents domaines notamment). C’est ce que propose cette [demande de changement](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d52736e24fe2e927c26817256f8d1a3c8b5d51a0). À noter que la fonctionnalité n’est pas encore complètement terminée, on ne peut notamment pas utiliser de VRF en IPv6. ###IPv6 ####Compilation par défaut dans le noyau C’est une nouveauté qui n’est pas passée inaperçue, le code pour IPv6 est désormais compilé par défaut dans l’image du noyau (la compilation en module était auparavant le mode par défaut). Il s’agit avant tout d’une décision symbolique, la plupart des grandes distributions ayant déjà configuré leurs noyaux ainsi. Les détails, dans la [demande de modification](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=de551f2eb22a77a498cea9686f39e79f25329109). ####Ajout des _Identifier Locator Addressing_ à IPv6 — le retour de la dualité des IP Les _Identifier Locator Addressing_ (ILA) sont une nouvelle méthode pour tenter de résoudre un bon vieux problème des protocoles IP : une adresse IP est utilisée actuellement à la fois comme identifiant d’équipement et comme information de localisation. Pour le premier cas, vous pouvez ainsi penser à l’utilisation des adresses IP source et destination, pour relier (en complément des numéros de ports) un paquet à une [_socket_](https://fr.wikipedia.org/wiki/Berkeley_sockets) [TCP](https://fr.wikipedia.org/wiki/Transmission_Control_Protocol). Pour le second cas, on parle du routage : l’adresse est lue par les routeurs et permet d’envoyer le paquet au bon endroit. Le premier problème évident avec cette architecture est la mobilité. L’équipement (et on espère donc son identifiant) ne change pas, mais sa localisation si. Un autre souci est le [_multi‐homing_](https://fr.wikipedia.org/wiki/Multi-homing), c’est‐à‐dire avoir plusieurs fournisseurs d’accès pour un équipement. L’équipement aura plusieurs adresses IP, mais on aimerait qu’il puisse être identifié de façon identique avec les deux. Cette dualité de l’adresse IP est bien documentée, par exemple dans la [RFC 4984](https://tools.ietf.org/html/rfc4984#section-2.2), et en français sur le [_blog_ de Stéphane Bortzmeyer](http://www.bortzmeyer.org/separation-identificateur-localisateur.html). Il y a même des protocoles, comme [LISP](https://fr.wikipedia.org/wiki/Locator/Identifier_Separation_Protocol "Locator/Identifier Separation Protocol"), qui devraient permettre d’y remédier s’ils sont déployés. Les ILA qui nous intéressent ici visent un cas d’utilisation bien précis : les machines virtuelles et les services construits pour pouvoir être migrés entre différents serveurs physiques (et donc changer de localisation). La principale motivation de ce travail est le rejet de l’existant, notamment la volonté d’avoir un protocole sans encapsulation (ce que fait LISP) ni en‐têtes supplémentaires dans le paquet IP. Le paquet sera ainsi pleinement traitable par un équipement intermédiaire standard (routeur, pare‐feu...) sans aucune mise à jour. L’encapsulation étant coûteuse en ressource, cette motivation est très compréhensible. Rentrons dans le concret : l’idée est de prendre le format d’une adresse IPv6 standard et de la couper en deux. La première partie sera la localisation (lue par le routage jusqu’à joindre la machine physique du service), la seconde partie servira d’identification (sans aucun lien avec une interface physique). Une application n’a besoin que de la seconde partie, la première moitié sera ajoutée par le noyau lors de l’émission du paquet (qui lui aura l’information de la localisation réelle du service). Pour des questions de compatibilité, les applications rempliront en réalité la première partie avec les informations qu’elles possèdent (exemple : le résultat d’une requête DNS) et le noyau se chargera de récrire les 64 premiers bits (la partie de localisation). C’est le mécanisme de réécriture d’adresse connu habituellement sous le nom de [NAT](https://fr.wikipedia.org/wiki/Network_address_translation "Network Address Translation"), mais utilisé en local. La configuration de tout ça se fait actuellement à l’aide de la commande `ip`, en rajoutant des liens (_mapping_) statiques entre l’identifiant et sa localisation. Si vous voulez quelque chose de vraiment dynamique, il manque donc la partie en espace utilisateur pour mettre à jour les localisations des services. Au niveau de la sécurité, c’est léger, mais documenté par l’auteur. L’absence d’en‐tête supplémentaire empêche également l’ajout d’information pour assurer à l’application que le destinataire qu’il croit contacter à l’aide de l’identifiant est bien l’équipement réellement contacté. Cette technologie ne devra être utilisée que sur des réseaux bien maîtrisés, ce qui permet la simplicité du mécanisme pour un problème aussi complexe. Pour plus d’informations, il y a tout d’abord la [demande de changement](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0b233dc7167884f95f08e796ac6a6767ae7d0d70), qui détaille notamment la (faible) dégradation de performance. Il y a également un [article sur _LWN.net_](https://lwn.net/Articles/657012/) et un [_draft_ à l’IETF](https://tools.ietf.org/html/draft-herbert-nvo3-ila-01) (écrit par l’auteur du code du noyau Linux. Vous pouvez également constater son changement d’employeur entre la v0 et la v1 du _draft_). ###Suivi des connexions Open vSwitch Quand vous avez de nombreuses machines virtuelles, réparties ou non sur différents hyperviseurs, vous avez probablement également envie de virtualiser la commutation des paquets (_switching_) entre les différentes machines virtuelles, afin qu’il soit transparent de migrer des services et d’avoir de bonnes performances. Sous Linux, [Open vSwitch](https://en.wikipedia.org/wiki/Open_vSwitch) est une solution pour remplir ce rôle. Et dans ce nouveau noyau, un utilisateur peut désormais [suivre l’état des connexions Open vSwitch](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7f8a436eaa2c3ddd8e1ff2fbca267e6275085536). ###Performances #### De la qualité de service plus rapide Que serait un nouveau noyau sans des optimisations de performance en réseau ? Pour cette version, on peut citer des changements pour [`tc`](https://linuxfr.org/wiki/une-introduction-au-controle-du-trafic-reseau-avec-linux) (_traffic control_), qui permet de gérer la qualité de service (limiter un utilisateur à un débit, rendre prioritaire certains usages, etc.). Dans la [demande de changement](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=56e5d1ca183d8616fab377d7d466c244b4dbb3b9), l’auteur parle d’un passage sur son environnement de 5 millions de paquets traités par seconde à 11 millions désormais. #### Tunnels légers Malgré les dégradations de performance de l’encapsulation réseau, qui ont été une des motivations du concept des ILA décrites précédemment, encapsuler et décapsuler des paquets est une opération très courante dans les réseaux IP. Pour le grand public, l’une des opérations classiques est notamment d’utiliser un [réseau privé virtuel](https://fr.wikipedia.org/wiki/R%C3%A9seau_priv%C3%A9_virtuel) (VPN pour les intimes). Pour les centres de données, Open vSwitch (OVS) fait également de l’encapsulation. Améliorer les performances et avoir une approche un peu unifiée pour l’encapsulation présente donc un avantage et [une demande de changement](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e69724f32e62502a6e686eae36b7aadfeea60dca) dans ce sens a été proposée. _A priori_, cette approche devrait permettre d’obtenir de meilleures performances et de mieux passer à l’échelle. Les encapsulations pour OVS et [MPLS](https://fr.wikipedia.org/wiki/Multiprotocol_Label_Switching "Multiprotocol Label Switching") (très récemment introduit en version 4.1 du noyau) utilisent déjà cette nouvelle interface. Si vous avez du mal à être convaincu que ce changement est important, vous pouvez lire le début du [courriel résumant les changements réseau](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dd5cdb48edfd34401799056a9acf61078d773f90) de ce noyau. ###Nouveau pilote Si les performances dans le noyau sont essentielles, certains fabricants produisent du matériel capable de très fortement diminuer la tâche du noyau en effectuant de très nombreuses opérations directement dans le matériel. Le [processeur SwitchX-2](http://www.mellanox.com/page/products_dyn?product_family=145&mtag=switchx_2_vpi) entre dans cette catégorie et peut désormais être utilisé avec Linux grâce aux changements [[_1_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=93c1edb27f9e7ef7f276b91763c93242bbda71cb), [_2_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=31557f0f9755696530d08465cf9940404f2d48e2) et [_3_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4ec14b7634b298186f18f65d959354dc3c60e02c)]. Avec ce matériel, il devient en théorie possible de construire de gros commutateurs (_switchs_) performants avec un noyau Linux. Il a suffi d’[adapter le code](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0c4f691ff6791e55ac831666df0b49b1679c56e4) pour ne pas commuter en logiciel un paquet déjà commuté par la carte. ###Un peu d’humain Si cette nouvelle version est riche en améliorations réseau, l’ambiance sur la liste de diffusion n’a pas toujours été au beau fixe. Linus Torvalds a notamment réagi à la demande d’intégration de la partie réseau par un :> « _Christ, people. Learn C, instead of just stringing random characters together until it compiles (with warnings)._ » Que l’on pourrait traduire par :> _Bon dieu, les gars. Apprenez le C, au lieu d’enchaîner des caractères au hasard jusqu’à ce que ça compile (avec des alertes)._ Vous pouvez retrouver le [courriel complet](https://lkml.org/lkml/2015/9/3/428) dans les archives de la liste. Cet incident, bien que postérieur à ce qui va suivre, est peut‐être à rapprocher avec l’annonce du départ de la développeuse qui maintenait les pilotes USB3, qui [critique notamment le manque de respect](http://www.theregister.co.uk/2015/10/06/linix_kernel_dev_who_asked_linus_torvalds_to_stop_swearing_quits_over_swearing/) sur les différentes listes de diffusion du noyau. ##Sécurité ### Anti‐fork‐bomb Un mécanisme _anti‐[fork‐bomb](https://fr.wikipedia.org/wiki/Fork_bomb)_ a été ajouté au noyau. Il se base sur un ajout récent du noyau, les _cgroups_pid_. Ce correctif introduit une nouvelle option, _fork_remaining_. Cette valeur est décrémentée à chaque appel système [`fork()`](https://fr.wikipedia.org/wiki/Fork_%28programmation%29). Lorsqu’elle atteint zéro, le noyau refuse les _forks_ supplémentaires. La valeur _unlimited_ permet de désactiver cette limite. Un petit exemple : ```bash mkdir /sys/fs/cgroup/pids/parent echo 2> /sys/fs/cgroup/pids/parent/pids.fork_remaining echo $$> /sys/fs/cgroup/pids/parent/cgroup.procs cat /sys/fs/cgroup/pids/parent/pids.fork_remaining 1 cat /sys/fs/cgroup/pids/parent/pids.fork_remaining 0 cat /sys/fs/cgroup/pids/parent/pids.fork_remaining sh: fork: Resource temporary unavailable ``` ### Révision de l’héritage des _capabilities_ Les capacités (_capabilities_) sont une extension de la gestion des droits d’un programme permettant d’effectuer des tâches habituellement réservées au super‐utilisateur _root_ (ou un programme marqué [_setuid_](https://fr.wikipedia.org/wiki/Setuid)). Ces capacités peuvent être ajoutées au niveau d’une tâche en cours (grâce à `CAP_SETPCAP`) ou bien au niveau d’un fichier (vous pouvez essayer `getcap /bin/ping`, par exemple). Toucher aux capacités est toujours un problème difficile, la moindre modification risquant de se transformer en faille de sécurité. [L’héritage](http://lwn.net/Articles/632520/) de ses capacités, permettant à un programme de déléguer ses pouvoirs spéciaux à une sous‐tâche, est notamment très discuté. L’argumentation de Andy Lutomirski, développeur du noyau, est que l’héritage proposé actuellement est, justement, totalement inutile si vous n’êtes pas _root_. Pour le faire fonctionner correctement, il faut marquer manuellement chaque fichier concerné. Dans la vraie vie, personne ne le fait, car c’est proche d’un travail d’Hercule et qu’en plus de nombreux systèmes de fichiers ne le permettent pas. Il propose donc l’ajout d’un masque d’environnement, simplifiant l’héritage et le rendant fonctionnel. Si vous voulez les détails de la complexité du problème et de l’implémentation, vous pouvez lire la [demande de changement](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=58319057b7847667f0c9585b9de0e8932b0fdb08). ##Systèmes de fichiers Les changements dans les systèmes de fichiers pour cette version sont majoritairement constitués de corrections et de nettoyages. ### Btrfs Btrfs reçoit une correction du [_trim_](https://fr.wikipedia.org/wiki/Trim_%28informatique%29) pour quelques cas particuliers où les _trims_ étaient manquants. Il reçoit également des corrections pour RAID 5 et RAID 6, en particulier pour le [nettoyage de données](https://en.wikipedia.org/wiki/Data_scrubbing) et le remplacement de périphériques quand plusieurs sont manquants. Les nouveautés concernent aussi la prise en charge de nouveaux contrôleurs _blkio_ pour un seul périphérique (gestion de plusieurs périphériques prévue), ainsi que des corrections et nettoyages divers. Pour plus d’informations, vous pouvez consulter la [[_demande de modification_](http://lkml.iu.edu/hypermail/linux/kernel/1509.0/02784.html)]. ### ext3 Le code concernant ext3 a été supprimé. Désormais, les systèmes de fichiers ext3 devront être montés avec le mode de compatibilité d’ext4. Dans la pratique, cela fait plusieurs années que de nombreuses distributions le font déjà, ce qui a servi à montrer que le code d’ext4 était assez stable pour remplacer celui d’ext3. Si le changement n’affectera pas l’espace utilisateur, cela permet de supprimer 28 000 lignes de code et de supprimer des contournements spécifiques à ext3 dans la mémoire virtuelle du noyau et les couches bloc. D’autre part, cela simplifie la maintenance, car il fallait vérifier à chaque fois si une correction de bogue dans ext4 concernait ext3 pour être manuellement portée. [source : [LKML](http://lkml.iu.edu/hypermail/linux/kernel/1508.3/05063.html)] Le système de fichiers ext2 n’a pas été supprimé car, [d’après Theodore Ts’o](http://lkml.iu.edu/hypermail/linux/kernel/1508.3/05063.html) :> _C’est un système de fichiers simple qui permet de comprendre facilement ce qui est nécessaire pour créer un nouveau système de fichiers._ ### ext4 Comme d’habitude, il y a principalement des corrections de bogues, en particulier sur les quelques ajouts et modifications apportés à [Linux 4.2](https://linuxfr.org/news/sortie-du-noyau-linux-4-2#ext4) (voir les [détails sur LKML](http://lkml.iu.edu/hypermail/linux/kernel/1506.3/00768.html)). [source : [_Phoronix.com_](https://www.phoronix.com/scan.php?page=news_item&px=EXT4-Updates-Linux-4.3)] ### F2FS F2FS est un système de fichiers adapté aux SSD et autres supports de stockage _Flash_. Pour cette version de noyau, nous n’avons pas de nouveauté importante, mais pas mal de petits changements, comme l’amélioration et la correction des _extent_caches_, qui est maintenant une option de montage par défaut. Un travail non négligeable a été également mené pour éviter des problèmes de performance dus à la mémoire (limiter les requêtes de pages mémoire). De plus, un nouvel appel `ioctl()` a été ajouté, `ioctl(F2FS_GARBAGE_COLLECT)`, qui permet à l’utilisateur de faire explicitement une requête de nettoyage des tâches en cours. ### XFS - gestion des cycles de vie d’EFI/EFD retravaillée pour corriger des corruptions de journaux de récupération, des plantages et des attentes lors de démontage ; - métadonnées UUID séparées sur le disque afin d’activer le changement de l’étiquette d’amorçage UUID pour les systèmes de fichiers en version 5 ; - correction de mauvaises compilations de _gcc_ pour certaines plates‐formes et certains niveaux d’optimisation ; - correction de l’allocation d’attributs distante et de la récupération de données corrompues ; - correction des annotations des vérificateurs de verrous ([_lockdeps_](https://www.kernel.org/doc/Documentation/locking/lockdep-design.txt)) des nœuds d’index (_inodes_) générant des erreurs avec de trop nombreuses sous‐classes ; - modifications du verrouillage des nœuds d’index (_inodes_) de répertoires afin d’éviter que les vérificateurs de verrous [_lockdeps_](https://www.kernel.org/doc/Documentation/locking/lockdep-design.txt) ne génèrent de faux positifs ; - une poignée de corrections de corruptions mineures ; - divers autres petits nettoyages et corrections. Pour plus d’informations, vous pouvez consulter la [demande de modification](http://lkml.iu.edu/hypermail/linux/kernel/1509.0/03565.html). ##Virtualisation ###KVM Comme d’habitude, les correctifs sont arrivés en deux lots, [le premier](https://lkml.org/lkml/2015/8/14/643) avant les vacances de Paolo Bonzini (mainteneur KVM) et [le deuxième](https://lkml.org/lkml/2015/9/10/266) au retour de ses vacances. Il n’y a quasiment que des corrections de bogues et peu de nouveautés : - ARM : prise en charge complète du débogage sur ARM64, changement d’état actif pour les interruptions de l’horloge, sauvegarde et restauration fainéante pour les registres de calcul flottant et SIMD pour ARM64, une cible générique ARMv8 (pour ne pas avoir à cibler un processeur particulier) ; - PowerPC : activation du _microthreading_ pour POWER8 ; - x86 : prise en charge du MSR (_Memory Service Routine_) Hyper-V (l’hyperviseur de Windows) pour stocker les informations en cas de plantage. ###Xen Peu de [nouveautés](https://lkml.org/lkml/2015/9/8/495) de même de ce côté (pourtant personne n’a annoncé de vacances) : - conversion du pilote *xen-blkfront* à l’API *multiqueue* ; - prise en charge des invités paravirtualisés de plus de 512 Gio sur x86 (cette fonctionnalité est cependant désactivée par défaut, car ils ne peuvent pas être migrés avec les outils actuels) ; - toujours sur x86, prise en charge du PMU (outils d’analyse de performance utilisant `perf`) sur le domaine principal _dom0_ ; - sur ARM, prise en charge de l’attachement de canaux de communication d’événements à plusieurs processeurs virtuels. #Le bilan en chiffres ![Évolution globale du nombre de lignes de code dans le noyau](http://damballa.alwaysdata.net/evolnbligne4.3.png "Évolution globale du nombre de lignes de code dans le noyau") ![Nombre d’insertions et de suppressions depuis la version 3.0](http://damballa.alwaysdata.net/insersupp4.3.png "Nombre d’insertions et de suppressions depuis la version 3.0") #Appel à volontaires Cette dépêche a nécessité plus de 790 éditions (à l’heure de l’écriture de ces statistiques) et a mobilisé 19 personnes du 14 septembre au 29 novembre dans l’espace de rédaction. ![Répartition des contributions à cette dépêche](http://damballa.alwaysdata.net/people_linuxfr_kernel43.png "Répartition des contributions à cette dépêche") Cette dépêche a été rédigée par plusieurs contributeurs, dont voici la répartition : | | Mainteneur | Contributeur(s) ----------------------------- | -------------------------------------------------- | --------------- **La phase de test** | aucun | aucun | **Arch** | [Romain Perier](//linuxfr.org/users/rperier) | [_Tiwaz_](//linuxfr.org/users/tiwaz), [Florent Fourcot](//linuxfr.org/users/ffourcot) | **IPC** | aucun | [_ariasuni_](//linuxfr.org/users/sinma) | **Développement** | aucun | [_Tiwaz_](//linuxfr.org/users/tiwaz)| **Pilotes graphiques libres** | [Martin Peres](//linuxfr.org/users/mupuf) | aucun | **Réseau** | aucun | [Florent Fourcot](//linuxfr.org/users/ffourcot), [_Tiwaz_](//linuxfr.org/users/tiwaz) | **Systèmes de fichiers** | aucun | [_ariasuni_](//linuxfr.org/users/sinma), [_Tiwaz_](//linuxfr.org/users/tiwaz)| **Sécurité** | aucun | [Florent Fourcot](//linuxfr.org/users/ffourcot), [_Tiwaz_](//linuxfr.org/users/tiwaz)| **Virtualisation** | [Xavier Claude](//linuxfr.org/users/claudex) | aucun | **Édition générale** | aucun | [_jcr83_](//linuxfr.org/users/jcr83), [Davy Defaud](//linuxfr.org/users/davy78), [_eggman_](//linuxfr.org/users/eggman), [_Moul_](//linuxfr.org/users/m5oul) 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_, _Réseau_, _Développement_ et _IPC_, 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 ! C’est un travail à faire au fil du temps, par ajouts successifs (une simple adresse URL ou un paragraphe enrichissent déjà le contenu et les sources), n’hésitez pas !

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