Sortie du noyau Linux 4.2

110
16
sept.
2015
Noyau

La sortie de la version stable 4.2 du noyau Linux a été annoncée le 30 août 2015 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 (qui est sous licence CC BY-SA, Attribution - Partage dans les Mêmes Conditions).

Sommaire

Annonces des RC par Linus Torvalds

RC-1

La version RC-1 est sortie le dimanche 5 juillet 2015 :

C’est dimanche, deux semaines se sont écoulées et la fenêtre d’intégration est fermée. J’ai seulement mis à jour la référence dans les branches git ; les archives tar et les corrections devraient être également disponibles.

Je pensais que cette RC serait l’une des plus grosses que nous ayons eues, mais il se trouve que tout dépend de la manière de compter. Si l’on compte seulement le nombre de modifications, c’est effectivement l’une des plus grosses RC-1 de l’histoire récente, mais la 3.10-rc1 était pratiquement aussi grosse et, à partir de là, elle a grossi vraiment plus que d’habitude. Je doute que nous égalions la taille de la 3.10 au moment de la sortie, étant donné que nous avons fait des progrès pour ne pas intégrer de grosses modifications après la sortie de la RC-1.

Et il se trouve que la 3.15-rc1 avait plus de modifications que la 4.2-rc1 (ça se joue à un cheveu), donc, encore une fois, ce n’est pas la plus grosse RC1 de tous les temps, si l’on compte le nombre de modifications.

Mais ça reste vraiment une des plus grosses. Les changements sont bien trop nombreux pour pouvoir en communiquer la liste, et donc, comme d’habitude pour les RC1, j’ai joint mon journal de fusion, dans lequel les personnes nommées sont celles dont j’ai fusionné les changements, et pas forcément celles qui ont effectivement écrit le code. Pour avoir le détail, jetez un œil dans le dépôt git.

Cependant, si l’on regarde uniquement le nombre de lignes modifiées, c’est vraiment la plus grosse de toutes les RC que nous ayons jamais eue, avec un peu plus d’un million de lignes ajoutées (et presque 250 000 lignes enlevées). Cela dépasse le précédent record (3.11-rc1), dont la taille était principalement due à l’ajout de Lustre dans la branche staging.

Ce nombre important de lignes est largement dû à une seule cause : l’ajout massif des nouveaux en-têtes de descriptions de registres des cartes graphiques d’AMD. En fait, ces en‐têtes de descriptions de registres représentent à eux seuls 41 % de l’ensemble des modifications. Le reste de ce nouveau pilote de périphérique représente encore 8 % du total, ce qui fait que l’on se retrouve dans la situation pour le moins étrange dans laquelle un seul pilote couvre presque la moitié de la RC-1 en nombre de lignes.

À part cette anomalie peu courante, le reste semble plutôt normal — principalement des pilotes et des mises à jour d’architectures. L’architecture Renesas H8/300 est revenue sous une nouvelle forme après nettoyage, ainsi nous prenons en charge de (pseudo) nouvelles architectures, mais c’est petit comparé au volume de modifications provenant d’ARM (avec x86, loin derrière). Il est intéressant de remarquer qu’il y a eu quelques changements dans le code de bas niveau de l’architecture x86 : à la fois une réorganisation du code source du prologue x86, et beaucoup de nettoyage dans la gestion des unités de calcul à virgule flottante. C’est plutôt inhabituel, étant donné que le code de bas niveau x86 est plutôt stable et qu’il est rare d’y voir de gros changements.

Hormis les « pilotes et les architectures », il y a beaucoup de modifications dans les systèmes de fichiers, y compris des changements fondamentaux et du nettoyage dans la gestion des liens symboliques par Al. Ainsi que toutes les mises à jour habituelles dans les différents systèmes de fichiers, le réseau, la cryptographie, les outils, les tests, etc.

Linus

RC-2

La version RC-2 est sortie le dimanche 12 juillet 2015 :

Une autre semaine, une autre RC. Que dire ? Trouvez‐moi ennuyeux, mais c’est comme ça que ça marche.

Ce n’est pas une RC particulièrement grosse, et ça a été plutôt calme. Il y a, certes, eu quelques ennuis avec la RC-1, mais tout ça semblait plutôt négligeable, donc espérons que la RC-2 se terminera avec encore moins de problèmes ennuyeux.

La RC-2 se compose en gros d’un tiers de pilotes (DRM en constitue l’essentiel), un tiers d’architectures (ARM, MIPS et PA-RISC, et un brin d’x86) et un tiers de divers. Ce qui sort du lot concerne principalement les systèmes de fichiers (Btrfs) et quelques mises à jour concernant les minuteurs, et les outils de gestion des performances propres à l’infrastructure de l’outil plutôt qu’au noyau.
Le journal abrégé ci‐dessous donne plus de détails, vous pouvez le parcourir rapidement (il n’est pas si gros) pour avoir une idée de ce qui a été fait.

Allez‐y, testez et vérifiez que tout fonctionne bien.

Linus

RC-3

La version RC-3 est sortie le dimanche 19 juillet 2015 :

C’est un dimanche habituel, avec une sortie de RC relativement normale. Il y a eu quelques retombées dues au nettoyage des routines des unités de calcul en nombres flottants sur x86, mais ça ne concerne que les processeurs avec l’instruction xsaves, et tout devrait être rentré dans l’ordre maintenant.

Il y a approximativement 50 % de pilotes, le reste est constitué pour moitié de « mises à jour d’architectures » (x86, ARM, m68k, S390 et ARC) et le reste est constitué d’un peu de tout. Du réseau, des outils, du système de fichiers, etc.

J’aurais aimé que la RC-3 soit un peu plus petite qu’elle ne l’est, mais je ne pense pas qu’il y ait quoi que ce soit de particulièrement effrayant qui se trame.

Linus

RC-4

La version RC-4 est sortie le dimanche 26 juillet 2015 :

Nouvelle semaine, nouvelle RC.

J’espérais vraiment que l’activité se calme, mais ce n’est pas encore le cas. Il n’y a rien de spécialement gros ou effrayant, mais nous n’avons toujours pas atteint le stade à partir duquel le rythme diminue et que les bogues deviennent vraiment insignifiants.

Nous avons encore eu quelques bogues liés au travail de nettoyage bas niveau de l’assembleur x86 et de l’instruction syscall, concernant la compatibilité 32 bits (uniquement utile pour AMD) qui s’est retrouvée subtilement cassée. Tout devrait être désormais corrigé, donc si vous utilisez un noyau 64 bits avec un espace utilisateur 32 bits (notamment des outils tels que Wine, etc.) et que vous avez rencontré des soucis auparavant, mettez‐vous à jour.

Bien sûr, merci de vous mettre à jour, même si vous n’avez pas eu de problème jusqu’ici, juste pour tester la nouvelle RC.

Si l’on excepte ce problème, il s’agit principalement de pilotes et du réseau. USB, processeurs graphiques, pilote MMC, pilotes réseau, audio. Avec un peu d’activité du côté d’ARM due essentiellement à des pilotes, avec des mises à jour de l’arbre des périphériques correspondant à des corrections, la gestion des cartes mémoire multimédia MMC. Nous avons aussi quelques petites corrections dans les systèmes de fichiers.

Allez‐y, testez.

Linus

RC-5

La version RC-5 est sortie le dimanche 2 août 2015 :

Nous arrivons maintenant dans les dernières RC, mais il semblerait que cette 4.2 soit une version qui nécessitera sans doute plus de RC que les sept habituelles. Les choses ne se calment pas comme je l’avais espéré, et un nombre important de problèmes ont été découverts.

Par exemple, il y a un correctif dans le cœur de VFS qui a été seulement fusionné hier – le bogue en lui‐même était ancien, mais certains changements apportés par cette version l’ont rendu beaucoup plus visible et fréquent. Il y a également des régressions sur le MST DP i915 qui sont relativement cachées, mais qui nécessitent encore du travail, tout comme les quelques manques autour du nettoyage bas niveau du code x86 et des interruptions non masquables (NMI). De plus, il y a également des questions en attente concernant des changements dans la mémoire virtuelle.

Rien de cela n’est particulièrement méchant, et ces bogues sont des cas très spécifiques, difficiles à atteindre, et des points de détails, ce qui fait que je ne suis pas particulièrement inquiet. Mais c’est plus que je ne l’escomptais à ce niveau de version. Peut‐être que dans deux semaines, lorsque la RC-7 sera là, je serai plus serein, les choses iront bien et je serai prêt à valider la sortie d’une 4.2, mais actuellement, j’espère juste que les choses vont se tasser et qu’il n’apparaîtra pas d’autres problèmes.

Mis à part ces petits désagréments, les choses semblent plutôt classiques. Pas beaucoup de perturbations dues aux architectures cette fois‐ci (mis à part ce problème de NMI relaté précédemment) – et un peu plus des trois quarts des modifications sont dues aux pilotes, avec DRM, InfiniBand, réseau, et gestion de charge SCSI. Le reste est composé principalement de modifications de système de fichiers et de code réseau.

Vous pouvez consulter le résumé de la liste des modifications, qui donne une assez bonne vue sur les détails. S’il vous plaît, continuez à tester. Et sachez que si vous m’envoyez une demande d’intégration que je considère comme inappropriée, je ne réagirai sans doute pas de manière mesurée (vous êtes prévenus). Nous avons vraiment besoin de ralentir et retrouver un rythme normal (bien que cette RC-5 ne soit pas vraiment si grosse que ça).

Linus

RC-6

La version RC-6 est sortie le dimanche 9 août 2015 :

La semaine dernière, je n’étais pas satisfait de l’état des RC, mais ça va mieux. Non seulement, la RC-6 est beaucoup plus petite, mais en plus les problèmes qui m’embêtaient ont été résolus au début de la semaine, et il n’en reste pas de graves. Si tout va bien, je pense que nous terminerons selon le calendrier habituel (c’est‐à‐dire dans deux semaines). Touchons du bois.

Dans la RC-6, les statistiques semblent un peu bizarres, parce que les modifications de l’architecture ARC dominent (30 % du total). C’est dû au fait que les autres changements sont plutôt petits, et aussi que la correction du « llock/scond livelock » n’était pas petite. Mais je ne m’inquiète pas.

Si on exclut la bizarrerie ARC, tout paraît normal. Principalement des pilotes (pilotes graphiques, son, I²C, entrée, USB, thermique, etc.) et des mises à jour d’architectures (MIPS et SPARC). Avec quelques corrections des systèmes de fichiers et de la mémoire virtuelle.

S’il vous plaît, testez et vérifiez que les problèmes ont bien été corrigés. OK ?

Linus

RC-7

La version RC-7 est sortie le dimanche 16 août 2015 :

En général, ces temps‐ci, la RC-7 est notre dernière RC, et la semaine prochaine devrait sortir la version 4.2 finale. Mais à ce stade, je n’ai toujours pas pris ma décision. Au moment de la RC-5, je m’inquiétais de quelques questions en suspens. Puis, dimanche dernier, pour la RC-6, j’étais plus confiant. Et maintenant, une semaine plus tard, et nous avons constaté quelques répercussions provenant de la réécriture du prologue x86 bas niveau, et je ne sais plus.

Donc, ça peut être la dernière RC, ou pas. Cela dépendra si d’autres problèmes surviennent la semaine prochaine, et de mon ressenti dimanche prochain. Une partie de moi est convaincue que les problèmes bizarres de compatibilité 32 bits, etc., sont enfin réglés, mais l’autre partie de moi est encore un peu méfiante.

Dans l’ensemble, ça s’est assez bien passé. C’est une bonne petite RC, avec des statistiques relativement normales. 70 % de pilotes (réseau, NTB, Xen, md, pilotes graphiques), le reste étant principalement constitué de quelques mises à jour d’architectures et de réseau, hors pilotes. Le mini‐journal en annexe donne les détails habituels — il est vraiment court.

Par conséquent, une sortie la semaine prochaine est certainement encore possible.

Linus

RC-8

La version RC-8 est sortie le lundi 24 août 2015 :

La version 4.2-rc8 est disponible, et évidemment ça signifie que finalement je me suis dégonflé, et que j’ai décidé de retarder la version finale d’une semaine.

Il n’y a plus vraiment de problèmes non résolus, et donc j’ai hésité entre sortir la version finale ou une autre RC. Mais comme cette semaine nous avons eu un autre problème de bas niveau sur x86, et qu’en plus beaucoup de personnes sont en vacances, j’ai décidé qu’attendre une semaine de plus ne ferait pas de mal. Mais il s’en est fallu de peu. Cette RC-8 est assez petite, et je pense vraiment que ça aurait pu le faire dans les deux cas.

Donc la RC-8 n’est pas une grosse RC et la majorité des changements sont des annulations de modifications de dernière minute qui n’étaient pas vraiment prêtes. Surtout des changements sur les pilotes, le réseau, des correctifs sur x86 et une poignée de correctifs sur l’outillage de performance. La liste de modifications donne une vue d’ensemble détaillée.

Linus

Version finale

La version finale est sortie le 30 août 2015 :

Donc, à en juger par le peu d’activité de cette semaine, ce n’aurait pas été une erreur de sortir la version 4.2 la semaine dernière, après tout. Mais il y a vraiment eu quelques corrections effectuées, et retarder la version 4.2 d’une semaine ne posait pas vraiment de problème.

Donc, la voici, et la fenêtre de fusion pour la version 4.3 est à présent ouverte. J’ai déjà en attente quelques demandes anticipées d’intégrations, mais comme toujours je commencerai à les traiter demain et donnerai à la version 4.2 le temps de s’installer.

La liste des changements par rapport à RC-8 est minuscule et se trouve en annexe. Le correctif est plutôt petit lui aussi.

Allez la récupérer.

Linus

Liste des nouveautés

Architecture

Systèmes monopuces ARM

  • Les processeurs Allwinner A23 ainsi que les Broadcom BCM63138 bénéficient de la prise en charge du SMP (multiprocesseur).
  • Un embryon de prise en charge pour la carte i.MX7d. L’i.MX7 dispose de deux cœurs Cortex-A7 pouvant atteindre des fréquences de 1,0 GHz, ainsi que d’un cœur Cortex-M4 cadencé jusqu’à 256 MHz, le tout avec une prise en charge des mémoires LPDDR2 et LPDDR3, un bus Ethernet gigabit, et un bus PCI Express. La série des i.MX7 est principalement réservée à ce que l’on appelle communément « l’Internet des objets ».
  • Un embryon de prise en charge pour le ZTE ZX296702, qui dispose d’un double cœur Cortex-A9, ainsi qu’une puce Mali 400.
  • Une prise en charge pour le NVIDIA Tegra HDA.
  • Une prise en charge pour les nouvelles plates‐formes Broadcom suivantes : Buffalo WXR-1900DHP, SmartRG SR400ac, et ASUS RT-AC87U.
  • Une prise en charge pour la carte ARM Juno.
  • Une prise en charge pour le système monopuce HiSilicon Hi6220, permettant ainsi de faire fonctionner la carte HiKey (carte disposant d’un Cortex-A53 octocœur 64 bits pour 130 US$).
  • La plate‐forme mvebu prend désormais en charge le Compulab CM-A510, le D-Link DNS-327L et les cartes Linksys basées sur un Armada 385.
  • La plate‐forme OMAP gagne également la prise en charge du Baltos IR 5221, du LogicPD Torpedo, ainsi que du Toby Churchill SL50 (lien vers le SL40, aucun lien vers le SL50 n’existe pour le moment).

Renesas H8/300

Le noyau Linux gagne encore en portabilité en ajoutant la prise en charge d’un nouveau processeur, le Renesas H8-300 dans sa version 32 bits. Ce processeur se retrouve par exemple dans les Lego Mindstorms. Jusqu’alors, sa prise en charge était maintenue dans un arbre séparé du noyau officiel. Il est désormais intégré au noyau 4.2 grâce à un ajout de plus de 7 000 lignes de code.

ARCv2, HS38 CPU Cores

Les processeurs HS38 issus d’une architecture ARCv2, et développés par DesignWare, sont désormais directement gérés dans le noyau. Cette évolution de l’architecture ARC est censée être deux fois plus performante, tout en ayant une faible consommation et un nombre de transistors peu élevé.

Général

Amélioration des verrous

Grâce à une amélioration des verrous (passage de ticket spinlock à qspinlocks), la montée en charge sur les systèmes ayant beaucoup de processeurs et les architectures à mémoire non uniforme (NUMA) va être plus performante. Cela ne dispense cependant pas les développeurs de travailler leurs verrous [Cf. phoronix.com].

Amélioration de l’ordonnanceur

Diverses améliorations de l’ordonnanceur, dont l’équilibrage sur les systèmes NUMA [Cf. phoronix.com].
Amélioration de performance des disques à mémoire Flash SSD de 12 % sur certains tests, quatre fois sur d’autres tests en désactivant des choses inutiles sur les disques statiques, comme la NCQ, et autres mesures qui laissaient des temps à vide pour le SSD.
[Cf. phoronix.com].

Le nettoyage du code d’assemblage continue

La suppression du code d’assemblage x86 commencée dans le noyau 4.1 continue. De petites améliorations de vitesse et des micro‐optimisations sont à attendre. Cela améliore aussi la gestion des interruptions [Cf. phoronix.com].

Plus de limite pour une suite de liens symboliques

Le code principal de recherche des noms de fichiers a été retravaillé afin de ne plus utiliser la récursivité. Les effets seront visibles au niveau de l’utilisation de la pile, qui sera réduite (améliorant la fiabilité des systèmes de stockage complexes) et de la limite des niveaux d’imbrication des liens symboliques, qui a été relevée.

L’appel système splice et les sockets Unix

Les sockets de domaine Unix gèrent désormais l’appel système splice().

Control group write back

Les correctifs d’écriture différée selon le groupe de contrôle (cgroup) ont été intégrés. Cela permet un meilleur contrôle de l’écriture de données selon les groupes de contrôle, corrigeant des comportements qui étaient depuis longtemps défaillants [LWN.net].

Développeurs

Amélioration de l’outil perf

Comme à chaque nouvelle version, l’outil perf bénéficie de son lot d’améliorations listées dans le correctif suivant.

Pilotes graphiques libres

Direct Rendering Manager

Maintenant au sein de DRM, l’interface logicielle (API) de gestion atomique du mode graphique est considérée comme complète, elle est donc exposée par défaut à l’espace utilisateur. Cette interface, intégrée initialement dans Linux 4.0, permet à l’espace utilisateur de vérifier si une configuration est gérée par le matériel avant de l’appliquer. Cela devrait donc permettre d’exploiter l’interface logicielle KMS des plans graphiques ajoutée dans Linux 3.19. Martin Graßlin, développeur du compositeur KWin, a déjà exprimé son souhait d’utiliser cette nouvelle interface, afin de réduire à néant les coûts liés à la composition graphique. Pour plus d’informations sur le sujet, vous pouvez consulter les articles écrits par Daniel Vetter, mainteneur du pilote i915 (Intel), sur LWN.net [partie 1 et partie 2].

Pour plus d’informations, vous pouvez consulter les demandes d’intégration DRM et panneaux.

AMD/ATI

Pilote de rendu nouvelle génération (pilote amdgpu)

Plus d’un an et demi après son annonce à la Game Developer Conference 2014, le pilote AMDGPU est enfin fusionné dans le noyau. Ce pilote, issu d’AMD, représente le nouveau cœur dans le noyau pour la gestion des cartes à base de processeur graphique AMD CI+. Le but pour AMD est d’avoir une interface unifiée, tant pour les pilotes libres que pour les pilotes propriétaires. Cette nouvelle architecture permet de garder les pilotes (que ce soit Gallium3D ou Catalyst) en espace utilisateur. Ce pilote a nécessité l’ajout de plus de 400 000 lignes de code, et de plus de 200 fichiers.

Cette fusion des équipes de développement noyau devrait garantir la gestion des futures générations de processeurs graphiques AMD avant leur sortie commerciale, mais également augmenter la stabilité et les performances des deux pilotes.

La FSF s’est permis de rappeler que cette architecture n’est cependant pas plus ouverte que la précédente. En effet, le pilote AMDGPU intègre un paquet binaire redistribuable à charger sur les cartes AMD pour pouvoir être fonctionnel, comme sur le pilote RADEON.

Pour plus d’informations, vous pouvez regarder la conférence d’Alex Deucher à l’XDC 2014, la conférence des développeurs X.Org qui s’est déroulée à Bordeaux en octobre dernier. Vous pouvez également consulter la demande d’intégration.

Pilote de rendu pour les anciennes générations (pilote radeon)

Avec l’introduction du pilote AMDGPU, la majorité des efforts de développement devrait maintenant se concentrer sur ce pilote. Le pilote radeon continuera à être maintenu et amélioré, mais à un rythme bien plus lent.

Cette nouvelle version du pilote apporte cependant une fonctionnalité importante, la gestion du codage vidéo avec le moteur matériel VCE1. Ce moteur a été ajouté fin 2011 aux processeurs graphiques AMD et permet de compresser directement des vidéos au format H.264 / MPEG-4 AVC. Cette fonctionnalité est destinée à permettre l’enregistrement de la sortie vidéo et la diffusion en temps réel de cette vidéo depuis un ordinateur puissant vers une machine plus économe située directement dans le salon de joueurs (voir la solution GameStream de NVIDIA). Elle permet également de diffuser ses exploits en direct sur Internet avec une perte de performance plus faible que les solutions traditionnelles de codage sur le processeur (voir Steam Broadcast).

Pour plus d’informations sur les nouveautés du pilote radeon, vous pouvez consulter la demande d’intégration radeon.

Pilote HSA (pilote amdkfd)

Le pilote amdkfd (inclus dans Linux 3.19), qui permet de faire communiquer plus rapidement le processeur graphique et le processeur central, a reçu l’ajout d’un module de gestion d’interruptions et autres événements. Ce module permettra l’ajout d’un nouveau module dédié au débogage des applications HSA.

Un paramètre noyau a également été ajouté afin de spécifier si une application doit recevoir le signal SIGBUS lorsque le processeur graphique rencontre une exception liée à la mémoire et que l’application n’est pas en mesure de recevoir cette information, ou si un message doit être écrit dans le journal du noyau. Ce paramètre est activé par défaut.

Pour plus d’informations, vous pouvez consulter la demande d’intégration amdkfd.

Intel (pilote i915)

Comme d’habitude, le pilote i915 a reçu beaucoup de modifications de la part des ingénieurs d’Intel. Les nouveautés principales sont la finalisation de la gestion dynamique des espaces d’adressage (voir la dépêche sur Linux 4.1), ainsi que l’activation du vérificateur de commandes pour les processeurs Haswell. Ces modifications vont permettre d’activer des extensions OpenGL quand Mesa3D les gérera.

Du côté consommation d’énergie, le pilote a reçu des optimisations afin de réduire l’activité du processeur lors de la vérification des commandes envoyées par l’espace utilisateur. Le pilote a également affiné la configuration du processeur graphique en mode boost afin d’éviter son utilisation lorsque ce n’est pas nécessaire. La gestion des modes basse consommation pour le contrôleur d’affichage fait également son arrivée.

Toujours du côté de la gestion du mode graphique, la gestion atomique ne fait toujours pas partie de Linux 4.2. Mais le travail continue ! On peut cependant noter une gestion expérimentale des processeurs Broxton qui réutilise le bloc d’affichage des processeurs Skylake.

Les processeurs Skylakes et Broxtons sont toujours marqués comme expérimentaux et ne sont pas gérés par défaut. C’est ennuyeux car les processeurs Skylake sont maintenant disponibles à la vente. Espérons que Linux 4.3 éliminera cette limitation.

Toutes les nouveautés ne sont pas décrites ici. Pour plus d’informations, vous pouvez consulter la publication sur le blog de Daniel Vetter, mainteneur i915.

NVIDIA (pilote nouveau)

Aucune nouveauté pour le pilote nouveau. Ben Skeggs, le mainteneur, a été très occupé à réorganiser le cœur du pilote pour que celui‐ci soit plus facile à utiliser et que le compilateur vérifie plus de choses à la compilation. Ce travail vient d’être accepté dans Linux 4.3 et nous partagerons plus d’informations à sa sortie !

Il est cependant à noter que les microcodes nécessaires au processeur graphique du Tegra K1 (GK20A) ont fait leur entrée dans linux-firmware.

VirtIO (pilote virtio-gpu)

Le pilote graphique pour systèmes virtualisés gérant VirtIO fait son entrée dans le noyau. Celui‐ci exporte pour l’instant uniquement l’interface KMS, sans accélération graphique 3D. Cette interface est utilisable directement avec un compositeur Wayland ou via l’utilisation du pilote xf86-video-modesetting. Le pilote virtio-gpu a cependant pour vocation de proposer une accélération 3D via Virgil3D.

Pour plus d’informations, vous pouvez consulter la demande d’intégration virtio-gpu.

Pilotes graphiques pour systèmes monopuces

Le pilote Omapdrm a été partiellement réécrit pour corriger des bogues (crash au déchargement des modules, cisaillements lors des changements de pages, etc.) présents depuis des années. Il en résulte un code plus lisible et maintenable, tout en étant plus stable et robuste. Le code a été majoritairement testé sur la Pandaboard OMAP4, avec un et deux écrans.

Le pilote DRM/MSM (pour les puces graphiques SnapDragon) voit l’ajout de la prise en charge de l’Adreno 306 que l’on retrouve dans le SnapDragon 400c. Ce dernier promet d’être moins énergivore que son prédécesseur, l’Adreno 305.
De plus, nous avons droit aux habituels correctifs (assez nombreux), et l’ajout de la prise en charge du format de tampon NV12MT.

Réseau

Suppression du cache pour les routes en IPv6

Si vous avez bonne mémoire, vous vous souvenez peut‐être de la suppression du cache des routes en IPv4, décrite dans la dépêche sur le noyau Linux 3.6.

C’est désormais au tour du système IPv6 de recevoir les mêmes changements, grâce à Martin KaFai Lau, développeur employé par Facebook. Son travail s’appuie sur la même idée et permet aux deux versions d’IP de converger à ce sujet dans le noyau Linux.

Ses modifications sont réparties en plusieurs séries, mais la plus importante est celle‐ci. Elle contient notamment des indicateurs de performance, et des détails sur la nouvelle implémentation (qui continue de sauvegarder les routes avec des MTU différentes).

Lecture des en‐têtes du premier paquet TCP (SYN) sur une interface de connexion

Lorsqu’un développeur d’applications ouvre une interface de connexion (socket) avec le protocole TCP, il ne peut habituellement obtenir des informations sur la connexion qu’une fois que la poignée de main (SYN-ACK, ACK) est terminée.

Les informations contenues dans les en‐têtes du premier paquet reçu sont perdues, l’application ne peut pas y avoir accès.

Google semble avoir un cas d’utilisation d’étude de ces paquets, à des fins d’empreintes numériques. Les développeurs de Google ont donc proposé une modification ajoutant une option pour faire sauvegarder les en‐têtes de ce paquet par le noyau, et pour demander à les lire ensuite.

Pour la petite histoire, les développeurs de chez Google indiquent utiliser depuis trois ans une approche équivalente en interne.

Un nouvel algorithme de gestion de congestion pour TCP

La gestion de congestion de TCP est essentielle à tout réseau : c’est elle qui permet d’éviter de prendre toute la bande passante disponible avec une seule connexion. Son principe est d’augmenter progressivement la vitesse d’une connexion, et de détecter quand le réseau commence à être saturé. C’est à chaque client de vérifier l’état de congestion pour permettre un partage sain des capacités du réseau entre tous les utilisateurs, sans aucun mécanisme central.

Même en considérant que tous les clients vont coopérer correctement, ce problème est très loin d’être trivial, notamment pour une détection de saturation réseau correcte. La plupart des algorithmes se basent sur la détection de perte de paquets. Pour qu’un paquet soit considéré comme perdu, il faut d’abord être certain qu’il n’a pas été reçu (donc utiliser un délai de grâce, ce qui augmente la latence). Cette détection peut être compliquée par le fameux problème de saturation de tampon (buffer bloat). Enfin, un réseau peut connaître de la perte naturelle de paquets, sans pour autant être congestionné.

Le nouvel algorithme introduit dans le noyau s’appelle Delay-gradient congestion control. Comme son nom l’indique, l’idée est de changer d’approche. Plutôt que de construire la détection de congestion sur la perte de paquets, mécanisme peu fiable, cet algorithme se base sur les variations du délai de transmission (RTT). Quand ce délai augmente de façon anormale, une congestion est détectée et l’émission de paquet est adaptée pour en tenir compte. Pour plus de détails, le site LWN.net a détaillé le mécanisme.

Pour rappel, vous pouvez consulter les algorithmes disponibles sur votre noyau préféré avec /proc/sys/net/ipv4/tcp_available_congestion_control, et vérifier ou configurer l’algorithme utilisé avec /proc/sys/net/ipv4/tcp_congestion_control.

Meilleure allocation des ports TCP/UDP

Les ports TCP et UDP sont essentiels pour identifier de façon unique une connexion réseau entre deux équipements. Ces ports ne sont pas très nombreux, il ne peut y en avoir que 65 535 pour ces protocoles.

Cela pose un problème pour des serveurs très chargés avec énormément de connexions à ouvrir. Soit il n’y a plus de ports disponibles (et la connexion échoue), soit on peut passer un temps très important à trouver un port disponible, prenant des ressources à tout le monde.

Il y a cependant deux types de ports : ceux qui sont utilisés par un socket serveur ne peuvent être utilisés par quiconque d’autre. On n’a pas le contrôle sur les identifiants utilisés par les clients, on ne peut donc pas prendre le risque côté serveur de réutiliser ce port.

En revanche, pour les sockets client, on peut très facilement réutiliser les ports en maintenant l’unicité de l’identification réseau (basée sur les deux adresses IP, les deux ports, et le protocole utilisé) :

Adresse locale Adresse distante Port source Port destination
A B 2000 80
A C 2000 80
A B 2001 80

La solution proposée par Éric Dumazet est donc de séparer cet espace de ports en deux parties : une pour les utilisateurs de la fonction connect() (client), une autre pour les utilisateurs de la fonction bind() (serveur). En divisant ainsi l’espace, on fait gagner du temps à tout le monde (il est très probable que la fonction connect() pourra partager un port dans les premiers trouvés, tandis que la fonction bind() aura beaucoup moins de vérifications à faire). Si par hasard un des espaces était totalement utilisé, l’itération se poursuivrait sur le second [correctif].

Sécurité

LSM

Les modules de sécurité Linux (LSM) peuvent être « empilés » pour effectuer plus de contrôles de sécurité. Il n’est pour l’instant pas possible d’utiliser simultanément plusieurs modules « monolithiques » : les structures opaques de sécurité présentes un peu partout dans le noyau n’ont pas été dupliquées. Cela signifie donc qu’il est possible d’empiler plusieurs modules « simples » (pour l’instant il n’existe que Yama) avec d’autres modules « lourds » (SELinux, SMACK…).

Par la même occasion, les vérifications liées aux « capabilities » ont été regroupées dans un nouveau module générique qui est empilé par défaut avant tous les autres. Le code pour effectuer ces vérifications a été retiré de tous les autres modules, ce qui lève certaines ambiguïtés et évite la duplication du code.

(Correctifs : 1, 2, 3, 4, 5, 6, 7 ; article LWN.net : Progress in security module stacking).

IMA

Les fichiers des systèmes de fichiers virtuels pour les cgroups et les espaces de noms ne sont plus vérifiés par défaut. Les autres systèmes de fichiers virtuels (devpts, SELinux, binfmt…) sont aussi suggérés comme « à ignorer » dans la politique de test par défaut, parce que les opérations effectuées par IMA ne sont pas pertinentes dans ce cas [correctifs : 1 et 2].

Avec IMA, les signatures des fichiers sont automatiquement définies et mises à jour et ne doivent pas être modifiées à la main par un utilisateur. Dans certains cas, cette opération peut tout de même être nécessaire. Elle est donc limitée aux modes fix et log [correctif].

La nouvelle condition euid ajoutée pour les politiques de sécurité permet de vérifier l’intégrité des fichiers accédés par un processus avec un euid défini. Pour les fichiers CAP_SETUID, les uid et les suid sont pris en compte [correctif].

La règle de filtre mask est étendue pour filtrer les ouvertures de fichiers contenant un ou plusieurs modes MAY_READ, MAY_WRITE ou MAY_APPEND au lieu d’un seul uniquement. Par exemple, mask=^MAY_READ correspondra à l’ouverture de fichiers en lecture et écriture [correctif].

Une nouvelle politique nommée tcb est incluse par défaut. Elle est similaire à la politique ima_tcb existante mais ajoute des règles tirant parti des améliorations mentionnées ci‐dessus. Le changement de la politique ima_tcb aurait potentiellement cassé le fonctionnement des systèmes actuels. Donc, au lieu de définir une nouvelle politique à chaque changement des options par défaut, une nouvelle option de démarrage est définie (ima_policy=) pour spécifier quelle politique incluse utiliser. La politique ima_tcb n’est plus prise en charge [correctif].

SELinux

La liste des classes de sockets netlink a été mise à jour pour tenir compte des nouveaux ajouts dans le noyau. Les classes désormais inutiles ont aussi été supprimées [correctif].

Les fichiers des systèmes de fichiers virtuels sysfs, pstore et debugfs peuvent être étiquetés chacun avec un contexte différent. L’utilisation de ces fichiers peut donc faire partie des contrôles d’une politique de sécurité. Cette amélioration est importante dans le cas d’Android, où certains fichiers de debugfs ont besoin d’être lus par des applications et le système doit donc être accessible par tous, ce qui induit un risque en termes de sécurité [correctifs : 1 et 2].

Un nettoyage de certaines définitions de permissions d’accès obsolètes a été réalisé [correctif].

Une correction a été effectuée pour un bogue introduit par un précédent correctif, qui n’avait pas tenu compte du cas où un système de fichiers était en fait un montage NFS v4.2 [correctif].

Le stockage des catégories NetLabel est maintenant plus optimal, et cela corrige indirectement un bogue sur les systèmes 32 bits [correctif].

Un correctif ajouté dans le noyau 4.1 a introduit une régression qui entraînait la non exécution des vérifications de sécurité pour les accès aux zones de mémoire partagées anonymes. Un nouveau correctif rétablit la situation.

SMACK

Le partage de descripteurs de fichiers DMA-Buf ne fonctionnait pas car SMACK n’était pas capable de récupérer leurs attributs étendus. Cette situation est pour l’instant ignorée, ce qui autorise le partage de ces descripteurs de fichiers [correctif].

Dans certains cas, les erreurs n’étaient pas remontées jusqu’à l’espace utilisateur, ce qui ne permettait pas de savoir d’où venait le problème. Cette situation est prise en charge par ce correctif.

SMACK peut limiter l’usage des capacités CAP_MACADMIN et CAP_MAC_OVERRIDE aux processus s’exécutant avec une étiquette spécifique. Mais n’avoir qu’une seule étiquette n’est pas suffisant dans certains cas (Tizen). L’interface onlycap peut désormais accepter plusieurs étiquettes [correctif].

EVM

Pour éviter que les attributs étendus utilisés par EVM soient supprimés lorsque le système est éteint et régénérés automatiquement à l’exécution, EVM autorise uniquement les fichiers à recevoir une étiquette au moment de leur création. Mais comme les systèmes de fichiers virtuels ne sont pas persistants, la suppression de leurs attributs n’est pas un souci. Cette fonctionnalité est utilisée par certains modules LSM (SELinux ou SMACK, par exemple) [correctif].

Cryptographie

Cette nouvelle version du noyau prend en charge les Chacha20, Poly1305 et RFC7539 [correctifs : 1, 2, 3, 4, 5, 6, 7 et 8].

L’implémentation de SHA-512 a été remplacée par celle, plus flexible, utilisée par le projet OpenSSL. Cette dernière contient une version accélérée pour ARM64 et une version générique [correctif].

Jitter RNG

Une nouvelle source d’entropie pouvant être utilisée uniquement à l’intérieur du noyau a été introduite. Elle n’est donc pas exposée à l’espace utilisateur. Le « jitterentropy RNG » mesure certains intervalles de temps entre des accès mémoire et des instructions exécutées par le processeur pour générer une suite de bits qui vérifie certaines propriétés de non déterminisme. Cela ne permet pas de prouver que l’ensemble est réellement aléatoire, donc il va principalement être utilisé comme graine supplémentaire et non comme remplacement des autres sources d’entropie [correctif ; article LWN.net : Random numbers from CPU execution time jitter ; CPU Jitter Random Number Generator].

Deterministic Random Bit Generator (DRBG)

Le DRBG remplace le générateur de nombres aléatoires par défaut dans le noyau. Il est alimenté par le « jitterentropy RNG » comme source additionnelle [correctifs : 1, 2, 3, 4, 5, 6, 7, 8, 9 et 10 ; SP800-90A Deterministic Random Bit Generator (DRBG)].

Nouvelle API de chiffrement de clef publique

Cette nouvelle interface logicielle permet l’implémentation de calcul déporté de manière asynchrone, lorsque le matériel requis est présent et pris en charge par l’API de chiffrement de Linux [correctif].

Matériel

La gestion du module d’opérations cryptographiques présent sur certaines cartes embarquées Marvell a été ajoutée [correctifs : 1, 2, 3, 4, 5, 6, 7…].

Divers

Tous les usages de structures kernel_param_ops utilisent désormais l’attribut const [correctif].

sysfs, /proc et les conteneurs

Le montage des arborescences sysfs et /proc a été modifié pour n’autoriser que certains dossier particuliers (notamment /sys/debug) à servir de point de montage pour d’autres systèmes de fichiers virtuels. Une nouvelle règle a été ajoutée pour s’assurer qu’une nouvelle instance de ces points de montage (par exemple dans un conteneur) utilise au minimum les attributs de montage utilisés par les instances existantes (nodev, ro et atime). Il avait été proposé d’obliger ces points de montage à être montés avec les options noexec et nosuid, mais cela a été retiré [correctifs : 1, 2, 3, 4, 5, 6, 7, 8 et 9 ; article LWN.net : Enforcing mount options for sysfs and proc].

Liste non exhaustive des vulnérabilités corrigées

Systèmes de fichiers

FUSE

FUSE est une interface noyau qui permet d’implémenter des systèmes de fichiers en espace utilisateur. Malheureusement, son manque de performance est pointé régulièrement.
Linus Torvalds a également fait remarquer que FUSE est un jouet destiné aux gens égarés. Malgré cela, de nombreux systèmes ont vu le jour, tels que SSHFS, WebDrive, boxfs, GlusterFS, jusqu’à ZFS. FUSE a été porté sur divers systèmes, tels qu’OS X, FreeBSD ou encore NetBSD.
La montée en charge a été améliorée. Miklos Szeredi a expliqué que l’un des problèmes vient d’une connexion monolithique à FUSE. Le fait de cloner les connexions FUSE permet de ne plus avoir de lecture‐écriture requête‐réponse sur un seul descripteur de fichier et permet au démon FUSE d’avoir de multiples descripteurs, chacun pouvant être utilisé pour recevoir des requêtes et envoyer des réponses [article sur Phoronix.com].

Btrfs

La gestion des quotas sur les sous‐volumes a été mise à jour. La gestion des périphériques a été améliorée, et divers changements ont eu lieu, pour un total de 1 500 lignes de code changées [article sur Phoronix.com].

F2FS

F2FS, le système de fichiers pour NAND et mémoire flash, gère désormais le chiffrement par fichier.
Une amélioration de la gestion du TRIM a été apportée, ainsi que la récupération des superblocs endommagés et diverses corrections [article sur Phoronix.com].

GFS2

Global File System 2 (GFS2) est un système réseau distribué. Des améliorations de performance ont été faites, par exemple sur le renommage des fichiers. La consommation mémoire via les tampons a été réduite. Une meilleure gestion des verrous a abouti à un gain en performances [article sur Phoronix.com].

ext4

La stabilisation et le nettoyage d’ext4 se poursuivent, surtout suite à l’ajout de la gestion du chiffrement. Il est possible de remplir une partie d’un fichier avec des zéros grâce à l’option FALLOC_FL_INSERT_RANGE [article sur Phoronix.com].

NCQ TRIM

Dans la lancée des optimisations SSD faites par l’ordonnanceur, la prise en charge du NCQ TRIM a été améliorée. Il est maintenant activable ou désactivable au démarrage, mais dans beaucoup de micrologiciels le TRIM n’a pas été testé et peut provoquer erreurs et corruptions [article sur Phoronix.com].

ext3 est en cours de suppression

Assuming no major objections come up, the ext3 file-system driver will be dropped for the Linux 4.3 kernel, confirmation de la suppression d’ext3 au profit d’ext4 qui le gère, sur la LKML.

ext4 est rétro‐compatible avec ext3 et ext2, donc cette suppression est sans conséquences. C’est le mainteneur d’ext3 qui a poussé les correctifs. Le mainteneur d’ext4 a déjà donné son accord.

Virtualisation

KVM

  • ARM : beaucoup de changements sont en cours, mais rien n’est encore prêt pour cette version, il y a juste des corrections de bogues et l’activation du VFIO qui permet d’avoir un pilote en espace utilisateur pour l’accès direct au matériel d’entrées‐sorties. Un point intéressant pour les performances des machines virtuelles.
  • s390 (ordinateurs centraux IBM) : des corrections de bogues et la prise en charge des pages mémoire de plus de 2 Gio.
  • x86 : l’hôte et l’invité peuvent utiliser kvmclock en tant qu’ordonnanceur ; prise en charge de l’écriture combinée ; prise en charge du system management mode (SMM), nécessaire au secure boot pour les invités ; implémentation des compteurs de performance virtualisés pour les processeurs AMD. L’allocation PCI legacy est obsolète et l’option de compilation est maintenant de ne pas inclure le mécanisme par défaut à la compilation (remplacé par VFIO). En plus de cela, il y a aussi le chargement opportuniste de contexte FPU pour les invités utilisant beaucoup le calcul à virgule flottante.
  • code commun : prise en charge de plusieurs espaces d’adressage. Pour l’instant, seul le code x86 SMM en profite, mais l’équipe derrière le s390 veut aussi l’utiliser.

Xen

  • Ajout de make xenconfig pour faciliter la création de noyaux pour invités Xen.
  • Préparation de l’intégration des pages mémoire de 64 Kio pour ARM.
  • Utilisation automatique de hvc0 pour ARM.

Le bilan en chiffres

Linux 4.2 permet au noyau de passer le cap des 20 millions de lignes de code et plus de 50 000 fichiers. Cette version est la seconde en termes de nombre de modifications depuis l’introduction de Git. En effet, le noyau 3.15 reste malgré tout légèrement plus imposant, mais nous sommes ici en présence d’une grosse version. Outre le nombre de modifications, le nombre de lignes insérées dépasse le million (avec une moyenne de 700 000 depuis l’introduction de Git), alors que le nombre de lignes supprimées reste stable par rapport aux versions précédentes, soit environ 280 000 lignes (avec une moyenne de 300 000 depuis l’introduction de Git).

Cette fois, il faut remonter au noyau 2.6.28 pour espérer avoir une aussi grande variation du nombre de lignes de code. Ce dernier oscille généralement entre 200 000 et 300 000, alors que nous sommes ici à presque 800 000 lignes (moyenne de 230 000).

Evolution des insertions et suppression dans le noyau depuis le 3.0

Bref, une nouvelle version riche de code, et un doublement du nombre de lignes depuis le 25 décembre 2008, où, pour la première fois, le noyau dépassa les 10 millions de lignes de code.

Si vous êtes intéressé par les chiffres bruts, mais bien mis en forme, Thorsten Leemhuis les a compilés dans un beau classeur à découvrir.

Evolution du nombre de ligne dans le noyau

Appel à volontaires

Cette dépêche a nécessité plus de 780 éditions (à l’heure de l’écriture de ces statistiques), et mobilisé 22 personnes du 21 juillet au 16 septembre 2015 dans l’espace de rédaction.

Répartition des éditions de cette dépêche

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

Mainteneur Contributeur(s)
La phase de test Aucun Robin
Architecture Romain Perier
Développeurs Aucun
Pilotes graphiques libres Martin Peres
Réseau Aucun Florent Fourcot
Systèmes de fichiers Aucun BRULE Herman
Sécurité Timothée Ravier
Virtualisation Xavier Claude
Édition générale Aucun eggman, jcr83, M5oul

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, sans 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 et de volontaires.

Nous sommes particulièrement à la recherche de mainteneurs pour les sections Systèmes de fichiers et Réseau, les précédents n’ayant pas donné de signes de vie pendant la rédaction des dernières dépêches.

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 commits 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 !
C’est un travail à faire au fil du temps, par ajouts successifs (une simple adresse URL ou un § enrichissent déjà le contenu et les sources), n’hésitez-pas !

Aller plus loin

  • # Cache IPv6

    Posté par  (site web personnel) . Évalué à 7.

    Le cache IPv6 est bien différent de l'ancien cache IPv4. La table de routage IPv6 a toujours été organisée sous forme de FIB tree (alors que ce n'était pas le cas en IPv4 par défaut et donc le cache était à part) et le cache se trouvait alors sous forme d'entrées dans cet arbre.

  • # Adieu ext3

    Posté par  . Évalué à 6.

    Une pensée pour ext3 qui m'aura suivi toute ma vie de barbu durant, ou presque.

    De belles améliorations pour le pilote AMD libre, ça fait rêver même si je n'en ai pas l'utilité, on attend toujours qu'nVidia se bouge de ce côté…

    Merci pour cette dépêche.

    La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

  • # Suppression

    Posté par  . Évalué à 10.

    Ext4 est rétro-compatible avec ext3 et ext2, donc cette suppression est sans conséquences. C'est le mainteneur de ext3 qui a poussé les patchs. Le mainteneur de ext4 a déjà donné son accord.

    Mais du coup, est-ce que le ramasse-miettes va supprimer le mainteneur ?

  • # Ma pourquoi tant de zut pour FUSE.

    Posté par  . Évalué à 9.

    Linus Torvalds a également fait remarquer que FUSE est un jouet destiné aux gens égarés.

    Quelles sont les alternatives pour une interface que j'utilise tous les jours ?

    Signé : un gent en cours d'égarement.

    • [^] # Re: Ma pourquoi tant de zut pour FUSE.

      Posté par  . Évalué à 5.

      Chuuut une certaine personne va t'entendre et va intégrer ça dans systemd…

      • [^] # Re: Ma pourquoi tant de zut pour FUSE.

        Posté par  . Évalué à 1.

        Chuuut une certaine personne va t'entendre et va intégrer ça dans systemd…

        L'automount de systemd fonctionne déjà très bien avec FUSE.

        % tail -1 /etc/fstab
        xxx@mon.serveur.local:/home/logindistant /home/loginlocal/mnt/monserveur fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,transform_symlinks,identityfile=/home/loginlocal/.ssh/id_rsa,uid=1000,gid=1000,allow_other,reconnect 0 0

    • [^] # Re: Ma pourquoi tant de zut pour FUSE.

      Posté par  (site web personnel) . Évalué à 4.

      Je regardais wikipedia, ça fait beaucoup de jouets : https://en.wikipedia.org/wiki/Filesystem_in_Userspace#Example_uses !

      • [^] # Re: Ma pourquoi tant de zut pour FUSE.

        Posté par  . Évalué à 1. Dernière modification le 17 septembre 2015 à 23:55.

        Justement, la liste comporte un beau mélange de jouets et de gens égarés (avec aussi quelques trucs utiles j'en conviens, mais ça m'intéresse pas car on est trolldi).

        Juste trois exemples:

        Jouet:

        Wuala: A multi-platform, Java-based fully OS integrated distributed file system.

        Gens égarés:

        google-drive-ocamlfuse: FUSE filesystem over Google Drive

        La combo: jouet carrément plein de fun pour gens égarés:

        PNGDrive: A FUSE filesystem that claims to secretly store your files within images.

      • [^] # Re: Ma pourquoi tant de zut pour FUSE.

        Posté par  . Évalué à 3.

        Et aussi ntfs (version 3g je crois) non cité entre autres.

        • [^] # Re: Ma pourquoi tant de zut pour FUSE.

          Posté par  . Évalué à 8.

          J'aimerais bien savoir qui se contente du pilote ntfs du noyau plutôt que de ntfs-3g via FUSE…

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Ma pourquoi tant de zut pour FUSE.

            Posté par  . Évalué à -4.

            Utiliser NFS sous Linux, c'est quand même le signe qu'on fait partie des gens égarés. Je continue de souscrire au propos de Linus. (et d'utiliser ntfs-3g via fuse, tout égaré que je suis).

            • [^] # Re: Ma pourquoi tant de zut pour FUSE.

              Posté par  . Évalué à 7.

              Bof, déjà je vois pas le rapport avec NFS, qui est très bien.

              D'autre part, si je veux un système de fichiers un minimum moderne (qui prend largement moins de place que la FAT32, a un journal, des ACLs, possibilité de chiffrer/compresser le contenu, etc…) et compris par à peu près tout le monde (Windows, Linux, MacOS, FreeBSD, …) y'a pas grand choix à part NTFS…

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Ma pourquoi tant de zut pour FUSE.

        Posté par  . Évalué à 7.

        Je n'ai pas lu le mail de Linus (et je ne suis pas sûr de pouvoir en distinguer la nuance), je ne sais pas si c'est FUSE qui est un jouet ou si c'est les usages de FUSE qui sont des jouet. Si c'est le premier cas je me déclare tout à fait incompétent pour le savoir. Pour le second, c'est faux[1], le fait de supporter des systèmes de fichier tel que NTFS via FUSE est de base un usage intéressant, mais il y a aussi tous les cas de système de fichiers qui ne peuvent que difficilement intégré le noyau :

        • des systèmes de fichier pour solution « [One|Google]Drive », Hubic, etc
        • des systèmes de fichier conçus comme interface utilisateur : le noyau utilise /proc et /sys pour ça, mais on peut très bien imaginer une application utilisateur qui le fasse. C'est par exemple le cas de WMII qui peut se manipuler via un FS utilisateur issu de Plan9

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

  • # Radeon versus commerce

    Posté par  . Évalué à 2.

    J'espère que les puces Radeon pas si vieilles que ça ou même plus vieilles continueront à être supportées pendant, heu, vingt ans.

    Il ne faudra pas se faire piéger par AMD qui risque de pratiquer l'obsolescence pour inciter à l'achat de son nouveau matériel. Les développeurs devront veiller à la compatibilité sinon on dégaine les rapports de bogues ;).

    • [^] # Re: Radeon versus commerce

      Posté par  . Évalué à 1. Dernière modification le 17 septembre 2015 à 09:17.

      Fedora lit Linuxfr, heu, là j'utilise la machine à remonter le temps sur 4h.

      Ils recherchent ceux qui utilisent des CPU (pas des GPU) 32 bits AMD. C'est sur Phoronix.

    • [^] # Re: Radeon versus commerce

      Posté par  . Évalué à 4.

      Et encore faut-il pouvoir : les gens qui en ont sur laptop…c'est déjà plus compliqué de changer juste la carte ;)

    • [^] # Commentaire supprimé

      Posté par  . Évalué à -10.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Radeon versus commerce

        Posté par  . Évalué à 10.

        Euh c'est archi faux.

        Premièrement qu'est ce que AMDGPU ? (ils auraient pû trouver un nom plus bullshité)

        AMDGPU (le driver pas le backend llvm) est un tout nouveau driver écrit from scratch par les devs amd pour Linux et ne sera que en espace kernel (donc si j'ai bien compris il gérera le hardware et l'accélération 2d mais pas les apis 3d qui elles devront être couplé avec mesa ou catalyst userspace)
        Il a pour but de 1 essayer une nouvelle architecture de driver moderne et essayer d'autres paradigmes (Je ne m'y connais pas assez pour affirmer ces propos) mais il a aussi pour but de fusionner les bons côtés du pilote radeon et de catalyst ainsi que de fusionner les devs afin de doubler la vitesse de développement!
        Ainsi selon les dires d'amd (contrairement à tes propos blasé) les futures carte amd seront pleinement supporté avant leur sortie commerciale!
        Cela va sûrement permettre une fois le driver stabilisé de permettre à Linux d'avoir de meilleures performances gpu amd que Windows ! J'attends avec impatience de voir si c'est vrai.
        Sinon vivement Vulkan qui va révolutionner le jeu sur Linux ainsi que grandement faciliter le développement de drivers gpu.

        Sinon vous savez s'il est prévu d'implémenter l'atomic mode setting dans les pilotes amd ?
        Ah et achetez des cartes amd au lieu de nvidia car nvidia ne supporte pas direct x 12 et Vulkan au niveau hardware.
        M'enfin moi mon choix est surtout éthique.
        Moinssez moi comme à votre habitude :D

        • [^] # Re: Radeon versus commerce

          Posté par  . Évalué à 7.

          Moinssez moi comme à votre habitude :D

          ok ! \o_

          Mais c'est dommage, parce que c'était plutôt bon comme commentaire. :/

          *splash!*

          • [^] # Re: Radeon versus commerce

            Posté par  . Évalué à -9.

            Merci haha, si j'ai dis ça c'est parce que je trouve les lecteurs de Linuxfr un poil trop sévère (et c'est un euphémisme), j'ai été banni de la rédaction de journaux alors que mes journaux avaient un bon et intéressant fond, d'autant plus qu'ils sont bien souvent très proche de l'actualité étant donné que je lis les news en anglais en real time via atom feed.
            Le problème est que mes journaux avaient une forme "bâclé" , des fautes d'orthographe (normal j'écris sur un Android avec un clavier minuscule, je n'ai pas de PC)
            Et j'ai très peu de temps libre alors je fais des bookmarks et je lance parfois une question mais je m'arrête la, je ne représente pas ce que les médias des liens de mes bookmarks ont déjà fait et sûrement mieux que je ne le ferai jamais.
            Mais que voulez vous c'est l'esprit de Linuxfr, vous donnez je trouve beaucoup trop d'importance à la forme. Ça donne une atmosphère froide, pas très humaine.
            Mais derrières ces exigences futiles ça troll sur systemd et ça cherche à avoir toujours raison même quand l'on sait que l'on a pertinemment tord. Ah ego quand tu nous tiens…
            Ça me surprend beaucoup de voir de tels réactions sur un site dédié au libre et donc normalement (du moins je pensais) à des gens ouvert, qui sont passionné et qui ont de l'éthique.
            Bref je trouve ça triste, je suis sûr d'être loin d'être le seul à penser ça.
            Ça serai sympa d'avoir une seconde chance pour les journaux mais ça aussi sur linuxfr ont dirai que ce principe est inconnue alors banni j'étais, je suis et je resterai.
            Mais malgré tout je vous aime et je suis heureux de m'instruire sur vos journaux et dépêches aseptisées sans fautes et sans émotions, un peu à la Wikipedia.
            Je vous souhaite une heureuse et absurde vie :) et qui sait ? Peu être qu'un jour vous changerez ou alors je deviendrai comme vous des libristes aseptisé allergiques aux fautes d'orthographe et aux bookmarks pourtant instructifs.

            • [^] # Re: Radeon versus commerce

              Posté par  . Évalué à 0.

              Ouais enfin en même temps ton commentaire répondait à un troll qui répondait à un troll encore plus poilu que lui donc bon :/

              *splash!*

            • [^] # Re: Radeon versus commerce

              Posté par  . Évalué à 5. Dernière modification le 17 septembre 2015 à 23:05.

              En même temps venir sur Linuxfr pour parler de Linux nan mais quelle idée pas étonnant que tu te fasses moinsser O_o

              Si tu veux être sûr d'être vraiment pertinent il faut parler de cuisine, ou bien de sujets politiques de fond comme la densité capillaire, la pullulation préoccupante des monotrèmes ou la probabilité de survie des tomates en milieu routier.

              *splash!*

            • [^] # Re: Radeon versus commerce

              Posté par  (site web personnel) . Évalué à 9.

              Cf https://linuxfr.org/aide#aide-karma pour l'aide sur le système de karma

              Ton compte était associé à quatre entrées de forums notées très légèrement positivement par les visiteurs. Ensuite il y a eu trois journaux notés très négativement, d'où une baisse de karma, qui est devenu négatif, ce qui entraîne des restrictions. Et pour remonter son karma il y a deux voies, la méthode progressive en ayant des contenus et commentaires notés positivement, et la méthode rapide en ayant une dépêche publiée. Tes trois derniers commentaires bien notés vont aider pour la méthode progressive.

            • [^] # Re: Radeon versus commerce

              Posté par  (site web personnel) . Évalué à 1.

              J'ai vraiment hésité entre moinsser et plusser ton commentaire et, en fait, j'aurais bien aimé faire les deux. Évidemment j'aurais pu ne rien faire pour un résultat similaire, mais, sur le Web chacun sait combien il est vital de donner son avis. Du coup j'ai moinssé, bien sûr.

        • [^] # Re: Radeon versus commerce

          Posté par  . Évalué à 0. Dernière modification le 22 septembre 2015 à 14:23.

          il a aussi pour but de fusionner les bons côtés du pilote radeon et de catalyst ainsi que de fusionner les devs afin de doubler la vitesse de développement!

          Pas d'après ce que j'ai compris.

          Il s'agit d'exposer en frontal une API commune au pilote propriétaire et au pilote libre, et c'est tout. Derrière, l'équipe qui développe les pilotes propriétaires continuera de le faire comme maintenant, et l'équipe qui développe les pilotes libres également. Je ne vois pas en quoi ils vont interagir plus que maintenant. Le backend (désolé je ne connais pas d'équivalent en français) restera à la charge de chaque équipe respective.

          Ou alors il y a quelque chose que je n'ai pas compris et je veux bien qu'on m'explique :)

          • [^] # Re: Radeon versus commerce

            Posté par  (site web personnel) . Évalué à 8. Dernière modification le 22 septembre 2015 à 15:13.

            La partie noyau sera écrite qu'une seule fois.

            Quant au merge des équipes, le pilote Vulkan sera développé en Open Source (pas initialement, mais presque). Du coup, il restera que OpenGL et quelques petites extensions proprios. Tout le reste sera libre bientôt! Source: Slide 4 de http://www.x.org/wiki/Events/XDC2015/Program/deucher_zhou_amdgpu.pdf

            J'en ai parlé avec Alex Deucher, et il a confirmé que les gens de Catalysts se mettaient au dev Open Source :)

            • [^] # Re: Radeon versus commerce

              Posté par  . Évalué à 2.

              Wow ! Alors ça c'est du lourd !

              Si je comprends bien, AMD est en train de migrer toute son architecture en open source ?? (disons le plus possible) Ils confirment donc l'expérience open source en la généralisant ! C'est tout bonnement splendide. Je me souviens avant 2009, on rêvait sans y croire un instant à des pilotes graphiques libres. Aujourd'hui on est en plein dedans.

              Maintenant qu'AMD va allouer davantage de ressources à l'open source, les changements vont être encore plus rapides ! J'ai tellement hâte de voir ce que ça va donner dans les prochains mois !

              • [^] # Commentaire supprimé

                Posté par  . Évalué à -10.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: Radeon versus commerce

                  Posté par  . Évalué à 3.

                  Le desktop on s'en fiche : on a déjà tout le reste : les serveurs Web, le cloud, l'embarqué, les équipements réseau, les téléphones, les tablettes, les montres, … ;-)

                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à -10.

                    Ce commentaire a été supprimé par l’équipe de modération.

                    • [^] # Re: Radeon versus commerce

                      Posté par  . Évalué à 2.

                      Merci de confirmer que linux c pas fait pour le desktop

                      Je n'ai rien dit de tel. Juste que le desktop n'est plus aussi important qu'il l'était dans les années 90.

                      boites noires qu'on a surtout pas le droit de toucher…

                      Je vois pas ce qui t'empêche de hacker des équipements, de l'embarqué, ou ton téléphone Android…

                      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                      • [^] # Commentaire supprimé

                        Posté par  . Évalué à -10.

                        Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: Radeon versus commerce

                  Posté par  . Évalué à -2.

                  Tu dis ça en rigolant mais je le pense vraiment pour plusieurs raisons,
                  Primo les drivers graphiques deviennent enfin aussi puissant et complet que leurs équivalent Windows.
                  Ensuite Vulkan va vaincre direct x 12.
                  Ensuite steam machines plus arrivée massive de vrai jeux sur Android (don't starve, lifeisstrange, spelunky, etc)
                  Ensuite chrome OS qui devient conséquent.
                  Plus critique massive de windaube 10 pour ses spyware intégré (c'était déjà le cas pour les autres windaube mais bon les médias se réveillent…) et une certaine lassitude générale du manque d'innovation des OS windaube. Ah et j'oubliais ! Windows 10 à désormais des pubs intégré à son menu démarrer !!! (en plus d'y en avoir dans le démineur)

                  Et les interfaces graphiques Linux commencent à avoir une longueur d'avance énorme sur Windows.
                  Enfin les ordinateurs chinois vont être massivement vendu avec ubuntu kilyn os pré-installé grâce au gouvernement.
                  Les hardcore gamers vont installer steam OS en dual boot sur le pc.
                  Si c'est pas en 2016, en tout cas je suis sur d'une chose c'est pour bientôt ;)

              • [^] # Re: Radeon versus commerce

                Posté par  (site web personnel) . Évalué à 3.

                Yep, c'est ce que j'ai compris de nos discussions :)

  • # pilote AMDGPU pour quels GPU?

    Posté par  (site web personnel) . Évalué à 6.

    Tout d'abord merci pour la dépêche.

    Il est indiqué que le pilote AMDGPU concerne les « cartes à base de GPU AMD CI+ ».
    À quelle architecture cela correspond-il dans cette liste http://www.x.org/wiki/RadeonFeature/#index5h2 ?
    Southern Islands, Sea Islands, Volcanic Islands ?

  • # Très bon travail :)

    Posté par  . Évalué à 1.

    Cependant une phrase qui me semble un peu tordue:

    Enfin, un paquet peut connaître de la perte naturelle de paquet sans pour autant être congestionné.

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

  • # « Espérons que Linux 4.3 sortira cette limitation. »

    Posté par  (Mastodon) . Évalué à 3.

    « Espérons que Linux 4.3 sortira cette limitation. »
    Tournure maladroite, je propose « Espérons que Linux 4.3 éliminera cette limitation. »

    Merci pour l'énorme travail effectué.

  • # participation en rédaction

    Posté par  (site web personnel) . Évalué à 6.

    Il semble que certains des commentaires ci-dessus viennent de gens de bonne foi, qui auraient pu participer en rédaction au préalable : la dépêche a été initiée dès la RC-1.

    Je m'adresse aux rédacteurs : comment faire venir des gens compétents (par mail, par irc, par xmpp ? IRL ?).
    Cette dépêche est sortie, tardivement il est vrai, pour autant beaucoup de monde s'est mobilisé (et Mupuf< est resté présent pour y contribuer largement ! mici _o/).

    Pour autant, quid de la reprise ? La 4.3 est déjà en route : en rédaction et elle sera publiée.

    Quid de l'implication ? Vous pouvez participer à la tribune, participer à la traduction, relire, ajouter des sujets qui vous tiennent à cœur : autant l'ajouter à l'article que simplement en tribune ? (appel à motivés)

    Notre coordination passe par la tribune de rédaction, est capitalisée sur le wiki : rediger-des-depeches-noyau et traductions-classiques et au final, c'est l'article qui est publié (les voyeurs peuvent le regarder en avance, ce serait mieux d'y contribuer si vous y voyez des choses à ajouter !).

    Il me semble que peu de monde comprend que LinuxFr.org est créé par ses membres, que les commentaires ne sont qu'un sous-ensemble (créant l'ambiance, il faut croire) vu que c'est participer-a-linuxfr qui propose un mode de fonctionnement enrichi^W limité par le manque d'échanges (en élaboration, seuls Oumph< et un contributeur externe ont compris la démarche ?).

    D'autres auraient tant à dire, participer, résumer, évoquer des sujets connexes. Cela ne me déprime pas, je reconnais nos limitations en tant qu'équipe (et les miennes). D'ailleurs, quand puis-je récupérer mes droits d'édition des commentaires ? (pour l'ortho principalement comme je l'ai toujours dit, même si à côté j'ai traité d'autres sujets).

    • [^] # Re: participation en rédaction

      Posté par  . Évalué à 6.

      Personnellement je pense pouvoir aider pour la pile graphique et pour les systèmes de fichiers.
      Sinon j'adorerais voir le changelog de la pile audio sur Linuxfr, ou puis-je le trouver de manière digeste en anglais ?

      • [^] # Re: participation en rédaction

        Posté par  . Évalué à 1.

        Comme amorce, tu peux rechercher ce qui concerne alsa dans le noyau. Regarde dans les sources.

      • [^] # Re: participation en rédaction

        Posté par  (site web personnel) . Évalué à 5.

        Cool! Tu te mets en mainteneur de système de fichiers? Et pourquoi pas aussi bosser sur la partie audio (ça doit pas être trop dur vu le peu de changements)?

        • [^] # Re: participation en rédaction

          Posté par  . Évalué à -4.

          Je suis infiniment désolé pour le retard Martin peres, j'avais cassé l'écran de mon smartphone le rendant inaccessible et je n'ai pas de PC par conséquent je ne pouvais te répondre :(
          J'ai enfin réparé mon oneplus donc je suis enfin de nouveau disponible.
          Pour le 4.3 je vais pas trop avoir le temps mais pour le 4.4 je veux bien être mainteneur de systèmes de fichiers et m'occuper de la pile son :)
          Mais mon niveau d'anglais est relativement médiocre donc mes traductions seront imparfaite, aussi je connais relativement mal le système d'édition de linuxfr.org.

          • [^] # Re: participation en rédaction

            Posté par  (site web personnel) . Évalué à 4.

            Pour le 4.3 je vais pas trop avoir le temps mais pour le 4.4 je veux bien être mainteneur de systèmes de fichiers et m'occuper de la pile son :)

            bah, tu peux t'inscrire tout de même pour https://linuxfr.org/redaction/news/sortie-du-noyau-linux-4-3 et faire ce que tu peux

            Mais mon niveau d'anglais est relativement médiocre donc mes traductions seront imparfaite, aussi je connais relativement mal le système d'édition de linuxfr.org.

            tu peux copier/coller les paragraphes en anglais, parfois il y aura des traducteurs bienveillants passant par là, sinon c'est à toi de le faire (et il y aura des correcteurs pour compléter / corriger). C'est très interactif : apporter le contenu c'est 50% du boulot, le rendre compréhensible et synthétiser 40%, reste les 10% de mise en forme (ce que je puis faire et que d'autres font aussi).

            Tu peux regarder rédaction et traductions-classiques pour t'aider.

    • [^] # Re: participation en rédaction

      Posté par  . Évalué à 5.

      Histoire de donner mes deux centimes d'euro, il m'est arrivé quelques fois d'aller voir—par curiosité, certes—l'interface de rédaction des dépêches, et à chaque fois l'ergonomie du truc m'a fait fuir. Il y aurait quand même mieux que ce bidule improbable venu des années 90 avec un gros bouton modifier en-dessous de chaque paragraphe (qui rend par ailleurs la lecture très pénible)…

      • [^] # Re: participation en rédaction

        Posté par  . Évalué à 4.

        Depuis que je contribue (deux ans) je n’ai jamais vu de bouton «modifier» en-dessous des paragraphes, donc ça doit faire longtemps. L’interface est pas extraordinaire mais elle fonctionne bien.

        Que reproches-tu en particulier à cette interface? Note également que des améliorations peuvent être suggérées, ou des problèmes rapportés, en utilisant l’outil de suivi du site (mais je comprends que tu n’ait pas pris le temps de le faire si l’interface t’as fait fuir dès le premier contact).

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

  • # Roadmap AMDGPU

    Posté par  . Évalué à 10.

    Salut salut ! Comme je suis banni de l'édition de journaux, je le dis ici.

    AMD vient d'annoncer (via des slides pdf) plusieurs nouvelles qui font rêver !

    AMD a profité de la XDC 2015 à Toronto pour annoncer sa future roadmap AMDGPU, amd à notamment annoncé que son l'implémentation propriétaire d'openCL 2.1 va devenir open source ! Ce qui va révolutionner le support et les performances d'openCL pour les libristes.

    AMD a aussi annoncé qu'ils vont bientôt lancer un driver prototype pour Vulkan !!
    Il sera au début propriétaire mais il est déjà annoncé qu'il basculera en open source dans pas trop longtemps, cela signifiera que l'on pourra enfin avoir des drivers amd entièrement libre avec de très bonnes performances.

    Il est aussi annoncé que la gestion de l'énergie sera implémenté bientôt en transférant celle de catalyst dans AMDGPU (cela va enfin rendre ce pilote pleinement utilisable).
    Les addons firepro vont aussi devenir opensource mais cela avait déjà été annoncé par le passé
    Le pilote Vulkan sera basé sur dri3.
    Et il y a aussi d'autres news comme les interops ou encore le DAL : "Display DAL ‒AMD display team contributing directly to amdgpu ‒More features than current code ‒Initial support for DCE11" mais je n'ai pas vraiment compris ce que c'est.
    Le lien phoronix.com : http://www.phoronix.com/scan.php?page=article&item=amd-gpu-xdc15&num=1
    Les slides pdf : http://www.x.org/wiki/Events/XDC2015/Program/deucher_zhou_amdgpu.pdf

Suivre le flux des commentaires

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