Sortie du noyau Linux 3.15

108
12
juin
2014
Noyau

La sortie de la version stable 3.15 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. Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche.

Tux

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 :

  1. notification comme quoi la luminosité a été modifiée ;
  2. 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/<pid>/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 Intel vPro. Elle permet de gérer un système en discutant directement avec une puce dédiée, sans passer par le système d’exploitation (out‐of‐band management).

LSM

Diverses corrections de bogues et améliorations mineures sont listées dans le message de demande d’intégration des correctifs.

SELinux

La mise en correspondance de zones mémoire proches de l’adresse 0 peut poser des problèmes de sécurité (cela simplifie principalement l’écriture d’exploitations de failles du noyau). Ainsi, une limitation arbitraire avait été ajoutée (vm.mmap_min_addr, configurable à l’aide de sysctl) pour réduire ce risque. Les processus souhaitant mettre en correspondance une zone mémoire inférieure à mmap_min_addr doivent disposer de la « capacité » (capability) CAP_SYS_RAWIO.

Pour le noyau 2.6.30, Eric Paris avait choisi de placer la vérification effectuée par SELinux (MAC) avant la vérification classique de « capacité » (DAC) [correctif]. Ce comportement était un cas exceptionnel, car les vérifications effectuées au niveau des appels système suivent toutes l’ordre DAC puis MAC (cf. un exemple complet pour le contrôle d’accès à un fichier).

Cette inversion a eu pour principale conséquence la mise en avant d’un cas d’erreur courant et géré sans aucun problème par les programmes (notamment Wine et QEMU) dans la majeure partie des cas. En effet, lorsque qu’un programme essayait d’effectuer un mmap() au‐dessous de mmap_min_addr, il se voyait refuser l’accès par SELinux en premier, ce qui générait un AVC qui était affiché à l’utilisateur (par setroobleshoot) avec un message du type :

SELinux is preventing /usr/bin/wine-preloader from 'mmap_zero' accesses on the memprotect.

L’utilisateur croyait alors à tort qu’il y avait un problème de sécurité. Si l’application échouait, ce n’était pas non plus nécessairement la faute de SELinux. Et, si c’était effectivement le cas, il fallait non seulement autoriser ce programme dans la politique SELinux, mais également lui donner la capacité CAP_SYS_RAWIO pour qu’il puisse fonctionner.

Ayant causé plus de soucis que de bénéfices potentiels (détection de programmes malveillants), cette inversion MAC/DAC a été corrigée (cf. l’article de Daniel Walsh sur le sujet) [correctif].

Un autre bogue a été corrigé : des nœuds d’index (inodes) dans /proc pouvaient être laissés avec une étiquette de sécurité (label) attribuée par défaut au lieu de celle indiquée dans la politique de sécurité. Cela se produisait si un programme y accédait avant que la politique ne soit chargée [correctif].

Systèmes de fichiers

Code commun

VFS

L’appel système renameat2 a été ajouté afin de permettre d’échanger les noms de deux fichiers de façon atomique. Avec cet appel système, il devient donc possible de remplacer un dossier par un lien symbolique sans risque qu’une opération arrive durant l’opération et ne réussisse pas ! Vous pouvez consulter l’article de LWN sur le sujet, ainsi que la page de manuel de l’appel système, afin d’obtenir plus d’informations.

Une autre modification importante est l’ajout de nouveaux verrous équivalents aux verrous POSIX, mais associés aux fichiers et non plus aux processus. La différence semble être peu importante, mais elle permet de rendre ces verrous utiles pour la synchronisation de plusieurs fils d’exécution à l’intérieur d’un même processus.

Avec les verrous POSIX classiques (qui n’ont pas été remplacés), si deux fils d’exécution (threads) d’un même processus ouvraient le même fichier, un verrou posé en écriture par un fil serait remplacé par un autre verrou en écriture posé par l’autre fil. De plus, si le fichier est ouvert plusieurs fois (utile pour paralléliser la lecture de données dans plusieurs fils) les verrous posés par un fil sur un fichier sont enlevés lorsqu’un autre fil ferme son descripteur de fichier. Il est très difficile de se prémunir contre ça sans rajouter beaucoup de verrous internes à l’application et s’assurer que les chemins des fichiers sont uniques (pas de lien dur ou symbolique).

Cependant, si les verrous sur un fichier ne sont plus associés à l’identifiant du processus (PID) mais sont associés aux descripteurs de fichier, le noyau ne fera plus de distinction entre deux tentatives de verrouillage venant de deux fils d’exécution d’un même processus ou de deux processus séparés ! Pour plus d’information, vous pouvez lire l’article dédié sur LWN.

SATA

La vitesse de sortie de veille a été augmentée en autorisant le contrôleur de disque SATA à se réinitialiser en tâche de fond pendant que le reste du noyau se réveille puis rend la main à l’espace utilisateur. Ce n’est pas un problème, car même si une application utilisateur ou le noyau essaient de relire un fichier pendant que le contrôleur SATA se réveille, le processus ou le module sera bloqué et la requête mise en file d’attente en attendant que le contrôleur ait fini son travail. Le résultat est un temps de réveil de 7 à 12 fois plus rapide sur les machines de son développeur et une faible complexité du code (1 et 2). Plus d’informations sont disponibles sur LWN.

Ext3/4

Le système de fichiers par défaut de nombreuses distributions se stabilise encore et toujours, mais peu de nouveautés à se mettre sous la dent.

XFS

Idem du côté de XFS, la période est relativement calme. À noter que le sous‐système XFS n’est plus maintenu par SGI mais désormais par Dave Chinner (Red Hat). Celui‐ci remercie au passage grandement SGI pour le boulot réalisé depuis les débuts de XFS. Les modifications les plus significatives concernent la gestion de O_TMPFILE, ainsi que l’option de l’appel système fallocate (COLLAPSE_RANGE et ZERO_RANGE).

Btrfs

Suite à l’embauche de Chris Mason chez Facebook, puis au déploiement sur une ferme de serveurs de test de Btrfs, ce système de fichiers a le vent en poupe. Btrfs se voit amélioré considérablement, avec une bonne salve de corrections et d’améliorations de performance qui ne semblent cependant pas visibles dans les tests de Phoronix.

Le temps semble être à la stabilisation de Btrfs.

F2FS

Ce système de fichiers qui s’entend bien avec les mémoires Flash (Flash‐Friendly File System) se voit doté d’une amélioration des performances sous certaines charges de serveur, ainsi que d’une gestion des dossiers de taille importante.

kernfs

Le pseudo‐système de fichiers kernfs a été tout juste introduit dans la version 3.14. Il reprend la logique de sysfs pour la rendre plus utile aux différents sous‐systèmes ayant besoin d’un système de fichiers virtuel. Il continue d’être amélioré, en particulier par Tejun Heo, auteur de la majorité des correctifs.

ZRAM

Ajout de la gestion de l’algorithme de compression LZ4 pour zram. zram est un système de d’échange de mémoire (swap) compressé tournant en mémoire vive, afin d’améliorer les performances des machines qui en manquent.

En vrac

Par manque de temps, tous les changements n’ont pu être résumés. Voici quelques informations complémentaires :

Virtualisation

KVM

Les nouveautés tirées de la demande d'intégration :

  • pour les architectures ARM, il y a quelques corrections pour les caches ;
  • du côté du PowerPC, les invités peuvent profiter de la mémoire transactionnelle (disponible avec le POWER8) ;
  • MIPS profite de quelques corrections de bogue, mais d’autres devraient arriver avec la prochaine version, car QEMU va avoir droit à KVM avec MIPS ;
  • pour les x86 :
    • des optimisations dans les registres de débogage utilisés par certains jeux pour Windows,
    • de manière générale, les invités Windows profitent de plusieurs corrections de bogues,
    • pour tous les invités, les instructions des processeurs Intel Broadwell sont maintenant exposées, ainsi que les instructions MPX développées par Intel pour protéger les accès mémoire,
    • pour les invités OS X, il y a un contournement avec le minuteur de préemption pour la virtualisation imbriquée, et quelques modifications de l’horloge présentée par KVM ;
  • pour l’architecture s390 (les ordinateurs centraux d’IBM), les erreurs de page asynchrones sont implémentées, et des améliorations des interruptions font que les périphériques virtio sont plus rapides.

Xen

Aucune nouveauté du côté de Xen pour cette version.

Le bilan en chiffres

Une fois n’est pas coutume, LWN n’a pas encore publié son article sur les statistiques des contributions à cette nouvelle version de Linux.

Nous avons profité de ce délai de leur part pour améliorer la qualité de cette dépêche, mais nous ne pouvons pas la retarder infiniment. Nous rajouterons cette partie dans un commentaire quand l’article de LWN sera disponible.

Appel aux volontaires

Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition :

Mainteneur Contributeur(s)
La phase de test aucun Julien Pecqueur, Albert_
Architecture Romain Perier Sébastien Chauvel
Pilotes graphiques libres Martin Peres
Réseau Florent F.
Systèmes de fichiers Jiehong Martin Peres
Sécurité Timothée Ravier
Virtualisation Xavier Claude
Édition générale aucun Martin Peres, Davy Defaud, rogo

Un peu de vocabulaire :

  • Le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie. Il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer.
  • Un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche. Il n’y a aucune forme d’engagement pour le futur.

Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps. Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les correctifs intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau !

  • # Fiiiiiiirst

    Posté par . Évalué à -10.

    pas encore lu que je sens déjà que je vais y passer des heures…. de plaisir….à lire je veux dire.
    bon je me tais et je reviendrais quand j'aurais fini et que j'aurais quelque chose d'intéressant à dire ;)

  • # Merci pour la référence

    Posté par . Évalué à 5.

    Hé, hé, j'ai apprécié la référence à OpenJill.
    Oui effectivement, je pleure de nostalgie.

    • [^] # Re: Merci pour la référence

      Posté par (page perso) . Évalué à 2.

      De rien, je venais de lire qu'un barbu nostalgique se fadait de l'assembleur plutôt que d'utiliser dosbox ;-)

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # Kernel stack

    Posté par (page perso) . Évalué à 10.

    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

    Pour une explication complète de ce changement il y a cet article LWN (avec des commentaires intéressants) : https://lwn.net/Articles/600644/

    • [^] # Re: Kernel stack

      Posté par (page perso) . Évalué à 2.

      Sauf que cet article finit indiquant que le changement n'aura pas lieu pour 3.15 ;-)

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: Kernel stack

        Posté par (page perso) . Évalué à 5.

        Et bien, il semblerait que Linus ait cédé.

      • [^] # Re: Kernel stack

        Posté par (page perso) . Évalué à 9.

        Il faut lire les commentaires ;-)
        Tu y trouvera celui-ci écrit par Jon Corbet (l'auteur de l'article) : "Well, I was wrong about one thing…Linus just merged the 16K stack patch for 3.15."

    • [^] # Re: Kernel stack

      Posté par (page perso) . Évalué à 5.

      Il fut une époque ou l'on faisait fonctionner un ordinateur avec 16 Ko (Thomsom MO5 ou ZX81)… aujourd'hui c'est juste pour la stack du noyau :/ Combien de CPU, même récent, n'ont pas ces 16Ko en cache L1 ?

      • [^] # Re: Kernel stack

        Posté par (page perso) . Évalué à 4.

        pour le ZX81, 16 ko c'était en prenant une extension : par défaut, c'était 1 ko ;-)

      • [^] # Re: Kernel stack

        Posté par (page perso) . Évalué à 6.

        Un processeur que j'utilise couramment en embarqué, c'est les STM32F4, ils sont assez loin de pouvoir faire tourner linux (quoique linux gère les absences de MMU maintenant).
        Ils ont quand même 4ko de cache instruction.

        Et ce changement n'est que pour les x86_64. Le premier AMD64, les opteron avaient 64ko de L1.
        Les proco x86_64 les plus pourris du moment (et probablement ever, y a peut être eu des Semprons 64), les Atom, descendent à 32Ko (les anciennes générations avaient 64Ko -_-')

        Aussi, quand t'es "au sommet" de la stack, tu veux pas forcément avoir accès ) comment a été appelé le main() de ton programme, donc je pense que la question n'a pas trop de sens.

      • [^] # Re: Kernel stack

        Posté par . Évalué à 2.

        Comme le dit Ph Husson, les CPU 64-bits n'ayant pas au moins 32Ko de cache L1 doivent se compter sur les doigts d'une main.
        De plus, je ne pense pas qu'il y ait un grand intérêt à mettre toute ta kernel stack en mémoire L1.

        Sinon tu peux voir les choses dans l'autre sens: c'est cool, maintenant on peut faire tourner des démo technique uniquement dans la mémoire L1! Je suis même persuadé que certain vieux jeux devraient pouvoir tenir dedans aussi :D

        • [^] # Re: Kernel stack

          Posté par . Évalué à 4.

          Comme le dit Ph Husson, les CPU 64-bits n'ayant pas au moins 32Ko de cache L1
          doivent se compter sur les doigts d'une main.

          Les processeurs AMD opterons, au moins la génération Bulldozer, ont un L1d de 16ko par coeur.

      • [^] # Re: Kernel stack

        Posté par . Évalué à 3.

        Mettre la stack en cache, quelle idée…

        • [^] # Re: Kernel stack

          Posté par . Évalué à 1.

          Mettre la stack en cache, quelle idée…

          Une bonne idée (car nous parlons de kernel stack, celle qu'utilisent tous les processus).

          kentoc'h mervel eget bezan saotred

          • [^] # Re: Kernel stack

            Posté par . Évalué à 3.

            Kernel ou pas, que tu mettes quelques octets en cache en haut de la stack, ok (et encore), mais d'une manière générale, tu mets pas en cache ce que tu accèdes de manière séquentiel. Même les cpu les moins puissant depuis 2002 optimise l'accès aux données séquentiels.

            D'autre part, on met des caches lines en cache, pas des pages, d'ailleurs il est impossible de mettre des page complète en cache sur la plupart des CPU. Une page ne se map qu'en quelques caches lines dont la taille << taille d'une page (dépendant de la quantité de mémoire physique sur certains CPU).

            • [^] # Re: Kernel stack

              Posté par . Évalué à -1. Dernière modification le 17/06/14 à 08:35.

              Même les cpu les moins puissant depuis 2002 optimise l'accès aux données séquentiels.

              Oui et ils font ça comment ?
              Pour moi il y a 2 manières, la première c'est mettre une valeur dans un registre (un indice de boucle par exemple) et l'autre, de mettre une portion de code souvent accédée dans le cache de plus bas niveau car il tourne (presque) à la même vitesse que le cpu et est très proche de lui ce qui fait que l'accès aux données ou aux instructions est extrêmement rapide.

              D'autre part, on met des caches lines en cache, pas des pages

              Et alors ? la kernel stack ne serait composée que de pages ?
              D'ailleurs je ne comprends ton propos pourquoi serait il impossible de mettre une page mémoire (entière) dans un cache ? surtout quand on voit des caches de 8Mo (voir plus) sur les processeurs modernes.

              kentoc'h mervel eget bezan saotred

              • [^] # Re: Kernel stack

                Posté par . Évalué à 9.

                Il te faut lire :
                http://lwn.net/Articles/250967/

                Tes réponses montrent que tu as une vision plus que flou du fonctionnement des caches.

                "La première sécurité est la liberté"

              • [^] # Re: Kernel stack

                Posté par (page perso) . Évalué à 4.

                Oui et ils font ça comment ?

                Avec un bus mémoire qui a des bursts…

                Et alors ? la kernel stack ne serait composée que de pages ?
                8ko de mémoire contiguë, sur mon x86 ça fait 2 pages en tout cas.
                Et on parlait de cache L1 dans la discussion, les caches L1 sont en lignes.
                Si on parle de L2/L3, alors la stack rentre dedans…

        • [^] # Re: Kernel stack

          Posté par . Évalué à 10.

          Oui, c'est une stack cachée :-)

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Merci

    Posté par . Évalué à -8.

    Infos intéressantes je vais tester tout ça.

    • [^] # Re: Merci

      Posté par . Évalué à 0.

      Merci pour cette dépêche très instructive.

  • # Soigne toi bien

    Posté par (page perso) . Évalué à 5.

    A noter que Jonathan Corbet, qui a fait de LWN ce qu'il est aujourd'hui, est en convalescence (cf http://lwn.net/Articles/594980/). Il a donc moins de temps pour faire ses articles de très grande qualité.

    D'ailleurs, j'encourage au passage tout le monde à souscrire à LWN afin de les aider dans leur travail journalistique de pointe.

    • [^] # Re: Soigne toi bien

      Posté par (page perso) . Évalué à 10.

      En convalescence ? C'est plutôt qu'il annonce avoir un cancer et qu'il va entrer en traitement. Malheureusement il est encore loin de la convalescence.
      Il y a quand même des raisons d'espérer : "The good news is that my condition, while serious, still has a good probability of being curable. Things were caught at a stage where, with a bit of luck, the disease can be evicted from my body and, eventually, this whole episode will fade into a bad memory."

  • # Reiser4

    Posté par (page perso) . Évalué à -4.

    Par manque de temps, tous les changements n’ont pu être résumés. Voici quelques informations complémentaires :

    • Reiser4 : [1], [2], [3] ;

    Ça par exemple, le mise en œuvre externe de Reiser4 ! Elle bouge donc encore ?

    Ok, c'était facile, moche et éculé, je →[] de ce pas.

    • [^] # Re: Reiser4

      Posté par . Évalué à 2.

      C'est pas malin de déterrer ainsi de tels sujets de conversation…

  • # ça me fait toujours rêver

    Posté par . Évalué à 10.

    le processus de développement de linux, si comme moi tu aimerais le même processus dans ta boite : pouce vert

    le bonne exemple : Mettre à jour la somme de contrôle tout simplement

    par chez nous : Mettre à jour la somme de contrôle ? pourquoi faire ? en quoi ca te regarde ? de toute facon ca tourne depuis 2 ans comme ca ? laisse le devellopeur responsable de ça le faire. /o\ et j'imagine que je ne suis pas tous seul dans ce cas, ca me desespere encore plus.

    ça donnerait presque envie d'elever des chèvres dans le Larzac

    • [^] # Re: ça me fait toujours rêver

      Posté par . Évalué à 6.

      Tu sais, il n'est pas rare que Linus envoie chier des gens pour moins que ça.

      Et puis je vais faire l'avocat du diable, mais personnellement je comprends les gens qui refusent des changements sur des systèmes en production si ce n'est pas critique. Typiquement, mettre à jour la somme de contrôle, si c'est risquer un effondrement de la stack réseau pour 0,1% de perf sur la plateforme, est-ce vraiment un pari à prendre ?

      • [^] # Re: ça me fait toujours rêver

        Posté par . Évalué à 10.

        mon expérience, et parcours mon prouvé que tous les problemes/bug doivent etre toujours résolu, il y a le risque que cela entraîne une cascade de probleme a résoudre dans l'urgence.

        genre analogie foireuse : rouler avec une roue de secours crevé dans le coffre de la voiture, pourquoi la faire remplacer ? ca marche très bien comme ca, de quoi je me mêle, etc …

        actuellement je vois que personne ne veut prendre de risque, mais implicitement il prenne la décision que cela leur explose a la figure un jour ou l'autre.

        citons Linus :

        Parfois, vous devez seulement prendre une décision. Il n’est pas toujours évident de savoir quelle est la « bonne » décision, et parfois il peut être bon de se contenter de dire « nous n’en savons rien » et de ne pas prendre de décision du tout. Dans d’autres cas, vous devez vraiment choisir entre des alternatives techniques. La bonne nouvelle, c’est que la plupart des choix techniques peuvent être changés si, plus tard, il s’avère qu’ils étaient erronés. Cela peut être douloureux, mais parfois il vaut mieux faire un choix, même si vous ne savez pas si c’est le bon.

        • [^] # Re: ça me fait toujours rêver

          Posté par . Évalué à 8.

          genre analogie foireuse : rouler avec une roue de secours crevé dans le coffre de la voiture, pourquoi la faire remplacer ? ca marche très bien comme ca, de quoi je me mêle, etc …

          Tu aurais pu prendre une analogie plus récente et dans l'air du temps avec les banques (et d'autres) qui crient au scandale depuis l'arrêt du support de Windows XP.

          de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité

        • [^] # Re: ça me fait toujours rêver

          Posté par . Évalué à 2.

          Je suis tellement… mais tellement d'accord avec toi dark_star! T'imagines même pas!

          Je ne supporte pas de fixer des bugs à coup de hacks et encore moins les décisions qui préfèrent garder ces hacks crade plutôt que de trouver la bonne solution.
          On ne donne pas assez de temps au devs pour faire les choses proprement ou, au moins, pour prendre le temps de cleaner de temps en temps. C'est bien dommage.

          Moi aussi le dev de Linux me fait rêver. Tes cleans massifs, des fonctionnalités à la pelle, des améliorations de performances partout, … aaah…

          • [^] # Re: ça me fait toujours rêver

            Posté par . Évalué à 3.

            Je ne supporte pas de fixer des bugs à coup de hacks et encore moins les décisions qui préfèrent garder ces hacks crade plutôt que de trouver la bonne solution.

            En fait, il faut avoir les c… et faire son méchant, et prendre le temps qu'il faut. Car à partir de plusieurs couches, même un bug mineur prendra un temps exponentiel à être corrigé.

            "La première sécurité est la liberté"

            • [^] # Re: ça me fait toujours rêver

              Posté par . Évalué à 4. Dernière modification le 13/06/14 à 20:04.

              certe mais une fois corrigé, il disparaît, on n'en parle plus :) cela fait du temps en plus pour faire autre choses. de mon point de vue, les decideurs attendent d'avoir un volume d'emmerde trop important pour pouvoir s'en occuper correctement.

              en général ils attendent que le client exige une explication et une solution :(,il a été endormi pendant de looongue semaine par le dirco, puis PAF il faut pondre la solution impossible dans la semaine. Mais qu'est ce qui les empêchent de nous prévenir 4 semaine avant ?

              J'en parle car je sais que pour début juillet on va m'avertir debut juillet que c'est urgent :) oui vous avez bien lu, le projet qui stagne depuis 1 an :( en R&D qui va me nécessiter 4 semaine de delai raccourci en 3/4 jours. en general j'arrive à travailler en douce/cachette sur le projet pour ne pas être surpris, mais j'aime pas trop.

              Linux, ma bouffée oxygène a défaut de chèvre de le larzac :)

    • [^] # Re: ça me fait toujours rêver

      Posté par . Évalué à 5.

      ça donnerait presque envie d'elever des chèvres dans le Larzac

      Malheureusement, il y aura toujours des gens ( de préférence installé en hémisphère et n'ayant comme point de vu qu'un gus sur un estrade ) pour te pondre un truc te disant que non, c'est pas comme ça qu'on élève des chèvres ou qu'il faut faire ceci maintenant.

      • [^] # Re: ça me fait toujours rêver

        Posté par . Évalué à 4.

        installé en hémisphère

        J'aimerais bien voir des gens installé en hémisphère, ça doit demander une sacré architecture du bâtiment.
        Dans Star Wars je crois qu'on en vois disposé en sphère ou presque.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: ça me fait toujours rêver

          Posté par . Évalué à 3. Dernière modification le 13/06/14 à 14:34.

          Désolé, hémicycle est le nom donné quand on n'a pas une indigestion de fromage de chèvres.

          Dans Star Wars, c'est plus une sphére alongée et tronquée. Un solide de révolution complète et non seulement la moitié.

          • [^] # Re: ça me fait toujours rêver

            Posté par . Évalué à 0.

            Dans Star Wars, c'est plus une sphére alongée et tronquée. Un solide de révolution complète et non seulement la moitié.

            Tu confonds pas avec R2D2 ?

    • [^] # Re: ça me fait toujours rêver

      Posté par (page perso) . Évalué à 1. Dernière modification le 24/08/14 à 15:20.

      Donc ca te derange pas de pouvoir exploiter que 10% de ta carte réseau car le cpu est sature? D avoir plein de bug et du code pas clean?

      le développeur responsable de ça le faire

      C'est vrai ont as tous le temps de décoder les adresses mac faire la gestion des ips puis du tcp dans les trames brutes… non, le dev attends d'obtenir via read/write le contenu des packets, pas les trames complètes des carte réseau, sans parler de la sécurité. Donc le noyau faire lui même les sommes de contrôles, et c'est toujours casse pied d avoir des problèmes de lenteur a cause du code d un autre.
      Loi de wirth.

      Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

  • # Du lourd !

    Posté par (page perso) . Évalué à 3.

    C'est vraiment sympa. Il y a vraiment eu un beau boulot de fait.

    Je suis particulièrement heureux de l'amélioration de l'hibernation S3 et des performances réseau.

  • # luminosité

    Posté par . Évalué à 4.

    merci pour cette dépêche.

    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

    J'ai été heureux en voyant ce bug corrigé et qui se traîne depuis un moment. A chaque fois que je pressais la touche de luminosité des noms d'oiseaux sortaient systématiquement de ma bouche.

  • # Faute, carton jaune, placement à 9m

    Posté par . Évalué à 3.

    Linux permettait de le faire pour le mode ESP d’IPsec (mode tunnel) et, à partir de cette version, l’autorise également pour le mode AH (mode transport).

    C'est faux merci de corriger …
    Ah : authentication + integrity
    esp : encryption + integrity

    ah fonctionne en mode tunnel et transport
    ainsi que esp quoique le mode transport n'ai que peu d'intérêt.

    "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

    • [^] # Re: Faute, carton jaune, placement à 9m

      Posté par (page perso) . Évalué à 4.

      Corrigé, merci.

    • [^] # Re: Faute, carton jaune, placement à 9m

      Posté par . Évalué à 5. Dernière modification le 13/06/14 à 20:17.

      A un autre endroit :

      /dev/random utilisera les nouvelles instructions RDSEED

      Est ce une errreur ? Où l'on remplacerait utilisera par pourra utiliser ?
      Ou bien 'la fin d'un problème' (sic) ? Où l'on donne à un micrologiciel non-ouvert l'exclusivité, sur x86, de cette fonction essentielle ?

      • [^] # Re: Faute, carton jaune, placement à 9m

        Posté par (page perso) . Évalué à 4. Dernière modification le 14/06/14 à 00:54.

        Ça utilisera en plus d’autre sources.

        […] 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.

        Sinon

        Ou bien 'la fin d'un problème' (sic) ?

        D’où est-ce que tu cites ça?

        Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: Faute, carton jaune, placement à 9m

          Posté par . Évalué à 5. Dernière modification le 14/06/14 à 09:48.

          D’où est-ce que tu cites ça?

          Une expression, pas une citation.

          Ça utilisera en plus d’autre sources.

          La page wikipedia résume très bien la situation, pour ceux intéressés par le sujet (il y a également les posts G+ de TS'O, déjà cités ici en commentaire d'un autre dépêche, qui sont parmi le choix de références, en bas de page).

          Random utilise d'autres soures, par exemple le bruit réseau. Mais, par exemple : des distributions comme Fedora génèrent les clefs lors du premier boot. A ce stade là, l'entropie autre est quasi nulle. Les clefs générées se basent concrètement quasiment uniquement sur la puce Intel. Hum, dans le temps on aurait dit "defective by design".

          Autre point, l'histoire a été souvent relatée, et une pétition avait été faite pour demander le retrait total du support de rdrand (génération des cpu avant ceux ayant rdseed). Pétition balayée d'un revers de main. L'histoire a cependant rebondi, et un plus large public s'y est intéressé (semble t il), lorsque Redhat a essayé de coller ce patch qui propose en option une confiance aveugle dans l'implémentation de Intel et outrepasse totalement le pool d'entropie habituel du noyau.

          J'évite tout troll et parti pris, j'espère. Donc le "ça utilisera en plus d'autres sources" est normal L'inverse serait anormal, et si quelqu'un (ayant le niveau technique) pouvait confirmer que 'tout va bien' et qu'il n'y a plus lieu de s'inquiéter, ça serait extra…

          C'est sur des sujets comme ceux là que l'on constate la force du modèle de développement à sources ouvertes.

          • [^] # Re: Faute, carton jaune, placement à 9m

            Posté par (page perso) . Évalué à 5.

            D’où est-ce que tu cites ça?

            Une expression, pas une citation.

            sic, ça veut dire grosso-modo «écrit tel quel dans le texte», donc je trouve ça étrange pour une expression, mais pourquoi pas.

            Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: Faute, carton jaune, placement à 9m

            Posté par . Évalué à 2.

            Linux devrait offrir un moyen pour l'utilisateur de fournir de l'entropie, qui pourrait être :
            - Les bits de poids faible de l'entré micro
            - Idem avec une webcam
            - un fichier personnel (image)
            - un hash des éléments précédents

            "La première sécurité est la liberté"

            • [^] # Re: Faute, carton jaune, placement à 9m

              Posté par (page perso) . Évalué à 2.

              Tu parles de cat /dev/snd/pcmC0D0p > /dev/urandom, ou cat /dev/video0 > /dev/urandom ?
              Ok spa les bits de poids faible, mais c'est pas dur a coder si tu veux le faire.

              • [^] # Re: Faute, carton jaune, placement à 9m

                Posté par . Évalué à 2.

                Vers /dev/random plutôt que urandom, non ?

                Dans tous les cas, il me semble que ça n'augmente pas le niveau d'entropie disponible (estimé par le noyau), par contre l'entrée est bien mixée dans le pool ce qui ne peut pas faire de mal.

                • [^] # Re: Faute, carton jaune, placement à 9m

                  Posté par . Évalué à 2.

                  Si tu rajoutes des trucs aléatoires, comme les bits de poids faibles d'une source audio, ou les bits de poids faible d'une image, tu ajoutes de l'entropie ! Le hash sert uniquement à enlever tout "pattern".

                  "La première sécurité est la liberté"

                • [^] # Re: Faute, carton jaune, placement à 9m

                  Posté par (page perso) . Évalué à 3.

                  man 4 random a l'air de dire que c'est bien vers urandom qu'il faut écrire, ce qui me parait logique, random en a rien à faire d'une source d'entropie

                  • [^] # Re: Faute, carton jaune, placement à 9m

                    Posté par . Évalué à 4.

                    A priori, les 2 utilises la même source d'entropie, sauf que l'un bloque et l'autre non.

                    Ecrire semble ajouté des données mais n'augmente pas les chiffres d'entropie réelle.

                    Il faudrait voir si il est facile de lire une entrée micro (même du bruit de ligne, peut être suffisant) ou une webcam pour augmenter ce pool.

                    "La première sécurité est la liberté"

                    • [^] # Re: Faute, carton jaune, placement à 9m

                      Posté par (page perso) . Évalué à 3.

                      La webcam, ça ne me semble pas une très bonne idée pour l'autonomie. Pour le micro, je crois que ça ne change pas grand chose.

                      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: Faute, carton jaune, placement à 9m

                      Posté par . Évalué à 5.

                      Il faudrait voir si il est facile de lire une entrée micro (même du bruit de ligne, peut être suffisant) ou une webcam pour augmenter ce pool.
                      C'est ce que fait le démon randomsound il me semble.

                      Sinon il y a aussi haveged qui est pas mal (étudié et proposé par des scientifiques français à l'origine), qui se base sur les compteurs de performance au sein des processeurs.

  • # Linux 3.15 supporte la manette PS4

    Posté par . Évalué à 10. Dernière modification le 13/06/14 à 15:27.

    Hey!

    Petite amélioration qui ravira les joueurs Linux: la Dualshock 4 (i.e. la manette PS4) est compatible avec ce nouveau kernel!
    http://www.phoronix.com/scan.php?page=news_item&px=MTY1MjQ

    PS: Et merci encore pour cet article, je les attends à chaque fois avec impatience! ;)

  • # AVX-512 ?

    Posté par . Évalué à 2.

    Est-ce que le "support" d'AVX-512 dans le noyau concerne des optimisations faites au noyau qui utilisent cette instruction ou l'OS a-t'il vraiment quelque chose à voir dans le fait que des programmes utilisent cette instruction ? Le noyau scanne-t'il les programmes au démarrage pour vérifier leur validité ? Je ne vois pas trop comment peut le noyau empêcher un binaire d'utiliser des instructions AVX-512.

    • [^] # Re: AVX-512 ?

      Posté par (page perso) . Évalué à 3.

      Ce sont des optimisations faites pour le noyau.

    • [^] # Re: AVX-512 ?

      Posté par . Évalué à 5.

      Au minimum, l'OS sauvegarde les registres AVX-512, sinon les programmes ne peuvent pas les utiliser.

      "La première sécurité est la liberté"

      • [^] # Re: AVX-512 ?

        Posté par (page perso) . Évalué à 7.

        Ah si, ils peuvent, c'est juste que le résultat est un peu moins prédictible :)

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: AVX-512 ?

      Posté par . Évalué à 6.

      C'est uniquement détection du support AVX-512 et la sauvegarde des registres concernées au changement de contexte qui a été ajouté.

      Le noyau lui-même ne se sert pas de ces instructions. En général, il s'en sert assez peu, à part peut-être pour les copies-mémoire (même pas sûr vu que le cache regroupe les accès par dessus) et éventuellement de nouvelles fonctions implémentées en hard (CRC, crypto, etc).

      • [^] # Re: AVX-512 ?

        Posté par (page perso) . Évalué à 2.

        Merci Brice, je prendrai le temps de vérifier mieux la prochaine fois. Je pensais en effet aux copies dans le noyal.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.