Sommaire
En bref
- Pilotes graphiques libres :
- DRM : interface unifiée pour la gestion des plans graphiques ;
- Radeon : gestion de l’encodage vidéo matériel et d’une nouvelle puce unifiée avec processeur graphique intégré (APU) ;
- Nouveau : gestion initiale de la famille Kepler et meilleure gestion des ventilateurs.
- Réseau :
- amélioration forte des performances ;
- affectation de règles iptables à un cgroup.
- Systèmes de fichiers :
- réduction du temps de réveil après une mise en veille en mémoire vive ;
- nouvel appel système pour échanger les noms entre deux fichiers de façon atomique ;
- verrous POSIX par fichier ;
- ajout de la gestion de l’algorithme de compression LZ4 pour zram.
La phase de test
RC-1
La version RC-1 est sortie le 13 avril 2014.
Ça fait deux semaines que la 3.14 a été livrée et la 3.15-rc1 est maintenant étiquetée et publiée ; les correctifs et les archives tar » sont — au moment où j’écris ces lignes — en train de passer dans les compresseurs de kernel.org. Ce qui veut dire que la fenêtre de fusion est fermée et que les gens doivent m’envoyer uniquement des corrections de bogues.
Et franchement, il était temps. Cette version ne contient pas vraiment de choses bizarres, mais elle est grosse. Bien sûr, nous avons déjà eu des versions avec plus de lignes et de fichiers modifiés (3.7-rc1 et 3.11-rc1, notamment), mais celles-ci ont tendance à avoir quelque chose de particulier dedans (3.7-rc1 a vu la désintégration largement automatisée du fichier d’en-tête UAPI et la 3.11 a vu la fusion de la correction des bogues de Lustre).
En comparaison de ces grosses versions, 3.15-rc1 est seulement grosse. Pas de gros changement unitaire, mais seulement énormément de correctifs. Effectivement, il y a eu quelques intégrations de nouveaux pilotes (rtl8723au, notamment). Mais, même s’ils étaient gros, ils ne représentent pas la majorité des changements. Il y a seulement énormément de changements.
En fait, nous avons le plus grand nombre de correctifs dans l’histoire récente (peut-être depuis toujours), à un peu plus de 12 000 correctifs hors fusions (et environ 800 fusions).
Et il y en a vraiment un peu partout. L’essentiel concerne les modifications de pilotes, ce qui représente environ trois quarts des modifications. Le staging se démarque, mais c’est vraiment sur tout le périmètre des pilotes, avec le réseau, le son, les médias, les pilotes graphiques, les pilotes de blocs…
Mais il y a aussi des tonnes de trucs qui ne concernent pas les pilotes. En dehors du sous-répertoire des pilotes, les mises à jour d’architecture comptent environ pour la moitié des changements (avec en tête ARM, principalement dû aux « device-tree descriptors ». Mais il y a aussi IPS, x86, PowerPC, s390, Blackfin…). Et le reste est aussi assez varié, avec le cœur du réseau, la documentation, le noyau, mm, les outils, etc.
Ainsi, alors que les modifications de pilotes et d’architecture représentent l’essentiel, nous avons aussi beaucoup de changement du cœur.
Quoi qu’il en soit, encore plus que d’habitude, la RC-1 est beaucoup trop grande pour inclure un résumé du rapport de toutes les publications. Mais le résumé du rapport des fusions que j’ai fait peut donner à minima une vue d’ensemble de tous les changements. Comme d’habitude, les personnes citées dans le rapport de fusion sont les mainteneurs depuis que j’ai récupéré les changements, et non les développeurs qui ont écrit le code. Vous pouvez voir ça dans les journaux complets de git.
Quoi qu’il en soit, comme la RC-1 est déjà sacrément grosse, je ne veux pas entendre de « désolé j’ai raté la fenêtre, puis-je encore me faufiler ? ». Corrections uniquement.
La seule exception concerne deux choses en cours qui sont arrivées pendant la fenêtre de fusion, mais qui ont été explicitement retardées. Nous avons donc en attente un mouvement de fichier fbdev (je ferai le mouvement du fichier après la RC-1, simplement pour que les choses soient plus simples à voir dans l’historique et ne pas mélanger les mouvements avec les développements). Et il y avait une demande de fusion sur les espaces de noms et montages que je n’ai pas intégrée, mais que je ferai probablement après quelques améliorations ou commentaires supplémentaires. Ça retardera probablement la 3.16, mais nous verrons de combien de lignes de code ce truc a besoin…
Linus
RC-2
La version RC-2 est sortie le 20 avril 2014.
« Et le septième jour la RC est ressuscitée, conformément aux Écritures du Kernel summit de l’année 2004. »
Cela fait une semaine, donc voici une nouvelle RC. Et alors que la RC-1 était de mémoire une des plus grosses RC, la RC-2 a l’air tout à fait normale. Nous avons eu quelques erreurs tenaces corrigées, mais ce n’était pas réellement quelque chose de pire que d’habitude. C’est peut‐être un peu plus gros que la plupart des RC-2, mais attendons de voir après la RC-3 quelles choses sont vraiment plus actives que d’habitude. La RC-2 est régulièrement plus calme que la RC-3, car il faut plus d’une semaine pour que certaines anomalies surviennent.
Quant à ce qu’il s’est passé au cours de la semaine dernière, le gros du correctif RC-2 est, en fait, la suppression du pilote RTL8187SE de staging, car il y en a maintenant un bon en dehors de staging. C’est vraiment un peu plus de la moitié du correctif en lui‐même. Mais, même si vous ignorez tout simplement cette sortie, les autres changements de pilotes représentent environ les deux tiers du reste (pilote graphiques, réseau, renommage des fichiers fbdev, IPMI, InfiniBand, pin control… Nommez votre pilote préféré). La partie concernant le DRM est probablement la plus remarquable.
En dehors des pilotes, nous avons les mises à jour habituelles d’architectures (principalement x86 et s390, un peu de PA-RISC) et quelques mises à jour de documentation. Quelques corrections pour le réseau et des mises à jour de système de fichiers (CIFS, sysfs, XFS). Et quelques trucs d’outillage.
Testez, s’il vous plaît,
Linus
RC-3
La version RC-3 est sortie le 27 avril 2014.
Nouvelle semaine, nouvelle RC. Jusqu’à présent, pas de grosses craintes et la RC-3 est adéquatement plus petite que la RC-2 ne l’était, nous sommes donc sur la bonne voie.
Les statistiques semblent relativement normales, avec une moitié de pilotes (pilote d’entrées, USB, pilotes graphiques, ACPI, régulateur…) et un tiers de mises à jour d’architectures (la majorité portant sur les fichiers DTS pour ARM, mais aussi d’autres mises à jour sur ARM et user-mode). Le reste est varié, mais principalement concentré sur les mises à jour des systèmes de fichiers (Btrfs et ext4).
Linus
RC-4
La version RC-4 est sortie le 4 mai 2014.
Rien de particulièrement exceptionnel en cours. 45 % de pilotes (DRM, son, [md](http://en.wikipedia.org/wiki/Mdadm "multiple device), pin-control, ACPI, etc.), 40 % d’architecture (principalement powerpc/powernv, mais aussi x86 et ARM), 15 % de divers (outillage de performance, mises à jour documentaires et code du noyau). Le rapport simplifié ci‐joint donne un bon aperçu des détails sans être trop gros.
Il y a encore quelques trucs en cours (par exemple, une correction en attente pour une intéressante corruption de la liste des « entrées de répertoires » (dentry) — même si une utilisation normale aura peu de risque d’être affectée). Mais, dans l’ensemble, c’est relativement calme et il n’y a rien d’horriblement effrayant. Nous sommes au milieu de la période d’apaisement, donc c’est comme je l’aime.
Mais, plus nous avons de tests, mieux c’est ; donc, s’il vous plaît, essayez-la.
Linus
RC-5
La version RC-5 est sortie le 9 mai 2014.
Oui, je suis conscient que c’est en avance de deux jours. Le programme normal était pour moi de faire des versions dominicales, mais, cette fois j’ai une combinaison de voyage (ce qui aurait avancé la version à samedi matin depuis l’aéroport comme c’est souvent mon habitude quand je voyage) et il se trouve que la RC-5 avait déjà suffisamment grossi pour être plus grosse que les RC-3 et RC-4 ne l’étaient.
Donc, au lieu de publier ça à la dernière minute avant que j’embarque dans un avion et que je sois hors ligne pour une semaine, j’ai décidé qu’il n’y a absolument aucune raison pour ce genre de livraison sur le fil. Je préfère faire une livraison tranquillement un vendredi après‐midi, plutôt qu’une précipitée un lendemain matin avant de disparaître pendant une semaine.
Peu importe, assez d’explications. La RC-5 est sortie et, bien que j’eusse été plus joyeux si ça avait été aussi petit que la RC-4, ça semble n’être que des corrections solides (fameux derniers mots). L’intéressante corruption de la liste dcache, que j’avais mentionnée comme reliquat de la RC-4, est dedans ; et ce serait adorable si vous aviez un test de charge pour la couche VFS qui interagit avec la consommation de mémoire. Mais, le jeu en valait la chandelle, la correction nettoie pas mal de choses et retire plus de lignes qu’elle n’en ajoute, donc je la sens bien.
Exceptée cette intéressante modification véritable du cœur (où « véritable du cœur » est défini comme « un domaine auquel je tiens particulièrement », et ne signifie rien de plus ;), tout semble ennuyeusement familier : 55 % de pilotes, 20 % de mises à jour d’architectures et 25 % de divers (systèmes de fichiers, cœur du réseau, machines virtuelles, etc.).
Et, bien que cette RC-5 soit peut‐être plus grosse que les RC-3 et 4 ne l’étaient, ce n’est pas comme si c’était inquiétant. Cette période de fusion était plus grosse que la moyenne, et le fait que la RC-5 est donc un peu plus grosse que la moyenne n’est pas quelque chose qui m’inquiète plus que ça. Et comme la RC-4 était plus petite que d’habitude, tout s’égalise.
Mais je serai réellement entièrement non joignable toute la semaine prochaine, donc faites vos tests, parce que l’arborescence git sera très calme.
Linus
RC-6
La version RC-6 est sortie le 22 mai 2014.
À cause des voyages et du manque d’accès à Internet, des publications de RC n’ont pas suivi le cycle normal de publication dominicale, et, comme j’ai pris connaissance de ce qu’il s’est passé pendant que j’étais hors ligne, plutôt que d’attendre jusqu’à dimanche prochain pour revenir à un cycle normal, je publie en conséquence la RC-6 en milieu de semaine depuis Tokyo.
Avec la RC-5 qui était en avance de quelques jours et la RC-6 qui est en retard, nous avons presque deux semaines entre elles. La taille du résultat n’est pas deux fois plus grosse cependant. En partie parce qu’heureusement on a avancé dans la série des RC et que les choses sont censées se calmer, mais aussi parce que certains sous‐mainteneurs n’ont pas envoyé leurs demandes d’intégration car ils savaient que j’étais hors ligne. Quelle que soit la raison, c’est pas mal.
La distribution du correctif à l’air normale aussi. Principalement des pilotes (ACPI, son, média, pilote graphique i915, horloge clk, PCI…), avec le gros du reste qui correspond à diverses mises à jour d’architectures (notamment MIPS, mais aussi ARM et PA-RISC). Et une poignée de trucs divers dans les systèmes de fichiers et le code du cœur du noyau.
De toute façon, en fonction de ce qui est en cours, je rallongerai un peu la RC-7 pour revenir à une planification dominicale et, en fonction de comment les choses se passent d’ici là, ça pourrait être ne pas être la dernière RC.
Mais, s’il vous plaît, testez ça,
Linus
RC-7
La version RC-7 est sortie le 25 mai 2014.
… cette sortie dominicale se recale sur le calendrier habituel.
La RC-6 a seulement quelques jours, mais, comme prévu, du travail m’attendait à la maison. Cette version est donc normale, la RC-6 ayant juste été décalée par mon voyage.
Le contenu est en grande partie composé de changements concernant le réseau (principalement les pilotes), puisque les autres branches avaient été mises à jour pour la RC-6. Il y a aussi d’autres petits changements (DRM, ordonnanceur, perf, NFS, AFS, etc.).
Linus
RC-8
La version RC-8 est sortie le 1er juin 2014.
J’ai vraiment espéré que la RC-7 serait la dernière RC, mais la réalité a encore conspiré contre mes super plans bien établis, et me force donc à faire une RC-8. Ce n’est pas comme s’il y avait beaucoup de changement, mais une correction de dernière minute de dcache me fait penser que cela ne serait pas complètement sain de sortir la version définitive sans une semaine de test supplémentaire.
De tout de façon, normalement, une RC-8 n’est pas vraiment un énorme changement — la 3.15 est une des plus grosses (si ce n’est la plus grosse) version depuis bien longtemps, et nous faisons des RC-8 assez régulièrement. Ça pourrait ne pas être le cas de toutes les versions, mais je pense que nous avons 50 % de chances de faire une RC-8 à chaque version. Aussi je ne suis pas très fâché, et sûrement pas surpris.
Non, la véritable raison pour laquelle j’avais espéré que nous n’aurions pas besoin de faire une RC-8 pour la 3.15, c’est que c’est la fin des classes dans deux semaines et nous devons prendre nos vacances en famille juste après. Je déteste avoir encore un « Linus voyage pendant la fenêtre des fusions ». Normalement, je suis plus chanceux que ça durant dans mes voyages.
Certes, j’aurai Internet, et je pourrais faire la fenêtre des fusions pendant mes vacances en famille. Je préférerais juste ne pas à avoir le faire.
Aussi, essayons de voir comment cela va marcher — les dernières semaines de versions consistent généralement à regarder et être sûr que rien de grave ne se passe, par conséquent, le développement devrait fonctionner. Peut‐être que si cela fonctionne bien, nous finirons par continuer comme cela, même s’il n’y pas de conflit de calendrier qui me fait vouloir démarrer la fenêtre des fusions avant que je sois 100 % satisfait de la version précédente.
Ce n’est pas comme si je pensais que la RC-8 était cassée de quelque façon que ce soit. Je ne me sentais simplement pas faire une version 3.15 sans un petit peu plus de temps pour que les gens testent le correctif pour le dentry.
Quoi qu’il en soit, en dehors du changement dcache, il y a plein de petites choses éparpillées. Un changement d’une ligne est particulièrement intéressant : Minchan Kim avait trouvé un cas de figure qui remplissait entièrement la pile du noyau sur l’architecture x86-64 ; et, bien que cela soit quelque chose que je repoussais depuis longtemps, ce changement étend la pile à 16 Kio. Je pense que toutes les autres architectures 64 bits avaient cela depuis longtemps, aussi cela n’est pas très choquant, mais c’est, quelque part, assez fondamental sur une des architectures principales pour être mentionné.
Linus
Version finale
La version finale est sortie le 8 juin 2014.
Je me suis donc résigné à faire une RC-8, parce que j’étais un peu inquiet des corrections de dernière minute sur dcache, mais il s’est avéré que personne ne semble avoir remarqué quoi que ce soit. Malgré tout, nous avons eu d’autres problèmes pendant la semaine, aussi cela n’était pas plus mal. Les corrections de verrous futex et les nettoyages se démarquent, mais comme d’habitude il y a diverses autres corrections un peu partout réalisées depuis la RC-8, principalement les pilotes (DRM, réseau, son, USB, etc.), le réseau, l’ordonnanceur et les outils de mesure de performance.
Mais cela a été dans l’ensemble raisonnablement petit et calme, ce qui doit être, bien entendu, dû au fait que la semaine dernière était également la première semaine de la période de fusion pour la 3.16. Cela a pu distraire certains développeurs. Je ne suis pas complètement convaincu d’avoir apprécié le chevauchement, mais il semblerait que cela ait fonctionné correctement. Et, à moins que les gens crient très fort (« S’il te plaît ne refais plus jamais cela ! ») et qu’ils donnent de bonnes raisons pour cela, je pourrais refaire un chevauchement des fenêtres de fusion dans le futur, si cela peut aider pour certains problèmes de délai.
Ceci dit, je ne pense pas que cela ait été une expérience grandiose au point que je refasse un chevauchement à chaque fois, sans une bonne raison spécifique pour cela. C’était assez agréable d’être productif la dernière semaine de la RC (qui est généralement plutôt ennuyeuse et morte), mais je pense que cela pourrait représenter une distraction quand les gens devraient s’inquiéter de la stabilité de la RC.
Bien sûr, il se pourrait que le chevauchement aboutisse à moins de bruit pendant la dernière semaine de stabilisation, et que cela aide réellement. Cela pourrait aussi produire l’inverse. Je serais intéressé d’entendre l’avis des autres personnes, mais je soupçonne que la plupart n’ont aucune opinion particulière sur le sujet.
Quoiqu’il en soit, avec la version 3.15 publiée, ma branche « master » a déjà été fusionnée avec ma branche « next » sur ma machine locale, et je vais démonter la branche « next » une fois que j’aurai dégagé tout ça. Après cela, les futures fenêtre de fusion se feront sur la branche « master » et nous reviendrons au modèle normal de branche unique pour mon arbre.
Linus
Les nouveautés
Architecture
Gestion du mode mixte EFI
Certaines machines ont un micrologiciel EFI 32 bits, les noyaux 64 bits ne pouvaient du coup pas démarrer simplement dessus. Le mode mixte EFI (EFI mixed mode) ajouté à cette version 3.15, permet maintenant d’y remédier. Un exemple concret est la possibilité pour l’ASUS Transformer Book T100TA de démarrer sur un tel micrologiciel.
Le mode mixte EFI est un mode qui permet aux micrologiciels EFI 32 bits de démarrer sur des noyaux 64 bits, à condition que le chargeur de démarrage gère le protocole EFI handover. La plupart des chargeurs de démarrage populaires comme GRUB, SYSLINUX ou EFILINUX le gèrent, il sera donc possible de disposer de cette fonctionnalité très simplement à condition d’activer l’option CONFIG_EFI_MIXED depuis les options de configuration du noyau Linux.
AVX-512
Les premiers processeurs proposant le jeu d’instructions AVX-512 ne seront commercialisés qu’en 2015, avec la génération Knights Landing des processeurs Intel. Toutefois, leur prise en charge est déjà disponible dans cette version 3.15.
AVX-512 (Advanced Vector Extensions), extension directe de AVX-256, est un jeu d’instructions SIMD (Single Instruction Multiple Data). Il s’agit d’un jeu d’instructions qui permet d’appliquer une même opération arithmétique sur plusieurs données en parallèle. Par opposition aux instructions habituelles de type SISD, pour Single Instruction Single Data, SIMD permet d’appliquer une même opération d’addition, de multiplication sur plusieurs éléments d’une structure très régulière, comme c’est par exemple le cas sur des tableaux ou des matrices. AVX-512 permet, entre autres, d’agrandir la taille des registres AVX à 512 bits, ou encore va donner la possibilité aux compilateurs de vectoriser plus de boucles efficacement, grâce aux instructions Conflict Detection Instructions (CDI) qui, comme leur nom l’indique, permettent la détection des conflits.
Améliorations de l’ordonnanceur
L’ordonnanceur subit un travail de préparation qui vise à permettre une meilleure intégration avec le choix des états de veille du processeur, pour économiser l’énergie. Cela ne sera disponible que dans de futures versions du noyau [commit de fusion].
Il y a aussi eu plusieurs améliorations liées à l’usage des cgroups, notamment lors du changement de contexte entre deux processus d’un même cgroup [1, 2, 3].
Abandon des anciennes plates-formes x86
Je vais faire pleurer ceux d’entre vous qui ont des enfants qui jouaient à Jill, Linux 3.15 ne gère plus ces systèmes excitants introuvables que sont les SGI Visual Workstations, Sequent Computer Systems NUMAQ, IBM Summit/EXA et autres Unisys ES7000.
Instruction RDSEED
À partir du noyau 3.15, /dev/random utilisera les nouvelles instructions RDSEED des futures générations Broadwell de chez Intel [demande d’intégration].
À partir de cette génération, les processeurs Intel proposent une nouvelle instruction RDSEED. Il s’agit d’une instruction de génération de bits aléatoires. Comparée à son homologue RDRAND, qui fut introduite avec la génération Ivy bridge, elle est destinée à être utilisée par les logiciels qui disposent déjà d’un générateur de nombres pseudo-aléatoires (PRNG), en tant que « graine » (seed), c’est-à-dire une source d’entropie de nombres aléatoires. RDRAND, quant à elle, est une instruction de génération de nombres pseudo-aléatoires.
Systèmes mono-puces ARM
La plate-forme ARM est toujours très active, au point que les développeurs songent à mettre l’arborescence des périphériques dans un arbre Git dédié.
Parmi les nouveautés, on peut noter :
- l’ajout de la carte de développement A10-OLinuXino-LIME ;
- l’ajout du Freescale l’i.MX35 ;
- l’ajout des dérivés Freescale i.MX51 , i.MX25 et i.MX35 de chez Eukréa ;
- un ensemble d’améliorations au niveau des systèmes mono-puces i.MX de chez Freescale ;
- pas mal d’améliorations au niveau des systèmes mono-puces de chez ATMEL.
ACPI
Avant Linux 3.15, l’événement envoyé lors de l’appui sur une touche « augmenter la luminosité » ou « baisser la luminosité » pouvait signifier deux choses pour un environnement de bureau :
- notification comme quoi la luminosité a été modifiée ;
- touche de modification de luminosité pressée, « débrouille-toi ».
La plupart des environnements de bureau interprètent cet événement comme le cas numéro 2, ce qui causait des problèmes : changement de luminosité effectué deux fois — une fois par le noyau, une fois par l’environnement de bureau — ou changement de luminosité non détecté, et donc notification non affichée, etc. En effet, le scénario numéro 1 est très difficile à détecter en espace utilisateur.
Désormais, la grosse majorité des ordinateurs portables seront dans le cas numéro deux, ce qui rend la gestion de la luminosité plus simple et plus cohérente et résout les cas cités ci-dessus [commit].
Changement de la taille de la pile du noyau
La pile du noyau pour l’architecture x86_64 voit sa taille passer de 8 Kio à 16 Kio. Ce changement a été effectué par Minchan Kim [commit].
Pilotes graphiques libres
DRM (Direct Rendering Manager)
Le code commun aux pilotes graphiques libres (DRM) a reçu plus d’attention que d’habitude pour cette nouvelle version, notamment afin de préparer la venue de nouvelles fonctionnalités dans les versions futures. Il n’y a donc rien de visible pour le moment pour l’utilisateur final.
Le premier gros changement est la gestion universelle des plans d’affichage (display planes). Jusqu’à présent, le DRM n’exposait que les plans de type sprites et superposition (overlay) vidéo. Les plans pour curseurs étaient, eux, exposés via des appels ioctl() dédiés, alors que les plans primaires n’ont jamais été exposés. Désormais, tout client exposant la capacité DRM_CLIENT_CAP_UNIVERSAL_PLANES pourra accéder à l’interface de plans universelle (universal plane) et à la liste complète des plans proposés par le matériel. Ce client pourra dès maintenant changer des paramètres tels que la mise à l’échelle (scaling) ou désactiver l’affichage, sans avoir à effectuer de changement de mode graphique au niveau du contrôleur vidéo (CRTC). Cependant, l’intérêt de cette nouvelle interface ne sera clair que lorsque le travail de changement atomique du mode graphique et du commutation de pages (page flip) du noyau sera terminé. En attendant, si vous voulez plus d’information, vous pouvez consulter ce message ou l’article récapitulatif de la gestion du mode graphique de Pekka Paalanen (développeur Wayland).
Le deuxième changement important est la mise en commun du code gérant le canal auxiliaire de communication du DisplayPort (DP). Cela va permettre la gestion du Multi-Stream Transport (MST) proposé par le DisplayPort, qui permet de multiplexer plusieurs liaisons vidéo à travers le même câble DP. Voici la demande d’intégration de cette nouvelle infrastructure. La gestion du MST devrait, quant à elle, arriver dans Linux 3.16 ou 3.17.
La gestion des nœuds maîtres, mineurs et de contrôles a été revue dans cette version, notamment sur la gestion des verrous. En parlant de verrous, les symboles DRM vérifient maintenant activement que les bons verrous ont été pris avant l’appel, au lieu de simplement le marquer dans la documentation. Mais le changement le plus important vient mettre fin à une bidouille pour l’allocation d’un espace d’adressage pour le périphérique. En effet, il est impossible d’allouer un espace d’adressage sans avoir de nœud d’index (inode) disponible. Du coup, DRM attendait que le premier client ouvre un nœud vers un processeur graphique avant d’allouer l’espace d’adressage. Cette technique était clairement une bidouille, et Al Viro (mainteneur VFS) a conseillé d’utiliser une autre méthode qui a été appliquée.
Pour finir, la documentation DRM a été corrigée et nettoyée.
Adreno (pilote msm)
Dans cette nouvelle version, le pilote msm gagne la possibilité de diffuser du son via la prise HDMI [correctif] et devient plus économe en énergie en activant le clock gating après 66 ms d’inactivité [correctif].
Après un article de LWN sur comment gérer proprement des drapeaux inconnus dans les ioctl() ou les appels systèmes, Rob Clark a vérifié à nouveau son code et trouvé quelques problèmes qu’il a corrigés [correctif]. Ces modifications cassent la compatibilité binaire, mais Rob se justifie en disant qu’il n’y a presque aucun pilote en espace utilisateur et que, si une application venait à être cassée par ce changement, il reviendrait partiellement sur son correctif.
Le pilote msm utilise maintenant les plans d’affichage universels qui viennent juste d’être introduits, au lieu de l’ancienne interface de programmation [correctif].
Pour finir, une option noyau a été ajoutée afin d’afficher l’état des registres lorsque le processeur graphique se bloque [correctif]. Cela devrait aider pour l’écriture de rapports de bogues.
Pour information, le pilote freedreno (accélération 3D pour Adreno) utilisant le pilote msm vient de recevoir la prise en charge d’OpenGL 2.1. Celui-ci prenait en charge OpenGLES 2.0 depuis quelque temps, mais ne gérait pas quelques extensions nécessaires pour la version « bureau » d’OpenGL. Ce code devrait être disponible dans Mesa 3D 10.3 qui sortira en août.
AMD/ATI (pilote radeon)
La principale nouveauté concernant le pilote radeon est la prise en charge de l’encodeur vidéo matériel VCE afin d’accélérer la conversion de vidéos au format H.264. Ce noyau permet l’utilisation de cet encodeur à travers le standard OpenMAX, du groupe Khronos. Ce n’est pour l’instant possible qu’avec la version VCE 2.0 du matériel, la prochaine version de Mesa 3D (10.3) [correctif] et le greffon GStreamer gst-omx.
Cette nouvelle version apporte également la prise en charge complète d’un petit dernier dans la famille des processeurs APU Kaveri, le Mullins, qui est sorti le 29 avril 2014.
Pour finir, radeon a laissé tomber sa gestion spécifique du canal de communication auxiliaire du DisplayPort, afin d’utiliser la nouvelle version proposée par DRM [correctif]. Beaucoup d’autres bogues ont également été corrigés, notamment dans la gestion des horloges.
Samsung (pilote exynos)
Un gros travail de réorganisation du code a été mené sur le pilote exynos, avec notamment le déplacement du pilote DisplayPort depuis video/ vers drm/, afin de gérer correctement le branchement à chaud et le changement de mode graphique [correctif]. Il est également à noter l’ajout de la gestion des ponts LVDS, ainsi que des écrans à interface parallèle (remplacée par l’interface DSI).
Pour plus d’informations, vous pouvez consulter la demande d’intégration exynos.
Intel (pilote i915)
Aucune nouvelle fonctionnalité activée par défaut pour le pilote i915 dans cette version, mais un énorme travail de fond a été effectué.
La gestion des Per-Process Graphics Translation Tables (PPGTT, tables de traduction graphique par processus) fait son apparition, mais est désactivée par défaut à cause de quelques bogues trouvés à la dernière minute. PPGTT est une fonctionnalité des processeurs graphiques inclus dans les processeurs Intel Ivy Bridge, Haswell, et Broadwell qui permet l’isolation des tâches du processeur graphique, ce qui améliore la sécurité en fournissant un contexte et un espace d’adressage par descripteur de fichier et client de ressources graphiques. Pour en savoir plus sur GTT et GEM, un cours d’introduction a été écrit par Ben Widawsky, un ingénieur de chez Intel.
Par le passé, la gestion du power gating et du clock gating par le matériel Intel a surtout été gérée automatiquement. Désormais, les nouvelles architectures requièrent l’intervention du pilote afin, notamment, de sauvegarder et restaurer le contexte. Donc, il est nécessaire de préparer une infrastructure permettant de représenter les domaines énergétiques, de suivre leur état et de gérer les changements d’état. Comme les domaines énergétiques sont très dépendants de l’architecture et sont amenés à évoluer dans le futur, une couche d’abstraction est proposée par l’infrastructure. Cette infrastructure devrait commencer à être utilisée dans Linux 3.16.
Du côté de l’affichage, la gestion expérimentale du démarrage rapide et sans clignotement a été améliorée afin de pouvoir hériter du mode graphique qui a été mis en place au démarrage par le micrologiciel EFI. Encore un peu de travail est nécessaire pour rendre sa gestion parfaitement fiable, ce qui explique pourquoi l’option n’est pas activée par défaut bien que toute l’infrastructure soit maintenant en place. Si vous voulez l’essayer malgré tout, vous pouvez ajouter l’option i915.fastboot=1 à votre ligne de commande noyau.
Concernant l’affichage, la prise en charge des liens DisplayPort à 5,4 GHz, nécessaire pour piloter des écrans à ultra haute définition (4K), est disponible. Malheureusement, les écrans 4K actuels exposent généralement deux écrans, via le Multi-Stream Transport (MST), afin de proposer la 4K. En parlant de MST, le pilote i915 utilise maintenant la gestion du canal auxiliaire du DisplayPort proposée par DRM, ceci afin de pouvoir plus tard gérer les écrans accessibles via MST. Enfin, la gestion des grands curseurs a été ajoutée afin de mieux gérer les curseurs sur les écrans à haute densité de pixels.
La prise en charge des processeurs Broadwell a reçu beaucoup de modifications, mais elle reste encore incomplète. D’autres devraient suivre dans Linux 3.16.
Pour plus d’informations, vous pouvez consulter le billet de blogue de Daniel Vetter dédié à Linux 3.15.
NVIDIA (pilote nouveau)
La nouveauté principale côté du pilote nouveau est la gestion expérimentale de la nouvelle famille de cartes NVIDIA Maxwell, sortie le 18 février 2014. Cette gestion se limite actuellement au mode graphique [correctif] et à l’accélération 3D [correctif] en utilisant le microcode de NVIDIA. Ce microcode sera remplacé dans le futur par une version entièrement libre, quand les fonctionnalités basiques s’exécuteront en espace utilisateur. En effet, cette nouvelle famille de cartes a introduit un nouveau jeu d’instructions qu’il a fallu étudier et intégrer à Mesa 3D [correctif]. Il manque cependant les modifications nécessaires au pilote X.Org xf86-video-nouveau pour pouvoir utiliser l’accélération 2D et 3D sur processeur graphique Maxwell avec un serveur X.
Une première version d’un système de reprise sur panne a également été intégrée pour Kepler, afin de ne pas bloquer tout le système lorsque l’unité de gestion mémoire ne connaît pas la correspondance entre une adresse virtuelle et une adresse physique. Le pilote nouveau devrait également mieux gérer les cas où le microcode de changement contexte se bloque.
La gestion automatique de la ventilation s’améliore avec la correction de multiples bogues, et, surtout, l’ajout de la gestion de deux nouveaux types de ventilateurs couramment trouvés dans la famille Kepler. Si vous avez encore des problèmes de ventilateur dans cette version, vous êtes invités à écrire un rapport de bogue. De multiples bogues concernant la lecture du BIOS vidéo ont également été corrigés, en partie grâce à l’aide de NVIDIA.
Parmi les modifications apportées dans Linux 3.15, l’une d’elles se distingue particulièrement, pour deux raisons :
- elle prépare nouveau afin de pouvoir gérer le processeur graphique ARM Tegra K1, qui n’est pas accessible via un bus PCI, AGP ou PCIe ;
- elle est écrite par un nouvel employé de NVIDIA, Alexandre Courbot.
Ce n’est pas la première fois que NVIDIA contribue à nouveau puisque Aaron Plattner l’avait déjà fait en février 2013, mais c’est cependant la première fois que la gestion d’un nouveau jeu de composants est écrite par un employé de NVIDIA, français, qui plus est. Alexandre Courbot est, en effet, actif sur l’IRC et les listes de diffusion de nouveau et ajoute la gestion du Tegra K1 (nom de code GK20A) au noyau, tel que nous le rapportions sur LinuxFr.org en février. La majorité des contributions sont encore à venir, notamment dans Linux 3.16. La gestion de l’accélération 3D en espace utilisateur n’a pour l’instant nécessité que -8 / +21 changements ! Plus d’information dans un futur proche, mais, en attendant, voici une petite démonstration de l’avancement.
Poulsbo (pilote gma500)
Le pilote gma500 du tristement célèbre processeur graphique à basse consommation Poulsbo évolue doucement, avec la prise en charge d’un nouveau type d’unité de gestion mémoire et de gestionnaire d’interruptions (SGX).
Tegra (pilotes host1x et tegra)
Les choses ont bien bougé du côté de host1x qui reçoit une infrastructure pour l’allocation de contextes, la synchronisation des moteurs d’exécution et la gestion du moteur de rendu 2D. La gestion de la 3D est en cours d’écriture. Bien que ce travail ait été testé durant plusieurs semaines par de multiples contributeurs, les contrôles d’entrées-sorties introduits pour tegra sont actuellement considérés comme staging (branche git dédié à la mise en œuvre) de façon à permettre un changement plus tard, si l’interface venait à ne pas être adaptée. La gestion de la 2D et de la 3D a été testée avec le pilote grate. Pour rappel, host1x est la partie des processeurs Tegra qui gère les transferts DMA, ainsi que l’affichage et l’envoi asynchrone de commandes au processeur graphique et autres systèmes multimédias. Le processeur graphique Tegra est, lui, séparé, à la fois dans la puce et dans le code, et se charge de l’accélération 2D et 3D.
Pour plus d’informations, vous pouvez consulter la demande d’intégration tegra/host1x.
VMware (pilote vmwgfx)
Le pilote vmwgfx, pour l’accélération graphique dans les machines virtuelles VMware tournant sous Linux, a revu sa politique de sécurité afin de pouvoir gérer les nœuds de rendu (render nodes).
Réseau
À la recherche des performances
La recherche de gain en performance est une tâche courante dans le noyau Linux, et la partie réseau n’est pas en reste pour cette nouvelle version. Petit tour de ces nouveautés.
Une horloge plus fine
Dans les arcanes du très populaire TCP, l’estimation du RTT est importante pour certains algorithmes de gestion de la congestion. L’unité de cette estimation était la milliseconde, avec une bidouille immonde pour les cas inférieurs à cette valeur. Concrètement, cette bidouille dépendait de la fréquence de réveil de votre noyau (déterminée à la compilation). Cette fréquence étant à 1 000 Hz par défaut sur les architectures x86, l’estimation la plus fine utilisait des pas de 125 µs.
Sur des réseaux modernes très performants, ces 125 µs sont beaucoup trop imprécises. Le nouveau noyau compte donc désormais en microsecondes, mais reste compatible avec les anciens outils de l’espace utilisateur en exportant toujours les données en millisecondes. Une mise à jour de la commande ip sera nécessaire pour voir les changements.
Réécriture de l’interpréteur interne BPF
Que ne serait pas un nouveau noyau sans travail du côté du filtrage de paquets ? Le cœur de l’interpréteur a été réécrit dans cette version, avec pour objectif une amélioration des performances. Le correctif est accompagné de tests de performance prometteurs, et d’une promesse de faire encore mieux bientôt en adaptant le compilateur à la volée (Just In Time) de BPF.
Mettre à jour la somme de contrôle tout simplement
Pour limiter l’utilisation du processeur sur des réseaux à très forte capacité, un mécanisme courant est de déléguer une grande partie du travail à la carte réseau. L’idée est de faire « comme si » on envoyait et recevait des très gros paquets du côté noyau, pendant que la carte réseau se charge de découper/rassembler les paquets réels, bien plus petits. Pour en savoir plus, vous pouvez consulter un très bon article sur LWN.
C’est en utilisant ce mécanisme qu’un développeur de Google a détecté une forte utilisation du processeur pour le calcul de la somme de contrôle de ses paquets, avec près d’un pour cent du processeur dédié à cette simple tâche. Cette somme de contrôle a de bonnes propriétés mathématiques, elle est notamment incrémentale : quand on modifie un champ d’un paquet, on n’est pas obligé de tout recalculer, il suffit de calculer la différence induite par la partie réécrite.
L’analyse détaillée a donc conduit à identifier le coupable : la fonction csum_replace2(). Cette fonction prend une somme de contrôle, deux mots de 16 bits (l’ancien champ et le nouveau champ réécrit du paquet), et retourne la nouvelle somme de contrôle.
Cette fonction ne faisait pas réellement le travail, en délégant la tâche à la fonction csum_replace4(), prenant comme arguments des mots de 32 bits. Qui peut le plus peut le moins, mais le fait moins vite. csum_replace4() appelle, elle-même, une fonction générique encore plus complexe.
Cette mise à jour de la somme de contrôle est pourtant une tâche simple pour des mots de 16 bits, bien documentée depuis longtemps dans la RFC 1624. Davil Miller a signalé cette référence, et Éric Dumazet de chez Google a donc modifié la fonction pour utiliser cette méthode simple et rapide. Comme cette fonction est utilisée à d’autres endroits de la partie réseau, d’autres cas d’utilisation devraient profiter de ce gain.
Protection contre les dénis de service
Les dénis de service, consistant à surcharger un serveur par un nombre impressionnant de connexions, sont très courants sur Internet. Parmi ceux-ci, un grand classique est le bon vieux SYN flood. Sur un pare-feu à états, chaque paquet ajoutera une connexion à suivre, et il faut être capable de les gérer.
Chez Linux, ce suivi est effectué par la table conntrack. Cette table était protégée par un verrou central pour les insertions et les suppressions. Et ce verrou devenait avec le temps un énorme frein (un peu comme le Big Kernel Lock, à échelle très réduite).
Le nouveau noyau introduit donc un verrouillage plus fin, avec 1 024 verrous et une table de hachage pour savoir quel verrou utiliser. L’amélioration de performance est spectaculaire, si vous avez le matériel qui va avec. Avec un bon processeur et un réseau à 10 Gbit/s, le testeur est passé d’une gestion de 810 405 connexions par seconde à 2 233 876, soit une amélioration d’un facteur de presque trois.
Sécurité réseau
cgroups et réseau
C’est une modification triviale, mais il est désormais possible d’attacher une règle iptables à un cgroup pour du trafic entrant. Cela permet notamment de compter le trafic entrant d’une application.
Toujours du côté des cgroups, une refonte assez importante a supprimé la possibilité de compiler le contrôleur cgroup net_prio en tant que module. C’était le seul qui utilisait cette possibilité.
IPsec
Dans un paquet IPsec, il est possible d’ajouter un compteur de paquets pour se protéger des attaques par rejeu (en refusant des paquets dont le compteur est inférieur aux valeurs déjà reçues). Ce compteur est historiquement de 32 bits, ce qui permet d’envoyer un certain nombre de paquets.
Ce nombre est cependant insuffisant pour les réseaux modernes, et une extension existe dans le standard depuis 2005 pour utiliser un compteur à 64 bits. Linux permettait de le faire pour le protocole ESP d’IPsec (intégrité et authentification) et, à partir de cette version, l’autorise également pour le protocole AH (intégrité et confidentialité).
Depuis sa version 3.6, le noyau permet de gérer le routage à travers un tunnel, avec les vti (Virtual Tunnel Interface, nom venant de Cisco), pour gérer plus facilement et plus dynamiquement le routage à travers un tunnel IPsec. Ces VTI sont uniquement une abstraction des règles IPsec existantes dans le noyau. Pour ces VTI, ce noyau ajoute la possibilité de configurer un espace de noms et de faire passer de l’IPv6 dans un tunnel IPv4.
Bluetooth
Ce noyau introduit la gestion du niveau 4 (le plus élevé) de la sécurité en Bluetooth. Concrètement, ce mode de sécurité force l’utilisation de clefs de chiffrement plus fortes, mais ne sera compatible qu’avec les équipements utilisant la norme Bluetooth 4.1. Il n’y a pas de compatibilité pour ce mode avec le matériel plus ancien.
Commentons avec nftables
Avec le pare-feu de nouvelle génération nftables, on peut désormais ajouter des commentaires arbitraires associés à une règle. Cela permettra à l’administrateur pressé de répondre à la question « Mais, pourquoi ai-je bien pu ouvrir le port 22 ? ».
Sécurité
Audit
La valeur de proc//cmdline (nommée proctitle) fait maintenant partie des informations remontées par le sous-système d’audit [correctif]. Cette chaîne de caractères peut être changée par le processus avec la fonction setproctitle(), et ne peut donc pas être considérée comme « de confiance » d’un point de vue sécurité.
En revanche, elle sera particulièrement utile pour le débogage sur Android notamment, car les applications ne sont pas lancées à l’aide d’un classique fork() + exec(). En effet, pour accélérer le lancement, les applications Java utilisent une instance (processus) préparée à l’avance par la machine virtuelle Java Dalvik et la spécialisent en chargeant les classes de l’application. Ceci évite notamment d’avoir à charger systématiquement les classes des paquets de base pour chaque nouvelle application lancée, et permet donc de profiter de la propriété de copie sur écriture (Copy-On-Write) de l’appel système fork(). Lorsque la machine virtuelle Java (JVM) lance une application, elle change la valeur de proctitle pour la faire correspondre à son nom et cela apparaîtra désormais dans les journaux d’audit.
La prise en charge de l’audit des appels système a aussi été étendue pour gérer les appels 32 bits sur une architecture 64 bits [correctif].
Gestion de l’Intel Trusted Execution Environment
Une série de correctifs [1, 2, 3, 4 et 5] ajoute la gestion du périphérique Intel Trusted Execution Environment à l’Intel Management Engine Interface (IMEI). L’IMEI est une interface IPMI faisant partie de l’Intel Active Management Technology qui est présente dans les processeurs avec la technologie
