Retour vers le passé : de Linux 4.12 à 4.14

Linux 3 days ago Linux FR 6

Cela fait quelques 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ée/sortie : 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 soft 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 on choisit une nouvelle file en fonction de leur budget, de leur poids (qui est paramétrable) et du temps qu'ils ont pu passer à consommer les I/O.

Nouvel ordonnanceur d'entrée/sortie - Le retour : Kyber

Kyber se veut simple et répond à une problématique toute différente de BFQ. Kyber part du principe que les I/O 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 hardware plutôt haute performance), il est plus pertinent de ne pas ordonner de manière complexe les requêtes (ce qui prend du temps CPU) et d'allouer de manière rapide les files. Le gain est donc important en terme de ressource, puisque ce scheduler est très simple. Le revers à 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ème 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 une nouvelle ioctl qui permet, via deux clés de recherche défini comme un tuple (device, bloc, propriétaire, décalage), et renvoie toutes les informations de mappage d'espace connues pour le système de fichiers donné.
article lwn

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 statistique supplémentaire sur les blocs Show available_nids in f2fs/status commit
NFS
  • Nettoyage du drivers (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 du label CONFIG_UBIFS_FS_SECURITY pour activer/désactiver les labels 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 mirroir 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

Le btrfs a maintenant le support de zstd en plus des autres algorithmes de compression. Ce qui permet de réduire la charge cpu comparé à zlib, ou avoir un meilleur ratio de compression pour moins d'IO 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 SoC Amlogic GX.
Samsung :
  • mise à jour des DeviceTree ARM pour Exynos 5440 et 5420 (OdroidXU3) ;
  • correctifs divers.
Mediatek :
  • prise en charge du décodeur JPEG Mediatek dans v4l2 ;
  • ajout du DRM pour le SoC MT2701 ;
  • ajout du pilote pour la génération aléatoire matérielle du SoC MT7623.
Misc :

ajout des plateformes et SoC suivant :

  • NXP – NXP/Freescale LS2088A and LKS1088A SoC, I2SE’s i.MX28 Duckbill-2 boards, Gateworks Ventana i.MX6 GW5903/GW5904, Zodiac Inflight Innovations RDU2 board, Engicam i.CoreM6 Quad/Dual OpenFrame modules, Boundary Device i.MX6 Quad Plus SoM ;
  • Texas Instruments – Motorola Droid4 (OMAP processor).

4.14

ARM

De nombreuses améliorations sur diverses plateformes ont été faites, dont le Raspberry Pi Zero W.

Pilote graphique

4.12

AMD

Ajout de la gestion des GPU AMD Radeon RX Vega

4.14

HDMI CEC sur RPI

Maintenant vous pouvez controler le RPI via votre lien HDMI et donc votre télécommande. Pratique pour le home cinema.

Virtualisation

KVM

Retour avec le noyau 4.14 du support des processeurs ne proposant pas d'interruption non-masquable (NMI) virtuelle (Core 2 DUO) qui avait disparu avec la version 4.12 (patch, source)

Xen

Prise en charge de la virtualisation d'un sous-ensemble des appels POSIX pour les conteneurs de type Docker. (patch, source)

À partir de la version 4.12, il est possible de compiler le noyau avec Xen sans para-virtualisation. (patch, source)

Prise en charge du système de fichiers 9P (documentation 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 toutes façons, 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 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 de diff. Et si 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 a 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 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 GPU, 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 : 4.9 reste la version la plus massive publiée, et 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 et 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, le tout a l'air assez normal : deux tiers concernent les pilotes (les GPU, 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 et 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 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 (GPU 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 (les GPU, le 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 bug).

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'adoucissent avant que je m'en aille pérégriner autour du monde.

Bien sûr, peut-être que tout sera encore plus calme que d'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 lesquel 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 — NdT : +0800 au lieu de -0700 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, GPU, 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 patches a l'air assez normale : le plus gros concerne comme d'habitude les pilotes (il se peut que les GPU 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 patch 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.(NdT : 1864 contributeurs et 14570 patches !).

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 patches, et en partie à cause de cela la partie « pilotes » domine tout le reste, à plus de 85 % des patches de cette version (il n'y a pas que les entê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 et 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 des 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 « mergelog » (journal des fusions) 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 du GPU d'AMD. Mais si 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 bugs, 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é -rc1 un jour plus tôt, j'imagine que rc2 doit être « un jour plus longue » 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 patches 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 fichier (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 à 21h45, 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 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 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 de amdgpu, un peu de SCSI, une mise à jour de 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 toutes façons, 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 et 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 à 01h14, heure de Paris).

Les choses progressent assez normalement. RC5 est plus petite que ne l'était 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 en 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 et 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 patch 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 consiste juste 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 patches. 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 à 23h47, heure de Paris.

La plupart des changements depuis 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 patches, 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'à 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 (NdT : git shortlog --no-merges v4.12..v4.13 [fichiers], 13006 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 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 correctifs : 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 dûe à 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 (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 des 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 une 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 de 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 SMB1 de toutes façons, ça ne devrait affecter personne. Mais vous savez quoi ? Ça affecte certainement des gens, puisqu'ils continuent joyeusement à utiliser SMB1 sans s'en soucier.

Et vous pourrez certainement continuer à utiliser SMB1, 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 SMB1.

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 SMB1, c'est vraiment, vraiment, vraiment mauvais.

De toutes façons, 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 patches 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 qu'on est un jour en avance et, oui, je réalise que si j'avais attendu jusqu'à demain, j'aurais aussi atteint le 26ème 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 dûes à une activité inhabituelle. Par exemple, du côté de la mémoire virtuelle sur x86, 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 à 5 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 à 5 niveaux s'est faite, par exemple.

Donc, 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érique, qui comme d'habitude forment le gros des patches. 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 de 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 firmwares.

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 patches 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 1500 auteurs individuels pour plus de 11500 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