URL: https://linuxfr.org/news/sortie-du-noyau-linux-3-9 Title: Sortie du noyau Linux 3.9 Authors: antistress Davy Defaud, Batchyx, jcr83, Jiehong, Sidonie_Tardieu, yogitetradim, BAud, Anonyme, detail_pratique, Martin Peres, Mali, Maxime, Benoît Sibaud, claudex, Jarvis, alpentux, rootix, Nils Ratusznik, Strash, Tata Jeanette, patrick_g et Akiel Date: 2013年02月22日T16:18:22+01:00 License: CC By-SA Tags: linux, noyau_linux, coulisses, linus_torvalds et lwn Score: 67 La sortie de la version stable 3.9 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_](http://www.kernel.org/). Pour cette version, on voit surtout la poursuite de travaux de longue haleine (nettoyage/regroupement des architectures ARM, refonte de la gestion des modes d’affichage des puces graphiques Intel...), des traditionnelles corrections de bogues et optimisations (LZO, gestion de l’énergie...) même si quelques nouveautés se démarquent (gestion des ventilateurs de certaines puces graphiques NVIDIA, prise en charge des RAID 5 et 6 sous Btrfs, prise en charge de certaines architectures ARM par KVM, possibilité d’utiliser un SSD comme cache d’une autre unité de stockage...). À noter, une nouveauté déconnectée des notes de cette version mais apparue pendant son développement : Xen est dorénavant un projet de la Fondation Linux (lire la [dépêche dédiée](http://linuxfr.org/news/xen-devient-un-projet-de-la-fondation-linux)). Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche. Merci aux participants à la rédaction de cette dépêche : Davy Defaud, Batchyx (notamment la partie réseau), _jcr83_, _Jiehong_, Sidonie Tardieu, _yogitetradim_, _baud123_, Étienne Bersac (notamment la partie virtualisation), _detail_pratique_, Martin Peres, _Mali_, Maxime, Xavier Claude, Jarvis, _alpentux_, Nils Ratusznik, _Tata Jeanette_, _kripteks_, _Strash_, _Akiel_ et _patrick_g_ (notamment la partie statistiques). ---- [KernelNewbies 3.9 ](http://kernelnewbies.org/Linux_3.9) ---- #La phase de test ##RC-1 La version [RC-1](https://lkml.org/lkml/2013/3/3/147) a été annoncée par Linus le 3 mars : « Cela fait deux semaines, (OK, treize jours, mais c’est suffisamment proche), la fenêtre d’intégration est désormais fermée, et j’ai arrêté la version 3.9-rc1. Je ne sais pas si c’est seulement moi, mais cette fenêtre d’intégration a connu plus de moments "Uhhuh" que d’habitude. J’ai arrêté le processus d’intégration plusieurs fois à cause de bogues qui semblaient vraiment effrayants, mais heureusement à chaque fois les gens ont été aussi présents que les paparazzi autour de Justin Bieber. Un grand merci à Peter, Ted et Rafael (et également aux personnes ayant rapporté les bogues !) pour leur réactivité. Ça aurait pu être bien pire. Comme d’habitude, il y a des changements partout. Nous avons deux nouvelles architectures ([Metag](http://www.imgtec.com/meta/meta-technology.asp) et [ARC](http://en.wikipedia.org/wiki/Advanced_RISC_Computing "Advanced RISC Computing")) et des tonnes de travaux sur ARM (comme d’habitude) avec encore plus de plates‐formes passant sous le giron générique. Les développeurs MIPS ont essayé de rivaliser en nettoyant les espaces dans leur code, mais ceux d’ARM sont restés en tête en termes de changements sur leur plate‐forme. Nous avons également des mises à jour de presque tous les systèmes de fichiers, même si Btrfs (code initial RAID 5 & 6, instantanés et performances de fsync) et ext4 ([perforation](https://lwn.net/Articles/415889/), cache des [_extents_](http://fr.wikipedia.org/wiki/extent "Définition Wikipédia") et aussi performances de fsync) ont bénéficié des plus grands changements. Mais la plupart des mises à jour (environ 60 %) sont du côté des pilotes, comme d’habitude. Les principales se trouvent dans le processeur graphique, le réseau, la [branche de] recette _— staging —_, le contrôleur de broches _pinctrl_, le son ; mais il y en a un peu partout. Il y a pas mal de trucs, et, comme à l’accoutumée, même le résumé des modifications est vraiment trop long pour être posté ou survolé. Je vous suggère d’utiliser _git_ pour vérifier la partie qui vous intéresse. Linus » ##RC-2 La version [RC-2](https://lkml.org/lkml/2013/3/10/256) est sortie le 10 mars : « Salut, les choses ont été raisonnablement calmes. Bien sûr, Dave Jones a créé un peu de désordre avec Trinity, ce qui nous a tous agité un brin ; mais Al est de retour, et espérons qu’il est désormais occupé à chevaucher virtuellement à notre rescousse sur son cheval blanc. Mais sinon, tout s’est bien passé pendant cette phase de RC. Le _diffstat_ est raisonnablement plat (un bon signe), avec les pilotes de réseau sans fil qui sortent du rang. Ceci est principalement dû à un nouveau pilote pour le contrôleur USB Gigabit ASIX AX88179_178A. À part ces pilotes réseau, nous avons eu des mises à jour DRM, md et [GPIO](http://fr.wikipedia.org/wiki/GPIO "Définition Wikipédia"), Btrfs, réseau, ARM, son... Des trucs un peu partout, mais rien de terriblement inquiétant. Considérant que certaines RC2 sont trop longues pour pouvoir publier le résumé de leurs modifications, je suis content. Et maintenons les choses ainsi ! OK ? Linus » ##RC-3 La version [RC-3](https://lkml.org/lkml/2013/3/17/186) a été annoncée le 17 mars : « Pas aussi petite que la -rc2, mais cette dernière était exceptionnellement calme. Il y avait donc clairement des choses en attente qui sont arrivées pour cette -rc3, avec des pilotes réseau et USB dans le peloton de tête. Mais il y a aussi divers pilotes, des mises à jour d’architectures, des corrections sur Btrfs, etc. Linus » ##RC-4 La version [RC-4](https://lkml.org/lkml/2013/3/23/147) a été annoncée le 23 mars : « Une semaine plus tard, voici une nouvelle -rc. Et les choses ne se sont pas calmées, ce qui démontre que la gentille petite version -rc2 était certainement une exception. Mais je suis optimiste, bon sang, et je vais continuer à espérer que les choses vont changer, et que la semaine à venir sera ennuyeuse et dépourvue du moindre travail réel. Cela vaudrait mieux, car ce sont les vacances de printemps et les enfants sont là. Qu’importe. Bien que ça n’ait pas été aussi calme que je l’aurais voulu, ce n’est pas pour autant que les choses ont été incroyablement passionnantes non plus. La plupart des modifications sont vraiment assez triviales. La majeure partie du travail est terminée dans les pilotes (DRM, md, net, mtd, USB, son), mais aussi dans les mises à jour des plates‐formes (PowerPC, ARM, SPARC, x86) et le travail sur les systèmes de fichiers (CIFS, ext4). Allez la tester, Linus » ##RC-5 La version [RC-5](https://lkml.org/lkml/2013/3/31/133) est, elle, sortie le 31 mars : « Nouvelle semaine, nouvelle -rc. Je suis comme la poste américaine : "Ni la neige, ni la pluie, ni la chaleur, ni l’obscurité de la nuit" ne m’empêcheront de faire des sorties hebdomadaires de -rc. De petites vacances comme Pâques ? Bah, fumisteries. Cela pourrait bien retarder le courriel de sortie de quelques heures parce qu’un homme doit se goinfrer d’un étrange dessert de saison (et les desserts de Pâques finlandais sont plus étranges que bien d’autres), mais ça n’arrêtera pas la progression inéluctable vers la publication 3.9 finale. Donc la voici. Une pimpante nouvelle version prête à sortir n’attendant plus qu’à être testée. Rien de particulier ne se distingue. Les mises à jour du DRM Exynos et des pilotes IBM [RamSan](http://en.wikipedia.org/wiki/Texas_Memory_Systems) sont un peu plus grosses que le reste, une mise à jour de [L2TP](http://fr.wikipedia.org/wiki/L2TP "Définition Wikipédia")... Le reste étant de plutôt petits correctifs un peu partout. La plupart sont des pilotes (block, net, media, TTY, USB), du réseau et des mises à jour de systèmes de fichiers (Btrfs, NFS). Quelques mises à jours d’architectures (x86, ARC). Les choses semblent se calmer un peu, et tout semble en bonne voie pour la sortie de la 3.9 dans quelques semaines. Linus » ##RC-6 La version [RC-6](https://lkml.org/lkml/2013/4/8/9) a été annoncée le 7 avril : « Les choses semblent en bonne voie et la semaine a été plutôt ennuyeuse. Beaucoup de petites corrections, quelques retours en arrière. Du réseau, des petites corrections sur les architectures (ARM, MIPS, [S/390](http://fr.wikipedia.org/wiki/ZSeries), Alpha, [TILE](http://en.wikipedia.org/wiki/TILE64), x86), des pilotes, des mises à jour mineures des systèmes de fichiers ([GFS2](http://fr.wikipedia.org/wiki/Global_File_System), ext4, une minuscule correction des [attributs étendus](http://fr.wikipedia.org/wiki/attributs étendus "Définition Wikipédia") de ReiserFS). Rien d’enthousiasmant ne se distingue, je pense que le résumé des modifications qui suit dresse un bon état des lieux pour les gens qui se complairaient dans les détails... Les choses semblent en bonne voie, ce qui signifie qu’à moins que quelque chose n’apparaisse, la RC7 sera probablement la dernière RC, comme d’habitude. Linus » ##RC-7 La version [RC-7](https://lkml.org/lkml/2013/4/14/107) a été annoncée le 14 avril : « Nouvelle semaine, nouvelle -rc. Il s’agit majoritairement de divers correctifs d’une ligne, avec quelques corrections de pilotes légèrement plus grosses. La plus intéressante (pour moi, et probablement personne d’autre) est une correction pour un bogue plutôt subtile d’invalidation du cache [TLB](http://fr.wikipedia.org/wiki/Translation_Lookaside_Buffer "Translation Lookaside Buffer") qui ne touche que les [PAE](http://fr.wikipedia.org/wiki/Physical_Address_Extension "Physical Address Extension") [extension d’adresse physique] 32 bits, en raison de la façon étrange dont ça fonctionne. Même dans ce cas, vous ne serez touché que dans des cas de correspondances particulièrement alambiqués, néanmoins nous suspectons cette erreur d’être la cause des bogues déclenchés par Google Chrome, tels que : chrome: Corrupted page table at address 34a03000 *pdpt = 0000000000000000 *pde = 0000000000000000 Bad pagetable: 000f [#1] PREEMPT SMP Cependant, ce problème est si rare que nous n’avons pas pu vérifier que cela le résout réellement. Ceci étant dit, ce bogue est nettement plus commun (et par "nettement plus commun", je veux dire "toujours littéralement impossible à rencontrer, à moins d’être vraiment malchanceux") sur des machines récentes qui ont un plus gros cache TLB et qui auraient pu tourner sans problème en mode 64 bits sans ce dégoutant avorton qu’est le PAE x86, et une petite voix en moi me dit que toute personne rencontrant ce problème sur une telle machine n’a probablement que ce qu’il mérite. Mais si vous avez vu des messages comme celui‐ci, et que vous fonctionnez toujours en PAE, essayez la nouvelle -rc. Le reste des corrections est sans doute plus pertinent pour la plupart des gens, mais eh, celle du PAE m’a titillé l’esprit. Quoi qu’il en soit, allez la tester, malgré le problème de PAE. Linus » ##RC-8 La version [RC-8](https://lkml.org/lkml/2013/4/21/89) a été annoncée le 21 avril : « Oui, j’espérais vraiment (et je l’avais à l’origine prévu) sortir la version 3.9 finale ce week‐end, mais nous avons eu suffisamment de problèmes pour que je ne me sente pas à l’aise avec ça. C’était limite, aucun des problèmes n’était énorme ; et peut‐être aurais‐je pu me contenter de baptiser cette -rc en version 3.9 et ouvrir la fenêtre d’intégration. Mais eh, une semaine supplémentaire ne fera pas de mal. Le gros des changements concerne ici le réseau (à la fois le cœur et les pilotes), mais il y a des corrections de bogues sur les architectures (SPARC, x86, ARM et PowerPC) et divers trucs. Deux ou trois retours en arrière et un peu de nettoyage. Le résumé des modifications donne une idée du détail. Rien en soi n’aurait dû retarder la sortie de la 3.9 à mon sens, mais j’espérais une semaine plus calme. S’il vous plaît, ne m’envoyez plus de demandes d’intégration, à moins que ce soit quelque chose de vraiment critique, et donnons‐nous pour objectif une sortie très calme de la version 3.9 le week‐end prochain. D’accord ? Linus » #Le détail des nouveautés ##Mise en veille « suspend freeze » pour tous et PowerClamp pour processeurs Intel Cette version du noyau introduit [PM_SUSPEND_FREEZE](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7e73c5ae6e7991a6c01f6d096ff8afaef4458c36), un nouveau mode de mise en veille. Il sagit d’un mode de mise en veille intermédiaire, permettant un réveil plus réactif que _suspend-to-RAM_ (alias PM_SUSPEND_MEMORY) mais en contrepartie moins économe en énergie (le processeur tourne toujours mais au ralenti, car les traitements en cours sont interrompus). Ce nouveau mode bénéficiera principalement aux ordiphones et tablettes. Un autre ajout de cette version est cette fois spécifique aux processeurs Intel ; [il s’agit de PowerClamp](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/thermal/intel_powerclamp.txt), un pilote qui permet de limiter la consommation processeur en utilisant ses capacités de mise en veille _— C state —_ plutôt qu’en jouant sur la vitesse de son horloge. ## Du côté d’ARM Ce noyau, dans la lignée de ce qui est fait [depuis la version 3.7](https://linuxfr.org/news/sortie-du-noyau-linux-3-7#toc_10) apporte de nombreuses améliorations concernant la [prise en charge des architectures ARM](http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/02975.html). Le travail de nettoyage et d’harmonisation devrait se poursuivre encore pendant une ou deux versions, mais le travail effectué peut déjà être mesuré, dans le sens où 18 [systèmes mono‐puces (SoC)](http://fr.wikipedia.org/wiki/Syst%C3%A8me_sur_une_puce "Définition Wikipédia") sont maintenant pris en charge en mode « multi‐plate‐forme » (le but étant d’arriver à : « un même noyau pour tous » à l’identique des architectures x86). ##Pilotes graphiques pour vos PC ###Intel Intel continue de préparer l’arrivée des futurs processeurs _Haswell_ (successeurs des _Ivy Bridge_, [dont la sortie est prévue pour le 4 juin prochain](http://www.pcinpact.com/breve/79256-haswell-lancement-4-juin.htm) et qui sont pleinement [pris en charge par le noyau depuis la version 3.8.2](https://01.org/linuxgraphics/downloads/2013/2013q1-intel-graphics-stack-release)) et _Valley View_ ([SoC](http://fr.wikipedia.org/wiki/SoC "Définition Wikipédia") à base de processeur _Atom_) qui, rappelons‐le, utilisent tous deux un cœur graphique de même génération que celui équipant les actuels processeurs _Ivy Bridge_ (Gen7). Parallèlement, les pilotes des générations actuelles poursuivent leur importante refonte de la gestion des modes d’affichage entamée [avec la version 3.7](http://linuxfr.org/news/sortie-du-noyau-linux-3-7#toc_20), avec cette fois la reprise du _modeset locking_ (voir [le billet de Daniel Vetter à ce sujet](http://blog.ffwll.ch/2013/02/new-kernel-modesetting-locking.html)). ###Nouveau (pilote libre pour puces NVIDIA) Le pilote Nouveau offre finalement la possibilité de gérer (manuellement ou automatiquement) le ventilateur sur les puces NV40 et NV50 (équipant les cartes GeForce 6xxx à 9xxx et les puces graphiques 1xx à 3xx). Ce point avait été évoqué lors la sortie de la [version 3.7](http://linuxfr.org/news/sortie-du-noyau-linux-3-7#toc_21). Cette fonctionnalité est cependant désactivée par défaut, en attendant qu’assez de testeurs aient pu valider le comportement du ventilateur dans toutes les situations. Toujours dans la catégorie gestion énergétique, Nouveau vérifie maintenant la température de la carte et peut éteindre l’ordinateur si celle‐ci devient critique (environ 130 °C). Cette fonctionnalité est activée par défaut sur les cartes ayant une sonde de température interne (non [I2C](http://en.wikipedia.org/wiki/I2c "Définition Wikipédia")), à l’exception des NV50 (GeForce 8800, pas la famille des NV50). Le support des NV50 [devrait être intégré dans la version 3.10](http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=ba366c25bc0b2a6f5e4d3fab07851e6f39b883be). Par ailleurs, les fonctionnalités DMA-BUF/PRIME (permettant de gérer les systèmes intégrant deux puces graphiques, la plus puissante — mais aussi la plus gourmande — devant prendre le relais quand le besoin se fait sentir) ont été intégrées avec une licence permettant aux pilotes non libres d’en faire usage (ce qui devrait être rapidement le cas, comme l’énonce [cette dépêche](https://linuxfr.org/news/actualite-des-puces-graphiques-tegra-optimus-uvd-et-beignet)). NVIDIA peut ainsi bénéficier du travail effectué par la communauté tout en gardant son pilote fermé : chacun appréciera ([ou pas](http://www.h-online.com/open/features/Kernel-comment-Bad-show-NVIDIA-1845899.html)). Pour plus de détails, le lecteur pourra se référer à [la dépêche saluant la sortie de la version 3.3 du noyau](https://linuxfr.org/news/sortie-du-noyau-linux-3-3#toc_12). ###Radeon (pilote libre pour puces ATI/AMD) Les puces AMD de la famille _Oland_ (équipant les cartes de la série Radeon HD 8500 et 8600) sont désormais prises en charge, ainsi que la prochaine génération de puces [APU](http://fr.wikipedia.org/wiki/Accelerated_Processing_Unit) (puce intégrant le processeur central et le processeur graphique), _Richland_. ##Systèmes de fichiers La nouveauté à souligner est que Btrfs ([liste des changements](https://lkml.org/lkml/2013/3/2/90)) prend désormais en charge les [RAID](http://fr.wikipedia.org/wiki/RAID_%28informatique%29) 5 et 6 (en plus des RAID 0 et 1). Pour rappel, il y a trois gros avantages à implémenter le RAID dans le système de fichiers au lieu de laisser ce travail à une couche d’abstraction. Premièrement, la restauration est potentiellement beaucoup plus rapide, car il n’y a besoin de restaurer que les morceaux qui contiennent des données, alors qu’une couche d’abstraction est obligée de toujours restaurer le disque entier. Deuxièmement, il est possible d’avoir différents types de RAID au sein d’un même système de fichiers, comme les données en RAID 0 et les métadonnées en RAID 1. Enfin, en cas de corruption de données sur un RAID 0, Btrfs peut se baser sur les [sommes de contrôle](http://fr.wikipedia.org/wiki/Somme_de_contr%C3%B4le) des métadonnées pour déterminer quelle copie est valide. De même, un correctif améliore aussi les performances de `fsync`. Concernant les autres systèmes de fichiers : Un bogue avait été découvert dans la version 3.0 qui affectait les performances du système de journal d’ext4, JDB2, a été corrigé ([liste des changements](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6515925b8259549b7f2187e25d3260306e3e85e5)). La prise en charge des espaces de noms d’utilisateurs a été introduite [précédemment](http://linuxfr.org/news/sortie-du-noyau-linux-3-8#toc_29), elle est maintenant disponible pour les systèmes de fichiers CIFS, NFS, Ceph, OCFS2 et quelques autres, mais pas dans XFS. Or, il n’est pas possible d’activer ces *namespaces* si un système de fichiers qui ne les gère pas est aussi activé, ce qui veut dire que la fonctionnalité ne pourra pas être intégrée dans la plupart des distributions. Pour rappel, cette fonctionnalité permet de donner les droits d’administration à un utilisateur sur une partie restreinte du système de fichiers sans qu’il puisse utiliser ces droits hors de ladite partie. ##Réseau ###IPv6 L’implémentation d’IPv6 a reçu plusieurs améliorations dans ce noyau. En particulier, des problèmes de sécurité liés à l’implémentation des technologies de transition [_6rd_](http://fr.wikipedia.org/wiki/_6rd_ "Définition Wikipédia") et [_6to4_](http://fr.wikipedia.org/wiki/_6to4_ "Définition Wikipédia") sont maintenant corrigibles dans le noyau Linux. Le problème se situe au niveau de l’encapsulation et la décapsulation d’IPv6 à l’intérieur d’IPv4 : l’attaquant peut, dans certains cas, contrôler les adresses de provenance qui seront utilisées lors de l’encapsulation et les adresses de destination qui seront utilisées après la décapsulation. Cela permet de masquer la véritable origine d’une attaque ou d’attaquer le réseau dans lequel se trouve le relais _6to4_ ou _6rd_. Ces problèmes et leurs solutions sont détaillés dans les RFC [3964](http://tools.ietf.org/html/rfc3964#section-5.2) et [5969](http://tools.ietf.org/html/rfc5969#section-12). Le [correctif de Hannes Frederic Sowa](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=218774dc341f219bfcf940304a081b121a0e8099) n’implémente qu’une partie des vérifications de ces RFC. Le reste pouvant déjà être corrigé par l’administrateur réseau avec des règles `iptables` et l’activation du filtrage du chemin inverse ([_reverse path filtering_](http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html)). Divers correctifs pour la multidiffusion de groupe sur IPv6, le [_multicast IPv6_](http://fr.wikipedia.org/wiki/Multicast#IPv6), ont également été intégrés dans ce noyau : les trafics de nœud local _— node‐local —_ et interface locale _— interface‐local —_ ne fuiteront plus, et on ne demandera plus aux cartes réseau de recevoir ce type de trafic. En revanche, le noyau rejoindra désormais automatiquement tous les types de groupes _all‐nodes_ et _all‐routers_ (si le routage est activé). Auparavant, uniquement _link‐local all‐nodes_ et _link‐local all‐routers_ étaient automatiquement rejoints. Enfin, _netconsole_, qui permet de faire transiter les messages du noyau à travers le réseau, [gère maintenant IPv6](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b3d936f3ea1c97c32680e0cd235474cf9dadb762) en plus d’IPv4. ###Netfilter Ce noyau 3.9 introduit un nouveau système pour marquer des sessions. Jusqu’à présent, l’administrateur réseau qui souhaitait différencier des types de sessions (par exemple, pour privilégier des sessions par rapport à d’autres, ou pour simplifier ses règles de filtrage) n’avait à sa disposition qu’une « marque de connexion » (`connmark`) sous la forme d’un entier arbitraire de 32 bits. Souvent, cet entier était utilisé comme un masque de bits, ce qui pose certains problèmes : 32 bits ne sont parfois pas suffisants, et il faut que les administrateurs et logiciels se mettent d’accord sur la signification de chaque bit. Ces problèmes peuvent maintenant être évités avec les `connlabels`, ou étiquettes de session. Cette nouvelle fonctionnalité de [Netfilter](http://fr.wikipedia.org/wiki/Netfilter "Définition Wikipédia") permet à un administrateur réseau d’attacher une ou plusieurs étiquettes à une session. C’est équivalent à utiliser `connmark` comme un masque de bits, sauf qu’il est possible de mettre jusqu’à 128 étiquettes sur une connexion au lieu de 32. Et `iptables` a été modifié pour que l’administrateur réseau puisse utiliser des noms plutôt que des numéros d’étiquettes. Une autre fonctionnalité a été ajoutée dans Netfilter : la possibilité d’utiliser un filtre [_« Berkeley Packet Filter »_ comme règle `iptables`](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e6f30c731718db45cec380964dfee210307cfc4a). Il était déjà possible de filtrer le contenu des paquets avec [_u32_](http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.adv-filter.u32.html), mais de manière extrêmement limitée. BPF offre un langage de filtrage plus avancé, avec embranchements, opérations arithmétiques, registres et compilation à la volée sur certaines architectures. Cela tire parti du fait que BPF était déjà couramment utilisé en tant que filtre d’interface de connexion ([_socket_](http://fr.wikipedia.org/wiki/Socket#Logiciel)). Par exemple, les filtres `pcap-filter` utilisés notamment par `tcpdump` sont traduits en un programme BPF, et il est donc possible d’utiliser toutes leurs fonctionnalités avec `iptables`. ### Interfaces de connexion Il est maintenant possible de [verrouiller un filtre BPF sur une interface de connexion](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d59577b6ffd313d0ab3be39cb1ab47e29bdc9182) ([_socket_](http://fr.wikipedia.org/wiki/Socket#Logiciel "Définition Wikipédia")), de telle sorte qu’il ne puisse pas être enlevé. Cela permet à un processus de verrouiller un filtre sur une interface de connexion privilégiée, avant de se défaire de ses privilèges ou de l’envoyer à un processus non privilégié. Ce noyau implémente désormais [l’option `SO_REUSEPORT`](https://lwn.net/Articles/542629/) sur les types d’interface de connexion usuels. Cette option permet à plusieurs processus d’écouter sur un même port, les demandes de connexions étant réparties équitablement entre les différents processus. Couplé à la parallélisation du traitement des paquets (introduit dans le [noyau 2.6.35](https://linuxfr.org/news/nouvelle-version-2635-du-noyau-linux#long4) par le même auteur, Tom Herbert, travaillant chez Google), cela permet d’augmenter les performances des serveurs multicœurs. ### Ponts réseau (bridges) Ce noyau implémente maintenant le [filtrage des réseaux locaux virtuels](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=243a2e63f5f47763b802e9dee8dbf1611a1c1322) ([VLAN](http://fr.wikipedia.org/wiki/VLAN "Définition Wikipédia")) dans les [ponts réseaux _— bridges —_](http://fr.wikipedia.org/wiki/Pont_%28informatique%29 "Définition Wikipédia") de manière native. Chaque port dispose maintenant d’une liste de réseaux locaux virtuels autorisés, ceux ne faisant pas partie de cette liste seront filtrés en entrée et en sortie du port. ## Virtualisation ### ARM KVM prend désormais en charge les processeurs ARM Cortex A15. Pour information, Xen supportera ARM à partir de la version 4.3 prévue cet été. Les pilotes permettant l’ajout à chaud de processeurs et de mémoire vive du côté « invité », _DomU_, sont inclus. La suppression à chaud, elle, n’est pas encore prise en charge. Les entrées‐sorties virtuelles VFIO ont été étendues pour permettre l’accès direct aux cartes VGA aux systèmes invités. Les pilotes [VMCI](http://pubs.vmware.com/vmci-sdk/) ont été inclus : ils gèrent la communication entre un hyperviseur VMware et un système GNU/Linux invité. Ils sont notamment utilisés pour le partage de dossiers. ### dm-cache Une nouvelle cible du gestionnaire de correspondance de périphériques, le _device-mapper_, a fait son apparition : `dm-cache`. Il permet, par exemple, d’utiliser un disque SSD local comme cache d’un périphérique réseau. À noter que ce n’est pas ni [_bcache_](http://bcache.evilpiepirate.org/) (par Google), ni [_EnhanceIO_](https://github.com/stec-inc/EnhanceIO) (issu de Facebook), ni la solution de [VISA](http://visa.cs.fiu.edu/dmcache/) qui a été reprise, mais une nouvelle implémentation Red Hat, par Joe Thornber et Heinz Mauelshagen (concepteur de la première version de LVM). Cette version est beaucoup plus avancée : promotion et déchéance de blocs du cache, modularisation des politiques du cache, meilleure gestion de la concurrence et de la saturation du cache, de la surveillance _— monitoring —_, etc. Le code est conséquent, mais il réutilise une partie de `thin-provisionning`, notamment pour les méta‐données. Pour l’instant, seules deux politiques sont incluses dans le noyau : `multiqueue` qui gère l’écriture dans le cache en écriture différée — [_writeback_](http://fr.wikipedia.org/wiki/M%C3%A9moire_cache#Politique_d.27.C3.A9criture_dans_la_m.C3.A9moire_de_niveau_sup.C3.A9rieur) — et écriture immédiate — [_writethrough_](http://fr.wikipedia.org/wiki/M%C3%A9moire_cache#Politique_d.27.C3.A9criture_dans_la_m.C3.A9moire_de_niveau_sup.C3.A9rieur) —, et `cleaner` qui permet de nettoyer progressivement tous les blocs modifiés _— dirty blocks —_ via une écriture différée. Il suffit de basculer la politique d’un volume vers `cleaner` pour synchroniser le cache vers le disque original. LVM ne sait pas encore tirer parti de cette nouvelle cible, mais vous pouvez déjà la tester avec `dmsetup`. ## Autres nouveautés Un peu anecdotique peut‐être en 2013, mais toujours sympathique : les pilotes `libata` prennent dorénavant en charge ZPODD _— zero power optical device drives —_, afin que les lecteurs de disques optiques compatibles ne consomment quasiment aucune énergie lorsqu’ils ne contiennent aucun disque. La (dé)compression [LZO](http://fr.wikipedia.org/wiki/LZO "Définition Wikipédia") est dorénavant bien plus rapide, [le code du noyau ayant intégré les derniers développements en la matière](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b0af9cd9aab60ceb17d3ebabb9fdf4ff0a99cf50), qui tirent parti au mieux des architectures récentes (x86 comme ARM). Les développeurs ne baissent pas les bras et continuent de [tenter de dompter les fonctions de gestion de l’énergie ASPM](http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/03707.html) de nos systèmes (on se souvient [des difficultés rencontrées récemment à ce sujet](https://linuxfr.org/news/sortie-du-noyau-linux-3-3#toc_34)). Signalons également que les processeurs [Synopsys ARC](http://www.synopsys.com/IP/ProcessorIP/ARCProcessors/Pages/default.aspx) qui équipent des [SoC](http://fr.wikipedia.org/wiki/SoC "System on Chip — système monopuce") que l’on retrouve dans de nombreux produits électroniques grand public, comme les boîtiers TV, sont désormais [pris en charge](http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/03172.html), tout comme les puces [NFC](http://fr.wikipedia.org/wiki/Near_Field_Communication "Définition Wikipédia") [_MicroRead_](http://www.lembarque.com/la-puce-nfc-microread-dinside-secure-est-compatible-avec-le-noyau-linux-3-9_000410) d’Inside Secure, et les puces Wi‐Fi de [la série](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8ca151b568b67a7b72dcfc6ee6ea7c107ddd795c) [7000](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=99cd471423991fe9ba011e8948cdea95f5432338) qu’Intel devrait commercialiser dans les prochains mois (peut‐être en association avec les processeurs _Haswell_). Enfin, du côté des [SoC](http://fr.wikipedia.org/wiki/SoC "Définition Wikipédia") ARM, la prise en charge du cœur processeur graphique ARM du Tegra s’est améliorée, avec l’ajout de la prise en charge des _planes_ (sorte de compositeur matériel), de la synchronisation verticale et du basculement de page ([_page flipping_](http://en.wikipedia.org/wiki/Page_flipping#Page_flipping)).> _The cgroup controller for regulating disk read and write speeds now correctly supports hierarchical control groups where CFQ is used as the I/O scheduler. This does not yet apply to I/O throttling, however (1, 2 and others)._>>_Changes to the kernel’s memory management can reduce latencies produced by "stable pages" (1 and others). Since Linux 3.0, stable pages protect data already delivered to the kernel for writing but not yet written from further modification. This is important for processes such as checksum calculation and filesystem‐implemented compression. More detail can be found in this LWN.net article._ Source : [_H-online_](http://www.h-online.com/open/features/Kernel-Log-Coming-in-3-9-part-1-Filesystems-and-storage-1831197.html) #Statistiques En ce qui concerne les statistiques du cycle de développement du noyau 3.9, le site [_LWN.net_](http://lwn.net/) a publié son traditionnel [article récapitulatif](https://lwn.net/Articles/547073/). En termes de modifications, le total s’établit à 11 802 au 21 avril, alors qu’il était de 12 394 pour le noyau précédent (le record absolu). Le point notable de ce cycle 3.9 est que le record du nombre de développeurs différents a été battu, puisqu’il s’établit à 1 364. Les contributeurs les plus prolifiques sont Takashi Iwai, qui a écrit 265 modifications pour améliorer les pilotes de son de la couche ALSA, et H. Hartley Sweeten et ses 259 modifs portant sur le nettoyage du sous‐système [_Comedi_](http://www.comedi.org/) (périphériques d’acquisition de données). En termes de lignes de code, c’est Paul Gortmaker qui remporte la timbale avec 34 927 lignes modifiées. Paul s’est concentré sur la suppression de plusieurs pilotes réseau obsolètes, et le noyau s’est allégé de plus de 34 000 lignes suite à ce nettoyage de printemps. Si l’on regarde le classement des entreprises, on constate que Red Hat a cédé sa première place au profit d’Intel (1 050 modifications contre 1 185). C’est la première fois que la firme de Santa Clara s’empare ainsi de la tête du classement, et cela démontre sa détermination à fournir des pilotes libres pour toutes ses lignes de produits. Enfin, pour ceux qui s’intéressent au développement à long terme du noyau, on peut noter que Jonathan Corbet, le fondateur du site _LWN.org_, a donné sa traditionnelle conférence _Linux Weather Forecast_ lors du sommet 2013 de la [Fondation Linux](http://www.linuxfoundation.org/). [La vidéo](https://www.youtube.com/watch?v=ABbQ5GVlNvw) est fort intéressante, puisqu’elle propose une rétrospective sur un an (depuis le noyau 3.3, en mars 2012). Sur cette période d’à peine un an, ce sont plus de 68 000 modifications qui ont été intégrées et 3 172 développeurs différents qui ont participé à l’évolution de Linux. En résumé, il n’y a pas d’inquiétude à avoir quant au rythme d’évolution !