URL: https://linuxfr.org/news/le-noyau-linux-3-10-est-sorti Title: Le noyau Linux 3.10 est sorti Authors: Jiehong Davy Defaud, Sidonie_Tardieu, yogitetradim, Mali, palm123, patrick_g, Martin Peres, jcr83, Yves Bourguignon, antistress, Jarvis, Anonyme, Denis Dordoigne, misaflo, Strash, Nÿco, ariasuni, claudex, bayo, EdB, Nils Ratusznik, François et Benoît Sibaud Date: 2013年05月06日T23:18:28+02:00 License: CC By-SA Tags: linux, kernel, noyau_linux, coulisses, linus_torvalds et lwn Score: 100 La sortie de la version stable 3.10 du noyau Linux vient d’être annoncée par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable depuis les serveurs du site [_kernel.org_](http://www.kernel.org/). Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche (qui est sous licence libre CC BY-SA). Merci à tous les participants à la rédaction de cette dépêche, dont vous trouverez les noms en cliquant sur le lien _22 contributeurs_, sous le titre de cette dépêche ! ---- [L’article de H-online sur les nouveautés de Linux 3.10](http://www.h-online.com/open/features/What-s-new-in-Linux-3-10-1902270.html) [Article LWN sur Linux 3.10 — partie 1](http://lwn.net/Articles/548834/) [Article LWN sur Linux 3.10 — partie 2](http://lwn.net/Articles/549477/) [Article LWN sur Linux 3.10 — partie 3](http://lwn.net/Articles/550205/) [Article de Kernel Newbies sur Linux 3.10](http://kernelnewbies.org/Linux_3.10) [Site officiel du noyau Linux](http://www.kernel.org/) [Sortie du noyau précédent](http://linuxfr.org/news/sortie-du-noyau-linux-3-9) ---- #La phase de test ##RC-1 La version [RC-1](https://lkml.org/lkml/2013/5/11/155) a été annoncée par Linus le 11 mai :> _Et voici la plus grosse_ -rc1 _depuis des années (peut‐être depuis toujours), au moins en ce qui concerne le nombre de changements (pas forcément sur le nombre de lignes : je n’ai pas vérifié les statistiques à ce sujet)._> _Ce qui était inattendu, car si linux-next était assez gros, il n’était pas non plus exceptionnel. Je suis sûr que Stephen Rothwell parlera des statistiques sur les changements qui n’étaient pas dans -next, et nous verrons si c’était bien la raison..._>> _Bref, malgré le grand nombre de changements, espérons que tout soit extrêmement simple. Bien sûr !_>> _Cependant, même normalement, il n’y a aucune possibilité de lister tous les changements, d’autant plus quand c’est une_ -rc1 _aussi énorme. Je peux joindre mon journal résumé une nouvelle fois, et il est amusant de mentionner (à nouveau) que le nom attribué aux changements n’est pas nécessairement le nom de l’auteur du code ; c’est juste la personne qui m’a envoyé par courriel la demande d’intégration. Donc, on peut voir ça en gros comme le haut du panier des mainteneurs, mais c’est assez trompeur, puisque certains de ces changements sont effectués par des groupes, alors qu’il n’y a qu’une personne qui m’envoie le résultat final._>> _Mais ça reste à peu près lisible et vous donne une idée raisonnable de ce qui se passe. On peut mieux comprendre en regardant_ Git _directement, puisque les fusions des changements contiennent souvent une meilleure description de ce qui a été effectué. Les sous‐mainteneurs n’envoient pas systématiquement la description, mais la plupart des fusions contiennent de l’information humainement compréhensible._>> _Il est bien possible que j’aie raté quelque chose : c’était vraiment une fenêtre de d’intégration bien plus fournie que d’habitude._>> _Si c’est le cas, bougez‐vous le cul._> > _Linus_ ##RC-2 La version [RC-2](https://lkml.org/lkml/2013/5/20/577) a été annoncée par Linus le 20 mai :> _Juste un peu plus d’une semaine, et la_ -rc2 _est là._>> _Pour une_ -rc2, _elle n’est pas déraisonnablement grosse, mais j’ai intégré quelques ajouts que je n’aurais pas intégrés plus tard dans la série des RC. Donc, ce n’est pas non plus petit. Nous avons des mises à jour d’architectures (PowerPC, MIPS, PA-RISC), des corrections de pilotes (réseau, pilotes graphiques, target, Xen), des mises à jour de systèmes de fichiers (Btrfs, ext4 et Ceph -rdb)._> > _Et de nombreuses petites corrections éparses. Le résumé des changements est ajouté, ça devrait être plus petit et lisible à l’avenir._>> _Linus_ ##RC-3 La version [RC-3](https://lkml.org/lkml/2013/5/26/212) a été annoncée le 26 mai :> _À nouvelle semaine, nouvelle_ rc. _Et une_ grosse _qui plus est._>> _Je ne suis pas particulièrement ravi : cette_ -rc3 _est bien plus grosse que la_ -rc2 _ne l’était, bien qu’il n’y ait rien de particulièrement effrayant qui sorte du lot, juste un gros paquet de petites modifications. Apparemment, pas mal de monde a zappé la_ -rc2 _et s’est rattrapé sur cette_ -rc3.>> _Bref._>> _Je peux quasiment garantir que la_ -rc4 _sera plus petite, parce que, d’une, je vais être bien grincheux avec quiconque tenterait d’envoyer autant de modifications que pour la -rc3 ; et de deux, je suis en voyage presque toute la semaine (et une partie de la semaine prochaine). J’aurai accès à Internet mais j’attends de vous — et je l’espère vraiment — que ça se calme pour la suite. D’accord ? D’ACCORD ?_>> _Cela étant dit, il n’y a que des petites modifications, qui pour la plupart concernent les pilotes : réseau, zone de préparation — staging area —, USB, pilotes graphiques, DRM... Il y a aussi quelques mises à jour d’architectures : ARM, MIPS et PowerPC. Et pour le reste, du bazar un peu partout._>> _Récupérez‐moi ça,_>> _Linus_ ##RC-4 La version [RC-4](https://lkml.org/lkml/2013/6/2/23) a été annoncée le 2 juin :> _À nouvelle semaine, nouvelle_ -rc. _Mais cette fois (au moins jusqu’ici), seulement sous forme d’une arborescence Git — à ceux qui utilisent les archives_ tar _et les correctifs, je m’excuse, mais je suis un abruti fini et je n’ai installé ni_ [kup](https://git.kernel.org/cgit/utils/kup/kup.git), _ni ses dépendances Perl, et encore moins mes scripts_ kup _de sorties sur mon [Pixel](https://plus.google.com/+LinusTorvalds/posts/dk1aiW4JjHd) avant mon départ._>> _Et alors que je peux lire et écrire des courriels, que Git parvient encore à s’en sortir avec les quelques Kio/s (saccadés) de la connexion Internet à laquelle j’ai actuellement accès, installer les paquets Perl et compagnie semble illusoire._>> _Je soupçonne que personne n’utilise vraiment les archives ou les correctifs, sachant que Git est tellement plus pratique et efficace, donc avec un peu de chance personne ne s’en plaindra. Mais je finirai par combler ce manque. Avec de la chance, d’ici un à deux jours, lorsque ma mise à jour_ yum _sera finie. Et si ce n’est pas fait dans ce délai, alors je le ferai quelques jours plus tard, à mon retour à la maison._>> _Enfin, bon, la_ rc4 _est plus petite que la_ rc3 _(youpi !). Mais elle pourrait l’être encore plus (bouh !). On retrouve la nuée habituelle de corrections de pilotes (DRM, pinctrl, SCSI, target, fbdev, Xen), mais aussi de systèmes de fichiers (CIFS, XFS, avec de petites corrections pour ReiserFS et NFS)._>> _Mais aussi des mises à jour d’architectures : m68k (la plupart sont des mises à jour defconfig), PowerPC, ARM et x86._>> _Allez‐y, testez._>> _Linus_ ##RC-5 La version [RC-5](https://lkml.org/lkml/2013/6/8/108) est sortie le 8 juin :> _Oui, il est déjà l’heure. Une autre semaine ou presque a passé et une nouvelle version candidate est sortie, afin d’encourager et de rappeler à chacun de l’essayer._>> _J’aimerais pouvoir dire que les choses se calment, mais je mentirais. La_ rc5 _est plus grosse que la_ rc4, _à la fois en termes de changements et en nombre de fichiers modifiés (bien qu’en fait la_ rc4 _avait plus de lignes changées)._>> _Mes amis, mes amis, mes amis. Je vais devoir recommencer à vous maudire, à moins que vous n’arrêtiez de m’envoyer des trucs non critiques. Donc, la prochaine demande d’ajout qui vient « nettoyer » ou qui contient uniquement des gribouillis inutiles, je vais vous interpeller et j’essaierai de trouver de nouvelles façons de vous insulter, vous, votre mère et feu votre hamster._>> _Alors, ne le faites pas. Ne m’envoyez que des corrections pour des problèmes sérieux. D’accord ?_>> _Donc, les changements de la_ rc5 _ont eu lieu à peu près partout : presque la moitié concerne des pilotes (réseau, USB, pilotes graphiques, lecteur de cartes MMC, son...), l’autre moitié concerne des sous‐systèmes variés. Quelques mises à jour d’architectures : MIPS, ARM, quelques pincées d’IA-64, [[MicroBlaze]], [s390](http://fr.wikipedia.org/wiki/ZSeries "Définition Wikipédia") et un peu d’x86. Enfin, la partie réseau (hors pilotes), XFS, FUSE, GFS2, JFS..._>> _Donc, il y en a plus que ce que j’aurais aimé, mais au moins rien ne semble particulièrement inquiétant._>> _Allez‐y, testez. Et encore une fois, s’il vous plaît, ne me faites pas vous maudire, vous et vos animaux de compagnie._>> _Linus_ ##RC-6 La version [RC-6](https://lkml.org/lkml/2013/6/15/204) est sortie le 15 juin :> _À nouvelle semaine, nouvelle_ rc.>> _Et je n’ai même pas eu à maudire les gens autant que ça. Bien sûr, j’ai un peu menacé vos hamsters et refusé une paire de demandes d’ajout, mais avouons‐le, c’était plutôt sans enthousiasme. Dans la majorité des cas les ajouts étaient intéressants._>> _Ce qui ne veut pas dire que la_ rc6 _n’aurait pas pu être plus petite, et je serai probablement encore plus fâché la semaine prochaine si vous essayez d’ajouter des trucs qui ne devraient pas l’être à cette étape, mais ça va mieux que pour la_ rc5.>> _Et alors que je suis encore en déplacement, cette fois‐ci Internet fonctionne mieux, et tout aussi important : j’ai désormais mes scripts de sorties et_ kup _installés sur mon Pixel, donc les archives_ tar _et correctifs sont en cours au moment où j’écris ces mots. Juste pour vous, [[Luddites]], qui utilisez toujours des technologies anciennes._>> _Même si vous êtes un [[Luddite]] et que vous n’avez pas encore découvert les plaisirs coupables d’un flux de travail Git, vous avez vraiment envie utiliser le dernier noyau, j’en suis sûr. Donc, allez‐y, vérifiez que vous ne pouvez pas trouver de cas de régression. En effet, nous avons des corrections un peu partout, même si le fichier des différences est dominé par un correctif de l’analyseur syntaxique DTC [device tree compiler], dû au changement des fichiers générés par [Bison](http://fr.wikipedia.org/wiki/GNU_Bison) 2.5 plutôt que par Bison 2.4._>> _Ce qui reste est plutôt petit, même s’il y en a un peu partout. Architectures : x86, PowerPC, MIPS, ARM et s390. Systèmes de fichiers : Ceph et XFS. Mises à jour réseau et pilotes (son, sans fil, md [RAID logiciel], pilotes grahiques, pilotes en mode bloc)..._>> _Linus_ ## RC-7 La version [RC-7](https://lkml.org/lkml/2013/6/22/97) a été annoncée le 22 juin :> _Voilà, c’est, je l’espère, la dernière_ rc _de la série, et les choses se sont effectivement calmées. Si ça continue ainsi, on est bon pour la sortie._>> _Ça veut dire que l’on a toujours besoin de tests et de gens qui viennent brailler s’ils découvrent des cas de régressions, ou quoi que ce soit._>> _Cette_ rc _contient un paquet assez hétéroclite de corrections çà et là avec (comme d’habitude) des mises à jour notables concernant les pilotes et les architectures. Cette fois‐ci, nous avons, par exemple, des mises à jour sur les médias._>> _Mais il y a également des corrections majeures pour certaines vieilleries comme les routines_ cpu-idle, _ou encore pour la mise en mémoire de l’horloge pour le nouveau mode_ full NOHZ, _etc. Il y a donc des corrections un peu partout, mais la plupart restent heureusement légères._>> _Allez‐y, testez !_>> _Linus_ #Les nouveautés #Les améliorations ##Cryptographie De nouveaux pilotes pour le coprocesseur ARM Freescale SAHARA 2 _— Symmetric/Asymmetric Hashing and Random Accelerator —_ et le processeur Broadcom BCM2835 RNG (Raspberry Pi) font leur apparition, et les pilotes dédiés aux jeux d’instructions AVX/AVX2 et SSE3 ont été optimisés. En détail : - optimisations du [mode d’opération](http://fr.wikipedia.org/wiki/Mode_d%27op%C3%A9ration_%28cryptographie%29 "Définition Wikipédia") [XTS](http://fr.wikipedia.org/wiki/Mode_d%27op%C3%A9ration_%28cryptographie%29#Xex-Tcb-Cts_.28XTS.29) pour les chiffrements Twofish, CAST6, Camellia et AES sur les architectures x86 ; - implémentations de Blowfish, Twofish, Serpent et Camellia sur x86_64 via AVX2 ; - optimisations de SHA-256 et SHA-512 via les extensions SSSE3, AVX et AVX2 ; - nouveau pilote pour le coprocesseur SAHARA2 ; - nouveau pilote pour le Broadcom BCM2835 RNG ; - correction du code d’authentification de message GMAC dans certains cas d’utilisation hors IPsec ; - ajout d’une implémentation générique du code d’authentification de message [CMAC](http://fr.wikipedia.org/wiki/CMAC "Définition Wikipédia") (incluant IPsec) ; - unification de la prise en charge des différents matériels ATMEL ; - prise en charge des matériels multiples dans `hwrng/timeriomem` ; - diverses corrections. ## ARM ## De nombreux changements de ce nouveau noyau ont concerné les architectures ARM. On peut citer notamment : - la prise en charge du Cortex-A5 Atmel SAMA5D3 ; - la prise en charge du CSR SiRFatlas6 ; - la mise à jour de la plate‐forme Tegra 4 de NVIDIA ; - l’amélioration du multi‐plate‐forme, qui permet à un même noyau de pouvoir fonctionner sur la majorité des plates‐formes, grâce à la grande unification des codes sources entamée dans les précédentes versions du noyau. Les nouveaux matériels pris en charge sont : - le Broadcom BCM2835, - le CNS3XXX, - le Sirf, - le Nomadik, - le MSX, - le Spear, - le NVIDIA Tegra, - et le UX500 ; - la mise à jour du descripteur de matériel [_Device-Tree_](http://www.devicetree.org/) ; - diverses mises à jour. ###AArch64 La prise en charge de l’architecture ARM 64 bits (AArch64) [commencée dans le noyau 3.7](https://linuxfr.org/news/sortie-du-noyau-linux-3-7#toc_11) continue d’être améliorée, bien qu’il ne soit pas prévu d’avoir de matériel avant l’année prochaine. Le système monopuce _Versatile Express_ est maintenant pris en charge, ainsi que les grappes de serveurs multiples _— multi-cluster —_, un _printk_ préliminaire simplifié, des fonctions noyau optimisées, et l’initialisation automatique du contrôleur d’interruptions et des horloges via le descripteur de matériel [Device Tree](http://www.devicetree.org/). À noter que le _Versatile Express_ est le matériel que QEMU envisage d’émuler dans le monde ARM 64 bits. ## Audio ## Le domaine sonore vient se consolider avec une multitude de changements épars : une meilleure prise en charge des microphones et des casques, la compression matérielle de la capture audio pour les matériels qui en sont capables, l’utilisation de délais possible dans les codecs, ou encore la prise en charge du [codec ALC268](http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PFid=27&Level=5&Conn=4&ProdID=140). ## Virtualisation La prise en charge de l’hyperviseur de Microsoft, Hyper-V, a été améliorée. Un nouveau [pilote pour les cartes graphiques virtuelles Hyper-V Synthetic Video](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=68a2d20b79b105f02dcbc52c211d7e62f98996b7) arrive. Il permet une résolution jusqu’à ×ばつ1080 pixels pour un invité GNU/Linux tournant sur Windows Server 2012. L’[ajout à chaud de mémoire vive](http://git.kernel.org/linus/1cac8cd4d146b60a7c70d778b5be928281b3b551) est pris en charge. Enfin, lorsque Windows VSS signale à l’invité qu’une sauvegarde de secours va être faite, Linux intercepte ce [signal](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=96dd86fa588169b745a71aedf2070e80f4943623) et le transmet à un démon en espace utilisateur qui s’assure que les systèmes de fichiers sont cohérents, avant que l’hôte ne fasse la capture. KVM prend en charge la virtualisation imbriquée. Il s’agit d’une fonctionnalité des prochains processeurs Intel appelée _VMCS shadowing_. C’est une fonctionnalité spécifique à certains processeurs qui permet à une machine virtuelle d’avoir accès aux instructions de virtualisation. La virtualisation des contrôleurs d’interruptions programmables (APIC) des processeurs Intel est maintenant fonctionnelle, et permet d’optimiser les performances de la virtualisation des interruptions matérielles à destination des invités. La virtualisation sur architecture MIPS32 est prise en charge par KVM. Celle des architectures PowerPC n’est, elle, pas encore annoncée comme complète. Xen prend désormais en charge la virtualisation sur processeurs ARM [multi‐cœurs](http://git.kernel.org/linus/9a9ab3cc00dc0c338e3ab96f75a0e1a3c1aa3c27). La prise en charge de Xen par QEMU est notable : cela permet d’utiliser _virtio_, SPICE et les formats de disque QEMU par dessus Xen. ## Préemption périodique Si on remonte un peu dans le temps, le noyau gérait les tâches d’une manière très simple : Un tic d’horloge, était envoyé de manière régulière au processeur sous la forme d’une interruption non masquable de fréquence _f_ (disons f = 1 000 Hz). À chaque interruption reçue, le processeur arrêtait la tâche qu’il était en train de traiter et pouvait, par exemple, laisser l’ordonnanceur décider si cette tâche devait être continuée, ou si une autre tâche devait être commencée. L’un des problèmes de cette approche, c’est que l’attente est dite active. En effet, un processeur ne faisant rien, et mis en sommeil, sera toujours réveillé à la fréquence _f_. Il a été décidé, dans un premier temps, de permettre de désactiver ces _tics_ quand le processeur est en veille (avec la variable `CONFIG_NO_HZ_IDLE`). Ceci permet d’économiser de l’énergie, mais tend à augmenter la durée de sortie de veille du processeur. Ce comportement n’est pas forcément intéressant sur un système temps réel, ou pseudo‐temps réel. Dans cette nouvelle version, il est maintenant possible de désactiver les tics avec la variable `CONFIG_NO_HZ_FULL`, dans un cas très précis : lorsqu’un cœur ne traite qu’une seule tâche. Dans les systèmes à haute performance, cela peut s’avérer bénéfique. En réalité, il existe toujours un tic une fois par seconde, mais uniquement à cause de l’ordonnanceur. De plus, c’est un changement qui n’est pour l’instant disponible que pour les architectures x86_64 (bien qu’un correctif soit dans les tiroirs pour le x86). Dans un futur plus ou moins proche, il est prévu de pouvoir se débarrasser complètement de ces interruptions prédéterminées, mais cela demande des changements parfois profonds dans le noyau. À terme, il s’agit d’utiliser des événements pour interrompre un processeur uniquement quand c’est nécessaire. ##Pilotes graphiques pour vos PC ###Intel Chez Intel, les choses avancent, que ce soit pour les générations actuelles ou futures. [_Sandy Bridge_](http://fr.wikipedia.org/wiki/Sandy_Bridge#Famille_Sandy_Bridge "Définition Wikipédia") et [_Ivy Bridge_](http://fr.wikipedia.org/wiki/Sandy_Bridge#Famille_Ivy_Bridge "Définition Wikipédia") bénéficient maintenant d’une prise en charge du surcadencement de meilleure tenue. En effet, la valeur limite du mode *turbo* est correctement détectée. Bien que les choses ne soient pas gérées de la même manière pour l’architecture Haswell, sa prise en charge est au rendez‐vous. La nouvelle version du noyau mettrait également un terme à la nécessité, pour certains, d’utiliser l’option `drm_kms_helper.poll=0`. Si c’est votre cas, vous devriez pouvoir maintenant vous en passer. La mise en veille, ainsi que le retour à la session, se fait maintenant sans passer par une console virtuelle ; [KMS](http://fr.wikipedia.org/wiki/Kernel-based_mode-setting "Définition Wikipédia") l’a rendu inutile. L’apparition fugace d’une console au retour de veille ne devrait être désormais qu’un mauvais souvenir. Les processeurs graphiques d’Intel ne pouvaient être utilisés que pour afficher quelque chose, mais il est maintenant possible de les utiliser sans devoir forcément afficher quelque chose. Ce n’est pas forcément utile au quidam, mais les développeurs peuvent trouver ça intéressant. - __ - __ ###Nouveau (pilote libre pour puces NVIDIA) [Cette nouvelle version du pilote](http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=c8f80213bbb9cd2b1b1d383372d14f6083f2ce1e) apporte la prise en charge du [pavage](https://en.wikipedia.org/wiki/Tiled_rendering) de la mémoire du système hôte. Christoph Bumiller a également ajouté pour [_Fermi_](http://fr.wikipedia.org/wiki/Fermi_%28architecture_de_carte_graphique%29) et [_Kepler_](http://fr.wikipedia.org/wiki/Kepler_%28architecture_de_carte_graphique%29) la prise en charge de la compression des textures dans la mémoire vidéo (VRAM), ainsi que l’ajout d’interfaces avec des instructions logicielles nécessaires pour l’exécution d’un noyau OpenCL/CUDA et la lecture des compteurs de performance. Une prise en charge initiale des GF117 (NVD7) a également été [ajoutée](http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=79198497616d993cc81ac0b5533fa50bb21e0ddf) par Ben Skeggs. Cependant, cette prise en charge n’a pu être testée par l’équipe de développement, par manque de matériel. Si vous possédez cette carte, veuillez contacter l’équipe de _Nouveau_. Malheureusement, peu d’améliorations visibles concernant la gestion de l’énergie sont arrivées dans ce noyau. Ce travail est en cours et requiert encore beaucoup d’ingénierie inverse. La seule nouveauté apportée par ce noyau est l’ajout de la prise en charge de la mesure de température pour les G80, premières cartes de la famille NV50. Les cartes NVA0 restent les seules cartes avec lesquelles il est parfois impossible de lire la température. ###Radeon (pilote libre pour puces ATI/AMD) Pour cette version, la prise en charge des puces _Southern Islands_ (HD 7xxx) est grandement améliorée. En effet, le pilote libre _xf86-video-ati_ est maintenant fonctionnel et gère correctement le pavage bidimensionnel _— 2D tiling —_, que ce soit pour les couleurs ou les textures. Au rang des bonnes nouvelles, on retrouve également la prise en charge du décodage vidéo unifié (VDU), ainsi qu’en VDPAU. Tout cela est possible en mettant à jour le pilote libre, ainsi que _libdrm_. Enfin, il est maintenant possible de décompresser les [textures S3](http://en.wikipedia.org/wiki/S3_Texture_Compression). ### Autres pilotes vidéo Les puces _Tegra_ de Nvidia ont maintenant accès à l’accélération en deux dimensions. Bien entendu, le travail est en cours pour prendre en charge la 3D. Vous aurez besoin, pour l’instant, d’utiliser les branches idoines de Mesa, _libdrm_ et _greta_, le nouveau pilote. Un nouveau pilote est apparu pour une puce émulée par [SPICE](http://en.wikipedia.org/wiki/SPICE_%28protocol%29) (le VNC aux stéroïdes de QEMU). Il permet, pour le moment, d’utiliser la gestion des modes d’affichage par le noyau ([KMS](http://fr.wikipedia.org/wiki/Kernel-based_mode-setting "Kernel‐based mode‐setting")). Il devrait évoluer pour offrir des fonctionnalités 3D. ##Systèmes de fichiers ###Btrfs et ext4 Btrfs est maintenant à même d’enregistrer les méta‐données de manière plus efficace : ses performances sont donc légèrement meilleures. En effet, la taille mémoire a été réduite d’environ 30 % pour un arbre référence. Cependant, ce changement n’est pas rétrocompatible. Pour l’utiliser, c’est simple : `btrfstune -x`, mais il est conseillé de lire le manuel avant de tout casser. ### XFS Une nouveauté expérimentale permet de jouer avec la protection des méta‐données grâce au contrôle de redondance cyclique. Pour ce faire, il faudra utiliser une version à jour de `mkfs.xfs` ; ceci vous permettant alors de créer une partition avec cette propriété activée. Il n’y a pas grand chose d’autre à se mettre sous la dent, si ce n’est quelques améliorations au niveau des entrées‐sorties, et un ré‐usinage du code. ### F2FS Ce système de fichiers expérimental porté par Samsung et conçu pour les mémoires Flash, s’étoffe en proposant un nouveau schéma à verrou global. Le reste n’est que correction d’un code encore jeune, et grandissant. Niveau performances, ce [n’est pas encore forcément significatif](http://www.phoronix.com/scan.php?page=article&item=linux_310fs_fourway&num=1). ##Réseau Concernant la pile réseau du noyau 3.10, la plus grosse nouveauté est l’implémentation de l’algorithme [_Tail Loss Probe_](https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01) destiné à accélérer la reprise lors de la perte d’un paquet à la fin d’une transaction TCP. Cette nouvelle fonction est une contribution des développeurs de Google qui, selon le message de [_commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6ba8a3b19e764b6a65e4030ab0999be50c291e6c), utilise déjà TLP sur ses fermes de serveurs :> _La modification TLP a été testée extensivement sur les serveurs Web de Google. Son efficacité est maximum sur les transactions courtes, pour lesquelles il parvient à réduire les délais de latence des retransmissions TCP de 15 % et à améliorer le temps de réponse HTTP de 6 % en moyenne._ Parmi les autres nouveautés, on note la prise en charge des entrées‐sorties à mémoire associée ([MMIO — Memory‐mapped I/O](http://en.wikipedia.org/wiki/MMIO "Memory‐mapped I/O")) pour l’interface [Netlink](http://en.wikipedia.org/wiki/Netlink). La documentation de cette nouvelle possibilité se trouve dans [ce _commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5683264c3981047aa93eebabcdbb81676018a7c9) et les programmes l’utilisant pourront s’éviter de coûteuses copies de données. Enfin, pour les insatiables du réseau, vous pouvez consulter le [message de David Miller](http://article.gmane.org/gmane.linux.network/268053), mainteneur du sous‐système réseau de Linux, qui récapitule toutes les nouveautés de cette version 3.10 du noyau. #Statistiques En ce qui concerne les statistiques du cycle de développement du noyau 3.10, le site _LWN.net_ a publié son traditionnel [article récapitulatif](http://lwn.net/Articles/555968/). En termes de modifications, c’est un nouveau record absolu qui est établi par ce noyau 3.10. Selon les [chiffres du site _www.remword.com_](http://www.remword.com/kps_result/3.10_petop.html), le total se monte en effet à 13 637 correctifs, alors qu’il était de 11 909 pour le noyau précédent. Un autre record battu est celui du nombre de développeurs différents qui passe de 1 364 pour le 3.9 à 1 448 pour ce noyau 3.10. Greg Kroah‐Hartman s’est d’ailleurs fendu d’un [petit billet sur son blog](http://kroah.com/log/blog/2013/07/01/3-dot-10-kernel-development-rate/) pour mettre en avant un autre chiffre spectaculaire. Comme le noyau 3.10 a intégré un nombre record de modifications et que la période de développement a été assez courte (63 jours), il est normal que le taux de modifications par heure batte lui aussi tous les records. Alors qu’il tournait autour de 7 pour les noyaux précédents, on passe maintenant à 9,02 pour le 3.10. Comme le dit Greg :> _Every year I think we can’t go faster, and every year I’m wrong._ Les trois contributeurs les plus prolifiques de ce cycle sont : - H. Hartley Sweeten et ses 392 modifications portant sur le nettoyage du sous‐système [_comedi_](http://www.comedi.org/ "Control and Measurement Device Interface") (périphériques d’acquisition de données) ; - Jingoo Han qui a écrit 299 modifications visant à améliorer de nombreux pilotes pour qu’ils utilisent des fonctions standardisées comme, par exemple, l’interface de programmation d’allocation de ressources administrée ; - Hans Verkuil est le nouveau mainteneur du sous‐système Video4Linux, et il a fourni 293 modifications pour améliorer et nettoyer les pilotes d’acquisition vidéo. Si l’on regarde le classement des entreprises, Red Hat reprend la première place dérobée par Intel lors du classement précédent (1 207 modifications contre 1 012). Comme le souligne Jonathan Corbet dans l’article de LWN, on peut noter également la continuelle montée en puissance des firmes travaillant dans le mobile et l’embarqué. L’alliance [Linaro](http://fr.wikipedia.org/wiki/Linaro), par exemple, a produit 675 modifications dans cette édition du noyau Linux. Enfin, n’oublions pas que les contributeurs sans affiliation particulière sont quand même devant Red Hat et les autres entreprises, avec un total de 1 495 modifications. C’est aussi un signe de bonne santé d’avoir autant de contributions émanant de volontaires non payés.

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