URL: https://linuxfr.org/news/sortie-du-noyau-linux-3-19 Title: Sortie du noyau Linux 3.19 Authors: Martin Peres Davy Defaud, esdeem, BAud, Siosm, Romain Perier, Yves Bourguignon, Benoît Sibaud, palm123, jcr83, Anonyme, Spack, alpha_one_x86, Gauthier Monserand, ZeroHeure, claudex, Olivier Esver, Mali, ariasuni, Kameramann et M5oul Date: 2014年12月16日T00:30:17+01:00 License: CC By-SA Tags: coulisses, linus_torvalds, seccomp, smack, lwn, kernel et noyau_linux Score: 118 La sortie de la version stable 3.19 du noyau Linux a été annoncée le dimanche 8 février 2015 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site _kernel.org_. Le détail des évolutions, nouveautés et prévisions se trouve dans la seconde partie de la dépêche. Pour rappel, la page wiki _[[[rédiger des dépêches noyau]]]_ signale quelques possibilités pour aider à la rédaction et s’y impliquer (ce que tout inscrit peut faire, ne serait‐ce que traduire\^Wsynthétiser les annonces de RC). ---- [Les noyaux précédents](http://linuxfr.org/wiki/depeches_noyau) [Site officiel du noyau Linux](http://www.kernel.org/) [LWN : The 3.19 merge window opens](http://lwn.net/Articles/625146/) [LWN : 3.19 Merge window part 2](http://lwn.net/Articles/626150/) [LWN : The end of the 3.19 merge window](http://lwn.net/Articles/627202/) [Kernel Newbies : Linux 3.19](http://kernelnewbies.org/Linux_3.19) [arm-soc contents merged into 3.19 - Linaro](http://www.linaro.org/blog/core-dump/arm-soc-contents-merged-3-19/) [Heise : Die Neuerungen von Linux 3.19](http://www.heise.de/open/artikel/Die-Neuerungen-von-Linux-3-19-2541595.html) ---- # En bref * Architectures * Changement dynamique possible de parties de l'arbre du device tree * Gestion de Coresight, le traceur matériels pour processeurs ARM * Développeurs * Introduction de fonctions 64 bits pour la gestion du temps au delà de 2038 * Encore un nouvel appel système (!) : [`execveat()`](//linuxfr.org/news/sortie-du-noyau-linux-3-19#appel-syst%C3%A8me-execveat) * Pilotes graphiques libres * DRM : la gestion du mode graphique atomique approche à grands pas * AMD/ATI : ajout du pilote AMDKFD pour la gestion de HSA * Intel : gestion initiale de la famille Skylake * NVIDIA : gestion initiale des nouveaux processeurs graphiques Maxwell * Réseau * Pilote pour la gestion des communications entre conteneurs * Sécurité * Intel Memory Protection Extensions (MPX) * Correction de l'appel système setgroups() * Systèmes de fichiers * OverlayFS multi couche * Données inline pour CephFS * Virtualisation * Gestion de Xen sur les systèmes non-cohérents #Annonces des RC par Linus Torvalds ##RC-1 La version [RC1](https://lkml.org/lkml/2014/12/20/207) est sortie le samedi 20 décembre 2014 :> Donc, cela fait deux semaines à un jour près et la phase d’intégration est terminée.>> Considérant combien de contributions sont arrivées tardivement, j’estime difficile de me préoccuper de quiconque déciderait de placer la limite plus loin que ceux qui l’ont déjà fait. Cela dit, il n’y a peut‐être aucun vrai retardataire — et à la vue de la taille de la RC1, il ne doit vraiment pas y en avoir beaucoup. Non seulement je pense qu’il y a plus de contributions qu’il n’y en avait dans _linux-next_ : c’est historiquement une des plus grosses RC1 (du moins par les _commits_). Nous en avons eu de plus grosses (les 3.10 et 3.15 ont été précédées de longues phases d’intégration), mais ce n’était clairement pas une petite phase d’intégration.>> En tout cas, nous avons eu des changements de tous les côtés, y compris une nouvelle architecture (Nios II). Mon « journal de fusion résumé » est joint et, comme d’habitude, je veux souligner qu’il attribue les contributions aux personnes me les envoyant, ce qui n’est en général pas du tout la même chose que les gens qui écrivent effectivement le code, même s’il y a évidemment un recoupement.>> Dans les grandes lignes, cela ressemble à une sortie plutôt normale. À peu près deux tiers de mises à jour de pilotes, avec à peu près la moitié du reste qui sont des mises à jour d’architectures (et, non, les correctifs du nouveau Nios II ne sont pas du tout prédominantes, c’est à peu près pour moitié de l’ARM, dont la prise en charge du nouveau Nios II représente moins de 10 % des mises à jour d’architecture en nombre de lignes). Le sixième restant est « divers » : réseau, mises à jour des en‐têtes, documentation, systèmes de fichiers, outils et cœur du noyau (à peu près dans cet ordre).>> Évidemment, les vacances arrivant, je m’attends à ce que les quelques prochaines semaines soient plutôt calmes, mais nous verrons bien. J’ose espérer que les gens auront le temps de tester cela entre tous leurs laits de poule,>> Linus ##RC-2 La version [RC2](https://lkml.org/lkml/2014/12/28/142) est sortie le dimanche 28 décembre 2014 :> Cette RC est minuscule, pour des raisons évidentes.> > Je ne m’attends pas à ce que cela dure, mais nous aurons probablement une autre semaine de calme relatif avant un vrai retour à la normale.> > À peu près 80 % de pilotes (le DRM formant la grande majorité), avec quelques petits correctifs concernant ARM64, l’audit et quelques petits mono‐lignes çà et là à d’autres endroits.>> Linus ##RC-3 La version [RC3](https://lkml.org/lkml/2015/1/5/787) est sortie le lundi 5 janvier 2015 :> Elle a été repoussée d’un jour — non pas à cause de problèmes de développement particuliers, mais simplement parce que je carrelais une salle de bain hier. Mais la RC3 est maintenant sortie, et les choses sont demeurées raisonnablement calmes. J’espère vraiment que cela signifie que le 3.19 a l’air bon, mais il est tout aussi probable que les gens récupèrent encore de leur période de vacances.>> Un peu plus de trois quarts des changements concernent les pilotes — surtout du réseau, de la gestion de température, la couche de périphériques d’entrée, le son et la gestion de l’alimentation. Le reste est divers — systèmes de fichiers, infrastructure réseau, quelques correctifs d’architectures, etc. Mais l’ensemble est plutôt petit.>> Donc, allez‐y, testez,> > Linus ##RC-4 La version [RC4](https://lkml.org/lkml/2015/1/11/190) est sortie le dimanche 11 janvier 2015.> Une autre semaine, une autre RC.>> Les choses sont restées raisonnablement calmes, bien que nous ayons aussi eu quelques régressions de dernière minute dans la gestion de la mémoire. Heureusement, la plupart d’entre elles ont été corrigées rapidement, ne laissant qu’un problème avec ARM64 toujours en suspens.> > Donc, allez plus loin et testez plus encore. Je serai en déplacement pour les deux prochaines semaines à cause du LCA, mais je devrais avoir Internet, et, si les choses continuent à être raisonnablement calmes, je ne pense pas que mon voyage soit réellement perceptible. Finalement, on est dans les temps, à l’inverse de plusieurs sorties de l’année dernière.> > Quoi qu’il en soit, la version courte de mon journal de fusion en annexe donne les détails, mais à part les correctifs du `kgdb` apparaissant comme une activité inhabituelle sous `kernel/debug/`, les choses semblent plutôt normales : une majorité de mises à jour de pilotes (pilotes graphiques, _pinctrl_, HID, réseau), des mises à jour d’architectures (principalement x86 cette fois, quelques trucs mineurs pour ARM[64]) et quelques correctifs sur les outils (principalement `perf`).>> Linus ##RC-5 La version [RC5](https://lkml.org/lkml/2015/1/18/32) est sortie le dimanche 18 janvier 2015 :> Une autre semaine, une autre RC.> > Sortie plutôt normale, même si j’aurais souhaité qu’en RC5 nous nous soyons calmés davantage. Mais, non, avec les quelques inclusions dans l’arborescence des pilotes notamment, elle est en fait plus grosse que ne l’était la RC4.>> Cela dit, ce n’est pas comme s’il y avait quoi que ce soit de particulièrement effrayant là‐dedans.> > Le bogue mémoire ARM64 que j’ai mentionné comme mis en attente dans les notes de la RC4 a été corrigé un jour après cette précédente RC, et le reste a l’air plutôt standard. Surtout des pilotes (réseau, USB, cible SCSI, couche bloc, contrôleur mémoire, TTY, etc.), mais aussi des mises à jour d’architectures (ARM, X86, S/390 et quelques petites corrections sur PowerPC), quelques mises à jour de systèmes de fichiers (FUSE et NFS), des corrections de traçage et quelques corrections des outils d’analyse de performance.> > La version courte de mon journal avec les détails est en annexe.> > Allez‐y, testez.>> Linus ##RC-6 La version [RC6](https://lkml.org/lkml/2015/1/26/1) est sortie le dimanche 25 janvier 2015 :> Une autre RC, une autre semaine plus proche de la sortie. Et celle‐ci est légèrement plus petite que ne l’était la RC5, bien que plus petit encore serait toujours mieux.> Mais, comme la RC5, aucun des changements ne semble particulièrement effrayant et plus d’un quart ont été appliqués à la version stable, donc les choses ont l’air d’être sur les bons rails. Je m’attends, pour l’heure, à faire une RC7 la semaine prochaine, avec le 3.19 final dans deux semaines, selon le calendrier habituel.>> Les statistiques ont l’air tout à fait normales, avec un correctif comprenant à peu près 70 % de changements pour les pilotes (le retour en arrière d’un pilote pour les ordinateurs portables Dell représente le plus gros des correctifs, mais il y a le réseau, les médias, les pilotes graphiques, les entrée‐sorties GPIO, le son...) et à peu près 14 % de mises à jour d’architectures (x86 et ARM sont les plus grosses, mais il y a d’autres petites mises à jour également) et le reste se répartit un peu partout (mises à jour de documentation, du réseau, mises à jour de systèmes de fichiers — principalement Btrfs, etc.).> > La version courte du journal des changements propose une sorte de résumé détaillé pour les gens qui veulent avoir une idée de ce qu’il s’est passé. Rien de vraiment particulier ne s’en distingue.>> Linus ##RC-7 La version [RC7](https://lkml.org/lkml/2015/2/2/14) est sortie le dimanche 1^(er) février 2015 :> Tout semble être assez calme et normal, donc ce sera probablement la dernière RC, à moins que quelque chose d’inattendu ne survienne soudainement. Ce qui veut dire que j’aimerais voir plus de gens tester l’utilisation ce bébé [N. D. T. : _chiot_ est le terme employé par Linus], juste pour validation.> > Les statistiques de cette TC sont plutôt normales — à peu près 50 % de pilotes, 20 % de mises à jour d’architectures (pour la plupart ARM et ARM64, quelques x86), avec les systèmes de fichiers apparaissant un peu plus que d’habitude (largement dus aux changements dans le système de quotas), le reste étant « divers » — outils de test de performance, quelques changements mineurs dans le noyau et la mémoire virtuelle, etc.> > Mais tout cela est assez petit. La version courte du journal des changements est jointe pour les curieux,>> Linus ## Version finale La [version finale](http://lwn.net/Articles/632488/) est sortie le 8 février 2015 :> Alors, rien de bien passionnant et bien que que j’ai été tenté plusieurs fois de faire une RC8, il n’y avait vraiment aucune raison à cela.> > À titre d’exemple, Sasha Levin a utilisé KASan et a trouvé un bogue intéressant dans les verrous tournants paravirtualisés. Mais, il s’est avéré qu’il était présent depuis toujours, et il n’est même pas évident qu’il puisse vraiment être déclenché dans la pratique. Nous le corrigerons et l’indiquerons dans la version stable, et aussi tentant que cela fût, ça n’était pas une raison valable pour retarder le 3.19.>> Et les véritables corrections qui ont été faites (voir la version courte du journal de changements) étaient toutes franchement petites, à l’exception de quelques changements de taille moyenne dans InfiniBand qui étaient tous des suppressions de code qui n’était tout simplement pas prêt.>> Donc, il est sorti — venez le récupérer. Et, par conséquent, la fenêtre d’intégration pour le 3.20 est évidemment désormais ouverte aussi.> > Linus #Les nouveautés ##Architecture ### Allwinner #### Cartes de développement Deux nouvelles cartes de développement font leur apparition dans la liste des matériels supportés. La [Banana Pi](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0750693e1c32ac8c86c62e506ac59cf42ca8a736) est une carte embarquée peu chère, très flexible et adaptée pour un usage au quotidien ou en tant que carte de développement. Pour un montant assez correct, vous disposerez d’un système monopuce Allwinner A20 (ARM Cortex-A7 double‐cœur, 1 GHz, processeur graphique Mali-400 MP2), de 1 Gio de mémoire vive DDR3, d’un connecteur HDMI et LVDS, de l’USB 2, du SATA, d’un contrôleur Ethernet Gigabit et d’un en‐tête d’extension où vous pourrez brancher plein de choses. La [A20-OLinuXino-Lime2](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=35669b39f1219ecb58ed84664545c1136d855d27) est une carte de développement en [matériel libre](http://fr.wikipedia.org/wiki/Mat%C3%A9riel_libre) produit par OLimex. Elle dispose d’un système monopuce Allwinner A20 (double‐cœur Cortex A7 cadencé à 1 GHz, un processeur Mali-400), 1 Gio de mémoire vive DDR3, un connecteur HDMI _Full HD_ 1080p, un connecteur LCD (4,3′′, 7,0′′ et 10,1′′), de l’USB 2.0, un contrôleur Ethernet Gigabit, un lecteur de carte microSD, un connecteur SATA et permet de connecter jusqu’à 160 GPIO. Ces deux cartes sont désormais prises en charge par le noyau Linux _mainline_. #### A80 Le Allwinner A80, développé par la société Allwinner Technology, est le premier système monopuce de la série Allwinner A8X. Il dispose de l’architecture [_Big.LITTLE_](http://fr.wikipedia.org/wiki/Big.LITTLE) d’ARM avec huit cœurs, dont quatre Cortex A7 à basse consommation, et quatre autres cœurs Cortex A15 à haute performance. La puce intègre un processeur graphique PowerVR G6230 gérant OpenCL 1.1, OpenGL 3.0, OpenGL ES Next 3.0 et 2.0. Par rapport à ses prédécesseurs, il intègre la prise en charge de l’USB 3, le décodage matériel H.265 et la prise en charge de caméras dont la définition peut atteindre 16 mégapixels. Le Allwinner A80 est désormais pris en charge par le noyau. La carte de développement Optimus A80, sortie au même moment que le système monopuce, est également [prise en charge](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=57bf43bbe9ae1f4d6f7860f472eadbecb83a93bd). ### Samsung Exynos - gestion du nouveau système monopuce [Exynos 4415](http://git.kernel.org/linus/c0adae9e51ab88293d6cc729c46fdb4365bf77f5) ; - prise en charge de l’unité de gestion d’alimentation (PMU) pour les [Exynos 5420](http://git.kernel.org/linus/af2e0a0754accf2276d58d6dfaa15563133130aa) et [Exynos 3250](http://git.kernel.org/linus/8fcc774fc72910fa26767ae8ca2da3d64ae80a01) ; - gestion de la mise en veille en mémoire (_suspend to ram_) pour le [Exynos 5420](http://git.kernel.org/linus/0fdf088fd84d87d6fc5d3961cc86feb8bd295398). ### AMD Seattle Les processeurs AMD Seattle sont maintenant gérés par Linux. Ce sont les premiers processeurs grand public de la firme AMD à être basés sur l’architecture ARM 64 bits (ARMv8-A Cortex A57) et non pas x86. Ils embarquent notamment un coprocesseur cryptographique. ### Device tree overlay — surcouche d’arborescence matérielle Le [_Device tree_](http://devicetree.org/Main_Page) est une structure de données chargée au démarrage du noyau qui décrit la topologie et certaines informations matérielles. Le code du noyau qui gère certains microcontrôleurs ou même certains pilotes viennent ensuite y chercher des informations afin de s’initialiser correctement. Cela permet d’avoir un code beaucoup plus générique avec moins d’informations codées _en dur_. Le souci est qu’il a été écrit de façon statique par ses créateurs, par conception et architecture logicielle. C’est extrêmement pratique et puissant pour exprimer plein de contraintes, mais cela reste lourd et complexe à mettre en place sur des cartes dont les possibilités matérielles ou la topologie peuvent rapidement changer, comme c’est le cas sur une BeagleBone ou une Raspberry Pi, par exemple. Cette version du noyau introduit une nouvelle fonctionnalité : le _Device tree Overlay_. L’_overlay_ est une fonctionnalité qui permet de venir modifier à chaud une portion de cette arborescence matérielle sur un noyau en train de tourner, ou de venir greffer une portion d’un autre _device tree_ par dessus un autre qui est déjà en cours d’exécution. Cela va permettre de résoudre pas mal de problèmes, comme ceux évoqués plus haut. Pour de plus amples informations au sujet du _Device tree_, je vous invite à lire [_ce paragraphe_](//linuxfr.org/news/sortie-du-noyau-linux-3-18#r%C3%A9solveur-de-r%C3%A9f%C3%A9rences-au-sein-du-devicetree) de notre précédente dépêche et [_cet article_](http://lwn.net/Articles/616859/). ### ARM Coresight La technologie ARM Coresight est maintenant prise en charge par le noyau. Coresight est un mécanisme de débogage matériel d’un système monopuce ARM qui inclut une partie [[JTAG]] et une partie de traçage et de débogage de matériel et bus matériel assistée, nous nous focaliserons ici sur cette dernière. Il est aujourd’hui très complexe de porter un nouveau système monopuce au sein du noyau ou d’un système d’exploitation temps réel, et de comprendre précisément et finement ce qu’il se passe à l’intérieur. Il y a, en effet, énormément de contrôleurs et de composants interconnectés : processeur graphique, contrôleur d’accès direct à la mémoire (DMA), processeur de traitement de signal (DSP), AMBA bus, etc. Cela peut rendre la tâche d’un développeur extrêmement ardue, afin de savoir quel signal est levé dans le processeur et à quel moment (IRQ, DMA), ou quel flux de données transite sur un bus. C’est précisément là que Coresight intervient. Pour plus d’informations, vous pouvez consulter [l’article écrit par Linaro](http://www.linaro.org/blog/core-dump/coresight-tracing-update/) sur le sujet. ##Développeurs ### Problème lié à l’année 2038 [Le problème lié à l’année 2038 est toujours là](http://lwn.net/Articles/599580/). Les fonctions internes `do_settimeofday()`, `timekeeping_inject_sleeptime()`, et `mktime()` ont maintenant des remplaçants sûrs pour le bogue de l’année 2038. Dans chaque cas, la nouvelle version ajoute « 64 » au nom de la fonction, et passe au type `time64_t` ou `timespec64` pour représenter le temps. Maintenant, il est possible de rendre obsolètes les anciennes versions et la conversion du code peut commencer. ### Gestion des « interruptions hiérarchiques par domaine » La prise en charge des _interruptions hiérarchiques par domaine_ a été fusionnée au cœur du gestionnaire d’interruptions. Cette gestion est rendue nécessaire pour une prise en compte correcte du matériel complexe qui a de multiples contrôleurs d’interruptions, liés de différentes manières. Voir le nouvel article ajouté à [`Documentation/IRQ-domain.txt`](http://lwn.net/Articles/625547/#hirq) pour un peu plus d’informations. ### ftrace Les filtres utilisés à l’intérieur du sous‐système `ftrace` gèrent maintenant l’opérateur logique _NON_ « `!` » dans les expressions. ### Option `SO_INCOMING_CPU` pour getsockopt() Une nouvelle option de `getsockopt()` apparaît, `SO_INCOMING_CPU`. Elle retourne le processeur sur lequel un traitement est en cours pour une _socket_ donnée. Les applications qui se servent de cette option, sur les grands systèmes, par exemple, mettront à profit le matériel à files d'attente multiples en répartissant le travail sur plusieurs processeurs. ### Appel système `execveat()` L’appel système `execveat()` rejoint les autres : comme pour les autres appels système terminant par _at_ (à), il faut un descripteur de fichier pour le répertoire à utiliser comme point de départ pour trouver le fichier exécutable. Il sert aussi à exécuter un fichier binaire directement à partir d’un descripteur de fichier ouvert, pour une meilleure mise en œuvre de l’appel système `fexecve()`, trouvé sur d’autres systèmes de type UNIX. ### Binder, le système de communication inter‐processus d’Android quitte la partie instable Malgré quelques réclamations sur la liste de diffusion, le code du système de communication inter‐processus (IPC) _Binder_ d’Android a été déplacé de _staging_ vers la branche principale du noyau. En fin de compte, c’est une interface de programmation qui a été livrée sur des millions de systèmes et qui doit être gérée d’une manière ou d’une autre. ## Pilotes graphique libres _**Divulgation complète** : Cette partie a été écrite par le contributeur habituel, mais celui‐ci travaille maintenant pour Intel. Son discours peut donc être biaisé. Ce contributeur a cependant [affirmé sur son blog](http://mupuf.org/blog/2015/01/09/first-week-as-intel-employee/) qu’il resterait factuel et juste envers tous les pilotes, comme il s’est efforcé de le faire depuis le début de ses contributions. Cette partie reflète uniquement son opinion et pas celle de son employeur._ ### DRM (Direct Rendering Manager) Les travaux sur la gestion atomique du mode graphique avancent fortement dans cette nouvelle version. Pour rappel, grâce à cette gestion atomique, les applications telles que le serveur X peuvent changer les paramètres de tous les plans graphiques (exposés par l’interface de programmation _universal plane_, [intégrée dans Linux 3.15](//linuxfr.org/news/sortie-du-noyau-linux-3-15#drm-direct-rendering-manager)) à la fois ; on évite aussi, par exemple, au compositeur d’utiliser les [_shaders_](http://fr.wikipedia.org/wiki/Shader) plutôt que les plans graphiques pour le rendu vidéo. Ces plans graphiques sont plus efficaces, car ils sont généralement capables d’afficher les vidéos dans leur format natif ([[YUV]]) sans avoir à être convertis en RVB. De plus, ils sont généralement capables de redimensionner la taille d’une image de façon matérielle. Sans la gestion atomique des plans graphiques, il est impossible pour un compositeur de migrer dynamiquement le rendu d’une image d’un plan graphique à un autre ou de faire la composition en utilisant des _shaders_. Une fois cette gestion stabilisée, il deviendra possible d’économiser de l’énergie grâce à cette technique. Pour l’instant, cette nouvelle interface est masquée par une option noyau. Plus d’informations sont disponibles dans la [demande d’intégration 3.19](https://linuxfr.org/news/sortie-du-noyau-linux-3-15#drm-direct-rendering-manager) et sur le [_blog_ du mainteneur du pilote i915](http://blog.ffwll.ch/2015/01/update-for-atomic-display-updates.html). La deuxième principale nouveauté est l’ajout de deux nouvelles propriétés DRM afin de fournir une meilleure gestion des écrans par les processeurs graphiques virtuels [[_commit_](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm?id=5bb2bbf596a0ca35b8ba2b0d5b734a1f270040ff)]. Ces propriétés en lecture seule sont à destination du serveur X et des environnements de bureau, afin qu’ils puissent positionner les écrans de la même façon que dans la machine hôte. Il faudra donc attendre quelques mois afin que le serveur graphique et les environnements de bureau utilisent ces propriétés. Le pilote de processeur graphique virtuel _qxl_, utilisé par KVM, a été [modifié](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm?id=7dea0941f8806e79fed562256822564d5f903edc) afin de lire ces propriétés depuis l’hôte avant de modifier les propriétés nouvellement ajoutées. Comme d’habitude, la gestion de [nouveaux panneaux](http://www.spinics.net/lists/dri-devel/msg71693.html) a été étoffée, élargissant ainsi le paysage des plate-formes embarquées mues par des pilotes libres. Pour finir, une [demande d’intégration de modifications diverses](http://www.spinics.net/lists/dri-devel/msg71691.html) a été faite. Pour plus d’informations, vous pouvez consulter la [demande d’intégration](http://lists.freedesktop.org/archives/dri-devel/2014-December/073956.html) DRM. ### AMD/ATI (pilote Radeon) Pour AMD, la version 3.19 du noyau apporte un changement très important, l’introduction du pilote AMDKFD (_AMD Kernel Graphic Driver_). Ce dernier expose une interface bas niveau aux applications utilisant le calcul générique sur un processeur graphique ([[GPGPU]]). Cette interface tire parti du modèle de programmation HSA (_Heterogeneous System Architecture_). Ce dernier vise une collaboration plus rapide entre le processeur graphique et le processeur central. Pour plus d’information sur HSA, vous pouvez consulter la [page Wikipédia](https://en.wikipedia.org/wiki/Heterogeneous_System_Architecture) ou le [site d’AMD](http://www.amd.com/fr-fr/innovations/software-technologies/hsa#). Pour plus d’informations concernant le code, vous pouvez consulter [les demandes](http://lkml.iu.edu/hypermail/linux/kernel/1411.2/04987.html) [d’intégration](http://lists.freedesktop.org/archives/dri-devel/2014-December/073521.html). Une autre nouveauté est l’amélioration de la gestion du ventilateur. Jusqu’à présent, le ventilateur était géré par un circuit intégré externe, configuré par le BIOS. Cependant, de nouveaux processeurs graphiques nécessitent maintenant une gestion du ventilateur par le noyau, comme c’est le cas pour le pilote Nouveau. Ce problème a été découvert et documenté dans un rapport de bogue par un utilisateur Radeon, il y a plus d’un an. Cet utilisateur a commencé par faire de la rétro‐ingénierie du pilote propriétaire grâce à l’outil MMIOTRACE, qui est également utilisé par le projet Nouveau et a trouvé la liste des écritures nécessaires pour gérer manuellement la vitesse du ventilateur. Cependant, en novembre, Alex Deucher d’AMD a fourni des correctifs plus complets, afin d’apporter cette gestion manuelle du ventilateur. Ces correctifs ont finalement été intégrés dans Linux 3.19. Il faudra cependant attendre au moins Linux 3.20 avant que cette gestion soit exposée via l’interface de HWMON. Pour plus d’informations, vous pouvez [consulter le rapport de bogue](https://bugs.freedesktop.org/show_bug.cgi?id=73338) qui détaille tout l’historique. Outre ces changements, la gestion d’énergie pour la famille _Canary Island_ s’améliore, ainsi que la gestion des espaces d’adressage par contexte graphique. Pour plus d’information, vous pouvez consulter [les demandes](http://lists.freedesktop.org/archives/dri-devel/2014-November/072536.html) [d’intégration](http://lists.freedesktop.org/archives/dri-devel/2014-December/073431.html). ### Intel (pilote i915) Dans cette nouvelle version, le pilote i915 apporte une gestion basique des processeurs graphiques Intel [Skylake](https://fr.wikipedia.org/wiki/Skylake) qui succèdent à la famille [Broadwell](https://en.wikipedia.org/wiki/Broadwell_(microarchitecture)) et qui devraient être disponibles à la vente en septembre 2015. Malheureusement, contrairement à ce qui a été [annoncé dans la dépêche précédente](https://linuxfr.org/news/sortie-du-noyau-linux-3-18#intel-pilote-i915), la gestion du PPGTT (_Per‐Process Graphics Translation Table_) n’a pas pu être activée pour les processeurs [Haswell](https://en.wikipedia.org/wiki/Haswell_(microarchitecture)) à cause d’un bogue avec la gestion des contextes. Le PPGTT devrait cependant être activé dans Linux 3.20 pour les processeurs [Broadwell](https://en.wikipedia.org/wiki/Broadwell_(microarchitecture)). La gestion atomique du mode graphique continue d’avancer, même si rien n’est encore utilisable. Dans cette nouvelle version, plusieurs portions du code ont été découpées en une partie de validation et une partie pour appliquer les changements. Le pilote prévient si une combinaison n’est pas possible avant de commencer à appliquer les changements. Une version préliminaire devrait être disponible dans Linux 3.20, si l’on en croit les dires du mainteneur i915. La gestion des modes d’affichage en espace utilisateur — le _User-based ModeSetting_ (UMS) —, ancêtre de l’actuelle gestion en espace noyau — [_Kernel-based ModeSetting_](https://fr.wikipedia.org/wiki/Kernel-based_mode-setting) (KMS) — qui fut introduite en 2009, commence à être supprimée du noyau. Il aura donc [fallu 5 ans](https://www.archlinux.org/news/xf86-video-intel-only-supports-kms-now/) entre la suppression de la gestion du mode d’affichage en espace utilisateur dans le pilote X.Org _xf86-video-intel_ et la suppression du code correspondant dans le noyau. Étonnamment, cette nouvelle version apporte des correctifs pour des familles plutôt anciennes. Ainsi, les [générations 3 et 4](https://fr.wikipedia.org/wiki/Intel_GMA) ont reçu une meilleure prise en charge de la remise à zéro de l’état après un blocage du processeur graphique. De même, les processeurs graphiques i830M devraient avoir une gestion fonctionnelle de l’affichage. Lors de la demande d’intégration, Linus [a fait remarquer](https://lkml.org/lkml/2014/12/15/889) qu’un message d’avertissement était généré dans le journal noyau lors du démarrage. Après investigation, [Linus « pas content » Torvalds a rappelé](https://lkml.org/lkml/2014/12/15/909) pourquoi il est inacceptable qu’une telle modification se soit retrouvée sur son ordinateur et a fait valoir son opinion en disant qu’il y avait un manque flagrant de tests. Bien d’autres modifications importantes sont présentes dans cette nouvelle version. Si vous voulez en savoir plus, vous pouvez consulter l’habituel [compte‐rendu détaillé des modifications](http://blog.ffwll.ch/2014/12/neat-drmi915-stuff-for-319.html) de Daniel Vetter (mainteneur i915). Vous pouvez aussi consulter la [demande d’intégration i915](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/i915?id=26045b53c96f23b75a48544349c3d936e8402418). ### NVIDIA (pilote Nouveau) Le changement principal pour Nouveau dans cette version est la gestion très préliminaire des nouveaux processeurs graphiques de la famille Maxwell. Il est maintenant possible d’avoir un affichage fonctionnel, mais sans aucune accélération. Cette accélération n’est en effet pas facile à fournir, car il est impossible d’envoyer le microcode de changement de contexte sans passer par le processeur de gestion d’énergie. Comme ce microcode doit nécessairement être signé par NVIDIA, Nouveau [utilise celui inclus avec le VBIOS](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=ba6e34e612718b81744dfb1acb408cfb0043d6e4). Il reste donc à écrire ce microcode de changement de contexte. NVIDIA a [proposé de fournir son microcode](http://lists.freedesktop.org/archives/nouveau/2014-September/018831.html) avec les droits de redistribution, afin qu’il soit possible pour l’équipe de Nouveau de fournir une accélération graphique sur les générations futures. Malheureusement, il n’y a eu encore aucune concrétisation ; par conséquent, l’équipe ne sait pas quand l’accélération sera disponible. NVIDIA poursuit son effort en ajoutant la [gestion de la tension d’alimentation](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=ef1df1bc11fb41f1d636533e7ea8d22c850b1b10) pour le GK20A présent dans le Tegra K1. Ce travail est indispensable pour la gestion du changement de fréquence, qui devrait arriver dans la prochaine version du noyau. NVIDIA a également répondu à une question de Pierre Moreau (un troisième développeur Nouveau français actif !) concernant [le rôle d’un registre](https://www.mail-archive.com/nouveau@lists.freedesktop.org/msg18772.html) qui, s’il est mal configuré, empêche Nouveau de fonctionner sur son MacBook Pro. Pierre a ainsi pu écrire un correctif qui a été [accepté dans Linux 3.19](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=e9d91238990d89421315a556a3ba4dbbae35ffbf). ### GPU des systèmes monopuces Le pilote Tegra pour les systèmes monopuces de NVIDIA a reçu la gestion des plans graphiques universels [[_commit_](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/tegra?id=c7679306a923c2feb383f709446c1110db1c56e4)]. Le pilote peut également utiliser l’IOMMU du système, lorsque celle‐ci est disponible. On évite ainsi, par exemple, d'allouer une grosse portion contiguë de mémoire, l’IOMMU se chargeant de mettre les pages dans le bon ordre dans l’espace d’adressage [[_commit_](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/tegra?id=df06b759f2cf4690fa9991edb1504ba39932b2bb)]. Pour finir, plusieurs améliorations liées à l’affichage ont été faites pour les liens [DSI](http://en.wikipedia.org/wiki/Digital_Serial_Interface). Pour plus d’informations, vous pouvez [consulter la demande d’intégration](http://lists.freedesktop.org/archives/dri-devel/2014-November/071964.html). Le pilote MSM, à destination des processeurs graphiques Adreno de Qualcomm, reçoit dans cette version la gestion de la famille a4xx. Pour profiter de la 3D, il sera cependant nécessaire d’utiliser Mesa 10.5, qui devrait sortir dans les prochaines semaines. Une autre amélioration majeure est la conversion du code d’affichage, afin d’utiliser la nouvelle interface de gestion atomique d’un mode graphique introduite dans cette version. Pour plus d’informations, vous pouvez consulter les [différentes](http://lists.freedesktop.org/archives/freedreno/2014-November/000155.html) [demandes](http://lists.freedesktop.org/archives/freedreno/2014-November/000157.html) d’[intégration](http://lists.freedesktop.org/archives/freedreno/2014-December/000206.html). Le pilote Exynos, pour les processeurs graphiques Samsung, a reçu la gestion du système monopuce Exynos 4415, ainsi qu’un gros effort de nettoyage et débogage du code. Pour plus d’informations, vous pouvez [consulter la demande d’intégration](http://www.spinics.net/lists/linux-samsung-soc/msg39541.html). ## Réseau La couche réseau a un nouveau sous‐système pour recourir au matériel approprié pour les fonctions de commutation et routage. ### eBPF et socket réseau Pour Linux 3.18, Alexei Starovoitov avait activement travaillé à introduire un nouvel appel système [`bpf()`](https://lwn.net/Articles/612878/), couvrant la gestion de programmes BPF étendu. Ce système se veut générique et indépendant de la partie réseau. Ce sera un moyen d’envoyer depuis l’espace utilisateur des filtres compilés dynamiquement par LLVM à divers sous‐systèmes (réseau, sécurité). Cependant, dans la pratique, on ne pouvait pas encore utiliser la structure créée. [Une première implémentation pour les _sockets_ réseau est maintenant disponible](http://lwn.net/Articles/625224/). Malgré le nom de _Berkeley Packet Filter_, la création de filtres n'est pas encore à l'ordre du jour. Pour l’instant, la structure n’a accès en entrée qu’au paquet réseau et non à toutes les métadonnées présentes dans la structure du noyau (skb). En sortie, elle n’a accès qu’à une table de hachage partagée avec l’espace utilisateur. Cela en limite l’usage à la collecte de statistiques ([des exemples sont disponibles](https://lwn.net/Articles/625238/)), mais d’autres applications devraient être possibles dans les prochains cycles de développement. ### Nouveau pilote pour gérer les connexions réseau entre conteneurs L’interconnexion de conteneurs au travers de réseaux virtuels se fait grâce au nouveau pilote ipvlan. Ce dernier est conçu pour fonctionner avec les espaces de noms en réseau. Il est un peu comme le pilote _macvlan_ existant, mais il fait son multiplexage à un niveau plus haut dans la pile. Lors de la création de plusieurs espaces de noms, conteneurs ou invités (sous‐hôtes) sur un hôte, plusieurs modes de connexion au réseau sont généralement disponibles (hôte seulement, NAT, pont réseau). Dans le cas d’un pont réseau (l’équivalent d’un _switch_), l’hôte possède une interface physique (généralement appelée maître), éventuellement une interface représentant le pont, et une interface reliée (esclave) pour chaque sous‐hôte. Le plus généralement, on utilise le pilote _bridge_ (_cf._ `man brctl`). Il est cependant utile de limiter les interactions de chaque sous‐hôte. Là où _macvlan_ répartit les paquets en fonction de l’adresse MAC (niveau 2), _ipvlan_ peut le faire en fonction de l’adresse IP (niveau 3). ### Pagination à la demande pour InfiniBand La couche InfiniBand prend maintenant en charge la pagination à la demande : le paramétrage d’un emplacement [RDMA](http://en.wikipedia.org/wiki/Remote_direct_memory_access "Remote Direct Memory Access — Accès direct à la mémoire à distance") et le remplissage via des défauts de page lorsque la mémoire est effectivement utilisée. On évite ainsi un blocage inutile d’une zone mémoire. ## Sécurité ### Intel Memory Protection Extensions (MPX) La prise en charge, pour les programmes en espace utilisateur, de la technologie MPX spécifique aux processeurs Intel a été ajoutée. Les processeurs disposant de cette extension matérielle (architecture Skylake, qui n’est pas encore disponible) pourront contrôler les accès à la mémoire en vérifiant notamment qu’ils sont effectués dans une région valide. Cette protection peut empêcher l’exploitation de vulnérabilités de type dépassement de mémoire tampon. Pour que cette fonctionnalité soit efficace, il faut donner au processeur beaucoup d’informations sur les différentes zones mémoire dont l’accès est valide. Il est donc probable que l’adoption de cette technologie se fasse progressivement. La prise en charge dans la suite de compilateurs GCC ainsi que dans la bibliothèque _glibc_ est en cours d’intégration. Plus de détails dans l’[article sur _LWN.net_](http://lwn.net/Articles/582712/), dans la [dépêche sur le noyau 3.14](//linuxfr.org/news/sortie-de-linux-3-14#intel-memory-protection-extensions-mpx) et dans la [documentation du noyau](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/x86/intel_mpx.txt) [[_correctifs_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=x86%2C+mpx%3A)]. ### seccomp et ARM64 L’architecture ARM64 peut maintenant faire usage du sous‐système _seccomp_. ### Correction de l'appel système `setgroups()` Le comportement de l’appel système `setgroups()` a été modifié pour corriger une éventuelle faille de sécurité. Ce problème a été expliqué dans un [article de _LWN.net_](http://lwn.net/Articles/621612/), lorsqu’un développeur a essayé d’introduire dans Linux un moyen de réduire les privilèges d’une application. En effet, enlever un utilisateur d’un groupe peut parfois augmenter les privilèges, et quelques administrateurs utilisent les droits UNIX de cette façon. Le problème est que Linux propose déjà à un utilisateur de diminuer ses privilèges lorsque celui‐ci s’exécute dans un espace de noms utilisateur. [Cela a été corrigé](http://lwn.net/Articles/626665/) dans cette nouvelle version, mais ce changement peut casser certaines applications. ### Chargement non voulu de modules noyau Dans certains cas, il était possible de charger des modules noyau non nécessaires sans avoir besoin d’être super‐utilisateur (_root_). Plus de détails sont disponibles dans [cet article de Mathias Krause](https://plus.google.com/+MathiasKrause/posts/PqFCo4bfrWu). ### LSM #### IMA & EVM Un méchanisme (_hook_) a été ajouté pour charger un certificat [X.509](http://fr.wikipedia.org/wiki/X.509) directement dans le trousseau de clés [IMA](http://sourceforge.net/p/linux-ima/wiki/Home/ "Integrity Measurement Architecture") chargé de la vérification d’intégrité [correctifs : [_1_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e3c4abbfa97ed0b7aed36f18b32911ccf76d52c2), [_2_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=65d543b2335ede80e5e66bc4f559f62db5f469bd), [_3_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fd5f4e9054acbf4f22fac81a358baf3c27aa42ac), [_4_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c9cd2ce2bc6313aafa33f8e28d29a8690252f219) et [_5_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c57782c13ecd7e7aca66cbf0139ad2a72317dc81)]. #### SMACK Pour qu’un processus puisse poser un verrou sur un fichier sur lequel il n’a que le droit d’accès en lecture, il doit disposer du mode d’accès [SMACK](https://fr.wikipedia.org/wiki/Simplified_Mandatory_Access_Control_Kernel "Simplified Mandatory Access Control Kernel") « _lock_ » (_cf._ [dépêche noyau 3.13](https://linuxfr.org/news/sortie-de-linux-3-13#smack)). L’étiquette « `_` » étant utilisée comme étiquette pour le système de base, un processus quelconque ne peut verrouiller en lecture l’un de ces fichiers que si une règle est définie. Comme c’est une opération très courante, l’étiquette « `_` » a été modifié pour se comporter légèrement différemment, en autorisant le verrouillage en lecture pour tous les processus. Cela implique que les processus avec l’étiquette « `^` », qui peuvent lire tous les fichiers d’un système, peuvent désormais aussi les verrouiller en lecture. Ce changement a été effectué pour simplifier les politiques SMACK [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6c892df2686c5611979792aaa4ddea9ee9f18749)]. ### Liste non exhaustive des vulnérabilités corrigées * [CVE-2014-9529](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9529) [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a3a8784454692dd72e5d5d34dcdab17b4420e74c)] ; * [CVE-2015-0239](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0239) [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f3747379accba8e95d70cec0eae0582c8c182050)] ; * [CVE-2014-8480](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8480) [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=63ea0a49ae0b145b91ff2b070c01b66fc75854b9)] ; * [CVE-2014-8134](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8134) [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=29fa6825463c97e5157284db80107d1bfac5d77b)] ; * [CVE-2014-8989](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8989) [correctifs : [_1_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f95d7918bd1e724675de4940039f2865e5eec5fe), [_2_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=80dd00a23784b384ccea049bfb3f259d3f973b9d), [_3_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=be7c6dba2332cef0677fbabb606e279ae76652c3), [_4_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=273d2c67c3e179adb1e74f403d1e9a06e3f841b5) et [_5_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0542f17bf2c1f2430d368f44c8fcf2f82ec9e53e)]. Pour plus de détails sur la vulnérabilité CVE-2015-0239 qui impacte KVM : [_[oss-security] KVM SYSENTER emulation vulnerability - CVE-2015-0239_](https://marc.info/?l=oss-security&m=142237526019198&w=2). ##Systèmes de fichiers ### OverlayFS multicouche OverlayFS gère maintenant plusieurs couches. Il est utilisé pour les CD autonomes (_live CD_), car il rend inscriptible une couche en lecture seule, en y ajoutant une zone en lecture‐écriture. ### Ceph avec des données _inline_ Le système de fichiers distribué [Ceph](https://fr.wikipedia.org/wiki/Ceph_%28stockage%29) gère les données _inline_ pour augmenter les performances, principalement pour les petits fichiers, comme le font déjà ext4 et Btrfs. Il gère maintenant également le chiffrement des messages entre les clients et les serveurs. Pour rappel, Ceph est un système de fichiers réparti sans point individuel de défaillance ([_SPOF_](http://fr.wikipedia.org/wiki/Point_individuel_de_d%C3%A9faillance)), avec une bonne gestion de l’extensibilité. ### SquashFS avec LZ4 [[SquashFS]] gère la compression [[LZ4]] qui est une compression peu gourmande en temps processeur. SquashFS est un système de fichiers compressé en lecture seule, utilisé par les CD autonomes (_live_ CD), par exemple. ### Btrfs Le [RAID 5](https://fr.wikipedia.org/wiki/RAID_%28informatique%29#RAID_5_:_volume_agr.C3.A9g.C3.A9_par_bandes_.C3.A0_parit.C3.A9_r.C3.A9partie) et le [RAID 6](https://fr.wikipedia.org/wiki/RAID_%28informatique%29#RAID_6), pris en charge nativement par le Btrfs, sont améliorés. Le changement à chaud des disques est aussi mieux pris en charge. Il y a énormément de corrections de bogues, y compris une corruption après un crash ou dans une condition d’erreur. ### F2FS Une nouvelle option de montage nommée _fastboot_ réduit un certain nombre de vérifications effectuées lors du montage du système de fichiers, et accélère donc potentiellement le démarrage du système d’exploitation. ### NFS Le client et le serveur NFS prennent maintenant en charge les options NFS 4.2 `ALLOCATE` et `DEALLOCATE`. La première peut être utilisée pour demander la préallocation du stockage d’un fichier, tandis que la seconde est utile pour libérer un emplacement. ### Divers - La multi‐file de blocs est améliorée et est prise en charge dans le pilote [NVMe](http://en.wikipedia.org/wiki/NVM_Express "Non‐Volatile Memory Express"), qui gère les disques à mémoire Flash SSD directement reliés au bus PCI Express. - Optimisation de la couche de la [carte des périphériques](http://fr.wikipedia.org/wiki/Carte_des_p%C3%A9riph%C3%A9riques) ([_device mapper_](http://en.wikipedia.org/wiki/Device_mapper)) responsable de la cryptographie et/ou de la couche [RAID](https://fr.wikipedia.org/wiki/RAID_%28informatique%29) par bloc. ## Virtualisation ### KVM La prise en charge de la virtualisation KVM pour l’architecture Itanium (IA64) a été supprimée. Elle n’était pas maintenue et, apparemment, n’était pas utilisée non plus. ### Xen Cette nouvelle version du noyau apporte une gestion complète des processeurs n’ayant pas de cohérence pour leurs caches, comme c’est le cas dans les processeurs ARM. L’hyperviseur a donc reçu un mécanisme permettant d’effectuer les opérations de maintenance de cache nécessaires sur ces processeurs. Pour plus d’informations, vous pouvez consulter les [demandes](http://lkml.iu.edu/hypermail/linux/kernel/1412.1/02490.html) [d’intégration](http://lkml.iu.edu/hypermail/linux/kernel/1412.1/02488.html) Xen. ### Virtio Virtio, le [cadriciel d’abstraction des entrées‐sorties](http://www.linux-kvm.org/page/Virtio) à destination des hyperviseurs, passe en version 1.0. Le pilote SCSI spécifique pour les machines virtuelles (virtio_scsi) peut faire usage de la gestion des files matérielles multiples (_blk-mq_ : [présentation sur _blk-mq_](http://events.linuxfoundation.org/sites/events/files/slides/scsi.pdf)) qui est implémentée dans le noyau depuis la version 3.13 [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ccbedf117f015d4f415130069b47d63c359bc110)]. Pour plus d’informations, vous pouvez consulter la [demande d’intégration Virtio](http://lkml.iu.edu/hypermail/linux/kernel/1412.1/02488.html). ### Hyper-V Prise en charge de l’enlèvement à chaud des interfaces réseau virtuelles (vNIC) [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c3582a2c4d0baf1fa3955c8b3d3d61308df474c7)]. #Le bilan en chiffres En ce qui concerne les statistiques du cycle de développement du noyau 3.19, le site _LWN.net_ a publié son traditionnel [article récapitulatif](http://lwn.net/Articles/631509/). En nombre de modifications, on se situe à 12 461, soit environ 1 300 modifications de plus que la version précédente du noyau. Le nombre de contributeurs est, quant à lui, de 1 422. Ce nombre est resté relativement constant sur la dernière année. Le développeur ayant écrit le plus de modifications est H. Hartley Sweeten (463) pour son travail de nettoyage des pilotes [Comedi](http://www.comedi.org/). Du côté des développeurs ayant le plus modifié de lignes, Malcolm Priestley remporte la palme grâce à son travail d’amélioration sur le pilote _vt6655_. Environ 200 entreprises ont participé à l’élaboration de ce noyau. En tête, on retrouve Intel, qui a effectué 12 % des changements que l’on peut trouver dans cette nouvelle version. En deuxième place, Red Hat a contribué pour 8,3 % des changements. Il est cependant important de noter que les développeurs sans affiliation ont effectué 10,9 % des modifications, soit juste un peu moins qu’Intel, alors que les personnes non identifiées ont écrit 7,5 % des modifications. On peut donc dire, bien que le noyau soit majoritairement écrit par des employés d’entreprises, que les contributeurs indépendants sont toujours les bienvenus et sont même une majorité ! #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 | [Pierre Mazière](//linuxfr.org/users/peetah) et [Davy Defaud](//linuxfr.org/users/davy78) | **Arch** | [Romain Perier](//linuxfr.org/users/rperier) | **Développeurs** | Aucun | **Pilotes graphiques libres** | [Martin Peres](//linuxfr.org/users/mupuf) | **Réseau** | Aucun | [alpha_one_x86](//linuxfr.org/users/alpha_one_x86) **Systèmes de fichiers** | Aucun | [alpha_one_x86](//linuxfr.org/users/alpha_one_x86) **Sécurité** | [Timothée Ravier](//linuxfr.org/users/siosm) | **Virtualisation** | [Xavier Claude](//linuxfr.org/users/claudex) | [Timothée Ravier](//linuxfr.org/users/siosm) et [Martin Peres](//linuxfr.org/users/mupuf) **Édition générale** | Aucun | [Martin Peres](//linuxfr.org/users/mupuf), [Timothée Ravier](//linuxfr.org/users/siosm), [eggman](//linuxfr.org/users/eggman), [BAud](https://linuxfr.org/users/baud) et [Davy Defaud](//linuxfr.org/users/davy78) Un peu de vocabulaire : * le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie, il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer ; * un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche, sans aucune forme d’engagement pour le futur. Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps et de volontaires.> Nous sommes particulièrement à la recherche de mainteneurs pour les sections _Systèmes de fichiers_ et _Réseau_, les précédents n’ayant pas donné de signes de vie pendant la rédaction des dernières dépêches. Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les _commits_ intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau !

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