Sommaire
Annonces des versions candidates par Linus Torvalds
RC-1
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
RC-2
La version RC-2 est sortie le dimanche 1er janvier 2017 :
Eh, ç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 la RC-2 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 dans cette fenêtre de fusion et a été retardé jusqu’à la 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
RC-3
La version RC-3 est sortie le dimanche 8 janvier 2017 :
Donc, après une très petite RC-2 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 en suspens ; 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 RC-3 typique, mais pour la première vraie RC après la fenêtre de fusion (c’est‐à‐dire que je la compare à une RC-2 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’architectures, 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 aller la tester.
Merci,
Linus
RC-4
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 RC-4 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 (pilotes graphiques, réseau, son et 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 RC-2 va se répercuter sur la suite — techniquement, nous en sommes à la RC-4, mais avec une semaine presque perdue, cela ressemble plutôt à une RC-3. Mais, je croise les doigts pour que nous ayons moins de changements la semaine prochaine.
De toute façon, allez‐y, 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
RC-5
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’architectures é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
RC-6
La version RC-6 est sortie le dimanche 29 janvier 2017 :
Cette semaine semble avoir été vraiment calme. La RC-6 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 RC-6 la plus grosse RC de ce cycle de publications jusqu’à présent (c’est évidemment sans compter la RC-1).
Ce n’est cependant pas si gros que ça, puisque la 4.10 a été jusque‐là globalement assez calme, mais c’est un peu pénible. J’espérais passer au calendrier habituel « la RC-7 est la dernière RC » pour une fois (malgré les 4.8 et 4.9 tendant vers une RC-8) 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 RC-6 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, alors parfois ça s’accumule). Donc, je ne renonce pas à rêver que « la RC-7 soit la dernière RC ».
Les changements touchent principalement les pilotes (le processeur graphique 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 le tester,
Linus
RC-7
La version RC-7 est sortie le dimanche 5 février 2017 :
Eh, 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 RC-7 est assez petite, la moitié des corrections au niveau des pilotes (réseau, pilotes graphiques et HID comptant pour la majorité), 20 % de mises à jour d’architectures (X86, SPARC, PowerPC, un peu de cryptographie ARM64) et le reste est du « divers » : systèmes de fichiers, réseau général, mémoire virtuelle, 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 bogue aléatoire déclenché par un outil spécifique à une architecture en particulier). Le journal de fusion abrégé est en annexe pour les personnes qui veulent une vue d’ensemble du détail des modifications.
Linus
RC-8
La version RC-8 est sortie le dimanche 12 février 2017 :
Eh, 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 RC-7 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 [N. D. T : 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 correctif 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êtes des fichiers et divers). Environ un tiers des commits est marqué comme étant stable.
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 la RC-8, 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 l RC-8.
Allez‐y, 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 processeurs 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 fils d’exécution 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 fils d’exécution 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 (cf. article sur Phoronix).
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 (cf. article sur Phoronix).
X86
L’architecture x86 reçoit de nombreuses corrections de bogues 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 DEL 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 à pleine puissance 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 en 1080p sur une 9300 M, 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 processeur. Il faut écrire le niveau de performance 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.
Voir l’article du site Phoronix.
AmdGPU (carte graphique ATI/AMD)
Cette mise à jour introduit la prise en charge des affichages virtuels multiples et la mise à jour de la gestion de l’alimentation des cartes graphiques.
Et aussi l’accélération du processeur graphique pour les générations plus récentes lors de l’utilisation du circuit de décodage vidéo universel UVD.
La prise en charge des processeurs graphiques Radeon RX550 (nom de code Polaris 12) a été ajoutée.
Elle apporte aussi son lot de nettoyage de code et correction de bogues.
Voir l’article du site Phoronix dédié à ce sujet.
Prise en charge des plates‐formes
Amélioration de la prise en charge d’Amlogic S905 et suivants
La gestion des systèmes monopuces ARM 64 bits 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’USB 2 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 à 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 trois familles GXBB, GXL et GXM ;
- gestion de l’interface
SDCard/SDIO/eMMC pour les trois familles GXBB, GXL et GXM ;
- prise en charge du Wi‐Fi via SDIO pour les trois 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 systèmes monopuces Broadcom ;
- prise en charge du système monopuce Modem MDM9615 et la carte Sierra Wireless MangOH Green, le système monopuce MDM9515 est dans le module semi‐génerique WP8548 de Sierra Wireless ;
- prise en charge des Nexus 5X et Nexus 6P à base de systèmes monopuces Qualcomm msm8992 et msm8994 ;
- prise en charge initiale du Motorola Droid 4 à base de système monopuce TI OMAP4430 ;
- prise en charge initiale de AM571x-IDK à base de système monopuce 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 libre OpenHardware Turris Omnia à base de système monopuce Marvell ;
- prise en charge des cartes à base d’i.MX6 : Toradex Colibri, Engicam i.CoreM6, UDOO Neo, liteBoard, liteSOM, Boundary Devices Nitrogen6_SOM2 ;
- prise en charge des systèmes monopuces 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 systèmes monopuces Rockchip RK3066 et RK1108 ;
- prise en charge de la carte PX5 à base de système monopuce Rockchip rk3188 ;
- prise en charge de la carte Macnica Sodia à base de système monopuce FPGA ;
- prise en charge de la carte NanoPi M1 SBC à base de système monopuce AllWinner Sun8i ;
- prise en charge de la carte Pine64 à base de système monopuce AllWinner A64 ;
- prise en charge des cartes LS1046A-QDS et LS1046A-RDB à base du système monopuce FreeScale LayerScape LS1046A ;
- prise en charge des cartes TM2 et TM2E à base de système monopuce Samsung Exynos 5433 ;
- prise en charge de la carte NVIDIA P2771 à base de système monopuce Tegra de NVIDIA ;
- prise en charge de la carte MicroZed à base de système monopuce/FPGA Zynq-7000 ;
- prise en charge du microcontrôleur STM32F746.
Statistiques
En nombre de correctifs soumis par entreprise
Le plus grand nombre de contributions pour cette version 4.10 est d’origine non précisée (Inconnue : 3 103, 23,82 %). Ensuite, on trouve les sociétés Intel avec 1 730 correctifs (13,28 %) et Red Hat, 882 correctifs (6,77 %), suivis par Samsung (3,98 %) et Novell (3,83 %). Les développeurs bénévoles sont en sixième place avec 473 correctifs (3,63 %).
En nombre de correctifs par nation
Trente‐sept pays ont participé par leurs contributions à cette version du noyau. En première place, la Chine avec 1 077 correctifs (8,27 %), puis l’Allemagne avec 1 013 correctifs (7,77 %) et les États‐Unis avec 735 correctifs (5,64 %).
