Retour vers le passé : de Linux 4.12 à 4.14

Cela fait quelque temps que nous n’avions pas eu de dépêche sur notre noyau préféré. Un petit retour en arrière sur les améliorations apportées par Linux 4.12, 4.13 et 4.14.

Sommaire

• Améliorations apportées
  • 4.12
    • Nouvel ordonnanceur d’entrées‐sorties : BFQ
    • Nouvel ordonnanceur d’entrées‐sorties — Le retour : Kyber
  • Systèmes de fichiers
    • 4.12
      • GETFSMAP (pour ext4 et xfs)
      • ext4
      • XFS
      • F2FS
      • NFS
      • OrangeFS
      • UBIFS
      • Btrfs
    • 4.13
      • Btrfs
    • 4.14
      • Btrfs
  • Architecture
    • 4.12
      • Allwinner
      • Rockchip
      • Amlogic
      • Samsung
      • Mediatek
      • Divers
    • 4.14
      • ARM
  • Pilotes graphiques
    • 4.12
      • AMD
    • 4.14
      • HDMI CEC sur RPI
  • Virtualisation
    • KVM
    • Xen
• Annonces des versions candidates par Linus Torvalds
  • Version 4.12
    • RC1
    • RC2
    • RC3
    • RC4
    • RC5
    • RC6
    • RC7
    • Version finale
  • Version 4.13
    • RC1
    • RC2
    • RC3
    • RC4
    • RC5
    • RC6
    • RC7
    • Version finale
  • Version 4.14
    • RC1
    • RC2
    • RC3
    • RC4
    • RC5
    • RC6
    • RC7
    • RC8
    • Version finale

Améliorations apportées

4.12

Nouvel ordonnanceur d’entrées‐sorties : BFQ

Le noyau utilise un nouvel ordonnanceur d’entrées‐sorties : Budget Fair Queueing (BFQ). Ce scheduler reçoit tous les compliments possibles. Il doit améliorer les débits, la latence pour les applications temps réel comme pour les tâches de développeurs, être très équitable entre les processus, fournir des délais de garantie… À vous d’essayer et de vous faire votre propre avis.

Pour ce qui est de son fonctionnement, BFQ crée une file par périphérique et une par processus (ou par cgroup). Il place les tâches synchrones dans les files des processus et asynchrones dans les files de périphériques (comme son prédécesseur CFQ). BFQ alloue à chaque file un budget exprimé en nombre de secteurs. Il donne la main à une seule file à la fois et lui applique ces demandes tant que :

• il lui reste du budget ;
• il reste des demandes ;
• il ne met pas trop de temps à épuiser son budget ;
• une requête est trop longue à s’exécuter.

Suite à quoi il est associé un nouveau budget à cette file et l’on choisit une nouvelle file en fonction de son budget, de son poids (qui est paramétrable) et du temps qu’elle a pu passer à consommer les entrées‐sorties.

Nouvel ordonnanceur d’entrées‐sorties — Le retour : Kyber

Kyber se veut simple et répond à une problématique toute différente de BFQ. Kyber part du principe que les entrées‐sorties sont très rapides et que le goulot d’étranglement des performances reste le processeur. Dans ce cas bien spécifique (et donc sur un type de matériel plutôt haute performance), il est plus pertinent de ne pas ordonner de manière complexe les requêtes (ce qui prend du temps processeur) et d’allouer de manière rapide les files. Le gain est donc important en termes de ressource, puisque cet ordonnanceur est très simple. Le revers de la médaille, c’est que ce type de ressource matérielle n’est pas disponible pour tous et que BFQ a encore beaucoup d’avenir.

Systèmes de fichiers

Divers systèmes de fichiers ont reçu des améliorations durant la sortie des différentes versions 4.12, 4.13 et 4.14 : GETFSMAP (pour ext4 et XFS), ext4, XFS, F2FS, NFS, OrangeFS, UBIFS, Btrfs.

4.12

GETFSMAP (pour ext4 et xfs)

GETFSMAP est un nouveau type d’« ioctl() » qui permet, via deux clés de recherche définies comme un tuple (device, bloc, propriétaire, décalage), de renvoyer toutes les informations de correspondance d’espace connues pour le système de fichiers donné [article de LWN.net].

ext4

Ajout de la prise en charge de GETFSMAP.

XFS

Ajout de la prise en charge de GETFSMAP.

F2FS

• activation par défaut d’une option favorisant la récupération de petits blocs ;
• ajout d’un iotctl pour forcer l’écriture de certains blocs ;
• ajout de statistiques supplémentaires sur les blocs. Show available_nids in f2fs/status commit

NFS

Nettoyage du pilote (suppression de fonctions non utilisées).

OrangeFS

• ajout de la prise en charge des très gros répertoires ;
• ajout de la prise en charge de llseek sur les répertoires.

UBIFS

Ajout de l’étiquette CONFIG_UBIFS_FS_SECURITY pour activer/désactiver les étiquettes de sécurité.

Btrfs

Cette version introduit des correctifs importants pour les niveaux de RAID 5 et 6 :

• activation de la réparation automatique durant la lecture (similaire à ce qui existe déjà pour RAID 1 et 1 + 0) ;
• correction d’un potentiel crash lors d’un scrub et d’un dev-replace concurrents ;
• correction d’un potentiel crash lors de l’annulation d’un dev-replace ;
• suppression de faux rapports durant le scrub quand il est possible de faire une réparation ;
• suppression de rapports miroirs erronés durant la réparation.

Toutefois, la fonctionnalité reste considérée comme instable.
Une liste des changements plus complète est disponible sur le wiki du projet Btrfs.

4.13

Btrfs

Les changements visibles par l’utilisateur sont :

• la prise en charge de l’appel système statx() ;
• l’ajout de la possibilité à un processus lancé avec CAP_SYS_RESSOURCES de dépasser les limites fixées par les quotas ;
• une meilleure précision des seuils à partir desquels la compression est déclarée bénéfique et est déclenchée ;
• la suppression de l’option de montage alloc_start, qui avait été créée pour des fins de débogage.

Plus de détails ici.

4.14

Btrfs

Btrfs prend maintenant en charge Zstd en plus des autres algorithmes de compression. Ce qui permet de réduire la charge processeur comparé à zlib, ou avoir un meilleur ratio de compression pour moins d’entrées‐sorties comparé a LZ4.

Architecture

4.12

Allwinner

• Allwinner H3 et H5 gagnent la prise en charge de l’USB OTG ;
• ajout de la prise en charge des cartes FriendlyARM NanoPi, NEO Air, Xunlong et Orange Pi PC 2.

Rockchip

• prise en charge de l’USB 3.0 pour le RK3399 ;
• ajout de la prise en charge du Samsung Chromebook Plus (Kevin) et des terminaux ChromeOS tournant sur des RK3399.

Amlogic

• ajout de la prise en charge de Khadas VIM et HwaCom AmazeTV ;
• ajout de la gestion DRM/HDMI pour les systèmes monopuces Amlogic GX.

Samsung

• mise à jour des DeviceTrees ARM pour Exynos 5440 et 5420 (OdroidXU3) ;
• correctifs divers.

Mediatek

• prise en charge du décodeur JPEG Mediatek dans V4L 2 ;
• ajout du DRM pour le système monopuce MT2701 ;
• ajout du pilote pour la génération aléatoire matérielle du système monopuce MT7623.

Divers

Ajout des plates‐formes et systèmes monopuces suivants :

• NXP — systèmes monopuces NXP/Freescale LS2088A et LKS1088A, cartes i.MX28 Duckbill-2 de I2SE, Gateworks Ventana i.MX6 GW5903/GW5904, cartes Zodiac Inflight Innovations RDU2, modules Engicam i.CoreM6 Quad/Dual OpenFrame, modules BoundaryDevice i.MX6 Quad Plus ;
• Texas Instruments — Motorola Droid 4 (processeur OMAP).

4.14

ARM

De nombreuses améliorations sur diverses plates‐formes ont été réalisées, notamment pour le Raspberry Pi Zero W.

Pilotes graphiques

4.12

AMD

Ajout de la gestion des processeurs graphiques AMD Radeon RX Vega

4.14

HDMI CEC sur RPI

Maintenant vous pouvez contrôler le RPI via votre lien HDMI et donc votre télécommande. Pratique pour le cinéma à la maison.

Virtualisation

KVM

Retour avec le noyau 4.14 de la prise en charge des processeurs ne proposant pas d’interruptions non masquables (NMI) virtuelles (Core 2 DUO) qui avait disparu avec la version 4.12 ([correctif], [source]).

Xen

Prise en charge de la virtualisation d’un sous‐ensemble des appels POSIX pour les conteneurs de type Docker ([correctif, [source]).

À partir de la version 4.12, il est possible de compiler le noyau avec Xen sans para‐virtualisation. ([correctif], [source]).

Prise en charge du système de fichiers 9P (documentation de 9pfs).

Annonces des versions candidates par Linus Torvalds

Version 4.12

RC1

La version RC1 a été annoncée par Linus Torvalds le samedi 13 mai 2017 :

Bon. Je sors celle‐ci un jour plus tôt parce que, de toute façon, je n’aime pas les demandes d’intégration [pull requests] de dernière minute et parce que demain, c’est la fête des mères. Donc, je risque de me retrouver entraîné dans toutes sortes de choses.

En outre, cela a été une fenêtre d’intégration assez large, donc bien que techniquement, il y a encore du temps pour une journée supplémentaire d’intégration, j’ai en fait déjà suffisamment de modifications. Donc, voilà.

Malgré une taille imposante, tout s’est déroulé (jusqu’ici) comme sur des roulettes. Je ne pense pas avoir personnellement vu de panne du tout, ce qui est toujours une bonne chose. D’habitude, je finis par avoir quelque chose qui casse ou qui déclenche une erreur de compilation idiote, et qui aurait dû être remarquée bien avant que cela ne remonte jusqu’à moi, mais jusqu’à présent tout se passe bien.

Les célèbres mots de la fin :

Les statistiques de cette version ont l’air étranges, parce qu’elles sont totalement dominées par les fichiers d’en‐tête de la nouvelle Vega10 d’AMD et qui contiennent toutes les définitions de registres. À vrai dire, ils représentent à eux‐seuls presqu’exactement la moitié des lignes du diff. Et si l’on ignore cette partie, les pilotes du nouveau processeur d’images Atom (IPU) d’Intel ont fini par former une part non négligeable du reste.

Mais si l’on fait abstraction de ces deux gros ajouts, les statistiques ont l’air à peu près normales : deux tiers de pilotes, le reste étant des mises à jour des architectures, de la mise à jour de documentations et du « divers » (systèmes de fichiers, réseau, mise à jour des fichiers d’en‐tête, fichiers du tronc commun).

Une chose qui valait la peine d’être notée : je n’ai pas mis en ligne de différentiels ou d’archives TAR de cette révision. Ils devraient à présent être générés automatiquement par kernel.org pour les RC, mais cela signifie aussi qu’ils ne seront pas signés par ma clé. Si la signature est vraiment importante pour vous, récupérez le dépôt Git et vérifiez les étiquettes [tags].

Testez.

Linus

RC2

La version RC2 a été annoncée le dimanche 21 mai 2017 (soit lundi, heure de Paris) :

Je reviens au calendrier dominical habituel et tout le reste a l’air assez normal aussi. Cette RC2 est peut‐être un peu plus importante que d’habitude, mais la fenêtre d’intégration entière était plus longue que la plupart des autres, donc peut‐être n’est‐ce dû qu’à cela. Et ce n’est pas comme si elle était immense non plus. En général, comme les gens découvrent des problèmes, la semaine de la RC2 est plutôt calme.

Les correctifs de la RC2 touchent un peu à tout : les pilotes pour les disques en parallèle (md), le réseau, les pilotes en préparation [staging], les processeurs graphiques, les chiens de garde [watchdog]… les architectures (x86, ARM[64], PowerPC et s390, les mises à jour de KVM), le tronc commun de la gestion du réseau, le filtre réseau BPF…

Le journal abrégé ci‐joint fournit un aperçu des détails, et il n’est pas de taille au point de vous empêcher de le passer en revue pour se donner un avant‐goût.

Rien d’inhabituel ne se dégage de tout cela, à part la taille en général. Et ce n’est même pas comme si c’était exceptionnel : la 4.9 reste la version la plus massive publiée, et la 4.12 ne va pas remettre cela en cause, même si elle est dans le haut de la fourchette.

J’espère simplement que le reste des RC ne va pas continuer à suivre cette tendance du « c’est toujours plus grand ».

Allez-y, testez. Jusqu’ici, malgré une plus grande taille, je n’ai rien vu d’inhabituel.

Linus

RC3

La version RC3 a été annoncée ce dimanche 28 mai 2017 (soit lundi, heure de Paris) :

Eh bien, il semble que tout se passe bien, et la RC3 n’est même pas très importante. J’espère qu’aucun problème ne va nous tomber dessus entre‐temps, mais jusqu’ici, j’ai vraiment l’impression que ce cycle va être tranquille, malgré la longueur de la fenêtre d’intégration.

Touchons du bois.

De toutes façons, la RC3 contient un peu de tout. La plus grosse modification individuelle n’est en fait qu’une mise à jour de la documentation (les docs du P-State d’Intel ont été converties au format *.rst), ce qui fait que les statistiques semblent un peu étranges, un quart concernant uniquement la documentation. Il y a également quelques mises à jour d’utilitaires (performances et autotests BPF).

Mais si l’on fait abstraction de ces deux morceaux, l’ensemble a l’air assez normal : deux tiers concernent les pilotes (les processeurs graphiques, le NVMe, le SCSI, les terminaux tty, périphériques blocs), le reste concernant pour moitié le réseau, et l’autre moitié la catégorie « divers » (tronc commun du noyau, fichiers d’en‐tête, XFS, mises à jour d’architectures).

Allez‐y, testez.

Linus

RC4

La version RC4 a été annoncée le dimanche 4 juin 2017 (soit lundi, heure de Paris) :

Les choses restent assez calmes pour le 4.12, bien que pas tout à fait aussi calmes qu’elles en avaient l’air plus tôt dans la semaine. Je pense que deux tiers des commits ont été soumis vendredi ou ce week‐end.

Mis à part le timing, les choses ont l’air assez normales. Le tout est assez petit, rien ne se démarque vraiment comme étant inhabituel. Cela ressemble pratiquement à la « loi normale de distribution des correctifs », dont les deux tiers concernent les pilotes (pilotes graphiques et RDMA, mais également les cibles SCSI, les interfaces homme‐machine [HID], les périphériques de saisie [input], les disques en parallèle [md], le SCSI…) et le reste étant un mélange d’architectures (principalement x86 cette fois‐ci), de systèmes de fichiers (OverlayFS et divers) et de code dans le tronc commun (gestion de la mémoire [mm] et fichiers d’en‐têtes).

Allez-y, testez.

Linus

RC5

La version RC5 a été annoncée le dimanche 11 juin 2017 (soit lundi, heure de Paris) :

Bon. La tendance « toutes les versions candidates ont été petites et agréables tout au long de la publication », ça ne pouvait sûrement pas se poursuivre jusqu’au bout.

La RC5 n’est pas si énorme, mais elle n’est certainement pas aussi petite et agréable que j’espérais. Il n’y a rien de particulièrement inquiétant et cela peut bien être dû au hasard du calendrier. Les tailles des versions candidates fluctuent beaucoup en fonctions des sous‐systèmes synchronisés pour une RC en particulier, et il se peut que nous ayons simplement rencontré le cas où « il se trouve que tout le monde a décidé de synchroniser cette semaine ».

Quoi qu’il en soit, la RC5 est notre plus grosse version candidate pour ce noyau (évidemment, sans compter la RC1, qui contient toute la fenêtre d’intégration). Et les modifications qu’elle apporte s’appliquent absolument partout : nous avons des mises à jour de pilotes (processeurs graphiques, réseau, le SCSI, les périphériques bloc et le son sont les plus grosses, mais il y en a un peu partout), nous avons des mises à jour d’architectures (ARM[64], PowerPC, SPARC, x86) et nous avons du système de fichiers (Btrfs, ext4, et plusieurs corrections d’UFS grâce à un regain récent d’activité du côté des rapports de bogue).

Mais nous avons également de la mise à jour de documentation, de la gestion réseau générique, des corrections sur la manipulation des clés de chiffrement, ainsi que sur KVM et sur les performances.

Donc, ce n’est pas vraiment un gros morceau. Plutôt un ensemble de petites choses différentes.

Et ce n’est pas déraisonnablement gros. Cette version candidate se démarque parce que le cycle 4.12 a été assez calme.

De toutes façons, j’espère vraiment que ce n’était qu’une facétie du calendrier. D’abord parce que j’espère — de manière générale — que les publications se raréfient à mesure que l’on progresse, mais également, et en particulier, parce que je serai en voyage durant les prochaines semaines et que, même si j’ai Internet et mon fidèle portable, j’espérais que les choses s’adouciraient avant que je m’en aille pérégriner autour du monde.

Bien sûr, peut‐être que tout sera encore plus calme que ’'habitude justement parce que les gens auront en fait finalisé tous leurs patches. J’ai le droit d’espérer.

Quoi qu’il en soit, n’hésitez pas à tester.

Linus

RC6

La version RC6 a été annoncée ce lundi 19 juin 2017 en fin d’après‐midi, heure de Paris (écart dû au fuseau horaire de Pékin, depuis lequel Linus Torvalds a publié cette version) :

Bien. Je suis en voyage et donc les horaires de cette version sont un peu détraqués, mais ça ne fait qu’un seul jour de retard (même si j’ai l’impression que cela en fait beaucoup plus, car je suis actuellement à Pékin et en avance de quinze heures sur mon fuseau horaire habituel [N. D. T. : +8 h au lieu de -7 h en temps normal]).

La bonne nouvelle, c’est que la RC6 est plus petite que ne l’était la RC5, et que je pense que nous sommes revenus sur nos rails et que la RC5 n’a vraiment été grosse qu’à cause des hasards du calendrier. On verra. Le week‐end prochain, quand je rentrerai à la maison et que je construirai la RC7, je verrai comment je sentirai les choses. J’ai toujours bon espoir qu’il s’agisse d’un cycle de sortie normal, dans lequel la RC7 est la dernière version candidate.

Et les choses ont l’air assez normales. Deux tiers de pilotes (rDMA se démarque, mais il y a aussi des pilotes réseau, graphiques, HID, etc.), le reste étant le mélange habituel d’architectures (s390, MIPS, PowerPC, ARM, XTemsa) et de systèmes de fichiers (encore du boulot sur UFS, mais également Ceph, Configfs et XFS), de la gestion de la mémoire, du réseau et des mises à jour des outils (dans « perf »).

N’hésitez pas à tester.

Linus

RC7

La version RC7 a été annoncée dimanche 25 juin 2017 (soit lundi, heure de Paris) :

Cela fait une semaine, et nous avons une nouvelle version candidate « -rc ».

Elle est assez petite et il n’y a pas eu de grosse surprise, donc si rien de fâcheux ne se produit dans la semaine à venir, ce sera la version RC finale. Mais, comme d’habitude, je me réserve le droit de faire traîner les choses si je finis par mal les sentir pour quelque raison que ce soit, y compris l’instinct. Donc, on verra.

Le journal abrégé ci‐joint est suffisamment court pour être étudié en détail, mais vu d’en haut, la distribution globale des correctifs a l’air assez normale : le plus gros concerne comme d’habitude les pilotes (il se peut que les processeurs graphiques et le réseau se démarquent, mais il y a un groupe de choses diverses comme les périphériques bloc, pinctrl, les interfaces homme‐machine [HID], le son, les périphériques de saisie, les cibles SCSI…) avec différentes mises à jour des archis (principalement PowerPC, mais il y a aussi du x86, de l’ARM64, du s390 et un peu de bruit du côté de MIPS).

En dehors des archis et des pilotes, on a quelques correctifs sur la gestion générique du réseau, des scripts, et des micro‐corrections sur le tronc commun du noyau, dont une ou deux petites choses à régler sur le correctif de l’espacement de pile [stack gap] de la dernière RC.

Mais tout cela reste très concis.
À vous de tester.

Linus

Version finale

La version définitive du noyau 4.12 a été annoncée le dimanche 2 juillet 2017 (soit lundi, heure de Paris) :

Cette semaine a été très calme, je n’avais donc pas de raison valable pour retarder la sortie de la version 4.12.

J’avais déjà eu l’occasion d’en parler lors des annonces des versions candidates, la 4.12 est l’une des plus grosses versions jamais publiées, et je crois que seule la 4.9 a eu plus de commits. Et cette dernière était grosse en partie parce que Greg avait annoncé que ce serait une version à durée de maintenance étendue (LTS). Mais la 4.12 est tout simplement grosse.

Il n’y a rien non plus de spécialement bizarre dans l’arborescence — c’est du développement normal, seulement un peu plus que d’habitude. Le journal abrégé ci‐dessous ne liste évidemment que les changements mineurs effectués depuis la RC7 — la liste complète de toutes les modifications de la 4.12 est trop grosse pour la poster ici [N. D. T. : 1 864 contributeurs et 14 570 correctifs !].

En ce qui concerne le nombre de différences, la 4.12 est également très imposante, bien que cela ne soit pas dû au fait qu’il y ait eu beaucoup de développement : le bloc de fichiers d’en‐têtes pour la prise en charge de Vega d’AMD représente quasi exactement la moitié des correctifs, et en partie à cause de cela la partie « pilotes » domine tout le reste, à plus de 85 % des correctifs de cette version (il n’y a pas que les en‐têtes de Vega d’AMD — le pilote de l’IPU d’Intel dans « staging » est gros aussi, par exemple).

Mais à part le fait qu’elle soit grosse et qu’elle ait subi un petit sursaut en taille autour de la RC5, la version candidate s’est stabilisée assez proprement, donc je pense qu’on est bon, et qu’on peut y aller.

Allez‐y, utilisez‐le.

Ah, et évidemment, cela signifie que la fenêtre d’intégration pour le noyau 4.13 est par conséquent ouverte. Vous connaissez le principe.

Linus

Version 4.13

RC1

La version RC1 a été annoncée par Linus Torvalds le samedi 15 juillet 2017 :

Bon. Normalement je fais cela le dimanche après‐midi, mais il m’arrive occasionnellement de le faire un jour plus tôt pour éviter que les gens m’attendent.

En réalité, j’avais prévu de le faire hier soir cette fois‐ci, parce que j’ai été ennuyé par un tas de demandes d’intégration tardives vendredi (et quelques‐unes aujourd’hui), mais j’ai fini par aller dîner et ne rien faire, donc ça ne fait qu’un jour d’avance. La prochaine fois…

Ça a l’air d’être une version assez normale et, comme toujours, la RC1 est bien trop grande pour poster ne serait‐ce que le journal abrégé. Donc, voici le journal des fusions [mergelog] qui montre de qui j’ai rapatrié les modifications accompagnées d’une ligne de description à chaque fois.

Une fois encore, les statistiques des changements sont totalement dominées par des fichiers d’en‐tête des processeurs graphiques d’AMD. Mais si l’on en fait abstraction, les choses ont l’air plutôt normales, avec environ deux tiers de pilotes et un tiers de « reste » (architecture, tronc commun du noyau, gestion réseau générique, utilitaires).

Assez inhabituelles sont, en revanche, les mises à jour de la documentation, qui forment une part assez remarquable du « reste » (presque la moitié), grâce à un effort continu pour régulariser et nettoyer son contenu.

Commencez à tester.

Linus

RC2

La version RC2 a été annoncée le dimanche 23 juillet 2017 :

Les choses font doucement leur chemin et nous avons en fait une version RC2 raisonnablement active.

Normalement, la RC2 est de petite taille parce que les gens reprennent leur souffle et parce qu’ils n’ont pas encore commencé à trouver des bogues. Mais, cette fois‐ci, nous avons une RC2 plus grosse que la moyenne. Nous n’aurons qu’à voir comment cela se traduit au cours du reste du cycle de sortie, mais je soupçonne tout cela de n’être que la variabilité normale des choses (et parce que j’ai publié la RC1 un jour plus tôt, j’imagine que la RC2 doit être « plus longue d’une journée », malgré sa sortie habituelle le dimanche).

Des changements un peu partout, bien que les statistiques des changements soient dominées par le nouveau pilote vboxvideo dans staging. Je n’aurais pas dû le laisser passer, mais Greg, comme nous le savons tous, est « spécial ». En plus, quod licet Iovi et tout le toutim… Il arrive occasionnellement à Greg d’enfreindre les règles.

Si l’on ignore ce nouveau pilote expérimental, le reste est toujours formé d’environ une moitié de correctifs pour les pilotes (réseau, rDMA, SCSI, USB). L’autre moitié a l’air normale aussi : des mises à jour des architectures (x86, SPARC, PowerPC), du système de fichiers (NFS, OverlayFS, divers…), du réseau et du tronc commun du noyau. Et un peu de nouveau code de test de BPF.

C’est l’heure de refaire des tests. Vous connaissez le principe.

Linus

RC3

La version RC3 a été annoncée le dimanche 30 juillet 2017 à 21 h 45, heure de Paris :

Encore une semaine, encore une RC.

D’habitude, la RC2 est vraiment la plus calme mais pour ce cycle, RC2 a été assez active et cela m’a inquiété un peu, en me faisant me demander si quelque chose de mauvais était en train de se passer avec le 4.13.

Mais non, ce sont juste les hasards du calendrier et le fait que les gens ont commencé à envoyer des correctifs assez tôt. Et pour cette version, c’est la RC3 qui est petite. Elle fait à peu près la moitié de la taille (en commits) de la RC2. D’habitude, c’est l’inverse. Peut‐être que les gens commencent à partir en vacances (le mois d’août tend à être calme, en particulier en Europe).

Je ne me plains pas. C’est sympa, les semaines calmes.

Linus

RC4

La version RC4 a été annoncée le dimanche 6 août 2017 (soit lundi, heure de Paris) :

La RC3 était donc plus petite qu’à l’habitude, et maintenant c’est la RC4 qui est plus grosse que d’habitude.

En revanche, elle ne l’est pas démesurément, et la raison à cela est assez claire : l’intégration de la branche réseau a manqué la RC3, donc elle se retrouve en RC4 à la place. Ceci, avec les intégrations côté médias, compte pour le gros des changements (la partie réseau a plus de commits, alors que les médias ont plus de lignes modifiées, dues en grande partie à des SVG dans la documentation).

À vrai dire, les changements côté média apportés à ces fichiers SVG dominent tellement le reste que les différentiels pour cette version candidate sont à 90 % dans Documentation/media. C’est en partie à cause du fait que tout le reste est assez petit. Donc, il y aura peut‐être un peu plus de commits que d’habitude, mais ils ne sont vraiment pas aussi gros et effrayants qu’ils en ont l’air.

À part les changements dans les médias et le réseau, il y a quelques mises à jour d’amdgpu, un peu de SCSI, une mise à jour d’ext4 et des mises à jour des architectures. Et un peu de bruit divers. Le journal abrégé ci‐joint est un bon condensé pour avoir un avant‐goût des changements.

De toute façon, rien ne se démarque vraiment et, même si j’espère que tout va se calmer au fur et à mesure, tout a l’air parfaitement sur les rails pour donner une version normale.

Donc allez‐y, testez tout ça. À ce stade, ça devrait vraiment être sans risque.

Linus

RC5

La version RC5 a été annoncée le dimanche 13 août 2017 (soit lundi 14 à 1 h 14, heure de Paris).

Les choses progressent assez normalement. La RC5 est plus petite que ne l’était la RC4 et rien n’a l’air particulièrement effrayant dans cette fenêtre de publication.

Espérons que ça continue comme ça.

Les statistiques des changements ont l’air normales aussi, avec un tout petit peu plus de 40 % de mises à jour de pilotes, et un tout petit moins de 40 % de mises à jour des architectures. Même si la raison pour laquelle les mises à jour des architectures apparaissent si hautes est largement due à un unique fichier eBPF JIT dans MIPS qui s’est perdu (quelqu’un a oublié de faire git add, selon moi) et qui a été arrangé ici.

En dehors des pilotes et des architectures, c’est le lot habituel au hasard : du réseau, de la mémoire virtuelle, des fichiers d’en‐tête et quelques scripts. Et des correctifs d’une seule ligne divers et variés.

Journal abrégé ci‐joint. Vous pouvez vous faire une idée de ce qu’il se passe en le lisant. Des tas de petits détails qui ont été réglés.

Allez‐y, testez. Et tout indique qu’on sortira le 4.13 selon le calendrier habituel.

Linus

RC6

La version RC6 a été annoncée le dimanche 20 août 2017 :

Les choses ont été plutôt calmes et la RC6 est là. Rien ne sort vraiment du lot — tout a l’air normal, avec juste une peu moins de la moitié du correctif concernant les pilotes (le réseau sort du lot, mais il y a aussi InfiniBand et diverses autres choses aussi), un tiers du reste concernant les mises à jour d’architecture. Le reste ne consiste qu’en diverses choses plus ou moins basiques un peu partout.

Le journal abrégé des modifications ci‐joint est à peu près autant descriptif que n’importe quoi d’autre. Il est assez court pour que vous puissiez le parcourir facilement pour voir s’il y a quelque chose de particulier qui vous intéresse.

Donc, tout semble en bonne voie pour un calendrier de publication normal, ce qui devrait impliquer une RC7 en fin de semaine prochaine et ensuite la 4.13 finale la semaine d’après.

À moins que quelque chose ne se passe, bien sûr. Demain, il y a l’éclipse solaire et peut‐être que ça va causer ruine et désolation, même pires que le trafic apocalyptique de l’Oregon. On ne sait jamais.

Linus

RC7

La version RC7 a été annoncée le dimanche 27 août 2017 :

Hmm. Nous avons quelques problèmes qui ont surgi la semaine passée, mais rien qui n’impacte vraiment le calendrier.

Donc, voici la RC7, et j’espère toujours que ce sera la dernière, même si « même les plans les mieux ficelés »…

La RC7 est assez petite, avec la plupart des changements dans les pilotes et les architectures, comme d’habitude. Cela dit, cette fois, « la plupart » est tout juste vrai. On a pas mal d’autres changements, si bien que les pilotes et les architectures ne forment que 60 % des correctifs. Il y a des fichiers d’en‐tête, de la mémoire virtuelle, du réseau, du tronc commun noyau, de la documentation, des scripts…

Un pot‐pourri, en d’autres mots, mais que de petites corrections. Vous pouvez passer le journal abrégé en revue, rien ne sort du lot à mes yeux pour l’instant.

Linus

Version finale

La sortie du noyau 4.13 a été annoncée le dimanche 3 septembre 2017 à 23 h 47, heure de Paris :

La plupart des changements depuis la RC7 sont en fait des correctifs au niveau du réseau, le plus gros d’entre eux s’appliquant à divers pilotes. Avec mes excuses aux auteurs desdits correctifs, ils n’ont pas tous l’air aussi intéressants que ça (et c’est exactement ce qu’il faut à la veille d’une publication). Détails dans le journal abrégé.

À noter que le journal abrégé ne remonte évidement que jusqu’à la RC7. Le journal complet du noyau 4.13 est bien trop gros à poster et aucune personne saine d’esprit ne le lirait. Donc, si le reste vous intéresse, récupérez l’arborescence Git et limitez le journal aux fichiers qui vous intéressent si vous mourrez vraiment d’envie de voir les détails [N. D. T. : git shortlog --no-merges v4.12..v4.13 [fichiers], 13 006 commits en tout, 209 cette semaine].

Non. l’effervescence est en grande partie venue de la couche de notification MMU, où nous avons eu une régression de toute dernière minute et quelques discussions sur ce problème. Gloire à Jérôme Glisse pour avoir sauté sur l’occasion et implémenté le correctif.

Ce qui est beau à voir, c’est que la régression a mis en évidence une partie assez vilaine et pas bien documentée (ni bien pensée) des notifications MMU, et le correctif n’a pas seulement réglé le problème, mais l’a fait en faisant du nettoyage et en documentant ce qui devrait être la bonne façon de se comporter. Et il l’a fait de plus en se débarrassant du notificateur problématique et en enlevant au passage presque deux cents lignes dans le processus.

J’adore voir ce genre de correctif : du code meilleur et plus concis.

Le reste de l’exaltation, cette semaine, était purement personnel et a consisté en sept heures de pure agonie due à un calcul rénal. Je vais très bien, mais j’ai vraiment eu l’impression que ça a duré beaucoup plus que sept heures, et je ne veux même pas imaginer ce que cela doit être pour qui l’expérience s’est éternisée plus longtemps. Ouille !

Quoi qu’il en soit, en ce qui concerne les problèmes du 4.13 :

Alors même que nous avons eu beaucoup de changements tout du long (le 4.13 n’était pas particulièrement gros, mais même une version « bien dans la moyenne » n’est pas exactement « petite »), il y a un tout petit changement qui mérite un peu plus d’attention, car c’est un de ces très rares changements où l’on modifie un comportement à cause d’une question de sécurité, et où les gens doivent bien être conscients de ce changement au moment de mettre à jour.

Cette fois, ce n’est pas un problème de sécurité du noyau, mais un problème de sécurité générique au niveau d’un protocole.

La modification en question est simplement le changement du comportement par défaut de CIFS : au lieu d’opter par défaut pour SMB 1.0 (qu’on devrait tous arrêter d’utiliser : faites une recherche Google avec « stop using SMB1 » ou requête similaire), les montages CIFS par défaut basculent maintenant a priori sur le plus moderne SMB 3.0.

Maintenant, puisque vous ne devriez plus utiliser SMB 1 de toutes façons, ça ne devrait affecter personne. Mais vous savez quoi ? Ça affecte certainement des gens, puisqu’ils continuent joyeusement à utiliser SMB 1 sans s’en soucier.

Et vous pourrez certainement continuer à utiliser SMB 1, mais à cause du changement de version par défaut du protocole, vous devrez maintenant en être conscients. Il se peut que vous deviez ajouter une option explicite vers=1.0 à vos options dans /etc/fstab ou assimilé si vous tenez à utiliser SMB 1.

Mais si la version 3.0 par défaut ne fonctionne pas (parce que vous utilisez toujours un ptérodactyle comme essuie‐glace), avant de tous retourner au pas si bon vieux temps et d’utiliser ce vers=1.0, vous devriez peut‐être essayer vers=2.1. Parce que, ouvrons les yeux, le SMB 1, c’est vraiment, vraiment, vraiment mauvais.

De toute façon, la plupart des gens ne le remarqueront même pas. Et ceux qui le remarqueront peuvent vérifier leur situation actuelle (regardez simplement la sortie de mount et voyez s’il y a des choses concernant CIFS dedans) ; et vous devriez vraiment mettre à jour la version par défaut, même si vous ne mettez pas à jour le noyau.

Bon, assez dit de ce côté. Ce n’était vraiment qu’une modification de deux lignes… sur les millions de lignes que l’ensemble des correctifs du noyau 4.13 a modifié dans le vrai code.

Allez récupérer le nouveau noyau.

Linus

Version 4.14

RC1

La version RC1 du noyau 4.14 a été annoncée par Linus Torvalds le samedi 16 septembre 2017 :

Oui, je réalise que l’on est un jour en avance et, oui, je réalise que si j’avais attendu jusqu’à demain, j’aurais aussi atteint le 26ᵉ anniversaire de la publication de Linux-0.01, mais de ces faits indéniables, ni l’un ni l’autre ne m’ont donné l’envie d’attendre avant de refermer la fenêtre d’intégration.

C’était une fenêtre « intéressante ». Ce n’est pas tant qu’elle est inhabituelle en taille. Je pense que c’est une sortie tout à fait classique qui se profile, après la 4.13 qui, elle, était maigre. Mais contrairement à la 4.13, cela n’a pas été non plus une fenêtre complètement harmonieuse et, honnêtement, je n’ai vraiment pas envie d’attendre toutes les requêtes d’intégration possibles et arrivant en vrac.

Ne vous méprenez pas. Les choses n’ont pas l’air mal, mais j’ai horreur de repérer des problèmes pendant la fenêtre d’intégration quand j’ai l’impression que ces choses auraient dû être remarquées avant que le code ne parvienne jusqu’à moi, et c’est arrivé quelques fois au cours de cette publication.

Certes, certaines d’entre elles sont simplement dues à une activité inhabituelle. Par exemple, du côté de la mémoire virtuelle sur x86, le 4.14 n’a pas simplement UNE nouvelle fonctionnalité au cœur de la gestion de la mémoire, mais trois : la table des pages à cinq niveaux, la prise en charge de l’identification de l’espace d’adressage ASID (cela s’appelle « PCID » sur x86, pour des raisons qui ne sont pas bonnes) et la prise en charge du chiffrement de la mémoire d’AMD. Donc, le fait que nous ayons connu quelques cahots est tout à fait compréhensible. Et, en réalité, ce qui devrait étonner tout le monde, c’est avec quelle facilité l’intégration de la table des pages à cinq niveaux s’est faite, par exemple.

Donc, le 4.14 est en train de recevoir de nouvelles fonctionnalités très fondamentales.

Évidemment, comme d’habitude, ces types de changements fondamentaux passent presque inaperçus en comparaison de la masse de toutes les mises à jour des pilotes de périphériques, qui comme d’habitude forment le gros des correctifs. Cette fois‐ci, un cas particulièrement notable est un ajout tardif à la fenêtre d’intégration — ou plutôt un retrait tardif — dans le sens où nous nous sommes finalement débarrassés des images des micrologiciels [firmwares] dans l’arborescence du noyau. C’est parce les gens ne les ont pas utilisées ces dernières années, puisque qu’il y a un dépôt séparé pour les images de micrologiciels.

Mais il y a des changements un peu partout. De la documentation, de la mise à jour des architectures, des systèmes de fichiers, du réseau, des utilitaires. Ça n’a pas été une petite version, même si je m’attendais qu’avec la plupart de l’Europe en vacances en août, on ait un peu levé le pied. Eh bien, non.

Quoi qu’il en soit, comme toujours, le journal abrégé est bien trop gros pour être posté. Donc, voici ci‐joint le « journal des fusions » et, comme toujours, ce ne sont pas les gens qui ont écrit les correctifs qui s’y trouvent nommés, mais les mainteneurs qui les ont soumis pour intégration. Donc, il y a environ 90 mainteneurs mentionnés ici, mais on devrait noter qu’il y a plus de 1 500 auteurs individuels pour plus de 11 500 commits individuels, hors fusions. C’est donc surtout un bref tour d’horizon des fusions que j’ai effectuées et si vous voulez voir les détails, il vous faudra aller voir le journal de l’arborescence Git.

Linus

RC2

La version RC2 a été annoncée le dimanche 24 septembre 2017 (soit lundi, heure de Paris) :

Je reviens à mon calendrier habituel de publication le dimanche, et voici donc une RC2 qui paraît normalement.

C’était une RC2 très habituelle, avec un début de semaine très calme et la plupart des changements qui sont arrivés le vendredi après‐midi et le samedi (avec les tout derniers se présentant le dimanche matin).

Normalement, j’ai tendance à ne pas apprécier la façon dont cela repousse tout mon travail au week‐end, mais cette fois j’en ai tiré profit, en allant passer à la place la partie calme de la semaine à faire de la plongée.

De toute façon, la seule chose inhabituelle qui vaut le coup d’être soulignée est que la requête d’intégration du sous‐système de sécurité qui a été présentée pendant la fenêtre d’intégration a été rejetée à cause de plusieurs problèmes et, donc, la RC2 se termine avec la plupart de cette requête de sécurité se retrouvant intégrée en tant que parties indépendantes à la place.

En conséquence, environ 30 % des correctifs sont en réalité des choses qui auraient techniquement dû arriver durant la fenêtre d’intégration, mais qui ont été reportés à la RC2 à cause de ce problème.

À part cela, c’est le mélange habituel de diverses choses. Des pilotes (le réseau, rDMA et les pilotes graphiques se démarquent), des correctifs d’architectures (x86, MIPS, s390, PARISC, PowerPC, ARM), un peu de systèmes de fichiers, du réseau et de la documentation.

Rien qui ne sorte vraiment du lot, bien que nous soyons heureusement venus à bout de tous les problèmes qui concernaient l’ASID sur x86. Touchons du bois.

Journal abrégé ci‐joint en tant que bref aperçu des détails.

Allez le tester.

Linus

RC3

La version RC3 a été annoncée le dimanche 1^er octobre 2017 (soit lundi, heure de Paris) :

Donc, la 4.14 continue d’être une version un peu pénible à sortir, et je commence à mettre cela, au moins en partie, sur le compte du fait qu’elle est censée être une LTS [Long Term Support : version prise en charge à long terme].

La dernière version LTS que l’on a eue (4.9) a donné lieu à la publication de l’un des plus gros noyaux que nous ayons connus, parce que tout le monde voulait en faire partie. La version 4.14 n’a pas l’air d’être aussi grosse, mais il semble bien qu’elle soit à l’origine de certains travaux de dernière minute, parce que les gens veulent préparer quelque chose pour cette version 4.14, bien conscients que ce sera une LTS.

Mais qui sait. Il se peut qu’une partie de tout ça ne soit que pure coïncidence. Mais je connais déjà au moins deux demandes d’intégration supplémentaires qui sont toujours en suspens et qui voudront sûrement être intégrées elles aussi dans le 4.14.

Quoi qu’il en soit, concernant les changements effectifs de RC3… La plupart d’entre eux correspondent aux petites corrections normales, mais il y a deux ou trois petites choses un peu plus notables :

• des correctifs sur la gestion de certains états de l’unité de calcul en virgule flottante sur x86 ;
• des correction de certains problèmes de cryptographie concernant notre gestion interne des clés ;
• un peu de ménage dans smp et hotplug.

… et toutes ces choses sont plus grosses que je l’aurais espéré à ce stade, mais elles ont toutes de bonnes raisons d’être intégrées maintenant. Elles ont toutes une chose en commun, dans le sens où elles font toutes du nettoyage pour pouvoir corriger un problème sous‐jacent (et donc, en fait, le commit qui le corrige est assez petit, mais il y a toute une série de nettoyages qui rendent possible cette correction).

Les deux cas que je considère potentiellement toujours en suspens sont du même genre : un correctif au niveau de l’écriture en mémoire cache [writeback] et quelques autres au niveau des chiens de garde [watchdog] avec, dans les deux cas, une majorité de nettoyage pour pouvoir régler les choses.

De toute façon, tout cela a en commun le fait que j’aurais adoré recevoir ce code pendant la fenêtre d’intégration en tant que « changements évidemment appréciables », mais ça ne me fait pas peur de le recevoir pendant les phases de RC.

Mais, bon, j’arrête de me plaindre.

Les choses n’ont pas l’air mal. Oui, c’est plus de changements que j’en aurais espéré à ce stade, mais en même temps, aucun d’eux n’a l’air de fondamentalement poser problème à la sortie du noyau 4.14. La plupart du ménage de l’unité de calcul en virgule flottante sur x86 est fait depuis un certain temps, par exemple. C’est juste que les corrections de bogues ont fait qu’ils ont été intégrés à un moment un peu moins optimal.

Les différents changements finissent par donner aux statistiques un aspect un peu inhabituel : les corrections sur les pilotes de périphériques qui d’habitude dominent le reste ne représentent qu’un quart du butin cette fois‐ci, avec les correctifs d’architectures (qui ne concernent pratiquement que x86) formant un autre quart. Le reste concerne le cœur du noyau (la plupart correspondant aux mises à jours de SMP et hotplug), la sécurité (changements dans la manipulation des clés) et les utilitaires (principalement sur les performances, mais aussi de nouveaux auto‐tests). Quelques corrections sur les systèmes de fichiers (Btrfs et XFS, un peu de « divers ») comptant pour le reste.

Il est encore un peu tôt, dans ce cycle de publication des RC, pour dire si cela aura un impact sur le calendrier. Pour le moment, j’ai toujours l’impression que l’on respecte bien le calendier habituel (à savoir, la RC7 étant la dernière RC), mais il faudra juste voir comment se déroule la suite de cycle de publication.

Merci d’aller le tester.

Linus

RC4

La version RC4 a été annoncée le dimanche 8 octobre 2017 (soit lundi, heure de Paris) :

Nouvelle semaine, nouvelle RCc.

Cette version semble bien continuer d’être plus active dans ses versions candidates que d’habitude, mais en fait, on dirait que ça se calme. Donc, la RC4 est plus grande que ne l’est d’habitude une RC4 (environ 400 commits hors fusions, quand d’habitude, à ce stade, on devrait en être à environ 300), mais en même temps, elle a l’air tout à fait normale. Il y a eu l’intégration des chiens de garde [watchdog] que j’ai mentionnée à la sortie de la RC3 ; mais, à part ça, elle ressemble plus à une RC normale que la RC3, par exemple.

En particulier, si l’on fait abstraction de cette histoire de chiens de garde, on retrouve l’habituel « principalement des pilotes et des mises à jour des architectures ». Cette fois, la plupart des mises à jour d’architectures concernent (de loin) ARM, et les pilotes sont dominés par le réseau, mais il y a d’autres choses dedans aussi (USB, MMC, HID…). Et les habituels ajouts divers un peu partout ailleurs.

La bonne nouvelle, c’est que les statistiques des changements sont assez « plates ». Autrement dit, les changements sont tout petits. L’exception concerne cette affaire de chiens de garde et un peu de réorganisation dans les fichiers *.dts des STM32.

J’ai donc bon espoir que les choses se présentent normalement. Je m’attends à ce que cela continue et que les choses commencent à se calmer. Si la RC5 ne présente pas de signe notable d’accalmie, je pense qu’il faudra commencer à penser à une RC8 et au reste, mais on verra. Le Kernel Summit approche, donc les gens seront en train de voyager quand on en sera un peu plus loin dans le cycle de développement. On verra comment cela affecte les choses.

En tout cas, le journal abrégé est ci‐joint. Allez‐y, testez.

Linus

RC5

La version RC5 a été annoncée le dimanche 15 octobre 2017 (soit lundi, heure de Paris) :

Les choses semblent enfin commencer à se calmer pour le 4.14.

Il est clair qu’on a déjà connu des RC5 plus petites, mais on en a aussi eu de plus grosses aussi, et cette semaine a enfin commencé à ressembler à la normale, au cours d’une publication qui, jusqu’ici, avait l’air un peu plus fouillis que ce qu’elle aurait peut‐être dû être.

Donc, en considérant que cette tendance va persister, on est tout bon. Touchons du bois.

Alors, qu’avons‐nous là ? Un petit peu de tout, mais ce qui pourrait être le plus remarquable concerne quelques correctifs appliqués à la nouvelle gestion sur x86 de la mémoire cache TLB dans son entier, à cause des changements apportés à l’ASID et qui sont arrivés avec cette publication. Certains des changements concernant la gestion tardive [lazy] du TLB posaient problème sur quelques‐unes des puces AMD avec des réglages particuliers, parce qu’elle était un petit peu trop tardive à vider le TLB. Même si les entrées du TLB n’étaient pas utilisées (et qu’elles étaient vidées avant toute utilisation possible), le TLB pouvait être rempli spéculativement, et ça posait problème si l’on avait déjà libéré les tables de pages que ce remplissage spéculatif finissait par référencer.

L’autre chose qui peut valoir le coup d’être mentionnée est à quel point le fait d’avoir beaucoup de personnes essayant des choses au hasard peut être efficace, et le nombre de choses qu’elles trouvent. On a toujours fait des tests au hasard (qui se souvient de l’ancien programme crashme (« plante‐moi ») qui ne faisait rien d’autre que générer du code au hasard et faire un saut vers lui ? On a fait ça de façon très active les premiers temps), mais les gens ont fait des tests aléatoires bien ciblés sur les pilotes et les sous‐systèmes, et il y a eu différents correctifs (pas seulement la semaine passée) qui ont découlé de ces efforts. C’est vraiment beau à voir !

Quoi qu’il en soit, la RC5 est sortie et les choses ont l’air normales. On a des mises à jour d’architectures (principalement x86 et PowerPC, mais aussi un peu de MIPS), des pilotes (processeurs graphiques, réseau, USB, son et divers), du noyau interne (correctifs sur les dépendances des verrous [lockdeps], réseau, gestion de la mémoire) et un peu d’utilitaires (performances et auto‐tests).

Allez‐y, testez.

Linus

RC6

La version RC6 a été annoncée le lundi 23 octobre 2017 :

Alors, la RC6 a été retardée, pas à cause de problèmes de développement, mais simplement parce qu’Internet a été de très mauvaise qualité pendant mon habituel dimanche après‐midi, et que j’ai décidé de ne même pas essayer de me battre contre ça.

Et en retardant les choses, j’ai reçu deux demandes d’intégration supplémentaires de la part de Greg. J’imagine que je dois dire oui ?

La RC6 est un peu plus importante que je ne l’espérais, et je ne sais pas encore si c’est le signe qu’après tout, il nous faudra une RC8 au cours de cette publication (ce qui ne serait pas terriblement surprenant) ou si c’est simplement dû au calendrier. Je vais laisser ouverte cette question pour le moment. Donc, sachez simplement qu’une RC8 peut arriver.

À part ça, les choses ont l’air normales : les pilotes (processeurs graphiques, réseau, saisie, médias, USB…) en forment le plus gros, mais nous avons aussi quelques mises à jour des auto‐tests qui apparaissent également dans les statistiques de changement. Le reste est réparti à peu près équitablement un peu partout : un peu de documentation, des mises à jour d’architectures, du système de fichiers, du tronc commun du noyau et de la gestion de clés.

Allez‐y, testez.

Linus

RC7

La version RC7 a été annoncée le dimanche 29 octobre 2017 :

De retour à la maison, et de retour au calendrier normal des publications le dimanche après‐midi.

Et la RC7 est également normale en taille. À dire vrai, en regardant les statistiques des sorties des versions RC7 pour la lignée des noyaux 4.x, elle tombe pile sur la taille médiane. Elle avait même l’air plus petite que d’habitude jusqu’à l’intégration des correctifs réseau aujourd’hui.

Malgré tout, en regardant tous les problèmes que nous avons eus, je ferai fort probablement une RC8, à moins que la semaine à venir finisse par être si calme qu’il n’y ait pas lieu de le faire. Ce qui, tout aussi improbable que ce soit, serait fort appréciable. Si je finis par faire une RC8, cela repoussera aussi la deuxième moitié de la fenêtre d’intégration pendant la semaine de Thanksgiving, ce qui serait gênant parce que je serai à nouveau en voyage. Donc, je serais vraiment ravi si les choses se mettaient soudainement à se calmer au point de rendre une RC8 sans objet.

J’ai le droit d’espérer.

Mais je ne sortirai le noyau 4.14 que quand je sentirai qu’il sera vraiment prêt, pas quand ce sera le plus pratique.

En tout cas, allez‐y, testez. Le journal abrégé ci‐joint est suffisamment court pour être facilement passé en revue. Il y a une paire de retours en arrière [reverts] et du contenu divers un peu partout (la partie réseau étant peut‐être la plus remarquable, mais il y a aussi du système de fichiers, des pilotes, de l’architecture…).

Linus

RC8

La version RC8 a été annoncée le dimanche 5 novembre 2017 :

Donc, en fait, ça a été une assez bonne semaine et aucun des correctifs qui sont arrivés ne me déplaît vraiment.

Mais de là à me faire décider que nous n’avions pas besoin d’une RC8 pour ce cycle, il aurait fallu qu’elle soit totalement silencieuse et elle ne l’était pas. Rien qui n’ait l’air vraiment effrayant, mais nous avons bien eu tout de même quelques retours en arrière, et je me sentirai mieux en donnant au noyau 4.14 une nouvelle semaine finale.

… et j’espère vraiment que ce sera bien la semaine finale et que nous ne découvrirons rien de nouveau et d’effrayant.

Je ne pense pas que ce sera le cas.

Cette RC8 signifie bel et bien que la seconde moitié de la fenêtre d’intégration aura lieu au cours de la semaine de Thanksgiving, quand je serai en vacances avec la famille. On verra comment ça se passe. J’espère que les gens m’enverront leurs soumissions plus tôt (surtout maintenant que l’on a une semaine supplémentaire pour le 4.14) et que j’aurai effectué une quantité suffisante de fusions au cours de la première semaine pour que voyager avec un portable n’ait même pas de réel impact sur la fenêtre d’intégration.

Et si ce n’est pas le cas, et que je me retrouve en difficulté à gérer tout ça, je n’aurai qu’à allonger un peu la fenêtre d’intégration. On l’a déjà fait par le passé, c’est un peu gênant, mais ce n’est pas la fin du monde.

Quoi qu’il en soit, concernant la RC8 : les statistiques des changements ont l’air immenses parce que j’ai intégré la première partie des marquages SPDX (de jolies étiquettes pour décrire les licences et utilisables par les scripts). Il y a donc tout un tas de modifications d’une seule ligne apportées à un grand nombre de fichiers. Cela va continuer de se produire pendant un certain temps.

Mais cela ne change évidemment aucune ligne de code, même si cela engendre malgré tout une recompilation.

En revanche, tous ces ajouts d’une ligne rendent les vrais changements difficiles à voir, si l’on regarde le différentiel. Vous pouvez en avoir un aperçu assez bon en écumant le journal abrégé ci‐joint à la place, et le tout est assez restreint : la plupart concerne des correctifs mineurs d’architectures, avec une pincée de mises à jour du réseau et des pilotes (son, DRM, cartes multimédia MMC, horloges, réseau). MIPS y apparaît, principalement à cause de mises à jour d’adresse de courriel (elles‐mêmes dues au passage de imgtec.com vers mips.com). Le reste concerne les utilitaires, la documentation et diverses choses (gestion des clés, quelques correctifs de la mémoire virtuelle, etc.).

Une chose pour laquelle j’ai reçu beaucoup de plaintes et qui n’était clairement pas populaire : la façon dont /proc/cpuinfo n’indiquaient plus d’informations de fréquences utiles sur x86 depuis le noyau 4.13. Ceci a été corrigé (et rétroporté sur la branche stable). C’est peut‐être ce qui est le plus flagrant pour la plupart des gens. Le reste n’est vraiment que de petits correctifs de bogues en interne.

Allez‐y, testez,

Linus

Version finale

La version définitive du noyau 4.14 a été annoncée le dimanche 12 novembre 2017 :

Pas de surprise cette semaine, bien que cela vaille le coup de souligner combien le robot 0day s’est encore amélioré (il était déjà très utile avant, mais Fengguang a travaillé à le rendre encore mieux, et à faire état des problèmes qu’il rencontre).

Bien sûr, quelques‐uns des rapports se sont avérés n’être dus qu’au fait que 0day faisait des choses qui ne marchent pas (par exemple, KASAN avec de vieilles versions de GCC, mais aussi des choses comme charger de vieux pilotes ISA dans des situations où cela n’a aucun sens. Souvenez‐vous que l’on ne pouvait même pas demander [à la machine] si le matériel était ou non présent, et que l’on devait simplement le savoir), mais même là, tout s’est bien passé.

Le journal abrégé ci‐joint ne concerne évidemment que le (bref) ensemble de ce qui est postérieur à RC8, et il est vraiment minuscule. Relativement peu de commits et ils sont petits. Ce qui se démarque le plus dans les statistiques des changements est le script Perl « leaking_addresses » [« fuites d’adresses », du noyau vers l’espace utilisateur], qui est en fait en phase active de développement, mais j’ai intégré sa première version avec le noyau 4.14 simplement pour que les gens puissent voir cet état initial, commencer à observer les résultats finals et peut‐être se demander « Est‐ce que mon code devrait rendre ces adresses noyau visibles depuis l’espace utilisateur ? ».

Les changements en pratique commenceront, espérons‐le, à « infuser » au cours du développement du noyau 4.15, avec un premier changement notable probable (qui a été largement débattu sur la liste de diffusion) consistant à générer, par défaut, une somme (hash) remplaçant toute adresse produite par %p. On utilisait habituellement des modes « stricts » qui remplaçaient toutes les adresses en sortie par des zéros, mais cela était en fait contre‐productif, dans le sens où, souvent, les gens utilisaient les adresses comme des « identifiants uniques des objets du noyau » au cours du débogage (ou pour la compilation croisée — pensez aux sockets réseau) et par conséquent, se contenter d’effacer les valeurs des pointeurs rendait ce genre de pratique sans objet. Mais utiliser une somme sécurisée permet ce genre d’utilisation en tant qu’identifiants, tout en évitant de révéler l’adresse elle‐même au grand jour.

(Les autres situations dans lesquelles la vraie adresse a de l’importance nécessiteront alors d’autres approches — nous restreindrons /proc/kallsyms aux seules entités qui en ont vraiment besoin, etc.)

De toute façon, mis à part ce seul script, le reste n’est vraiment constitué que de changements d’une ligne [one‐liners] ou de « quelques lignes » à la fois.

Le changement de dernière minute le plus notable concerne probablement le fait que nous ayons dû annuler le code qui affichait une bonne valeur en MHz dans /proc/cpuinfo même dans le cas du moderne « processeur qui relève la fréquence de façon dynamique ». Ça marchait bien, mais c’était beaucoup trop coûteux sur les machines équipées de dizaines, voire de centaines de cœurs processeurs. Nous avons trouvé une astuce, mais qui n’a pas pu être préparée à temps pour le 4.14. On va donc la mettre au point, puis on la rétro‐portera.

Tout le reste est assez ésotérique, mais vous pouvez toujours lire le journal des changements…

Et avec ça, la fenêtre d’intégration pour le noyau 4.15 est évidemment ouverte. Comme mentionné dans les dernières annonces des RC, la semaine supplémentaire pour la RC8 implique qu’à présent, la semaine de Thanksgiving finit par tomber pendant la seconde moitié de la fenêtre d’intégration, et je serai absent pour cause de vacances en famille.

On verra comment ça se passe.

Il se pourrait que je décide de prolonger la durée de la fenêtre d’intégration si je sens que je ne pourrai pas être suffisamment réactif.

Ou alors, peut‐être que vous ne vous apercevrez de rien, parce que j’aurai bien mon portable et un accès à Internet.

Ou bien encore, je déciderai tout simplement que la publication du 4.14 a été douloureuse, et que les éventuels traînards à la fin du 4.15 ne justifieront pas une nouvelle publication douloureuse, et que je me contenterai de dire « pas de chance, vous étiez en retard pendant la fenêtre d’intégration, et j’avais plus envie d’être dehors au soleil que de recevoir vos demandes d’intégration en deuxième semaine ».

Parce que j’adorerais vraiment que la sortie du noyau 4.15 soit plus petite et plus calme.

Dans tous les cas, allez‐y, testez la nouvelle version 4.14, qui est annoncée comme étant le prochain noyau LTS [N. D. T. : Long Term Support, noyau maintenu à long terme] — et commencez à m’envoyer vos demandes d’intégration pour la fenêtre du noyau 4.15.

Linus

Aller plus loin

• Site officiel du noyau Linux (362 clics)