Sortie du noyau Linux 4.10

La sortie de la version stable 4.10 du noyau Linux a été annoncée le 19 février 2017 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org.

Sommaire

Annonces des versions candidates par Linus Torvalds

RC1

La version RC1 est sortie le samedi 25 décembre 2016 :

C’est Noël et deux semaines se sont écoulées depuis l’ouverture de la fenêtre de fusion. Celle-ci est donc maintenant fermée.

J’ai accepté quelques demandes d’intégration aujourd’hui, mais j’en ai également rejeté quelques-unes qui sont arrivées en retard et qui paraissaient douteuses. L’auteur se reconnaîtra.

Dans l’ensemble, ce n’était pas du tout une grosse évolution — rien à voir avec la 4.9. Cependant, elle n’était pas négligeable non plus. Je pense que la 4.7 était plus petite. La 4.8 aurait pu l’être aussi. C’est le jour de Noël et en ce moment, j’ai la flemme de calculer les statistiques comme je le fais habituellement.

Tout semble assez normal, même si nous avons eu une quantité inhabituelle de nettoyages ultimes dans toute l’arborescence sur les derniers jours de la fenêtre de fusion. Mais les statistiques générales semblent assez habituelles : un peu plus de la moitié concerne des pilotes. Il y a peut-être un peu moins de mises à jour d’architecture que d’habitude et un bon nombre de mises à jour de documentation, en raison de la conversion vers sphinx. Et puis il y a les diverses corrections habituelles un peu partout, bien que les mises à jour des outils de performances se démarquent.

Le journal abrégé est beaucoup trop grand, comme c’est toujours le cas lors de la fenêtre de fusion, donc comme d’habitude dans ces cas-là, vous aurez juste le journal de fusion.

Linus

RC2

La version RC-2 est sortie le dimanche 1er janvier 2017 :

Hé, ça a été une semaine vraiment lente entre le jour de Noël et le jour du nouvel an et je ne m’en plains pas du tout.

Cela signifie que RC2 est ridiculement et bizarrement petite. J’ai failli décider de la zapper entièrement, mais une petite RC sans importance de temps en temps ne fait de mal à personne. Donc, voilà.

Le seul travail remarquable ici est la correction DAX. Il aurait vraiment dû se trouver dans la fenêtre de fusion, mais dépendait de plusieurs choses de cette fenêtre de fusion et a été retardée jusqu’à RC2 pour cette raison. Même ça n’était pas très important et le reste est constitué de petites corrections insignifiantes.

Je m’attends à ce que les choses recommencent la semaine prochaine quand les gens se remettront des vacances.

Linus

RC3

La version RC3 est sortie le dimanche 8 janvier 2017 :

Donc après une très petite RC2 en raison de la petite pause de Noël, nous semblons être de retour à la normale. Après une période de calme comme ça, j’ai tendance à m’attendre à un gros morceau juste à cause du travail suspendu, mais je suppose que pendant la courte pause, il y avait vraiment des vacances pour tout le monde, et donc au lieu de cela on observe juste un modèle habituel de RC. Elle est toujours un peu plus petite qu’une RC3 typique, mais pour la première vraie RC après la fenêtre de fusion (c’est-à-dire que je la compare à une RC2 régulière), c’est assez normal.

Les stats semblent normales pour le noyau : un peu moins de ⅔ de pilotes, avec presque la moitié restante de mises à jour d’architecture, le reste étant « divers » (principalement des systèmes de fichiers et du réseau).

Donc, rien de particulier ne sort du lot. Vous pouvez vous faire une idée des détails grâce au journal abrégé ci-joint, mais plus important encore — vous pouvez y aller et tester.

Merci,

Linus

RC4

La version RC-4 est sortie le dimanche 15 janvier 2017 :

Tout semble plutôt normal, et c’est donc une sortie dominicale comme d’habitude. Nous en sommes à la RC4, et il est clair qu’on a commencé à trouver des régressions. C’est parfait.

C’est un ensemble de corrections légèrement plus hétérogène que la semaine dernière : la plus grande partie concerne les pilotes (GPU, réseau, son, USB se démarquent), mais il y a aussi les changements habituels d’architectures (principalement x86 cette fois-ci) et un nombre important de corrections des systèmes de fichiers (XFS, BTRFS, certains pour le cœur de VFS), les outils (surtout perf), la gestion de la mémoire, le réseau, etc.

C’est le moment où je commence à espérer que la taille des RC va commencer à diminuer. On verra comment la petite taille de la RC2 va se répercuter sur la suite — techniquement, nous en sommes à la RC4, mais avec une semaine presque perdue, cela ressemble plutôt à une RC3. Mais je croise les doigts pour que nous ayons moins de changements la semaine prochaine.

De toutes façons, allez-y et testez-la. Ce n’était pas une énorme fenêtre de fusion ; je pense qu’elle est en assez bon état pour qu’on se jette à l’eau.

Linus

RC5

La version RC-5 est sortie le dimanche 22 janvier 2017 :

Les choses semblent se calmer un peu et tout semble en règle.

Il n’y a eu que 250 modifications (sans compter les fusions) au cours de la dernière semaine et les statistiques concernent moins de 300 fichiers (les pilotes et les mises à jour d’architecture étant en majorité, mais il y a également des mises à jour d’outils, de gestion des réseaux et de systèmes de fichiers).

Donc, continuez à tester et je pense que nous aurons un calendrier de sortie habituel.

Linus

RC6

La version RC-6 est sortie le dimanche 29 janvier 2017 :

Cette semaine semble avoir été vraiment calme. La RC6 semblait partie pour être une jolie petite version. Pile comme je le veux.

… puis vendredi est arrivé et la petite et tranquille release candidate a quelque peu explosé au point de ne pas être si petite après tout.

Tant pis. Ce n’est pas comme si c’était un nouveau procédé — les gens finissent par m’envoyer leur travail de la semaine le vendredi et cela se passe depuis quelques années maintenant, je l’ai déjà signalé. C’était juste encore plus remarquable que d’habitude.

Et ce lot tardif de demandes d’inclusions arrivé vendredi (avec quelques-unes ce week-end) a fait de la RC6 la plus grosse RC de ce cycle de publications jusqu’à présent (c’est évidemment sans compter la RC1).

Ce n’est cependant pas si gros que ça, puisque 4.10 a été jusque-là globalement assez calme, mais c’est un peu pénible. J’espérais passer au calendrier habituel « la RC7 est la dernière RC » pour une fois (malgré les 4.8 et 4.9 tendant vers une RC8) et je veux vraiment que les choses se calment pour que cela se produise.

Nous verrons.

Quoi qu’il en soit, il n’y a rien qui m’inquiète particulièrement dans RC6 en dehors du manque de ralentissement, et que c’est peut-être juste le timing (c’est-à-dire que tout le monde n’envoie pas ses mises à jour à chaque RC, donc parfois ça s’accumule). Donc je ne renonce pas à rêver que « la RC7 soit la dernière RC ».

Les changements touchent principalement les pilotes (le GPU et le réseau se démarquent, mais rdma, média et MD sont assez remarquables également), le reste se composant principalement des mises à jour réseau génériques et XFS, avec le lot habituel de divers correctifs épars.

Allez tester,

Linus

RC7

La version RC-7 est sortie le dimanche 5 février 2017 :

Hé, regardez ça – tout a été très calme et à moins qu’un problème n’arrive, nous sommes de retour au calendrier habituel selon lequel c’est la dernière RC.

Bien sûr, en regardant réellement mon calendrier, j’ai remarqué que si ça se déroule comme cela, la prochaine fenêtre de fusion sera gênante pour moi à cause de mon voyage et donc il s’avère que je n’aurais pas dû espérer que les choses se calment. Mais j’ai déjà fait des fenêtres de fusions durant un voyage auparavant, donc cela ne va pas être nécessairement un gros problème.

Et de toute façon, n’importe quoi peut arriver pendant la semaine prochaine.

Quoi qu’il en soit, la RC7 est assez petite, la moitié en corrections au niveau des drivers (réseaux, GPU et HID comptant pour la majorité), 20 % de mise à jour d’architectures (X86, Sparc PowerPC, un peu de crypto Arm64) et le reste est du « divers » : système de fichiers, réseau général, VM, script Genksyms, etc.

L’ensemble est relativement petit, et rien de particulier ne sort du lot (à part un rappel supplémentaire de mon aversion pour modversions — nous avons corrigé un autre bug aléatoire déclenché par un outil spécifique à une architecture en particulier). Le journal de fusion abrégé est annexé pour les personnes qui veulent une vue d’ensemble du détail des modifications.

Linus

RC8

La version RC-8 est sortie le dimanche 12 février 2017 :

Hé, c’est une nouvelle semaine et j’aurais pu sortir la version 4.10.

Elle n’a pas été si chargée que ça, bien que nous ayons eu un certain nombre de petites corrections de régressions de dernière minute (certaines ne faisant qu’annuler des choses qui posaient problème et demandaient un peu plus de réflexion, d’autres les corrigeant). Mais rien qui sorte de l’ordinaire et je n’aurais eu aucune gêne à sortir la version finale aujourd’hui.

Mais j’ai décidé qu’il n’y avait pas non plus d’énormes raisons impérieuses de le faire (autre que de revenir au calendrier habituel « la RC7 est la dernière RC », ce qui aurait été appréciable) et avec les voyages à venir, j’ai décidé que je ne devais pas forcément ouvrir la fenêtre de fusion. J’ai déjà géré des fenêtres de fusion pendant des voyages, mais je préfère l’éviter. Si nous en étions à la deuxième semaine de la fenêtre de fusion, lorsque la plus grande partie a été fusionnée, ce serait une chose, mais ce n’est pas comme cela que ça se présente.

Évidemment, tous les développeurs qui sont déjà prêts pour la fenêtre de fusion (et oui, vous devriez, n’est-ce pas ?) et qui savent que tu seras occupé la semaine suivante [NDT: oui, la rupture de syntaxe se trouve aussi dans l’original], vous êtes plus que bienvenus pour envoyer vos demandes d’intégration tôt. Je vais les garder dans un coin, rien à craindre.

Et si ce n’est pas le cas, vous avez maintenant une semaine supplémentaire pour peaufiner votre travail 😉

Le journal de fusion abrégé est annexé, mais tout semble plutôt normal : pratiquement la moitié du patch est constitué de pilotes, un tiers du reste étant des mises à jour d’architectures (arm, powerpc et x86). Le restant concerne surtout le réseau et quelques mises à jour de systèmes de fichiers, avec un petit nombre d’autres choses (documentation, outil perf, en-tête des fichiers, misc). Environ un tiers des commits sont marqués comme étant stables.

Linus

Version finale

La version 4.10 finale est sortie le dimanche 19 février 2017 :

La voilà donc, la version 4.10 définitive. C’est assez calme depuis RC8, mais nous avons bien fini par corriger plusieurs problèmes mineurs, donc cette semaine supplémentaire a été complètement bénéfique.

Globalement, la 4.10 n’a pas fini aussi petite qu’elle en avait l’air au départ. Après l’immense version qu’a été la 4.9, je m’attendais à ce que les choses soient plutôt calmes, mais cela s’est terminé en une version plutôt dans la moyenne, selon les normes des noyaux modernes. Nous avons donc environ 13 000 commits (sans compter les fusions qui représenteraient un peu plus de 1 200 commits supplémentaires, si on les prenait en compte). Le travail est terminé, évidemment. Le journal abrégé ci-dessous ne concerne que les changements de la semaine dernière, depuis RC8.

Allez-y et vérifiez que tout va bien. Et je commencerai évidemment à intégrer des soumissions pour la 4.11 dès lundi.

Linus

Améliorations apportées à cette version

AMD Ryzen

L’arrivée de cette nouvelle architecture de processeur a montré un problème dans l’affectation des fils d’exécution (threads) aux cœurs des processeurs AMD Ryzen. En effet, avant cette version, les threads des processeurs Zen disposaient chacun d’un numéro d’identification unique (cpuid_core_id) alors qu’avec la nouvelle topologie de cœur Zen, deux threads d’un même cœur doivent avoir le même numéro d’identification.
On peut supposer que cela pouvait nuire aux performances dans certains scénarios, mais rien n’a été précisé à ce sujet dans le commit. À noter que cette correction a été rétro-portée dans le noyau 4.9.10.

La prise en charge de ces processeurs a également été ajoutée au module de détection d’erreurs mémoire (EDAC). Ceci ne sera utile que sur les machines disposant de mémoire ECC, principalement les serveurs (dont la gamme AMD Ryzen n’est pas encore sur le marché).

Microsoft Surface 3

Amélioration de la prise en charge des boutons de la tablette ainsi que de la gestion du couvercle.
http://www.phoronix.com/scan.php?page=news_item&px=Surface3-Better-With-Linux-4.10

Architectures

Arm

L’architecture ARM 64 bits (ARM64/AArch64) prend en charge le bus PCI (Peripheral Component Interconnect) avec l’ACPI (Advanced Configuration and Power Interface). Cette norme a pour but de réduire la consommation d’énergie d’un périphérique. Elle est codéveloppée par Hewlett-Packard, Intel, Microsoft, Phoenix et Toshiba.
http://www.phoronix.com/scan.php?page=news_item&px=PCI-Linux-4.10

X86

L’architecture X86 reçoit de nombreuses corrections de bug et optimisations : les très anciens processeurs sans identifiant CPUID ne démarraient plus. Il y a aussi des corrections dans la mise à jour des microcodes.

Pilote audio

Une meilleure gestion de l’énergie est proposée par le DAPM.
De nouveaux pilotes pour les puces Cirrus Logic CS42L42, Qualcomm MSM8916-WCD, et Realtek RT5665.
Et aussi des correctifs pour Intel Skylake.

Pilote graphique

Nouveau (carte graphique Nvidia)

La mise à jour du pilote inclut la gestion du contrôle des LED du logo NVIDIA illuminé sur le côté de certaines cartes graphiques de la marque, la prise en charge du DisplayPort MST (Multi Stream Transports) qui permet une utilisation de plusieurs écrans via un seul câble DisplayPort à condition que votre moniteur prenne en charge la version 1.2 du DisplayPort.

Très attendue, la prise en charge du changement de la fréquence qui permet enfin de jouer à pleines performances avec les pilotes libres. En effet, beaucoup de cartes démarrent à basse vitesse, et le pilote propriétaire est chargé de faire varier la fréquence en fonction de la charge demandée, que ce soit pour la 3D ou la décompression vidéo. Ainsi il était impossible d’utiliser VDPAU pour lire une vidéo 1080p sur une 9300M, alors que ça passait en 720p. Cela reste manuel et expérimental, il y a notamment des cas où la fréquence mémoire ne change pas en même temps que le CPU. Il faut écrire le niveau de performances demandé dans /sys/kernel/debug/dri/0/pstate .

Ces grosses modifications devaient au départ arriver dans Linux 4.9 mais ont été reportées pour améliorer le code.

Lien vers l’article du site Phoronix

AmdGPU (carte graphique ATI/AMD)

Cette mise à jour introduit le support des affichages virtuels multiples et la mise à jour de la gestion de l’alimentation des cartes graphiques.
Et aussi l’accélération du GPU pour les générations plus récentes lors de l’utilisation de l’UVD.

La prise en charge des GPU Radeon RX550 (nom de code POLARIS 12) a été ajoutée.

Elle apporte aussi son lot de nettoyage de code et correction de bogues.

Lien vers l’article du site Phoronix

Outils Perf

Prise en charge des plateformes

Amélioration de la prise en charge d’Amlogic S905 et suivants

La gestion des SoCs ARM64bits d’Amlogic fait l’objet d’un gros travail depuis Linux 4.7, Linux 4.10 amène de nombreux changements :

  • prise en charge de l’USB2 pour la famille GXBB (S905) ;
  • prise en charge de la famille GXL (S905X et S905D) quasi identique au S905 ;
  • prise en charge de la famille GXM (S912) identique a la famille GXL avec 8 cœurs Cortex-A53 ;
  • gestion de l’interface Ethernet interne 100 Mbit/s des familles GXM et GXL ;
  • gestion de la sortie graphique Composite avec un pilote tout neuf DRM/KMS (Direct Rendering Manager/Kernel ModeSetting) qui utilise les derniers composants comme ‘Atomic Modesetting’, ‘GEM-CMA’, ‘FBDev-CMa’ ou encore ‘PRIME-CMA’, ceci pour les 3 familles GXBB, GXL et GXM ;
  • gestion de l’interface SDCard/SDIO/eMMC pour les 3 familles GXBB, GXL et GXM ;
  • prise en charge du WiFi via SDIO pour les 3 familles GXBB, GXL et GXM ;
  • prise en charge des cartes Nexbox A1 et A95X.

La prise en charge de l’affichage par HDMI est prévue pour une prochaine version.

Autres

  • Prise en charge des cartes Luxul XAP-1510, Luxul XWR-3100, Netgear R8500, TP-LINK Archer C9 V1 et Tenda AC9 basées sur des SoCs Broadcom ;
  • prise en charge du SoC Modem MDM9615 et la carte Sierra Wireless MangOH
    Green, le SoC MDM9515 est dans le module semi-génerique WP8548 de Sierra Wireless ;
  • prise en charge des Nexus 5X et Nexus 6P à base de SoCs Qualcomm msm8992 et msm8994 ;
  • prise en charge initiale du Motorola Droid 4 à base de SoC TI OMAP4430 ;
  • prise en charge initiale de AM571x-IDK à base de SoC TI AM5718 ;
  • prise en charge de la famille DRA71x de Texas Instruments ;
  • prise en charge du Oxford Semiconductor OX820, successeur du OX810SE, et du NAS Pogoplug V3 ;
  • prise en charge initiale du routeur Open-Source OpenHardware Tussis Omnia à base de SoC Marvell ;
  • prise en charge des cartes à base de i.MX6 : Toradex Colibri, Engicam i.CoreM6, UDOO Neo, liteBoard, liteSOM, Boundary Devices Nitrogen6_SOM2 ;
  • prise en charge des SoCs r8a7743 et r8a7745 de Renesas et des cartes SK-RZG1E et SK-RZG1M ;
  • prise en charge des cartes MK808, Rockchip PX3 Evaluation, Rockchip RK1108 Evaluation à base de SoCs Rockchip RK3066 et RK1108 ;
  • prise en charge de la carte PX5 à base de SoC Rockchip rk3188 ;
  • prise en charge de la carte Macnica sodia à base de SoCFPGA ;
  • prise en charge de la carte NanoPi M1 SBC à base de SoC AllWinner Sun8i ;
  • prise en charge de la carte Pine64 à base de SoC AllWinner A64 ;
  • prise en charge des cartes LS1046A-QDS et LS1046A-RDB à base du SoC FreeScale LayerScape LS1046A ;
  • prise en charge des cartes TM2 et TM2E à base de SoC Samsung Exynos5433 ;
  • prise en charge de la carte NVIDIA P2771 à base de SoC Tegra de NVIDIA ;
  • prise en charge de la carte MicroZed à base de SoC/FPGA Zynq-7000 ;
  • prise en charge du microcontrôleur STM32F746.

Statistiques

En nombre de patchs soumis par entreprise

Le plus grand nombre de contributions pour cette version 4.10 est d’origine non précisée (Unknown : 3103, 23,82 %). Ensuite, on trouve les sociétés Intel avec 1730 patchs (13,28 %) et Red Hat, 882 patchs (6,77 %), suivis par Samsung (3,98 %) et Novell (3,83 %). Les développeurs bénévoles sont en sixième place avec 473 patchs (3,63 %).

En nombre de patchs par nation

37 pays ont participé par leurs contributions à cette version du noyau. En première place, la Chine avec 1077 patchs (8,27 %) puis l’Allemagne, 1013 patchs (7,77 %) et les États-Unis, 735 patchs (5,64 %).

Lire les commentaires

(Source: LinuxFr.org : les dépêches)
Logo