URL: https://linuxfr.org/news/sortie-du-noyau-linux-4-5 Title: Sortie du noyau Linux 4.5 Authors: Collectif esdeem, Davy Defaud, Tiwaz, M5oul, BAud, jcr83, superna, Anonyme, rogo, Nils Ratusznik, palm123, Christophe Turbout, alpha_one_x86, Frédéric Massot, Brndan, Teromene, antistress, sylvainc_, kp, Benoît Sibaud, frederic, Ytterbium, patrick_g, dourouc05, Yves Bourguignon, claudex, romrom et gim Date: 2016年02月24日T13:15:33+01:00 License: CC By-SA Tags: noyau_linux, sortie_version, coulisses, linus_torvalds et lwn Score: 74 La sortie de la version stable 4.5 du noyau Linux a été annoncée le 13 mars 2016 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site [_kernel.org_](http://kernel.org/). Le détail des évolutions, nouveautés et prévisions se trouve dans la seconde partie de la dépêche (qui est sous [licence CC BY-SA](http://creativecommons.org/licenses/by-sa/3.0/deed.fr), Attribution — Partage dans les Mêmes Conditions). ---- [Dépêches des noyaux précédents](https://linuxfr.org/wiki/depeches_noyau) [Site officiel du noyau Linux](https://www.kernel.org/) [La liste des nouveautés sur Kernelnewbies.org](http://kernelnewbies.org/Linux_4.5) ---- #En bref # Annonces des RC par Linus Torvalds ## RC1 La version [RC1](https://lkml.org/lkml/2016/1/24/196) est sortie le dimanche 24 janvier 2016 : La fenêtre de fusion est close et la RC1 est là. Allez‐y, testez ! C’est une version relativement normale — ni anormalement grande, ni anormalement petite. Les statistiques sont également relativement normales, avec les pilotes un peu au-dessus de 70 % de l’ensemble (le gros des pilotes étant les pilotes graphiques, le réseau, le son, _staging_, fbdev, mais il y en a un peu partout). Le journal abrégé est trop gros et indigeste pour être joint au message ; mais, je joins mon « journal de fusion » qui crédite les mainteneurs avec lesquels j’ai effectué les fusions — mais pas nécessairement les personnes qui ont fait chacun des correctifs. Outre les pilotes, nous avons les mises à jour d’architectures (plus de la moitié d’entre elles étant pour ARM — 32 et 64 bits cette fois‐ci, le reste se composant des PowerPC, x86, MIPS, S390). Concernant les architectures, il est probablement utile de mentionner qu’apparemment, les gens d’ARM **(!)** ont finalisé leurs travaux sur la plate‐forme et que vous pouvez vraiment construire un noyau ARM générique pour toutes les plates‐formes ARMv6/7 (et décrire le matériel avec _devicetree_). Ça a pris de nombreuses années pour y arriver. Beau boulot. Il y a, évidemment, les habituelles mises à jour de documentation, de systèmes de fichiers, de réseau et celles du noyau de base. Un certain nombre de jolis nettoyages de MM sont venus d’Andrew cette fois‐ci, par exemple, et Al Viro a fait en sorte que les recherches de chemin (_pathname lookup_) restent en mode [RCU](https://en.wikipedia.org/wiki/Read-copy-update), même lors des traversées de chemins symboliques (_symlink traversal_). Il y en a un peu pour tout le monde. Linus ## RC2 La version [RC2](https://lkml.org/lkml/2016/1/31/231) est sortie le dimanche 31 janvier 2016 : Pas plus tard que vendredi, je comptais parler de combien il est agréable de voir cette nouvelle tendance de petites RC2, parce qu’il n’y avait vraiment pas eu beaucoup de demandes d’intégration. Mais il s’avère que les demandes d’intégrations étaient juste fortement décalées vers la fin de la semaine et que la 4.5-rc2 n’est pas particulièrement petite après tout. Elle a quasiment doublé dans le week-end. Ce n’est pas si gros que ça de toute façon et le décalage vers la fin de la semaine est probablement logique pour une RC2 — ça prend un certain temps pour commencer à trouver les problèmes que la fenêtre d'intégration a apportés. Ainsi, ce comportement bizarre ne m’inquiète pas : ça me parait assez naturel. Pour le type de corrections que nous avons ici, le journal abrégé donne plus de détails, mais il y en a un peu partout. Les mises à jour de pilotes et d’architectures représentent seulement la moitié environ des modifications, avec des correctifs de performance et de nouveaux auto-test de virtio représentant la plupart de ce qui reste. Il y a également des correctifs de btrfs. Rien de tout cela n’est vraiment important de toute façon. Allez‐y, testez. Linus ## RC3 La version [RC3](https://lkml.org/lkml/2016/2/7/266) est sortie le dimanche 7 février 2016 : C’est dimanche après-midi et tout est normal. Donc ça signifie qu’il y a une nouvelle RC pile dans les temps. Elle est légèrement plus grosse que j’aurais aimé, mais pas excessivement (ni même inhabituellement). La majorité des correctifs sont assez petits, bien que les modifications soient totalement dominées par la (grosse) suppression des pilotes RDMA en _staging_ qui n’allaient nulle part. Ces correctifs de suppression représentent 90 % du changement. Les 10 % restants sont constitués principalement des pilotes (réseau, pilotes graphiques, son, USB), et de divers autres choses (réseau de base, quelques correctifs VM d’Andrew, ceux des systèmes monopuces ARM, la crypto, etc.). Donc, ce n’est peut‐être pas une petite RC, mais il n’y a rien non plus de particulièrement inquiétant. Le journal abrégé est joint, pour les personnes qui veulent un aperçu plus détaillé. Linus ## RC4 La version [RC4](https://lkml.org/lkml/2016/2/14/173) est sortie le dimanche 14 février 2016 : C’est la Saint-Valentin, donc je prépare un cadeau pour tous, sous la forme d’une RC habituelle. Tout a l’air normal, il y a un problème en attente et non expliqué pour l’instant, avec des modifications concernant les VM dans cette version (en particulier le nettoyage transparent des _huge pages_), mais cela semble concerner uniquement l’architecture S390, donc cela ne devrait pas bloquer tout le monde. Et sinon tout semble normal. La taille est normale, comparée aux récentes RC4, et rien ne ressort en particulier. Un peu moins des 2/3 concerne les pilotes (DRM, son, SCSI, réseau... C’est assez réparti), et le reste est habituel : mises à jour d’architectures, (ARC, MIPS, ARM) et diverses choses (cryptographie, réseau et noyau...). Comme d’habitude, le journal abrégé est attaché, on peut le parcourir pour avoir une idée de ce qui se passe. Donc, à part vous occuper de votre chéri(e), vous pouvez y aller et tester. Je voyagerai la semaine prochaine, mais j’aurai mon ordinateur portable, et si les choses restent tranquilles et normales comme jusqu’ici, il ne devrait pas y avoir de problèmes. Linus ## RC5 La version [RC5](https://lkml.org/lkml/2016/2/20/168) est sortie le samedi 20 février 2016 : Tout continue à être normal et a été bien calme. D’accord, le nettoyage de la VM THP semble toujours poser problème sur S390, mais à part cela, je ne vois rien d’inquiétant. Une autre semaine, une autre RC. La modification a l’air tout à fait normale, avec 55 % de pilotes (DRM et _clk_ surtout, mais ils ne sont pas seuls) et presque 20 % de mises à jour d’architectures (ARM, m68k, PowerPC, S390, x86). Le reste est réparti entre systèmes de fichiers (ext4, EFI, CIFS), quelques mises à jour de noyau et en‐têtes de fichiers. Et des mises à jour de documentation. Tout a l’air normal. Le journal abrégé est joint. Linus ## RC6 La version [RC6](https://lkml.org/lkml/2016/2/28/207) est sortie le dimanche 28 février 2016 : J’aurais souhaité une RC-6 plus petite mais, en même temps, je suis plutôt soulagé que Kirill ait trouvé et corrigé le problème avec le nettoyage du code des THP qui nous avait frappé pendant ce cycle de publication. Donc, je ne peux pas vraiment me plaindre. S’ajoute à mon grand soulagement un autre rapport de bogue effrayant qui s’est avéré ne pas être du tout un bogue du noyau, mais un problème de microcode. Ce qui pourrait peut‐être être pire, mais au moins ce n’est pas quelque chose dont nous sommes responsables (et maintenant que c’est connu, c’est évitable). Les statistiques des changements paraissent bizarres cette fois, parce qu’il y a un gros correctif concernant les fichiers d’en‐tête des pilotes réseau, qui donne l’impression que le dossier des `include` représente quasiment 40 % des changements. Mais ce correctif ne fait que renommer une tonne de champs réservés, aucun code n’est effectivement modifié. Si l’on ignore cette bizarrerie statistique, tout semble plutôt normal : principalement des pilotes (le réseau et l’USB dominent, mais il y a également quelques modifications de pilotes graphiques, son, ACPI), avec les habituelles mises à jour d’architecture (ARC, ARM, x86) et un peu de réseau de base. Quelques travaux de performance et quelques corrections de systèmes de fichiers (NFS, [DAX](https://www.kernel.org/doc/Documentation/filesystems/dax.txt "Direct Access for files") et un peu de VFS de base). J’aimerais pouvoir dire que nous sommes sur la bonne voie pour respecter le calendrier habituel de publication, mais attendons de voir l’avancement la semaine prochaine. Si la RC-7 n’a pas commencé à diminuer, je pourrais décider finalement que cette version est l’une de celles où l’on fait aussi une RC-8. C’est trop tôt pour le dire. Il n’y a rien de particulièrement effrayant, mais j’aurais aimé une RC encore plus calme cette semaine. Le journal abrégé est joint, comme d’habitude, pour les personnes qui veulent un aperçu des détails. Linus ## RC7 La version [RC7](https://lkml.org/lkml/2016/3/6/195) est sortie le dimanche 6 mars 2016 : Les choses se sont calmées la semaine dernière et je pense que l’on aboutira à une version normale, où la RC-7 est la dernière RC. Bien sûr, je me réserve le droit de changer d’avis, au cas où nous trouverions quelque chose de fâcheux, mais dans l’ensemble, ça me paraît bien. Nous avons eu des changements plus importants que je n’aimerais à ce stade, mais ils concernaient pour la plupart des pilotes individuels. La plupart des modifications sont triviales, d’une ou deux lignes, avec peut‐être juste la couche bloc qui se distingue par de plus gros changements (et plus gros relativement au reste, pas particulièrement gros dans l’absolu). Les changements sont très épars, mais environ 3/4 touchent les pilotes (la suppression d’un pilote USB redondant représente le plus gros morceau, mais il y a un peu de tout, y compris des correctifs de compatibilité de son, de pilotes graphiques, _watchdog_, _libdata_, RDMA, etc.). Le reste correspond à des correctifs d’architectures (SPARC, x86, MIPS, ARM) et de systèmes de fichiers (JFFS, CIFS, Ceph, Btrfs, mais aussi un joli petit correctif dans le code de _dentry_ qui non seulement corrige un bogue, mais nettoie aussi pas mal de choses). Donc, allez‐y, testez, parce que nous devrions avoir pratiquement terminé à ce point pour cette version et les choses semblent aller très bien. Le journal abrégé est joint comme d’habitude, pour les personnes qui veulent des informations plus détaillées à propos des choses qui ont eu lieu cette semaine, Linus ## Version finale La version [finale](https://lkml.org/lkml/2016/3/14/50) est sortie le dimanche 13 mars 2016 : C’est un peu tard pour un dimanche, plus tard que mon horaire habituel, parce que je n’arrivais pas à décider si je devais faire une RC-8 ou pas et j’ai tergiversé à ce sujet. En fin de compte, j’ai évidemment décidé de publier, mais il aurait pu en être autrement. Nous avons eu une méchante régression qui a été réparée hier. Les dernières corrections de la couche réseau envoyées en début de semaine étaient plus grandes que je ne l’aurais souhaité. Mais la couche bloc devrait être parfaite maintenant. David a relu toute sa demande de modification de la couche réseau une nouvelle fois pour me rassurer à ce sujet. Donc, à la fin, je ne vois rien pour retarder ce cycle de sortie plus longtemps que d’habitude. Dans l’ensemble, tout semble plutôt petit. Le _diffstat_ paraît un peu plus gros pour un correctif de XFS, parce qu’il a trois correctifs de travail de nettoyage qui le précèdent. Il y a aussi un correctif de modèle de type d’accès **(?)** dans la couche son qui générait beaucoup de bruit, mais tout est très simple en fin de compte. En plus de ce qui précède, il y a de petits correctifs un peu partout — le journal abrégé est joint pour les gens qui veulent parcourir les détails, comme d’habitude. Allez‐y, testez. Et, évidemment, avec la publication de la 4.5, je vais ouvrir la fenêtre de fusion pour la 4.6. Linus # Les nouveautés ## Gestion de la mémoire ## Architecture ### Gestion d’énergie La gestion d’énergie du noyau est améliorée (et le sera davantage pour la prochaine version 4.6), grâce à une meilleure gestion du processeur graphique, de l’ACPI et du PCI express. Si vous aimez les chiffres et les jolies courbes, [_Phoronix_](https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.5-Quick-Power-Test) montre l’amélioration de la consommation, en milliwatts. En résumé, nous avons un gain moyen de 9 % pour la version 4.5 par rapport à la version 4.4 et, logiquement, la température globale baisse d’un même facteur. Des gains de 10 % à 12 % supplémentaires sont à attendre pour la version 4.6. ### ARM [SoC](https://fr.wikipedia.org/wiki/Système_sur_une_puce) #### Retravail massif des architectures ARM v6 et ARM v7 Ce travail est le résultat de cinq ans pour unifier les architectures ARM v6 et ARM v7 et permettre l’utilisation du même noyau. Cela fait suite au grand nettoyage et travail d’abstraction de la plate‐forme via la création de sous‐systèmes. Cela permet, entre autres, de faire démarrer différentes plates‐formes avec un seul et même noyau, alors que, jusqu’à présent, il était nécessaire d’avoir un noyau par plate‐forme. Référence : [_commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6b5a12dbca7a8681ecb78dbebaedc1f8364ebd10). ### En bref * prise en charge des processeurs [ARM Cortex-A9Tango4](http://www.sigmadesigns.com/news/sigma-designs-to-launch-new-arm-based-chipset-family-with-hevc-at-ces/), spécialisés pour les plates‐formes multimédia « sécurisées » de [Sigma Designs](http://www.sigmadesigns.com/) ; * prise en charge du [Broadcom BCM2836](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2836/) (système monopuce du Raspberry _Pi 2_) et de la gestion de puissance (_power management_) via le microcode interne ; * activation de `cpufreq` sur le Freescale i.MX7D ; * Rockchip : prise en charge du SMP pour le rk3036, prise en charge générale pour le rk3228 ; * prise en charge du SMP pour les systèmes monopuces Broadcom Kona et NSP ; * nettoyage du côté OMAP en supprimant l’ancien code IOMMU ; * ajout de la prise en charge de l’[Orange _Pi Plus_](http://www.orangepi.org/) (puce Allwinner). ### MIPS * Début de prise en charge du système monopuce à base de MIPS [Microchip PIC32MZDA](http://www.microchip.com.cn/community/html/university/plan_3_3/005.pdf), actuellement seulement le _Device Tree_, les pilotes viendront pour Linux 4.6 ; * prise en charge des structures _nvram_ pour BCM963xx ; * beaucoup de travail sur la prise en charge de la norme IEEE Std 754 (math-emu) ; * prise en charge du [MediaTek MT7621](https://wikidevi.com/wiki/MediaTek_MT7621). ---- ## Développement et traçage ###Prise en charge de l’option Sanitizer (`-fsanitize=undefined`) de GCC Cette option, disponible à partir de GCC 4.9, est un outil de débogage qui insère du code d’instrumentation durant la compilation. Ce code permet de faire des vérifications à l’exécution, et de prévenir en amont les comportements dits « indéfinis ». Désormais, le noyau 4.5 prend en charge l’activation de cette option. ### Introduction d’un nouvel appel système copy_file_range() Ce nouvel appel système [`copy_file_range()`](http://man7.org/linux/man-pages/man2/copy_file_range.2.html) permet de faire des copies « sans charge ». S’il n’apporte que peu d’avantage en local, ce nouvel appel permet, dans le cas de systèmes de fichiers réseau, d’effectuer la copie sans passer par le client dans le cas d’un transfert sur le même serveur. Par exemple, pour une copie en NFS, il peut éviter de faire transiter le flux du fichier sur le réseau. ## Pilotes graphiques libres ### AMD (pilotes amdgpu et radeon) #### Prise en charge expérimentale de PowerPlay La prise en charge expérimentale de PowerPlay apporte de meilleures performances au pilote _amdgpu_. Les cartes graphiques modernes démarrent en mode économie d’énergie et faible performance. Pour avoir les meilleures performances, la carte doit dynamiquement changer ses fréquences d’horloge. Linux 4.5 ajoute la prise en charge de la technologie PowerPlay dans le pilote _amdgpu_ pour les processeurs graphiques Tonga et Fiji, ainsi que pour les processeurs graphiques embarqués Carrizo et Stoney. PowerPlay est le nom commercial d’un ensemble de technologies de gestion de l’énergie réalisées dans plusieurs processeurs graphiques AMD. Il est disponible via le pilote propriétaire _Catalyst_ et a pour but de remplacer la gestion de l’énergie actuellement utilisée sous Linux dans le pilote _amdgpu_. Pour les processeurs graphiques ayant la possibilité de changer les fréquences d’horloge, les performances seront bien meilleures. PowerPlay n’est pas activé par défaut pour le matériel pris en charge, à cause de soucis de stabilité. Il est cependant activable en ajoutant l’option « `amdgpu.powerplay=1` » au démarrage. Voir : . ### Broadcom (pilote vc4 pour RPi) ### Intel (pilote i915) - ajout d’une prise en charge basique de _Kabylake_ ; - ajout de l’identificateur PCI pour le SKL GT4 ; - ajout de la prise en charge de DP MST (_Display Port Multi-Stream Transport_) côté processeur graphique, pour l’audio. ### NVIDIA (pilote nouveau) - prise en charge du changement de vitesse du PCI Express ; - suppression de l’interface _pstate_, ajout de _debugfs_ ; - améliorations diverses. ### Autres Ajout du pilote DRM _etnaviv_ pour cœur 3D basé sur Vivante, utilisé dans de nombreuses cartes ARM. ## Réseau ### Paramètres TCP keepalive configurables par espace de noms réseau Les paramètres réseaux par défaut (`tcp_keepalive_time`, `tcp_keepalive_intvl`, `tcp_keepalive_probes`) gérant les paquets TCP _keepalive_ sont maintenant configurables par espace de nommage réseau (_network namespace_) grâce à Nikolay Borisov ([[_1_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=13b287e8d1cad951634389f85b8c9b816bd3bb1e)], [[_2_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9bd6861bd4326e3afd3f14a9ec8a723771fb20bb)] et [[_3_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b840d15d39128d08ed4486085e5507d2617b9ae1)]). Les espaces de nommage réseau, dont les conteneurs sont friands, sont des copies de la pile réseau, avec leurs propres interfaces, routes, règles pare‐feu, mais aussi leurs propres paramètres réseaux accessibles par le pseudo‐système de fichiers `/proc`, par exemple. Pour rappel, le principe des paquets _keepalive_ est de détecter les déconnexions et de maintenir les connexions actives malgré les équipements réseau rencontrés (pare‐feu, NAT...). Ainsi, lorsqu’un _socket_ est configuré avec l’option `SO_KEEPALIVE`, ce qui n’est pas le cas par défaut, un chronomètre est activé à chaque réception de paquet. Après une certaine durée — `tcp_keepalive_time` — sans avoir reçu de nouveau paquet de l’hôte distant, un paquet sonde _keepalive_ est émis, afin de solliciter une réponse. Sans réponse, de nouveaux paquets sondes _keepalive_ sont réémis à intervalle de temps régulier `tcp_keepalive_intvl`. Passé un certain nombre d’essais `tcp_keepalive_probes`, la connectivité est considérée comme perdue si aucun paquet n’a été reçu. ### Ajout des compteurs paquets/octets au module Netfilter nft_ct Les expressions de suivi de connexion `ct` (_conntrack_) dans les règles _nftables_ acceptent maintenant deux paramètres supplémentaires, `packets` et `bytes`, qui permettent par exemple de filtrer les connexions « suivies » respectivement par nombre de paquets ou par nombre d’octets échangés. Si la direction (`original` ou `reply`) n’est pas précisée, ces compteurs représentent la somme des valeurs dans les deux sens. Amélioration proposée par Florian Westphal [[_1_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=48f66c905a976bf0ff092fc24f08d9addd82a24)]. ## Sécurité ## Périphériques en mode bloc (block devices) Correction pour la couche MD (dont le mainteneur quitte son rôle de mainteneur) pour la prise en charge des horodatages de 64 bits pour le bogue de l’année 2038. Amélioration de la stabilité de BCache pour former une sorte de disque hybride à partir d’un SSD et d’un disque rotatif. Diverses améliorations sur l’implémentation des normes [NVM Express (NVMe)](https://en.wikipedia.org/wiki/NVM_Express) et lightNVM, qui sont bien plus adaptées pour le transfert vers les disques non‐rotatifs comme les SSD. ## Systèmes de fichiers ### Btrfs Une nouvelle gestion du système de cache de l’espace libre permet d’être plus performant. Cela se ressent surtout sur les larges volumes de plus de 30 Tio. Cette fonctionnalité peut être testée via l’option « `space_cache=v2` ». ### ext4 Diverses corrections, surtout autour du chiffrement, ont été récemment ajoutées. Ajout du projet de quota. ## Virtualisation Il y a peu de changements avec cette version. Espérons que ça nous réserve de plus grands changements pour la suite. ### KVM ####S390 Prise en charge du _runtime instrumentation_ pour les invités. Cela permet de faciliter le traçage et le débogage d’applications. Cela est utilisé par des outils comme Valgrind. Un invité peut maintenant avoir 248 processeurs virtuels. ####ARM Réécriture du _world switch_ de l’architecture ARM64 en C. Prise en charge des identifiants de machine virtuelle sur 16 bits. Les compteurs de performances de la virtualisation devaient être introduits avec cette version, mais ils ont raté la fenêtre de fusion. ####x86 Introduction de nouvelles fonctionnalités Hyper-V (_synthetic interrupt controller_, un des blocs du bus des périphériques paravirtualisés), nettoyage du code des MMU. ## Cgroups **Stabilisation de l’unification de la hiérarchie des _cgroups_** : Les _cgroups_, introduits depuis le noyau 2.6.24, ont été retravaillés pour obtenir une nouvelle implémentation disponible depuis le noyau 3.16. Cette nouvelle version n’était disponible jusqu’à présent que via une option de montage spécifique (`-o DEVEL_sane_behavior`), attestant de son caractère expérimental. Ce code est considéré comme suffisamment stable pour être désormais exposé plus directement, via le type de système de fichiers [_cgroup2_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/cgroup-v2.txt), montable directement sans option spécifique. # Le bilan en chiffres Selon le site [_LWN.net_](http://lwn.net/Articles/678567/), l’article de Jonathan Corbet indique que cette version 4.5 a impliqué 1 528 développeurs, alors que pour la version 4.4, il y en avait eu 1 575. ![Nombre de lignes par entreprise](http://damballa.alwaysdata.net/line_by_user_kernel45.png) Pour cette version 4.5, la palme du développeur le plus actif a été remportée par Linus Walleij, si l’on s’appuie sur le nombre de _commits_ (236 *changesets*), ou par Doug Ledford, si l’on s’appuie sur le nombre de lignes modifiées (53 086 lignes). ![Nombre de lignes par entreprise](http://damballa.alwaysdata.net/line_by_society_kernel45.png) Si l’on se réfère aux entreprises impliquées dans le noyau, Intel l’emporte haut la main, notamment devant Red Hat, Linaro, Samsung et AMD, en nombre de _commits_, même si Red Hat est premier d’une courte tête en nombre de lignes modifiées. # Systématisation du choix du noyau destiné à être maintenu à long terme L’annonce a été faite durant ce cycle : dorénavant le premier noyau à sortir chaque année sera automatiquement désigné comme étant la version LTS annuelle, comme développé dans [ce journal](https://linuxfr.org/users/patrick_g/journaux/des-noyaux-linux-lts-au-debut-de-chaque-annee). # Appel à volontaires Cette dépêche a nécessité plus de 410 éditions (à l’heure de l’écriture de ces statistiques), et mobilisé 23 personnes du 24 février 2016 au 13 avril 2016 dans l’espace de rédaction. **Graphe** Cette dépêche est rédigée par plusieurs contributeurs, dont voici la répartition : ![Répartition des modifications par utilisateur](http://damballa.alwaysdata.net/people_linuxfr_kernel45.png) | | Mainteneur | Contributeur(s) ----------------------------- | -------------------------------------------------- | --------------- **En bref** | Aucun | [rogo](//linuxfr.org/users/rogo)| **La phase de test** | Aucun | Aucun | **Arch** | Aucun | [Tiwaz](//linuxfr.org/users/tiwaz) | **IPC** | Aucun | [ariasuni](//linuxfr.org/users/sinma) | **Développement** | Aucun | [rogo](//linuxfr.org/users/rogo)| **Pilotes graphiques libres** | [Martin Peres](//linuxfr.org/users/mupuf) | Aucun | **Réseau** | Aucun | [Florent Fourcot](//linuxfr.org/users/ffourcot), [Tiwaz](//linuxfr.org/users/tiwaz) | **Block devices** | Aucun | [rogo](//linuxfr.org/users/rogo)| **Systèmes de fichiers** | Aucun | [ariasuni](//linuxfr.org/users/sinma)| **Sécurité** | Aucun | [rogo](//linuxfr.org/users/rogo)| **Virtualisation** | [Xavier Claude](//linuxfr.org/users/claudex) | Aucun | **Édition générale** | Aucun | [jcr83](//linuxfr.org/users/jcr83), [Moul](//linuxfr.org/users/m5oul), [eggman](//linuxfr.org/users/eggman)| Un peu de vocabulaire : * le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie, il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer ; * un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche, sans aucune forme d’engagement pour le futur. Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps et de volontaires.>Nous sommes particulièrement à la recherche de mainteneurs pour les sections Systèmes de fichiers, Réseau, Développement et IPC les précédents n’ayant pas donné de signes de vie pendant la rédaction des dernières dépêches. Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les _commits_ intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau ! C’est un travail à faire au fil du temps, par ajouts successifs (une simple adresse URL ou un paragraphe enrichissent déjà le contenu et les sources), n’hésitez pas !

AltStyle によって変換されたページ (->オリジナル) /