URL: https://linuxfr.org/news/sortie-du-noyau-linux-4-0 Title: Sortie du noyau Linux 4.0 Authors: Martin Peres Davy Defaud, Anonyme, Siosm, BAud, Yves Bourguignon, M5oul, palm123, Kioob, Aissen, Mali, Jiehong, Sébastien Koechlin, feth, claudex, Cilyan Olowen, ʭ ☯ , jcr83, Benoît Sibaud, Meku, Olivier Esver, FantastIX, Xavier Teyssier, pums974, rpnpif, Dring, dcp, Melkor73 et Thomas Debesse Date: 2015年02月23日T07:51:11+01:00 License: CC By-SA Tags: kernel, noyau_linux, coulisses, linus_torvalds, seccomp, selinux et smack Score: 108 La sortie de la version stable 4.0 du noyau Linux a été annoncée le 12 avril 2015 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site [_kernel.org_](http://www.kernel.org). Le détail des évolutions, nouveautés et prévisions se trouve dans la seconde partie de la dépêche. ---- [Les noyaux précédents](http://linuxfr.org/wiki/depeches_noyau) [Site officiel du noyau Linux](http://www.kernel.org/) [The 3.20 merge window opens](http://lwn.net/Articles/632761/) [3.20 merge window part 2](http://lwn.net/Articles/633096/) [The end of the 4.0 merge window](http://lwn.net/Articles/634471/) [Die Neuerungen von Linux 4.0](http://www.heise.de/open/artikel/Die-Neuerungen-von-Linux-4-0-2600242.html) [Kernel newbies : Linux 4.0](http://kernelnewbies.org/Linux_4.0) ---- # En bref [Après de longues discussions](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c517d838eb7d07bbe9507871fab3931deccff539), ce noyau n’est pas le 3.20, mais le 4.0. Rétroactivement, on pourrait justifier cela grâce à l’arrivée de la modification à chaud du noyau, ou que [compter au‐delà de vingt n’est pas une sinécure](//linuxfr.org/users/kalenx/journaux/un-sondage-pour-la-numerotation-des-versions-de-linux) : c’est selon. La nouveauté principale du noyau est la [mise à jour du noyau à la volée](https://linuxfr.org/news/sortie-du-noyau-linux-4-0#mise-%C3%A0-jour-du-noyau-%C3%A0-la-vol%C3%A9e). Du coté des pilotes graphiques, la [gestion atomique du mode graphique](https://linuxfr.org/news/sortie-du-noyau-linux-4-0#drm-direct-rendering-manager) a été introduite en mode expérimentale. Pour finir, le [drapeau lazytime](https://linuxfr.org/news/sortie-du-noyau-linux-4-0#lazytime) a été introduit dans la couche d'abstraction VFS afin de booster les performances de atime. # Annonces des versions candidates par Linus Torvalds ## RC-1 La version [RC1](https://lkml.org/lkml/2015/2/22/203) est sortie le dimanche 22 février 2015 :>Voyons quelle proportion, le cas échéant, va être cassée par ce changement de version.>Probablement moins que pendant la période du 3.0, mais j’imagine bien quelqu’un cherchant des versions significatives.>>Parce que le peuple a parlé, et même si la plupart des interventions n’étaient qu’un charabia complet, les nombres ne mentent pas. Le peuple a préféré 4.0, et ce sera 4.0. À moins que quelqu’un ne surgisse avec un bon argument contre.>>Jusque là, les arguments contre semblent avoir été « un numéro majeur devrait aller avec une fonctionnalité majeure ou une rupture de compatibilité », ce qui montre le peu que les gens connaissent. Nous ne cassons pas la compatibilité, et nous n’avons pas fait de sorties basées sur une fonctionnalité depuis, en fait, le début.>>D’un autre côté, l’argument le plus fort pour certains des partisans d’une version 4.0 semble avoir été le souhait de voir une 4.1.15 — parce que « c’était la version de Linux que Skynet utilisait pour le T-800 ».>>Donc, au final, je ne voudrais pas trop lire [le destin] dans ce numéro.>>Sur le plan réellement technique, c’était plutôt une petite version. En considérant les normes actuelles. Elle est assurément notablement plus petite que certains noyaux récents, même si nous parlons de ~9k de modifs hors fusion plutôt que de 10-11k, donc ce n’est pas comme s’il y avait une énorme différence.>>L’infrastructure de mise à jour à chaud a fait la une, mais mes fonctionnalités favorites sont personnellement les quelques nettoyages de mémoire virtuelle, par lesquels cette sortie nous débarrasse du code de correspondance non linéaire largement inutilisé (remplacé par une émulation avec beaucoup de mises en correspondance plus petites) et unifie la prise charge des tables de pages pour NUMA et PROTNONE.>>Mais personne ne devrait le remarquer. Parce que passer en 4.0 ne veut pas dire que nous avons changé de quelque manière que ce soit ce que voient les gens. Ça n’est que la continuité, avec seulement des plus petits chiffres, de manière à ce que je puisse faire des sorties sans avoir à retirer à nouveau mes chaussettes.>>Allez‐y, testez. Les arborescences Git sont déjà là, l’archive _tar_ et les correctifs vont sortir au moment où j’écris. Bien sûr, avec le changement de version, je suppute qu’il y aura quelques hoquets avec les miroirs de _kernel.org_, même si Konstantin pense que tous les scripts sont déjà prêts. Donc, si vous ne trouvez pas les archives _tar_ et les correctifs, soit j’ai déconné, soit c’est Konstantin. :)>>Linus ## RC-2 La version [RC2](https://lkml.org/lkml/2015/3/3/572) est sortie le mardi 3 mars 2015 :>Ainsi la RC2 a loupé le créneau habituel du dimanche après‐midi, parce que j’ai passé la plupart du week‐end à déboguer un problème qui apparaissait sur un vieux Mac Mini que j’avais dans le coin, et que je déteste faire des sorties, même en début de RC, avec des problèmes sur des machines auxquelles j’ai directement accès. Même si cela a seulement affecté de vieilles machines que les vrais développeurs ont peu de chance d’avoir ou du moins d’utiliser.>>Aujourd’hui, j’ai le correctif de Daniel Vetter le corrigeant, donc, plutôt que de faire une RC2 du dimanche soir, c’est une du mardi matin. Allez la récupérer. Elle fonctionne mieux grâce à ce retard.>>À part ce petit correctif d’une ligne pour i915 ? Pas grand chose en fait. Ce fut une semaine très calme, pour un début de processus de sortie. Bien sûr, la 3.19-rc2 était encore plus petite, donc cela poursuit une tendance, mais c’était la semaine de Noël. J’espère que ce faible volume est juste dû au fait que la fenêtre de fusion du 4.0 elle‐même était quelque peu plus calme que pour les toutes dernières sorties. Mais je suppute que la vraie raison est la mise en attente des arborescences des pilotes et du réseau de GregKH et davem, qui n’ont pas eu le temps d’être prêtes pour la RC2.>>On verra.>>En tout cas, la version courte du journal des modifications est en annexe, et les tests sont grandement appréciés.>>Linus ## RC-3 La version [RC3](https://lkml.org/lkml/2015/3/8/216) est sortie le dimanche 8 mars 2015 :>De nouveau en phase avec le calendrier des sorties du dimanche après‐midi, puisqu’il n’y a rien eu de particulièrement étrange cette semaine, et aucun bogue de dernière minute dont j’aurais eu connaissance ou que j’aurais voulu résoudre qui aurait repoussé l’échéance.>>En termes de taille, on est aussi dans la normale, pas aussi petit que la RC2. Cela s’explique facilement par la récupération des correctifs de David et Greg (puisque le réseau et les pilotes ont tendance à être les deux plus grosses parties).>>Et la répartition des correctifs est plutôt classique également : à peu près deux tiers de pilotes (processeurs graphiques, réseau, USB, _staging_, son, divers), le reste concernant les systèmes de fichiers (principalement NFS et Btrfs), des mises à jour d’architectures ([ARC](http://en.wikipedia.org/wiki/ARC_%28processor%29), x86, ARM, PowerPC), du réseau et de la documentation.>>En d’autres termes, tout semble complètement normal à cette étape du processus de sortie.>>S’il vous plaît, testez‐moi tout ça,>>Linus ## RC-4 La version [RC4](https://lkml.org/lkml/2015/3/15/180) est sortie dimanche 15 mars 2015 :>Hmm. Rien de particulièrement étrange cette semaine non plus, avec peut‐être juste une mise à jour légèrement plus grosse que prévue d’un système monopuce ARM. Donc, « seule » la moitié du correctif est composée de mises à jour de pilotes, la moitié restante étant des changements dans ARM.>>Le reste est l’habituel mélange de divers correctifs — quelques autres architectures (S/390, [Nios II](http://en.wikipedia.org/wiki/Nios_II)), du réseau, du cœur de noyau et de la mémoire virtuelle, quelques mises à jour de la documentation. Rien ne se détache particulièrement ici. Le journal court est en annexe, je pense qu’on se débrouille bien à cette étape du cycle de sortie.>>Linus ## RC-5 La version [RC5](https://lkml.org/lkml/2015/3/23/1) est sortie dimanche 22 mars 2015 :>Alors, la RC5 est presque exactement de la même taille que la RC4. Je serais plus heureux si les RC rétrécissaient, mais je suppose que je devrais être reconnaissant qu’au moins elles ne semblent pas grossir.>>Il n’y a rien de particulièrement inquiétant, bien que j’essaie toujours de penser à la régression de performance de l’équilibrage NUMA. Ça ne devrait pas être bloquant, mais c’est ennuyeux, et je veux que ce soit corrigé.>On y arrivera, j’en suis certain.>>En attendant, la rc5 est principalement constituée de mises à jour de pilotes (à travers toute l’arborescence des pilotes : pilotes graphiques, USB, son, réseau, HID, entrées, contrôleurs de broches [_pinctrl_], etc.) avec quelques mises à jour d’architectures (x86, ARM, ARM64, SPARC) et quelques corrections de systèmes de fichiers (principalement Btrfs). Et, également, un soupçon de corrections du code réseau, hors pilotes.>>Le journal court des modifications est en annexe, bien qu’il ne soit pas particulièrement intéressant. La plupart des gros correctifs étaient des retours en arrière, comme il se doit à cette étape.>>Linus ## RC-6 La version [RC6](https://lkml.org/lkml/2015/3/29/248) est sortie dimanche 29 mars 2015 :>Ça se calme gentiment, et il y a des corrections un peu partout. La régression de performance de l’équilibrage NUMA est corrigée, et les choses s’améliorent à nouveau de manière générale. Il y a eu un certain nombre de problèmes avec i915 et une double faute KVM qui a fait que pendant un bon moment j’étais quasi certain que ce serait un cycle qui irait jusqu’à une RC8, mais cela pourrait ne pas s’avérer nécessaire.>>À part les problèmes susmentionnés, le gros de cette sortie est constitué principalement de petites correction de divers pilotes et de mises à jour d’architectures. Le journal court donne un meilleur aperçu de ce qu’il s’est passé.>>Mais, s’il vous plaît, testez bien cette RC, et braillez s’il y a des régressions que nous aurions ratées.>>Linus ## RC-7 La version [RC7](https://lkml.org/lkml/2015/4/6/402) est sortie le lundi 6 avril 2015 :>Bon, la RC7 a un jour de retard, pour cause de dîner de Pâques. Pour compenser, elle inclut quelques corrections supplémentaires.>>Mais elle est encore assez petite, et on est en bonne voie pour la 4.0 le week‐end prochain. Il y a une minuscule probabilité que je décide de repousser la 4.0 d’une semaine, simplement parce que je voyage la semaine d’après, et je pourrais vouloir éviter d’ouvrir la fenêtre d’intégration. Nous verrons comment je le sens le week‐end prochain.>>En tout cas, rien de particulièrement étrange dans cette RC7. Elle contient à peu près trois quarts de mises à jour de pilotes (la plupart étant des pilotes réseau, mais il y a des trucs un peu partout : pilotes graphiques, [IIO](http://wiki.analog.com/software/linux/docs/iio/iio "Industrial I/O (entrées‐sorties industrielles)"), entrées, USB...). Le reste est composé de quelques petites corrections sur x86, un peu de réseau, une correction concernant [_lazytime_](http://tuxdiary.com/2014/11/26/lazytime/ "option de montage d’ext4") et de la documentation.>Et tout ça est assez petit.>>Linus ## Version finale La [version finale](https://lkml.org/lkml/2015/4/12/178) est sortie le dimanche 12 avril 2015 :> Alors, j’ai décidé de sortir le 4.0 selon le calendrier habituel, parce qu’il n’y avait vraiment aucun problème connu et, bien que je voyagerai à la fin de la semaine à venir en raison de la visite d’une université, j’espère que cela n’affectera pas trop la fenêtre de fusion.> On verra.>> Linux 4.0 était une version assez petite, à la fois dans _linux-next_ et par sa taille finale, bien qu’évidemment, « petit » est tout relatif. Elle fait tout de même plus de 10 000 _commits_ non fusionnés. Mais, nous avons clairement eu de plus grosses versions (et, à en juger par _linux-next_, la 4.1 va être l’une des plus grosses).>> Ce qui est une bonne chose. Cela colle parfaitement à « la v4.0 est supposée être une version _stable_ », et absolument pas l’objet de nouvelles fonctionnalités expérimentales, etc. Je suis personnellement bien plus satisfait par les sorties planifiées que par la mauvaise époque où nous avions des sorties basées sur les fonctionnalités.>> Ceci dit, il y a quelques éléments de numérologie intéressants amenés par la 4.0. En ne regardant que les statistiques dans _git_, cette version n’est pas juste celle faisant passer la barre du demi‐million de _commits_ au total, mais également la limite des 4 millions d’objets _git_. De manière intéressante (si l’on regarde les modèles numériques), Linux 3.0 était le moment où nous nous avons dépassé le quart de million de _commits_ et 2 millions d’objets _git_, donc il y a là un joli (et complètement non intentionnel) modèle concernant le dépôt _git_ du noyau.>> [Une autre rapide note historique de numérologie de bas de page : l’ancien historique de l’arbre BK approchait la limite de _commits_ des 16 bits que BK avait à l’origine. Donc, ce « quart de million de _commits_ » est vraiment pas mal du tout. Pendant toutes les années sous BK nous n’avons eu que 65 000 _commits_. Bien sûr, nous n’avons utilisé BK que pendant trois ans, et nous sommes maintenant avec _Git_ depuis presque dix ans, mais tout de même — cela montre à quel point le processus global de développement s’est _énormément_ accéléré].>> En termes de fonctionnalités, le 4.0 n’a rien de vraiement spécial. On a beaucoup parlé de la nouvelle infrastructure de correction du nouveau noyau, mais en réalité, ce n’était pas la seule raison du changement de version, on a eu de bien plus gros changements dans d’autres versions. Donc, c’est davantage une version de « solide amélioration du code ».>> Ramenez‐le et amusez‐vous,>> Linus « nous sommes tous des moutons » Torvalds N. D. T . : La version 4.0 a été nommée « [_Hurr durr I’m a sheep_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c517d838eb7d07bbe9507871fab3931deccff539) », soit « [onomatopées de votre choix] je suis un mouton » par Linus. # Les nouveautés ## Architecture ### ACPI Les portables de marque Toshiba seront beaucoup mieux gérés : le pilote _toshiba_acpi_ gère [maintenant](http://lkml.iu.edu/hypermail/linux/kernel/1502.2/02418.html) l’activation du mode « éco », de l’USB 3, de la charge rapide USB en veille, etc. Pour avoir eu le plaisir d’utiliser une machine concernée depuis neuf mois, j’ajoute que ce n’est pas rien : au départ, le pavé tactile n’était pas géré (arrivé avec le noyau 3.18), l’écran ne se rallumait pas après une mise en veille, et la machine consommait deux fois plus de batterie. ### Mise à jour du noyau à la volée #### Intérêt et champ d’application Un nouveau [système de mise à jour du noyau à la volée](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1d9c5d79e6e4385aea6f69c23ba543717434ed70) — c’est‐à‐dire sans redémarrer l’ordinateur, et donc sans interrompre (complètement) les services — a fait son apparition, sous le modeste nom de _livepatch_. La fonctionnalité est particulièrement intéressante pour les serveurs et probablement pour un grand nombre d’autres ordinateurs. Comme on le verra plus bas, ce système de mise à jour n’est pas universel et ne permettra pas de mettre à jour l’ensemble du noyau, mais permettra notamment, on peut l’espérer, de mettre en œuvre des correctifs de sécurité sans redémarrer les systèmes, donc sans fenêtre de maintenance. #### Historique Au commencement, était [kSplice](https://linuxfr.org/users/cosmocat/journaux/mise-%C3%A0-jour-de-s%C3%A9curit%C3%A9-du-noyau-linux-sans-red%C3%A9marrage), une solution de mise à jour à chaud du noyau révolutionnaire, ultérieurement [rachetée par Oracle](http://www.oracle.com/us/corporate/Acquisitions/ksplice/customer-letter-430127.html) pour utilisation exclusive avec sa distribution, fermant la porte à Red Hat, SUSE, etc. S’ensuivirent des violations de GPL (temporaires), et d’[autres piques à Red Hat](https://lwn.net/Articles/524020/). L’année dernière, Red Hat et SUSE ont annoncé quasiment en même temps, respectivement [_kpatch_](http://rhelblog.redhat.com/2014/02/26/kpatch/) et [_kGraft_](https://www.suse.com/communities/conversations/kgraft-live-kernel-patching/), toutes deux des solutions de mise à jour à chaud. Étant données les politiques respectives des deux entreprises, on pouvait espérer qu’une des solutions au moins se retrouve dans la branche principale du noyau. Et ça n’a pas tardé, Red Hat et SUSE ont travaillé de concert en prenant les meilleurs élements de _kpatch_ et _kGraft_. Red Hat a eu l’idée d’utiliser une implémentation plus simple, qui utilise `stop_machine()`, c’est‐à‐dire qui arrête l’ensemble du système pendant quelques millisecondes, regarde la pile, et change le code de la fonction, si c’est sans danger, puis enlève le code de l’ancienne fonction, devenu inutile. De son côté, SUSE décida de travailler au niveau des tâches elles‐mêmes : plutôt que d’arrêter le système, les tâches sont arrêtées une par une, et si une tâche doit appeler la fonction à mettre à jour, alors il est fait en sorte que ce soit la nouvelle qui soit appelée. Dès que chaque tâche a été traitée, l’ancienne fonction est enlevée, et le système tourne effectivement avec le nouveau code. L’avantage est que le système n’est arrêté à aucun moment, mais que la mise à jour peut prendre plusieurs minutes avant de se propager, car il faut également envoyer un signal de réveil aux tâches endormies pour garantir qu’elles ont été mises à jour. Regardez cette [excellente présentation de _kGraft_ à _Kernel Recipes 2014_](https://kernel-recipes.org/fr/2014/patcher-le-noyau-en-temps-reel/) (en anglais) pour plus de détails. Red Hat et SUSE ont tous deux accepté de migrer leurs solutions vers *livepatch* dès que celui‐ci sera suffisamment complet. #### Implémentation Les deux solutions sont basées sur *ftrace*, l’outil de traçage interne au noyau qui permet déjà de mettre à jour à chaud l’_[[incipit]]_ des fonctions du noyau, pour tracer leurs appels à la demande. *livepatch* utilise une des toutes dernières évolutions de *ftrace* qui permet à plusieurs sous‐systèmes du noyau d’utiliser en même temps la mise à jour à chaud dynamique. L’implémentation de *livepatch* qui vient d’arriver dans le noyau a pour but de combiner l’avantage des deux méthodes de _kGraft_ et _kpatch_. Dans un premier temps, cela ne fonctionne que sur l’architecture x86, mais du travail est en cours pour PowerPC, S390 et ARM. #### Concrètement, que voit l’utilisateur ? ~~Vous payez un abonnement à Oracle, Red Hat ou SUSE et votre serveur se met à jour tout seul.~~ Chaque mise à jour est en fait un nouveau module noyau à insérer (donc visible avec `lsmod`). Ce module utilise les API du sous‐système _livepatch_ pour aller remplacer l’implémentation d’une fonction à mettre à jour, par une nouvelle fonction présente dans le module. Cela veut donc dire qu’on ne peut pas, par exemple, mettre à jour une structure (avec un nouveau champ), ou appliquer la totalité des mises à jour ainsi. C’est une opération coûteuse, car le module correctif est fait manuellement à chaque fois. À terme, cela devrait néanmoins permettre de corriger une partie des failles de sécurité découvertes dans le noyau sans devoir redémarrer la machine. Voir l’exemple dans ce [correctif](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=13d1cf7e702596e0cd8ec62afa6bd49c431f2d0c) et le message de ce [correctif de fusion](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1d9c5d79e6e4385aea6f69c23ba543717434ed70). ## Développeurs ### KASan : Kernel Adress Sanitizer _KASan_ est l’équivalent pour le noyau d’_ASan_ ([_Address Sanitizer_](http://en.wikipedia.org/wiki/AddressSanitizer)). Il permet de détecter lorsque le noyau accède à des zones mémoire qu’il n’a pas explicitement alloué auparavant. Il a déjà été utilisé avec succès pour trouver des bogues dans le noyau (parfois en combinaison avec [_Trinity_](http://codemonkey.org.uk/projects/trinity/)). Tout ceci est réalisé à l’aide d’une combinaison de nouvelles fonctionnalités ajoutées au compilateur C de GCC pour suivre les accès à la mémoire. Lorsqu’un accès invalide est effectué, un message complet de la situation est affiché dans le journal système du noyau. Pour cela, le noyau établit une « carte » représentant à l’échelle un huitième la mémoire adressable. Pour l’instant, seule l’architecture x86_64 est gérée. Chaque octet de la carte code la validité de l’accès à la zone de mémoire auquel il correspond. Cette carte est mise à jour par le noyau lors des allocations et désallocations mémoire et est consultée avant chaque accès à la mémoire. _KASan_ bénéficie du fait qu’une partie importante de ses fonctionnalités est implémentée directement dans le compilateur et ajoutée à la compilation dans le noyau. Il est donc plus rapide que `kmemcheck`, mais il ne peut pas détecter l’accès à des zones de mémoire non initialisées. D’autre part, `DEBUG_PAGEALLOC` et `SLUB_DEBUG` sont plus rapides que _KASan_, mais ils sont moins précis que celui‐ci. Plus de détails dans l’article sur _LWN.net_ : [_The kernel address sanitizer](http://lwn.net/Articles/612153/). ### Suppression de l’appel système `remap_file_pages()` Comme annoncé l’an dernier, la mise en œuvre de l’appel système `remap_file_pages()` a été supprimée. À sa place, on a une fonction qui émule la même fonctionnalité utilisant de multiples zones de la mémoire virtuelle, de sorte que les (rares) applications utilisant cet appel devraient continuer à fonctionner. À noter qu’il n’y a pas de ruptures d’API ou d’ABI. [article de [_LWN.net_](http://lwn.net/Articles/597632/)] ### Nouvelles fonctionnalités pour l’outil `perf` L’outil `perf` a bénéficié d’une nouvelle série d’améliorations diverses recensées dans le message du [correctif de fusion](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a4cbbf549a9be10b7583c44249efccd64839533d). ### Read-Copy-Update (RCU) pour fils d’exécution à priorité temps réel Le noyau peut être compilé pour que le méchanisme de synchronisation des fils d’exécution (_threads_) appelé [_read-copy-update_](https://en.wikipedia.org/wiki/Read-copy-update) (RCU) à délai de grâce (_grace-period-handling_) fonctionnent avec des priorités temps réel. La plupart des systèmes n’en ont pas besoin, mais certaines charges de travail élevées peuvent tirer profit de cette fonctionnalité. ### `Tinyfication` : suppression possible d’une version du sous‐système RCU Le sous‐système _read-copy-update_ gérant la mise en veille peut être compilé hors du noyau pour libérer de la place sur les systèmes allégés où il peut ne pas être nécessaire. Voir l’[article de _LWN.net_](http://lwn.net/Articles/202847/) pour plus de détails. ### Vérifications supplémentaire lors d’un appel à `might_sleep()` La fonction de débogage `might_sleep()` va maintenant vérifier le débordement de pile. En effet, il semble que souvent, ce qui ressemble à un appel inapproprié à une fonction de mise en veille est en fait un artefact causé par un débordement de pile. ### Méchanisme `devfreq_event` Le nouveau mécanisme `devfreq_event` fournit un moyen pour les dispositifs en charge de la gestion d’énergie d’obtenir des données brutes sur les performances et l’utilisation de ces dispositifs. ## Périphériques d’entrée ### Pavé tactile FocalTech Une bonne nouvelle pour les possesseurs de portables Asus récents, la gestion des pavés tactiles FocalTech arrive enfin dans cette version du noyau. Auparavant, le périphérique était utilisable au travers de son émulation qui le faisait passer pour une souris USB générique. Cette prise en charge basique était [déjà activée depuis le noyau 3.18](http://lkml.iu.edu/hypermail/linux/kernel/1410.0/03983.html), mais ne permettait que la reconnaissance d’un seul point de contact et des boutons physiques, le reste n’étant accessible qu’au travers d’un protocole propriétaire. C’est [Mathias Gottschlag qui s’est attelé à la tâche de la rétro‐ingénierie](https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1372609/comments/32) et, alors que tout le monde s’attendait à un travail de longue haleine, il a [déchiffré le protocole dans la journée](https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1372609/comments/33). L’intégration a été plus longue, le temps de tester le pilote sur le plus de configurations possibles, les [dernières modifications sont même arrivées dans la RC4](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/input/mouse/focaltech.c). Le pilote noyau étant compatible Synaptics, c’est donc un pavé tactile entièrement fonctionnel et [réglable à souhait](https://wiki.archlinux.org/index.php/Touchpad_Synaptics) au travers de [`synclient`](http://doc.ubuntu-fr.org/touchpad#utilisation_de_synclient) qui nous arrive. ## 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 ([introduite partiellement dans Linux 3.19](https://linuxfr.org/news/sortie-du-noyau-linux-3-19#drm-direct-rendering-manager)) s’achèvent dans cette nouvelle version grâce à l’arrivée d’un nouveau `IOCTL` qui permet enfin d’effectuer un changement atomique. Couplés aux changements proposés par Rob Clark, qui rendent l’état entièrement stocké sous forme de propriété, il devient possible d’utiliser cette gestion atomique depuis l’espace utilisateur ! Cette fonctionnalité reste cependant encore masquée derrière le paramètre `drm.atomic=1`, probablement en attendant que plus de tests soient faits sur l’interface avant que celle‐ci ne devienne publique. Pour plus d’informations sur l’intérêt d’une gestion atomique du mode graphique, vous pouvez consulter la [dépêche précédente sur le noyau 3.19](//linuxfr.org/news/sortie-du-noyau-linux-3-19#drm-direct-rendering-manager). Pour plus d’informations sur les changements apportés spécialement dans cette version du noyau 4.0, vous pouvez consulter [l’article de Daniel Vetter sur le sujet](http://blog.ffwll.ch/2015/01/update-for-atomic-display-updates.html). Comme d’habitude, cette nouvelle version du noyau apporte la gestion de nouveaux panneaux et écrans. Pour plus d’informations, vous pouvez consulter la [demande d’integration](http://www.spinics.net/lists/dri-devel/msg75813.html). Pour plus d’informations, vous pouvez consulter la [demande d’intégration DRM](http://lists.freedesktop.org/archives/dri-devel/2015-February/077595.html). ### AMD/ATI (pilote radeon) La nouveauté principale de ce noyau pour le pilote Radeon est l’amélioration du code de gestion du son via HDMI et l’activation de la sortie audio Display Port pour toutes les générations de cartes qui le gèrent [[_commits_](http://lists.freedesktop.org/archives/dri-devel/2015-January/075368.html)]. Une autre nouveauté importante est l’intégration des modifications nécessaires pour faire fonctionner l’extension OpenGL 4.0 [`ARB_draw_indirect`](https://www.opengl.org/registry/specs/ARB/draw_indirect.txt). Le code pour cette extension est déjà présent dans [Mesa 3D](http://fr.wikipedia.org/wiki/Mesa_3D). La vitesse des ventilateurs pour les familles _Southern Islands_ et _Canary Islands_ ([voir les désignations commerciales](http://xorg.freedesktop.org/wiki/RadeonFeature/#index5h2)) peut maintenant être gérée manuellement par l’utilisateur, grâce à l’interface [HWMON](https://www.kernel.org/doc/Documentation/hwmon/sysfs-interface). La gestion automatique du ventilateur est, quant à elle, présente, mais désactivée par défaut, car elle est encore instable. Pour plus d’informations, vous pouvez consulter la [demande d’intégration _radeon_](http://lists.freedesktop.org/archives/dri-devel/2015-January/076003.html). ### Intel (pilote i915) La conversion du pilote _i915_ vers la gestion atomique du mode graphique continue. Dans cette nouvelle version, le pilote permet la mise à jour des plans graphiques de façon atomique. Il manque cependant encore la gestion asynchrone de cette mise à jour (qui sera disponible dans Linux 4.1) ainsi que la mise à jour des paramètres du filigrane (_watermark_). Du côté de la gestion du mode graphique, un gros travail de réorganisation du code a été fait. Il reste cependant encore à retravailler la gestion des boucles à phase asservie ([PLL](https://fr.wikipedia.org/wiki/Boucle_%C3%A0_phase_asservie)) du bloc d’affichage, afin d’obtenir la gestion atomique des contrôleurs d’affichage vidéo [CRTC](https://en.wikipedia.org/wiki/Video_display_controller). Ce travail a créé une régression dans le cycle RC5 qui a même [pu être reproduite par Linus](http://lkml.iu.edu/hypermail/linux/kernel/1503.3/02205.html), sans pour autant que celui‐ci ne se mette en colère sur la fragilité de l’étape intermédiaire d’atomisation du mode graphique. Une autre nouveauté est la gestion des listes d’exécution _Execlists_. Celles‐ci sont un nouveau mode d’envoi de commandes au processeur graphique introduit dans le matériel, en parallèle de l’ancien mode dans les processeurs _Broadwell_, et unique moyen d’envoyer des commandes aux processeurs graphiques _Skylake_ et suivants. Ce nouveau mode est activé par défaut pour les processeurs qui le gérent. La gestion du PPGTT (_Per‐Process Graphics Translation Table_), carte de correspondance mémoire vidéo par processus, est maintenant activée par défaut sur les processeurs gérant les _Execlists_. Il reste encore des bogues à corriger sur les processeurs plus anciens. Si vous voulez en savoir plus, vous pouvez consulter l’habituel [compte‐rendu détaillé des modifications](http://blog.ffwll.ch/2015/02/neat-drmi915-stuff-for-320.html) de Daniel Vetter (mainteneur _i915_). ### NVIDIA (pilote nouveau) Peu de nouveautés majeures dans cette nouvelle version, à cause du travail nécessaire pour la gestion des nouveaux processeurs graphique _Maxwell_. Cependant, Ben Skeggs a profité du calme pour unifier les noms des différents composants avec les noms utilisés par NVIDIA. Cela va permettre une communication plus simple avec les ingénieurs de chez NVIDIA. Ben Skeggs a également commencé le travail de séparation entre DRM et NVKM. À terme, cela permettra à plusieurs instances de _Nouveau-DRM_ s’exécutant dans différentes machines virtuelles de pouvoir fonctionner en parallèle, et ainsi fournir une accélération complète dans chaque machine virtuelle. Pour l’instant, ce travail a uniquement consisté en le renommage des différents fichiers et structures. Pour finir, les ingénieurs de NVIDIA ont ajouté la gestion manuelle du recadencement (_reclocking_) pour les processeurs graphiques monopuces GK20A. Ils ont également décidé de fusionner le module de détection de plate‐forme (`nouveau_platform.ko`) avec `nouveau.ko` afin, entre autres, de [simplifier la gestion des symboles](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=055a65d5987a7f246c3fc2297158286882dbdbcf). ### Pilotes grahiques pour systèmes monopuces #### Qualcomm (pilote msm) Le pilote Linux pour les processeurs graphiques _Adreno_ de Qualcomm s’améliore avec la gestion du [eDP](https://en.wikipedia.org/wiki/DisplayPort#eDP) et des curseurs matériels _mdp5_. Ces derniers, ainsi que les curseurs matériels _mdp4_, se voient également dotés de la gestion du format [[YUV]]. Pour plus d’information, vous pouvez consulter la [demande d’intégration _msm_](http://lists.freedesktop.org/archives/dri-devel/2015-February/076673.html). Pour avoir un compte‐rendu de l’état du pilote _msm_ + _freedreno_, vous pouvez consulter l’[article récapitulatif de _LWN.net_](https://lwn.net/Articles/638908/) sur la présentation de Rob Clark, le créateur initial et principal du projet. #### NVIDIA (pilote tegra) Du côté des processeurs graphiques Tegra de NVIDIA, la nouveauté principale est la conversion (semble‐t‐il complète) vers la gestion atomique du mode graphique. Bravo à Thierry Reding pour son travail ! Le pilote de blocs _host1x_ a également été amélioré afin de gérer la mise en veille et le réveil des différents blocs qu’il contrôle. Pour plus d’information, vous pouvez consulter la [demande d’intégration _tegra_](http://www.spinics.net/lists/linux-tegra/msg21220.html). #### Renesas (pilote rcar-du) Le pilote du processeur graphique de Renesas a reçu quelques améliorations liées à l’affichage, telles que la gestion des [modes entrelacés](https://fr.wikipedia.org/wiki/Entrelacement_(vid%C3%A9o)) ou la possibilité d’utiliser une horloge externe. Il est également maintenant possible de chaîner un encodeur HDMI après un encodeur [[LVDS]]. Pour plus d’information, vous pouvez consulter la [demande d’intégration _rcar-du_](http://lists.freedesktop.org/archives/dri-devel/2014-December/074520.html). #### Samsung (pilote exynos) La nouveauté principale du pilote pour les processeurs graphiques des systèmes monopuces de Samsung est la gestion du contrôleur d’affichage DECON qui est introduit dans les Exynos7. Ce contrôleur est apparemment très différent du contrôleur précédent qui avait été introduit dans les Exynos4. La gestion atomique du mode graphique devait faire partie de cette nouvelle version, mais trop de bogues étaient encore présents pour rendre ce code disponible. Pour plus d’informations, vous pouvez consulter la [demande d’intégration](http://lists.freedesktop.org/archives/dri-devel/2015-February/077456.html). ## Réseau ### Algorithmes TCP d’évitement de congestion Il est maintenant possible de choisir un algorithme d’évitement en fonction du destinataire, simplement via la table de routage. Par exemple :> `ip route add 10.0.42.0/16 dev eth0 congctl hybla` ### Gestion des espaces de noms pour TIPC L’implémentation du protocole de communication transparente interprocessus — [_Transparent Inter‐Process Communication protocol_](http://tipc.sourceforge.net/) — gère désormais correctement les espaces de noms. ### Identifiants de flux pour Open vSwitch Le sous‐système [_Open vSwitch_](http://en.wikipedia.org/wiki/Open_vSwitch) peut maintenant générer ses propres identifiants de flux (_flow IDs_) pour identifier les échanges réseau dans le trafic de commandes en mode utilisateur. Les performances de certaines opérations peuvent être améliorées jusqu’à 40 % grâce à cette amélioration. ### Gestion des filtres eBPF pour le contrôle du trafic réseau Le sous-système de contrôle du trafic prend désormais en charge l’utilisation de filtres écrits dans le langage de la machine virtuelle [eBPF](http://fr.wikipedia.org/wiki/BSD_Packet_Filter "extended Berkeley Packet Filter"). ## Sécurité ### Prise en compte des puces TPM 2.0 Les puces [_Trusted Platform Module_](http://fr.wikipedia.org/wiki/Trusted_Platform_Module) 2.0 sont prises en charge [correctifs : [_1_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7a1d7e6dd76a2070e2d86826391468edc33bb6d6), [_2_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=30fc8d138e9123f374a3c3867e7c7c5cd4004941), [_3_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=aec04cbdf7231c1b0da76172de82dfa2388a80d7)]. ### Version 2.2.0 de la bibliothèque seccomp Cette version de [_seccomp_](http://en.wikipedia.org/wiki/Seccomp) ajoute [[_annonce_](http://lwn.net/Articles/633155/)] : * la prise en charge des architectures [AArch64, MIPS, MIPS64, MIPS64 N32 ; * la gestion du nouvel appel système `seccomp()` et de la synchronisation des filtres pour les programmes à multiples fils d’exécution (_multithreads_) [_Cf._ [dépêche 3.17](//linuxfr.org/news/sortie-de-linux-3-17#filtres-seccomp-pour-les-programmes-multithreads)] ; * l’inclusion des bibliothèques de liaison (_bindings_) pour Python ; * la mise à jour de la liste des appels système disponibles (noyau 3.19). ### LSM David Howells a corrigé la façon dont les différents modules LSM effectuaient certaines vérifications sur les nœuds d’index (_inodes_) pour améliorer la prise en compte du système de fichiers [[OverlayFS]] [correctifs : [_1_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7ac2856d99e8038d356767c81ef7f2e85d366441), [_2_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=729b8a3dee2bc873e4647e9384de9111548e599e), [_3_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e656a8eb2e0b35258219bb46929323e4d1f49dad), [_4_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8802565b605fc718046684f463845a1147f2fabd), [_5_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2c616d4d88de1dc5b1545eefdc2e291eeb9f2e9d) et [_6_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e36cb0b89ce20b4f8786a57e8a6bc8476f577650)]. ### SELinux #### Gestion de Binder Le mécanisme de communication interprocessus _Binder_, propre à Android, est maintenant contrôlable à l’aide des « crochets » LSM et la prise en charge de SELinux a été ajoutée dans cette version [[_correctif_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=79af73079d753b2d04e46f7445716d3b5f914dbd)]. #### SMACK La gestion du marquage de paquets réseau à l’aide de `secmark` de [[Netfilter]] a été ajoutée pour les paquets locaux en IPv4 et IPv6 [[_correctif_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=69f287ae6fc8357e0bc561353a2d585b89ee8cdc)]. Les étiquettes CIPSO sont utilisées dans les autres cas [[_correctif_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7f368ad34f0657f4bc39bf5bad6692b5a81a1194)]. Les opérations sur les fichiers et les accès bidirectionnels à un [_socket_ UNIX](http://fr.wikipedia.org/wiki/Berkeley_sockets#Socket_unix) sont désormais contrôlées et auditées correctement [correctifs : [_1_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5e7270a6dd14fa6e3bb10128f200305b4a75f350), [_2_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=96be7b5424948ae39d29d5149eaec0bd6edd7404) et [_3_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=138a868f009bfca8633032cdb91e2b02e292658b)]. Un autre cas particulier où une zone de mémoire partagée liée à un fichier situé sur un _tmpfs_ pouvait se retrouver avec la mauvaise étiquette a été corrigé [[_correctif_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1d8c2326a4a2a4d942f9165b5702fe6f869ccf48)]. L’utilisation de _KASan_ a permis de corriger un cas potentiel d’utilisation d’une zone mémoire après qu’elle a été libérée [[_correctif_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6d1cff2a885850b78b40c34777b46cf5da5d1050)]. ### Liste non exhaustive des vulnérabilités corrigées * [CVE-2014-8159](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8159) [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8494057ab5e40df590ef6ef7d66324d3ae33356b)] ; * [CVE-2015-2150](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-), [XSA-120](http://xenbits.xen.org/xsa/advisory-120.html) [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=af6fc858a35b90e89ea7a7ee58e66628c55c776b)] ; * [CVE-2015-1593](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-) [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4e7c22d447bb6d7e37bfe39ff658486ae78e8d77)]. ## Systèmes de fichiers ###Lazytime Sur les systèmes de fichiers [[POSIX]], trois dates sont associées à chaque fichier (en réalité à chaque [nœud d’index](http://fr.wikipedia.org/wiki/N%C5%93ud_d%27index)) : `mtime` correspond à la date de dernière modification du contenu, `ctime` correspond à la date de dernière modification des métadonnées (propriétaire, groupe, droits...) et enfin `atime` correspond à la date du dernier accès. Le champ `atime` a été l’objet de nombreuses critiques au cours du temps, chaque lecture du fichier entraînant une opération d’écriture afin de mettre à jour le champ. Pour éviter de multiplier les écritures inutiles, plusieurs stratégies successives ont été développées sous forme d’options de montage des systèmes de fichiers. Voici un résumé des anciennes solutions (consultez la [page de manuel de `mount`](https://web.archive.org/web/20150507105052/http://www.linux-france.org:80/article/man-fr/man8/mount-8.html) (NdM: remplacement par un lien archive.org) pour avoir des détails) : - `atime` et `diratime` pour le fonctionnement historique ; - `noatime` et `nodiratime` sont les plus simples, le champ `atime` n’est plus mis à jour en cas d’accès en lecture ; - `relatime` pour ne faire les mises à jour de `atime` que dans le cas où il n’y avait pas eu de lecture depuis la dernière écriture, l’option inverse étant `norelatime` ; - `strictatime` pour forcer le mode `atime`. Une nouvelle option de montage des systèmes de fichiers a été intégrée au noyau : **`lazytime`**. Cette dernière maintient la date de dernier accès dans `atime`, mais la conserve uniquement en mémoire. Tout le système voit donc des champs `atime` mis à jour conformément à la norme. Ces modifications sont reportées sur le disque dans les cas suivants : - le nœud d’index doit être modifié pour toute autre raison ; - l’application force une synchronisation (`fsync`, `syncfs` ou `sync`) ; - en cas de manque de mémoire ; - toutes les 24 heures (ext4 uniquement pour le moment, c’est le comportement récent de `relatime` sur ce système de fichiers). L’objectif est de réduire les écritures disque liées à `atime` de manière plus efficace que `relatime`, en profitant des écritures obligatoires, et de gagner en précision et fonctionnalités, en rétablissant le comportement historique de `atime`. Cette option, initialement développée pour ext4 a finalement été remontée au niveau de la couche [[VFS]] (_Virtual FileSystems_ — système de fichiers virtuel) pour permettre à tous les types de systèmes de fichiers d’en profiter. Pour ceux qui sont intéressés, _LWN.net_ y a dédié un [article](https://lwn.net/Articles/621046/ "[LWN.net] Introducing lazytime") (en anglais). ###Btrfs Entre autres, grâce au déploiement de Btrfs au sein de grosses grappes de serveurs chez Facebook, Josef Bacik a corrigé un problème dans lequel le système de fichiers retournait à tort des erreurs de type « manque de place » (`ENOSPC`). Le code de gestion des niveaux [RAID](http://fr.wikipedia.org/wiki/RAID_%28informatique%29 "Redundant Array of Independent Disks") [5](http://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 [6](http://fr.wikipedia.org/wiki/RAID_%28informatique%29#RAID_6) a été nettoyé. Un bogue a cependant été introduit et a retardé la [demande de fusion](https://lkml.org/lkml/2015/2/19/423). Le correctif a, quant à lui, été [édité le lendemain même](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/fs/btrfs?id=e57cf21e9787c081db4db6afa02e6e70112ee410). ###Ceph RBD (la version « périphérique de type bloc » du client Ceph) exploite maintenant le composant « multi‐queue » du noyau, ce qui devrait en améliorer les performances. De plus, l’option `tcp_nodelay` est maintenant prise en compte, afin de réduire la latence. De son côté, CephFS reçoit de nombreux correctifs. Pour plus d’informations, veuillez consulter la [demande d’intégration](https://lkml.org/lkml/2015/2/19/368). ###F2FS [F2FS](http://fr.wikipedia.org/wiki/F2FS), le système de fichiers spécialisé pour les mémoires Flash n’a subi que des modifications mineures, nettoyage de code et correction de bogues [_[demande d’intégration](http://lkml.iu.edu/hypermail/linux/kernel/1502.1/03032.html)_]. ###OverlayFS OverlayFS a été intégré dans le [noyau 3.18](http://linuxfr.org/news/sortie-du-noyau-linux-3-18#overlayfs). Ce système de fichiers, principalement utilisé par les distributions sur support autonome (_live_), s’est vu ajouter la [gestion du multicouche](http://linuxfr.org/news/sortie-du-noyau-linux-3-19#overlayfs-multicouche) en 3.19. Dans ce nouveau noyau est ajoutée la possibilité d’avoir de multiples couches en lecture seule. La couche supérieure accessible en écriture est désormais optionnelle [_[demande d’intégration](http://lkml.iu.edu/hypermail/linux/kernel/1502.1/01782.html)_]. ### pNFS Le sous‐système [_parallel NFS_](http://www.pnfs.com/) (pNFS) a obtenu la prise en compte de la disposition [_FlexFile_](http://tools.ietf.org/id/draft-ietf-nfsv4-flex-files-04.txt) en cours de développement. Cette disposition permet aux métadonnées de fichiers d’être stockées à un endroit différent du contenu des fichiers. ## Virtualisation ### [VirtIO](http://lkml.iu.edu/hypermail/linux/kernel/1502.2/01510.html) [Rusty Russel](http://en.wikipedia.org/wiki/Rusty_Russell) a annoncé l’implémentation de la version 1.0 du standard [VirtIO](http://lwn.net/Articles/239238/) selon les [spécifications OASIS](http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.html). Ces périphériques dédiés aux environnements virtuels, permettent aux invités d’utiliser des pilotes et mécanismes de découverte standards et documentés, plutôt que des variantes par type de systèmes d’exploitation ou d’environnements. L’intérêt pour un standard (plutôt qu’un billet de blog et le code) s’est montré avec l’adoption massive de VirtIO. On ne le retrouve pas que dans [[KVM]], il est aussi utilisé dans [[Xen]], [[VirtualBox]], [BHyVe](http://en.wikipedia.org/wiki/Bhyve) (l’hyperviseur de FreeBSD) et même dans les ordiphones, pour communiquer avec les accélérateurs matériels. Plus de détails dans l’article [_Standardizing virtio_](http://lwn.net/Articles/580186/) de _LWN.net_. ###[KVM](https://lkml.org/lkml/2015/2/12/492) Une amélioration est commune à toutes les architectures, il s’agit d’introduire une scrutation (_polling_) lorsqu’une instruction d’arrêt [`HLT`](http://en.wikipedia.org/wiki/HLT) (ou équivalent sur d’autres architectures) est exécutée sur l’invité. Cela peut diminuer la latence jusqu’à 50 %. Actuellement, il faut l’activer manuellement, mais le but à terme est d’avoir une activation automatique. - *ARM* : émulation du contrôleur d’interruptions GICv3 ; - *S390* (ordinateurs centraux IBM) : une petite victoire pour le développement du noyau Linux, il est maintenant possible d’avoir les identifiants uniques UUID et les noms longs d’invités dans `/proc/sysinfo` avant que cette fonctionnalité soit disponible dans l’hyperviseur d’IBM ; - *x86* : prise en charge de la journalisation des modifications des pages mémoire (*page modification logging*), une nouvelle fonctionnalité des processeurs Xeon _Broadwell_ qui accélère le suivi des *dirty pages*. La virtualisation imbriquée gère l’APICv (des instructions processeur qui accélèrent l’émulation des contrôleurs d’interruptions programmables — [APIC](http://en.wikipedia.org/wiki/Advanced_Programmable_Interrupt_Controller "Advanced Programmable Interrupt Controller") — dans les machines virtuelles). Enfin, la latence des minuteurs (_timers_) d’interruption de type *TSC deadline* peut être réduite avec une nouvelle option (ces minuteurs permettent de soulager le processeur en demandant au contrôleur d’interruptions de générer une interruption quand le temps est écoulé, au lieu de laisser ce calcul au processeur). Toutes les architectures ont, bien sûr, reçu des correctifs de bogues. ###Xen Pas de nouveauté pour cette version. ## Pages de manuel Les pages des manuels continuent d’être mises à jour régulièrement. Les dernières nouveautés depuis la dernière mention dans ces colonnes sont listées dans le [journal des modifications](http://man7.org/linux/man-pages/changelog.html#release_3.78). # Le bilan en chiffres En ce qui concerne les statistiques du cycle de développement du noyau 4.0, le site _LWN.net_ a publié son traditionnel [article récapitulatif](https://lwn.net/Articles/637909/). En nombre de modifications, on se situe à un peu plus que 10 000, soit environ 2 400 modifications de moins que la version précédente du noyau, ce qui en fait le cycle le plus calme depuis quelques années. Cependant, ce « calme » est relatif puisque 403 000 lignes de code ont été ajoutées alors que 222 000 lignes ont été supprimées, ce qui a conduit à une augmentation nette de 181 000 lignes. Le nombre de contributeurs reste, quant à lui, relativement constant avec 1 403 auteurs. Pour une fois, le développeur ayant apporté le plus de modifications n’est pas H. Hartley Sweeten, pour son travail de nettoyage des pilotes Comedi, mais Lars‐Peter Clausen, pour son travail de nettoyage et d’amélioration des pilotes audio. Du côté des développeurs ayant le plus modifié de lignes, Ben Skeggs remporte la palme par son travail de renommage des puces et la séparation de NVKM et DRM (voir la [sous‐section sur le pilote Nouveau](https://linuxfr.org/news/sortie-du-noyau-linux-4-0#nvidia-pilote-nouveau)). Environ 200 entreprises ont participé à l’élaboration de ce noyau. En tête, on retrouve Intel, qui a effectué 11,6 % des changements que l’on peut trouver dans cette nouvelle version. En deuxième place, Red Hat a contribué pour 7,0 % des changements. Il est cependant important de noter que les développeurs sans affiliation ont effectué 8,6 % des modifications, soit juste un peu moins qu’Intel, alors que les personnes non identifiées ont écrit 7,1 % 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) | [Jiehong](https://linuxfr.org/users/jiehong) **Développeurs** | Aucun | **Pilotes graphiques libres** | [Martin Peres](//linuxfr.org/users/mupuf) | **Réseau** | Aucun | | **Systèmes de fichiers** | Aucun |[Kioob](//linuxfr.org/users/kioob), [Mali](//linuxfr.org/users/mali) | **Sécurité** | [Timothée Ravier](//linuxfr.org/users/siosm) | **Virtualisation** | [Xavier Claude](//linuxfr.org/users/claudex) | **Édition générale** | Aucun | [Martin Peres](//linuxfr.org/users/mupuf) 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. 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). Essayons d’augmenter la couverture sur les modifications du noyau !

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