URL: https://linuxfr.org/news/sortie-de-linux-3-12 Title: Sortie de Linux 3.12 Authors: Collectif Martin Peres, JPEC, Davy Defaud, antistress, Benoît Sibaud, yogitetradim, Anonyme, Yves Bourguignon, Jiehong, djabal, Olivier Esver, Maxime, palm123, Florent Zara, khalahan, Kioob, jcr83, nonas et patrick_g Date: 2013年09月10日T11:08:50+02:00 License: CC By-SA Tags: noyau_linux, coulisses, linus_torvalds, lwn, linux et kernel Score: 102 La sortie de la version stable 3.12 du noyau Linux vient d’être annoncée par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site [_kernel.org_](http://kernel.org/). Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche. À noter que [Linus s’est ravisé en cours de route](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=272b98c6455f00884f0350f775c5342358ebb73f) s’agissant du nom de code à donner à cette version, puisqu’il a finalement opté pour _« One Giant Leap for Frogkind »_, que l’on peut traduire par « un grand pas pour la grenouillité » : Linus semble en effet [avoir été impressionné par la photographie d’une grenouille accompagnant le décollage d’une fusée de la NASA](https://plus.google.com/+LinusTorvalds/posts/9Gjr58KUJcH)... ![La grenouille](http://nieuwsbeest.nl/wordpress/wp-content/uploads/2013/09/kikker2-590x360.png) Enfin, remerciement ~~spatial~~ spécial à [Martin Peres](http://linuxfr.org/users/mupuf) pour son travail titanesque sur la dépêche — dont les passages sur les pilotes graphiques libres. ---- [Noyaux précédents](http://linuxfr.org/wiki/depeches_noyau) [kernelnewbies.org](http://kernelnewbies.org/Linux_3.12) [[Phoronix] Linux 3.12 Changes, Kernel Feature Overview](http://www.phoronix.com/scan.php?page=news_item&px=MTUwMjg) [Site officiel du noyau Linux ](https://www.kernel.org/) ---- #La phase de test ### RC-1 La version [RC-1](http://lkml.indiana.edu/hypermail/linux/kernel/1309.2/00473.html) a été annoncée par Linus le 16 septembre :> Cela fait deux semaines et la phase d’intégration du noyau 3.12 est désormais close.> > L’arborescence _git_ a été mise à jour, les archives de l’ensemble du code source et les correctifs devraient être disponibles aussi, et voici mon « rapport d’intégration synthétique » pour la phase d’intégration : c’est un peu comme un _shortlog_ de _git_ complété par le nom des personnes dont proviennent les changements (_pas_ forcément les auteurs du code, mais les mainteneurs qui m’ont envoyé la demande d’intégration) et accompagné d’une courte description de l’objectif de ces modifications.> > Globalement cette fenêtre d’intégration était plutôt habituelle. Environ 73 % de pilotes, 12 % de mises à jour d’architectures et 6 % de systèmes de fichiers. Le reste étant regroupé dans la catégorie « divers ».> > Personnellement, j’apprécie particulièrement les améliorations d’évolutivité qui ont été intégrées cette fois‐ci. Le verrouillage des couches _tty_ a été nettoyé et, durant ce processus, beaucoup de verrouillages se font désormais par _tty_. Ce qui se remarque lors de quelques (je l’admets, bizarres) montées en charge. Et le travail sur l’évolutivité des _[dentry](http://fr.wikipedia.org/wiki/Virtual_File_System#L.27objet_dentry) refcounts_ a pour conséquence que le cache des noms de fichiers s’adapte dorénavant très bien à un changement d’échelle, même dans le cas où l’on recherche le même répertoire ou fichier (ce qui pouvait historiquement provoquer des blocages du verrou `per-dentry d_lock`).>> Mais ces choses ne sont pas détectables sur des machines normales, je suis juste bizarre et j’ai tendance à m’enthousiasmer pour les améliorations de notre `dentry cache`. Simplement parce qu’il s’agit, à mon avis, de l’une des parties les plus intéressantes du cœur de code. > > Donc, la plupart des personnes seront probablement plus intéressées par les mises à jour de pilotes qui impactent plus concrètement le quotidien. >> Allez‐y, testez.>> Linus ### RC-2 La version [RC-2](https://lkml.org/lkml/2013/9/23/639) a été annoncée le 23 septembre par Linus :> J’aurais vraiment dû ramener mon échéancier de publication au dimanche — il a été perturbé lorsque j’ai fait une publication le jour de la fête du travail, et il est calé sur le lundi depuis lors.> > Mais, bon, je ne l’ai pas fait. Donc, la voilà, une semaine plus tard, la publication de la rc2.> > Les choses ont été plutôt calmes, probablement parce que la semaine dernière beaucoup de gens étaient en transit pour la _LinuxCon_ et la conférence _Linux Plumbers_. Donc, rien de très intéressant ne sort du lot. Ce sont principalement des mises à jour ou corrections de pilotes (les pilotes graphiques en majorité, mais il y a aussi du réseau, et quelques petits trucs par‐ci par‐là). À part les pilotes, il y a eu des mises à jour sur les architectures (TILE, ARM et MIPS) et un peu de brouhaha concernant les systèmes de fichiers (principalement Btrfs).> > Le résumé de publication est à la limite trop gros pour être vraiment lisible, mais je l’ajoute quand même.> > Linus ### RC-3 La version [RC-3](https://lkml.org/lkml/2013/9/29/281) a été annoncée le 29 septembre par Linus :> Je suis revenu à une publication dominicale, donc la voilà, la rc3.>> Rien de spécial ne ressort. Il y a un certain nombre de bouleversements dans `mm`, ce qui est inhabituel à cette étape, mais ce ne sont que des retours arrières : pendant la phase d’intégration, Andrew a envoyé quelques changements qui étaient encore en cours de discussion, et nous revenons dessus pour l’instant.> > Si l’on ignore les changements concernant `mm`, le reste a l’air très normal : le principal est constitué des pilotes (GPU, dm/bcache, USB, audio...), avec l’habituel saupoudrage de changements dans les architectures (PowerPC, x86, ARM, MIPS) et les systèmes de fichiers (UDF, XFS, ReiserFS). Et quelques outils pour les performances.> > Et nous avons eu quelques réglages de performance pour la prise en charge du nouveau verrou sous ARM et s390.> > Dans l’ensemble, pas vraiment de quoi être effrayé. Allez‐y, testez.> > Linus ###RC-4 La version [RC-4](https://lkml.org/lkml/2013/10/6/148) a été annoncée le 6 octobre par Linus :>Hummm. La rc4 contient plus de nouveaux changements que la rc3, ce qui ne me rassure pas vraiment, mais rien ne sort vraiment du lot. Peut‐être plus de mises à jour de systèmes de fichiers qu’attendu à cette étape, mais je soupçonne que ce ne soit qu’un hasard. Nous avons ici des correctifs pour CIFS, XFS, Btrfs, FUSE et NILFS.>>Il y a également les mises à jour classiques de pilotes (principalement réseau et architectures cibles, cette fois), avec également des modifications réseau génériques. Et quelques mises à jour d’architectures (ARM, Power, [S+core](http://en.wikipedia.org/wiki/S%2Bcore), [AVR32](http://en.wikipedia.org/wiki/AVR32).>>Rien d’inquiétant. Donc, allez‐y, testez.>> Linus ###RC-5 La version [RC-5](http://lkml.indiana.edu/hypermail/linux/kernel/1310.1/03776.html) a été annoncée le 13 octobre par Linus :> Ça semble se calmer gentiment et la rc5 est plus petite que les précédentes rc.>> En fait, le plus excitant que nous ayons eu cette semaine n’était même pas un bogue du noyau, c’était un bogue du compilateur wrt `asm goto` qui a été trouvé à cause de code qui est en attente d’intégration dans le 3.13. Mais le contournement (heureusement, plutôt simple) pour ce bogue a été intégré plus tôt, parce que nous utilisons effectivement `asm goto`, et il n’est pas certain que notre utilisation existante puisse déjà déclencher le bogue, juste pas assez pour être remarquable de manière évidente.>> À part cela, la plupart des changements sont les habituelles corrections des architectures (TILE, ARM, x86, s390) et des pilotes (GPU, HID, son, I2C, _watchdog_). Le reste étant constitué de mises à jour de Btrfs et des outils de performances. Et de l’habituel brouhaha.>>Allez‐y, testez.>>Linus ###RC-6 La version [RC-6](http://lkml.indiana.edu/hypermail/linux/kernel/1310.2/02337.html) a été annoncée le 19 octobre par Linus :>Je suis à [PDX](http://en.wikipedia.org/wiki/Portland_International_Airport "Portland International Airport"), sur le point de m’envoler pour le _Kernel Summit_, et c’est presque devenu une tradition que de faire une publication de rc en utilisant le Wi‐Fi de l’aéroport. Donc, la voilà...>>Le fichier correctif est encore en cours d’extraction, mais les arborescences _git_ sont à jour et le fichier _tar_ devrait déjà être sorti. Rien d’important n’est arrivé la semaine dernière, et la semaine à venir va probablement être calme également, puisque nombre des mainteneurs principaux seront à Édimbourg pour le KS.>>Le rapport des modifications détaillé suit, mais, pour résumer, il s’agit principalement de mises à jour de pilotes. USB, [[InfiniBand]], ACPI... Quelques mises à jour de documentation et de CIFS, le reste étant du bruit.>>S’il vous plaît, testez.>>Linus ###RC-7 La version [RC-7](http://lkml.indiana.edu/hypermail/linux/kernel/1310.3/01253.html) a été annoncée le 27 octobre par Linus :>Le _Kernel Summit_ est terminé, et donc la septième — et probablement la dernière -rc pour la 3.12 est sortie, et je suis revenu sur le calendrier habituel du dimanche.>>Le ralentissement dans la taille des -rc s’est malheureusement inversé cette fois, principalement à cause de mises à jour de la partie réseau qui n’étaient pas incluses dans les rc5 et rc6. Vous pouvez voir ça dans le rapport avec plus de 50 % de correctifs réseau (à la fois les pilotes et le noyau). Le reste est principalement composé des autres pilotes (GPU, media, SCSI, _thermal_, HID) et de plus petites mises à jour sur les architectures (s390, PA-RISC, x86).>>Rien ne semble particulièrement surprenant. Donc, nous sommes toujours sur la bonne voie pour la 3.12. Ce qui signifie que la fenêtre d’intégration pour la 3.13 va probablement finir par être un peu foirée, d’autant plus que j’ai encore des voyages à venir.>>Je peux habituellement planifier en tenant compte de ces aléas, mais avec deux voyages et juste une semaine entre les deux, j’ai le choix de retarder la 3.12 pour aucune raison valable, ou juste dire : « OK, nous allons garder la fenêtre d’intégration ouverte un peu plus longtemps, parce que je ne serai pas aussi réactif que je le devrais. »>>Mais, qui sait ? Si quelque chose de particulièrement effrayant arrive pendant la semaine prochaine, je dirai probablement simplement : « OK, nous allons faire une rc8 à la place. » Donc, je garde mes options ouvertes.>>Linus #Les nouveautés ## CPU-Freq La politique _on-demand_ (à la demande) de `cpufreq` permet de faire varier les fréquences de votre processeur de façon à économiser de l’énergie au maximum, sans dégrader les performances. Cependant, le comportement de la politique _on-demand_ ne correspondait pas forcément au comportement attendu pour certaines charges de travail, comme l’a [fait remarquer Stratos Karafotis](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dfa5bb622555d9da0df21b50f46ebdeef390041b). Le résultat a eu comme effet de bord d’améliorer considérablement les performances dans les jeux vidéo, avec des améliorations du nombre d’images par seconde [jusqu’à 87 % pour le pilote radeon](http://www.phoronix.com/scan.php?page=article&item=amd_linux312_preview&num=1) et [40 % pour Nouveau](http://www.phoronix.com/scan.php?page=article&item=linux_312_nv). Une explication plus complète de cette soudaine envolée des performances est [disponible sur _Phoronix_](http://www.phoronix.com/scan.php?page=article&item=linux_312_performance&num=1) et [traduite et commentée dans ce journal sur _LinuxFr.org_](https://linuxfr.org/users/savitzkaia/journaux/amelioration-des-performances-graphiques-du-noyau-3-12). ## Pilotes graphiques libres ### DRM #### Render nodes Historiquement, l’ouverture d’un descripteur de fichier sur un pilote graphique DRM n’apportait aucun droit, tant qu’un `DRM_MASTER` n’autorisait pas l’application à utiliser le processeur graphique. Le `DRM_MASTER` est l’équivalent d’une capacité qui est attribuée au premier programme qui utilise le processeur graphique depuis la dernière commutation de terminal virtuel (_VT-switch_). Ce programme est typiquement le serveur graphique X. Une fois l’authentification effectuée, le programme qui a ouvert le descripteur de fichier a le droit d’exécuter toutes les fonctions exposées par l’interface DRM et par le pilote. Une application peut ensuite faire son rendu dans un tampon graphique puis partager ce tampon en utilisant `gem_flink()`. Cette fonction permet de rendre le tampon public en l’identifiant par un numéro. L’application doit ensuite envoyer ce numéro au serveur graphique pour que celui‐ci puisse l’importer avec `gem_open()`. Le problème principal de cette approche est qu’une fois le tampon partagé, toutes les applications authentifiées peuvent deviner ce numéro, puis lire et modifier ce tampon. Il y a donc des problèmes de confidentialité et d’intégrité sur le contenu des fenêtres. La nouveauté principale de cette nouvelle version du noyau est la création des nœuds de rendu (_render nodes_). Ceux‐ci exposent seulement un sous‐ensemble des capacités du pilote, de façon à permettre aux applications de s’exécuter sans pouvoir interagir avec d’autres applications sans leur consentement. Ces nœuds sont dédiés à toutes les applications utilisant le processeur graphique pour faire des calculs graphiques, du calcul générique ([[GPGPU]]), du décodage ou de l’encodage vidéo. L’appel `gem_flink()` n’est pas autorisé sur les _render nodes_, il est nécessaire d’utiliser [`DMA-BUF`](https://www.kernel.org/doc/Documentation/dma-buf-sharing.txt) pour partager ses tampons. Pour garder la compatibilité avec les applications actuelles, un nouveau périphérique a été créé dans `/dev`. Pour utiliser un _render node_, il est maintenant nécessaire d’ouvrir `/dev/dri/renderD128` au lieu de `/dev/dri/card0`. Ce travail a été commencé par [Dave Airlie](http://airlied.livejournal.com/72187.html), qui voulait introduire les _modesetting nodes_ pour améliorer le support du multi‐siège (partager un ordinateur entre plusieurs utilisateurs de bureau). Suite aux [discussions du XDC2012 liées à la sécurité](https://lwn.net/Articles/517375/), Kristian Høgsberg a [proposé](http://lists.freedesktop.org/archives/dri-devel/2012-September/028338.html) les _render nodes_ en combinaison avec `DMA-BUF`. Le but étant de résoudre des problèmes de sécurité des bureaux sous GNU/Linux et de supprimer la procédure d’authentification ridicule qui empêche une application d’utiliser le processeur graphique si un serveur graphique n’est pas en cours d’exécution. Martin Peres a ensuite [proposé](http://lists.freedesktop.org/archives/dri-devel/2012-December/032107.html) les modifications nécessaires au protocole DRI2, à la bibliothèque libdrm, au serveur X et à l’infrastructure Mesa 3D pour utiliser les _render nodes_ de façon transparente dans l’environnement X11. David Herrmann a ensuite [soumis un projet](https://dvdhrm.wordpress.com/2013/05/29/drm-render-and-modeset-nodes/) à la [fondation X.org](http://www.x.org/wiki/XorgFoundation/), dans le cadre du _Google Summer of Code 2013_. Celui‐ci a retravaillé, sous la direction de Dave Airlie, les modifications de Kristian Høgsberg, et c’est sa version qui a été envoyée à Linus pour inclusion. Les _modesetting nodes_ sont, eux, encore en cours de discussion. Ceux‐ci sont dédiés aux serveur X et compositeur Wayland. Ils permettront de faire les opérations privilégiées, telles que gérer la résolution de l’écran ou importer des tampons graphiques GEM venant d’autres applications, tout en respectant la notion de siège. Pour plus d’informations, vous pouvez consulter le [_blog_ de David Herrmann](https://dvdhrm.wordpress.com/2013/09/01/splitting-drm-and-kms-device-nodes/). #### Gestion de la mémoire (GEM/TTM) Avec l’introduction des _render nodes_, il est important que l’API de DRM garantisse l’isolation entre les différents clients. Il est donc devenu urgent de résoudre une faille de sécurité liée à la gestion des accès aux tampons graphiques par le processeur central. Ce travail a encore une fois été effectué par David Herrmann, dans le cadre de son _GSoC 2013_. Quand un client demande un accès à un tampon par le processeur central, celui‐ci demande à DRM d’exposer ce tampon à une adresse fixe de son nœud. Le client peut ensuite invoquer [`mmap()`](http://fr.wikipedia.org/wiki/Mmap)] pour rendre le tampon accessible dans son espace d’adressage virtuel, et accéder au tampon comme s’il avait été alloué avec [`malloc()`](http://fr.wikipedia.org/wiki/Malloc). Le problème est que n’importe quelle application peut faire correspondance la même zone mémoire, et accéder au tampon sans contrôle d’accès. Deux solutions ont été proposées : * rendre local l’espace d’adressage exposé par le nœud ; * contrôler l’accès aux tampons lors de l’appel à `mmap()` (solution la plus simple). La première solution consiste à ne pas faire de contrôle d’accès, mais simplement avoir un espace d’adressage différent par client. Lors de l’appel à `mmap()`, il suffit donc de charger le bon espace d’adressage virtuel en fonction du client qui fait la demande. Cela ressemble beaucoup à la façon dont la mémoire est partagée entre les différents processus d’un système, et c’est la plus élégante. La deuxième solution est de garder global l’espace d’adressage (partagé entre tous les clients), mais de vérifier qu’un client a le droit d’accéder à un certain décalage + taille. C’est cette solution qui a été retenue, car elle est la moins invasive. Cependant, il existe deux allocateurs de mémoire vidéo dans Linux, [GEM](http://fr.wikipedia.org/wiki/Graphics_Execution_Manager) et TTM. Plutôt que de dupliquer le code lié au `mmap()`, et comme l’implémentation de TTM est meilleure, il a été décidé que GEM devrait utiliser l’implémentation de TTM. Pour plus d’informations, vous pouvez lire le message de [_commit_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fe3078fa5c367186c94a6652581ffbe9ccea4640). Une fois les implémentations GEM et TTM unifiées, le code pour gérer la gestion des accès a été ajouté. Chaque tampon graphique maintient sa liste de clients qui ont le droit de faire des accès depuis le processeur central. Lorsqu’un client essaye de projeter un tampon graphique dans son espace d’adressage virtuel, DRM vérifie qu’il appartient bien à la liste des clients autorisés. Si c’est le cas, le `mmap()` réussit. Sinon, une erreur est retournée. Pour plus d’informations, vous pouvez lire le message de [_commit_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=88d7ebe59341dc3b82e662b80809694e3c6b3766). #### Autres Voici quelques autres modifications apportées à DRM. En vrac : * squelette pour la gestion de la commutation de tampon vidéo (_page flipping_) asynchrone ; * ajout de la prise en charge des ponts DRM ([_DRM bridges_](http://lists.freedesktop.org/archives/dri-devel/2013-August/043714.html)) ; * [prise en charge](http://lists.freedesktop.org/archives/dri-devel/2013-August/043125.html) des _InfoFrames_ HDMI et des modes 4K (ultra HD) ; * corrections de bogues liés aux verrous dans GEM/Prime. ### Intel (pilote i915) Avec Linux 3.12, le pilote i915 diminue la consommation énergétique des processeurs Haswell grâce à l’ajout du prise charge du PC8+ et du _Panel Self‐Refresh_. Le mode PC8+ est le mode d’endormissement le plus profond, introduit dans les processeurs Haswell. Ce mode permettra d’économiser plus d’énergie dans les cas d’utilisation où le périphérique doit constamment rester allumé. C’est, par exemple, le cas des tablettes graphiques qui ne peuvent pas se permettre d’utiliser la fonction de mise en veille. Le _Panel Self‐Refresh_ est la fonctionnalité de rafraîchissement autonome de l’écran. Celle‐ci est désactivée par défaut, à cause d’un problème de suivi d’état du _front buffer_ avec X. Certains processeurs graphiques Haswell / Iris Pro ont aussi vu l’activation de leur cache de 128 Mio, ainsi que quelques modifications pour le rendre plus efficace. Une autre fonctionnalité importante apportée par ce noyau est l’ajout de la prise en charge des [résolutions 4K](https://en.wikipedia.org/wiki/4K_resolution) avec le HDMI. La plupart des fonctionnalités nécessaires pour la prise en charge d’un espace d’adressage par processus ont aussi été fusionnées dans ce noyau. Si tout se passe bien, Linux 3.13 devrait voir arriver la prise en charge complète de cette fonctionnalité, ce qui devrait augmenter l’isolation entre les différents clients graphiques, et donc, augmenter la sécurité des nœuds de rendu (_render nodes_). Pour finir, Jesse Barnes a ajouté la prise en charge du _fastboot_. Ce mode permet d’améliorer la vitesse de démarrage en essayant de réutiliser le mode graphique mis en place par UEFI. Il n’est pas encore utilisé par défaut, car il utilise quelques bidouilles pour fonctionner. Ces bidouilles devraient être supprimées dans la prochaine version du noyau. Si vous ne voulez pas attendre jusque‐là, vous pouvez utiliser le paramètre noyau `i915.fastboot=1` pour activer le mode _fastboot_. Pour plus d’informations, vous pouvez consulter la [publication sur le _blog_ de Daniel Vetter](http://blog.ffwll.ch/2013/09/neat-drmi915-stuff-for-312.html), mainteneur du sous‐système DRM du pilote graphique i915. ### NVIDIA (pilote Nouveau) La nouveauté principale pour ce pilote est la prise en charge de l’extinction automatique de la carte si aucun programme ne l’utilise depuis plus de 5 secondes. Cela devrait réduire la consommation électrique de 5 ou 6 W sur un ordinateur portable équipé de la technologie Optimus, lorsque celui‐ci utilise uniquement le processeur graphique Intel. Cette prise en charge a été ajoutée par Dave Airlie, mainteneur du sous‐système DRM du noyau. Cette nouvelle version apporte aussi le décodage vidéo matériel sur les cartes équipées des moteurs VP3 ou VP4. Cela concerne les puces NV98, NVA3, NVA5, NVA8, NVAA and NVAC. Malheureusement, la prise en charge du H.264 est instable, et n’est donc pas activée par défaut. Pour plus d’informations, vous pouvez consulter la [page Wiki du projet](http://nouveau.freedesktop.org/wiki/VideoAcceleration/). Comme pour l’ajout de la prise en charge de VP2, cette contribution nous vient de Ilia Mirkin. Ce nouveau noyau a aussi tenté d’activer par défaut les interruptions [MSI](https://en.wikipedia.org/wiki/Message_Signaled_Interrupts). Cependant, trop de cartes ne marchaient plus et cette prise en charge a été désactivée par défaut. Comme NVIDIA a récemment annoncé un [effort d’ouverture](https://linuxfr.org/users/nonolapero/journaux/effort-d-ouverture-de-la-part-de-nvidia) envers la communauté de Nouveau, Luca Stash [a demandé](http://www.mail-archive.com/nouveau@lists.freedesktop.org/msg14127.html) s’il y avait des _errata_ connus liés aux interruptions MSI. Un peu moins d’un mois plus tard, Robert Morell, de chez NVIDIA, a répondu en expliquant la procédure à suivre sur plusieurs puces. Il est dommage que la réponse ait pris autant de temps, car Ben Skeggs avait entre‐temps déjà effectué la rétro‐ingénierie permettant la prise en charge de presque toutes les cartes. Les informations complémentaires de NVIDIA ont cependant permis de compléter la prise en charge d’une puce graphique assez commune (NV92). Andy Ritger en a aussi profité pour envoyer de la [documentation du matériel](http://http.download.nvidia.com/open-gpu-doc/gk104-disable-underflow-reporting/1/gk104-disable-underflow-reporting.txt) pour expliquer un autre _errata_ qui rendrait par défaut une partie de l’écran rouge, si le débit mémoire était insuffisant. C’est la première documentation du matériel que nous recevons, et elle est assez détaillée ! C’est ce genre de documentation que l’équipe de Nouveau espère obtenir en plus grand nombre dans le futur, car il est très difficile de diagnostiquer un tel problème, puis de trouver quel registre est responsable de cette erreur. Les informations de NVIDIA ont été mises à profit par la communauté. Les interruptions MSI devraient être activées par défaut dans Linux 3.13, et le bogue de configuration rendant l’écran partiellement rouge devrait aussi être résolu. ![Une partie de l’équipe de Nouveau en compagnie de Andy Ritger de NVIDIA](http://fs.mupuf.org/mupuf/nvidia/images/nouveau_nvidia.jpg) _Une partie de l’équipe de Nouveau en compagnie de Andy Ritger de NVIDIA (deuxième en partant de la droite). Photo prise à l’extérieur des locaux de SUSE Linux à Nuremberg, en septembre 2012._ ### ATI/AMD (pilote radeon) Du côté des améliorations qui seront appréciées pour cette nouvelle version, citons la gestion d’énergie pour les cartes ATI/AMD [apparue avec la version précédente du noyau](https://linuxfr.org/news/linux-pour-workgroups-3-11-le-noyau-pret-pour-le-bureau#atiamd-pilote-radeon), avec la prise en charge d’ASPM (_Active State Power Management_) et DPM (_Dynamic Power Management_) pour les nouvelles cartes Radeon HD 8000 (Sea Islands / CIK) qui viennent compléter la liste des cartes prises en charge. Ce noyau apporte aussi la prise en charge des futurs processeurs à puce graphique intégrée ([APU](http://fr.wikipedia.org/wiki/Accelerated_Processing_Unit)) [Berlin](http://pro.clubic.com/it-business/serveur-informatique/actualite-566444-roadmap-amd-serveurs-processeurs-arm-apu.html), qui devraient sortir début 2014. Du coté des changements plus cachés, le déplacement des tampons graphiques (BO) entre les différentes mémoires a été réécrit de façon à utiliser un contrôleur d’accès direct à la mémoire ([DMA](http://fr.wikipedia.org/wiki/Direct_Memory_Access)), à la place du moteur 3D de la carte. On peut supposer que ce changement permettra de moins pénaliser les performances 3D lorsqu’une application manque de mémoire graphique, car le rendu pourra continuer à se faire pendant que les tampons non utilisés seront déplacés dans la mémoire centrale. Il est aussi à noter plusieurs nettoyages et plusieurs corrections de bogues. ### Adreno (pilote msm) Parmi les nouveautés de ce noyau à souligner, citons la prise en charge des cœurs graphiques [[Adreno]] qui équipent les [SoC](http://fr.wikipedia.org/wiki/SoC) (_Systems on Chip_, ou systèmes sur une puce) d’architecture ARM produits par [Qualcomm](http://fr.wikipedia.org/wiki/Qualcomm) (sous l’appellation [[Snapdragon]]) et que l’on retrouve, par exemple, dans le [Samsung Galaxy S4](http://fr.wikipedia.org/wiki/Samsung%20Galaxy%20S4). Le pilote, nommé Freedreno et développé par [rétro-ingénierie](http://fr.wikipedia.org/wiki/r%C3%A9tro-ing%C3%A9nierie), est un pilote 2D et 3D qui prend en charge la gestion des modes d’affichage par le noyau ([KMS](http://fr.wikipedia.org/wiki/Kernel-based_mode-setting)), et s’appuie sur l’infrastructure 3D commune [Gallium3D](http://fr.wikipedia.org/wiki/Gallium3D). Cette version du noyau [intègre le pilote DRM](http://permalink.gmane.org/gmane.linux.ports.arm.msm/4970) (nommé _msm_), tandis que Mesa 9.2, [sorti le 27 août dernier](http://lists.freedesktop.org/archives/mesa-announce/2013-August/000061.html), [intègre le pilote Gallium3D](http://cgit.freedesktop.org/mesa/mesa/tree/docs/relnotes/9.2.html). Cette avancée majeure est due principalement à Rob Clark ([blogue](http://bloggingthemonkey.blogspot.fr/)). Ce pilote DRM vient remplacer le pilote du constructeur, spécifiquement conçu pour Android. Une particularité intéressante de [l’espace utilisateur de ce pilote (parties DDX et DRI)](http://fr.wikipedia.org/wiki/Pile_graphique_Linux#Composition_d.E2.80.99un_pilote_graphique_libre_sous_Linux) est qu’il est également compatible avec celui du constructeur. Cependant le pilote DRM msm est le seul à prenant en charge le nouveau gestionnaire d’affichage [[Wayland]] et son compositeur de référence Weston. Pour plus d’informations, Rob Clark a donné une [présentation](http://www.x.org/wiki/Events/XDC2013/XDC2013RobClarkARMOpenSource/) sur l’état des pilotes graphiques ARM au [XDC2013](http://www.x.org/wiki/Events/XDC2013/). Il en a profité pour faire une [démonstration](https://www.youtube.com/watch?v=n1fSfANH9tU#t=2280) de sa pile graphique libre pour Adreno. Vous pouvez aussi consulter la dépêche [_État des pilotes graphiques libres pour SoC_](https://linuxfr.org/news/etat-des-pilotes-graphiques-libres-pour-soc) et le [wiki de Freedreno](https://github.com/freedreno/freedreno/wiki#status). ### Divers ARM Outre l’ajout du pilote DRM _msm_ pour les processeurs graphiques Adreno, la prise en charge d’un autre processeur graphique R-Car fait son apparition pour les [systèmes monopuces](http://fr.wikipedia.org/wiki/SoC), R8A7790. Cette prise en charge se limite pour l’instant à la gestion des modes d’affichage (_modesetting_), ainsi qu’à l’émulation [_fbdev_](http://fr.wikipedia.org/wiki/Framebuffer_Linux). Il n’y a donc, pour l’instant, aucune accélération disponible. Du coté du pilote [Exynos](https://en.wikipedia.org/wiki/Exynos), une meilleure gestion d’énergie devrait être disponible pour le moteur G2D. Cette version du noyau est aussi l’occasion pour Exynos de [passer](https://lkml.org/lkml/2013/7/26/176) au [_Device Tree_](https://en.wikipedia.org/wiki/Device_tree). Rien de neuf pour le pilote [Tegra](https://fr.wikipedia.org/wiki/Tegra), à part quelques corrections de bogues. ## Systèmes de fichiers ### Btrfs Dans cette version de Btrfs, [deux nouvelles fonctionnalités](http://lkml.indiana.edu/hypermail/linux/kernel/1309.1/02981.html) font leur apparition, la prise en charge des [[UUID]] pour les sous‐volumes et celle de la déduplication hors‐ligne. Gérer les [[UUID]] pour les sous‐volumes permet de résoudre un problème de performance qui apparaissait lorsque le système de fichiers utilise beaucoup de sous‐volumes ou d’instantanés du système de fichiers (_snapshots_). La prise en charge de la déduplication hors‐ligne permet à une application en espace utilisateur de scanner le système de fichiers à la recherche de duplications, même si celui‐ci est monté. Le noyau vérifiera ensuite par lui‐même que les fichiers sont bien des duplicatas, et fera une déduplication. Ceci est un travail initial qui devrait s’améliorer dans les futures versions du noyau. Un programme expérimental utilisant cette nouvelle fonctionnalité est déjà disponible sous le nom de [`bedup`](https://btrfs.wiki.kernel.org/index.php/Deduplication). ### ext4 Au programme pour ext4 dans cette nouvelle version du noyau, une [nette amélioration des performances](http://www.phoronix.com/scan.php?page=news_item&px=MTQ5MzI), ainsi qu’une amélioration de la reprise sur panne lorsque le volume est monté avec le paramètre `errors=ignore`. L’amélioration des performances est due à une nouvelle politique de mise en cache agressive des [_extents_](https://fr.wikipedia.org/wiki/Extent). Cette nouvelle politique permettrait, d’après son créateur, de réduire la consommation mémoire et d’apporter des améliorations pour les entrées‐sorties asynchrones. Pour plus d’informations, voir le [_pull request_ de Ted Ts’o](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ae67d9a888a000a9df43de10eb9950075e93508c). ### F2FS Du coté du système de fichiers [F2FS](https://fr.wikipedia.org/wiki/F2FS) (_Flash‐Friendly File System_), on trouve des améliorations de [performance](http://www.phoronix.com/scan.php?page=news_item&px=MTQ1OTE), la prise en charge à la volée des attributs étendus, des options pour contrôler le ramasse‐miettes (_garbage collector_) via `sysfs` et, bien sûr, des corrections de bogues. Pour rappel, F2FS est à destination des mémoires Flash NAND et est sponsorisé par Samsung. Pour plus d’informations sur les nouveautés de ce noyau, vous pouvez consulter le [_pull request_ de Kim Jaegeuk](https://lkml.org/lkml/2013/9/5/77). ### Z-RAM Avec Linux 3.12, Z-RAM sort enfin de la zone _staging_. Les principales [raisons invoquées](http://lkml.indiana.edu/hypermail/linux/kernel/1308.1/03476.html) sont que Z-RAM a vécu un long moment dans _staging_, a reçu beaucoup d’améliorations et a un large panel d’utilisateurs connus et réputés. Pour plus d’informations, vous pouvez consulter la [demande d’intégration de Kim Minchan](http://lkml.indiana.edu/hypermail/linux/kernel/1308.1/03472.html). #Le bilan en chiffres En ce qui concerne les statistiques du cycle de développement du noyau 3.12, le site _LWN.net_ a publié son traditionnel [article récapitulatif](http://lwn.net/Articles/570483/). En nombre de modifications, on se situe, avec 10 966 correctifs, un poil au dessus de la version 3.11 (10 893 correctifs), à relativement bonne distance du record de la version 3.10 (13 637 correctifs), selon [les chiffres du site _www.remword.com_](http://www.remword.com/kps_result/3.12_petop.html). Idem, pour le nombre de développeurs différents, qui s’établit pour cette version à 1 374 contre 1 306 pour la version précédente, et 1 427 pour l’antépénultième. Les contributeurs les plus prolifiques de ce cycle sont Sachin Kamat, auteur de 261 modifications, Jingoo Han, à l’origine de 243 modifications, et Greg Kroah‐Hartman, qui ferme la marche avec 214 modifications. Mark Brown loupe le podium de peu avec 210 modifications, tandis que H. Hartley Sweeten, qui poursuit sa croisade pour nettoyer le sous‐système _[comedi](http://www.comedi.org/)_ (périphériques d’acquisition de données) et parvient cette fois à alléger le noyau de 21 000 lignes de code, échoit cette fois à la cinquième place (rappelons qu’il a occupé la première place cinq fois au cours des sept dernières versions, un score proche de celui de Rafael Nadal sur la terre battue de Roland Garros). À noter que Rob Clark (que nous avons cité plus haut pour son travail de développement d’un pilote pour puces graphiques Adreno) n’arrive que 101^e au classement, mais, d’une part, la structure de [la pile graphique libre sous GNU/Linux](http://fr.wikipedia.org/wiki/Pile_graphique_Linux) implique que seule une petite partie du pilote intègre le noyau, et, d’autre part, cela ne rend pas justice à la tâche qu’il accomplit avec quelques autres (dont Luc Verhaegen) pour produire [des pilotes graphiques libres pour systèmes monopuces ARM](http://linuxfr.org/news/etat-des-pilotes-graphiques-libres-pour-soc). Si l’on regarde le classement des entreprises, Intel, Linaro et Red Hat (dans cet ordre, cette fois, avec une confortable avance pour Intel) continuent de s’accaparer le podium (avec les contributeurs sans affiliation particulière). #Pour la suite En ce qui concerne les futures nouveautés des prochaines versions du noyau, on peut se tourner vers la [page spécifique](http://www.linuxfoundation.org/en/Linux_Weather_Forecast) de la Fondation Linux. ![Le chiffre "4"](http://farm1.staticflickr.com/193/486676439_fdbf8f24db.jpg) Par ailleurs, il est possible que Linus tienne compte des remarques qui lui ont été faites au [_Kernel Summit_](http://events.linuxfoundation.org/events/linux-kernel-summit) et à la [_LinuxCon Europe_](http://events.linuxfoundation.org/events/linuxcon-europe), et que, dans l’année à venir, une version 4.0 « stable » du noyau soit publiée... Enfin, si suffisamment de contributeurs sont intéressés ! Voilà en effet ce qu’il a dit dans le [courriel annonçant la sortie du noyau 3.12](http://lkml.indiana.edu/hypermail/linux/kernel/1311.0/00914.html) :>Sur un sujet totalement différent : nous arrivons à des numéros de version où je dois _« enlever mes chaussettes »_ pour arriver à compter à nouveau si haut. Je suis d’accord avec _3._, mais je ne veux pas que nous arrivions à des nombres de fous comme ceux que nous avions dans la série 2._x_. Donc, à un moment donné, nous allons passer de 3._x_ à 4._x_, juste pour garder des numéros petits et faciles à retenir. Nous n’y sommes pas encore, mais en fait, je voudrais éviter d’aller dans les vingts. Donc je le verrais bien arriver dans un an à peu près, et nous aurons la 4.0 qui suivra la 3.19, ou quelque chose comme ça.>>Maintenant, c’est juste un numéro (puisque nous avons abandonné les versions par fonctionnalité depuis un moment), et c’est pas avant un an au plus tôt, alors pourquoi je le mentionne déjà ? >>La raison pour laquelle je le mentionne, c’est parce que je ressassais quelque chose que Dirk Hohndel avait déclaré lors de la _LinuxCon Europe_ et au _Kernel Summit_. Il a demandé, lors de la session de questions‐réponses, si nous pouvions faire une version orientée stabilité et corrections de bogues uniquement, et je l’avais dénigré (_« pooh‐poohed »_) parce que je n’ai pas l’impression que la plupart d’entre nous ont la capacité d’attention nécessaire (_[toux]_, _[toux]_, débile, créature des bois, _[toux]_, _[toux]_).>>Donc, je suis peut‐être pessimiste, mais je m’attends à ce que de nombreux développeurs disent : _« Allons chasser les bogues... Attendez ! Oh, brillant ! »_, et partent faire une nouvelle fonction à la place. Ou, tout simplement, arrêter cette version.>>Mais, je me demande... Peut‐être que c’est possible et que je projette injustement mon propre _« écureuil intérieur »_ sur les autres développeurs du noyau. Si nous avons assez de retours, et que les gens savent que, pour une version (et les entreprises et meneurs le savent aussi), les seuls correctifs qui seraient acceptés concerneraient des corrections de bogues, alors peut‐être que les gens se concentreraient vraiment pour que ça puisse fonctionner.>>Et la raison pour laquelle je mentionne la « 4.0 », c’est que ce serait le moment parfait pour le faire. Dans environ un an : _« Allez, après la 3.19 (ou autre), nous faisons une version avec seulement des corrections, puis cela deviendrait la 4.0. »_>>Des commentaires ?>>Linus En attendant, comment dit le _boss_ déjà ? Ah, oui : allez‐y, testez ! :) [[_source de l’image_](https://secure.flickr.com/photos/boklm/486676439/)]

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