URL: https://linuxfr.org/news/sortie-du-noyau-linux-3-7 Title: Sortie du noyau Linux 3.7 Authors: antistress baud123, EdB, maboiteaspam, detail_pratique, Batchyx, Yves Bourguignon, Olivier B, Benoît, Christophe Turbout, patrick_g, Davy Defaud, Strash, Akiel, matteli, Florent Zara, Kioob, Martin Peres, Maxime, mike.simonson, _PhiX_, david.g, chtitux, Thomas Debesse, SQP, Sylvestre Ledru, Remus, yogitetradim et Xavier Teyssier Date: 2012年10月03日T02:02:51+02:00 License: CC By-SA Tags: grsecurity, lwn, harald_welte, kernel, linux, noyau_linux et coulisses Score: 91 La sortie de la version stable 3.7 du noyau Linux [vient d’être annoncée](http://article.gmane.org/gmane.linux.kernel/1408240) par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site _kernel.org_. Le détail des évolutions, nouveautés et prévisions (dont un certain nombre concernent les [architectures ARM](http://fr.wikipedia.org/wiki/architecture ARM "Définition Wikipédia")) est dans la seconde partie de la dépêche (qui est sous licence CC BY-SA). _Merci aux participants à la rédaction de cette dépêche : Florent Zara, Christophe Turbout, Sylvestre Ledru, patrick_g, detail_pratique, SQP, baud123, _PhiX__, _Maxime, EdB, Thomas DEBESSE, Yves Bourguignon, Batchyx, Strash, Martin Peres, yogitetradim, Akiel, matteli, mike.simonson, Kioob, david.g, Benoît, Remus, maboiteaspam et obms_ ---- [LWN : Les nouveautés du noyau 3.7](https://lwn.net/Articles/519883/) [The H Open : Coming in 3.7 (Part 1): Filesystems & storage](http://www.h-online.com/open/features/Kernel-Log-Coming-in-3-7-Part-1-Filesystems-storage-1750000.html) [The H Open : Coming in 3.7 (Part 2): Networking](http://www.h-online.com/open/features/Kernel-Log-Coming-in-3-7-Part-2-Networking-1752099.html) [The H Open : Coming in 3.7 (Part 3): Infrastructure](http://www.h-online.com/open/features/Kernel-Log-Coming-in-3-7-Part-3-Infrastructure-1755953.html) [The H Open : Coming in 3.7 (Part 4): Drivers](http://www.h-online.com/open/features/Kernel-Log-Coming-in-3-7-Part-4-Drivers-1757358.html) [The H Open : Coming in 3.7 (Part 5): CPU and platform code](http://www.h-online.com/open/features/Kernel-Log-Coming-in-3-7-Part-5-CPU-and-platform-code-1758293.html) ---- # La phase de test ## RC-1 teintée de scepticisme La version [RC-1](http://lkml.org/lkml/2012/10/14/281) a été annoncée par Linus le 14 octobre 2012 : Les deux semaines sont finies, j'ai fait les fusions pendant mon voyage, donc pas de raison de les prolonger. Le 3.7-rc1 est sorti et il y a quelques gros trucs qui valent le coup d'être mentionnés : - nettoyage des fichiers d'include « UAPI ». L'idée est que ce qui est exporté en espace utilisateur devrait maintenant être trouvé dans include/uapi et arch/$(ARCH)/include/uapi. Espérons que ça finira vraiment par marcher. Parce que sinon c'était juste une merde inutile. De toute façon, je ne veux plus jamais revoir ce genre de nettoyage massif des fichiers d'include. - inclusion de l'architecture arm64 : on verra bien si ça fonctionne... et on verra combien d'années il faudra aux mainteneurs d'arm pour faire ce que chacune des autres architectures 64 bits a déjà fait : refusionner avec le code 32 bits. Comme d'habitude, ils ont affirmé qu'il y avait des tonnes de raisons expliquant que _ce cas_ était différent, et comme d'habitude, tout cela finira se révéler n'être que des c***eries, et dans quelques années nous aurons de gros patches pour tenter de tout refusionner. Mais peut-être était-ce _vraiment_ différent cette fois. Je me marre... - code arm multiplateforme. Enfin ! L'arborescence arm complète (appareils, code, bazar, etc.) signifie qu'au moins quelques noyaux arm peuvent maintenant être compilés pour prendre en charge plusieurs plateformes différentes avec un seul binaire. Je suis sûr qu'il manque encore plein de trucs, mais c'est de toute façon une étape importante. - virtualisation d'arm et gestion de Xen. - les espaces de noms utilisateurs reviennent, et ils fonctionnent. - signature des modules du noyau. - jolis nettoyages : _workqueues_ (Tejun Heo) et les _execve_ / _kernel_thread_ génériques (Al Viro). Il y a des tonnes d'autres mises-à-jour, mais ce qui précède est le plus marquant, parce c'est du lourd et du neuf. J'en rate d'ailleurs peut-être un peu. Évidemment, en sus des nouveautés du dessus, le gros des patches concerne les habituelles mises-à-jour des pilotes — que je n'ai pas évoquées. Donc, les nouveautés marquantes sont en fait plus petites que les habituelles mises-à-jour. Bref, le résumé du journal est bien trop gros, comme toujours pour une rc-1, mais j'ai joint mon résumé des fusions qui donne au moins une idée générale de ce que j'ai pu faire. ## RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure La version [RC-2](http://lkml.org/lkml/2012/10/20/136) a été annoncée par Linus le 20 octobre 2012 : Depuis quelques mois, c'est devenu presque habituel de ma part de publier des versions d'un aéroport alors que je voyage quelque part. Cette -rc n'y échappe pas. Reste libre, petit point d'accès de l'aéroport de Portland ! Bref, ça fait grosso-modo une semaine, donc voici la -rc2. Les trucs les plus notables sont les corrections des problèmes provoqués par la dernière -rc : il y a beaucoup de patches de nettoyage en rapport à la réorganisation des fichiers d'en-tête UAPI, mais aussi quelques changements sur le fonctionnement de la signature des modules. Précisément, la réorganisation d'UAPI (même en détectant les renommages) éclipse tout le reste : les stats de diff sont très inhabituelles. Au lieu du classique « 65% de pilotes et le reste en vrac », on a 50% de patches d'architecture (principalement les fichiers d'en-têtes d'UAPI), 30% de fichiers d'include (encore des fichiers d'en-têtes d'UAPI), et 20% pour tout le reste. Malgré tout, le résumé reste à peu près lisible, parce que les changements d'UAPI ne sont pas effectivement majoritaires, donc rien ne sort du lot. Des changements sur les pilotes DRM et USB, et quelques corrections un peu partout. Testez donc et amusez-vous bien. ## RC3 par un fan d'Highlander La version [RC-3] (http://lkml.org/lkml/2012/10/28/150) a été annoncée par Linus le 28 octobre 2012 : Une semaine est passée, il est temps de sortir la -rc3 ! Rien ne sort particulièrement du lot : beaucoup de petites corrections, avec par exemple les corrections de fuites de mémoire dans les pilotes usb. Beaucoup de changements, sans lien les uns avec les autres. La majorité concerne les pilotes (tous ceux dans : drm, réseau sans fil, staging, usb, son), mais aussi quelques corrections dans les systèmes de fichiers (ntfs, btrfs, ext4), au niveau architectures (arm, x86 et m68k) et des mises-à-jour diverses. Le résumé du journal est joint ci-dessous. En parlant du résumé : mon dieu, certains d ́entre vous ont besoin de changer de prénom. Je suis habitué au fait qu ́il y ait de multiples « David » et « Peter » etc, mais il y a trois « Linus » différents dans cette rc. Les gars, écoutez bien : je veux rester unique comme l'est un flocon de neige, pas juste un autre gars dans la masse. Je vais me chercher une [broadsword](http://fr.wikipedia.org/wiki/broadsword "Définition Wikipédia"). Linus « Il ne peut en rester qu'un » Torvalds. ## RC4 : ext4 corrigé = fin du raffut La version [RC-4] (http://lkml.org/lkml/2012/11/4/151) a été annoncée par Linus le 4 novembre 2012 : Cette semaine a été plutôt calme, donc les gars voici pour vous une jolie petite -rc. Rafael m'a inquiété, pendant un moment, avec ce qui semblait être une régression difficile à déboguer, mais cela s'est avéré être un problème en espace utilisateur, donc tout semble plutôt stable. Les choses semblent totalement normales : la plupart des changements sont des corrections de pilotes, avec une poignée d'autres trucs (client nfs, mises à jour mineures d'architectures et quelques trucs réseau). Les corrections de pilotes concernent à peu près tout : son, carte graphique, interface homme-machine et périphériques d'entrées, bus i2c, réseau. Peut-être le plus important à signaler, à cause du bruit engendré dans certains cercles, la correction concernant _ext4 bitmap journaling_ qui règle ce problème qui a fait tant de boucan. C'est une petite correction et malgré tout ce raffut, vous ne pouviez être confronté à ce bogue, à moins d'avoir fait des choses insensées, en utilisant des options de montage spéciales. Autre chose ? Rien de particulier ne ressort. Le résumé ci-joint donne un aperçu raisonnable sur le détail de ce sur quoi les gens travaillent. Je voyagerai la semaine prochaine, mais je pense avoir un accès wifi correct et, si ça reste aussi calme, personne ne s'en rendra compte. Allez-y et testez. ## RC5 : Linus voyage dans le temps et l'espace La version [RC-5](http://lkml.org/lkml/2012/11/11/87) a été annoncée par Linus le 11 novembre 2012 : Une autre semaine vient de passer (modulo les différences de timezone), donc la rc5 est là. Je suis heureux de constater que c'est plutôt une petite rc. La rc4 était déjà plutôt calme et cette rc5 a encore moins de commits. Plus important, à part un _revert_ et une mise a jour du pilote pnctl, c'est non seulement un petit nombre de commits, mais ils sont pour la plupart d'une seule ligne. Les stats de diff semblent plutôt jolies et homogènes. Les mises à jours sont : - architecture (sparc, arm/arm64 et s390) - pilotes (drm, mmc, net, pinctrl, hid, sound, hwmon, pci) - divers (net, akpm, xen, virtio, mudles et crypto) - systèmes de fichiers (gfs2, xfs et cifs) Mais c'est réellement petit. Le résumé du journal est joint ci-dessous. S'il vous plait, testez - Bien que j'espère que c'est calme parce que les choses sont sur une bonne voie - je voudrais que ce soit vérifié. ## RC6 : Jusqu'ici tout va bien La version [RC-6](http://lkml.org/lkml/2012/11/16/681) a été annoncée par Linus le 16 novembre 2012 : Légèrement moins d'une semaine, mais comme je pars en vacances demain, la voilà. Les choses continuent d'être calmes. Nous avons quelques commits de plus que dans la -rc5, mais pas assez pour m'inquiéter, et la plupart des changements sont vraiment minuscules. En outre, les quelques commits qui ne sont pas d'une ligne (ou de quelques lignes) ont tendance à être des retours en arrière (par exemple le ré-ajout de `/proc//oom_adj`) ou des choses assez obscures (la fonction MIPS `irqflags`). Donc, nous avons quelques mise à jour d'architectures (principalement mips et unicore32, avec une poignée de arm[64] et s390) et changements sur les pilotes (son, net, usb). Avec quelques corrections réseau et mm. Le shortlog ci-joint donne un aperçu du genre de choses qui se sont produites, ce n'est pas vraiment très excitant, mais c'est assez court pour être lu entièrement et donner une vague idée. J'aurais un ordinateur portable avec moi pendant mon voyage, mais si tout se calme encore plus, je serais content. Je ferais bien une -rc7, mais en considérant combien tout cela a été calme, je soupçonne que c'est la dernière -rc. À moins que quelque chose de dramatique ne se produise. ## RC7 : Garçon, une autre ! La version [RC-7](http://lkml.org/lkml/2012/11/25/126) a été annoncée par Linus le 25 novembre 2012 : Une semaine plus tôt, j'avais même envisagé de zapper la -rc7 tellement tout était calme mais j'ai finalement décidé qu'il n'y a avait aucune raison à se dépêcher de sortir cette version. Comme j'avais tristement raison. La -rc7 est maintenant disponible, et elle n'est pas vraiment plus petite que les précédentes versions, bien au contraire. Pour une raison que j'ignore, la prise en charge des unités de stockage _block layer_ est apparue sur le radar et les modules md, scsi, mais aussi la couche générique sont concernés par ces changements. C'est donc certain : nous voulons une autre semaine de test ; heureusement, tout cela est vraiment solide. Quelques changements corrigent les systèmes de fichiers (reiserfs, xfs et ext3), ainsi que d'autres mises à jours de pilotes (sound, networking and drm). Shortlog ajouté. Déballez le paquet et testez le. ## RC8 : Linus frappé par l'esprit de Noël ? La version [RC-8](http://lkml.org/lkml/2012/12/3/444) a été annoncée par Linus le 3 décembre 2012 : Je ne voulais pas en arriver là, mais j'étais mal à l'aise hier de sortir la 3.7 en raison de problèmes de dernière minute, et j'ai décidé de ne pas me précipiter. Et aujourd'hui, je me sens encore moins à l'aise, à cause du retour d'un problème dans kswapd. J'ai donc finalement décidé de livrer une nouvelle -rc. Ce n'est pas très pratique au niveau des dates, car cela signifie que la prochaine période de fusions interviendra à une date très proche de Noël. Cela devrait au moins motiver les gens à m'envoyer les changements au plus tôt et à ne pas attendre la dernière minute. Ça serait chouette. Et puisque je décale tout d'une semaine, je serais très méchant si quelqu'un décide de m'envoyer des modifications à un moment aussi tardif du processus qui n'auraient pas pour but de résoudre des problèmes majeurs. Si vous m'envoyez des petits patches qui ne corrigent pas des problèmes majeurs (plantages, failles de sécurité...), je vais vous maudire et ignorer votre demande. Alors ne le faites pas. La seule chose que je souhaite voir, ce sont des patches qui corrigent des problèmes critiques. Dans le cas contraire, ou si aucun retour utilisateur ne motive votre patch, posez le devant le sapin et attendez la version 3.8. (Bon, tandis que j'écris ça je reçois une de ces demandes de modification qui me fait penser "nous n'avons pas vraiment besoin de ça". Je vais l'inclure parce que, techniquement, elle est arrivée avant que je n'envoie cet avertissement, mais...). # Les nouveautés ## ARM SoC multi-platform La grande diversité des plateformes à base d'[architecture ARM](http://fr.wikipedia.org/wiki/architecture ARM "Définition Wikipédia") est une force de cet écosystème, mais c'est aussi une source de complexité lorsqu'il s'agit d'implémenter leur prise en charge logicielle. Jusqu'à présent, chaque architecture ARM nécessitait de compiler une version du noyau spécifique, à l'inverse de ce qui se passe avec les autres architectures (à quelques exceptions près : versions 32/64 bits dans le monde x86 par exemple). Une première implémentation de la [branche _ARM soc multi-platform_](https://lwn.net/Articles/496400/) vient d'[être introduite](https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9cd11c0c47b8690b47e7573311ce5c483cb344ed), destinée à être complétée ultérieurement. Elle permet la prise en charge de différentes plateformes ARM avec une seule et même version compilée du noyau, ce qui est un gros progrès. Il faut en effet savoir qu'avec une architecture x86, le noyau peut se lancer et demander au matériel de s'identifier, alors que les matériels ARM n'ont pas cette capacité et qu'il faut donc préalablement configurer le noyau pour un matériel donné. Le travail réalisé consiste à sortir la description du matériel du noyau et à la reporter dans un fichier texte qui lui sera transmis lors du démarrage par le [chargeur d'amorçage](http://fr.wikipedia.org/wiki/chargeur d\'amorçage "Définition Wikipédia"), permettant de réaliser des versions du noyau beaucoup plus polyvalentes. Les plateformes actuellement prises en charge sont les suivantes : Highbank, Vexpress, Mvebu, Socfpga and Picoxcell. ## AArch64 (ARM64) Jusqu'à présent les architectures ARM sont des architectures RISC 32 bits (dites AArch32). La [société ARM](https://fr.wikipedia.org/wiki/ARM_%28soci%C3%A9t%C3%A9%29 "Définition Wikipédia") et ses partenaires ayant des vues commerciales sur le marché des serveurs, très gourmands en mémoire, une version 64 bits (ARMv8) se concrétisera en 2014 avec [la série des processeurs Cortex-A50](http://www.h-online.com/open/news/item/ARM-introduces-Cortex-A53-and-Cortex-A57-64-bit-processor-cores-1740889.html) (que [les Cortex-A53 et Cortex-A57](http://www.arm.com/about/newsroom/arm-launches-cortex-a50-series-the-worlds-most-energy-efficient-64-bit-processors.php) inaugureront). Préparant ce lancement, [Catalin Marinas de la société ARM a proposé](http://www.phoronix.com/scan.php?page=news_item&px=MTEzNDg) les modifications nécessaires pour permettre au noyau de gérer cette nouvelle architecture, dite AArch64. Debian [souhaite de son côté](http://www.phoronix.com/scan.php?page=news_item&px=MTEzODI) intégrer cette fonctionnalité à _Jessie_, le successeur de _Wheezy_ (qui elle-même devrait succéder à _Squeeze_ début 2013). ## Xen pour processeurs ARM [Selon indexel.net](http://www.indexel.net/actualites/virtualisation-xen-fonctionnera-bientot-sur-les-processeurs-arm-3480.html), il s'agit là de la confirmation de « deux tendances lourdes de l'industrie informatique : l'intérêt croissant des fabricants de serveurs pour les processeurs basse consommation et l'arrivée imminente de la virtualisation sur les terminaux mobiles ». C'est à [Citrix Systems](http://fr.wikipedia.org/wiki/Citrix Systems "Définition Wikipédia") [que l'on doit](https://lkml.org/lkml/2011/11/29/265), au terme de plus d'un an de développement, le portage de l’hyperviseur [Xen](http://fr.wikipedia.org/wiki/Xen "Définition Wikipédia") pour processeurs ARM Cortex A15, à partir des fonctions liées à la virtualisation introduites avec l’architecture ARMv7... En attendant la prise en charge des architectures ARMv8 et ARM 64 bits. Samsung mène de son côté le projet [Xen ARM Project](http://www.xen.org/products/xen_arm.html), un projet de paravirtualisation qui ne repose pas sur les extensions de virtualisation ARMv7 et prendra en charge les architectures ARMv5 et ARMv6. ## SoC ARM Freescale i.MX (DragonBall MX) Toujours du côté des architectures ARM, un nouveau pilote graphique KMS [offre](http://www.phoronix.com/scan.php?page=news_item&px=MTEyMDU) la prise en charge des [SoC ARM Freescale](https://en.wikipedia.org/wiki/I.MX "Définition Wikipédia") i.MX51 et i.MX53 (à base de Cortex-A8 – le premier des deux étant un [SoC](http://fr.wikipedia.org/wiki/SoC "Définition Wikipédia") bas de gamme destiné aux netbooks fonctionnant sous Google Chrome OS notamment), voire i.MX6 (à base de Cortex-A9). ## Supervisor Mode Access Prevention (Intel Haswell) La gestion du [SMAP _(Supervisor Mode Access Prevention)_](https://lwn.net/Articles/517475/) a été ajoutée pour les futurs microprocesseurs Intel (famille _Haswell_, prévue pour 2013) : il s'agit d'une fonctionnalité hardware qui déjoue, au prix d'un léger impact sur les performances, les accès non désirés aux données en espace utilisateur à partir du mode superviseur. Cette fonction s'ajoute aux deux précédentes : XD _(Execute-Disable)_ qui a été introduite avec les AMD Athlon 64/Opteron puis reprise dans les derniers Intel Pentium 4 _Prescott_, et [SMEP](http://linuxfr.org/news/le-noyau-linux-est-disponible-en-version%C2%A030#toc_22) _(Supervisor Mode Execution Prevention)_ qui a été introduite avec les derniers processeurs Intel (famille _Ivy Bridge_). Les développeurs de [PaX](http://fr.wikipedia.org/wiki/PaX "Définition Wikipédia") (un patch externe applicable sur le noyau Linux et qui vise justement à protéger les zones mémoires contre diverses attaques, que nous [avions récemment évoqué ici](http://linuxfr.org/users/patrick_g/journaux/les-performances-d-un-noyau-avec-le-patch-pax)) ont [donné leur avis](https://forums.grsecurity.net/viewtopic.php?f=7&t=3046) sur cette fonctionnalité, avec, en conclusion : « Intel implémente l'équivalent de UDEREF 6 ans après PaX, PaX l'utilisera sur amd64 pour des performances améliorées »... ## MODSIGN (sécurisation des modules complémentaires du noyau) La possibilité de charger des modules complémentaires d'un noyau en train de fonctionner est une fonctionnalité très pratique. Elle autorise les distributions à inclure des noyaux de plus petite taille qui pourront quand même prendre en charge une grande quantité de matériel par ce biais. Cette technique pose toutefois une difficulté : comment garder le contrôle des modules chargés ? Il pourrait s'agir d'un [blob](http://fr.wikipedia.org/wiki/Binary_large_object "Définition Wikipédia") que la distribution ne souhaite pas supporter, voire d'un logiciel malveillant... Il est désormais possible de compiler le noyau de telle sorte [qu'il n'accepte que les modules signés](https://lwn.net/Articles/470906/). David Howells, pour le compte de [Red Hat](http://fr.wikipedia.org/wiki/Red Hat "Définition Wikipédia"), a proposé cette fonctionnalité que l'arrivée prochaine du [_secure boot_](http://fr.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Lancement_s.C3.A9curis.C3.A9_.28secure_boot.29 "Définition Wikipédia") (que Fedora 18 [prendrait en charge](http://jwboyer.livejournal.com/44787.html)) rend d'une actualité brûlante. Deux nouvelles options de configuration du noyau sont introduites : `CONFIG_MODULE_SIG` et `CONFIG_MODULE_SIG_FORCE`. La première autorise la prise en charge des modules signés proprement dite : les modules seront signés lors de la compilation et le noyau vérifiera les signatures lors du chargement des modules. Les signatures peuvent utiliser les algorithmes de cryptographie [SHA-1](http://fr.wikipedia.org/wiki/SHA-1 "Définition Wikipédia"), [SHA-224](http://fr.wikipedia.org/wiki/SHA-224 "Définition Wikipédia"), [SHA-256](http://fr.wikipedia.org/wiki/SHA-256 "Définition Wikipédia"), [SHA-384](http://fr.wikipedia.org/wiki/SHA-384 "Définition Wikipédia") et [SHA-512](http://fr.wikipedia.org/wiki/SHA-512 "Définition Wikipédia"). Avec la deuxième, le chargement d'un module ne sera autorisé que s'il utilise une clé spécifique du noyau. ## Wii Balance Board (\^_\^) Après le [Kinect de la Xbox 360](https://linuxfr.org/users/kirikouu/journaux/driver-libre-pour-kinect) et la [Wiimote](http://www.bluez.org/gsoc-nintendo-wii-remote-device-driver/), c'est au tour de la [Wii Balance Board](http://fr.wikipedia.org/wiki/Wii Balance Board "Définition Wikipédia") (que l'on trouve dans le célèbre pack Wii Fit) de se voir offrir l'honneur d'une [prise en charge par le noyau](https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9fa40a1135d94cb6eed99e264c6d4fe00c0a73f9) (au moyen d'une modification du pilote Wiimote). David Herrmann ([blogue](https://dvdhrm.wordpress.com/), [github](https://github.com/dvdhrm)), à l'origine de la prise en charge de la Wiimote comme de la Wii Balance Board, [explique](http://www.mail-archive.com/linux-input@vger.kernel.org/msg01340.html) : « la Nintendo Balance-Board est un contrôleur qui se comporte exactement comme la Wiimote, mais qui transmet ses données via une extension. Nous pouvons donc simplement ajouter la Balance-Board à la façon d'une extension pour obtenir une prise en charge complète ». ## Oracle SPARC T4 Le processeur [SPARC T4](http://fr.wikipedia.org/wiki/en:SPARC T4 "Définition Wikipédia") (alias _Niagara 4_) lancé par Oracle en 2011 est désormais pris en charge. Le T4 est le dernier rejeton de la famille de processeurs SPARC développée par Sun Microsystems, qu'Oracle a repris en 2010. Il s'agit d'une puce RISC octocœurs, chaque cœur gérant huit _threads_. Pour mémoire, le T3 possédait deux fois plus de cœurs mais ceux-ci étaient moins rapides (1,65 GHz maximum pour le T3 contre 2,85 GHz ou 3 GHz pour le T4, suivant les serveurs). En outre, des optimisations conféreraient au T4 des performances mono-thread cinq fois supérieures à son prédécesseur. Le T5, qui [devrait être annoncé prochainement](http://www.silicon.fr/power7-sparc-t5-ibm-oracle-risc-78194.html), serait, lui, un processeur à 16 cœurs. Un rappel qui intéressera sans doute nos lecteurs : l'[architecture SPARC](http://fr.wikipedia.org/wiki/architecture SPARC "Définition Wikipédia") a été introduite par Sun Microsystems mi-1987, mais c'est une marque de SPARC International, regroupant notamment Oracle et Fujitsu, et qui préside aux évolutions de l'architecture. Les spécifications de celle-ci sont entièrement libres, ce qui autorise la création par quiconque de [processeurs compatibles](http://www.sparc.org/ads/chips.html). La dernière version de l'architecture est ainsi la SPARC V9, apparue vers 1994 et qui marque le passage au 64 bits. Les processeurs SPARC T3 et T4 actuellement commercialisés par Fujitsu ou Oracle par exemple implémentent cette architecture. # Les améliorations ## Pilotes graphiques pour vos PC Avec cette version du noyau, [Intel](http://intellinuxgraphics.org/team.html) comme [Nouveau](https://fr.wikipedia.org/wiki/Nouveau_%28informatique%29 "Définition Wikipédia") posent les bases pour des développements futurs qui devraient être intéressants. ### Intel Du côté d'Intel pour commencer, outre la poursuite de l'implémentation de la gestion des prochains processeurs _Haswell_ (successeurs _d'Ivy Bridge_) et _Valley View_ (SoC à base de processeur Atom) – qui utilisent tous deux un cœur graphique de même génération que celui équipant les actuels processeurs [_Ivy Bridge_](http://fr.wikipedia.org/wiki/Sandy_Bridge#Famille_Ivy_Bridge "Définition Wikipédia") (Gen7) – et diverses améliorations sur les architectures existantes, on signalera surtout l'importante réécriture du code gérant les modes d'affichage _([mode-setting](http://fr.wikipedia.org/wiki/Kernel-based_mode-setting "Définition Wikipédia"))_ afin d'améliorer la gestion des interfaces [DisplayPort](http://fr.wikipedia.org/wiki/DisplayPort "Définition Wikipédia"). Ce travail permettra à l'avenir d'autres améliorations comme le projet _Fastboot_ qui – comme son nom ne l'indique pas – évite le désagrément visuel des changements de résolutions successifs au démarrage, en prenant le contrôle de l'affichage tout de suite après le BIOS ou le [chargeur d'amorçage](http://fr.wikipedia.org/wiki/chargeur d\'amorçage "Définition Wikipédia" "Définition Wikipédia") (une arlésienne du monde Linux). Suite à l'annonce de ces changements sur son blogue, Daniel Vetter ([blogue](http://blog.ffwll.ch/)) a dû se justifier auprès des *BSDistes en colère qui craignaient que les 18 mois passés à porter l'ancien code n'aient servi à rien. Au final, [la situation ne serait pas aussi désolante a-t-il expliqué](http://blog.ffwll.ch/2012/08/new-modeset-code.html?showComment=1345839928596#c4448264265793442335), la base du code n'étant pas touchée. Également, après avoir été activé sur _Ivy Bridge_ (Gen7, Linux 3.2) puis _Sandy Bridge_ (Gen6, Linux 3.4), le mode RC6 (mode de gestion d'énergie qui passe en veille profonde la partie graphique du processeur en cas d’inactivité) est activé pour les processeurs [_Clarkdale_](https://fr.wikipedia.org/wiki/Clarkdale_\(processeur\) "Définition Wikipédia") et [_Arrandale_](https://fr.wikipedia.org/wiki/Arrandale "Définition Wikipédia") (tous deux équipés d'un cœur graphique Gen5 _Ironlake_). ### Nouveau (pilote libre pour puces Nvidia) En parlant de réécriture, difficile de ne pas évoquer le travail de réécriture d'une large portion du code de Nouveau par Ben Skeggs ([Live Journal](http://airlied.livejournal.com/), [Google+](https://plus.google.com/109430210070297725121/posts)) pour le compte de Red Hat (des milliers de lignes de code ont été changées à cette occasion). Ne vous attendez pas pour autant à des nouveautés extraordinaires en termes de fonctionnalités ou de performance, du moins à ce stade. Il s'agit avant tout d'un travail de restructuration du code à partir de l'expérience accumulée ces dernières années et qui facilitera les développements futurs, comme l’amélioration de la gestion de l'énergie en permettant d'identifier plus facilement les parties du GPU actives ou non à un moment donné, ou l'implémentation du [SLI](https://fr.wikipedia.org/wiki/Scalable_Link_Interface "Définition Wikipédia"). Ce travail fait, Ben Skeggs s’attelle à présent à la gestion de la fréquence de la puce (une autre façon d'optimiser la gestion de l'énergie) et à celle des modes d'affichage, de sorte que nous devrions voir le résultat de ce travail prochainement. De son côté, Martin Peres alias mupuf ([blogue](http://www.mupuf.org/), [page recherche](http://phd.mupuf.org/), [Google+](https://plus.google.com/108010086967233476835/posts)), doctorant au Laboratoire Bordelais de Recherche en Informatique (LaBRI), œuvre également sur la gestion de l'énergie (pour _therm_ et _fanctrl_) et a introduit un mécanisme de contrôle rudimentaire du ventilateur, à deux positions : AUCUN et MANUEL. Comme leurs noms l'indiquent, le premier signifie que le pilote n’intervient pas et le second permet à l'utilisateur de définir la vitesse de rotation et ainsi de soulager ses oreilles. Il s'agit d'une première étape vers la [gestion automatique du ventilateur](http://cgit.freedesktop.org/nouveau/linux-2.6/tree/Documentation/thermal/nouveau_thermal) qui devrait être introduite dans Linux 3.8. Pour en savoir plus, n'hésitez pas à lire [le passionnant entretien](https://linuxfr.org/news/entretien-avec-martin-peres-developpeur-nouveau) qu'il a récemment donné dans nos colonnes (vous y découvrirez également comment le projet Nouveau est organisé). Linux 3.1 avait vu Ben Skeggs [triompher](http://www.phoronix.com/scan.php?page=news_item&px=OTQ4NA) du microcode des puces [_Fermi_](https://fr.wikipedia.org/wiki/Fermi_%28architecture_de_carte_graphique%29 "Définition Wikipédia") : dorénavant Nouveau ne dépendrait plus du microcode non-libre de Nvidia pour ces puces. [Cette fois](http://www.phoronix.com/scan.php?page=news_item&px=MTE4MTI) c'est le microcode des puces [_Kepler_](https://fr.wikipedia.org/wiki/Kepler_%28architecture_de_carte_graphique%29 "Définition Wikipédia") que Ben Skeggs a réussi à libérer ! C'est important car cela permet d'avoir ces cartes immédiatement fonctionnelles dans nos distributions, sans avoir à intégrer des morceaux de code non-libres dont la redistribution peut être soumise à condition. Ce travail n'est cependant pas encore terminé, car l'utilisation d'applications OpenGL telles que gnome-shell est encore très instable. ### Radeon (pilote libre pour puces ATI/AMD) Les [principales nouveautés](http://lists.freedesktop.org/archives/dri-devel/2012-October/028481.html) sont : - La série des Radeon HD 6900, nom de code [Cayman](http://en.wikipedia.org/wiki/Northern_Islands_\(GPU_family\)#Radeon_HD_6900), utilise désormais une mise à jour asynchrone des pages de table de la Mémoire Virtuelle - Gestion d'une page de table à 2 niveaux pour économiser encore un peu plus de mémoire. - Gestion des [PLL](http://fr.wikipedia.org/wiki/Boucle_%C3%A0_phase_asservie) améliorées. Lorsqu'au moins deux écrans partageant une PLL compatible sont connectés, le système n'utilisera désormais plus qu'une seule horloge pour gérer les multiples affichages. Ceci afin d'optimiser la gestion de la batterie. - Gestion native du rétroéclairage pour les systèmes [ATOMBIOS](http://phoronix.com/forums/showthread.php?7032-What-Is-AtomBIOS-amp-These-Different-Drivers&p=20922#post20922). - Gestion [ACPI](http://fr.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface) améliorée pour mieux interagir avec le GPU. - La fonction de rétroéclairage est corrigée sur certains ordinateurs portables. - Documentation des interfaces ACPI d'AMD - Nettoyage de code et corrections de bugs. ## Systèmes de fichiers ### Btrfs Les [modifications clés](http://lkml.indiana.edu/hypermail/linux/kernel/1210.1/01108.html) pour cette version 3.7 de Linux concernent notamment la nouvelle technique _hole punching_ (comme EXT4 et d'autres systèmes de fichiers auparavant, Btrfs peut désormais désallouer les blocs mémoires d'un fichier : cette technique de « perforation » est intéressante notamment pour les logiciels de virtualisation, en leur permettant de désallouer l'espace mémoire occupé par un fichier supprimé depuis un hôte – voir le commit de Chris Mason ["add hole punching"](https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2aaa66558172b017f36bf38ae69372813dedee9d)), des corrections du code _send/receive_ qui a été introduit avec la [version précédente du noyau](http://linuxfr.org/news/sortie-du-noyau-linux-3-6#toc_12) (cette fonction donne la possibilité aux programmes de l'espace utilisateur de réaliser une différence entre deux _snapshots_, de sauvegarder celle-ci dans un fichier et d'effectuer des opérations de restauration ; cette fonctionnalité est particulièrement intéressante pour la réalisation de backup incrémental, atomique), des performances améliorées pour fsync (spécialement pour les machines virtuelles installées sur une partition Btrfs – voir le commit de Chris Mason ["turbo charge fsync"](https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5dc562c541e1026df9d43913c2f6b91156e22d32) – mais cela ouvre aussi la voie à d'autres améliorations de performance comme celle concernant les écritures synchrones : voir le commit de Chris Mason ["improve fsync by filtering extents that we want"](https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4e2f84e63dc138eca91e89ccbc34f37732ce58f7)) et, enfin, une augmentation du nombre de liens durs pointant vers un même fichier (il est désormais possible d'avoir non plus 20, mais jusqu'à 65 536 liens durs pointant vers un même fichier). ### Ext4 Laissons la parole à [Theodore Ts'o](http://fr.wikipedia.org/wiki/Theodore Ts\'o "Définition Wikipédia"), lui-même, pour [évoquer](http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/03434.html) les modifications apportées à son bébé (propos traduits par nos soins) :>La grosse nouveauté ajoutée cette fois-ci est la gestion du redimensionnement à la volée via la fonctionnalité meta\_bg ([_metablock group feature_](http://linuxsoftware.co.nz/wiki/ext4#meta_bg_.28META_BG.29)). Cela nous permet de redimensionner les systèmes de fichiers de taille supérieure à 16 To. En outre, d'une manière générale, la vitesse du redimensionnement à la volée s'en trouve accrue. Nous avons aussi corrigé un certain nombre de concurrences critiques, dont certaines pouvaient aboutir à un interblocage, dans les entrées/sorties asynchrones d'ext4 et la défragmentation à la volée, grâce au bon travail de Dmitry Monakhov. Il y a aussi eu la correction d'un grand nombre de bogues mineurs et un nettoyage du code réalisé par d'autres contributeurs de ext4, dont un bon nombre soumettait des corrections pour la première fois. En marge des modifications prévues, il y a celles qui n’étaient pas prévues... Un bogue du système de fichiers dans la version 3.6 du noyau a fait s'allumer beaucoup de pixels sur les écrans alors que celui-ci ne survient que dans certaines conditions particulières et rares, et [avec des options expérimentales activées](https://plus.google.com/117091380454742934025/posts/f5a1eHxUzSh). Rassurez-vous ce bogue a été débusqué et [corrigé](https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8c673cbc7682b3f2862fe42f8069cac20c09e160) dans cette version et vous pouvez à présent remettre le niveau d'alerte sur [DEFCON](http://fr.wikipedia.org/wiki/DEFCON "Définition Wikipédia") 4 ou 5. Ce bogue aura au moins permis de faire un peu d'humour puisque Theodore Ts'o l'a dénommé « le bogue _Lance Armstrong_ » compte tenu de sa caractéristique : [bloquer les alertes, malgré un comportement anormal](http://www.lemondeinformatique.fr/actualites/lire-quand-lance-armstrong-perturbe-le-noyau-linux-51023.html). ## ALSA Les [nouveautés](http://www.gossamer-threads.com/lists/linux/kernel/1609870?do=post_view_threaded) consistent en quelques nouvelles fonctionnalités pour les pilotes audio incluant des optimisations de la consommation électrique à la volée : - la plupart des pilotes audio utilisent la nouvelle API d'économie d'énergie ; le très courant pilote audio HD sait à présent optimiser la consommation électrique à la volée (l'option power_save de sysfs peut aussi être utilisée manuellement à cet effet), la gestion de la consommation électrique à la volée du pilote ALSA HDA est améliorée ; - le pilote audio HD a vu son code de chargement de firmware réécrit ; - nouveaux pilotes pour Wolfson Microelectronics Bells, Wolfson Microelectronics WM0010 et DA9055. ## Réseau Les [nouveautés](https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=aecdc33e111b2c447b622e287c6003726daa1426) sont ici assez nombreuses : ### Gestion du NAT en IPv6 À l'origine, la position de l'ancien mainteneur de netfilter, Harald Welte, était [qu'il faudra lui passer sur le corps avant que la gestion du NAT en IPv6 soit intégrée](http://marc.info/?l=netfilter-devel&m=106933593502369&w=2). Les temps ont changé depuis, et Harald Welte n'est plus le mainteneur en chef de netfilter. Depuis, une certaine variante de NAT IPv6 a été normalisée par l'IETF dans la RFC6296, qui résolvait une partie des problèmes que posait le NAT en IPv4. La [position de Harald Welte s'est assouplie](http://lwn.net/Articles/452854/), et c'est finalement Patrick McHardy, le mainteneur en chef actuel, qui fournira l'implémentation du NAT IPv6, [après qu'il a été admis](http://lwn.net/Articles/468671/) par l'équipe de développement qu'il y avait des cas d'utilisation légitimes, et qu'avoir une seule implémentation était préférable. Ces patches n'implémentent pas que la RFC6298, mais aussi le NAPT tel qu'il est utilisé en IPv4. Inutile de préciser que, avant même que la [série de patches soit intégrée dans la branche principale](http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=aecdc33e111b2c447b622e287c6003726daa1426), celle-ci a déjà provoqué de vives réactions, notamment à [l'IETF](http://www.ietf.org/mail-archive/web/ietf/current/msg70744.html). ### TCP Fast Open côté serveur Alors que la gestion de _TCP Fast Open_ côté client (celui qui initie la connexion) est déjà intégrée dans le noyau [Linux 3.6](http://linuxfr.org/news/sortie-du-noyau-linux-3-6#toc_10), la gestion côté serveur a été intégrée dans ce noyau 3.7. Pour rappel, le but de TCP Fast Open est de réduire le temps de connexion lors d'une ouverture de session TCP, en utilisant une poignée de main (en anglais : _handshake_) à deux paquets au lieu de trois. Pour cela, un cookie doit être échangé entre le client et le serveur lors d'une poignée de main précédente. ### VXLAN Bien que VXLAN soit encore à l'[état de brouillon](http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02) à l'IETF, le noyau 3.7 gère maintenant ce protocole. VXLAN est un moyen de déployer un réseau virtuel prenant en charge les VLAN, au-dessus d'un réseau IPv4 classique. VXLAN permet d'utiliser jusqu'a 16 millions de VLAN différents, au lieu des 4094 VLAN traditionnels. Cela est intéressant pour les opérateurs de clouds, car ils isolent souvent leurs clients entre-eux, en les mettant sur des VLAN différents et sont gênés lorsque le nombre de clients à servir dépasse 4094, surtout lorsque certains clients demandent plusieurs VLAN. Enfin, le fait que VXLAN soit au-dessus d'un réseau IP permet d'alléger la charge qui pèse sur les switchs, qui n'ont plus à gérer les adresses des machines virtuelles, le routage étant déporté au niveau des hôtes, à une couche au dessus d'IP. ### Autres améliorations réseau Quelques améliorations sur les espaces de noms réseau ont été intégrées dans le noyau 3.7 : l'implémentation du protocole SCTP et le commutateur virtuel openvswitch tiennent maintenant compte de ces espaces réseau. Rappelons que les espaces de noms réseau permettent de créer une pile réseau virtuelle afin d'isoler certaines interfaces ou configurations réseau, pour ne les rendre disponibles qu'à certains processus. Cela est notamment utilisé dans les conteneurs lxc. L'implémentation des tunnels GRE a également subi quelques améliorations : il est maintenant possible d'utiliser IPv6 dans les tunnels GRE, et les interfaces GRE gèrent maintenant le _Generic Receive Offload_, qui permet de grouper des paquets similaires afin de factoriser le traitement de ces paquets. Enfin, en bref, le filtre BPF gère maintenant les opérations modulo et XOR, le MTU par défaut de l'interface `lo` passe de 16 Kio à 64 Kio, la gestion de la mémoire utilisée pour stocker les données des paquets a été optimisée et le module `team`, l'évolution à long terme du _bonding_, gère maintenant les interfaces non-ethernet, comme par exemple les tunnels IP. ## Perf perf, le sous-système d'évaluation des performances et ses outils ont reçu d'importantes améliorations avec ce nouveau noyau Linux 3.7. Ingo Molnar rapporte lors de sa demande d'inclusion que plus de 30 contributeurs ont pris part aux centaines de _[commits](http://fr.wikipedia.org/wiki/commit "Définition Wikipédia")_. La majeure partie de ces changements concerne les outils d'analyse. Les améliorations les plus notables de cette version 3.7 concernent un nouvel outil d'analyse perf kvm, un outil d'enregistrement des performances de l'ensemble du système, corrections d'UProbes, possibilité de compiler perf pour les systèmes Android, la fonction ftrace est étendue pour devenir dynamique, les performances de perf sont améliorées, support de l'analyse des événements par groupe, et plus encore. Beaucoup d'améliorations concernent l'infrastructure du sous-système perf de Linux, comme souligné par la demande d'inclusion. ## UAPI : Éclatement des fichiers d'en-tête UAPI est l'acronyme de _Userspace API_ ([API](http://fr.wikipedia.org/wiki/Interface_de_programmation) étant lui-même un acronyme). Cette modification, que l'on doit à David Howells (travaillant pour Red Hat et à qui l'on doit également la sécurisation des modules complémentaires du noyau évoquée ci-dessus), vise à séparer plus finement les fichiers d'en-tête (en anglais : _header_) du noyau, entre ceux à destination de l'espace utilisateur et ceux à usage interne uniquement. Cette modification permet de résoudre le problème d'en-tête incluant un en-tête qui inclut le premier en-tête (problème dit du _header spaghetti_) et qui empêchait David Howells de pouvoir marquer certaines fonctions `inline` (mot clé en C permettant de remplacer l'appel d'une fonction par le corps de celle-ci, pour gagner en performance). Cette tâche étant colossale (583 fichiers modifiés pour 32928 insertions et 30367 suppressions), sa réalisation a été automatisée à l'aide de scripts sur lesquels a porté en fait le plus gros du travail. À condition de maîtriser l’anglais, vous pourrez obtenir de plus amples informations à ce sujet sur [LWN](https://lwn.net/Articles/507794/). C'est la deuxième grosse modification des en-têtes du noyau, après celle de la [version 3.4](http://linuxfr.org/news/sortie-officielle-du-noyau-linux-3-4#toc_1), qui n'avait pas été trop mal accueillie. En revanche, celle-ci a mis du temps avant d'être incluse (elle était superbement ignorée lors des demandes de _pull_ des noyaux précédant) et a valu à son auteur la mise au point suivante [de la part de Linus](https://lkml.org/lkml/2012/10/13/127) :> David Je veux qu'il soit parfaitement clair que si tu proposes *un jour* un nouveau nettoyage d'envergure des fichiers d'include, je répondrai « b*rdel non » et te bloquerai de mes courriels à jamais. D'accord ? Alors ne t'en donne pas la peine. Nous en avons terminé avec ce genre de jeux. Pour toujours. Ça n'en vaut pas la peine, ne suggère plus jamais d'autres « nettoyages ». # Statistiques En ce qui concerne les statistiques du cycle de développement du noyau 3.7, le site LWN a publié [son traditionnel article récapitulatif](https://lwn.net/Articles/527191/). En termes de _patches_, le total s’établit à 11 982, alors qu’il était de 10 226 pour le noyau précédent. C’est un chiffre très élevé, puisque seul l'antique noyau 2.6.25 le dépasse avec 12 243 _patches_. Si l'on considère uniquement la période de merge (donc avant la sortie de la RC1), on a même un record absolu avec 10 409 _patches_ intégrés par Linus. En seulement 71 jours, ce sont environ 719 000 lignes de code qui ont été ajoutées et 395 000 supprimées, pour un accroissement total d’environ 324 000 lignes. Selon [les statistiques du site remword](http://www.remword.com/kps_result/3.7_petop.html), 1 316 personnes différentes ont participé à l'écriture des _patches_ de ce nouveau noyau (1 251 développeurs pour le précédent). Le contributeur le plus prolifique est encore une fois H. Hartley Sweeten avec 417 _patches_ portant sur le nettoyage du sous‐système [Comedi](http://www.comedi.org/) (périphériques d’acquisition de données). Un autre contributeur notable de ce cycle est Al Viro qui, avec 179 _patches_, continue son travail de refactorisation et de nettoyage de la couche VFS. En termes de lignes de code, c'est bien entendu David Howells qui l'emporte avec son projet d'éclatement des fichiers d'en-tête évoqué plus haut. C'est maintenant la période de merge du noyau 3.8 qui s'ouvre et [Linus a déjà annoncé](http://article.gmane.org/gmane.linux.kernel/1408240) qu'elle se fermerait un peu plus tôt que d'habitude, pour ne pas se télescoper avec les vacances de Noël. Si vous avez des branches Git à lui envoyer, dépêchez-vous ou craignez son courroux !

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