URL: https://linuxfr.org/news/linux-pour-workgroups-3-11-le-noyau-pret-pour-le-bureau
Title: Linux pour Workgroups 3.11, le noyau prêt pour le bureau
Authors: Jarvis
Davy Defaud, JPEC, Jiehong, antistress, Martin Peres, Benoît Sibaud, woprandi, ZeroHeure, jcr83, Olivier Esver, bayo, yogitetradim, palm123, 4fages, Amine "nh2" Brikci-Nigassa, ʭ ☯ , Anonyme, NeoX, Sylvestre Ledru, jlh, lovasoa, Mali, Matthieu Moy, patrick_g, maboiteaspam, Nÿco, ariasuni et claudex
Date: 2013年07月14日T08:27:43+02:00
License: CC By-SA
Tags: linux, kernel, noyau_linux, coulisses, linus_torvalds, ubuntu et lwn
Score: 91
La sortie de la version stable 3.11 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_](https://www.kernel.org/). Pour l’occasion, l’espiègle Tux arbore [le drapeau de Windows pour Workgroups 3.11] (http://www.h-online.com/open/news/item/Linux-for-Workgroups-Linux-3-11-s-feature-set-now-confirmed-1917712.html) au démarrage du système.
Merci à tous les participants à la rédaction de cette dépêche, dont vous trouverez les noms en cliquant sur le lien des contributeurs, sous le titre de la dépêche !
Merci spécial à [Martin Peres](http://linuxfr.org/users/mupuf) pour les passages graphiques sur les pilotes Nouveau et radeon (notamment pour ses explications sur la gestion de l’énergie).
----
[Sortie du noyau précédent](http://linuxfr.org/news/le-noyau-linux-3-10-est-sorti)
[[parityportal.com] Linux 3.11 features](http://www.parityportal.com/2013/07/12/linux-3-11-features/)
[Noyaux précédents](http://linuxfr.org/wiki/depeches_noyau)
[[LWN.net] The 3.11 merge window closes](https://lwn.net/Articles/558940/)
[[LWN.net] The 3.11 merge window opens](https://lwn.net/Articles/557314/)
[[h-online.com] "Linux for Workgroups": Linux 3.11’s feature set now confirmed](http://www.h-online.com/open/news/item/Linux-for-Workgroups-Linux-3-11-s-feature-set-now-confirmed-1917712.html)
[kernelnewbies.org](http://kernelnewbies.org/Linux_3.11)
[[Phoronix] Recapping The Linux 3.11 Kernel Features](http://www.phoronix.com/scan.php?page=news_item&px=MTQ1MDI)
----
# La phase de test #
## RC-1 ##
La version [RC-1](https://lkml.org/lkml/2013/7/14/107) a été annoncée le 14 juillet par Linus :
_Ça fait deux semaines et la fenêtre d’intégration est dorénavant fermée. Si j’ai oublié quelque chose, hurlez, mais il n’y a rien en attente à ma connaissance._
_Cette fenêtre d’intégration était plus petite en termes de nombre de changements que celle de la 3.10, mais nous avons plus de nouvelles lignes. La plupart semblent être en « staging » — un tiers des changements en termes de lignes est « staging » et l’intégration de Lustre en est la principale raison. Nous verrons comment ça finira ; je dois dire que nous n’avons pas une grande expérience sur les systèmes de fichiers à travers « staging »._
_Je pense que c’est une fenêtre d’intégration relativement calme, excepté pour celle de Lustre. Nous avons eu des problèmes sur quelques arborescences, et nous avons un débat en cours sur des correctifs stables déclenché par cette période de fusion ; nous devrions donc avoir un sujet de discussion pour le Kernel summit. Mais dans l’ensemble, je sens que nous devrions commencer à assister au calme estival habituel (excepté pour l’Australie)._
_Bien que plus petite que la dernière fenêtre d’intégration, ce n’est pas comme si elle était « minuscule », et comme d’habitude je fais uniquement un résumé du rapport de fusion de la -rc1 : comme d’habitude, les personnes nommées ici ne sont pas les contributeurs qui ont écrit le code (bien que dans certains cas cela soit vrai), mais les propriétaires des dépôts que j’ai récupérés._
_Eh, commençons tous les tests,_
_Linus_
## Avant la RC-2##
Avant la sortie de la RC-2, [Linus se plaint du manque de correctifs](http://lkml.indiana.edu/hypermail/linux/kernel/1307.2/02191.html). Les développeurs seraient‐ils partis en vacances ?
_Nous sommes à mi‐chemin de la première semaine après la fermeture de la fenêtre d’intégration, et, normalement, je devrais être en train de me plaindre à propos du nombre de trucs que vous m’envoyez tous, et de vous rabâcher que vous m’avez envoyé quelques conneries à moitié terminées pendant la fenêtre d’intégration, qui auraient probablement dû attendre jusqu’à la prochaine version._
_Mais, non. Tout le monde a préféré commérer autour de la fontaine, et j’ai eu une ou deux demandes d’intégration par jour de gens qui sont heureusement inconscients (ou trop intelligents pour s’impliquer) sur l’ensemble « Flame fest »._
_Je suis acariâtre et difficile. Envoyez‐moi trop de choses et je crie. Envoyez‐en moi trop peu et je crie. Parce que je suis la [Boucles d’or](http://fr.wikipedia.org/wiki/Boucles_d%27or_et_les_Trois_Ours) du développement du noyau, et je veux que mes demandes d’intégration soient bien, tout simplement. Et, clairement, toute l’énergie a été épuisée dans la discussion, pas dans le travail._
_Ouste ! Retournez à vos bureaux. Ne vous rassemblez pas tous dans la salle de pause._
_Linus_
_P.‐S. : Ou, peut‐être, vous êtes simplement professionnels et vous comptabilisez votre temps, et tout le monde a l’intention de m’envoyer son travail au moment de pointer, le vendredi à 17 heures ? Mais ce n’est pas ce qu’on ressent._
## RC-2 ##
La [deuxième RC](http://lkml.indiana.edu/hypermail/linux/kernel/1307.2/03644.html) a été annoncée une semaine plus tard par Linus :
_Voici donc une autre semaine, et la -rc2 est là._
_Les changements sont un peu bizarres, car, en vrac, 95 % d’entre eux concernent uniquement la suppression du pilote « staging » CSR qui n’attirait personne, de sorte que le `diffstat` (et le `dirstat` en particulier) n’est pas très intéressant ni lisible à cause de la suppression du pilote qui éclipse pratiquement tout le reste. Mais, j’avoue aimer voir de la suppression de code._
_Pour le reste des changements, une partie notable concerne la suppression des marques `_cpuinit`, dont les gens ont convenu qu’elles apportaient plus de difficultés que de gain à maintenir. Nous avions au préalable rendu les marqueurs inopérants, de sorte qu’ils n’aient pas d’importance pour la génération de code, et ici, pour la rc2, ils peuvent être effectivement supprimés._
_Résultat : nous avons deux événements distincts qui génèrent beaucoup de bruit au sein de la liste des changements, mais ils ne sont pas très intéressants, et ne rendent la lecture de celle‐ci que plus difficile._
_Si l’on ignore le bruit de fond susmentionné, il y a une ou deux choses à noter à propos de la rc2. Je pense que la plupart des changements sont de gentils correctifs, mais je voulais donner un peu plus d’importance à deux points que voici :_
_(a) le drapeau `O_TMPFILE`, nouveauté de la 3.11, a subi quelques nettoyages d’ABI / API (et également quelques correctifs d’implémentation), mais je pense que nous avons fini maintenant. Donc, si vous êtes intéressés par le concept de fichiers temporaires anonymes, allez de l’avant et testez‐le. L’absence de nom permet non seulement de se débarrasser de concurrences et complications avec la génération de fichier, mais ça peut aussi rendre le tout plus efficace, puisque vous n’avez pas les opérations d’annuaire qui peuvent causer de la sérialisation d’entrées‐sorties, entre autres._
_(b) nous avons eu un changement de dernière minute sur la façon dont la gestion du rétroéclairage ACPI est faite sur certaines machines. Et, bien que ce genre de chose ne devrait pas vraiment être fait en dehors de la fenêtre d’intégration, j’ai fini par l’intégrer quand même. Mais je voudrais vraiment avoir des gens qui testent cette chose, en particulier sur les ordinateurs portables munis d’une carte graphique Intel. Ça ne devrait toucher (et améliorer les choses avec de la chance) que les ordinateurs les plus récents dont le BIOS a été conçu pour Windows 8. Mais, bon, plus il y a de tests, mieux c’est. La gestion du rétroéclairage a été difficile auparavant, donc je le mentionne explicitement._
_Quoi qu’il en soit, en dehors de ces deux problèmes, je pense que le reste est assez normal pour une rc2. Ça a commencé un peu lentement, mais je pense que ça a fini normalement. Outre les trucs déjà mentionnés, nous avons des choses sur le DRM (radeon en particulier), quelques corrections de pilotes, des mises à jour s390, MIPS, ARM et x86, les pilotes audio, des corrections ext4 et Btrfs, bla bla._
_Le résumé des modifications depuis la -rc1 est en pièce jointe._
_Linus_
## RC-3 ##
La [troisième RC](http://lkml.indiana.edu/hypermail/linux/kernel/1307.3/02765.html) :
_À nouvelle semaine, nouvelle -rc._
_S’il vous plaît, oubliez ce que je vous ai dit la semaine dernière sur le fait de retourner au travail. Vous l’avez fait. La -rc3 a environ 50 % de changements de plus que la -rc2. C’est en partie dû au fait que quelques gens ont manqué la -rc2, mais aussi que des gens m’en ont envoyé plus. S’il vous plaît, arrêtez. C’est l’été. C’est agréable à l’extérieur. Emmenez les enfants à la piscine ou ailleurs. Envoyez‐moi seulement des correctifs de régressions._
_Sinon, je vais devoir recommencer à crier sur les gens._
_Quoi qu’il en soit, souvenez‐vous comment j’ai demandé aux gens de tester les modifications du rétroéclairage dans la -rc2 parce que des telles choses ont vraiment eu de mauvais antécédents ? Yep ! Tout ça a été annulé. Cela a corrigé les choses pour certaines personnes, mais ça a régressé pour les autres, et nous ne faisons pas « un pas en avant, deux pas en arrière ». Mais, n’ayez crainte, nous avons des super gens qui regardent ça._
_Le prise en charge de la crypto `crc t10 dif` a été annulée aussi, parce qu’elle pose des problèmes avec l’infrastructure d’`initrd`._
_Mais l’essentiel ici, concerne les mises à jour de pilotes de blocs (`drbd`, `rsxx`, `xen`, `bcache` et `libata`) et les changements de DRM (principalement `qxl`, mais il y a aussi des changements sur le « big tree » : `radeon`, `intel` et `nouveau`). Et, enfin, quelques pilotes — USB, SCSI, pincontrol, etc._
_Il y a également des mises à jour classiques pour certaines architectures (principalement pour Alpha, ARM et PowerPC)._
_Le rapport complet des changements depuis la rc2 est en pièce jointe. C’est tellement gros que j’ai débattu le fait de faire uniquement un rapport d’intégration dans le style « période d’intégration », mais peut‐être que les gens apprécient ce genre de détails ?_
_Linus_
## RC-4 ##
La [quatrième RC](http://lkml.indiana.edu/hypermail/linux/kernel/1308.0/01992.html) a été annoncée avant la nuit du 4 août :
_C’est à nouveau ce moment de la semaine..._
_« Appliquez 339 correctifs, qu’obtenez‐vous au final ?
Plus âgé d’une semaine et un peu plus redevable.
Saint Pierre, ne m’appelle pas, car je ne pourrais venir à toi.
Mon âme, au magasin de la compagnie, je la dois. »_
_J’avais espéré que les choses commenceraient à se calmer, mais la rc4 est à peu près de la même taille que la rc3. Ceci dit, les correctifs semblent un peu plus épars et moins intéressants — ce qui est une bonne chose. L’ennui, c’est bien. Maintenons les choses ainsi et essayons de faire moins de correctifs pour la rc5, d’accord ? Parce que nous avons parcouru la moitié du chemin maintenant, et je ne souhaite vraiment voir que des corrections._
_Nous avons des mises à jour d’architectures (ARM et PA-RISC), mais la majorité concerne des pilotes (surtout du réseau, USB et DRM). Il y a également des changements profonds au niveau réseau. Et les mouvements du code `printk` semblent importants si vous n’utilisez pas `git renames` (c’est‐à‐dire comme les correctifs que j’envoie)._
_Linus_
## RC-5 ##
La [cinquième RC](http://lkml.indiana.edu/hypermail/linux/kernel/1308.1/01817.html) est sortie le 11 août, et Linus s’amuse avec la sortie de [Windows 3.11](http://en.wikipedia.org/wiki/Windows_3.1x#Windows_for_Workgroups_3.11) :
_Malheureusement, la numérologie ne fonctionne pas si bien, et, alors que sortir la version 3.11 aujourd’hui serait une heureuse coïncidence (Windows 3.11 sortait ce jour même, il y a vingt ans), ce ne sera pas le cas._
_À la place, nous avons une 3.11-rc5._
_Cette dernière montre des signes d’accalmie et est nettement plus petite que les précédentes RC (autant en nombre de changements, qu’en taille desdits changements). Espérons seulement que ce n’est pas uniquement un coup de chance._
_Il semblerait qu’il n’y ait aucun changement majeur. Les changements touchant `radeon` sont les plus notables, mais la majorité d’entre eux ne concerne que la gestion dynamique de l’énergie qui est désactivée par défaut... Mis à part ça, quelques corrections média, des mises à jour d’architectures, quelques petites mises à jour au niveau systèmes de fichiers, etc. Rien ne sort vraiment du lot._
_Linus_
## RC-6 ##
La version [RC-6](https://lkml.org/lkml/2013/8/18/202) a été annoncée le 18 août par Linus :
_La semaine a été plutôt calme et les RC s’amenuisent, ce qui me satisfait._
_Bien sûr, nous avons rencontré un bogue intéressant et bruyant dans le code d’invalidation de la [TLB](http://fr.wikipedia.org/wiki/Translation_lookaside_buffer), mais c’était un bogue plus ancien et apparemment vraiment difficile à reproduire en pratique. Ceci dit, cela pourrait expliquer quelques `SIGSEGV` aléatoires, etc. Ainsi, si vous avez vu un comportement étrange, peut‐être que vous êtes tombé dessus, et la RC-6 corrigera cela. On touche du bois._
_Sinon, ce sont plutôt des changements divers : réseau, pilotes, USB, son et quelques corrections pour les systèmes de fichiers. On retrouve également des mises à jour architecturales pour x86, ARM et m68k. Mais, c’était vraiment calme. Le résumé ci‐dessous donne les détails pour ceux qui sont intéressés._
_Puisque les statistiques de cette rc étaient ennuyeuses, j’ai commencé à regarder des chiffres plus impressionnants. Cela fait maintenant huit ans que l’on utilise Git, et on a effectué plus de 400 000 changements durant cette période. C’est intéressant (du moins pour moi), puisqu’à l’époque où l’on utilisait BK (*[BitKeeper](http://fr.wikipedia.org/wiki/BitKeeper), de 2002 à 2005, NDT*) on s’approchait de la limite des 65 000 changements en trois ans d’utilisation. Cela fait donc longtemps que l’on a pulvérisé cette limite._
_Qu’en est‐il de ces 400 000 changements ? Ils tiennent tous dans un fichier empaqueté de 575 Mio (plus un index de 85 Mio). Après, c’est en forçant plus sur la compression du paquet de fichiers que la plupart des personnes doivent le faire, mais je pense qu’il est intéressant de voir comment huit années d’historique de développement actif ont la même taille que l’arbre des sources brut. En fait, je pense qu’il vous faut plus d’espace libre pour les fichiers objets lors de la compilation que l’espace nécessaire au stockage de tout l’historique._
_J’essaierai de me souvenir de faire des statistiques plus intéressantes et pertinentes pour la sortie de la rc7, parce que cela coïnciderait avec le 22^(e) anniversaire de l’annonce initiale de Linux sur_ comp.os.minix.
_Comme le temps passe vite lorsqu’on s’amuse..._
_Linus_
## RC-7 ##
La version [RC-7](https://plus.google.com/+Linux/posts/f96weYxzEu1) a été annoncée le 26 août sur Google+ par Linus :
_Bonjour à tout le monde ici‐bas utilisant Linux,_
_Je fais un système d’exploitation (libre) (juste un passe‐temps, même si c’est important et professionnel) pour les clones d’AT 486+ et presque tout le reste ici‐bas sous le soleil. Le brassage est en cours depuis avril 1991, et ce n’est pas encore prêt. J’aimerais avoir des retours sur les choses que les gens aiment ou détestent dans Linux 3.11-rc7._
_J’ai initialement porté_ bash _(1.08) et_ gcc _(1.40), mais les autres ont repris l’espace utilisateur, et ça semble fonctionner. Ça indique que je vais avoir la version 3.11 finale d’ici une semaine, et j’aimerais savoir quelles fonctionnalités la plupart des gens voudraient. Toutes les suggestions sont les bienvenues, mais je ne promets pas que je les implémenterai. :-)_
Puis il rajoute en commentaire :
_Ouais, je ne veux vraiment pas avoir de demandes de fonctionnalités en cette fin de version RC..._
_Mais ça fait 22 ans aujourd’hui depuis cette annonce, et j’aimerais que les gens testent le noyau actuel 3.11-rc7 que je viens de téléverser aux emplacements habituels._
_Linus_
# Les nouveautés #
## Zswap ##
Zswap est une fonctionnalité du noyau qui fournit la compression du cache pour le _swap_. C’est en développement depuis longtemps et le [code](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2b2811178e85553405b86e3fe78357b9b95889ce) est enfin disponible dans le développement principal du noyau Linux.
Zswap prend les pages qui sont dans le traitement d’évacuation du _swap_ et essaie de les compresser dans un groupe de mémoire vive allouée dynamiquement. Et si l’espace ainsi gagné est suffisant, des écritures sur disque sont évitées. Zswap échange ainsi cela par des cycles processeur pour réduire potentiellement des écritures et lectures en _swap_. Cet échange peut améliorer de façon significative les performances si les lectures du cache compressé sont plus rapides que les lectures du _swap_.
Pour plus de [détails sur Zswap](http://lwn.net/Articles/528817/).
## Compression LZ4 pour le noyau ##
LZ4 est un outil de compression très rapide par rapport à gzip, bzip2, LZMA ou LZO. Il utilise les algorithmes de compression [LZ77 et LZ78](http://fr.wikipedia.org/wiki/LZ77_et_LZ78) (pour plus de détails sur le fonctionnement de LZ4 voir [_ici_](http://fastcompression.blogspot.fr/2011/05/lz4-explained.html)). Le nouveau noyau prend en charge la compression LZ4 du noyau. Il permet ainsi de faire un démarrage plus rapide du noyau Linux. Cette prise en charge est actuellement possible **seulement pour l’architecture ARM**. Il n’est pas à exclure que cela soit étendu à d’autres architectures dans une prochaine version.
Plus de [détails sur LZ4 pour le noyau](http://lwn.net/Articles/541425/).
## Sécurité : option O_TMPFILE ##
La nouvelle option `O_TMPFILE` pour les appels système `open()` et `openat()` permet aux systèmes de fichiers d’optimiser la création de fichiers temporaires (fichiers qui n’ont pas besoin d’être visibles dans le système de fichiers). Lorsque l’option `O_TMPFILE` est présente, le nom du chemin fourni est seulement utilisé pour trouver le répertoire le contenant (et donc le système de fichiers où le fichier temporaire devrait être). Ainsi, par exemple, les programmes utilisant `O_TMPFILE` devraient avoir moins d’inquiétudes concernant la vulnérabilité des attaques avec des liens symboliques.
## Rapid Start ##
Matthew Garret, un spécialiste d’[UEFI](http://fr.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface), est actuellement en train de regarder comment mettre en œuvre Rapid Start sous Linux.
Rapid Start est une technologie Intel ayant pour but de permettre à un système de sortir d’un profond sommeil en 5 ou 6 secondes, c’est‐à‐dire plus rapidement que la traditionnelle hibernation et bien plus efficacement qu’une réelle extinction de la machine. Elle mémorise dans une partition dédiée d’un SSD le contenu de la mémoire vive.
Au niveau technique, Rapid Start utilise un micrologiciel qui copie le contenu de la mémoire vive sur la partition spéciale du disque SSD avant d’entrer en sommeil profond, et inversement remet son contenu dans la mémoire vive lors du réveil. La différence avec l’hibernation classique est que le micrologiciel se situe dans le BIOS UEFI, permettant de gagner quelques secondes (pas de GRUB, etc.).
Matthew Garret a mis en place un changement permettant de mettre en œuvre ce mécanisme. Évidemment, il faudra aussi mettre en œuvre cette avancée en espace utilisateur. Les développeurs de la distribution Ubuntu [commenceraient à travailler](http://www.phoronix.com/scan.php?page=news_item&px=MTQ0NzY) sur cela. Il est probable que cela soit fonctionnel pour la prochaine version LTS qui sortira en avril.
Pour plus de détails, voir [son blogue](http://mjg59.dreamwidth.org/26022.html).
## Renesas R-Car ##
Pour finir concernant les nouveautés, nous pouvons noter l’arrivée d’un [nouveau pilote graphique](http://cgit.freedesktop.org/~airlied/linux/commit/?id=4bf8e1962f91eed5dbee168d2348983dda0a518f) [Renesas R-Car](http://am.renesas.com/applications/automotive/cis/cis_highend/rcar_h1/index.jsp), qui est une puce à quatre cœurs ARM Cortex-A9. Cette puce est utilisée pour les systèmes embarqués dans les voitures haut de gamme.
# Les améliorations #
## Architectures ##
### ARM ###
De nombreux changements de ce nouveau noyau ont concerné les architectures ARM. On peut citer notamment :
* [prise en charge minimale](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=828989ad87af15b555f783a70efa2cc526b35b3f) du processeur Texas Instruments Keystone ARM ;
* un [début de prise en charge](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9851ca5774e693e2088a4b34ad456cfaadaf29a7) des calculatrices de la gamme [TI-Nspire](http://fr.wikipedia.org/wiki/TI-Nspire) ;
* prise en charge du processeur [Rockchips](http://en.wikipedia.org/wiki/Rockchip) RK3xxx ARM ;
* la compression LZ4 du noyau (développée [ci‐dessus](http://linuxfr.org/redaction/news/linux-pour-workgroups-3-11-le-noyau-pret-pour-le-bureau#compression-lz4-pour-le-noyau)) ;
* Samsung a ajouté [la prise en charge des puces S3C64XX](http://lists.freedesktop.org/archives/dri-devel/2013-June/040747.html) pour son pilote vidéo Exynos.
Voir [plus de changements](http://kernelnewbies.org/Linux_3.11-DriversArch#head-221aa16f56ad1ee062fee121d9f2eb9538f81417).
### AArch64 ###
Vous avez peut‐être déjà entendu parler de l’architecture [ARM 64 bits](http://linuxfr.org/news/sortie-du-noyau-linux-3-7#toc_11) ? C’est une architecture qui n’existe pas encore physiquement, mais seulement virtuellement. Il est maintenant possible de virtualiser cette architecture en utilisant KVM ou Xen. Au‐delà de cette possibilité de virtualisation, cette architecture a reçu des améliorations. Elle peut monter des partitions [Hugetlbfs](https://lwn.net/Articles/375096/) et utiliser des [_huge pages_ transparentes](https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-memory-transhuge.html). Enfin, il est à noter une amélioration au niveau du vidage de la mémoire disque du noyau (_Cache flushing_).
Pour [plus de détails](http://lkml.indiana.edu/hypermail/linux/kernel/1307.0/00404.html).
## Cryptographie ##
Voici la liste des [changements](http://lkml.indiana.edu/hypermail/linux/kernel/1307.0/02532.html) concernant la cryptographie :
* prise en charge du SHA-224 et SHA-384 pour les processeurs utilisant le jeu d’instructions [SSSE3](http://fr.wikipedia.org/wiki/SSSE3) ;
* API du [LZ4](http://en.wikipedia.org/wiki/LZ4_%28compression_algorithm%29) ;
* ~~Instruction PCLMULQDQ pour accélérer CRC T10 DIF~~ ;
* prise en charge du coprocesseur DCP de Freescale.
## Audio ##
Rien de révolutionnaire dans cette section. Seulement des prises en charge de nouveaux périphériques. Par exemple :
* [prise en charge de la radio](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8e0d70434d497f0265ccfe5d92a6a509410685ba) pour la carte MediaForte M56VAP ;
* ajout du [pilote](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a91c3fb2f84204dcf024ca6a032f12cdb84f2196) pour le convertisseur numérique USB vers S/PDIF [M2Tech hiFace](http://musiq-audiophile.blogspot.fr/2010/05/m2tech-hiface-les-dessous-dune-petite.html), qui se charge d’améliorer la transmission des données audio ;
* amélioration de la [prise en charge](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6) du pilote Intel Haswell.
Pour [plus de détails](http://lkml.indiana.edu/hypermail/linux/kernel/1307.0/01539.html).
## Pilotes graphiques ##
### Intel ###
[Haswell](http://fr.wikipedia.org/wiki/Haswell) est la nouvelle micro‐architecture, sortie début juin, qui succède à [Sandy Bridge](http://fr.wikipedia.org/wiki/Sandy_Bridge). Les premiers correctifs pour sa prise en charge datent d’[Août 2012](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=da612d880fbc598ac0efcef579355fb90d4bca4e), 10 mois avant la sortie officielle du microprocesseur. Son prise en charge a été déclarée stable fin novembre 2012 à l’occasion du [noyau 3.8](http://linuxfr.org/news/sortie-du-noyau-linux-3-8#toc_17), soit un peu plus de 7 mois avant sa sortie. Elle s’est encore améliorée dans les [sorties](https://linuxfr.org/news/sortie-du-noyau-linux-3-9#toc_13) [suivantes](https://linuxfr.org/news/le-noyau-linux-3-10-est-sorti#intel). On peut donc dire qu’Intel fourni une prise en charge exemplaire, car il permet aux distributions grand public, telles qu’Ubuntu, de pouvoir prendre en charge les nouveaux processeurs graphiques Haswell dès leur sortie, sans avoir besoin de mettre à jour le noyau ou de rétroporter les modifications dans le noyau de la distribution.
Les nouveautés apportées à la prise en charge d’Haswell dans cette version sont :
* _Intermediate Pixel Storage_ (IPS), qui permet de réduire le nombre de fois où le moteur graphique réveille la mémoire pour lire les pixels. Ainsi, cela fait diminuer la consommation électrique ;
* _Frame-Buffer Compression_ (FBC), qui permet aussi d’[économiser de l’énergie](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.60.8187&rep=rep1&type=pdf).
Pour plus de détails, voir ces courriels sur [_dri-devel_ en mai](http://lists.freedesktop.org/archives/dri-devel/2013-May/039198.html) et [en juin](http://lists.freedesktop.org/archives/dri-devel/2013-June/040657.html).
### NVIDIA (pilote Nouveau) ###
Cette nouvelle version marque l’arrivée de la [prise en charge de VP2](http://lists.freedesktop.org/archives/nouveau/2013-June/012821.html), groupe de moteurs de décodage vidéo matériel pour les [GeForce 8 et 9](http://nouveau.freedesktop.org/wiki/CodeNames/). Cette fonctionnalité a été développée par un ancien contributeur revenu travailler sur [Nouveau](http://fr.wikipedia.org/wiki/Nouveau_%28informatique%29), Ilia Mirkin. Son travail vient compléter la prise en charge déjà existante de VP4.2 et VP5, moteurs de décodage vidéo matériel respectivement pour les cartes de la famille [Fermi](http://nouveau.freedesktop.org/wiki/CodeNames/) et [Kepler](http://nouveau.freedesktop.org/wiki/CodeNames/), qui permettent le décodage matériel des vidéos encodées en MPEG-1, MPEG-2 et H.264. La prochaine version de Linux verra l’ajout du VP3 et VP4 ce qui complétera le décodage vidéo pour pratiquement toutes les cartes GeForce 8 et supérieures.
Pour utiliser le décodage vidéo, il est encore nécessaire d’utiliser les microcodes de NVIDIA. Comme leur licence ne permet pas leur redistribution, c’est à l’utilisateur de faire l’effort de les installer. Cette opération a longtemps nécessité de faire une `MMIOTrace` (opération [assez compliquée](http://nouveau.freedesktop.org/wiki/NVC0_Firmware/)), mais Ilia a simplifié la procédure en permettant l’extraction automatique des microcodes directement depuis le pilote propriétaire de NVIDIA. Si vous utilisez [[ArchLinux]], il vous suffit d’installer le paquet [_nouveau-fw_](https://aur.archlinux.org/packages/nouveau-fw) pour en bénéficier. Pour les autres distributions ou si vous souhaitez en savoir plus, vous pouvez visiter la page Wiki dédiée au [décodage vidéo](http://nouveau.freedesktop.org/wiki/VideoAcceleration/) qui vous indiquera le niveau de prise en charge actuel de chaque carte, la version logicielle de chaque composant que vous devez avoir, ainsi que la procédure à suivre pour extraire et installer les microcodes. Mais aussi, pour finir, comment utiliser l’accélération vidéo [[VDPAU]].
Cette nouvelle version a aussi permis de corriger bon nombre de bogues et plantages. Ces bogues étaient majoritairement liés à l’imperfection du microcode libre qui permet d’effectuer le changement de contexte dans la carte, processus indispensable à l’accélération 3D dans l’architecture actuelle de Nouveau. L’amélioration de ces microcodes a rendu [stable](http://cgit.freedesktop.org/~airlied/linux/commit/?id=f7d452f4fd5d86f764807a1234a407deb5b105ef) le (très problématique) processeur graphique [NVD9](http://nouveau.freedesktop.org/wiki/CodeNames/). La tâche de débogage est encore en cours, ce qui devrait augmenter la fiabilité et la cohérence du pilote dans la prochaine version.
Pour finir, la prise en charge initiale pour les [NVD7](http://nouveau.freedesktop.org/wiki/CodeNames/) a également été ajoutée.
### ATI/AMD (pilote radeon) ###
Le pilote [radeon](http://fr.wikipedia.org/wiki/Radeon_%28logiciel%29) a provoqué l’étonnement lorsqu’[Alex Deucher](http://www.botchco.com/agd5f/), développeur chez AMD, a publié un jeu de [165 correctifs](http://lists.freedesktop.org/archives/dri-devel/2013-June/040436.html) pour ajouter une prise en charge complète de la gestion d’énergie pour les cartes de la famille r6xx à SI (_Southern Island_). Comme la gestion d’énergie est un sujet complexe, voici une petite présentation sur les différents concepts présents.
#### La consommation des MOSFET ####
À l’échelle la plus basse, une carte graphique est majoritairement composée de transistors de type [MOSFET](https://fr.wikipedia.org/wiki/Transistor_%C3%A0_effet_de_champ_%C3%A0_grille_m%C3%A9tal-oxyde). Ces transistors sont une des causes principales de la consommation énergétique. Cette consommation est découpée en deux parties :
* la _consommation statique_ : à force de miniaturiser les transistors, ceux‐ci ne sont jamais complètement bloquants, il y a donc un courant de fuite lorsque le transistor est ouvert. Ce courant (_Ileak_) doit être multiplié avec la tension d’alimentation (_Vdd_) pour calculer la consommation statique (_Pstatic = Vdd ×ばつ Ileak_) ;
* la _consommation dynamique_ : cette consommation est liée au fait de changer l’état (ouvert/fermé) d’un transistor. Elle est généralement approximée par 3 facteurs, la fréquence de changement d’état (_f_), la tension d’alimentation (_Vdd_) au carré et la charge capacitive (_C_) qui empêche le changement d’état (_Pdynamic = f ×ばつ Vdd2 ×ばつ C_).
#### Les 3 méthodes pour diminuer la consommation des MOSFET ####
En se basant sur ces équations, une des premières approches pour réduire la consommation énergétique est de diminuer la tension d’alimentation (_Vdd_). Cependant, si l’on diminue trop la tension d’alimentation, la charge capacitive (_C_) vient empêcher le changement rapide d’état, ce qui contraint à diminuer la fréquence de fonctionnement de la carte et affecte donc les performances. Il faut donc adapter dynamiquement la fréquence et la tension d’alimentation, en fonction de la charge du processeur graphique. Cette technique s’appelle le _[dynamic voltage and frequency scaling](https://en.wikipedia.org/wiki/Voltage_and_frequency_scaling)_ et utilise généralement les [compteurs de performance matériels](https://en.wikipedia.org/wiki/Hardware_performance_counter) pour déterminer le niveau de performance requis.
Une autre solution pour diminuer la consommation énergétique est de couper l’horloge des blocs de transistors qui ne sont pas actuellement en cours d’utilisation. Cela permet de rendre nulle _la consommation dynamique_ au prix d’une augmentation de la complexité de l’arbre d’horloge. Cette technique s’appelle le _[clock gating](https://fr.wikipedia.org/wiki/Clock_gating)_ et peut théoriquement n’avoir aucun impact sur les performances.
Pour finir, la solution la plus efficace pour diminuer la consommation énergétique est de couper l’alimentation des blocs inutilisés de la carte. Cette technique, appelée _[power gating](https://en.wikipedia.org/wiki/Power_gating)_, a pour mérite de couper totalement la consommation énergétique au prix de la perte des informations stockées dans les registres des blocs concernés. Il est donc nécessaire de sauvegarder le contexte d’un moteur d’exécution avant d’utiliser le _power gating_ et de recharger le contexte après son utilisation. Ces opérations sont lentes, ce qui limite la fréquence à laquelle le _power gating_ peut être utilisé. Ces opérations sont généralement faites par un microcontrôleur dédié à la gestion d’énergie pour ne pas encombrer le processeur central (CPU).
#### Et DPM dans tout ça ? ####
Pourquoi parler de tout cela ? Tout simplement parce que derrière l’acronyme DPM (_Dynamic Power Management_), utilisé par AMD, se cache en fait les trois méthodes présentées. Cette gestion d’énergie implémentée par AMD est donc maintenant disponible pour toutes les cartes AMD, sauf celles de la prochaine génération (_Sea Islands_) où le travail a déjà commencé et, évidemment, sur les vieilles cartes où le DPM n’est pas ou peu pris en charge par le matériel.
Un [premier banc d’essai](http://www.phoronix.com/scan.php?page=article&item=amd_dpm_preview&num=1) sur la RC1 montre une amélioration des performances, notamment sur les jeux demandant beaucoup de ressources. DPM peut en effet améliorer les performances de la carte graphique, car le code agit sur sa fréquence et ses tensions d’alimentation (technique : _Dynamic Voltage and Frequency Scaling_). Jusqu’à présent le pilote libre AMD ne modifiait pas ces paramètres, et les valeurs par défaut n’étaient pas forcément celles permettant de profiter de toute la puissance de la carte. Un autre [test](http://www.phoronix.com/scan.php?page=article&item=amd_radeon_dpm&num=1) montre que, sur un échantillon de trois cartes graphiques différentes, on constate une réduction de la consommation en Watts (jusqu’à 40 %) et une réduction de la température (de quelques degrés).
Notons tout de même que DPM n’est pas activé par défaut, du fait de la jeunesse du code.
#### ASPM : gestion d’énergie pour le bus PCI-Express ####
Pour rester dans l’énergie, ASPM (_Active State Power Management_) est une autre fonctionnalité utilisée pour gérer la consommation énergétique des périphériques PCI Express. Cette fonctionnalité introduit deux modes basse consommation, équivalents des [C-States](https://fr.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface#CPU_states_.28.C3.A9tats_des_processeurs.29) des CPU. Le niveau d’endormissement L0 est sélectionné dès que le lien devient inactif, alors que le niveau L1 est sélectionné après une période d’inactivité supérieure. Le niveau L1 permet d’économiser plus d’énergie, au prix d’une latence de sortie d’endormissement supérieure.
L’ASPM avait déjà fait [parler de lui](https://lwn.net/Articles/449648/) en 2011, lorsque sa politique d’activation a été modifiée dans Linux pour pallier les crashs rencontrés avec le matériel bogué. Cela s’était traduit par une distribution plus stable pour certains et une [consommation énergétique bien supérieure](http://www.phoronix.com/scan.php?page=article&item=linux_2638_aspm&num=1) pour certains autres malchanceux. Une meilleure politique d’activation a ensuite été [ajoutée dans la version 3.3 de Linux](http://www.phoronix.com/scan.php?page=news_item&px=MTA0MTM).
La prise en charge de l’ASPM est maintenant gérée pour les familles R600 à _Southern Islands_. C’est‐à‐dire toutes les cartes récentes, sauf la toute dernière génération.
#### Prise en charge des cartes Sea Islands avant leurs sorties ! ####
Comme si l’amélioration de la gestion d’énergie ne suffisait pas, AMD a aussi publié la prise en charge du KMS, de la 3D, du décodage vidéo (UVD) et d’OpenCL pour les cartes de la famille _Sea Islands_ ! Outre le fait que la prise en charge presque complète pour une famille de cartes arrive d’un seul coup est impressionnant, c’est la première fois (pour Radeon) que cela arrive pour une carte **qui n’est pas encore sortie** !
En effet, les premières cartes de la famille _Sea Islands_ devraient être disponibles en octobre 2013. Avec un peu de chance, la gestion d’énergie pour les cartes de la famille _Sea Islands_ pourrait être ajoutée au prochain noyau Linux, ce qui amènera le même niveau de prise en charge à cette famille que pour les autres cartes modernes.
AMD a donc rattrapé son retard, et on peut supputer qu’il fera de même pour les prochaines familles de cartes. Dorénavant, il devrait être possible d’utiliser le pilote libre dès la sortie du matériel, en utilisant un noyau Linux stable (idéalement, toutefois, il faudrait qu’AMD prenne encore un peu plus d’avance pour que les différents composants — noyau, pilote, Mesa — soient à jour dans les dernières versions des distributions au moment de la sortie du matériel comme Intel essaye de le faire de son côté) !
#### Plus d’informations ####
Pour plus de détails sur les changements, voir ce [courriel de _dri-devel_ de juin](http://lists.freedesktop.org/archives/dri-devel/2013-June/040436.html) et [celui‐ci de juillet](http://lists.freedesktop.org/archives/dri-devel/2013-July/041924.html). Il est aussi intéressant de lire l’interview de [Jérome Glisse, développeur des pilotes Radeon chez Red Hat](http://linuxfr.org/news/entretien-avec-jerome-glisse-developpeur-des-pilotes-graphiques-radeon-pour-red-hat) pour comprendre les conditions dans lesquelles se fait le développement du pilote libre AMD Radeon.
### Autre pilote vidéo ###
Le pilote QXL qui est apparu dans la [précédente version](http://linuxfr.org/news/le-noyau-linux-3-10-est-sorti#autres-pilotes-vido) a reçu des [améliorations](http://cgit.freedesktop.org/~airlied/linux/commit/?id=7c6ca3040e9ac174e6d2189811da603e9c19a150) : redimensionnement dynamique, possibilité d’avoir plusieurs sorties vidéos et prise en charge de l’hibernation et de la mise en veille.
## Systèmes de fichiers ##
Pas de grosses nouveautés dans les systèmes de fichiers grand public.
### ext4 ###
Concernant le système de fichiers ext4, qui est installé par défaut dans la plupart des distributions GNU/Linux, on peut noter beaucoup de corrections de bogues, de nettoyage de code et d’optimisations.
Au niveau des corrections de bogues, il en est une à noter concernant le redimensionnement à chaud des systèmes de fichiers où la taille des blocs est plus petite que la taille d’une page (sur une architecture x86, elle est de 1 Kio. Plus utile, sur une architecture IA-64 ou [Power](http://en.wikipedia.org/wiki/Power_Architecture), où la taille est de 4 Kio).
Dans la catégorie nettoyage de code, la mise en œuvre de la perforatrice de l’ext4 a été vraiment améliorée et prend maintenant en charge les systèmes de fichiers de type [_bigalloc_](https://ext4.wiki.kernel.org/index.php/Bigalloc). Par ailleurs, Jan Kara a nettoyé de façon significative le nom d’accès du code de demande d’écriture. Enfin, la vérification d’erreurs a été améliorée et quelques vérifications de bonne santé du système de fichiers ont été ajoutées.
Concernant les optimisations, il y a deux points importants à mettre en valeur. La première est que `ext4_writepages()` est maintenant utilisé pour le mode sans allocation différée (`nodelalloc`) et pour le mode de compatibilité avec l’ext3. La seconde, si vous suivez encore, est que le mécanisme de réduction du _cache extent_ qui a été ajouté dans le [noyau 3.9](http://linuxfr.org/news/sortie-du-noyau-linux-3-9#toc_1), n’a plus de goulet d’étranglement au passage à l’échelle dû à un verrou tournant (ou [_spin lock_](http://fr.wikipedia.org/wiki/Spinlock)). D’autres optimisations ont permis de réduire l’utilisation du processeur.
Comme vous le voyez, le système de fichiers ext4 est devenu un système mûr spartiate en nouveautés.
Pour plus d’informations, voir [le _pull_ Git](http://lkml.indiana.edu/hypermail/linux/kernel/1307.0/00286.html).
### Btrfs ###
Btrfs est en général présenté comme le successeur d’ext4. Mais son but principal est de fournir un système de fichiers pour les nuages qui concurrence, par exemple, XFS. Peu de nouveautés le concernant, seulement des améliorations de performance, des corrections de bogues et du nettoyage de code. Il est tout de même à noter la [suppression de la structure `btrfs_sector_sum`](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f51a4a1826ff810eb9c00cadff8978b028c40756) qui permet d’améliorer la performance en écriture sur un disque SSD d’environ 70 %. Pour le moment seuls Oracle et SUSE supportent ce système de fichiers qui n’est toujours pas en version stable.
Pour plus d’informations, voir [le _pull_ Git](http://lkml.indiana.edu/hypermail/linux/kernel/1307.1/00890.html
).
Vous pouvez voir sur Phoronix [une série de tests de performance](http://www.phoronix.com/scan.php?page=article&item=linux_btrfs_311&num=1) sur Btrfs selon [les options de montage](https://btrfs.wiki.kernel.org/index.php/Mount_options). Cela met en évidence de grosses différences de performance en fonction des options que l’on utilise. Il est donc nécessaire de bien étudier cela avant de mettre en place Btrfs sur son infrastructure.
### XFS ###
Concernant le système de fichiers XFS, il y a du nouveau : le travail pour le projet de quotas et de groupe de quotas pour qu’ils soient utilisés ensemble a commencé à être inclus dans le code. Ajout d’un [compteur de changement d’inœuds](http://oss.sgi.com/archives/xfs/2013-06/msg00876.html) et d’une [transaction créant un _inode_](http://oss.sgi.com/archives/xfs/2013-06/msg00873.html).
Par ailleurs, il y a des améliorations de performance lors de la suppression et de la création d’inœuds, lors de la lecture à l’avance d’une ou plusieurs pages en mémoire cache (_readahead buffer_), et lors de [`bulkstat`](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/ch09s06.html). Enfin, il y a des corrections de bogues et du nettoyage de code.
Pour plus de détails, voir le [_pull_ Git](http://lkml.indiana.edu/hypermail/linux/kernel/1307.1/00889.html).
### F2FS ###
F2FS (_Flash-Friendly File-System_) est un système de fichiers récent qui a été introduit dans le noyau [3.8](http://lists.freedesktop.org/archives/nouveau/2013-June/012821.html). Il a été créé par Samsung pour les mémoires Flash de ses téléphones.
Peu de nouveautés le concernant. F2FS gère maintenant les [attributs étendus xattr de sécurité](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8ae8f1627f39bae505b90cade50cd8a911b8bda6). Il est maintenant possible de [remonter à chaud](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=696c018c7718f5e33e1107da19c4d64a25018878) (avec l’option `remount`) les partitions F2FS.
Pour finir, on peut noter un [test de performance](http://www.phoronix.com/scan.php?page=article&item=linux_311_filesystems&num=1) des différents systèmes de fichiers (ext4, Btrfs, XFS et F2FS) sur les noyaux 3.9, 3.10 et 3.11-rc1, en utilisant les options de montage par défaut. Il est difficile de ~~troller~~ faire la comparaison entre les différents systèmes de fichiers étant donné que les options de montage peuvent faire varier de façon sensible les résultats. Il est plus intéressant de voir l’évolution de chaque système de fichiers par rapport au noyau.
### Lustre ###
Vous vous rappelez peut‐être de [Ceph](http://linuxfr.org/news/nouvelle-version-2634-du-noyau-linux#ceph) ? Ceph et Lustre sont des systèmes de fichiers distribués et parallèles utilisés sur les grappes de serveurs. Ceph est déjà intégré dans le noyau depuis des lustres (_sic_). Si l’on veut résumer grossièrement la différence entre Ceph et Lustre : Ceph est utilisé pour sa haute disponibilité, Lustre pour sa haute performance.
La partie client du système de fichiers Lustre est maintenant dans la section _staging_ du noyau (emplacement pour du code en développement mais n’étant pas encore de qualité suffisante pour les exigences des développeurs du noyau). Cela permettra pour l’utilisateur final une facilité d’installation et de mise à jour. Cependant, pour éviter des problèmes de jeunesse de code, il a été [désactivé pour cette version](http://lkml.indiana.edu/hypermail/linux/kernel/1307.0/00398.html).
## Autres améliorations ##
* On pourra à l’avenir [utiliser des applications de Windows RT](http://www.winehq.org/pipermail/wine-devel/2013-July/100438.html) (le Windows qui utilise l’architecture ARM) en utilisant Wine ;
* Mise à jour de [pilotes pour des appareils récents](http://lkml.indiana.edu/hypermail/linux/kernel/1307.0/02389.html).
# Statistiques #
Voici les statistiques des nationalités des développeurs de Linux 3.0 à Linux 3.11 (rc7) pour le nombre de lignes modifiées :
Les nations importantes depuis le noyau 3.0 sont :
- les États‐Unis (moyenne : 20 %, en bleu foncé) ;
- l’Allemagne (moyenne : 8 %, en jaune) ;
- la Chine (moyenne : 7 %, en rouge) ;
- l’Angleterre (moyenne : 6,5 %, en vert) ;
- les Pays‐Bas (moyenne : 4,8 %, en orange).
La France et la Belgique ont chacune une moyenne de 1,3 %.
Il y a quelque chose de remarquable pour ce dernier noyau c’est le pourcentage de la Chine (en rouge) sur le noyau 3.11 (plus de 28 % contre moins de 18 % pour les États‐Unis). Est‐ce que les Chinois vont supplanter l’hégémonie américaine sur le noyau Linux ?
Peut‐être pas encore. Le système de fichiers Lustre a été intégré au noyau Linux 3.11 par Peng Tao, un développeur chinois. Cette modification représente 85 % des lignes modifiés par la Chine. Donc, _a priori_, c’est épisodique.
Il faut tout de même relever le nombre de personnes dont on ne connaît pas la nationalité (moyenne : 24,5 %, en noir).