URL: https://linuxfr.org/news/sortie-du-noyau-linux-3-15 Title: Sortie du noyau Linux 3.15 Authors: Martin Peres Davy Defaud, Siosm, JPEC, BAud, Florent Fourcot, rogo, Romain Perier, Albert_, Batchyx, palm123, Jiehong, ʭ ☯ , kp, claudex, jcr83, ariasuni, maboiteaspam, titinux, Nÿco, RoPP, Mali, Jarvis, Sytoka Modon, zyprexa, Strash, Benoît Sibaud, barmic et antistress Date: 2014年04月01日T14:29:42+02:00 License: CC By-SA Tags: linux, kernel, noyau_linux, coulisses, linus_torvalds, selinux et lwn Score: 108 La sortie de la version stable 3.15 du noyau Linux vient d’être annoncée par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site [_kernel.org_](https://www.kernel.org/). Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche. ![Tux](http://upload.wikimedia.org/wikipedia/commons/a/af/Tux.png) ---- [Les noyaux précédents](http://linuxfr.org/wiki/depeches_noyau) [Site officiel du noyau Linux](http://www.kernel.org) [Le détail des nouveautés sur kernelnewbies.org](http://kernelnewbies.org/Linux_3.15) [The Top Features Of The Linux 3.15 Kernel](http://www.phoronix.com/scan.php?page=news_item&px=MTcwOTY) ---- # En bref - Pilotes graphiques libres : - DRM : interface unifiée pour la gestion des plans graphiques ; - Radeon : gestion de l’encodage vidéo matériel et d’une nouvelle puce unifiée avec processeur graphique intégré (APU) ; - Nouveau : gestion initiale de la famille Kepler et meilleure gestion des ventilateurs. - Réseau : - amélioration forte des performances ; - affectation de règles _iptables_ à un _cgroup_. - Systèmes de fichiers : - réduction du temps de réveil après une mise en veille en mémoire vive ; - nouvel appel système pour échanger les noms entre deux fichiers de façon atomique ; - verrous POSIX par fichier ; - ajout de la gestion de l’algorithme de compression [LZ4](http://linuxfr.org/news/linux-pour-workgroups-3-11-le-noyau-pret-pour-le-bureau#compression-lz4-pour-le-noyau) pour [zram](http://linuxfr.org/news/le-noyau-linux-2636-est-disponible#bref19). # La phase de test ## RC-1 La version RC-1 est sortie le [13 avril 2014](https://lkml.org/lkml/2014/4/13/121).> Ça fait deux semaines que la 3.14 a été livrée et la 3.15-rc1 est maintenant étiquetée et publiée ; les correctifs et les archives _tar_ » sont — au moment où j’écris ces lignes — en train de passer dans les compresseurs de _kernel.org_. Ce qui veut dire que la fenêtre de fusion est fermée et que les gens doivent m’envoyer uniquement des corrections de bogues.>> Et franchement, il était temps. Cette version ne contient pas vraiment de choses bizarres, mais elle est grosse. Bien sûr, nous avons déjà eu des versions avec plus de lignes et de fichiers modifiés (3.7-rc1 et 3.11-rc1, notamment), mais celles-ci ont tendance à avoir quelque chose de particulier dedans (3.7-rc1 a vu la désintégration largement automatisée du fichier d’en-tête UAPI et la 3.11 a vu la fusion de la correction des bogues de Lustre).>> En comparaison de ces grosses versions, 3.15-rc1 est seulement grosse. Pas de gros changement unitaire, mais seulement énormément de correctifs. Effectivement, il y a eu quelques intégrations de nouveaux pilotes (rtl8723au, notamment). Mais, même s’ils étaient gros, ils ne représentent pas la majorité des changements. Il y a seulement énormément de changements.>> En fait, nous avons le plus grand nombre de correctifs dans l’histoire récente (peut-être depuis toujours), à un peu plus de 12 000 correctifs hors fusions (et environ 800 fusions).>> Et il y en a vraiment un peu partout. L’essentiel concerne les modifications de pilotes, ce qui représente environ trois quarts des modifications. Le _staging_ se démarque, mais c’est vraiment sur tout ​​le périmètre des pilotes, avec le réseau, le son, les médias, les pilotes graphiques, les pilotes de blocs...>> Mais il y a aussi des tonnes de trucs qui ne concernent pas les pilotes. En dehors du sous-répertoire des pilotes, les mises à jour d’architecture comptent environ pour la moitié des changements (avec en tête ARM, principalement dû aux « _device-tree descriptors_ ». Mais il y a aussi IPS, x86, PowerPC, s390, Blackfin...). Et le reste est aussi assez varié, avec le cœur du réseau, la documentation, le noyau, mm, les outils, etc.>> Ainsi, alors que les modifications de pilotes et d’architecture représentent l’essentiel, nous avons aussi beaucoup de changement du cœur.> > Quoi qu’il en soit, encore plus que d’habitude, la RC-1 est beaucoup trop grande pour inclure un résumé du rapport de toutes les publications. Mais le résumé du rapport des fusions que j’ai fait peut donner à minima une vue d’ensemble de tous les changements. Comme d’habitude, les personnes citées dans le rapport de fusion sont les mainteneurs depuis que j’ai récupéré les changements, et non les développeurs qui ont écrit le code. Vous pouvez voir ça dans les journaux complets de _git_.>> Quoi qu’il en soit, comme la RC-1 est déjà sacrément grosse, je ne veux pas entendre de « désolé j’ai raté la fenêtre, puis-je encore me faufiler ? ». Corrections uniquement.>> La seule exception concerne deux choses en cours qui sont arrivées pendant la fenêtre de fusion, mais qui ont été explicitement retardées. Nous avons donc en attente un mouvement de fichier _fbdev_ (je ferai le mouvement du fichier après la RC-1, simplement pour que les choses soient plus simples à voir dans l’historique et ne pas mélanger les mouvements avec les développements). Et il y avait une demande de fusion sur les espaces de noms et montages que je n’ai pas intégrée, mais que je ferai probablement après quelques améliorations ou commentaires supplémentaires. Ça retardera probablement la 3.16, mais nous verrons de combien de lignes de code ce truc a besoin...>> Linus ## RC-2 La version RC-2 est sortie le [20 avril 2014](https://lkml.org/lkml/2014/4/20/92).> « Et le septième jour la RC est ressuscitée, conformément aux Écritures du _Kernel summit_ de l’année 2004. »> > Cela fait une semaine, donc voici une nouvelle RC. Et alors que la RC-1 était de mémoire une des plus grosses RC, la RC-2 a l’air tout à fait normale. Nous avons eu quelques erreurs tenaces corrigées, mais ce n’était pas réellement quelque chose de pire que d’habitude. C’est peut‐être un **peu** plus gros que la plupart des RC-2, mais attendons de voir après la RC-3 quelles choses sont vraiment plus actives que d’habitude. La RC-2 est régulièrement plus calme que la RC-3, car il faut plus d’une semaine pour que certaines anomalies surviennent.> > Quant à ce qu’il s’est passé au cours de la semaine dernière, le *gros* du correctif RC-2 est, en fait, la suppression du pilote RTL8187SE de _staging_, car il y en a maintenant un bon en dehors de _staging_. C’est vraiment un peu plus de la moitié du correctif en lui‐même. Mais, même si vous ignorez tout simplement cette sortie, les autres changements de pilotes représentent environ les deux tiers du reste (pilote graphiques, réseau, renommage des fichiers _fbdev_, IPMI, InfiniBand, _pin control_... Nommez votre pilote préféré). La partie concernant le DRM est probablement la plus remarquable.> > En dehors des pilotes, nous avons les mises à jour habituelles d’architectures (principalement x86 et s390, un peu de PA-RISC) et quelques mises à jour de documentation. Quelques corrections pour le réseau et des mises à jour de système de fichiers (CIFS, sysfs, XFS). Et quelques trucs d’outillage.>> Testez, s’il vous plaît,>> Linus ## RC-3 La version RC-3 est sortie le [27 avril 2014](https://lkml.org/lkml/2014/4/27/282).> Nouvelle semaine, nouvelle RC. Jusqu’à présent, pas de grosses craintes et la RC-3 est adéquatement plus petite que la RC-2 ne l’était, nous sommes donc sur la bonne voie.>> Les statistiques semblent relativement normales, avec une moitié de pilotes (pilote d’entrées, USB, pilotes graphiques, ACPI, régulateur...) et un tiers de mises à jour d’architectures (la majorité portant sur les fichiers [DTS](http://en.wikipedia.org/wiki/Device_tree "device tree source") pour ARM, mais aussi d’autres mises à jour sur ARM et [_user-mode_](http://fr.wikipedia.org/wiki/User_Mode_Linux)). Le reste est varié, mais principalement concentré sur les mises à jour des systèmes de fichiers (Btrfs et ext4).>> Linus ## RC-4 La version RC-4 est sortie le [4 mai 2014](https://lkml.org/lkml/2014/5/4/438).> Rien de particulièrement exceptionnel en cours. 45 % de pilotes (DRM, son, [md](http://en.wikipedia.org/wiki/Mdadm "multiple device), pin-control, ACPI, etc.), 40 % d’architecture (principalement powerpc/powernv, mais aussi x86 et ARM), 15 % de divers (outillage de performance, mises à jour documentaires et code du noyau). Le rapport simplifié ci‐joint donne un bon aperçu des détails sans être trop gros.> > Il y a encore quelques trucs en cours (par exemple, une correction en attente pour une intéressante corruption de la liste des « entrées de répertoires » (_dentry_) — même si une utilisation normale aura peu de risque d’être affectée). Mais, dans l’ensemble, c’est relativement calme et il n’y a rien d’horriblement effrayant. Nous sommes au milieu de la période d’apaisement, donc c’est comme je l’aime.>> Mais, plus nous avons de tests, mieux c’est ; donc, s’il vous plaît, essayez-la.> > Linus ## RC-5 La version RC-5 est sortie le [9 mai 2014](https://lkml.org/lkml/2014/5/9/523).> Oui, je suis conscient que c’est en avance de deux jours. Le programme normal était pour moi de faire des versions dominicales, mais, cette fois j’ai une combinaison de voyage (ce qui aurait avancé la version à samedi matin depuis l’aéroport comme c’est souvent mon habitude quand je voyage) et il se trouve que la RC-5 avait déjà suffisamment grossi pour être plus grosse que les RC-3 et RC-4 ne l’étaient.>> Donc, au lieu de publier ça à la dernière minute avant que j’embarque dans un avion et que je sois hors ligne pour une semaine, j’ai décidé qu’il n’y a absolument aucune raison pour ce genre de livraison _sur le fil_. Je préfère faire une livraison tranquillement un vendredi après‐midi, plutôt qu’une précipitée un lendemain matin avant de disparaître pendant une semaine.>> Peu importe, assez d’explications. La RC-5 est sortie et, bien que j’eusse été plus joyeux si ça avait été aussi petit que la RC-4, ça semble n’être que des corrections solides (fameux derniers mots). L’intéressante corruption de la liste `dcache`, que j’avais mentionnée comme reliquat de la RC-4, est dedans ; et ce serait adorable si vous aviez un test de charge pour la couche VFS qui interagit avec la consommation de mémoire. Mais, le jeu en valait la chandelle, la correction nettoie pas mal de choses et retire plus de lignes qu’elle n’en ajoute, donc je la sens bien.>> Exceptée cette intéressante modification véritable du cœur (où « véritable du cœur » est défini comme « un domaine auquel je tiens particulièrement », et ne signifie rien de plus ;), tout semble ennuyeusement familier : 55 % de pilotes, 20 % de mises à jour d’architectures et 25 % de divers (systèmes de fichiers, cœur du réseau, machines virtuelles, etc.).> > Et, bien que cette RC-5 soit peut‐être plus grosse que les RC-3 et 4 ne l’étaient, ce n’est pas comme si c’était inquiétant. Cette période de fusion était plus grosse que la moyenne, et le fait que la RC-5 est donc un peu plus grosse que la moyenne n’est pas quelque chose qui m’inquiète plus que ça. Et comme la RC-4 était plus petite que d’habitude, tout s’égalise.> > Mais je *serai* réellement entièrement non joignable toute la semaine prochaine, donc faites vos tests, parce que l’arborescence _git_ sera très calme. > > Linus ## RC-6 La version RC-6 est sortie le [22 mai 2014](https://lkml.org/lkml/2014/5/21/610).> À cause des voyages et du manque d’accès à Internet, des publications de RC n’ont pas suivi le cycle normal de publication dominicale, et, comme j’ai pris connaissance de ce qu’il s’est passé pendant que j’étais hors ligne, plutôt que d’attendre jusqu’à dimanche prochain pour revenir à un cycle normal, je publie en conséquence la RC-6 en milieu de semaine depuis Tokyo.> > Avec la RC-5 qui était en avance de quelques jours et la RC-6 qui est en retard, nous avons presque deux semaines entre elles. La taille du résultat n’est pas deux fois plus grosse cependant. En partie parce qu’heureusement on a avancé dans la série des RC et que les choses sont censées se calmer, mais aussi parce que certains sous‐mainteneurs n’ont pas envoyé leurs demandes d’intégration car ils savaient que j’étais hors ligne. Quelle que soit la raison, c’est pas mal.>> La distribution du correctif à l’air normale aussi. Principalement des pilotes (ACPI, son, média, pilote graphique i915, horloge _clk_, PCI...), avec le gros du reste qui correspond à diverses mises à jour d’architectures (notamment MIPS, mais aussi ARM et PA-RISC). Et une poignée de trucs divers dans les systèmes de fichiers et le code du cœur du noyau.> > De toute façon, en fonction de ce qui est en cours, je rallongerai un peu la RC-7 pour revenir à une planification dominicale et, en fonction de comment les choses se passent d’ici là, ça pourrait être ne pas être la dernière RC.> > Mais, s’il vous plaît, testez ça,>> Linus ## RC-7 La version RC-7 est sortie le [25 mai 2014](https://lkml.org/lkml/2014/5/25/138).> ... cette sortie dominicale se recale sur le calendrier habituel.>> La RC-6 a seulement quelques jours, mais, comme prévu, du travail m’attendait à la maison. Cette version est donc normale, la RC-6 ayant juste été décalée par mon voyage.>> Le contenu est en grande partie composé de changements concernant le réseau (principalement les pilotes), puisque les autres branches avaient été mises à jour pour la RC-6. Il y a aussi d’autres petits changements (DRM, ordonnanceur, _perf_, NFS, AFS, etc.).>> Linus ## RC-8 La version RC-8 est sortie le [1^(er) juin 2014](https://lkml.org/lkml/2014/6/1/264).> J’ai vraiment espéré que la RC-7 serait la dernière RC, mais la réalité a encore conspiré contre mes super plans bien établis, et me force donc à faire une RC-8. Ce n’est pas comme s’il y avait beaucoup de changement, mais une correction de dernière minute de _dcache_ me fait penser que cela ne serait pas complètement sain de sortir la version définitive sans une semaine de test supplémentaire.>> De tout de façon, normalement, une RC-8 n’est pas vraiment un énorme changement — la 3.15 est une des plus grosses (si ce n’est **la** plus grosse) version depuis bien longtemps, et nous faisons des RC-8 assez régulièrement. Ça pourrait ne pas être le cas de toutes les versions, mais je pense que nous avons 50 % de chances de faire une RC-8 à chaque version. Aussi je ne suis pas très fâché, et sûrement pas surpris.>> Non, la véritable raison pour laquelle j’avais espéré que nous n’aurions pas besoin de faire une RC-8 pour la 3.15, c’est que c’est la fin des classes dans deux semaines et nous devons prendre nos vacances en famille juste après. Je déteste avoir encore un « Linus voyage pendant la fenêtre des fusions ». Normalement, je suis plus chanceux que ça durant dans mes voyages.>> Certes, j’aurai Internet, et je *pourrais* faire la fenêtre des fusions pendant mes vacances en famille. Je préférerais juste ne pas à avoir le faire.>> Aussi, essayons de voir comment cela va marcher — les dernières semaines de versions consistent généralement à regarder et être sûr que rien de grave ne se passe, par conséquent, le développement *devrait* fonctionner. Peut‐être que si cela fonctionne bien, nous finirons par continuer comme cela, même s’il n’y pas de conflit de calendrier qui me fait vouloir démarrer la fenêtre des fusions avant que je sois 100 % satisfait de la version précédente.>> Ce n’est pas comme si je pensais que la RC-8 était cassée de quelque façon que ce soit. Je ne me sentais simplement pas faire une version 3.15 sans un _petit_ peu plus de temps pour que les gens testent le correctif pour le `dentry`.>> Quoi qu’il en soit, en dehors du changement `dcache`, il y a plein de petites choses éparpillées. Un changement d’une ligne est particulièrement intéressant : Minchan Kim avait trouvé un cas de figure qui remplissait entièrement la pile du noyau sur l’architecture x86-64 ; et, bien que cela soit quelque chose que je repoussais depuis longtemps, ce changement étend la pile à 16 Kio. Je pense que toutes les autres architectures 64 bits avaient cela depuis longtemps, aussi cela n’est pas très choquant, mais c’est, quelque part, assez fondamental sur une des architectures principales pour être mentionné.>> Linus ## Version finale La version finale est sortie le [8 juin 2014](https://lkml.org/lkml/2014/6/8/70).> Je me suis donc résigné à faire une RC-8, parce que j’étais un peu inquiet des corrections de dernière minute sur `dcache`, mais il s’est avéré que personne ne semble avoir remarqué quoi que ce soit. Malgré tout, nous avons eu d’autres problèmes pendant la semaine, aussi cela n’était pas plus mal. Les corrections de verrous [_futex_](http://fr.wikipedia.org/wiki/Futex "Fast Userspace Mutex") et les nettoyages se démarquent, mais comme d’habitude il y a diverses autres corrections un peu partout réalisées depuis la RC-8, principalement les pilotes (DRM, réseau, son, USB, etc.), le réseau, l’ordonnanceur et les outils de mesure de performance.>> Mais cela a été dans l’ensemble raisonnablement petit et calme, ce qui _doit_ être, bien entendu, dû au fait que la semaine dernière était également la première semaine de la période de fusion pour la 3.16. Cela a pu distraire certains développeurs. Je ne suis pas complètement convaincu d’avoir apprécié le chevauchement, mais il semblerait que cela ait fonctionné correctement. Et, à moins que les gens crient très fort (« S’il te plaît ne refais plus _jamais_ cela ! ») et qu’ils donnent de bonnes raisons pour cela, je pourrais refaire un chevauchement des fenêtres de fusion dans le futur, si cela peut aider pour certains problèmes de délai.>> Ceci dit, je ne pense pas que cela ait été une expérience grandiose au point que je refasse un chevauchement à chaque fois, sans une bonne raison spécifique pour cela. C’était assez agréable d’être productif la dernière semaine de la RC (qui est généralement plutôt ennuyeuse et morte), mais je pense que cela pourrait représenter une distraction quand les gens devraient s’inquiéter de la stabilité de la RC.>> Bien sûr, il se pourrait que le chevauchement aboutisse à moins de bruit pendant la dernière semaine de stabilisation, et que cela aide réellement. Cela pourrait aussi produire l’inverse. Je serais intéressé d’entendre l’avis des autres personnes, mais je soupçonne que la plupart n’ont aucune opinion particulière sur le sujet.>> Quoiqu’il en soit, avec la version 3.15 publiée, ma branche « _master_ » a déjà été fusionnée avec ma branche « _next_ » sur ma machine locale, et je vais démonter la branche « _next_ » une fois que j’aurai dégagé tout ça. Après cela, les futures fenêtre de fusion se feront sur la branche « _master_ » et nous reviendrons au modèle normal de branche unique pour mon arbre.>> Linus # Les nouveautés ## Architecture ### Gestion du mode mixte EFI Certaines machines ont un micrologiciel EFI 32 bits, les noyaux 64 bits ne pouvaient du coup pas démarrer simplement dessus. Le mode mixte EFI ([_EFI mixed mode_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7cc3afdf43ffb703db831292f3816d909fd44767)) ajouté à cette version 3.15, permet maintenant d’y remédier. Un exemple concret est la possibilité pour l’ASUS _Transformer Book T100TA_ de démarrer sur un tel micrologiciel. Le mode mixte EFI est un mode qui permet aux micrologiciels EFI 32 bits de démarrer sur des noyaux 64 bits, à condition que le chargeur de démarrage gère le protocole [_EFI handover_](http://www.phoronix.com/scan.php?page=news_item&px=MTE0NzU). La plupart des chargeurs de démarrage populaires comme GRUB, SYSLINUX ou EFILINUX le gèrent, il sera donc possible de disposer de cette fonctionnalité très simplement à condition d’activer l’option `CONFIG_EFI_MIXED` depuis les options de configuration du noyau Linux. ### AVX-512 Les premiers processeurs proposant le jeu d’instructions AVX-512 ne seront commercialisés qu’en 2015, avec la génération _Knights Landing_ des processeurs Intel. Toutefois, leur prise en charge est déjà [disponible](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=918d80a136430aeb23659aa75f8b415090500667) dans cette version 3.15. AVX-512 (_Advanced Vector Extensions_), extension directe de AVX-256, est un jeu d’instructions SIMD (_Single Instruction Multiple Data_). Il s’agit d’un jeu d’instructions qui permet d’appliquer une même opération arithmétique sur plusieurs données en parallèle. Par opposition aux instructions habituelles de type SISD, pour _Single Instruction Single Data_, SIMD permet d’appliquer une même opération d’addition, de multiplication sur plusieurs éléments d’une structure très régulière, comme c’est par exemple le cas sur des tableaux ou des matrices. AVX-512 permet, entre autres, d’agrandir la taille des registres AVX à 512 bits, ou encore va donner la possibilité aux compilateurs de vectoriser plus de boucles efficacement, grâce aux instructions _Conflict Detection Instructions_ (CDI) qui, comme leur nom l’indique, permettent la détection des conflits. ### Améliorations de l’ordonnanceur L’ordonnanceur subit un travail de préparation qui vise à permettre une meilleure intégration avec le choix des états de veille du processeur, pour économiser l’énergie. Cela ne sera disponible que dans de futures versions du noyau [[_commit_ de fusion](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=971eae7c99212dd67b425a603f1fe3b763359907)]. Il y a aussi eu plusieurs améliorations liées à l’usage des _cgroups_, notamment lors du changement de contexte entre deux processus d’un même _cgroup_ [[_1_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=678d5718d8d099421b0dd54c01b0528f4aaf5919), [_2_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=606dba2e289446600a0b68422ed2019af5355c12), [_3_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fed14d45f945042a15b09de48d7d3d58d9455fc4)]. ### Abandon des anciennes plates-formes x86 Je vais faire pleurer ceux d’entre vous qui ont des enfants qui jouaient à [Jill](http://linuxfr.org/news/openjill-une-reecriture-du-moteur-de-la-trilogie-jill), Linux 3.15 [ne gère plus](http://lkml.iu.edu/hypermail/linux/kernel/1404.0/00690.html) ces systèmes ~~excitants~~ introuvables que sont les SGI Visual Workstations, Sequent Computer Systems NUMAQ, IBM Summit/EXA et autres Unisys ES7000. ### Instruction RDSEED À partir du noyau 3.15, `/dev/random` utilisera les nouvelles instructions RDSEED des futures générations _Broadwell_ de chez Intel [[_demande d’intégration_](http://lkml.iu.edu/hypermail/linux/kernel/1404.0/02103.html)]. À partir de cette génération, les processeurs Intel proposent une nouvelle instruction RDSEED. Il s’agit d’une instruction de génération de bits aléatoires. Comparée à son homologue RDRAND, qui fut introduite avec la génération _Ivy bridge_, elle est destinée à être utilisée par les logiciels qui disposent déjà d’un générateur de nombres pseudo-aléatoires (PRNG), en tant que « graine » (_seed_), c’est-à-dire une source d’entropie de nombres aléatoires. RDRAND, quant à elle, est une instruction de génération de nombres pseudo-aléatoires. ### Systèmes mono-puces ARM La plate-forme ARM est toujours très active, au point que les développeurs songent à [mettre l’arborescence des périphériques](http://lkml.iu.edu/hypermail/linux/kernel/1404.0/02827.html) dans un arbre _Git_ dédié. Parmi les nouveautés, on peut noter : - l’ajout de la carte de développement A10-OLinuXino-LIME ; - l’ajout du Freescale l’_i.MX35_ ; - l’ajout des dérivés Freescale _i.MX51_ , _i.MX25_ et _i.MX35_ de chez [Eukréa](http://www.eukrea.com/fr/societe/apropos) ; - un ensemble d’améliorations au niveau des systèmes mono-puces _i.MX_ de chez Freescale ; - pas mal d’améliorations au niveau des systèmes mono-puces de chez ATMEL. ### ACPI Avant Linux 3.15, l’événement envoyé lors de l’appui sur une touche « augmenter la luminosité » ou « baisser la luminosité » pouvait signifier deux choses pour un environnement de bureau : 1. notification comme quoi la luminosité a été modifiée ; 2. touche de modification de luminosité pressée, « débrouille-toi ». La plupart des environnements de bureau interprètent cet événement comme le cas numéro 2, ce qui causait des problèmes : changement de luminosité effectué deux fois — une fois par le noyau, une fois par l’environnement de bureau — ou [changement de luminosité non détecté, et donc notification non affichée](https://bugs.kde.org/show_bug.cgi?id=323516), etc. En effet, le scénario numéro 1 est très difficile à détecter en espace utilisateur. Désormais, la grosse majorité des ordinateurs portables seront dans le cas numéro deux, ce qui rend la gestion de la luminosité plus simple et plus cohérente et résout les cas cités ci-dessus [[_commit_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=886129a8eebebec260165741fe31421482371006)]. ### Changement de la taille de la pile du noyau La pile du noyau pour l’architecture x86_64 voit sa taille passer de 8 Kio à 16 Kio. Ce changement a été effectué par Minchan Kim [[_commit_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6538b8ea886e472f4431db8ca1d60478f838d14b)]. ## Pilotes graphiques libres ### DRM (Direct Rendering Manager) Le code commun aux pilotes graphiques libres (DRM) a reçu plus d’attention que d’habitude pour cette nouvelle version, notamment afin de préparer la venue de nouvelles fonctionnalités dans les versions futures. Il n’y a donc rien de visible pour le moment pour l’utilisateur final. Le premier gros changement est la gestion universelle des plans d’affichage (_display planes_). Jusqu’à présent, le DRM n’exposait que les plans de type [_sprites_](http://fr.wikipedia.org/wiki/Sprite_%28jeu_vid%C3%A9o%29) et superposition (_overlay_) vidéo. Les plans pour curseurs étaient, eux, exposés via des appels `ioctl()` dédiés, alors que les plans primaires n’ont jamais été exposés. Désormais, tout client exposant la capacité `DRM_CLIENT_CAP_UNIVERSAL_PLANES` pourra accéder à l’interface de plans universelle (_universal plane_) et à la liste complète des plans proposés par le matériel. Ce client pourra dès maintenant changer des paramètres tels que la mise à l’échelle (_scaling_) ou désactiver l’affichage, sans avoir à effectuer de changement de mode graphique au niveau du contrôleur vidéo (CRTC). Cependant, l’intérêt de cette nouvelle interface ne sera clair que lorsque le travail de changement atomique du mode graphique et du commutation de pages (_page flip_) du noyau sera terminé. En attendant, si vous voulez plus d’information, vous pouvez consulter [_ce message_](http://lists.freedesktop.org/archives/dri-devel/2014-March/055222.html) ou l’[article récapitulatif de la gestion du mode graphique](http://ppaalanen.blogspot.fr/2014/06/from-pre-history-to-beyond-global.html) de Pekka Paalanen (développeur Wayland). Le deuxième changement important est la mise en commun du code gérant le canal auxiliaire de communication du _DisplayPort_ (DP). Cela va permettre la gestion du _Multi-Stream Transport_ (MST) proposé par le _DisplayPort_, qui permet de multiplexer plusieurs liaisons vidéo à travers le même câble DP. Voici la [demande d’intégration](http://lists.freedesktop.org/archives/dri-devel/2014-February/054635.html) de cette nouvelle infrastructure. La gestion du MST devrait, quant à elle, [arriver dans Linux 3.16 ou 3.17](http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-i915-mst-support). La gestion des nœuds [maîtres](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm?id=c996fd0b956450563454e7ccc97a82ca31f9d043), [mineurs](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm?id=e40d641099213145a034981e646dc2180a488152) et de [contrôles](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm?id=ac05dbc57ef2b8709bf48693bb25e16a63e8e71f) a été revue dans cette version, notamment sur la gestion des verrous. En parlant de verrous, les symboles DRM vérifient maintenant activement que les bons verrous ont été pris avant l’appel, au lieu de simplement le [marquer dans la documentation](http://lists.freedesktop.org/archives/dri-devel/2014-January/052563.html). Mais le changement le plus important vient mettre fin à une bidouille pour l’allocation d’un espace d’adressage pour le périphérique. En effet, il est impossible d’allouer un espace d’adressage sans avoir de nœud d’index (inode) disponible. Du coup, DRM attendait que le premier client ouvre un nœud vers un processeur graphique avant d’allouer l’espace d’adressage. Cette technique était clairement une bidouille, et Al Viro (mainteneur VFS) a conseillé d’utiliser une autre méthode qui [a été appliquée](http://lists.freedesktop.org/archives/dri-devel/2014-January/052563.html). Pour finir, la documentation DRM a été [corrigée et nettoyée](http://lists.freedesktop.org/archives/dri-devel/2014-March/055546.html). ### Adreno (pilote msm) Dans cette nouvelle version, le pilote _msm_ gagne la possibilité de diffuser du son via la prise HDMI [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/msm?id=c0c0d9eeeb8df43964601a2c4666f0c49bedacb4)] et devient plus économe en énergie en activant le [_clock gating_](http://fr.wikipedia.org/wiki/Clock_gating) après 66 ms d’inactivité [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/msm?id=37d77c3ab589bf8e3160a33b651fe6dd7439ba48)]. Après un [article de LWN](https://lwn.net/Articles/588444/) sur comment gérer proprement des drapeaux inconnus dans les `ioctl()` ou les appels systèmes, Rob Clark a vérifié à nouveau son code et trouvé quelques problèmes qu’il a corrigés [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/msm?id=93ddb0d3b022dfbd963f243bd01741643cebfb28)]. Ces modifications cassent la compatibilité binaire, mais Rob se justifie en disant qu’il n’y a presque aucun pilote en espace utilisateur et que, si une application venait à être cassée par ce changement, il reviendrait partiellement sur son correctif. Le pilote _msm_ utilise maintenant les plans d’affichage universels qui viennent juste d’être introduits, au lieu de l’ancienne interface de programmation [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/msm?id=2d82d188b2cb11b6b221eb84dda2344ef3cd1bb4)]. Pour finir, une option noyau a été ajoutée afin d’afficher l’état des registres lorsque le processeur graphique se bloque [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/msm?id=5b6ef08e4b4e1bcb6b3ac4172c054e4462e2c767)]. Cela devrait aider pour l’écriture de rapports de bogues. Pour information, le pilote _freedreno_ (accélération 3D pour Adreno) utilisant le pilote _msm_ [vient de recevoir la prise en charge d’OpenGL 2.1](http://www.phoronix.com/scan.php?page=news_item&px=MTY5MjM). Celui-ci prenait en charge OpenGLES 2.0 depuis quelque temps, mais ne gérait pas quelques extensions nécessaires pour la version « bureau » d’OpenGL. Ce code devrait être disponible dans Mesa 3D 10.3 qui sortira en août. ### AMD/ATI (pilote radeon) La principale nouveauté concernant le pilote _radeon_ est la prise en charge de l’encodeur vidéo matériel VCE afin d’accélérer la conversion de vidéos au format H.264. Ce noyau permet l’utilisation de cet encodeur à travers le standard OpenMAX, du groupe Khronos. Ce n’est pour l’instant possible qu’avec la version VCE 2.0 du matériel, la prochaine version de Mesa 3D (10.3) [[_correctif_](http://cgit.freedesktop.org/mesa/mesa/commit/?id=f588b80bbaa6aa69416f34a54364cc08c9f0636a&utm_source=anzwix)] et le greffon GStreamer [_gst-omx_](http://gstreamer.freedesktop.org/releases/gst-omx/1.0.0.html). Cette nouvelle version apporte également la prise en charge complète d’un petit dernier dans la famille des processeurs [APU](http://fr.wikipedia.org/wiki/Accelerated_Processing_Unit) _Kaveri_, le _Mullins_, qui est sorti le 29 avril 2014. Pour finir, _radeon_ a laissé tomber sa gestion spécifique du canal de communication auxiliaire du DisplayPort, afin d’utiliser la nouvelle version proposée par DRM [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/radeon?id=496263bf2bee13387f6e2a780f0c783c9c377c42)]. Beaucoup d’autres bogues ont également été corrigés, notamment dans la gestion des horloges. ### Samsung (pilote exynos) Un gros travail de réorganisation du code a été mené sur le pilote _exynos_, avec notamment le déplacement du pilote DisplayPort depuis `video/` vers `drm/`, afin de gérer correctement le branchement à chaud et le changement de mode graphique [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/exynos?id=2e4e678aa8a49136a4954dd93e53ac5108977e5c)]. Il est également à noter l’ajout de la gestion des ponts [LVDS](http://fr.wikipedia.org/wiki/LVDS "Low Voltage Differential Signaling"), ainsi que des écrans à interface parallèle (remplacée par l’interface [DSI](http://en.wikipedia.org/wiki/Display_Serial_Interface "Display Serial Interface")). Pour plus d’informations, vous pouvez consulter la [demande d’intégration _exynos_](http://www.spinics.net/lists/dri-devel/msg55848.html). ### Intel (pilote i915) Aucune nouvelle fonctionnalité activée par défaut pour le pilote _i915_ dans cette version, mais un énorme travail de fond a été effectué. La gestion des [_Per-Process Graphics Translation Tables_](http://www.phoronix.com/scan.php?page=news_item&px=MTUzNzQ) (PPGTT, tables de traduction graphique par processus) fait son apparition, mais est désactivée par défaut à cause de quelques bogues trouvés à la dernière minute. PPGTT est une fonctionnalité des processeurs graphiques inclus dans les processeurs Intel _Ivy Bridge_, _Haswell_, et _Broadwell_ qui permet l’isolation des tâches du processeur graphique, ce qui améliore la sécurité en fournissant un contexte et un espace d’adressage par descripteur de fichier et client de ressources graphiques. Pour en savoir plus sur GTT et GEM, un [cours d’introduction](https://bwidawsk.net/blog/index.php/2014/06/the-global-gtt-part-1/) a été écrit par Ben Widawsky, un ingénieur de chez Intel. Par le passé, la gestion du [_power gating_](https://en.wikipedia.org/wiki/Power_gating) et du [_clock gating_](https://fr.wikipedia.org/wiki/Clock_gating) par le matériel Intel a surtout été gérée automatiquement. Désormais, les nouvelles architectures requièrent l’intervention du pilote afin, notamment, de sauvegarder et restaurer le contexte. Donc, il est nécessaire de préparer une infrastructure permettant de représenter les domaines énergétiques, de suivre leur état et de gérer les changements d’état. Comme les domaines énergétiques sont très dépendants de l’architecture et sont amenés à évoluer dans le futur, une couche d’abstraction est proposée par l’infrastructure. Cette infrastructure devrait commencer à être utilisée dans Linux 3.16. Du côté de l’affichage, la gestion expérimentale du démarrage rapide et sans clignotement a été améliorée afin de pouvoir hériter du mode graphique qui a été mis en place au démarrage par le micrologiciel EFI. Encore un peu de travail est nécessaire pour rendre sa gestion parfaitement fiable, ce qui explique pourquoi l’option n’est pas activée par défaut bien que toute l’infrastructure soit maintenant en place. Si vous voulez l’essayer malgré tout, vous pouvez ajouter l’option `i915.fastboot=1` à votre ligne de commande noyau. Concernant l’affichage, la prise en charge des liens DisplayPort à 5,4 GHz, nécessaire pour piloter des écrans à ultra haute définition ([[4K]]), est disponible. Malheureusement, les écrans 4K actuels exposent généralement deux écrans, via le _Multi-Stream Transport_ (MST), afin de proposer la 4K. En parlant de MST, le pilote _i915_ utilise maintenant la gestion du canal auxiliaire du DisplayPort proposée par DRM, ceci afin de pouvoir plus tard gérer les écrans accessibles via MST. Enfin, la gestion des grands curseurs a été ajoutée afin de mieux gérer les curseurs sur les écrans à haute densité de pixels. La prise en charge des processeurs _Broadwell_ a reçu beaucoup de modifications, mais elle reste encore incomplète. D’autres devraient suivre dans Linux 3.16. Pour plus d’informations, vous pouvez consulter le [billet de blogue de Daniel Vetter dédié à Linux 3.15](http://blog.ffwll.ch/2014/04/neat-drmi915-stuff-for-315.html). ### NVIDIA (pilote nouveau) La nouveauté principale côté du pilote _nouveau_ est la gestion expérimentale de la nouvelle famille de cartes NVIDIA _Maxwell_, sortie le 18 février 2014. Cette gestion se limite actuellement au mode graphique [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=c68c29c04c4ff11e51d98b2225c1e3b37ed22996)] et à l’accélération 3D [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=6f1e9b99b329238e3a3989785cf0dff67db78b1a)] en utilisant le microcode de NVIDIA. Ce microcode sera remplacé dans le futur par une version entièrement libre, quand les fonctionnalités basiques s’exécuteront en espace utilisateur. En effet, cette nouvelle famille de cartes a introduit un nouveau jeu d’instructions qu’il a fallu étudier et intégrer à Mesa 3D [[_correctif_](http://cgit.freedesktop.org/mesa/mesa/commit/?id=d548d47edf9f05e6dbf9656abc2f8e78d02cb2f6)]. Il manque cependant les modifications nécessaires au pilote X.Org _xf86-video-nouveau_ pour pouvoir utiliser l’accélération 2D et 3D sur processeur graphique _Maxwell_ avec un serveur X. Une première version d’un système de reprise sur panne a également été intégrée pour _Kepler_, afin de ne pas bloquer tout le système lorsque l’[[unité de gestion mémoire]] ne connaît pas la correspondance entre une adresse virtuelle et une adresse physique. Le pilote _nouveau_ devrait également mieux gérer les cas où le microcode de changement contexte se bloque. La gestion automatique de la ventilation s’améliore avec la correction de multiples bogues, et, surtout, l’ajout de la gestion de deux nouveaux types de ventilateurs couramment trouvés dans la famille _Kepler_. Si vous avez encore des problèmes de ventilateur dans cette version, vous êtes invités à [écrire un rapport de bogue](http://nouveau.freedesktop.org/wiki/Bugs/). De multiples bogues concernant la lecture du BIOS vidéo ont également été corrigés, en partie grâce à [l’aide de NVIDIA](http://permalink.gmane.org/gmane.comp.freedesktop.xorg.nouveau/16455). Parmi les modifications apportées dans Linux 3.15, [l’une d’elles se distingue](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=420b94697722512a2c0732970dc1530197a49adb) particulièrement, pour deux raisons : * elle prépare _nouveau_ afin de pouvoir gérer le processeur graphique ARM _Tegra K1_, qui n’est pas accessible via un bus PCI, AGP ou PCIe ; * elle est écrite par un nouvel employé de NVIDIA, Alexandre Courbot. Ce n’est pas la première fois que NVIDIA contribue à _nouveau_ puisque Aaron Plattner l’avait [déjà fait](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=ab9ccb96a6e6f95bcde6b8b2a524370efdbfdcd6) en février 2013, mais c’est cependant la première fois que la gestion d’un nouveau jeu de composants est écrite par un employé de NVIDIA, français, qui plus est. Alexandre Courbot est, en effet, actif sur l’IRC et les listes de diffusion de _nouveau_ et ajoute la gestion du _Tegra K1_ (nom de code _GK20A_) au noyau, tel que [nous le rapportions sur _LinuxFr.org_](http://linuxfr.org/news/nvidia-contribue-la-gestion-du-gpu-arm-tegra-k1-dans-nouveau) en février. La majorité des contributions sont encore à venir, notamment dans Linux 3.16. La gestion de l’accélération 3D en espace utilisateur n’a pour l’instant nécessité que [-8 / +21 changements](http://cgit.freedesktop.org/mesa/mesa/log/?qt=author&q=Alexandre+Courbot) ! Plus d’information dans un futur proche, mais, en attendant, voici une petite [démonstration de l’avancement](https://plus.google.com/102210158882002185456/posts/eEBoQWSqggc). ### Poulsbo (pilote gma500) Le pilote _gma500_ du tristement célèbre processeur graphique à basse consommation _Poulsbo_ évolue doucement, avec la prise en charge d’un nouveau type d’unité de gestion mémoire et de gestionnaire d’interruptions (SGX). ### Tegra (pilotes host1x et tegra) Les choses ont bien bougé du côté de _host1x_ qui reçoit une infrastructure pour l’allocation de contextes, la synchronisation des moteurs d’exécution et la gestion du moteur de rendu 2D. La gestion de la 3D est en cours d’écriture. Bien que ce travail ait été testé durant plusieurs semaines par de multiples contributeurs, les contrôles d’entrées-sorties introduits pour _tegra_ sont actuellement considérés comme *staging* (branche _git_ dédié à la mise en œuvre) de façon à permettre un changement plus tard, si l’interface venait à ne pas être adaptée. La gestion de la 2D et de la 3D a été testée avec le [pilote _grate_](https://github.com/grate-driver). Pour rappel, [_host1x_](http://http.download.nvidia.com/tegra-public-appnotes/host1x.html) est la partie des processeurs _Tegra_ qui gère les transferts DMA, ainsi que l’affichage et l’envoi asynchrone de commandes au processeur graphique et autres systèmes multimédias. Le processeur graphique _Tegra_ est, lui, séparé, à la fois dans la puce et dans le code, et se charge de l’accélération 2D et 3D. Pour plus d’informations, vous pouvez consulter la [demande d’intégration `tegra/host1x`](http://lists.freedesktop.org/archives/dri-devel/2013-April/037556.html). ### VMware (pilote vmwgfx) Le pilote _vmwgfx_, pour l’accélération graphique dans les machines virtuelles VMware tournant sous Linux, a revu sa politique de sécurité afin de pouvoir gérer les nœuds de rendu ([render nodes](https://linuxfr.org/news/sortie-de-linux-3-12#render-nodes)). ## Réseau ### À la recherche des performances La recherche de gain en performance est une tâche courante dans le noyau Linux, et la partie réseau n’est pas en reste pour cette nouvelle version. Petit tour de ces nouveautés. #### Une horloge plus fine Dans les arcanes du très populaire TCP, l’estimation du [RTT](http://fr.wikipedia.org/wiki/Round-trip_delay_time) est importante pour certains algorithmes de gestion de la congestion. L’unité de cette estimation était la milliseconde, avec une bidouille immonde pour les cas inférieurs à cette valeur. Concrètement, cette bidouille dépendait de la fréquence de réveil de votre noyau (déterminée à la compilation). Cette fréquence étant à 1 000 Hz par défaut sur les architectures x86, l’estimation la plus fine utilisait des pas de 125 μs. Sur des réseaux modernes très performants, ces 125 μs sont beaucoup trop imprécises. Le [nouveau noyau compte donc désormais en microsecondes](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=740b0f1841f6e39085b711d41db9ffb07198682b), mais reste compatible avec les anciens outils de l’espace utilisateur en exportant toujours les données en millisecondes. Une mise à jour de la commande ``ip`` sera nécessaire pour voir les changements. #### Réécriture de l’interpréteur interne [BPF](http://fr.wikipedia.org/wiki/BSD_Packet_Filter) Que ne serait pas un nouveau noyau sans travail du côté du filtrage de paquets ? [Le cœur de l’interpréteur a été réécrit](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bd4cf0ed331a275e9bf5a49e6d0fd55dffc551b8) dans cette version, avec pour objectif une amélioration des performances. Le correctif est accompagné de tests de performance prometteurs, et d’une promesse de faire encore mieux bientôt en adaptant le compilateur à la volée (_Just In Time_) de BPF. #### Mettre à jour la somme de contrôle tout simplement Pour limiter l’utilisation du processeur sur des réseaux à très forte capacité, un mécanisme courant est de déléguer une grande partie du travail à la carte réseau. L’idée est de faire « comme si » on envoyait et recevait des très gros paquets du côté noyau, pendant que la carte réseau se charge de découper/rassembler les paquets réels, bien plus petits. Pour en savoir plus, vous pouvez consulter un très bon [article sur _LWN_](http://lwn.net/Articles/358910/). C’est en utilisant ce mécanisme qu’un développeur de Google a détecté une forte utilisation du processeur pour le calcul de la somme de contrôle de ses paquets, avec près d’un pour cent du processeur dédié à cette simple tâche. Cette somme de contrôle a de bonnes propriétés mathématiques, elle est notamment incrémentale : quand on modifie un champ d’un paquet, on n’est pas obligé de tout recalculer, il suffit de calculer la différence induite par la partie réécrite. L’analyse détaillée a donc conduit à identifier le coupable : la fonction ``csum_replace2()``. Cette fonction prend une somme de contrôle, deux mots de 16 bits (l’ancien champ et le nouveau champ réécrit du paquet), et retourne la nouvelle somme de contrôle. Cette fonction ne faisait pas réellement le travail, en délégant la tâche à la fonction ``csum_replace4()``, prenant comme arguments des mots de 32 bits. Qui peut le plus peut le moins, mais le fait moins vite. ``csum_replace4()`` appelle, elle-même, une fonction générique encore plus complexe. Cette mise à jour de la somme de contrôle est pourtant une tâche simple pour des mots de 16 bits, bien documentée depuis longtemps dans la [RFC 1624](http://tools.ietf.org/html/rfc1624). Davil Miller a signalé cette référence, et [Éric Dumazet de chez Google a donc modifié la fonction](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=99f0b958b194f7d88973f1c2190d207e0a2c7e79) pour utiliser cette méthode simple et rapide. Comme cette fonction est utilisée à d’autres endroits de la partie réseau, d’autres cas d’utilisation devraient profiter de ce gain. #### Protection contre les dénis de service Les dénis de service, consistant à surcharger un serveur par un nombre impressionnant de connexions, sont très courants sur Internet. Parmi ceux-ci, un grand classique est le bon vieux [_SYN flood_](http://fr.wikipedia.org/wiki/SYN_flood). Sur un [pare-feu à états](http://fr.wikipedia.org/wiki/Pare-feu_%C3%A0_%C3%A9tats), chaque paquet ajoutera une connexion à suivre, et il faut être capable de les gérer. Chez Linux, ce suivi est effectué par la table ``conntrack``. Cette table était protégée par un verrou central pour les insertions et les suppressions. Et ce verrou devenait avec le temps un énorme frein (un peu comme le [_Big Kernel Lock_](http://fr.wikipedia.org/wiki/Verrou_global_du_noyau), à échelle très réduite). Le nouveau noyau introduit donc un [verrouillage plus fin](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=93bb0ceb75be2fdfa9fc0dd1fb522d9ada515d9c), avec 1 024 verrous et une table de hachage pour savoir quel verrou utiliser. L’amélioration de performance est spectaculaire, si vous avez le matériel qui va avec. Avec un [bon processeur](http://ark.intel.com/products/75281/Intel-Xeon-Processor-E5-2695-v2-30M-Cache-2_40-GHz) et un réseau à 10 Gbit/s, le testeur est passé d’une gestion de 810 405 connexions par seconde à 2 233 876, soit une amélioration d’un facteur de presque trois. ### Sécurité réseau #### cgroups et réseau C’est une [modification triviale](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a00e76349f3564bb8129fc0510dfd93248c3084d), mais il est désormais possible d’attacher une règle ``iptables`` à un _cgroup_ pour du trafic entrant. Cela permet notamment de compter le trafic entrant d’une application. Toujours du côté des _cgroups_, une refonte assez importante a supprimé la possibilité de compiler le contrôleur _cgroup_ ``net_prio`` en tant que module. C’était le seul qui utilisait cette possibilité. #### IPsec Dans un paquet IPsec, il est possible d’ajouter un compteur de paquets pour se protéger des attaques par rejeu (en refusant des paquets dont le compteur est inférieur aux valeurs déjà reçues). Ce compteur est historiquement de 32 bits, ce qui permet d’envoyer un certain nombre de paquets. Ce nombre est cependant insuffisant pour les réseaux modernes, et une extension existe dans le standard depuis 2005 pour utiliser un compteur à 64 bits. Linux permettait de le faire pour le protocole ESP d’IPsec (intégrité et authentification) et, à partir de cette version, [l’autorise également pour le protocole AH](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d4d573d0334d07341beffdcf97e2b85d3955d8ae) (intégrité et confidentialité). Depuis sa version 3.6, le noyau permet de gérer le routage à travers un tunnel, avec les ``vti`` (_Virtual Tunnel Interface_, nom venant de Cisco), pour gérer plus facilement et plus dynamiquement le routage à travers un tunnel IPsec. Ces VTI sont uniquement une abstraction des règles IPsec existantes dans le noyau. Pour ces VTI, ce noyau ajoute la [possibilité de configurer](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d4d573d0334d07341beffdcf97e2b85d3955d8ae) un [espace de noms](http://lwn.net/Articles/531114/) et de faire passer de l’IPv6 dans un tunnel IPv4. #### Bluetooth Ce noyau introduit la [gestion du niveau 4](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7b5a9241b780ea2f77e71647bc0d3c9708c18ef1) (le plus élevé) de la sécurité en Bluetooth. Concrètement, ce mode de sécurité force l’utilisation de clefs de chiffrement plus fortes, mais ne sera compatible qu’avec les équipements utilisant la norme Bluetooth 4.1. Il n’y a pas de compatibilité pour ce mode avec le matériel plus ancien. #### Commentons avec nftables Avec le pare-feu de nouvelle génération _nftables_, [on peut désormais ajouter des commentaires arbitraires](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0768b3b3d228c5acf2075f40f3d25cda30011d4f) associés à une règle. Cela permettra à l’administrateur pressé de répondre à la question « Mais, pourquoi ai-je bien pu ouvrir le port 22 ? ». ## Sécurité ### Audit La valeur de `proc//cmdline` (nommée `proctitle`) fait maintenant partie des informations remontées par le sous-système d’audit [[_correctif_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3f1c82502c299da08b7b7f08b435212e51166ed9)]. Cette chaîne de caractères peut être changée par le processus avec la fonction `setproctitle()`, et ne peut donc pas être considérée comme « de confiance » d’un point de vue sécurité. En revanche, elle sera particulièrement utile pour le débogage sur Android notamment, car les applications ne sont pas lancées à l’aide d’un classique `fork()` + `exec()`. En effet, pour accélérer le lancement, les applications Java utilisent une instance (processus) préparée à l’avance par la machine virtuelle Java _Dalvik_ et la spécialisent en chargeant les classes de l’application. Ceci évite notamment d’avoir à charger systématiquement les classes des paquets de base pour chaque nouvelle application lancée, et permet donc de profiter de la propriété de copie sur écriture ([_Copy-On-Write_](http://fr.wikipedia.org/wiki/Copy-On-Write)) de l’appel système `fork()`. Lorsque la machine virtuelle Java (JVM) lance une application, elle change la valeur de `proctitle` pour la faire correspondre à son nom et cela apparaîtra désormais dans les journaux d’audit. La prise en charge de l’audit des appels système a aussi été étendue pour gérer les appels 32 bits sur une architecture 64 bits [[_correctif_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4b58841149dcaa500ceba1d5378ae70622fe4899)]. ### Gestion de l’Intel Trusted Execution Environment Une série de correctifs [[_1_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3da72212725e1970e7969acc52bc5d3d7c16c3cf), [_2_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=266f6178d1f1b268a1ddba4d89a8105df6819f4d), [_3_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32e2b59fca2c422f6911c700cd4cf0809f7b2019), [_4_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=795536acd80bc80f41f794eb16070ac361368840) et [_5_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=92ab513072e73d74fee78062c9935f119339e4de)] ajoute la gestion du périphérique _Intel Trusted Execution Environment_ à l’[_Intel Management Engine Interface_](https://software.intel.com/en-us/blogs/2011/12/14/intelr-amt-and-the-intelr-me) (IMEI). L’IMEI est une interface [IPMI](http://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface "Intelligent Platform Management Interface") faisant partie de l’[_Intel Active Management Technology_](http://en.wikipedia.org/wiki/Intel_Active_Management_Technology) qui est présente dans les processeurs avec la technologie [Intel _vPro_](https://software.intel.com/en-us/blogs/2011/10/24/the-keys-to-intel-vpro-technology-heci-mei-lms-sol-uns?language=ru&wapkw=intel+management+engine+interface+%28intel+mei%29). Elle permet de gérer un système en discutant directement avec une puce dédiée, sans passer par le système d’exploitation ([_out‐of‐band management_](http://en.wikipedia.org/wiki/Out-of-band_management)). ### LSM Diverses corrections de bogues et améliorations mineures sont listées dans le [message de demande d’intégration des correctifs](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bea803183e12a1c78a12ec70907174d13d958333). #### SELinux La mise en correspondance de zones mémoire proches de l’adresse 0 peut poser des problèmes de sécurité ([cela simplifie principalement l’écriture d’exploitations de failles du noyau](https://blogs.oracle.com/ksplice/entry/much_ado_about_null_exploiting1)). Ainsi, une limitation arbitraire avait été ajoutée (`vm.mmap_min_addr`, configurable à l’aide de `sysctl`) pour réduire ce risque. Les processus souhaitant mettre en correspondance une zone mémoire inférieure à `mmap_min_addr` doivent disposer de la « capacité » (_capability_) `CAP_SYS_RAWIO`. Pour le noyau 2.6.30, Eric Paris avait choisi de placer la vérification effectuée par SELinux (MAC) avant la vérification classique de « capacité » (DAC) [[_correctif_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8cf948e744e0218af604c32edecde10006dc8e9e)]. Ce comportement était un cas exceptionnel, car les vérifications effectuées au niveau des appels système suivent toutes l’ordre DAC puis MAC (_cf._ un [exemple complet pour le contrôle d’accès à un fichier](http://unix.stackexchange.com/questions/16828/what-roles-do-dac-file-permissions-acl-and-mac-selinux-play-in-linux-file-s/)). Cette inversion a eu pour principale conséquence la mise en avant d’un cas d’erreur courant et géré sans aucun problème par les programmes (notamment [_Wine_](http://www.winehq.org/) et [[QEMU]]) dans la majeure partie des cas. En effet, lorsque qu’un programme essayait d’effectuer un `mmap()` au‐dessous de `mmap_min_addr`, il se voyait refuser l’accès par SELinux en premier, ce qui générait un `AVC` qui était affiché à l’utilisateur (par `setroobleshoot`) avec un message du type :> SELinux is preventing /usr/bin/wine-preloader from 'mmap\_zero' accesses on the memprotect. L’utilisateur croyait alors à tort qu’il y avait un problème de sécurité. Si l’application échouait, ce n’était pas non plus nécessairement la faute de SELinux. Et, si c’était effectivement le cas, il fallait non seulement autoriser ce programme dans la politique SELinux, mais également lui donner la capacité `CAP_SYS_RAWIO` pour qu’il puisse fonctionner. Ayant causé plus de soucis que de bénéfices potentiels (détection de programmes malveillants), cette inversion MAC/DAC a été corrigée (_cf._ l’[article de Daniel Walsh](http://danwalsh.livejournal.com/69035.html) sur le sujet) [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/security?id=98883bfd9d603a2760f6d53eccfaa3ae2c053e72)]. Un autre bogue a été corrigé : des nœuds d’index (_inodes_) dans `/proc` pouvaient être laissés avec une étiquette de sécurité (_label_) attribuée par défaut au lieu de celle indiquée dans la politique de sécurité. Cela se produisait si un programme y accédait avant que la politique ne soit chargée [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/security?id=f64410ec665479d7b4b77b7519e814253ed0f686)]. ## Systèmes de fichiers ### Code commun #### VFS L’appel système `renameat2` a été ajouté afin de permettre d’échanger les noms de deux fichiers de façon atomique. Avec cet appel système, il devient donc possible de remplacer un dossier par un lien symbolique sans risque qu’une opération arrive durant l’opération et ne réussisse pas ! Vous pouvez consulter l’[article de _LWN_](http://lwn.net/Articles/569134/) sur le sujet, ainsi que la [page de manuel](http://man7.org/linux/man-pages/man2/renameat.2.html) de l’appel système, afin d’obtenir plus d’informations. Une autre modification importante est l’ajout de nouveaux verrous équivalents aux verrous POSIX, mais associés aux fichiers et non plus aux processus. La différence semble être peu importante, mais elle permet de rendre ces verrous utiles pour la synchronisation de plusieurs fils d’exécution à l’intérieur d’un même processus. Avec les verrous POSIX classiques (qui n’ont pas été remplacés), si deux [fils d’exécution](http://fr.wikipedia.org/wiki/Thread_%28informatique%29) (_threads_) d’un même processus ouvraient le même fichier, un verrou posé en écriture par un fil serait remplacé par un autre verrou en écriture posé par l’autre fil. De plus, si le fichier est ouvert plusieurs fois (utile pour paralléliser la lecture de données dans plusieurs fils) les verrous posés par un fil sur un fichier sont enlevés lorsqu’un autre fil ferme son descripteur de fichier. Il est très difficile de se prémunir contre ça sans rajouter beaucoup de verrous internes à l’application et s’assurer que les chemins des fichiers sont uniques (pas de lien dur ou symbolique). Cependant, si les verrous sur un fichier ne sont plus associés à l’identifiant du processus (PID) mais sont associés aux descripteurs de fichier, le noyau ne fera plus de distinction entre deux tentatives de verrouillage venant de deux fils d’exécution d’un même processus ou de deux processus séparés ! Pour plus d’information, vous pouvez lire l’[article dédié sur _LWN_](http://lwn.net/Articles/586904/). #### SATA La vitesse de sortie de veille a été augmentée en autorisant le contrôleur de disque SATA à se réinitialiser en tâche de fond pendant que le reste du noyau se réveille puis rend la main à l’espace utilisateur. Ce n’est pas un problème, car même si une application utilisateur ou le noyau essaient de relire un fichier pendant que le contrôleur SATA se réveille, le processus ou le module sera bloqué et la requête mise en file d’attente en attendant que le contrôleur ait fini son travail. Le résultat est un temps de réveil de [7 à 12 fois plus rapide](https://01.org/suspendresume/blogs/tebrandt/2013/hard-disk-resume-optimization-simpler-approach) sur les machines de son développeur et une faible complexité du code ([_1_](https://github.com/01org/suspendresume/blob/master/dev/hard-disk-resume/ata_port_resume_async.patch) et [_2_](https://github.com/01org/suspendresume/blob/master/dev/hard-disk-resume/sd_resume_async.patch)). Plus d’informations [sont disponibles sur _LWN_](http://lwn.net/Articles/594864/). ### Ext3/4 Le système de fichiers par défaut de nombreuses distributions [se stabilise encore et toujours](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=24e7ea3bea94fe05eae5019f5f12bcdc98fc5157), mais peu de nouveautés à se mettre sous la dent. ### XFS Idem du côté de XFS, la période est relativement calme. À noter que le sous‐système XFS n’est plus maintenu par SGI mais désormais par [Dave Chinner](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=645ceee885facc6de60051be150ca1b06bdb9e51) (Red Hat). Celui‐ci remercie au passage grandement SGI pour le boulot réalisé depuis les débuts de XFS. Les modifications les plus significatives concernent la gestion de `O_TMPFILE`, ainsi que l’option de l’appel système [`fallocate`](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d15e03104eb9a4f8e244ab6ed3ca5a107e46db13) (`COLLAPSE_RANGE` et `ZERO_RANGE`). ### Btrfs Suite à l’embauche de Chris Mason chez *Facebook*, puis au déploiement sur une ferme de serveurs de test de Btrfs, ce système de fichiers a le vent en poupe. [Btrfs se voit amélioré considérablement](https://lkml.org/lkml/2014/4/1/460), avec une bonne salve de corrections et d’améliorations de performance qui ne semblent cependant pas visibles dans les [tests de Phoronix](http://www.phoronix.com/scan.php?page=article&item=linux_315_hddfs&num=1). Le temps semble être à la stabilisation de Btrfs. ### F2FS Ce système de fichiers qui s’entend bien avec les mémoires Flash ([_Flash‐Friendly File System_](http://fr.wikipedia.org/wiki/F2FS)) [se voit doté](http://lkml.iu.edu/hypermail/linux/kernel/1404.0/03080.html) d’une amélioration des performances sous certaines charges de serveur, ainsi que d’une gestion des dossiers de taille importante. ### kernfs Le pseudo‐système de fichiers _kernfs_ a été tout juste introduit dans la version 3.14. Il reprend la logique de _sysfs_ pour la rendre plus utile aux différents sous‐systèmes ayant besoin d’un système de fichiers virtuel. Il continue d’être amélioré, en particulier par Tejun Heo, auteur de la [majorité des correctifs](http://lkml.iu.edu/hypermail/linux/kernel/1404.0/00679.html). ### ZRAM Ajout de la gestion de l’algorithme de compression [LZ4](http://linuxfr.org/news/linux-pour-workgroups-3-11-le-noyau-pret-pour-le-bureau#compression-lz4-pour-le-noyau) pour [_zram_](http://linuxfr.org/news/le-noyau-linux-2636-est-disponible#bref19). _zram_ est un système de d’échange de mémoire (_swap_) compressé tournant en mémoire vive, afin d’améliorer les performances des machines qui en manquent. ### En vrac Par manque de temps, tous les changements n’ont pu être résumés. Voici quelques informations complémentaires : - [[Reiser4]] : [[_1_](http://www.phoronix.com/scan.php?page=news_item&px=MTY4MzA)], [[_2_](http://www.phoronix.com/scan.php?page=news_item&px=MTY4MzE)], [[_3_](http://www.phoronix.com/scan.php?page=news_item&px=MTY4Mzg)] ; - [[SquashFS]] : [[_1_](http://lkml.iu.edu/hypermail/linux/kernel/1405.1/04017.html)]. ##Virtualisation ###KVM Les nouveautés tirées de la [demande d'intégration](https://lkml.org/lkml/2014/3/31/42) : - pour les architectures ARM, il y a quelques corrections pour les caches ; - du côté du PowerPC, les invités peuvent profiter de la mémoire transactionnelle (disponible avec le [[POWER8]]) ; - MIPS profite de quelques corrections de bogue, mais d’autres devraient arriver avec la prochaine version, car QEMU va avoir droit à KVM avec MIPS ; - pour les x86 : - des optimisations dans les registres de débogage utilisés par certains jeux pour Windows, - de manière générale, les invités Windows profitent de plusieurs corrections de bogues, - pour tous les invités, les instructions des processeurs Intel _Broadwell_ sont maintenant exposées, ainsi que les instructions MPX développées par Intel pour protéger les accès mémoire, - pour les invités OS X, il y a un contournement avec le minuteur de préemption pour la virtualisation imbriquée, et quelques modifications de l’horloge présentée par KVM ; - pour l’architecture s390 (les ordinateurs centraux d’IBM), les erreurs de page asynchrones sont implémentées, et des améliorations des interruptions font que les périphériques [_virtio_](http://fr.wikipedia.org/wiki/Virtio) sont plus rapides. ###Xen Aucune nouveauté du côté de Xen pour cette version. # Le bilan en chiffres Une fois n’est pas coutume, _LWN_ n’a pas encore publié son article sur les statistiques des contributions à cette nouvelle version de Linux. Nous avons profité de ce délai de leur part pour améliorer la qualité de cette dépêche, mais nous ne pouvons pas la retarder infiniment. Nous rajouterons cette partie dans un commentaire quand l’article de _LWN_ sera disponible. # Appel aux 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_ | [Julien Pecqueur](https://linuxfr.org/users/jpec), [Albert_](https://linuxfr.org/users/albert_) **Architecture** | [Romain Perier](https://linuxfr.org/users/rperier) | [Sébastien Chauvel](https://linuxfr.org/users/sinma) **Pilotes graphiques libres** | [Martin Peres](https://linuxfr.org/users/mupuf) | **Réseau** | [Florent F.](https://linuxfr.org/users/ffourcot) | **Systèmes de fichiers** | [_Jiehong_](https://linuxfr.org/users/jiehong) | [Martin Peres](https://linuxfr.org/users/mupuf) **Sécurité** | [Timothée Ravier](https://linuxfr.org/users/siosm) | **Virtualisation** | [Xavier Claude](https://linuxfr.org/users/claudex) | **Édition générale** | _aucun_ | [Martin Peres](https://linuxfr.org/users/mupuf), [Davy Defaud](https://linuxfr.org/users/davy78), [_rogo_](https://linuxfr.org/users/rogo) 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. Il n’y a 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. 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 correctifs 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 によって変換されたページ (->オリジナル) /