tag:linuxfr.org,2005:/users/jcr83LinuxFr.org : les contenus de jcr832016-04-24T17:07:11+02:00/favicon.pngtag:linuxfr.org,2005:News/368762016-02-18T21:48:28+01:002016-02-20T16:22:44+01:00Sortie du noyau Linux 4.4Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>La sortie de la version stable 4.4 LTS du noyau Linux a été annoncée le 10 janvier 2016 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site <a href="http://kernel.org/"><em>kernel.org</em></a>.</p>
<p>Le détail des évolutions, nouveautés et prévisions se trouve dans la seconde partie de la dépêche (qui est sous <a href="http://creativecommons.org/licenses/by-sa/3.0/deed.fr">licence CC BY-SA</a>, Attribution — Partage dans les Mêmes Conditions)</p></div><ul><li>lien nᵒ 1 : <a title="https://linuxfr.org/wiki/depeches_noyau" hreflang="fr" href="https://linuxfr.org/redirect/95593">Dépêches des noyaux précédents</a></li><li>lien nᵒ 2 : <a title="https://www.kernel.org/" hreflang="en" href="https://linuxfr.org/redirect/95594"> Site officiel du noyau Linux</a></li><li>lien nᵒ 3 : <a title="http://www.heise.de/open/artikel/Die-Neuerungen-von-Linux-4-4-3053832.html" hreflang="de" href="https://linuxfr.org/redirect/96406">Die Neuerungen von Linux 4.4</a></li></ul><div><h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li><a href="#en-bref">En bref</a></li>
<li>
<a href="#annonces-des-rc-par-linus-torvalds">Annonces des RC par Linus Torvalds</a><ul>
<li><a href="#rc-1">RC-1</a></li>
<li><a href="#rc-2">RC-2</a></li>
<li><a href="#rc-3">RC-3</a></li>
<li><a href="#rc-4">RC-4</a></li>
<li><a href="#rc-5">RC-5</a></li>
<li><a href="#rc-6">RC-6</a></li>
<li><a href="#rc-7">RC-7</a></li>
<li><a href="#rc-8">RC-8</a></li>
<li><a href="#version-finale">Version finale</a></li>
</ul>
</li>
<li>
<a href="#les-nouveaut%C3%A9s">Les nouveautés</a><ul>
<li><a href="#gestion-de-la-m%C3%A9moire">Gestion de la mémoire</a></li>
<li>
<a href="#architecture">Architecture</a><ul>
<li>
<a href="#arm-soc">ARM </a><a href="https://fr.wikipedia.org/wiki/Syst%C3%A8me_sur_une_puce">SoC</a>
</li>
<li><a href="#mips">MIPS</a></li>
</ul>
</li>
<li><a href="#d%C3%A9veloppement-et-tra%C3%A7age">Développement et traçage</a></li>
<li>
<a href="#pilotes-graphiques-libres">Pilotes graphiques libres</a><ul>
<li><a href="#direct-rendering-manager">Direct Rendering Manager</a></li>
<li><a href="#amd-pilotes-amdgpu-et-radeon">AMD (pilotes amdgpu et radeon)</a></li>
<li><a href="#broadcom-pilote-vc4-rpi">Broadcom (pilote vc4, RPi)</a></li>
<li><a href="#intel-pilote-i915">Intel (pilote i915)</a></li>
<li><a href="#nvidia-pilote-nouveau">NVIDIA (pilote nouveau)</a></li>
<li><a href="#autres">Autres</a></li>
</ul>
</li>
<li>
<a href="#r%C3%A9seau">Réseau</a><ul>
<li><a href="#optimisation-de-la-poign%C3%A9e-de-main-tcp">Optimisation de la poignée de main TCP</a></li>
<li><a href="#encore-plus-rapide-avec-so_reuseport">Encore plus rapide avec SO_REUSEPORT</a></li>
<li><a href="#et-si-on-ajoutait-la-gestion-fine-de-cpu">Et si on ajoutait la gestion fine de CPU ?</a></li>
<li><a href="#nouvelles-m%C3%A9thodes-de-d%C3%A9tection-de-pertes-de-paquets">Nouvelles méthodes de détection de pertes de paquets</a></li>
<li><a href="#passage-%C3%A0-la-micro-seconde-pour-le-temps-de-transmission-durant-la-poign%C3%A9e-de-main-tcp">Passage à la micro-seconde pour le temps de transmission durant la poignée de main TCP</a></li>
<li><a href="#du-changement-dans-les-routes-%C3%A0-chemins-multiples-en-ipv4">Du changement dans les routes à chemins multiples en IPv4</a></li>
<li>
<a href="#en-bref-1">En bref</a><ul>
<li><a href="#licmp-avec-ipvs">L’ICMP avec IPVS</a></li>
<li><a href="#les-vrf-fonctionnent-d%C3%A9sormais-en-ipv6">Les VRF fonctionnent désormais en IPv6</a></li>
<li><a href="#identifiant-de-la-table-fib-en-ipv4">Identifiant de la table FIB en IPv4</a></li>
<li><a href="#les-tunnels-geneve-en-ipv6">Les tunnels Geneve en IPv6</a></li>
<li><a href="#plusieurs-chemins-en-mpls">Plusieurs chemins en MPLS</a></li>
<li><a href="#des-informations-sur-les-ponts-bridges-via-linterface-netlink">Des informations sur les ponts (bridges) via l’interface Netlink</a></li>
<li><a href="#des-applications-persistantes-pour-bpf">Des applications persistantes pour BPF</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#s%C3%A9curit%C3%A9">Sécurité</a></li>
<li>
<a href="#p%C3%A9riph%C3%A9riques-en-mode-bloc-block-devices">Périphériques en mode bloc (block devices)</a><ul>
<li><a href="#lecture-sans-interruption-et-polling">Lecture sans interruption et <em>polling</em></a></li>
<li><a href="#montage-loop">Montage <em>loop</em></a></li>
</ul>
</li>
<li>
<a href="#syst%C3%A8mes-de-fichiers">Systèmes de fichiers</a><ul>
<li><a href="#f2fs">F2FS</a></li>
<li><a href="#btrfs">Btrfs</a></li>
<li><a href="#ext4">Ext4</a></li>
</ul>
</li>
<li>
<a href="#virtualisation">Virtualisation</a><ul>
<li>
<a href="#kvm">KVM</a><ul>
<li><a href="#s390">s390</a></li>
<li><a href="#ppc">PPC</a></li>
<li><a href="#arm">ARM</a></li>
<li><a href="#x86">x86</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#cgroups">Cgroups</a></li>
</ul>
</li>
<li><a href="#le-bilan-en-chiffres">Le bilan en chiffres</a></li>
<li><a href="#appel-%C3%A0-volontaires">Appel à volontaires</a></li>
</ul><h2 id="en-bref">En bref</h2>
<ul>
<li><p>Au terme de deux années d’efforts, le code gérant TCP a été réorganisé, procurant une implémentation de bien meilleure qualité, avec des gains de performances pouvant dépasser 100 fois dans certains scénarios de serveurs TCP.</p></li>
<li><p>Un nouveau <a href="#lecture-sans-interruption-et-polling">mécanisme d’entrée/sortie</a> fait son apparition. S’il est encore expérimental et désactivé par défaut, il pourrait à terme compléter le mode de lecture des périphériques en mode bloc, en permettant une lecture séquentielle à plus haut débit.</p></li>
<li><p>Le mécanisme <a href="https://fr.wikipedia.org/wiki/BSD%20Packet%20Filter" title="Définition Wikipédia">BSD Packet Filter</a> du noyau a connu plusieurs évolutions importantes. Le principal changement est l’ouverture partielle de l’API aux programmes non privilégiés ; un code en espace utilisateur peut désormais utiliser l’appel système <code>bpf()</code> pour placer un filtre sur un socket. Ce nouveau noyau permet aussi de créer des filtres persistants, c’est-à-dire, qui peuvent être conservés malgré l’arrêt du processus, puis repris par un nouveau processus. Enfin, ce système eBPF a été intégré à perf, l’outil de mesure des performances interne à Linux.</p></li>
<li><p>Les utilisateurs de partitions ext4 <strong>chiffrées</strong> sont <a href="#ext4">encouragés</a> à passer à Linux 4.4 ou à utiliser des noyaux dans lesquels les corrections ont été rétro-portées : un bug menant à une corruption de données a été corrigé, ainsi qu’une fuite de mémoire.</p></li>
<li><p>Comme d’habitude, la grande majorité des <em>commits</em> est consacrée aux pilotes de matériel, tant pour améliorer la gestion de l’existant (portables Toshiba, etc.) que pour accepter de nouveaux matériels (nouvelle puce Realtek WiFi USB, Intel Skylake W8 touchpad, etc).</p></li>
</ul><h2 id="annonces-des-rc-par-linus-torvalds">Annonces des RC par Linus Torvalds</h2>
<h3 id="rc-1">RC-1</h3>
<p>La version <a href="https://lkml.org/lkml/2015/11/15/168">RC-1</a> est sortie le dimanche 15 novembre 2015 :</p>
<p>C’est dimanche, deux semaines sont passées et par conséquent, la 4.4-RC1 est parue et la fenêtre de fusion fermée.</p>
<p>Comme d’habitude, l’historique complet des changements est trop important pour être publié, vous trouverez donc en annexe le journal des fusions montrant l’origine des intégrations avec un petit commentaire sur chaque fusion.</p>
<p>Si on regarde l’ensemble des modifications en elles-mêmes, tout semble plutôt normal d’un point de vue général, même si les pilotes représentent peut-être une plus grosse part que d’habitude (75 % des correctifs) et les mises à jour d’architectures environ 10 %. Les 15 % restants se répartissent entre la documentation, les systèmes de fichiers, le cœur du réseau (par opposition aux pilotes réseau), l’outillage et les infrastructures cœur.</p>
<p>Les changements sur les pilotes sont partout, bien que les pilotes de préproduction, de réseau et de GPU ressortent (et ces trois parties comptent pour plus de la moitié des changements sur les pilotes – aux alentours de 40 % de l’ensemble des changements).<br>
Du côté des architectures, l’ARM (en prenant en compte le 32 et le 64 bits) compte pour à peu près la moitié des changements, alors que x86, PowerPC, MIPS, chris et S390 comptent pour l’autre moitié.</p>
<p>Allez-y, testez.</p>
<p>Linus</p>
<h3 id="rc-2">RC-2</h3>
<p>La version <a href="https://lkml.org/lkml/2015/11/22/207">RC-2</a> est sortie le dimanche 22 novembre 2015 :</p>
<p>Tout semble plutôt normal du côté de la 4.4 sans grosses surprises dans la RC-2. Il y a eu quelques ajouts tardifs de fonctionnalités : la prise en charge des <em>hugepages</em> sur <a href="https://fr.wikipedia.org/wiki/PA-RISC">PA-RISC</a> et quelques corrections concernant l’allocateur mémoire noyau <a href="http://en.wikipedia.org/wiki/SLUB_(software)">slub</a> ont seulement été fusionnées à la fin de cette semaine, mais à vrai dire, elles auraient dû faire partie de la fenêtre de fusion.</p>
<p>Mais le système d’allocation mémoire de masse n’est pas encore vraiment <em>utilisé</em> dans l’arborescence et donc, les mises à jour de ce côté portent sur une utilisation future plutôt que sur quelque chose qui pourrait régresser. Quant à PA-RISC, je n’arrive pas à trouver une raison de m’en inquiéter : je mets volontiers au défi tout utilisateur de PA-RISC de me prouver le contraire et de montrer comment la nouvelle fonctionnalité provoque une régression.<br>
Amenez-vous pour voir. </p>
<p>Le gros des changements depuis la rc-1 (de loin) se situe dans les pilotes (environ 70 % de correctifs — les pilotes réseau et GPU en représentant la plus grande part), avec des mises à jour d’architecture (12 %, avec PA-RISC et S390 étant les deux plus grosses mises à jour) et la base réseau (8 %) étant l’essentiel du reste. Les 10 % restants sont dispersés ; fs (systèmes de fichiers), mm (gestion de la mémoire) et les outils de performance en représentant la plus grande part.</p>
<p>Le journal abrégé est joint. Vous pouvez y voir un aperçu des changements. Je ne peux pas vraiment dire qu’il en ressorte quelque chose de particulier.</p>
<p>Allez-y, testez.<br>
Linus</p>
<h3 id="rc-3">RC-3</h3>
<p>La version <a href="https://lkml.org/lkml/2015/11/29/293">RC-3</a> est sortie le dimanche 29 novembre 2015 :</p>
<p>Je suis sorti presque toute la journée, donc, elle arrive quelques heures plus tard que d’habitude, mais elle est là, la RC hebdomadaire usuelle. « Progrès constant vers la 4.4 ».</p>
<p>Les changements semblent plutôt normaux : un peu moins de 60 % de mise à jour de pilotes (parmi lesquels près de la moitié sont des mises à jour de GPU, cette fois principalement biaisé par des correctifs de mises à jour des firmwares <em>nouveau</em>), environ 25 % de mises à jour d’architectures (principalement arm[64], mais aussi quelques changements dans x86, s390, powerpc, nios, mips, m68k, <a href="https://www.synopsys.com/dw/ipdir.php?ds=sw_linux">arc</a>…) et environ 10 % de mises à jour de systèmes de fichiers. Le reste étant « divers » (principalement des fichiers d’en-tête).</p>
<p>Le journal abrégé ci-joint donne un aperçu des détails. Je ne pense pas qu’il y ait grand-chose d’enthousiasmant, bien que cela dépende évidemment du fait que vous ayez été affecté par un problème particulier, ou pas. Il est constitué principalement de petites corrections diverses.</p>
<p>Linus</p>
<h3 id="rc-4">RC-4</h3>
<p>La version <a href="https://lkml.org/lkml/2015/12/6/137">RC-4</a> est sortie le dimanche 6 décembre 2015 :</p>
<p>Une nouvelle semaine, une nouvelle rc. Nous avons eu un peu plus de <em>commits</em> que la semaine dernière (principalement dus à la fusion des correctifs réseau), mais dans l’ensemble, ça a été plutôt calme.</p>
<p>Tout semble plutôt normal : environ 70 % de pilotes – les pilotes réseau, gpu, audio, et scsi dominent. De surcroît, nous avons 15 % de cœur de réseau et le reste est partagé entre mises à jour d’architectures et choses diverses un peu partout (dont quelques correctifs vfs et cœur du noyau).</p>
<p>Le journal abrégé en annexe donne une vue d’ensemble des détails, il est suffisamment petit pour qu’on puisse facilement le lire en diagonale.</p>
<p>Linus</p>
<h3 id="rc-5">RC-5</h3>
<p>La version <a href="https://lkml.org/lkml/2015/12/13/228">RC-5</a> est sortie le dimanche 13 décembre 2015 :</p>
<p>Une nouvelle semaine, une nouvelle rc. </p>
<p>La semaine a été plutôt tranquille et la RC-5 a l’air plutôt normale. Il y a eu un assez méchant bug primordial, introduit dans la RC-4, qui est désormais corrigé dans la RC-5, mais bien que cela soit un peu gênant, je ne crois pas que beaucoup de personnes aient rencontré le problème.</p>
<p>Mis à part ce petit problème, les choses sont tout à fait normales et il n’y a vraiment pas beaucoup de changements, et ils sont tous assez petits pour démarrer.</p>
<p>Donc, tout semble bon, et je pense que nous sommes sur la bonne voie pour le calendrier de sortie habituel, ce qui devrait nous amener à une version 4.4 très tôt en 2016. Je suis enclin à retarder cette version d’une semaine non pas à cause des problèmes de parution, mais tout simplement parce que je sais que les prochaines semaines vont être calmes et la plupart des gens veulent se concentrer sur autre chose que de se préparer pour la prochaine fenêtre de fusion.</p>
<p>On verra. Je devrais en finir et sortir la 4.4 à temps et ensuite décaler la fenêtre de fusion.</p>
<p>Quoi qu’il en soit, si vous avez tous finalisé vos achats de Noël, je recommande chaudement de s’intéresser de près à la RC-5 entre les cadeaux et la décoration. Et si vous ne célébrez pas les fêtes, vous n’avez aucune excuse pour ne pas tester tout ça.</p>
<p>Linus</p>
<h3 id="rc-6">RC-6</h3>
<p>La version <a href="https://lkml.org/lkml/2015/12/20/193">RC-6</a> est sortie le dimanche 20 décembre 2015 :</p>
<p>Tout continue normalement. Si la RC-5 de la semaine dernière était effectivement très petite, la RC-6, cette semaine, est un peu plus grosse. La principale différence est que la RC-6 intègre un changement réseau.</p>
<p>Mais, la RC-6 est toujours aussi petite, et les correctifs sont normaux : au-delà de 60 % pour les pilotes, 16 % pour le cœur de la gestion réseau, 13 % pour des mises à jour d’architectures et 10 % pour des choses diverses (de la documentation, des en-têtes de fichiers, de petites mises à jour du système de fichiers, etc.). Vous pouvez consulter les changements joints pour avoir une idée de ce qu’il s’est passé.</p>
<p>Je pense (et j’espère) qu’avec les vacances, la semaine prochaine continuera à être calme.</p>
<p>Et peut-être, je peux espérer que les gens utilisent la coupure pour jouer avec leur matériel et tester la plus récente version du noyau.<br>
Linus</p>
<h3 id="rc-7">RC-7</h3>
<p>La version <a href="https://lkml.org/lkml/2015/12/27/215">RC-7</a> est sortie le dimanche 27 décembre 2015 :</p>
<p>Noël est fini, et voilà le Nouvel An, mais il n’y a pas de repos pour les développeurs noyau, et la RC-7 est par là. [En regardant le patch RC-7]</p>
<p>OK, clairement il y a un peu de repos pour les développeurs noyau, car la rc7 est plutôt minuscule. Je pense qu’un tiers du patch provient des mises à jour de SPARC, et ils ne sont pas énormes non plus.</p>
<p>Le reste provient des autres architectures (x86, PA-RISC, MIPS, ARM, arc), des pilotes (gpu, sound, mtd…) et quelques mises à jour pour compiler. Mais tout est plutôt petit.</p>
<p>J’espère la même chose la semaine prochaine, quand je serai certainement prêt à publier la 4.4 finale, mais je vais probablement faire une RC-8 juste pour ne pas ouvrir la fenêtre de fusion alors que les gens sont toujours en vacances.</p>
<p>Linus</p>
<h3 id="rc-8">RC-8</h3>
<p>La version <a href="https://lkml.org/lkml/2016/1/3/261">RC-8</a> est sortie le dimanche 3 janvier 2016 :</p>
<p>En général, lorsque je fais une huitième RC, c’est qu’il reste un problème non résolu qui nécessite plus de temps pour être réglé. Cette fois, c’est seulement que je veux être certain que tout le monde est rentré de vacances et qu’il ne reste rien en cours, et que tous auront le temps de préparer leurs demandes d’intégration pour la prochaine fenêtre. Vous n’aurez aucune excuse si vous n’avez pas terminé vos travaux lorsque la fenêtre d’intégration s’ouvrira.</p>
<p>Les changements se trouvent dans les endroits habituels, et sont plutôt petits. On y trouve pour moitié des pilotes (principalement des pilotes de réseau, mais aussi du rdma et quelques autres changements mineurs) et pour le reste des mises à jour d’architectures (surtout SPARC, ARM), du code réseau et quelques corrections dans la cryptographie.</p>
<p>Mais c’est vraiment très petit. C’est bien comme ça que ça doit être, avec les vacances et la fin du cycle.</p>
<p>Attendez-vous à la sortie de la version 4.4 finale le week-end prochain, sauf si quelque chose de très inattendu survient.</p>
<p>Linus</p>
<h3 id="version-finale">Version finale</h3>
<p>La version <a href="https://lkml.org/lkml/2016/1/10/305">finale</a> est sortie le dimanche 10 janvier 2016 :</p>
<p>Rien de fâcheux n’est arrivé cette semaine, donc Linux-4.4 est disponible dans tous les endroits habituels.</p>
<p>Les changements depuis la RC-8 ne sont pas énormes. Il y a environ un tiers de mises à jour d’architectures, un tiers de pilotes et un tiers « divers » (principalement du cœur de noyau et du réseau), mais c’est tout petit.</p>
<p>Ce qui serait notable comprend la remise en état de l’ABI <em>sysenter</em> pour x86-32, que quelqu’un (<em>tousse*android-x86*tousse</em>) a mal utilisé en ne recourant pas au <a href="https://en.wikipedia.org/wiki/VDSO">vdso</a> et utilisant cette instruction à la place.</p>
<p>L’historique complet est annexé pour les personnes intéressées ou simplement curieuses.<br>
Et avec ça, la fenêtre de fusion pour la 4.5 est évidemment ouverte, même si je ne vais pas vraiment commencer l’intégration demain.</p>
<p>Linus</p>
<h2 id="les-nouveautés">Les nouveautés</h2>
<h3 id="gestion-de-la-mémoire">Gestion de la mémoire</h3>
<p>L’appel système <code>mlock()</code> permet de verrouiller en mémoire une zone d’adressage d’un programme qui contient des données cruciales (cryptographie, etc). Mais en pratique, ce verrou est parfois excessif, car on bloque une large zone de mémoire dont on ne se sert que très partiellement. Le noyau 4.4 introduit <code>mlock2()</code> qui permet des verrous reportés (<em>deferred memory locking</em>). Cette gestion plus fine de la mémoire permettra donc de diminuer certaines consommations de mémoire. Pour plus d’informations, voir la nouvelle page de <a href="http://man7.org/linux/man-pages/man2/mlock.2.html">man mlock</a> et <a href="http://lwn.net/Articles/650538/">(LWN) Deferred memory locking</a>.</p>
<p>Une autre modification structurelle a permis de nettoyer le code d’allocation de la mémoire. La structure <code>zonelist_cache</code>, introduite en 2006, était une source récurrente de problèmes, notamment sur les architectures <a href="http://fr.wikipedia.org/wiki/Non_Uniform_Memory_Access">NUMA</a>. Plutôt que de continuer à accumuler des aménagements sur ce code, une réécriture a permis de supprimer cet élément, avec performance <a href="https://lkml.org/lkml/headers/2015/9/21/204">généralement inchangée</a>, voire meilleure. Ce n’est pas souvent qu’on retire 240 lignes de code du noyau. </p>
<p>Pour plus de détails, lire l´article de LWN : <a href="http://lwn.net/Articles/658081/">Some kernel memory-allocation improvements</a>.</p>
<h3 id="architecture">Architecture</h3>
<h4 id="arm-soc">ARM <a href="https://fr.wikipedia.org/wiki/Syst%C3%A8me_sur_une_puce">SoC</a>
</h4>
<ul>
<li><p><a href="https://www.raspberrypi.org/">Raspberry Pi</a> : ajout d´un pilote pour communiquer avec le firmware, voir <a href="//linuxfr.org/news/sortie-du-noyau-linux-4-4#broadcom-pilote-vc4-rpi">plus loin</a> pour plus de détails.</p></li>
<li><p><a href="http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-processors-based-on-arm-cores/i.mx-6-processors/i.mx6qp/i.mx-6ultralite-processor-low-power-secure-arm-cortex-a7-core:i.MX6UL">i.MX6PU</a> : <a href="http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/361877.html">ajout</a> de la prise en charge du mode veille (<em>suspend/resume</em>) de ce SoC de Freescale.</p></li>
<li><p><a href="http://getchip.com/">C.H.I.P</a> : <a href="http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/371072.html">intégration</a> de la prise en charge du chipset Allwinner R8 présent dans cette carte. Il manque encore la gestion du Wifi (dépendante de deux régulateurs pour être alimenté) et du codec audio qui n’est pas encore activé dans le DeviceTree.</p></li>
<li><p>ARM SCPI : ajout d´un pilote pour le SCPI (Système de contrôle du Processeur), un système utilisé pour communiquer avec le système embarqué de gestion de consommation.</p></li>
<li><p>Rockchip RK3288 : <a href="https://lkml.org/lkml/2015/8/12/12">ajout</a> des domaines de puissance (Power Domain) compatible avec le module <code>genpd</code> qui permet de contrôler chaque domaine et de couper le courant de manière dynamique si le module n’est plus utilisé ou en veille.</p></li>
<li><p>Divers : prise en charge du <a href="https://lkml.org/lkml/2015/7/7/86">changement de CPU à chaud</a> pour la série des BG2Q de Marvell berlin, et du <a href="http://lists.infradead.org/pipermail/linux-mediatek/2015-August/001886.html">SMP</a> pour les 4 cœurs Cortex-A7 du SoC Mediatek MT6580. <a href="https://lkml.org/lkml/2015/8/26/732">Prise en charge initiale</a> de la famille de SoC Northstar Plus de Broadcom à base de Cortex-A9.</p></li>
<li><p>Plusieurs mises à <a href="https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.4-ARM64-Coming">jour ARM64</a>, comme une meilleure détection des fonctionnalités des cœurs ARM64 (en particulier sur des systèmes hétérogènes.), une implémentation native de fonctions atomiques et une optimisation des fonctions natives de copie depuis/vers l’espace utilisateur, ainsi qu’une mutualisation du code de gestion des compteurs de performance matériels (PMU) entre arm et arm64.</p></li>
<li><p>L’architecture <strong>arm64</strong> peut maintenant fonctionner avec des pages de taille 16 Kio. Cependant, <a href="https://lwn.net/Articles/663941">Linus a émis de sérieux doutes</a> quant à son utilité dans le monde réel. Petite explication : l’argument en faveur d’une taille de page de 16 Kio est de pouvoir gérer plus de mémoire. Sauf qu’avec cette taille de page, vous perdez beaucoup de mémoire et augmentez la fragmentation. Cela a déjà été évoqué il y a quelques années par les personnes s’occupant de l’architecture PPC. Excepté dans des cas très spécifiques (un seul processus qui a besoin de beaucoup de mémoire et très peu de processus en parallèle), cet apport n’a que peu d’intérêt.</p></li>
</ul><h4 id="mips">MIPS</h4>
<ul>
<li>Support du programme universitaire <a href="http://blog.imgtec.com/mips-processors/mipsfpga-opens-up-the-mips-architecture-to-universities-worldwide">MIPSfpga</a> qui permet aux universités du monde entier d’intégrer gratuitement un cœur <a href="https://fr.wikipedia.org/wiki/Architecture_MIPS">MIPS</a> dans leurs projets ;</li>
<li>Grosse évolution et nettoyage du code de démarrage <a href="https://fr.wikipedia.org/wiki/Architecture_MIPS">MIPS</a> qui tend à supporter le <a href="https://en.wikipedia.org/wiki/Device_tree">Device Tree</a> aussi bien que son homologue ARM ;</li>
<li>Ajout du support d’un nouveau cœur de test <a href="https://www.linux-mips.org/wiki/5K">5Ke</a>.</li>
</ul><h3 id="développement-et-traçage">Développement et traçage</h3>
<p>L’outil de traçage du noyau <a href="https://perf.wiki.kernel.org/index.php/Main_Page">perf</a> s’est enrichi d’une dizaine de fonctionnalités, allant d’une option pour <a href="https://git.kernel.org/torvalds/c/83e1986032dfcd3f9e9fc0d06e11d9153edae19b">afficher en nanosecondes</a> les marqueurs de temps à la <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e637d17757a10732fa5d573c18f20b3cd4d31245">configuration des événements</a> à tracer. Une grande part de ces modifications est spécifique ou optimisée pour l’<a href="https://software.intel.com/en-us/blogs/2013/09/18/processor-tracing">Intel Processor Tracing</a>.</p>
<p>Le travail le plus conséquent fut l’intégration de perf à eBPF. Une commande comme <code>perf record --event bpf-code.c /bin/ls</code> permet désormais de compiler le code source <a href="https://fr.wikipedia.org/wiki/BSD%20Packet%20Filter">BPF</a> et de charger ce filtre dans le noyau pour récupérer la trace noyau des événements sélectionnés.</p>
<h3 id="pilotes-graphiques-libres">Pilotes graphiques libres</h3>
<h4 id="direct-rendering-manager">Direct Rendering Manager</h4>
<p>Le code commun des pilotes DRM a gagné la capacité de sonder les différents CRTC et encodeurs disponibles pour les systèmes utilisant un <em>device tree</em>. Ce code permet de <a href="https://lists.freedesktop.org/archives/dri-devel/2015-October/093250.html">factoriser le code de plusieurs pilotes</a>.</p>
<p>L’interface fbdev au-dessus des pilotes DRM utilise maintenant la gestion du mode graphique atomique lorsque celle-ci est disponible afin de <a href="https://www.spinics.net/lists/dri-devel/msg88897.html">réduire le nombre de mises à jour du mode</a>, et réduire ainsi les clignotements.</p>
<p>Pour plus d’informations, vous pouvez consulter <a href="https://lkml.org/lkml/2015/11/8/308">la demande d’intégration DRM</a>.</p>
<h4 id="amd-pilotes-amdgpu-et-radeon">AMD (pilotes amdgpu et radeon)</h4>
<p>Les pilotes amdgpu et radeon <a href="http://lists.freedesktop.org/archives/dri-devel/2015-October/092509.html">continuent d’évoluer</a>, avec beaucoup de petites améliorations et un gros travail de fond avec l’ajout d’options de débogage, la gestion de nouveaux opcodes, l’activation du nouvel ordonnanceur GPU, et divers portages depuis radeon vers amdgpu. </p>
<h4 id="broadcom-pilote-vc4-rpi">Broadcom (pilote vc4, RPi)</h4>
<p>Fruit de l’important travail débuté il y a un an et demi par Eric Anholt (<a href="https://www.phoronix.com/scan.php?page=news_item&px=MTcyMTc">ex Intel, recruté à cet effet par Broadcom</a>), le pilote graphique libre pour les puces Broadcom VideoCore 4, utilisées par le Raspberry Pi, est maintenant intégré partiellement au noyau. Seules les parties KMS et 2D sont incluses ; la gestion 3D exigera de pouvoir se passer du <em>firmware</em> propriétaire pour la gestion d’énergie puisque l’IOMMU refuse actuellement l’accès au registre depuis les processeurs ARM ; les registres sont également non documentés. Le code inclut la gestion de HDMI, sans HDCP. Il est encore impossible d’initialiser le système sans logiciel propriétaire.</p>
<p>La gestion de la 3D fera son apparition dans Linux 4.5 (<a href="https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/vc4?id=21de54b3c4d08d2b20e80876c6def0b421dfec2e">commit</a>).</p>
<h4 id="intel-pilote-i915">Intel (pilote i915)</h4>
<p>Le processus de conversion du pilote i915 vers une gestion atomique du mode graphique continue avec l’ajout d’une base solide permettant de s’approprier le mode graphique utilisé par le firmware EFI (fastboot). Malheureusement, un bug a été trouvé tard dans le code ce qui a forcé à désactiver le code par défaut. À propos de la gestion atomique encore, le code permettant la validation et gestion dynamique de la fréquence d’horloge des CRTC <a href="//linuxfr.org/news/sortie-du-noyau-linux-4-3">introduit dans Linux 4.3</a> vient d’être porté dans le monde atomique.</p>
<p>Toujours côté affichage, la gestion du rafraîchissement automatique des panneaux (Panel Self-Refresh) et la gestion de la compression du framebuffer ont fortement avancé. Le PSR devrait être activé dans Linux 4.6 et devrait permettre de diminuer la consommation électrique.</p>
<p>L’espace d’adressage passe maintenant à 48 bits pour les processeurs Broadwell+ (génération 8), ce qui devrait permettre de gérer une plus grande quantité de mémoire, mais surtout va permettre d’avoir un espace d’adressage partagé entre le CPU et le GPU.</p>
<p>L’envoi de commande via le microcontrôleur GuC est maintenant géré, mais pas encore activé par défaut. Le GuC devrait à terme être un ordonnanceur et être responsable de la gestion d’énergie.</p>
<p>Pour plus d’informations, vous pouvez consulter le <a href="http://blog.ffwll.ch/2015/12/neat-drmi915-stuff-for-44.html">traditionnel article de blog</a> de Daniel Vetter, le mainteneur i915.</p>
<h4 id="nvidia-pilote-nouveau">NVIDIA (pilote nouveau)</h4>
<p>Le pilote nouveau a reçu de nombreuses améliorations liées à la gestion d’énergie, notamment le <em>reclocking</em>. Roy Spliet a en effet ajouté la gestion du <em>reclocking</em> de la mémoire GDDR3 pour les GPU G94-G200 (<a href="https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=0d42743dfa908a2ca4e349f883361906ebb4db95">commit</a>). Karol Herbst a quant à lui amélioré la fonction de calibration des PLL générant l’horloge de la mémoire GDDR5 pour les familles Kepler+ ce qui permet un <em>reclocking</em> bien plus fiable (<a href="https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=78eaf335e4c8224e74e5d512f20ec48109db9dac">commit</a>) ! Ben Skeggs a également perfectionné la détection des GPU ayant leur moteur 3D désactivé au démarrage (PGOB = Power Gating On Boot) et activé sa gestion pour le chipset GK107. Pour finir avec la gestion d’énergie, Martin Peres a ajouté la gestion des contrôleurs de tension commandés en modulation de largeur d’impulsion (PWM) qui sont très courants pour les GPU Maxwell et certaines cartes Kepler.</p>
<p>Alexandre Courbot de NVIDIA a profité des nouvelles fonctionnalités apportées par la réécriture du cœur de Nouveau (<a href="//linuxfr.org/news/sortie-du-noyau-linux-4-3#nvidia-pilote-nouveau">Linux 4.3</a>) pour améliorer les performances des accès à la mémoire d’instance. Le nouveau code est <a href="https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=69c4938249fb48aeed32fd76c67972e71f471cd2">40 % plus rapide</a>. Il a également converti le code de gestion de la mémoire vidéo pour utiliser la nouvelle API de Linux pour le DMA.</p>
<h4 id="autres">Autres</h4>
<p>Le pilote <code>virtio-gpu</code>, <a href="//linuxfr.org/news/sortie-du-noyau-linux-4-2#virtio-pilote-virtio-gpu">présenté dans la dépêche Linux 4.2</a>, a enfin reçu la gestion de la 3D dans le noyau. Le code nécessaire en espace utilisateur a été écrit, <a href="a8987b88ff1db4ac00720a9b56c4bc3aeb666537">fusionné dans Mesa en octobre</a> et sorti en version 11.1 (décembre 2015). Les changements nécessaires pour QEMU sont eux disponibles à partir de la version 2.5, sortie en décembre 2015. Pour plus d’informations, vous pouvez consulter <a href="https://www.youtube.com/watch?v=_LqpRbVCEuc">une vidéo de démonstration</a> ainsi que la page du projet <a href="https://virgil3d.github.io/">Virgil3D</a>.</p>
<p>Le pilote msm pour les GPU Qualcomm ajoute une gestion expérimentale du Snapdragon 820.</p>
<h3 id="réseau">Réseau</h3>
<h4 id="optimisation-de-la-poignée-de-main-tcp">Optimisation de la poignée de main TCP</h4>
<p>La <a href="https://fr.wikipedia.org/wiki/Transmission_Control_Protocol#.C3.89tablissement_d.27une_connexion">poignée de main TCP</a> est critique pour plusieurs raisons : elle introduit de la latence avant le moindre transfert de données et elle est source d’une vulnérabilité permettant des attaques par déni de service.</p>
<p>La réorganisation de cette poignée de main et l’optimisation des performances est un travail de longue haleine qui a atteint un point très intéressant dans cette version grâce à la <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e994b2f0fb9229aeff5eea9541320bd7b2ca8714">suppression d’un verrou</a> dans la procédure gérant les paquets SYN.</p>
<p>Si on prend du recul, cette poignée de main est désormais <a href="http://thread.gmane.org/gmane.linux.network/380654">10 à 100 fois plus rapide qu’il y a deux ans</a>. L’ordinateur de test du développeur est capable de gérer 3,5 millions paquets SYN par secondes, tout en ayant encore du temps CPU disponible.</p>
<h4 id="encore-plus-rapide-avec-so_reuseport">Encore plus rapide avec SO_REUSEPORT</h4>
<p>Toujours à propos de cette poignée de main, l’option <a href="https://lwn.net/Articles/542629/">SO_REUSEPORT</a> permet à plusieurs sockets d’écouter sur le même port, permettant notamment d’améliorer les performances avec un serveur multithreadé. Cette option a elle aussi été optimisée, permettant d’arriver à <a href="http://thread.gmane.org/gmane.linux.network/381777">six millions de paquets SYN</a> par seconde, sur la même machine de test que citée dans le paragraphe précédent.</p>
<h4 id="et-si-on-ajoutait-la-gestion-fine-de-cpu">Et si on ajoutait la gestion fine de CPU ?</h4>
<p>Et ce n’est pas terminé. L’option SO_INCOMING_CPU existait en lecture depuis 2014 et permettait de connaître le processeur gérant le flux de données TCP de la socket. À présent, cette option est également <a href="https://patchwork.ozlabs.org/patch/527795/">accessible en écriture</a> (via <code>setsockopt()</code>) et permet à une application de spécifier le processeur qui devrait gérer la socket. Cela étend l’idée de l’option SO_REUSEPORT, en permettant à chaque fil d’exécution d’une application de se positionner sur un processeur particulier.</p>
<h4 id="nouvelles-méthodes-de-détection-de-pertes-de-paquets">Nouvelles méthodes de détection de pertes de paquets</h4>
<p>Toujours sur TCP (et encore par un développeur de chez Google, la même entreprise que pour les optimisations de performance), une nouvelle méthode de détection de paquets perdus arrive dans le noyau Linux. Savoir si un paquet a été perdu est un problème non trivial, mais essentiel de TCP, notamment parce que cette détection est à la base de la gestion de congestion.</p>
<p>RACK (pour « Recent ACK ») est un nouvel algorithme qui considère comme perdu un paquet s’il n’a pas encore été acquitté alors qu’un acquittement a été reçu pour un paquet émis plus tard. Cet algorithme était en production sur des serveurs Google depuis plus d’un an au moment de la proposition de patchs. Pour plus d’informations, vous pouvez lire la <a href="https://www.mail-archive.com/netdev@vger.kernel.org/msg83215.html">demande d’inclusion</a> ainsi que le <a href="https://tools.ietf.org/html/draft-cheng-tcpm-rack-00">brouillon à l’IETF</a>.</p>
<h4 id="passage-à-la-micro-seconde-pour-le-temps-de-transmission-durant-la-poignée-de-main-tcp">Passage à la micro-seconde pour le temps de transmission durant la poignée de main TCP</h4>
<p>Ce n’est pas un hasard si l’auteur de ce commit est le même que celui qui a implémenté RACK : le noyau analyse maintenant à <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f1c28ae74bb1a34d36fca2db5161611d58b3148">la microseconde le temps de transfert des paquets</a> lors de la poignée de main TCP (les paquets suivants utilisaient déjà la microseconde). Cette amélioration de la précision est nécessaire sur les réseaux locaux si on souhaite utiliser cette information dans les algorithmes de congestion.</p>
<h4 id="du-changement-dans-les-routes-à-chemins-multiples-en-ipv4">Du changement dans les routes à chemins multiples en IPv4</h4>
<p>Pour comprendre ce changement, il <a href="//linuxfr.org/news/sortie-du-noyau-linux-3-6#toc_11">faut remonter au noyau 3.6</a> et la suppression du cache des routes en IPv4. Comme effet de bord de cette suppression, le routage des paquets en cas de chemins multiples pour une même route était devenu quasi aléatoire pour chaque paquet. C’est normalement peu important (en IP, chaque paquet devrait être indépendant), mais dérange certaines applications qui attendent les paquets dans l’ordre (et augmente dans tous les cas le coût de traitement pour les applications qui savent réordonner des paquets arrivés dans le désordre).</p>
<p>Afin que les paquets appartenant à un même flux de donnée utilisent la même route (et arrivent donc probablement dans le bon ordre), Peter Nørlund a <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=07355737a8badd951e6b72aa8609a2d6eed0a7e7">ajouté le calcul d’un condensat</a> (hash) prenant en entrée les adresses IP source et destination. Tous les paquets ayant le même hash prendront le même chemin.</p>
<p>Dans les détails non triviaux, les paquets d’erreurs en ICMP sont également gérés (il faut regarder des adresses à l’intérieur d’un paquet, cela complexifie beaucoup le traitement). Cette fonctionnalité est indispensable pour que la <a href="https://fr.wikipedia.org/wiki/Path_MTU_discovery">découverte de la MTU</a> continue de fonctionner correctement. En revanche, les identifiants de niveau supérieur (comme les ports en TCP et UDP), qui permettraient de mieux discriminer les flux, ne sont pas lus. Cette faiblesse d’identification des flux est une limitation d’IPv4 : en IPv6, on pourrait utiliser la lecture des labels de flux exactement pour ce cas d’usage.</p>
<h4 id="en-bref-1">En bref</h4>
<h5 id="licmp-avec-ipvs">L’ICMP avec IPVS</h5>
<p>En parlant de chemins multiples et de gestion des erreurs ICMP pour découvrir la MTU, <a href="https://fr.wikipedia.org/wiki/IPVS" title="Définition Wikipédia">IPVS</a> est un répartiteur de charge pour le noyau Linux. Facebook l’utilise, mais a fait face à un problème : les paquets <a href="https://fr.wikipedia.org/wiki/ICMP" title="Définition Wikipédia">ICMP</a> signalant des erreurs ne sont pas transmis à l’instance source de l’erreur, provoquant notamment des problèmes de <a href="https://fr.wikipedia.org/wiki/Path_MTU_discovery">découverte de MTU</a>. La série de <a href="http://archive.linuxvirtualserver.org/html/lvs-devel/2015-08/msg00076.html">correctifs</a> ajoute une nouvelle option <code>sysctl</code>, qui permet de corriger ce problème. Le comportement par défaut ne change pas.</p>
<h5 id="les-vrf-fonctionnent-désormais-en-ipv6">Les VRF fonctionnent désormais en IPv6</h5>
<p>Nous en parlions dans la <a href="//linuxfr.org/news/sortie-du-noyau-linux-4-3#prise-en-charge-initiale-des-vrf">dépêche du noyau 4.3</a>, les <em>Virtual Routing and Forwarding</em> (VRF) ont fait leur entrée dans le noyau Linux, mais ne fonctionnaient pas pour IPv6. <a href="https://lwn.net/Articles/660325/">C’est désormais corrigé</a>, elles sont pleinement fonctionnelles avec les deux versions du protocole IP.</p>
<h5 id="identifiant-de-la-table-fib-en-ipv4">Identifiant de la table FIB en IPv4</h5>
<p>Cette information était déjà disponible en IPv6, elle arrive en IPv4 : l’identifiant de la <a href="https://en.wikipedia.org/wiki/Forwarding_information_base">FIB</a> est <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b7503e0cdb5dbec5d201aa69d8888c14679b5ae8">désormais inclus</a> dans les informations de la table de routage.</p>
<h5 id="les-tunnels-geneve-en-ipv6">Les tunnels Geneve en IPv6</h5>
<p>Les tunnels <a href="https://tools.ietf.org/html/draft-gross-geneve-00">Geneve</a> sont un des très nombreux tunnels que le noyau Linux prend en charge. Ils fonctionnent <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8ed66f0e8235118a31720acdab3bbbe9debd0f6a">désormais également en IPv6</a> (seul l’IPv4 était disponible auparavant).</p>
<h5 id="plusieurs-chemins-en-mpls">Plusieurs chemins en MPLS</h5>
<p>Annoncé dans la <a href="//linuxfr.org/news/sortie-du-noyau-linux-4-1#routage-des-paquets-en-utilisant-le-m%C3%A9canisme-multiprotocol-label-switching-mpls">dépêche du noyau 4.1</a>, le code pour <a href="https://fr.wikipedia.org/wiki/MPLS" title="Définition Wikipédia">MPLS</a> dans le noyau Linux progresse. Il fonctionne maintenant avec <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e74f51056a167036f9168fb8d04b9e16ea12af43">plusieurs chemins pour une même route</a>.</p>
<h5 id="des-informations-sur-les-ponts-bridges-via-linterface-netlink">Des informations sur les ponts (bridges) via l’interface Netlink</h5>
<p><a href="https://en.wikipedia.org/wiki/Netlink">Netlink</a> est l’interface privilégiée pour exporter les informations réseau en espace utilisateur. Malheureusement, des morceaux historiques peuvent ne pas passer par là et ne pas exporter les informations dans <code>/proc</code> ou via le <code>sysfs</code>. C’était le cas pour les ponts (bridges), mais Nikolay Aleksandrov a fait un grand travail pour que le maximum d’informations soit maintenant accessible : annonce de la <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=68e4bd2778fb48a98cf9db8e218ef2f3a817bafc">première partie</a>, et de <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=68e4bd2778fb48a98cf9db8e218ef2f3a817bafc">la seconde</a>.</p>
<h5 id="des-applications-persistantes-pour-bpf">Des applications persistantes pour BPF</h5>
<p>On ne présente plus le <a href="https://www.kernel.org/doc/Documentation/networking/filter.txt">Berkeley Packet Filter (BPF)</a> du noyau. Celui-ci avait une limitation pour certains utilisateurs : lorsqu’un programme s’arrête, les règles qu’il a pu mettre en place disparaissent.</p>
<p>Daniel Borkmann, principal développeur de cette partie du noyau, a donc proposé de <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b2197755b2633e164a439682fb05a9b5ea48f706">permettre la persistance de ces règles</a>, ce qui se concrétise par des fichiers spéciaux que les programmes peuvent ouvrir dans <code>/sys/fs/bpf/</code>.</p>
<h3 id="sécurité">Sécurité</h3>
<p>Le chiffrement matériel avec le protocole <a href="https://en.wikipedia.org/wiki/Trusted_Platform_Module">Trusted Platform Module</a> accepte désormais la norme TPM 2.0. C’est la seule fonctionnalité notable parmi des <a href="https://github.com/torvalds/linux/commit/1873499e13648a2dd01a394ed3217c9290921b3d">développements</a> principalement de maintenance.</p>
<h3 id="périphériques-en-mode-bloc-block-devices">Périphériques en mode bloc (block devices)</h3>
<h4 id="lecture-sans-interruption-et-polling">Lecture sans interruption et <em>polling</em>
</h4>
<p>Rien à voir avec les coups de fils pour connaître notre gel douche préféré, c’est en fait l’apparition dans la couche E/S par bloc du noyau d’une technique issue de la couche réseau. Jusqu’à présent, la lecture d’un disque se faisait par interruptions successives déclenchées par le pilote, ce qui permet au processeur de s’occuper d’autres tâches entre deux interruptions.</p>
<p>Avec les SSD, les débits sont suffisamment élevés pour remettre en cause le mécanisme coûteux des interruptions matérielles et logicielles et envisager un flux plus continu. Ce noyau introduit un mécanisme de lecture où la couche-bloc demande elle-même les données (polling) au pilote. En cas de lecture séquentielle, le gain est parfois très net, jusqu’à un facteur deux, même s’il dépend fortement du périphérique.</p>
<p>L’implémentation est encore très partielle et expérimentale, mais son intégration au noyau devrait accélérer les développements. Pour en savoir plus : <a href="http://lwn.net/Articles/663879/">LWN</a>.</p>
<h4 id="montage-loop">Montage <em>loop</em>
</h4>
<p>Indépendamment du système de fichiers, on peut placer un point de montage <em>loop</em> sur un fichier, par exemple avec une image de DVD. Ce mécanisme utilise désormais des accès directs, sans passer par des mémoires tampon au niveau du périphérique de bloc <em>loop</em>. Les <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bc07c10a3603a5ab3ef01ba42b3d41f9ac63d1b6">performances</a> en sont grandement améliorées, notamment en termes de consommation de mémoire.</p>
<h3 id="systèmes-de-fichiers">Systèmes de fichiers</h3>
<h4 id="f2fs">F2FS</h4>
<p><a href="https://github.com/torvalds/linux/commit/0fcb9d21b4e18ede3727b8905e74acd0d1daef56">https://github.com/torvalds/linux/commit/0fcb9d21b4e18ede3727b8905e74acd0d1daef56</a></p>
<p>Intégration des changements de f2fs de Jaegeuk Kim :<br>
La plupart des changements sont des améliorations de stabilité et de performance de la fonctionnalité de mise en cache des extensions en mémoire.<br>
Avec en plus quelques nouvelles fonctionnalités et configurations supplémentaires ainsi que quelques corrections.</p>
<h4 id="btrfs">Btrfs</h4>
<p><a href="https://github.com/torvalds/linux/commit/27eb427bdc0960ad64b72da03e3596c801e7a9e9">https://github.com/torvalds/linux/commit/27eb427bdc0960ad64b72da03e3596c801e7a9e9</a></p>
<p>Intégration des changements de btrfs de Chris Mason :<br>
Beaucoup d’améliorations du côté de la gestion du sub-quota et beaucoup de nettoyage de la part de Dave Sterba et Anand Jain entre autres.<br>
Josef a soumis un tas de corrections concernant l’allocateur utilisé en production chez Facebook. Il a trouvé que l’option <code>mount -o ssd_spread</code> améliore grandement les performances sur du RAID 5/6 matériel, mais au prix de quelques engorgements CPU. Ces patchs font alors une grande différence.</p>
<h4 id="ext4">Ext4</h4>
<p><a href="https://github.com/torvalds/linux/commit/b0f85fa11aefc4f3e03306b4cd47f113bd57dcba">https://github.com/torvalds/linux/commit/b0f85fa11aefc4f3e03306b4cd47f113bd57dcba</a></p>
<p>Voici le <a href="https://lkml.org/lkml/2015/11/6/417">résumé</a> par Ted Ts’o en charge de ext4 :</p>
<ul>
<li>Ajout de la prise en charge de la fonctionnalité CSUM_SEED qui permettra dans le futur aux applications en espace utilisateur de changer l’UUID du volume sans réécriture de toutes les métadonnées de ce volume.</li>
<li>Un certain nombre de corrections diverses, qui concernent surtout le chiffrement de partitions ext4. Quiconque utiliserait ce chiffrement devrait rétro-porter tous les changements opérés en 4.4 pour corriger des fuites mémoires et des corruptions de données.</li>
<li>Il y a aussi du nettoyage des tests de ext4 et de la prise en charge de sysfs.</li>
</ul><h3 id="virtualisation">Virtualisation</h3>
<p>Il est désormais possible à une machine virtuelle dans QEMU d’utiliser l’accélération matérielle OpenGL 3D de son hôte. Ce <a href="https://virgil3d.github.io/">projet</a> assemble plusieurs éléments : <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3187567222178d4b3742e88242f7abb3c3b7a215">virtio-gpu</a> dans le noyau 4.4, virtio dans <a href="http://wiki.qemu.org/ChangeLog/2.5#virtio">QEMU 2.5</a>, et Mesa (git master).</p>
<h4 id="kvm">KVM</h4>
<p><a href="https://github.com/torvalds/linux/commit/933425fb0010bd02bd459b41e63082756818ffce">https://github.com/torvalds/linux/commit/933425fb0010bd02bd459b41e63082756818ffce</a></p>
<h5 id="s390">s390</h5>
<p>Des corrections et améliorations de la gestion des interruptions et du temps.</p>
<h5 id="ppc">PPC</h5>
<p>Principalement des corrections diverses.</p>
<h5 id="arm">ARM</h5>
<p>Pas de grosses nouveautés, mais beaucoup de petites corrections et améliorations nécessaires :</p>
<ul>
<li>des corrections pour le compteur d’architecture (arch-timer)</li>
<li>ajout de nouvelles sémantiques d’activation par niveau pour le compteur d’architecture (arch-timer)</li>
<li>une série de patchs pour arrêter de manière synchronisée un système invité (nécessaire pour la redirection d’interruptions)</li>
<li>amélioration des points de trace</li>
<li>une astuce pour la gestion des exceptions de panique de niveau EL2</li>
<li>encore du nettoyage de la virtualisation du GIC (Gestionnaire d’Interruptions de ARM) pour la suppression d’états redondants</li>
</ul><h5 id="x86">x86</h5>
<p>Quelques changements:</p>
<ul>
<li>gestion du "VT-d posted interrupts" (i.e. les périphériques PCI peuvent injecter des interruptions directement dans un CPU virtuel). Cela introduit donc un nouveau composant (dans virt/lib/) qui relie VFIO et KVM.
Les mêmes composants seront aussi utilisés pour la redirection d’interruptions sur ARM.</li>
<li> de nouvelles fonctionnalités Hyper-V, même si la principale "Hyper-V synthetic interrupt controller" devra attendre linux 4.5. Ceci permettra a KVM aussi d’exposer des périphériques Hyper-V.</li>
<li> la virtualisation imbriquée prend maintenant en charge les VPID (comme les PCID mais pour les CPUs virtuels) qui accélèrent un peu les choses</li>
<li> pour le futur matériel prenant en charge le NVDIMM, il y a maintenant la prise en charge de clflushopt, clwb et pcommit</li>
<li> prise en charge du "split irqchip", i.e. LAPIC dans le kernel + IOAPIC/PIC/PIT dans l’espace utilisateur, qui réduit la surface d’attaque de l’hyperviseur</li>
<li> intégration nécessaire des corrections pour le SMM (system management mode)</li>
<li> pour le côté client, "stable scheduler clock support" a été réécrit pour que son fonctionnement soit indépendant du superviseur</li>
</ul><h3 id="cgroups">Cgroups</h3>
<p><a href="https://github.com/torvalds/linux/commit/69234acee54407962a20bedf90ef9c96326994b5">https://github.com/torvalds/linux/commit/69234acee54407962a20bedf90ef9c96326994b5</a></p>
<p>Intégration des changements de cgroups de Tejun Heo. Le cœur de cgroups a vu de nombreux changements pour cette version :</p>
<ul>
<li>Le verrouillage <code>percpu_rwsem</code> pour le groupe de processus légers (<code>threadgroup</code>) est rétabli. Cette fonctionnalité était temporairement supprimée pour des raisons de latences causées par les appels <code>down_write</code>. Le re-travail de Oleg sur <code>percpu_rwsem</code> dont l’intégration est prévue pour la prochaine fenêtre d’intégration corrigera le problème.</li>
<li>Sur la nouvelle version de la hiérarchie, quand les gestionnaires sont activés et désactivés, toutes les opérations sont atomiques et peuvent échouer et revenir proprement. Cela permet des erreurs lors des appels ->can_attach() ce qui est nécessaire pour les <code>cpu RT slices</code>.</li>
<li>Les tâches restent associées à leur cgroup original après leur sortie jusqu’à leur libération complète. Cela permet un suivi des ressources des tâches fantômes et facilite la découverte de l’origine de ces processus fantômes dans la nouvelle hiérarchie. Le gestionnaire de numéro de processus était cassé avant ces changements, car les processus fantômes échappaient à ces limites ; malheureusement changer ce comportement a requis bien trop de changements profonds et cela reste une mauvaise idée de porter ces corrections en arrière, donc le gestionnaire de numéro de processus sur 4.3, la première version l’incluant, restera cassé au moins jusqu’à ce que l’on soit certain des changements du cœur de cgroups.</li>
<li>Optimisation d’une partie des tests communs en utilisant des <code>static_key</code>.</li>
</ul><h2 id="le-bilan-en-chiffres">Le bilan en chiffres</h2>
<p>Selon le <a href="http://lwn.net/Articles/668870/">site LWN</a>, cette version 4.4 a impliqué 1 548 développeurs alors que pour la version 4.3, il y en avait eu 1 600. Parmi ces 1 548 personnes, 246 ont fait leur première contribution au noyau.</p>
<p>Pour l’année 2015, la palme du développeur le plus actif a été remportée par H Hartley Sweeten si on s’appuie sur le nombre de commits (282 <em>changesets</em>), ou par Alex Deucher si l’on s’appuie sur le nombre de lignes modifiées (3 220 lignes).</p>
<p>Si l’on se réfère aux entreprises impliquées dans le noyau, Intel l’emporte haut la main, notamment devant Red Hat, Samsung et AMD, aussi bien en nombre de commits qu’en nombre de lignes modifiées (avec respectivement 12,9 % et 13,3 %).</p>
<h2 id="appel-à-volontaires">Appel à volontaires</h2>
<p>Cette dépêche a nécessité plus de 960 éditions (à l’heure de l’écriture de ces statistiques), et mobilisé 28 personnes du 16 novembre 2015 au 18 février 2016 dans l’espace de rédaction.</p>
<p><img src="//img.linuxfr.org/img/687474703a2f2f7069782e746f696c652d6c696272652e6f72672f75706c6f61642f6f726967696e616c2f313435353739313935372e706e67/1455791957.png" alt="Graphe des contributions à la dépêche" title="Source : http://pix.toile-libre.org/upload/original/1455791957.png"></p>
<p>Cette dépêche est rédigée par plusieurs contributeurs, dont voici la répartition :</p>
<table>
<thead><tr>
<th></th>
<th>Mainteneur</th>
<th>Contributeur(s)</th>
</tr></thead>
<tbody>
<tr>
<td><strong>En bref</strong></td>
<td>Aucun</td>
<td><a href="//linuxfr.org/users/rogo">rogo</a></td>
</tr>
<tr>
<td><strong>La phase de test</strong></td>
<td>Aucun</td>
<td>Aucun</td>
</tr>
<tr>
<td><strong>Arch</strong></td>
<td>Aucun</td>
<td><a href="//linuxfr.org/users/tiwaz">Tiwaz</a></td>
</tr>
<tr>
<td><strong>IPC</strong></td>
<td>Aucun</td>
<td><a href="//linuxfr.org/users/sinma">ariasuni</a></td>
</tr>
<tr>
<td><strong>Développement</strong></td>
<td>Aucun</td>
<td><a href="//linuxfr.org/users/rogo">rogo</a></td>
</tr>
<tr>
<td><strong>Pilotes graphiques libres</strong></td>
<td><a href="//linuxfr.org/users/mupuf">Martin Peres</a></td>
<td>Aucun</td>
</tr>
<tr>
<td><strong>Réseau</strong></td>
<td>Aucun</td>
<td>
<a href="//linuxfr.org/users/ffourcot">Florent Fourcot</a>, <a href="//linuxfr.org/users/tiwaz">Tiwaz</a>
</td>
</tr>
<tr>
<td><strong>Block devices</strong></td>
<td>Aucun</td>
<td><a href="//linuxfr.org/users/rogo">rogo</a></td>
</tr>
<tr>
<td><strong>Systèmes de fichiers</strong></td>
<td>Aucun</td>
<td><a href="//linuxfr.org/users/sinma">ariasuni</a></td>
</tr>
<tr>
<td><strong>Sécurité</strong></td>
<td>Aucun</td>
<td><a href="//linuxfr.org/users/rogo">rogo</a></td>
</tr>
<tr>
<td><strong>Virtualisation</strong></td>
<td><a href="//linuxfr.org/users/claudex">Xavier Claude</a></td>
<td>Aucun</td>
</tr>
<tr>
<td><strong>Édition générale</strong></td>
<td>Aucun</td>
<td>
<a href="//linuxfr.org/users/jcr83">jcr83</a>, <a href="//linuxfr.org/users/m5oul">Moul</a>, <a href="//linuxfr.org/users/eggman">eggman</a>
</td>
</tr>
</tbody>
</table><p>Un peu de vocabulaire :</p>
<ul>
<li>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 ;</li>
<li>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.</li>
</ul><p>Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps et de volontaires.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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 <em>commits</em> 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 !<br>
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 !</p></div><div><a href="https://linuxfr.org/news/sortie-du-noyau-linux-4-4.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/107364/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/sortie-du-noyau-linux-4-4#comments">ouvrir dans le navigateur</a>
</p>
jcr83esdeemM5oulsupernarogoFlorent FourcotTiwazYves BourguignonBenoît SibaudMartin PeresSébastien KoechlinBAudpalm123Olivier EsverɹǝıʌıʃONÿcoRomain PerierMohamed MEDIOUNIantistressgoernilDavy DefaudTuxMipsdavid.gʭ ☯ Dams NadéSiosmpatrick_gbobble bubblereynumhttps://linuxfr.org/nodes/107364/comments.atomtag:linuxfr.org,2005:News/366962015-11-30T09:57:07+01:002016-02-08T10:58:14+01:00Sortie du noyau Linux 4.3Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>La sortie de la version stable 4.3 du noyau Linux a été annoncée le 1<sup>er</sup> novembre 2015 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site <a href="http://kernel.org/"><em>kernel.org</em></a>.</p>
<p>Le détail des évolutions, nouveautés et prévisions se trouve dans la seconde partie de la dépêche, publiée sous <a href="http://creativecommons.org/licenses/by-sa/3.0/deed.fr">licence CC BY-SA</a>, Attribution — Partage dans les Mêmes Conditions.</p>
<p><strong>Note</strong> : Tout le monde peut participer à la <a href="//linuxfr.org/wiki/redaction" title="Lien du wiki interne LinuxFr.org">rédaction</a> de cette dépêche. Vous pouvez même vous proposer pour des <a href="//linuxfr.org/redaction/news/sortie-du-noyau-linux-4-3#appel-%C3%A0-volontaires">sections qui vous intéressent</a> et il y a même de <a href="//linuxfr.org/wiki/rediger-des-depeches-noyau">l’aide pour ceux qui voudraient s’y mettre et n’osent pas franchir le pas</a>.</p></div><ul><li>lien nᵒ 1 : <a title="https://linuxfr.org/wiki/depeches_noyau" hreflang="fr" href="https://linuxfr.org/redirect/94981">Dépêches des noyaux précédents</a></li><li>lien nᵒ 2 : <a title="https://www.kernel.org/" hreflang="en" href="https://linuxfr.org/redirect/94982"> Site officiel du noyau Linux</a></li><li>lien nᵒ 3 : <a title="http://www.heise.de/open/artikel/Die-Neuerungen-von-Linux-4-3-2860564.html" hreflang="de" href="https://linuxfr.org/redirect/95677">Die Neuerungen von Linux 4.3</a></li></ul><div><h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li><a href="#en-bref">En bref</a></li>
<li>
<a href="#annonces-des-rc-par-linustorvalds">Annonces des RC par Linus Torvalds</a><ul>
<li><a href="#rc-1">RC-1</a></li>
<li><a href="#rc-2">RC-2</a></li>
<li><a href="#rc-3">RC-3</a></li>
<li><a href="#rc-4">RC-4</a></li>
<li><a href="#rc-5">RC-5</a></li>
<li><a href="#rc-6">RC-6</a></li>
<li><a href="#rc-7">RC-7</a></li>
<li><a href="#version-finale">Version finale</a></li>
</ul>
</li>
<li>
<a href="#les-nouveaut%C3%A9s">Les nouveautés</a><ul>
<li>
<a href="#architecture">Architecture</a><ul>
<li><a href="#une-meilleure-analyse-de-performance-sur-certains-processeurs">Une meilleure analyse de performance sur certains processeurs</a></li>
<li><a href="#prise-en-chargearmv81">Prise en charge ARMv8.1</a></li>
<li><a href="#am%C3%A9lioration-de-la-prise-en-charge-des-syst%C3%A8mes-monopuces-arm">Amélioration de la prise en charge des systèmes monopuces ARM</a></li>
<li><a href="#mips-nest-pas-mort">MIPS n’est pas mort</a></li>
<li><a href="#s390">s390</a></li>
<li><a href="#amd-carrizo">AMD Carrizo</a></li>
</ul>
</li>
<li><a href="#ipc">IPC</a></li>
<li><a href="#d%C3%A9veloppement">Développement</a></li>
<li>
<a href="#pilotes-graphiques-libres">Pilotes graphiques libres</a><ul>
<li><a href="#direct-rendering-manager">Direct Rendering Manager</a></li>
<li>
<a href="#amdati">AMD/ATI</a><ul>
<li><a href="#pilote-de-rendu-nouvelle-g%C3%A9n%C3%A9ration-pilote-amdgpu">Pilote de rendu nouvelle génération (pilote amdgpu)</a></li>
<li><a href="#pilote-hsa-pilote-amdkfd">Pilote HSA (pilote amdkfd)</a></li>
</ul>
</li>
<li><a href="#intel-pilote-i915">Intel (pilote i915)</a></li>
<li><a href="#matrox-pilote-mgag200">Matrox (pilote mgag200)</a></li>
<li><a href="#nvidia-pilote-nouveau">NVIDIA (pilote nouveau)</a></li>
<li><a href="#vmware-pilote-vmwgfx">VMware (pilote vmwgfx)</a></li>
<li>
<a href="#pilotes-graphiques-pour-syst%C3%A8mes-monopuces">Pilotes graphiques pour systèmes monopuces</a><ul>
<li><a href="#qualcomm-snapdragon-pilote-msm">Qualcomm Snapdragon (pilote msm)</a></li>
<li><a href="#freescale">Freescale</a></li>
</ul>
</li>
</ul>
</li>
<li>
<a href="#r%C3%A9seau">Réseau</a><ul>
<li><a href="#prise-en-charge-initiale-des-vrf">Prise en charge initiale des VRF</a></li>
<li>
<a href="#ipv6">IPv6</a><ul>
<li><a href="#compilation-par-d%C3%A9faut-dans-le-noyau">Compilation par défaut dans le noyau</a></li>
<li><a href="#ajout-des-identifier-locator-addressing-%C3%A0-ipv6--le-retour-de-la-dualit%C3%A9-des-ip">Ajout des <em>Identifier Locator Addressing</em> à IPv6 — le retour de la dualité des IP</a></li>
</ul>
</li>
<li><a href="#suivi-des-connexions-openvswitch">Suivi des connexions Open vSwitch</a></li>
<li>
<a href="#performances">Performances</a><ul>
<li><a href="#de-la-qualit%C3%A9-de-service-plus-rapide">De la qualité de service plus rapide</a></li>
<li><a href="#tunnels-l%C3%A9gers">Tunnels légers</a></li>
</ul>
</li>
<li><a href="#nouveau-pilote">Nouveau pilote</a></li>
<li><a href="#un-peu-dhumain">Un peu d’humain</a></li>
</ul>
</li>
<li>
<a href="#s%C3%A9curit%C3%A9">Sécurité</a><ul>
<li><a href="#antiforkbomb">Anti‐fork‐bomb</a></li>
<li><a href="#r%C3%A9vision-de-lh%C3%A9ritage-des-capabilities">Révision de l’héritage des <em>capabilities</em></a></li>
</ul>
</li>
<li>
<a href="#syst%C3%A8mes-de-fichiers">Systèmes de fichiers</a><ul>
<li><a href="#btrfs">Btrfs</a></li>
<li><a href="#ext3">ext3</a></li>
<li><a href="#ext4">ext4</a></li>
<li><a href="#f2fs">F2FS</a></li>
<li><a href="#xfs">XFS</a></li>
</ul>
</li>
<li>
<a href="#virtualisation">Virtualisation</a><ul>
<li><a href="#kvm">KVM</a></li>
<li><a href="#xen">Xen</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#le-bilan-en-chiffres">Le bilan en chiffres</a></li>
<li><a href="#appel-%C3%A0-volontaires">Appel à volontaires</a></li>
</ul><h2 id="en-bref">En bref</h2>
<ul>
<li>Suppression du code d’ext3 étant donné qu’ext4 peut gérer ces partitions.</li>
<li>Mécanisme anti <em>fork-bomb</em> avec <code>cgroup_pids</code>.</li>
<li>Meilleure migration à chaud de machines virtuelles grâce au passage des <em>page faults</em> en espace utilisateur.</li>
<li>Adressage d’un réseau local IPv6 par <em>Identifier Locator Addressing</em>.</li>
</ul><h2 id="annonces-des-rc-par-linustorvalds">Annonces des RC par Linus Torvalds</h2>
<h3 id="rc-1">RC-1</h3>
<p>La version <a href="https://lkml.org/lkml/2015/9/12/243">RC-1</a> est sortie le samedi 12 septembre 2015 :</p>
<blockquote>
<p><em>Aujourd’hui, cela a été plutôt calme (ce qui est normal : en général, il y a un petit surplus d’activité le dernier vendredi de la fenêtre d’intégration, mais la fin de semaine est plus calme) et j’ai décidé de ne pas tenir compte de tout ce qui pourra arriver demain, de fermer tout de suite la fenêtre d’intégration et de publier la RC-1.</em></p>
<p><em>Je m’attendais à ce que la version 4.3 soit plutôt petite après les gros changements apportés par la version 4.2, mais ce n’est pas vraiment le cas – sa taille est plutôt moyenne, en fait. En effet, tout paraît normal, avec des modifications réparties à 70 % pour les pilotes, 10 % pour les mises à jour des architectures et les 20 % restants éparpillés (systèmes de fichiers, réseau, outils, documentation, gestion de la mémoire et mises à jour du « cœur » du noyau, etc.).</em></p>
<p><em>Du côté des pilotes, les pilotes graphiques en constituent une grosse part, en partie à cause des mises à jour de Nouveau qui n’avaient pas pu être intégrés dans la 4.2, donc il y a là en fait une mise à jour qui en vaut deux. Mais il y a aussi des mises à jour de pilotes dans la plupart des autres sous‐systèmes : réseau (filaire et sans‐fil), recette (<a href="http://www.kroah.com/log/linux/linux-staging-update.html" title="The Linux Staging Tree, what it is and is not"><em>staging</em></a>)</em> [N. D. T. : branche de mise au point centralisée avant intégration à la branche principale]<em>, média, cryptographie, contrôleur de broches (pinctrl), pour n’en nommer que quelques‐unes.</em></p>
<p><em>Les mises à jour d’architectures sont pour moitié sur ARM (notamment les mises à jour de l’arborescence matérielle [devicetree]), avec l’autre moitié éparpillée (x86, MIP, ARM64, PowerPC, s390).</em></p>
<p><em>Du côté des systèmes de fichiers, le gros du changement (en lignes de code) est la suppression du système de fichiers ext3 (ext4 assurant encore la prise en charge du ext3 — mais le code spécifique à ext3 a disparu). Mais il y a aussi des mises à jour diverses un peu partout : F2FS, Btrfs, NFS, XFS, UFS, GFS2, proc…</em></p>
<p><em>Comme d’habitude, l’historique complet des changements est trop gros pour être publié, par conséquent je joins mon historique de fusion qui donne une idée des changements intégrés et de l’ensemble de la situation…</em></p>
<p><em>Allez‐y, testez,</em></p>
<p><em>Linus</em></p>
</blockquote>
<h3 id="rc-2">RC-2</h3>
<p>La version <a href="https://lkml.org/lkml/2015/9/20/159">RC-2</a> est sortie le dimanche 20 septembre 2015 :</p>
<blockquote>
<p><em>Nous revenons au calendrier dominical habituel, voici donc la RC-2. Comme c’est la tendance depuis un moment maintenant, la RC-2 est assez petite, probablement parce qu’il faut un bout de temps avant que les rapports de régression ne commencent à arriver peu à peu (et certaines personnes attendent probablement délibérément la RC-2 pour ne serait‐ce que commencer à tester — vous, vous êtes des trouillards).</em></p>
<p><em>Quoi qu’il en soit, tout semble plutôt normal. Il y a quelques perturbations un peu partout dans l’arborescence à cause du ménage effectué dans le gestionnaire de flux des interruptions</em> [IRQ flow-handler] <em>qui a enlevé le paramètre redondant de numéro d’interruption. Mais à part ce changement ponctuel, c’est plutôt calme et succinct — nous verrons si ça va continuer. Touchons du bois.</em></p>
<p><em>Sinon, c’est le mélange habituel de corrections d’architectures et de pilotes, avec une pincée d’autres choses (les mises à jour de l’outillage de performances sortent du lot, par exemple). Je n’ai rien vu de particulièrement alarmant et le résumé ci‐joint, donne tous les détails plutôt ennuyeux.</em></p>
<p><em>Donc, si quelqu’un n’a pas osé faire la mise à jour juste après la fin de la période d’intégration, qu’il se lance. On a besoin de gens pour tester et remonter les problèmes.</em></p>
<p><em>Linus</em></p>
</blockquote>
<h3 id="rc-3">RC-3</h3>
<p>La version <a href="https://lkml.org/lkml/2015/9/27/42">RC-3</a> est sortie le dimanche 27 septembre 2015 :</p>
<blockquote>
<p><em>Et comme d’habitude, la RC-3 est de fait plus grosse que la RC-2 (les corrections commencent à affluer), mais rien de particulièrement alarmant ne sort du lot.</em></p>
<p><em>Tout paraît normal : l’essentiel concerne les pilotes (un peu partout, mais les pilotes graphiques et le réseau sont les parties les plus importantes), ainsi que les mises à jour d’architectures. Il y a aussi des mises à jour du réseau et des systèmes de fichiers, accompagnés de documentation.</em></p>
<p><em>Allez la récupérer,</em></p>
<p><em>Linus</em></p>
</blockquote>
<h3 id="rc-4">RC-4</h3>
<p>La version <a href="https://lkml.org/lkml/2015/10/04/128">RC-4</a> est sortie le dimanche 4 octobre 2015 :</p>
<blockquote>
<p><em>Vous savez tous comment ça se passe maintenant. C’est dimanche, et il y a une nouvelle version candidate.</em></p>
<p><em>Tout semble plutôt normal. Nous avons notablement moins de modifications que dans la RC-3 (qui était particulièrement grosse) et je ne vois rien d’exceptionnellement alarmant.<br>
Les statistiques semblent également tout à fait normales : un peu moins de la moitié des modifications concernent des pilotes (DRM continue à être notable, mais il y aussi InfiniBand, MMC, la couche d’entrées, etc.). À peu près un quart est constitué des mises à jour d’architectures (m68k, MIPS, x86) et le dernier quart est complètement varié (mise à jour de la documentation, outils, scripts, ordonnanceur, gestion de la mémoire…).</em></p>
<p><em>La liste des changements jointe donne une idée des détails.</em></p>
<p><em>Linus</em></p>
</blockquote>
<h3 id="rc-5">RC-5</h3>
<p>La version <a href="https://lkml.org/lkml/2015/10/11/132">RC-5</a> est sortie le dimanche 11 octobre 2015 :</p>
<blockquote>
<p><em>Le cycle de publication de la 4.3 se poursuit en douceur — touchons du bois. Il n’y a rien de particulièrement inquiétant ici : on a eu quelques retombées ennuyeuses provenant de la nouvelle fonction <code>strscpy()</code> (elle n’est pas encore</em> réellement <em>utilisée, mais on a eu des erreurs de compilation sur certaines architectures) et un changement dans la couche VFS qui a révélé un problème ancien et fascinant sur ext[3-4] ; mais dans l’ensemble, tout semble plutôt normal. C’est l’habituel « plein de petites corrections sur le code des pilotes et des architectures, saupoudrées de quelques mises à jour des systèmes de fichiers en guise de diversité ». Le résumé ci‐joint donne un aperçu des détails.</em></p>
<p><em>L’activité semble également se calmer gentiment, bien que, comme il n’y a pas eu de récupération de code réseau cette semaine, on pourrait bien en trouver un paquet dans la prochaine RC.</em></p>
<p><em>Quoi qu’il en soit, si vous n’avez pas testé un noyau récent dernièrement, n’hésitez pas à vous lancer dès maintenant — ça a l’air pas mal du tout.</em></p>
<p><em>Linus</em></p>
</blockquote>
<h3 id="rc-6">RC-6</h3>
<p>La version <a href="https://lkml.org/lkml/2015/10/18/303">RC-6</a> est sortie le dimanche 18 octobre 2015 :</p>
<blockquote>
<p><em>Cela continue à être calme, et même de plus en plus calme. J’en suis vraiment heureux, bien que ma nature suspicieuse cherche quelque chose à critiquer. Les gens se comportent‐ils de leur mieux en raison du</em> <a href="http://events.linuxfoundation.org/events/linux-kernel-summit" title="Linux Kernel Summit 2015">Kernel Summit</a> <em>qui approche, tout le monde cherchant à se montrer sous son meilleur angle ?</em></p>
<p><em>Ou peut‐être est‐ce simplement l’une de ces rares et indolores versions où rien de mauvais n’arrive ?</em></p>
<p><em>Ce serait adorable.</em></p>
<p><em>Qu’importe la raison, il n’y a rien de bizarre ou d’effrayant en vue, et le journal résumé ci‐joint est agréable et court. La quasi-totalité concerne les pilotes, avec notamment les correctifs sur InfiniBand et les pilotes graphiques. Mais même là, le plus gros correctif (et de loin) consiste simplement en une clarification du message de copyright dans InfiniBand, qui à lui seul forme un tiers de l’ensemble du correctif. Car le reste est vraiment mineur.</em></p>
<p><em>En dehors des corrections de pilote, il y a quelques toutes petites mises à jour d’architectures (le plus gros étant quelques corrections de KVM sur x86 pour l’émulation SMM, mais même ces dernières ne sont en aucun cas énormes). Et une poignée de corrections d’une ligne concernant la gestion mémoire.</em></p>
<p><em>Autrement dit, tout a l’air vraiment bien. Touchons du bois.</em></p>
<p><em>Linus</em></p>
</blockquote>
<h3 id="rc-7">RC-7</h3>
<p>La version <a href="https://lkml.org/lkml/2015/10/25/2">RC-7</a> est sortie le dimanche 25 octobre 2015 :</p>
<blockquote>
<p><em>Il est possible qu’il soit encore samedi chez moi, mais grâce au</em> <a href="http://events.linuxfoundation.org/events/linux-kernel-summit" title="Linux Kernel Summit 2015">Kernel Summit</a> <em>à venir en Corée, j’ai pris une longueur d’avance avec un fuseau horaire de +9 h, et ici c’est dimanche. Donc c’est le jour de la publication.</em></p>
<p><em>Cette RC casse la tendance de « réduction agréable et d’accalmie », principalement en raison au fait que nous avons intégré les corrections réseau en RC-7 (mais pas en RC-6). Il y a aussi quelques autres intégrations un peu plus grosses (corrections de systèmes monopuces ARM, pilotes graphiques, couche bloc et média) et évidemment toutes les corrections de pilotes divers, etc. Mais les changements réseau sont la raison pour laquelle cette RC a l’air quelque peu différente des précédentes.</em></p>
<p><em>Et malgré cette petite augmentation de taille, rien n’a l’air particulièrement inquiétant et ce cycle de publication continue à se dérouler en douceur. Comme déjà évoqué auparavant, la semaine prochaine est celle du</em> <a href="http://events.linuxfoundation.org/events/linux-kernel-summit" title="Linux Kernel Summit 2015">Kernel Summit</a> <em>et, avec un grand nombre de mainteneurs principaux occupés à Séoul, je présume que les choses resteront calmes et, à moins que quelque chose de bizarre ne survienne, je sortirai la 4.3 finale dimanche prochain (d’ici là, je serai de retour dans mon fuseau horaire habituel).</em></p>
<p><em>Le journal résumé ci‐joint est disponible pour les gens qui veulent inspecter les détails.</em></p>
<p><em>Linus</em></p>
</blockquote>
<h3 id="version-finale">Version finale</h3>
<p>La <a href="https://lkml.org/lkml/2015/11/1/202">version finale</a> est sortie le dimanche 1<sup>er</sup> novembre 2015 :</p>
<blockquote>
<p><em>Alors, la dernière semaine de la série des RC semblait chargée au point que je commençais à m’inquiéter pour la publication finale. Mais, les chiffres montrent qu’en réalité il ne s’agissait que d’une impression subjective de ma part, probablement due au</em> <a href="http://events.linuxfoundation.org/events/linux-kernel-summit" title="Linux Kernel Summit 2015">Kernel Summit</a> <em>et au voyage de retour de la Corée à chez moi. Ce n’était pas vraiment une semaine particulièrement chargée, c’est juste que les demandes d’intégration ont été plus importantes dans les tout derniers jours.</em></p>
<p><em>On a eu une mise à jour du code réseau et une correction tardive pour un bogue du mode vm86 sur x86 introduit par les nettoyages de vm86, mais à part ça c’est juste un ensemble de petites corrections d’une ligne un peu partout. OK, le truc sur le mode vm86 était également une correction d’une ligne, mais il s’agissait d’une chose un peu plus angoissante, car ça avait l’air plus effrayant que ça ne l’était en réalité, jusqu’à ce que quelqu’un (Andy) comprenne ce qu’il se passait.</em></p>
<p><em>Les changements depuis la RC-7 sont dominés par les trucs réseau, mais comme vous pouvez le voir sur le journal résumé ci‐joint, il n’y a rien de particulièrement inquiétant.</em></p>
<p><em>Donc, dans l’ensemble, ça reste un cycle de publication assez calme jusqu’à la fin. Et avec la sortie de la 4.3, la fenêtre d’intégration pour la 4.4 est évidemment ouverte, et gardons les doigts croisés pour que ce soit une publication tout aussi tranquille. Tout spécialement depuis que Greg a décidé, par anticipation (c’est une expérience amenée par une discussion lors du</em> <a href="http://events.linuxfoundation.org/events/linux-kernel-summit" title="Linux Kernel Summit 2015">Kernel Summit</a><em>) que la 4.4 serait une autre version LTS</em> [N. D. T. : <em>Long Term Support</em> — maintenance à durée étendue].</p>
<p><em>Linus</em></p>
</blockquote>
<h2 id="les-nouveautés">Les nouveautés</h2>
<h3 id="architecture">Architecture</h3>
<p>Plusieurs améliorations ont permis de diminuer le temps de démarrage du noyau sur système x86.</p>
<p>Len Brown, d’Intel, continue à travailler sur l’optimisation du démarrage sur x86. Son travail porte principalement sur quatre correctifs [<a href="https://www.phoronix.com/scan.php?page=news_item&px=Linux-x86-Boot-4.3">plus de détails sur <em>Phoronix.com</em></a>].<br>
Nous avons ainsi un gain de 700 µs sur trois correctifs et un peu d’élimination de code mort.</p>
<h4 id="une-meilleure-analyse-de-performance-sur-certains-processeurs">Une meilleure analyse de performance sur certains processeurs</h4>
<p><code>perf</code> est un outil déjà très puissant pour l’étude des performances sous Linux. Avec certains processeurs Intel, cette analyse pourra désormais être encore plus précise grâce à la récupération d’informations par <code>perf</code> directement sur la puce avec le <a href="https://software.intel.com/en-us/blogs/2013/09/18/processor-tracing"><em>processor trace</em></a> (PT). Parmi les promesses de ce matériel, on a notamment un meilleur suivi des applications avec plusieurs fils d’exécution (<em>threads</em>).</p>
<p>C’est bien entendu des développeurs d’Intel qui ont proposé l’ajout des modifications en plusieurs parties. On a ainsi dans le détail <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f4aa081949e7b6b01e711229c5a47ee3482a169c">un décodeur pour PT</a>, le <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=90e457f7be0870052724b2d9c2c106e5847f2c19">code pour gérer le PT</a>, l’ajout du <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5efb1d5489520ce72232bbc28e9156f0ebddc44e">nécessaire dans <code>perf</code></a>, un script d’<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4b715d24f4f14731c7b553cbb8604fe865cb8d3c">exemple de suivi de performance de PostgreSQL</a>.</p>
<h4 id="prise-en-chargearmv81">Prise en charge ARMv8.1</h4>
<p>Linux 4.3 prend désormais en charge l’architecture ARMv8.1 (disponible avec le <a href="http://www.cnx-software.com/2015/01/05/nvidia-tegra-x1/">Tegra X1</a>, par exemple). Cette dernière est une mise à jour mineure de la spécification ARMv8, qui apporte principalement la prise en charge des processeurs 64 bits dans le monde ARM. Les nouveautés implémentées pour ARMv8.1 sont le PAN, le LSE et la prise en charge de DBM.<br>
Le PAN est un acronyme en anglais pour <em>Privileged Access Never</em> — aucun accès privilégié — et représente la solution ARM pour empêcher les déréférencements dans le noyau.<br>
LSE, <em>Large System Extension</em> — extension système large — est utilisé pour construire des verrous et des opérations atomiques utilisables à grande échelle.<br>
Enfin, DBM — <em><a href="https://en.wikipedia.org/wiki/Dirty_bit">Dirty Bit Management</a></em> — est le système de gestion du bit « sale » qui sert principalement à la mise à jour propre et automatique des entrées dans la table des pages de la mémoire virtuelle paginée (<a href="https://fr.wikipedia.org/wiki/M%C3%A9moire_virtuelle#M.C3.A9moire_virtuelle_pagin.C3.A9e">PTE</a>).</p>
<p>[Article de CNXSoft : <a href="http://www.cnx-software.com/2015/11/04/linux-4-3-release-main-changes-arm-and-mips-architectures/"><em>Linux 4.3 Release — Main Changes, ARM and MIPS Architectures</em></a>]</p>
<h4 id="amélioration-de-la-prise-en-charge-des-systèmes-monopuces-arm">Amélioration de la prise en charge des systèmes monopuces ARM</h4>
<ul>
<li>
<p>Nouvelle prise en charge des systèmes monopuces 64 bits ARM suivants :</p>
<ol>
<li>Broadcom North Star 2 (pas encore disponible) ;</li>
<li>Marvell Berlin4CT (pas encore disponible) ;</li>
<li>Mediatek MT6795 (la réponse de Mediatek au SnapDragon 810 et sa volonté de venir sur le marché du haut de gamme) ; </li>
<li>
<a href="https://fr.wikipedia.org/wiki/Rockchip_RK3368">Rockchip RK3368</a> disponible par exemple <a href="https://plus.google.com/+charbax/posts/1EWmUYjnw9i"><em>ici</em></a>. C’est sans doute la carte ARM 64 bits la moins chère du marché.</li>
</ol>
</li>
<li><p>Plus de 23 000 lignes de code pour l’arborescence matérielle <em>DeviceTree</em>. Cela permet de prendre en charge dans le noyau principal les <a href="http://liliputing.com/2015/03/google-introduces-low-cost-chromebooks-for-education-with-rockchip-processors.html">Chromebooks Rockchip</a>, la <a href="https://community.freescale.com/thread/376844">carte d’évaluation i.MX6UL</a>, les modules <a href="https://store.gumstix.com/coms/overo-coms.html">Gumstix Overo</a> et le matériel <a href="http://pdf.directindustry.com/pdf/panasonic-industrial-robot-welding/panasonic-integrated-platform-digital-appliances-uniphier/29315-566484.html">UniPhier</a>.</p></li>
<li><p>Nouveaux pilotes Qualcomm SMM/SMD pour communiquer avec les coprocesseurs de certaines plates‐formes, ainsi que des ajouts pour Tegra (Tegra X1 et Denver).</p></li>
</ul><h4 id="mips-nest-pas-mort">MIPS n’est pas mort</h4>
<p>Ajout de la prise en charge du processeur 64 bits <a href="http://blog.imgtec.com/mips-processors/mips-i6400-the-leading-64-bit-cpu-revealed-coverage-roundup">MIPS I6400</a> et amélioration de la prise en charge des Octeon Cavium CN68xx.</p>
<h4 id="s390">s390</h4>
<p>Ajout intéressant, la prise en charge de la NUMA (<a href="https://fr.wikipedia.org/wiki/Non_Uniform_Memory_Access" title="Non Uniform Memory Access">architecture mémoire non unifiée, introduite par AMD dans son architecture Bulldozer</a>) pour s390. Enfin, la prise en charge d’une fausse NUMA, ou une NUMA purement logicielle, pour distribuer la mémoire sur les différents processeurs. Il semblerait que sous certaines circonstances, cela améliore les performances du système, et/ou sa latence.</p>
<h4 id="amd-carrizo">AMD Carrizo</h4>
<p>Linux 4.3 rend désormais disponibles, via le sous‐système <code>hwmon</code>, les informations énergétiques communiquées par les processeurs de la génération Carrizo d’AMD (les <a href="https://fr.wikipedia.org/wiki/Accelerated_processing_unit" title="Accelerated Processing Unit">APU</a> A10 par exemple).</p>
<h3 id="ipc">IPC</h3>
<p>KDBUS a reçu de <a href="https://www.phoronix.com/scan.php?page=news_item&px=KDBUS-Big-Updates">nombreuses modifications</a>. <a href="https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Rawhide-Kernel-KDBUS">Il était déjà utilisé dans Fedora <em>Rawhide</em></a> (la branche instable) depuis le 30 juillet, mais a été <a href="https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Drops-KDBUS">retiré récemment</a>. Certains aspects de KDBUS pourraient être repensés, ce qui signifie que l’intégration officielle de KBDUS dans Linux a peu de chances d’avoir lieu pendant le cycle de la version 4.4.</p>
<p>Pour rappel, l’intégration de KDBUS avait été <a href="https://www.phoronix.com/scan.php?page=news_item&px=KDBUS-Missing-Linux-4.1">proposée pour Linux 4.1</a> et a été <a href="https://www.phoronix.com/scan.php?page=news_item&px=KDBUS-Not-In-Linux-4.2">reportée durant le cycle de la 4.2</a>.</p>
<h3 id="développement">Développement</h3>
<ul>
<li>Introduction d’une nouvelle structure logicielle (<em>framework</em>) pour les pilotes de périphériques à mémoire non volatile qui devrait être utilisée lors de la sortie de la technologie <a href="https://fr.wikipedia.org/wiki/3D_XPoint">Intel 3D XPoint</a>. La <a href="https://www.kernel.org/doc/Documentation/nvmem/nvmem.txt">documentation de NVmem</a> (pour <em>Non Volatile memory layer</em>) est disponible sur le site <em>kernel.org</em>.</li>
<li>L’appel système <code>membarrier()</code> a enfin été intégré. C’est un correctif qui est en gestation depuis au moins 2010. Il permet de forcer la synchronisation entre processeurs, mais uniquement sur les processeurs qui font fonctionner l’application qui requiert cette synchronisation. Consultez l’<a href="https://lwn.net/Articles/369567/">article de <em>LWN.net</em></a>, en anglais, pour plus de détails.</li>
<li>La gestion des erreurs d’entrées‐sorties bloquantes a été simplifiée. Il y a désormais un nouveau champ <code>bi_error</code> dans la structure <em>bio</em> qui sert à stocker un code d’erreur. L’utilisation de <code>bi_end_ui()</code> a été supprimée.</li>
<li>Changement dans l’interface <code>static-key</code>, qui provoquait des confusions de nommage.</li>
<li>Le module de signature utilise désormais <a href="https://tools.ietf.org/html/rfc2315">PKCS#7</a>, ce qui nécessite d’avoir <em>openssl-devel</em> disponible pour construire le noyau avec ce module.</li>
</ul><h3 id="pilotes-graphiques-libres">Pilotes graphiques libres</h3>
<h4 id="direct-rendering-manager">Direct Rendering Manager</h4>
<p>Rien de bien intéressant dans le code commun des pilotes graphiques libres, si ce n’est des corrections de bogues dans la partie liée à la gestion atomique du mode graphique. Plusieurs nouveaux contrôleurs d’affichage sont maintenant <a href="http://lists.freedesktop.org/archives/dri-devel/2015-August/088489.html">gérés par Linux</a>.</p>
<p>Pour plus d’informations, vous pouvez consulter la <a href="https://lkml.org/lkml/2015/9/4/698">demande d’intégration de DRM</a>.</p>
<h4 id="amdati">AMD/ATI</h4>
<h5 id="pilote-de-rendu-nouvelle-génération-pilote-amdgpu">Pilote de rendu nouvelle génération (pilote amdgpu)</h5>
<p>Les cartes graphiques haut de gamme AMD R9 <em>Fiji</em> sont maintenant partiellement gérées par Linux. Cette famille a été commercialisée dès la fin du mois de juin 2015.</p>
<p>Autre nouveauté, l’ajout d’un ordonnanceur pour le processeur graphique. Son rôle est de répartir de manière plus juste les ressources de calcul du processeur graphique, mais aussi de donner la priorité aux applications les plus importantes. C’est notamment le cas du compositeur qui utilise le processeur graphique pour composer l’image à l’écran. Il a besoin de produire de façon prédictible la prochaine image avant la synchronisation verticale de l’écran, sous peine d’avoir à jeter les images qui ont été calculées, mais jamais affichées.</p>
<p>Pour plus d’informations, vous pouvez consulter <a href="http://lists.freedesktop.org/archives/dri-devel/2015-August/088642.html">les</a> <a href="http://lists.freedesktop.org/archives/dri-devel/2015-August/089261.html">demandes</a> <a href="http://lists.freedesktop.org/archives/dri-devel/2015-September/089813.html">d’intégration</a>.</p>
<h5 id="pilote-hsa-pilote-amdkfd">Pilote HSA (pilote amdkfd)</h5>
<p>AMD ajoute la gestion des processeurs à unité graphique intégrée (<a href="https://fr.wikipedia.org/wiki/Accelerated_processing_unit" title="Accelerated Processing Unit">APU</a>) Carrizo, sortis en juin 2015, au pilote <em>amdkfd</em>, qui permet de faire communiquer plus rapidement le processeur graphique et le processeur central.</p>
<p>Pour plus d’informations, vous pouvez consulter la <a href="https://www.spinics.net/lists/dri-devel/msg86504.html">demande d’intégration</a>.</p>
<h4 id="intel-pilote-i915">Intel (pilote i915)</h4>
<p>L’unité graphique des processeurs Intel Skylake <em>Gen9</em> est maintenant gérée par défaut et ne nécessite plus de passer d’argument au noyau.</p>
<p>Les autres nouveautés sont plus cachées, mais restent importantes. La plus notable est la gestion du mode graphique classique qui utilise maintenant le code de la gestion atomique, ce qui permet de tester ces parties de code un peu plus avant qu’elles puissent être activées par défaut.</p>
<p>Toujours du côté de l’affichage, la gestion des profondeurs de couleur de 12 bits par composante est maintenant disponible et activée par défaut pour le HDMI et les écrans compatibles.</p>
<p>Du côté de la gestion d’énergie, la fréquence de l’horloge du contrôleur d’affichage est maintenant dynamique, ce qui permet d’économiser de l’énergie lorsque des écrans à basse ou haute résolution (non 4K) sont présents. La gestion de la compression du tampon de trame (<em>framebuffer</em>), ainsi que la gestion du mode d’auto‐rafraîchissement de l’écran avancent encore, mais restent désactivées par défaut, car elles provoquent des blocages de l’écran sur certains systèmes.</p>
<p>Le code de suivi des requêtes, qui permet de savoir si une tâche soumise de façon asynchrone au processeur graphique a été exécutée ou pas encore, a été revu afin de prendre en charge la synchronisation entre plusieurs processeurs graphiques, mais également pour la venue éventuelle d’un ordonnanceur (voir la partie AMD). Ce travail n’est cependant pas encore terminé, la suite dans la prochaine dépêche noyau !</p>
<p>Pour plus d’informations, vous pouvez consulter l’<a href="http://blog.ffwll.ch/2015/09/neat-drmi915-stuff-for-43.html">article de blog du mainteneur i915</a>.</p>
<h4 id="matrox-pilote-mgag200">Matrox (pilote mgag200)</h4>
<p>Le pilote Matrox, qui n’avait pas reçu de modification depuis deux ans, vient de bénéficier de la gestion d’une nouvelle famille de processeurs graphiques, ainsi qu’une variante dans la famille précédente.</p>
<p>Pour plus d’informations, vous pouvez consulter les <a href="https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm?id=6d857c18aefdec782ba1db578a390fbac5145107">deux</a> <a href="https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm?id=e829d7ef9f17d7b84d4c3d110ecd4b7b2bcba865"><em>commits</em></a>.</p>
<h4 id="nvidia-pilote-nouveau">NVIDIA (pilote nouveau)</h4>
<p>Nouveau n’avait pas reçu de changement dans Linux 4.2, car un gros changement était en cours. Il fait son entrée dans Linux 4.3 et modifie la façon dont les différents modules sont initialisés et utilisés, afin que le compilateur puisse plus facilement détecter des erreurs d’accès. Le code qui en résulte est, de plus, bien plus simple à lire et modifier.</p>
<p>Ben Skeggs en a également profité pour revoir l’interface NVIF. Cette dernière a pour but d’exposer à l’espace utilisateur ou à des machines virtuelles les objets internes à Nouveau. Cette interface n’a encore jamais été utilisée. Ce changement n’est donc pas problématique.</p>
<p>NVIDIA, par le biais d’Alexandre Courbot, a ajouté le code de gestion préliminaire pour les processeurs Tegra basés sur l’architecture Maxwell (<a href="http://nouveau.freedesktop.org/wiki/CodeNames/">GM20B</a>). Cette gestion est cependant inutilisable, car elle <a href="https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm?id=8539b37acef73949861a16808b60cb8b5b9b3bab">requiert un microcode signé par NVIDIA</a> qui n’a pas encore été rendu public. Ce processeur est maintenant facilement accessible aux passionnés grâce à la carte de développement <a href="http://www.nvidia.com/object/jetson-tx1-module.html">Jetson TX1</a>.</p>
<p>Samuel Pitoiset a retravaillé le code de configuration et lecture des compteurs de performance globaux avant d’ajouter la gestion des compteurs qu’il a effectuée en rétro‐ingénierie pour les familles <a href="http://nouveau.freedesktop.org/wiki/CodeNames/#nv50familytesla">NV50</a> et <a href="http://nouveau.freedesktop.org/wiki/CodeNames/#nvc0familyfermi">NVC0</a>. Pour l’instant, peu de signaux sont reconnus pour la famille NVC0, mais le travail de rétro-ingénierie devrait reprendre, quand l’infrastructure au complet sera en place. À cette fin, il manque une bibliothèque en espace utilisateur pour accéder à l’interface NVIF <a href="//linuxfr.org/news/sortie-de-linux-3-17#nvidia-pilote-nouveau">introduite dans Linux 3.17</a> pour Nouveau et modifiée dans Linux 4.3. Il restera ensuite à modifier <a href="https://fr.wikipedia.org/wiki/Mesa_3D">Mesa 3D</a> pour exposer ces compteurs via l’interface OpenGL <a href="https://www.opengl.org/registry/specs/AMD/performance_monitor.txt"><code>GL_AMD_performance_monitor</code></a> et l’afficheur tête haute de <a href="https://fr.wikipedia.org/wiki/Gallium3D" title="Définition Wikipédia">Gallium3D</a> <a href="http://www.mesa3d.org/envvars.html"><code>GALLIUM_HUD</code></a>. Ces modifications sont le fruit d’un travail de longue haleine de la part de Samuel. Il a commencé à travailler sur ce sujet lors du <em>Google Summer of Code 2013</em>. Une page détaillant l’<a href="http://nouveau.freedesktop.org/wiki/PerformanceCounters/">état d’avancement</a> de l’implémentation de la gestion des compteurs de performance est en cours de construction.</p>
<p>Roy Spliet a ajouté la gestion du recadencement manuel pour les cartes <a href="http://nouveau.freedesktop.org/wiki/CodeNames/">NVA0</a> et l’a activée par défaut. </p>
<p>Pour plus d’informations, vous pouvez consulter la <a href="https://www.youtube.com/watch?v=dnG0X0uwLuY">présentation récapitulative de l’état du pilote</a> faite au <a href="http://www.x.org/wiki/Events/XDC2015/" title="X.Org Developer’s Conference 2015">XDC2015</a> par Alexandre Courbot (NVIDIA) et Martin Peres (hobbyiste) ou sa <a href="http://lwn.net/Articles/659391/">transcription faite par <em>LWN.net</em></a>.</p>
<h4 id="vmware-pilote-vmwgfx">VMware (pilote vmwgfx)</h4>
<p>Le pilote <em>vmwgfx</em> de VMware a reçu d’importantes modifications ayant pour but de pouvoir exposer OpenGL 3.3 dans les machines virtuelles.</p>
<p>Les modifications apportées sont l’utilisation d’une nouvelle interface de programmation pour la gestion des tampons de trame (<em>frame buffer</em>), un nouveau mécanisme d’envoi de commandes qui remplace l’ancien tampon circulaire et la gestion d’un nouveau périphérique virtuel appelé DX qui permet d’obtenir la gestion d’OpenGL 3.3.</p>
<p>Les modifications apportées à <a href="https://fr.wikipedia.org/wiki/Mesa_3D">Mesa 3D</a> (pilote 3D en espace utilisateur) nécessaires pour atteindre OpenGL 3.3 sont actuellement disponibles dans la branche de développement de Mesa 3D et devraient être disponibles prochainement, dans Mesa 3D 11.1.</p>
<p>Pour plus d’informations, vous pouvez consulter la <a href="http://lists.freedesktop.org/archives/dri-devel/2015-August/088455.html">demande d’intégration <em>vmwgfx</em></a>, ainsi que le <a href="http://lists.freedesktop.org/archives/dri-devel/2015-August/088246.html">courriel d’annonce de la fonctionnalité</a>.</p>
<h4 id="pilotes-graphiques-pour-systèmes-monopuces">Pilotes graphiques pour systèmes monopuces</h4>
<h5 id="qualcomm-snapdragon-pilote-msm">Qualcomm Snapdragon (pilote msm)</h5>
<ul>
<li>prise en charge des cartes de développement DragonBoard 410c (les puces ADV7533 nécessitant encore du travail) ;</li>
<li>prise en charge initiale des MSM8x94 (Snapdragon 810) ;</li>
<li>prise en charge des MSM8x74v1 (ajoutée à celle de la v2 existante) ;</li>
<li>prise en charge des plans DMA sur les MDP5 (plans additionnels ne pouvant pas être rééchelonnés) ;</li>
<li>ajout de nouveaux formats d’espace colorimétrique <a href="https://fr.wikipedia.org/wiki/YUV" title="Définition Wikipédia">YUV</a> aux MDP5 (simple plan VYUY, UYVY, YUYV et YVYU ; double plan NV16 et NV61 ; et triple plan YUV420 et YVU420) ;</li>
<li>prise en charge de la rotation pour les MDP5 ;</li>
<li>prise en charge initiale de la protection anticopie <a href="https://fr.wikipedia.org/wiki/HDCP" title="Définition Wikipédia">HDCP</a> ;</li>
<li>corrections diverses, etc.</li>
</ul><h5 id="freescale">Freescale</h5>
<p>Nouveau pilote <em>fsl-dcu</em> prenant en charge la gestion des modes d’affichage du DCU (<em>Display Controller Unit</em>) des systèmes monopuces de Freescale.</p>
<h3 id="réseau">Réseau</h3>
<h4 id="prise-en-charge-initiale-des-vrf">Prise en charge initiale des VRF</h4>
<p>Derrière l’idée des VRF, ou <em>Virtual Routing and Forwarding</em>, se cache le fait d’avoir plusieurs tables de routage, afin de se comporter différemment selon l’environnement. Le premier exemple est un équipement en production dont on planifie des changements dans son routage. Grâce aux VRF, l’administrateur pourra conserver la configuration actuelle dans une table et préparer la table à déployer dans un autre VRF. Un autre exemple serait une <a href="//linuxfr.org/forums/linux-general/posts/faire-passer-uniquement-le-trafic-d-un-logiciel-par-un-vpn">application spécifique qui doit utiliser une règle de routage différente</a>.</p>
<p>Cette fonctionnalité s’insère de façon peu intrusive pour qui veut l’utiliser. En effet, il y a déjà des fonctionnalités avancées de routage dans le noyau (notamment configurables avec <code>ip rule</code>), qui permettent de faire du routage en fonction de l’adresse IP source, d’un marquage du pare‐feu, etc. Et pour les applications, on peut utiliser l’option <code>SO_BINDTODEVICE</code> (<code>ping -I</code> par exemple) pour choisir l’interface. On a déjà presque tout : il faut juste lier le domaine de routage (la VRF) à une interface virtuelle (et donc la créer) et gérer les quelques détails (l’isolation <a href="https://fr.wikipedia.org/wiki/Address_Resolution_Protocol" title="Address Resolution Protocol">ARP</a> entre les différents domaines notamment).</p>
<p>C’est ce que propose cette <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d52736e24fe2e927c26817256f8d1a3c8b5d51a0">demande de changement</a>. À noter que la fonctionnalité n’est pas encore complètement terminée, on ne peut notamment pas utiliser de VRF en IPv6.</p>
<h4 id="ipv6">IPv6</h4>
<h5 id="compilation-par-défaut-dans-le-noyau">Compilation par défaut dans le noyau</h5>
<p>C’est une nouveauté qui n’est pas passée inaperçue, le code pour IPv6 est désormais compilé par défaut dans l’image du noyau (la compilation en module était auparavant le mode par défaut). Il s’agit avant tout d’une décision symbolique, la plupart des grandes distributions ayant déjà configuré leurs noyaux ainsi.</p>
<p>Les détails, dans la <a href="http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=de551f2eb22a77a498cea9686f39e79f25329109">demande de modification</a>.</p>
<h5 id="ajout-des-identifier-locator-addressing-à-ipv6--le-retour-de-la-dualité-des-ip">Ajout des <em>Identifier Locator Addressing</em> à IPv6 — le retour de la dualité des IP</h5>
<p>Les <em>Identifier Locator Addressing</em> (ILA) sont une nouvelle méthode pour tenter de résoudre un bon vieux problème des protocoles IP : une adresse IP est utilisée actuellement à la fois comme identifiant d’équipement et comme information de localisation.<br>
Pour le premier cas, vous pouvez ainsi penser à l’utilisation des adresses IP source et destination, pour relier (en complément des numéros de ports) un paquet à une <a href="https://fr.wikipedia.org/wiki/Berkeley_sockets"><em>socket</em></a> <a href="https://fr.wikipedia.org/wiki/Transmission_Control_Protocol">TCP</a>.<br>
Pour le second cas, on parle du routage : l’adresse est lue par les routeurs et permet d’envoyer le paquet au bon endroit.<br>
Le premier problème évident avec cette architecture est la mobilité. L’équipement (et on espère donc son identifiant) ne change pas, mais sa localisation si. Un autre souci est le <a href="https://fr.wikipedia.org/wiki/Multi-homing"><em>multi‐homing</em></a>, c’est‐à‐dire avoir plusieurs fournisseurs d’accès pour un équipement. L’équipement aura plusieurs adresses IP, mais on aimerait qu’il puisse être identifié de façon identique avec les deux.</p>
<p>Cette dualité de l’adresse IP est bien documentée, par exemple dans la <a href="https://tools.ietf.org/html/rfc4984#section-2.2">RFC 4984</a>, et en français sur le <a href="http://www.bortzmeyer.org/separation-identificateur-localisateur.html"><em>blog</em> de Stéphane Bortzmeyer</a>. Il y a même des protocoles, comme <a href="https://fr.wikipedia.org/wiki/Locator/Identifier_Separation_Protocol" title="Locator/Identifier Separation Protocol">LISP</a>, qui devraient permettre d’y remédier s’ils sont déployés.</p>
<p>Les ILA qui nous intéressent ici visent un cas d’utilisation bien précis : les machines virtuelles et les services construits pour pouvoir être migrés entre différents serveurs physiques (et donc changer de localisation). La principale motivation de ce travail est le rejet de l’existant, notamment la volonté d’avoir un protocole sans encapsulation (ce que fait LISP) ni en‐têtes supplémentaires dans le paquet IP. Le paquet sera ainsi pleinement traitable par un équipement intermédiaire standard (routeur, pare‐feu…) sans aucune mise à jour. L’encapsulation étant coûteuse en ressource, cette motivation est très compréhensible.</p>
<p>Rentrons dans le concret : l’idée est de prendre le format d’une adresse IPv6 standard et de la couper en deux. La première partie sera la localisation (lue par le routage jusqu’à joindre la machine physique du service), la seconde partie servira d’identification (sans aucun lien avec une interface physique). Une application n’a besoin que de la seconde partie, la première moitié sera ajoutée par le noyau lors de l’émission du paquet (qui lui aura l’information de la localisation réelle du service). Pour des questions de compatibilité, les applications rempliront en réalité la première partie avec les informations qu’elles possèdent (exemple : le résultat d’une requête DNS) et le noyau se chargera de récrire les 64 premiers bits (la partie de localisation). C’est le mécanisme de réécriture d’adresse connu habituellement sous le nom de <a href="https://fr.wikipedia.org/wiki/Network_address_translation" title="Network Address Translation">NAT</a>, mais utilisé en local.</p>
<p>La configuration de tout ça se fait actuellement à l’aide de la commande <code>ip</code>, en rajoutant des liens (<em>mapping</em>) statiques entre l’identifiant et sa localisation. Si vous voulez quelque chose de vraiment dynamique, il manque donc la partie en espace utilisateur pour mettre à jour les localisations des services.</p>
<p>Au niveau de la sécurité, c’est léger, mais documenté par l’auteur. L’absence d’en‐tête supplémentaire empêche également l’ajout d’information pour assurer à l’application que le destinataire qu’il croit contacter à l’aide de l’identifiant est bien l’équipement réellement contacté. Cette technologie ne devra être utilisée que sur des réseaux bien maîtrisés, ce qui permet la simplicité du mécanisme pour un problème aussi complexe.</p>
<p>Pour plus d’informations, il y a tout d’abord la <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0b233dc7167884f95f08e796ac6a6767ae7d0d70">demande de changement</a>, qui détaille notamment la (faible) dégradation de performance. Il y a également un <a href="https://lwn.net/Articles/657012/">article sur <em>LWN.net</em></a> et un <a href="https://tools.ietf.org/html/draft-herbert-nvo3-ila-01"><em>draft</em> à l’IETF</a> (écrit par l’auteur du code du noyau Linux. Vous pouvez également constater son changement d’employeur entre la v0 et la v1 du <em>draft</em>).</p>
<h4 id="suivi-des-connexions-openvswitch">Suivi des connexions Open vSwitch</h4>
<p>Quand vous avez de nombreuses machines virtuelles, réparties ou non sur différents hyperviseurs, vous avez probablement également envie de virtualiser la commutation des paquets (<em>switching</em>) entre les différentes machines virtuelles, afin qu’il soit transparent de migrer des services et d’avoir de bonnes performances.</p>
<p>Sous Linux, <a href="https://en.wikipedia.org/wiki/Open_vSwitch">Open vSwitch</a> est une solution pour remplir ce rôle. Et dans ce nouveau noyau, un utilisateur peut désormais <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7f8a436eaa2c3ddd8e1ff2fbca267e6275085536">suivre l’état des connexions Open vSwitch</a>.</p>
<h4 id="performances">Performances</h4>
<h5 id="de-la-qualité-de-service-plus-rapide">De la qualité de service plus rapide</h5>
<p>Que serait un nouveau noyau sans des optimisations de performance en réseau ? Pour cette version, on peut citer des changements pour <a href="//linuxfr.org/wiki/une-introduction-au-controle-du-trafic-reseau-avec-linux"><code>tc</code></a> (<em>traffic control</em>), qui permet de gérer la qualité de service (limiter un utilisateur à un débit, rendre prioritaire certains usages, etc.). Dans la <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=56e5d1ca183d8616fab377d7d466c244b4dbb3b9">demande de changement</a>, l’auteur parle d’un passage sur son environnement de 5 millions de paquets traités par seconde à 11 millions désormais.</p>
<h5 id="tunnels-légers">Tunnels légers</h5>
<p>Malgré les dégradations de performance de l’encapsulation réseau, qui ont été une des motivations du concept des ILA décrites précédemment, encapsuler et décapsuler des paquets est une opération très courante dans les réseaux IP. Pour le grand public, l’une des opérations classiques est notamment d’utiliser un <a href="https://fr.wikipedia.org/wiki/R%C3%A9seau_priv%C3%A9_virtuel">réseau privé virtuel</a> (VPN pour les intimes). Pour les centres de données, Open vSwitch (OVS) fait également de l’encapsulation.</p>
<p>Améliorer les performances et avoir une approche un peu unifiée pour l’encapsulation présente donc un avantage et <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e69724f32e62502a6e686eae36b7aadfeea60dca">une demande de changement</a> dans ce sens a été proposée. <em>A priori</em>, cette approche devrait permettre d’obtenir de meilleures performances et de mieux passer à l’échelle. Les encapsulations pour OVS et <a href="https://fr.wikipedia.org/wiki/Multiprotocol_Label_Switching" title="Multiprotocol Label Switching">MPLS</a> (très récemment introduit en version 4.1 du noyau) utilisent déjà cette nouvelle interface.</p>
<p>Si vous avez du mal à être convaincu que ce changement est important, vous pouvez lire le début du <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dd5cdb48edfd34401799056a9acf61078d773f90">courriel résumant les changements réseau</a> de ce noyau.</p>
<h4 id="nouveau-pilote">Nouveau pilote</h4>
<p>Si les performances dans le noyau sont essentielles, certains fabricants produisent du matériel capable de très fortement diminuer la tâche du noyau en effectuant de très nombreuses opérations directement dans le matériel. Le <a href="http://www.mellanox.com/page/products_dyn?product_family=145&mtag=switchx_2_vpi">processeur SwitchX-2</a> entre dans cette catégorie et peut désormais être utilisé avec Linux grâce aux changements [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=93c1edb27f9e7ef7f276b91763c93242bbda71cb"><em>1</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=31557f0f9755696530d08465cf9940404f2d48e2"><em>2</em></a> et <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4ec14b7634b298186f18f65d959354dc3c60e02c"><em>3</em></a>]. Avec ce matériel, il devient en théorie possible de construire de gros commutateurs (<em>switchs</em>) performants avec un noyau Linux. Il a suffi d’<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0c4f691ff6791e55ac831666df0b49b1679c56e4">adapter le code</a> pour ne pas commuter en logiciel un paquet déjà commuté par la carte.</p>
<h4 id="un-peu-dhumain">Un peu d’humain</h4>
<p>Si cette nouvelle version est riche en améliorations réseau, l’ambiance sur la liste de diffusion n’a pas toujours été au beau fixe. Linus Torvalds a notamment réagi à la demande d’intégration de la partie réseau par un :</p>
<blockquote>
<p>« <em>Christ, people. Learn C, instead of just stringing random characters together until it compiles (with warnings).</em> »</p>
</blockquote>
<p>Que l’on pourrait traduire par :</p>
<blockquote>
<p><em>Bon dieu, les gars. Apprenez le C, au lieu d’enchaîner des caractères au hasard jusqu’à ce que ça compile (avec des alertes).</em></p>
</blockquote>
<p>Vous pouvez retrouver le <a href="https://lkml.org/lkml/2015/9/3/428">courriel complet</a> dans les archives de la liste.<br>
Cet incident, bien que postérieur à ce qui va suivre, est peut‐être à rapprocher avec l’annonce du départ de la développeuse qui maintenait les pilotes USB3, qui <a href="http://www.theregister.co.uk/2015/10/06/linix_kernel_dev_who_asked_linus_torvalds_to_stop_swearing_quits_over_swearing/">critique notamment le manque de respect</a> sur les différentes listes de diffusion du noyau.</p>
<h3 id="sécurité">Sécurité</h3>
<h4 id="antiforkbomb">Anti‐fork‐bomb</h4>
<p>Un mécanisme <em>anti‐<a href="https://fr.wikipedia.org/wiki/Fork_bomb">fork‐bomb</a></em> a été ajouté au noyau. Il se base sur un ajout récent du noyau, les <em>cgroups_pid</em>. Ce correctif introduit une nouvelle option, <em>fork_remaining</em>. Cette valeur est décrémentée à chaque appel système <a href="https://fr.wikipedia.org/wiki/Fork_%28programmation%29"><code>fork()</code></a>. Lorsqu’elle atteint zéro, le noyau refuse les <em>forks</em> supplémentaires. La valeur <em>unlimited</em> permet de désactiver cette limite.</p>
<p>Un petit exemple :</p>
<pre><code class="bash">mkdir /sys/fs/cgroup/pids/parent
<span class="nb">echo </span><span class="m">2</span> > /sys/fs/cgroup/pids/parent/pids.fork_remaining
<span class="nb">echo</span> <span class="nv">$$</span> > /sys/fs/cgroup/pids/parent/cgroup.procs
cat /sys/fs/cgroup/pids/parent/pids.fork_remaining
1
cat /sys/fs/cgroup/pids/parent/pids.fork_remaining
0
cat /sys/fs/cgroup/pids/parent/pids.fork_remaining
sh: fork: Resource temporary unavailable</code></pre>
<h4 id="révision-de-lhéritage-des-capabilities">Révision de l’héritage des <em>capabilities</em>
</h4>
<p>Les capacités (<em>capabilities</em>) sont une extension de la gestion des droits d’un programme permettant d’effectuer des tâches habituellement réservées au super‐utilisateur <em>root</em> (ou un programme marqué <a href="https://fr.wikipedia.org/wiki/Setuid"><em>setuid</em></a>). Ces capacités peuvent être ajoutées au niveau d’une tâche en cours (grâce à <code>CAP_SETPCAP</code>) ou bien au niveau d’un fichier (vous pouvez essayer <code>getcap /bin/ping</code>, par exemple).</p>
<p>Toucher aux capacités est toujours un problème difficile, la moindre modification risquant de se transformer en faille de sécurité. <a href="http://lwn.net/Articles/632520/">L’héritage</a> de ses capacités, permettant à un programme de déléguer ses pouvoirs spéciaux à une sous‐tâche, est notamment très discuté.</p>
<p>L’argumentation de Andy Lutomirski, développeur du noyau, est que l’héritage proposé actuellement est, justement, totalement inutile si vous n’êtes pas <em>root</em>. Pour le faire fonctionner correctement, il faut marquer manuellement chaque fichier concerné. Dans la vraie vie, personne ne le fait, car c’est proche d’un travail d’Hercule et qu’en plus de nombreux systèmes de fichiers ne le permettent pas.</p>
<p>Il propose donc l’ajout d’un masque d’environnement, simplifiant l’héritage et le rendant fonctionnel. Si vous voulez les détails de la complexité du problème et de l’implémentation, vous pouvez lire la <a href="http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=58319057b7847667f0c9585b9de0e8932b0fdb08">demande de changement</a>.</p>
<h3 id="systèmes-de-fichiers">Systèmes de fichiers</h3>
<p>Les changements dans les systèmes de fichiers pour cette version sont majoritairement constitués de corrections et de nettoyages.</p>
<h4 id="btrfs">Btrfs</h4>
<p>Btrfs reçoit une correction du <a href="https://fr.wikipedia.org/wiki/Trim_%28informatique%29"><em>trim</em></a> pour quelques cas particuliers où les <em>trims</em> étaient manquants. Il reçoit également des corrections pour RAID 5 et RAID 6, en particulier pour le <a href="https://en.wikipedia.org/wiki/Data_scrubbing">nettoyage de données</a> et le remplacement de périphériques quand plusieurs sont manquants. Les nouveautés concernent aussi la prise en charge de nouveaux contrôleurs <em>blkio</em> pour un seul périphérique (gestion de plusieurs périphériques prévue), ainsi que des corrections et nettoyages divers.</p>
<p>Pour plus d’informations, vous pouvez consulter la [<a href="http://lkml.iu.edu/hypermail/linux/kernel/1509.0/02784.html"><em>demande de modification</em></a>].</p>
<h4 id="ext3">ext3</h4>
<p>Le code concernant ext3 a été supprimé. Désormais, les systèmes de fichiers ext3 devront être montés avec le mode de compatibilité d’ext4. Dans la pratique, cela fait plusieurs années que de nombreuses distributions le font déjà, ce qui a servi à montrer que le code d’ext4 était assez stable pour remplacer celui d’ext3.</p>
<p>Si le changement n’affectera pas l’espace utilisateur, cela permet de supprimer 28 000 lignes de code et de supprimer des contournements spécifiques à ext3 dans la mémoire virtuelle du noyau et les couches bloc. D’autre part, cela simplifie la maintenance, car il fallait vérifier à chaque fois si une correction de bogue dans ext4 concernait ext3 pour être manuellement portée.</p>
<p>[source : <a href="http://lkml.iu.edu/hypermail/linux/kernel/1508.3/05063.html">LKML</a>]</p>
<p>Le système de fichiers ext2 n’a pas été supprimé car, <a href="http://lkml.iu.edu/hypermail/linux/kernel/1508.3/05063.html">d’après Theodore Ts’o</a> :</p>
<blockquote>
<p><em>C’est un système de fichiers simple qui permet de comprendre facilement ce qui est nécessaire pour créer un nouveau système de fichiers.</em></p>
</blockquote>
<h4 id="ext4">ext4</h4>
<p>Comme d’habitude, il y a principalement des corrections de bogues, en particulier sur les quelques ajouts et modifications apportés à <a href="//linuxfr.org/news/sortie-du-noyau-linux-4-2#ext4">Linux 4.2</a> (voir les <a href="http://lkml.iu.edu/hypermail/linux/kernel/1506.3/00768.html">détails sur LKML</a>).</p>
<p>[source : <a href="https://www.phoronix.com/scan.php?page=news_item&px=EXT4-Updates-Linux-4.3"><em>Phoronix.com</em></a>]</p>
<h4 id="f2fs">F2FS</h4>
<p>F2FS est un système de fichiers adapté aux SSD et autres supports de stockage <em>Flash</em>. Pour cette version de noyau, nous n’avons pas de nouveauté importante, mais pas mal de petits changements, comme l’amélioration et la correction des <em>extent_caches</em>, qui est maintenant une option de montage par défaut.</p>
<p>Un travail non négligeable a été également mené pour éviter des problèmes de performance dus à la mémoire (limiter les requêtes de pages mémoire).</p>
<p>De plus, un nouvel appel <code>ioctl()</code> a été ajouté, <code>ioctl(F2FS_GARBAGE_COLLECT)</code>, qui permet à l’utilisateur de faire explicitement une requête de nettoyage des tâches en cours.</p>
<h4 id="xfs">XFS</h4>
<ul>
<li>gestion des cycles de vie d’EFI/EFD retravaillée pour corriger des corruptions de journaux de récupération, des plantages et des attentes lors de démontage ;</li>
<li>métadonnées UUID séparées sur le disque afin d’activer le changement de l’étiquette d’amorçage UUID pour les systèmes de fichiers en version 5 ;</li>
<li>correction de mauvaises compilations de <em>gcc</em> pour certaines plates‐formes et certains niveaux d’optimisation ;</li>
<li>correction de l’allocation d’attributs distante et de la récupération de données corrompues ;</li>
<li>correction des annotations des vérificateurs de verrous (<a href="https://www.kernel.org/doc/Documentation/locking/lockdep-design.txt"><em>lockdeps</em></a>) des nœuds d’index (<em>inodes</em>) générant des erreurs avec de trop nombreuses sous‐classes ;</li>
<li>modifications du verrouillage des nœuds d’index (<em>inodes</em>) de répertoires afin d’éviter que les vérificateurs de verrous <a href="https://www.kernel.org/doc/Documentation/locking/lockdep-design.txt"><em>lockdeps</em></a> ne génèrent de faux positifs ;</li>
<li>une poignée de corrections de corruptions mineures ;</li>
<li>divers autres petits nettoyages et corrections.</li>
</ul><p>Pour plus d’informations, vous pouvez consulter la <a href="http://lkml.iu.edu/hypermail/linux/kernel/1509.0/03565.html">demande de modification</a>.</p>
<h3 id="virtualisation">Virtualisation</h3>
<h4 id="kvm">KVM</h4>
<p>Comme d’habitude, les correctifs sont arrivés en deux lots, <a href="https://lkml.org/lkml/2015/8/14/643">le premier</a> avant les vacances de Paolo Bonzini (mainteneur KVM) et <a href="https://lkml.org/lkml/2015/9/10/266">le deuxième</a> au retour de ses vacances. Il n’y a quasiment que des corrections de bogues et peu de nouveautés :</p>
<ul>
<li>ARM : prise en charge complète du débogage sur ARM64, changement d’état actif pour les interruptions de l’horloge, sauvegarde et restauration fainéante pour les registres de calcul flottant et SIMD pour ARM64, une cible générique ARMv8 (pour ne pas avoir à cibler un processeur particulier) ;</li>
<li>PowerPC : activation du <em>microthreading</em> pour POWER8 ;</li>
<li>x86 : prise en charge du MSR (<em>Memory Service Routine</em>) Hyper-V (l’hyperviseur de Windows) pour stocker les informations en cas de plantage.</li>
</ul><h4 id="xen">Xen</h4>
<p>Peu de <a href="https://lkml.org/lkml/2015/9/8/495">nouveautés</a> de même de ce côté (pourtant personne n’a annoncé de vacances) :</p>
<ul>
<li>conversion du pilote <em>xen-blkfront</em> à l’API <em>multiqueue</em> ;</li>
<li>prise en charge des invités paravirtualisés de plus de 512 Gio sur x86 (cette fonctionnalité est cependant désactivée par défaut, car ils ne peuvent pas être migrés avec les outils actuels) ;</li>
<li>toujours sur x86, prise en charge du PMU (outils d’analyse de performance utilisant <code>perf</code>) sur le domaine principal <em>dom0</em> ;</li>
<li>sur ARM, prise en charge de l’attachement de canaux de communication d’événements à plusieurs processeurs virtuels.</li>
</ul><h2 id="le-bilan-en-chiffres">Le bilan en chiffres</h2>
<p><img src="//img.linuxfr.org/img/687474703a2f2f64616d62616c6c612e616c77617973646174612e6e65742f65766f6c6e626c69676e65342e332e706e67/evolnbligne4.3.png" alt="Évolution globale du nombre de lignes de code dans le noyau" title="Évolution globale du nombre de lignes de code dans le noyau | Source : http://damballa.alwaysdata.net/evolnbligne4.3.png"></p>
<p><img src="//img.linuxfr.org/img/687474703a2f2f64616d62616c6c612e616c77617973646174612e6e65742f696e73657273757070342e332e706e67/insersupp4.3.png" alt="Nombre d’insertions et de suppressions depuis la version 3.0" title="Nombre d’insertions et de suppressions depuis la version 3.0 | Source : http://damballa.alwaysdata.net/insersupp4.3.png"></p>
<h2 id="appel-à-volontaires">Appel à volontaires</h2>
<p>Cette dépêche a nécessité plus de 790 éditions (à l’heure de l’écriture de ces statistiques) et a mobilisé 19 personnes du 14 septembre au 29 novembre dans l’espace de rédaction.</p>
<p><img src="//img.linuxfr.org/img/687474703a2f2f64616d62616c6c612e616c77617973646174612e6e65742f70656f706c655f6c696e757866725f6b65726e656c34332e706e67/people_linuxfr_kernel43.png" alt="Répartition des contributions à cette dépêche" title="Répartition des contributions à cette dépêche | Source : http://damballa.alwaysdata.net/people_linuxfr_kernel43.png"></p>
<p>Cette dépêche a été rédigée par plusieurs contributeurs, dont voici la répartition :</p>
<table>
<thead><tr>
<th></th>
<th>Mainteneur</th>
<th>Contributeur(s)</th>
</tr></thead>
<tbody>
<tr>
<td><strong>La phase de test</strong></td>
<td>aucun</td>
<td>aucun</td>
</tr>
<tr>
<td><strong>Arch</strong></td>
<td><a href="//linuxfr.org/users/rperier">Romain Perier</a></td>
<td>
<a href="//linuxfr.org/users/tiwaz"><em>Tiwaz</em></a>, <a href="//linuxfr.org/users/ffourcot">Florent Fourcot</a>
</td>
</tr>
<tr>
<td><strong>IPC</strong></td>
<td>aucun</td>
<td><a href="//linuxfr.org/users/sinma"><em>ariasuni</em></a></td>
</tr>
<tr>
<td><strong>Développement</strong></td>
<td>aucun</td>
<td><a href="//linuxfr.org/users/tiwaz"><em>Tiwaz</em></a></td>
</tr>
<tr>
<td><strong>Pilotes graphiques libres</strong></td>
<td><a href="//linuxfr.org/users/mupuf">Martin Peres</a></td>
<td>aucun</td>
</tr>
<tr>
<td><strong>Réseau</strong></td>
<td>aucun</td>
<td>
<a href="//linuxfr.org/users/ffourcot">Florent Fourcot</a>, <a href="//linuxfr.org/users/tiwaz"><em>Tiwaz</em></a>
</td>
</tr>
<tr>
<td><strong>Systèmes de fichiers</strong></td>
<td>aucun</td>
<td>
<a href="//linuxfr.org/users/sinma"><em>ariasuni</em></a>, <a href="//linuxfr.org/users/tiwaz"><em>Tiwaz</em></a>
</td>
</tr>
<tr>
<td><strong>Sécurité</strong></td>
<td>aucun</td>
<td>
<a href="//linuxfr.org/users/ffourcot">Florent Fourcot</a>, <a href="//linuxfr.org/users/tiwaz"><em>Tiwaz</em></a>
</td>
</tr>
<tr>
<td><strong>Virtualisation</strong></td>
<td><a href="//linuxfr.org/users/claudex">Xavier Claude</a></td>
<td>aucun</td>
</tr>
<tr>
<td><strong>Édition générale</strong></td>
<td>aucun</td>
<td>
<a href="//linuxfr.org/users/jcr83"><em>jcr83</em></a>, <a href="//linuxfr.org/users/davy78">Davy Defaud</a>, <a href="//linuxfr.org/users/eggman"><em>eggman</em></a>, <a href="//linuxfr.org/users/m5oul"><em>Moul</em></a>
</td>
</tr>
</tbody>
</table><p>Un peu de vocabulaire :</p>
<ul>
<li>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 ;</li>
<li>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.</li>
</ul><p>Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps et de volontaires.</p>
<blockquote>
<p>Nous sommes particulièrement à la recherche de mainteneurs pour les sections <em>Systèmes de fichiers</em>, <em>Réseau</em>, <em>Développement</em> et <em>IPC</em>, les précédents n’ayant pas donné de signes de vie pendant la rédaction des dernières dépêches.</p>
</blockquote>
<p>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 <em>commits</em> 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 !<br>
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 !</p></div><div><a href="https://linuxfr.org/news/sortie-du-noyau-linux-4-3.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/106772/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/sortie-du-noyau-linux-4-3#comments">ouvrir dans le navigateur</a>
</p>
jcr83Davy DefaudesdeemFlorent FourcotTiwazMartin PeresM5oulariasuniChristopheBenoît Sibaudclaudexpalm123BAudmedcosmocatCreakJarvisʭ ☯ rogoStrashhttps://linuxfr.org/nodes/106772/comments.atomtag:linuxfr.org,2005:News/365952015-09-16T16:23:09+02:002015-11-09T02:14:40+01:00Sortie du noyau Linux 4.2Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>La sortie de la version stable 4.2 du noyau Linux a été annoncée le 30 août 2015 par Linus Torvalds. Le nouveau noyau est, comme d'habitude, téléchargeable sur les serveurs du site <a href="http://kernel.org/"><em>kernel.org</em></a>.</p>
<p>Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche (qui est sous <a href="http://creativecommons.org/licenses/by-sa/3.0/deed.fr">licence CC BY-SA</a>, Attribution - Partage dans les Mêmes Conditions).</p></div><ul><li>lien nᵒ 1 : <a title="https://linuxfr.org/wiki/depeches_noyau" hreflang="fr" href="https://linuxfr.org/redirect/94896">Dépêches des noyaux précédents</a></li><li>lien nᵒ 2 : <a title="https://www.kernel.org/" hreflang="en" href="https://linuxfr.org/redirect/94897"> Site officiel du noyau Linux</a></li></ul><div><h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li>
<a href="#annonces-des-rc-par-linus-torvalds">Annonces des RC par Linus Torvalds</a><ul>
<li><a href="#rc-1">RC-1</a></li>
<li><a href="#rc-2">RC-2</a></li>
<li><a href="#rc-3">RC-3</a></li>
<li><a href="#rc-4">RC-4</a></li>
<li><a href="#rc-5">RC-5</a></li>
<li><a href="#rc-6">RC-6</a></li>
<li><a href="#rc-7">RC-7</a></li>
<li><a href="#rc-8">RC-8</a></li>
<li><a href="#version-finale">Version finale</a></li>
</ul>
</li>
<li>
<a href="#liste-des-nouveaut%C3%A9s">Liste des nouveautés</a><ul>
<li>
<a href="#architecture">Architecture</a><ul>
<li><a href="#syst%C3%A8mes-monopuces-arm">Systèmes monopuces ARM</a></li>
<li><a href="#renesas-h8300">Renesas H8/300</a></li>
<li><a href="#arcv2-hs38-cpu-cores">ARCv2, HS38 CPU Cores</a></li>
</ul>
</li>
<li>
<a href="#g%C3%A9n%C3%A9ral">Général</a><ul>
<li><a href="#am%C3%A9lioration-des-verrous">Amélioration des verrous</a></li>
<li><a href="#am%C3%A9lioration-de-lordonnanceur">Amélioration de l’ordonnanceur</a></li>
<li><a href="#le-nettoyage-du-code-dassemblage-continue">Le nettoyage du code d’assemblage continue</a></li>
<li><a href="#plus-de-limite-pour-une-suite-de-liens-symboliques">Plus de limite pour une suite de liens symboliques</a></li>
<li><a href="#lappel-syst%C3%A8me-splice-et-les-sockets-unix">L’appel système <code>splice</code> et les sockets Unix</a></li>
<li><a href="#control-group-write-back">Control group write back</a></li>
</ul>
</li>
<li>
<a href="#d%C3%A9veloppeurs">Développeurs</a><ul>
<li><a href="#am%C3%A9lioration-de-loutil-perf">Amélioration de l’outil <code>perf</code></a></li>
</ul>
</li>
<li>
<a href="#pilotes-graphiques-libres">Pilotes graphiques libres</a><ul>
<li><a href="#direct-rendering-manager">Direct Rendering Manager</a></li>
<li>
<a href="#amdati">AMD/ATI</a><ul>
<li><a href="#pilote-de-rendu-nouvelle-g%C3%A9n%C3%A9ration-pilote-amdgpu">Pilote de rendu nouvelle génération (pilote amdgpu)</a></li>
<li><a href="#pilote-de-rendu-pour-les-anciennes-g%C3%A9n%C3%A9rations-pilote-radeon">Pilote de rendu pour les anciennes générations (pilote radeon)</a></li>
<li><a href="#pilote-hsa-pilote-amdkfd">Pilote HSA (pilote amdkfd)</a></li>
</ul>
</li>
<li><a href="#intel-pilote-i915">Intel (pilote i915)</a></li>
<li><a href="#nvidia-pilote-nouveau">NVIDIA (pilote nouveau)</a></li>
<li><a href="#virtio-pilote-virtio-gpu">VirtIO (pilote virtio-gpu)</a></li>
<li><a href="#pilotes-graphiques-pour-syst%C3%A8mes-monopuces">Pilotes graphiques pour systèmes monopuces</a></li>
</ul>
</li>
<li>
<a href="#r%C3%A9seau">Réseau</a><ul>
<li><a href="#suppression-du-cache-pour-les-routes-en-ipv6">Suppression du cache pour les routes en IPv6</a></li>
<li><a href="#lecture-des-ent%C3%AAtes-du-premier-paquet-tcp-syn-sur-une-interface-de-connexion">Lecture des en‐têtes du premier paquet TCP (SYN) sur une interface de connexion</a></li>
<li><a href="#un-nouvel-algorithme-de-gestion-de-congestion-pour-tcp">Un nouvel algorithme de gestion de congestion pour TCP</a></li>
<li><a href="#meilleure-allocation-des-ports-tcpudp">Meilleure allocation des ports TCP/UDP</a></li>
</ul>
</li>
<li>
<a href="#s%C3%A9curit%C3%A9">Sécurité</a><ul>
<li>
<a href="#lsm">LSM</a><ul>
<li><a href="#ima">IMA</a></li>
<li><a href="#selinux">SELinux</a></li>
<li><a href="#smack">SMACK</a></li>
</ul>
</li>
<li><a href="#evm">EVM</a></li>
<li>
<a href="#cryptographie">Cryptographie</a><ul>
<li><a href="#jitter-rng">Jitter RNG</a></li>
<li><a href="#deterministic-random-bit-generator-drbg">Deterministic Random Bit Generator (DRBG)</a></li>
<li><a href="#nouvelle-api-de-chiffrement-de-clef-publique">Nouvelle API de chiffrement de clef publique</a></li>
<li><a href="#mat%C3%A9riel">Matériel</a></li>
</ul>
</li>
<li><a href="#divers">Divers</a></li>
<li><a href="#sysfs-proc-et-les-conteneurs"><code>sysfs</code>, <code>/proc</code> et les conteneurs</a></li>
<li><a href="#liste-non-exhaustive-des-vuln%C3%A9rabilit%C3%A9s-corrig%C3%A9es">Liste non exhaustive des vulnérabilités corrigées</a></li>
</ul>
</li>
<li>
<a href="#syst%C3%A8mes-de-fichiers">Systèmes de fichiers</a><ul>
<li><ul>
<li><a href="#fuse">FUSE</a></li>
<li><a href="#btrfs">Btrfs</a></li>
<li><a href="#f2fs">F2FS</a></li>
<li><a href="#gfs2">GFS2</a></li>
<li><a href="#ext4">ext4</a></li>
<li><a href="#ncq-trim">NCQ TRIM</a></li>
</ul></li>
<li><a href="#ext3-est-en-cours-de-suppression">ext3 est en cours de suppression</a></li>
</ul>
</li>
<li>
<a href="#virtualisation">Virtualisation</a><ul>
<li>
<a href="#kvm"></a><a href="https://lkml.org/lkml/2015/6/23/479">KVM</a>
</li>
<li>
<a href="#xen"></a><a href="https://lkml.org/lkml/2015/6/30/319">Xen</a>
</li>
</ul>
</li>
</ul>
</li>
<li><a href="#le-bilan-en-chiffres">Le bilan en chiffres</a></li>
<li><a href="#appel-%C3%A0-volontaires">Appel à volontaires</a></li>
</ul><h2 id="annonces-des-rc-par-linus-torvalds">Annonces des RC par Linus Torvalds</h2>
<h3 id="rc-1">RC-1</h3>
<p>La version <a href="https://lkml.org/lkml/2015/7/5/218">RC-1</a> est sortie le dimanche 5 juillet 2015 :</p>
<p>C’est dimanche, deux semaines se sont écoulées et la fenêtre d’intégration est fermée. J’ai seulement mis à jour la référence dans les branches <em>git</em> ; les archives <em>tar</em> et les corrections devraient être également disponibles.</p>
<p>Je pensais que cette RC serait l’une des plus grosses que nous ayons eues, mais il se trouve que tout dépend de la manière de compter. Si l’on compte seulement le nombre de modifications, c’est effectivement l’une des plus grosses RC-1 de l’histoire récente, mais la 3.10-rc1 était pratiquement aussi grosse et, à partir de là, elle a grossi vraiment plus que d’habitude. Je doute que nous égalions la taille de la 3.10 au moment de la sortie, étant donné que nous avons fait des progrès pour <strong>ne pas</strong> intégrer de grosses modifications après la sortie de la RC-1.</p>
<p>Et il se trouve que la 3.15-rc1 avait plus de modifications que la 4.2-rc1 (ça se joue à un cheveu), donc, encore une fois, ce n’est pas la plus grosse RC1 de tous les temps, si l’on compte le nombre de modifications.</p>
<p>Mais ça reste vraiment une des plus grosses. Les changements sont bien trop nombreux pour pouvoir en communiquer la liste, et donc, comme d’habitude pour les RC1, j’ai joint mon journal de fusion, dans lequel les personnes nommées sont celles dont j’ai fusionné les changements, et pas forcément celles qui ont effectivement écrit le code. Pour avoir le détail, jetez un œil dans le dépôt <em>git</em>.</p>
<p>Cependant, si l’on regarde uniquement le nombre de lignes modifiées, c’est vraiment la plus grosse de toutes les RC que nous ayons jamais eue, avec un peu plus d’un million de lignes ajoutées (et presque 250 000 lignes enlevées). Cela dépasse le précédent record (3.11-rc1), dont la taille était principalement due à l’ajout de <em>Lustre</em> dans la branche <em>staging</em>.</p>
<p>Ce nombre important de lignes est largement dû à une seule cause : l’ajout massif des nouveaux en-têtes de descriptions de registres des cartes graphiques d’AMD. En fait, ces en‐têtes de descriptions de registres représentent à eux seuls 41 % de l’ensemble des modifications. Le reste de ce nouveau pilote de périphérique représente encore 8 % du total, ce qui fait que l’on se retrouve dans la situation pour le moins étrange dans laquelle un seul pilote couvre presque la moitié de la RC-1 en nombre de lignes.</p>
<p>À part cette anomalie peu courante, le reste semble plutôt normal — principalement des pilotes et des mises à jour d’architectures. L’architecture Renesas H8/300 est revenue sous une nouvelle forme après nettoyage, ainsi nous prenons en charge de (pseudo) nouvelles architectures, mais c’est petit comparé au volume de modifications provenant d’ARM (avec x86, loin derrière). Il est intéressant de remarquer qu’il y a eu quelques changements dans le code de bas niveau de l’architecture x86 : à la fois une réorganisation du code source du prologue x86, et beaucoup de nettoyage dans la gestion des unités de calcul à virgule flottante. C’est plutôt inhabituel, étant donné que le code de bas niveau x86 est plutôt stable et qu’il est rare d’y voir de gros changements.</p>
<p>Hormis les « pilotes et les architectures », il y a beaucoup de modifications dans les systèmes de fichiers, y compris des changements fondamentaux et du nettoyage dans la gestion des liens symboliques par Al. Ainsi que toutes les mises à jour habituelles dans les différents systèmes de fichiers, le réseau, la cryptographie, les outils, les tests, etc.</p>
<p>Linus</p>
<h3 id="rc-2">RC-2</h3>
<p>La version <a href="https://lkml.org/lkml/2015/7/12/184">RC-2</a> est sortie le dimanche 12 juillet 2015 :</p>
<p>Une autre semaine, une autre RC. Que dire ? Trouvez‐moi ennuyeux, mais c’est comme ça que ça marche.</p>
<p>Ce n’est pas une RC particulièrement grosse, et ça a été plutôt calme. Il y a, certes, eu quelques ennuis avec la RC-1, mais tout ça semblait plutôt négligeable, donc espérons que la RC-2 se terminera avec encore moins de problèmes ennuyeux.</p>
<p>La RC-2 se compose en gros d’un tiers de pilotes (DRM en constitue l’essentiel), un tiers d’architectures (ARM, MIPS et PA-RISC, et un brin d’x86) et un tiers de divers. Ce qui sort du lot concerne principalement les systèmes de fichiers (Btrfs) et quelques mises à jour concernant les minuteurs, et les outils de gestion des performances propres à l’infrastructure de l’outil plutôt qu’au noyau.<br>
Le journal abrégé ci‐dessous donne plus de détails, vous pouvez le parcourir rapidement (il n’est pas si gros) pour avoir une idée de ce qui a été fait.</p>
<p>Allez‐y, testez et vérifiez que tout fonctionne bien.</p>
<p>Linus</p>
<h3 id="rc-3">RC-3</h3>
<p>La version <a href="https://lkml.org/lkml/2015/7/19/355">RC-3</a> est sortie le dimanche 19 juillet 2015 :</p>
<p>C’est un dimanche habituel, avec une sortie de RC relativement normale. Il y a eu quelques retombées dues au nettoyage des routines des unités de calcul en nombres flottants sur x86, mais ça ne concerne que les processeurs avec l’instruction <code>xsaves</code>, et tout devrait être rentré dans l’ordre maintenant.</p>
<p>Il y a approximativement 50 % de pilotes, le reste est constitué pour moitié de « mises à jour d’architectures » (x86, ARM, m68k, S390 et ARC) et le reste est constitué d’un peu de tout. Du réseau, des outils, du système de fichiers, etc.</p>
<p>J’aurais aimé que la RC-3 soit un peu plus petite qu’elle ne l’est, mais je ne pense pas qu’il y ait quoi que ce soit de <em>particulièrement</em> effrayant qui se trame.</p>
<p>Linus</p>
<h3 id="rc-4">RC-4</h3>
<p>La version <a href="https://lkml.org/lkml/2015/7/26/84">RC-4</a> est sortie le dimanche 26 juillet 2015 :</p>
<p>Nouvelle semaine, nouvelle RC.</p>
<p>J’espérais vraiment que l’activité se calme, mais ce n’est pas encore le cas. Il n’y a rien de spécialement gros ou effrayant, mais nous n’avons toujours pas atteint le stade à partir duquel le rythme diminue et que les bogues deviennent vraiment insignifiants.</p>
<p>Nous avons encore eu quelques bogues liés au travail de nettoyage bas niveau de l’assembleur x86 et de l’instruction <code>syscall</code>, concernant la compatibilité 32 bits (uniquement utile pour AMD) qui s’est retrouvée subtilement cassée. Tout devrait être désormais corrigé, donc si vous utilisez un noyau 64 bits avec un espace utilisateur 32 bits (notamment des outils tels que Wine, etc.) et que vous avez rencontré des soucis auparavant, mettez‐vous à jour.</p>
<p>Bien sûr, merci de vous mettre à jour, même si vous n’avez pas eu de problème jusqu’ici, juste pour tester la nouvelle RC.</p>
<p>Si l’on excepte ce problème, il s’agit principalement de pilotes et du réseau. USB, processeurs graphiques, pilote MMC, pilotes réseau, audio. Avec un peu d’activité du côté d’ARM due essentiellement à des pilotes, avec des mises à jour de <a href="http://elinux.org/Device_Tree">l’arbre des périphériques</a> correspondant à des corrections, la gestion des cartes mémoire multimédia MMC. Nous avons aussi quelques petites corrections dans les systèmes de fichiers.</p>
<p>Allez‐y, testez.</p>
<p>Linus</p>
<h3 id="rc-5">RC-5</h3>
<p>La version <a href="https://lkml.org/lkml/2015/8/2/211">RC-5</a> est sortie le dimanche 2 août 2015 :</p>
<p>Nous arrivons maintenant dans les dernières RC, mais il semblerait que cette 4.2 soit une version qui nécessitera sans doute plus de RC que les sept habituelles. Les choses ne se calment pas comme je l’avais espéré, et un nombre important de problèmes ont été découverts.</p>
<p>Par exemple, il y a un correctif dans le cœur de <a href="https://fr.wikipedia.org/wiki/Virtual_File_System" title="Virtual File System">VFS</a> qui a été seulement fusionné hier – le bogue en lui‐même était ancien, mais certains changements apportés par cette version l’ont rendu beaucoup plus visible et fréquent. Il y a également des régressions sur le MST DP i915 qui sont relativement cachées, mais qui nécessitent encore du travail, tout comme les quelques manques autour du nettoyage bas niveau du code x86 et des interruptions non masquables (NMI). De plus, il y a également des questions en attente concernant des changements dans la mémoire virtuelle.</p>
<p>Rien de cela n’est particulièrement méchant, et ces bogues sont des cas très spécifiques, difficiles à atteindre, et des points de détails, ce qui fait que je ne suis pas particulièrement inquiet. Mais c’est plus que je ne l’escomptais à ce niveau de version. Peut‐être que dans deux semaines, lorsque la RC-7 sera là, je serai plus serein, les choses iront bien et je serai prêt à valider la sortie d’une 4.2, mais actuellement, j’espère juste que les choses vont se tasser et qu’il n’apparaîtra pas d’autres problèmes.</p>
<p>Mis à part ces petits désagréments, les choses semblent plutôt classiques. Pas beaucoup de perturbations dues aux architectures cette fois‐ci (mis à part ce problème de NMI relaté précédemment) – et un peu plus des trois quarts des modifications sont dues aux pilotes, avec DRM, InfiniBand, réseau, et gestion de charge SCSI. Le reste est composé principalement de modifications de système de fichiers et de code réseau.</p>
<p>Vous pouvez consulter le résumé de la liste des modifications, qui donne une assez bonne vue sur les détails. S’il vous plaît, continuez à tester. Et sachez que si vous m’envoyez une demande d’intégration que je considère comme inappropriée, je ne réagirai sans doute pas de manière mesurée (vous êtes prévenus). Nous avons vraiment besoin de ralentir et retrouver un rythme normal (bien que cette RC-5 ne soit pas vraiment si grosse que ça).</p>
<p>Linus</p>
<h3 id="rc-6">RC-6</h3>
<p>La version <a href="https://lkml.org/lkml/2015/8/9/125">RC-6</a> est sortie le dimanche 9 août 2015 :</p>
<p>La semaine dernière, je n’étais pas satisfait de l’état des RC, mais ça va mieux. Non seulement, la RC-6 est beaucoup plus petite, mais en plus les problèmes qui m’embêtaient ont été résolus au début de la semaine, et il n’en reste pas de graves. Si tout va bien, je pense que nous terminerons selon le calendrier habituel (c’est‐à‐dire dans deux semaines). Touchons du bois.</p>
<p>Dans la RC-6, les statistiques semblent un peu bizarres, parce que les modifications de l’architecture ARC dominent (30 % du total). C’est dû au fait que les autres changements sont plutôt petits, et aussi que la correction du « <em>llock/scond livelock</em> » n’était pas petite. Mais je ne m’inquiète pas.</p>
<p>Si on exclut la bizarrerie ARC, tout paraît normal. Principalement des pilotes (pilotes graphiques, son, I²C, entrée, USB, thermique, etc.) et des mises à jour d’architectures (MIPS et SPARC). Avec quelques corrections des systèmes de fichiers et de la mémoire virtuelle.</p>
<p>S’il vous plaît, testez et vérifiez que les problèmes ont bien été corrigés. OK ?</p>
<p>Linus</p>
<h3 id="rc-7">RC-7</h3>
<p>La version <a href="https://lkml.org/lkml/2015/8/16/87">RC-7</a> est sortie le dimanche 16 août 2015 :</p>
<p>En général, ces temps‐ci, la RC-7 est notre dernière RC, et la semaine prochaine devrait sortir la version 4.2 finale. Mais à ce stade, je n’ai toujours pas pris ma décision. Au moment de la RC-5, je m’inquiétais de quelques questions en suspens. Puis, dimanche dernier, pour la RC-6, j’étais plus confiant. Et maintenant, une semaine plus tard, et nous avons constaté quelques répercussions provenant de la réécriture du prologue x86 bas niveau, et je ne sais plus.</p>
<p>Donc, ça peut être la dernière RC, ou pas. Cela dépendra si d’autres problèmes surviennent la semaine prochaine, et de mon ressenti dimanche prochain. Une partie de moi est convaincue que les problèmes bizarres de compatibilité 32 bits, etc., sont enfin réglés, mais l’autre partie de moi est encore un peu méfiante.</p>
<p>Dans l’ensemble, ça s’est assez bien passé. C’est une bonne petite RC, avec des statistiques relativement normales. 70 % de pilotes (réseau, NTB, Xen, md, pilotes graphiques), le reste étant principalement constitué de quelques mises à jour d’architectures et de réseau, hors pilotes. Le mini‐journal en annexe donne les détails habituels — il est vraiment court.</p>
<p>Par conséquent, une sortie la semaine prochaine est certainement encore possible.</p>
<p>Linus</p>
<h3 id="rc-8">RC-8</h3>
<p>La version <a href="https://lkml.org/lkml/2015/8/24/9">RC-8</a> est sortie le lundi 24 août 2015 :</p>
<p>La version 4.2-rc8 est disponible, et évidemment ça signifie que finalement je me suis dégonflé, et que j’ai décidé de retarder la version finale d’une semaine.</p>
<p>Il n’y a plus vraiment de problèmes non résolus, et donc j’ai hésité entre sortir la version finale ou une autre RC. Mais comme cette semaine nous avons eu un autre problème de bas niveau sur x86, et qu’en plus beaucoup de personnes sont en vacances, j’ai décidé qu’attendre une semaine de plus ne ferait pas de mal. Mais il s’en est fallu de peu. Cette RC-8 est assez petite, et je pense vraiment que ça aurait pu le faire dans les deux cas.</p>
<p>Donc la RC-8 n’est pas une grosse RC et la majorité des changements sont des annulations de modifications de dernière minute qui n’étaient pas vraiment prêtes. Surtout des changements sur les pilotes, le réseau, des correctifs sur x86 et une poignée de correctifs sur l’outillage de performance. La liste de modifications donne une vue d’ensemble détaillée.</p>
<p>Linus</p>
<h3 id="version-finale">Version finale</h3>
<p>La <a href="https://lkml.org/lkml/2015/8/30/96">version finale</a> est sortie le 30 août 2015 :</p>
<p>Donc, à en juger par le peu d’activité de cette semaine, ce n’aurait pas été une erreur de sortir la version 4.2 la semaine dernière, après tout. Mais il y a vraiment eu quelques corrections effectuées, et retarder la version 4.2 d’une semaine ne posait pas vraiment de problème.</p>
<p>Donc, la voici, et la fenêtre de fusion pour la version 4.3 est à présent ouverte. J’ai déjà en attente quelques demandes anticipées d’intégrations, mais comme toujours je commencerai à les traiter demain et donnerai à la version 4.2 le temps de s’installer.</p>
<p>La liste des changements par rapport à RC-8 est minuscule et se trouve en annexe. Le correctif est plutôt petit lui aussi.</p>
<p>Allez la récupérer.</p>
<p>Linus</p>
<h2 id="liste-des-nouveautés">Liste des nouveautés</h2>
<ul>
<li><a href="https://lwn.net/Articles/648995/">4.2 Merge window part 1</a></li>
<li><a href="https://lwn.net/Articles/649652/">4.2 Merge window part 2</a></li>
<li><a href="https://lwn.net/Articles/650299/">4.2 Merge window part 3</a></li>
</ul><h3 id="architecture">Architecture</h3>
<h4 id="systèmes-monopuces-arm">Systèmes monopuces ARM</h4>
<ul>
<li>Les processeurs Allwinner A23 ainsi que les Broadcom BCM63138 bénéficient de la prise en charge du SMP (multiprocesseur).</li>
<li>Un embryon de prise en charge pour la carte i.MX7d. L’i.MX7 dispose de deux cœurs Cortex-A7 pouvant atteindre des fréquences de 1,0 GHz, ainsi que d’un cœur Cortex-M4 cadencé jusqu’à 256 MHz, le tout avec une prise en charge des mémoires LPDDR2 et LPDDR3, un bus Ethernet gigabit, et un bus PCI Express. La série des i.MX7 est principalement réservée à ce que l’on appelle communément « l’Internet des objets ».</li>
<li>Un embryon de prise en charge pour le <a href="http://www.cnx-software.com/2015/04/28/zte-zx296702-dual-core-cortex-a9-soc-boots-android-in-10-seconds-with-tuxonice/">ZTE ZX296702</a>, qui dispose d’un double cœur Cortex-A9, ainsi qu’une puce Mali 400. </li>
<li>Une prise en charge pour le NVIDIA Tegra HDA.</li>
<li>Une prise en charge pour les nouvelles plates‐formes Broadcom suivantes : <a href="http://www.buffalotech.com/products/wireless/dd-wrt-nxt/airstation-extreme-ac1900-dd-wrt-nxt-wireless-router">Buffalo WXR-1900DHP</a>, <a href="http://walkerfirst.com/uploads/files/literature/SmartRG%20SR400ac.pdf">SmartRG SR400ac</a>, et <a href="https://www.asus.com/fr/Networking/RTAC87U/">ASUS RT-AC87U</a>.</li>
<li>Une prise en charge pour la carte <a href="http://www.arm.com/products/tools/development-boards/versatile-express/juno-arm-development-platform.php">ARM Juno</a>.</li>
<li>Une prise en charge pour le système monopuce HiSilicon Hi6220, permettant ainsi de faire fonctionner la carte <a href="https://www.96boards.org/products/ce/hikey/">HiKey</a> (carte disposant d’un Cortex-A53 octocœur 64 bits pour 130 US$).</li>
<li>La plate‐forme mvebu prend désormais en charge le <a href="http://www.compulab.co.il/products/computer-on-modules/cm-a510/">Compulab CM-A510</a>, le <a href="http://www.dlink.com/fr/fr/support/product/dns-327l-2-bay-network-attached-storage">D-Link DNS-327L</a> et les cartes Linksys basées sur un Armada 385.</li>
<li>La plate‐forme OMAP gagne également la prise en charge du <a href="http://www.visionsystems.de/produkte/baltos-ir-5221.html">Baltos IR 5221</a>, du <a href="http://www.logicpd.com/products/system-on-modules/dm3730-torpedo-wireless-som/">LogicPD Torpedo</a>, ainsi que du Toby Churchill SL50 (lien vers le <a href="http://www.toby-churchill.com/products/lightwriter-sl40/">SL40</a>, aucun lien vers le SL50 n’existe pour le moment).</li>
</ul><h4 id="renesas-h8300">Renesas H8/300</h4>
<p>Le noyau Linux gagne encore en portabilité en ajoutant la prise en charge d’un nouveau processeur, le <a href="https://fr.wikipedia.org/wiki/Hitachi_H8">Renesas H8-300</a> dans sa version 32 bits. Ce processeur se retrouve par exemple dans les Lego Mindstorms. Jusqu’alors, sa prise en charge était maintenue dans un arbre séparé du noyau officiel. Il est désormais intégré au noyau 4.2 grâce à un ajout de plus de 7 000 lignes de code.</p>
<h4 id="arcv2-hs38-cpu-cores">ARCv2, HS38 CPU Cores</h4>
<p>Les processeurs <a href="https://www.synopsys.com/dw/ipdir.php?ds=arc-hs38-processor">HS38</a> issus d’une architecture ARCv2, et développés par DesignWare, sont désormais directement gérés dans le noyau. Cette évolution de l’architecture ARC est censée être deux fois plus performante, tout en ayant une faible consommation et un nombre de transistors peu élevé.</p>
<h3 id="général">Général</h3>
<h4 id="amélioration-des-verrous">Amélioration des verrous</h4>
<p>Grâce à une amélioration des verrous (passage de <em>ticket spinlock</em> à <em>qspinlocks</em>), la montée en charge sur les systèmes ayant beaucoup de processeurs et les architectures à mémoire non uniforme (<a href="https://fr.wikipedia.org/wiki/Non_Uniform_Memory_Access">NUMA</a>) va être plus performante. Cela ne dispense cependant pas les développeurs de travailler leurs verrous [<a href="http://www.phoronix.com/scan.php?page=news_item&px=Queue-Spinlocks-Linux-4.2"><em>Cf.</em> <em>phoronix.com</em></a>].</p>
<h4 id="amélioration-de-lordonnanceur">Amélioration de l’ordonnanceur</h4>
<p>Diverses améliorations de l’ordonnanceur, dont l’équilibrage sur les systèmes NUMA [<a href="http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.2-Scheduler-Upgrades"><em>Cf.</em> <em>phoronix.com</em></a>].<br>
Amélioration de performance des disques à mémoire Flash SSD de 12 % sur certains tests, quatre fois sur d’autres tests en désactivant des choses inutiles sur les disques statiques, comme la NCQ, et autres mesures qui laissaient des temps à vide pour le SSD.<br>
[<a href="http://www.phoronix.com/scan.php?page=news_item&px=cfq-io-scheduler-iops-linux-4.2"><em>Cf.</em> <em>phoronix.com</em></a>].</p>
<h4 id="le-nettoyage-du-code-dassemblage-continue">Le nettoyage du code d’assemblage continue</h4>
<p>La suppression du code d’assemblage x86 commencée dans le noyau 4.1 continue. De petites améliorations de vitesse et des micro‐optimisations sont à attendre. Cela améliore aussi la gestion des interruptions [<a href="http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.2-x86-Core"><em>Cf.</em> <em>phoronix.com</em></a>].</p>
<h4 id="plus-de-limite-pour-une-suite-de-liens-symboliques">Plus de limite pour une suite de liens symboliques</h4>
<p>Le code principal de recherche des noms de fichiers a été retravaillé afin de ne plus utiliser la récursivité. Les effets seront visibles au niveau de l’utilisation de la pile, qui sera réduite (améliorant la fiabilité des systèmes de stockage complexes) et de la limite des niveaux d’imbrication des liens symboliques, qui a été relevée.</p>
<h4 id="lappel-système-splice-et-les-sockets-unix">L’appel système <code>splice</code> et les sockets Unix</h4>
<p>Les sockets de domaine Unix gèrent désormais l’appel système <code>splice()</code>.</p>
<h4 id="control-group-write-back">Control group write back</h4>
<p>Les correctifs d’écriture différée selon le groupe de contrôle (<em>cgroup</em>) ont été intégrés. Cela permet un meilleur contrôle de l’écriture de données selon les groupes de contrôle, corrigeant des comportements qui étaient depuis longtemps défaillants [<a href="http://lwn.net/Articles/648292/"><em>LWN.net</em></a>].</p>
<h3 id="développeurs">Développeurs</h3>
<h4 id="amélioration-de-loutil-perf">Amélioration de l’outil <code>perf</code>
</h4>
<p>Comme à chaque nouvelle version, l’outil <code>perf</code> bénéficie de son lot d’améliorations listées dans le <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c58267e9fa7b0345dd9006939254701e3622ca6a">correctif suivant</a>.</p>
<h3 id="pilotes-graphiques-libres">Pilotes graphiques libres</h3>
<h4 id="direct-rendering-manager">Direct Rendering Manager</h4>
<p>Maintenant au sein de DRM, l’interface logicielle (API) de gestion atomique du mode graphique est considérée comme complète, elle est donc exposée par défaut à l’espace utilisateur. Cette interface, <a href="//linuxfr.org/news/sortie-du-noyau-linux-4-0#drm-direct-rendering-manager">intégrée initialement dans Linux 4.0</a>, permet à l’espace utilisateur de vérifier si une configuration est gérée par le matériel avant de l’appliquer. Cela devrait donc permettre d’exploiter l’interface logicielle KMS des plans graphiques <a href="//linuxfr.org/news/sortie-du-noyau-linux-3-19#drm-direct-rendering-manager">ajoutée dans Linux 3.19</a>. Martin Graßlin, développeur du compositeur KWin, a déjà exprimé son <a href="http://blog.martin-graesslin.com/blog/2015/08/layered-compositing/">souhait d’utiliser cette nouvelle interface</a>, afin de réduire à néant les coûts liés à la composition graphique. Pour plus d’informations sur le sujet, vous pouvez consulter les articles écrits par Daniel Vetter, mainteneur du pilote <em>i915</em> (Intel), sur <em>LWN.net</em> [<a href="https://lwn.net/Articles/653071/">partie 1</a> et <a href="https://lwn.net/Articles/653466/">partie 2</a>].</p>
<p>Pour plus d’informations, vous pouvez consulter les demandes d’intégration <a href="https://lkml.org/lkml/2015/6/25/708">DRM</a> et <a href="http://lists.freedesktop.org/archives/dri-devel/2015-June/084647.html">panneaux</a>.</p>
<h4 id="amdati">AMD/ATI</h4>
<h5 id="pilote-de-rendu-nouvelle-génération-pilote-amdgpu">Pilote de rendu nouvelle génération (pilote amdgpu)</h5>
<p>Plus d’un an et demi après son <a href="http://www.phoronix.com/scan.php?page=article&item=amd_catalyst_kernel&num=1">annonce à la <em>Game Developer Conference 2014</em></a>, le pilote AMDGPU est enfin fusionné dans le noyau. Ce pilote, issu d’AMD, représente le nouveau cœur dans le noyau pour la gestion des cartes à base de processeur graphique AMD CI+. Le but pour AMD est d’avoir une interface unifiée, tant pour les pilotes libres que pour les pilotes propriétaires. Cette nouvelle architecture permet de garder les pilotes (que ce soit Gallium3D ou Catalyst) en espace utilisateur. Ce pilote a nécessité l’ajout de plus de 400 000 lignes de code, et de plus de 200 fichiers.</p>
<p>Cette fusion des équipes de développement noyau devrait garantir la gestion des futures générations de processeurs graphiques AMD avant leur sortie commerciale, mais également augmenter la stabilité et les performances des deux pilotes.</p>
<p>La FSF s’est permis de rappeler que cette architecture n’est cependant pas plus ouverte que la précédente. En effet, le pilote AMDGPU intègre un paquet binaire redistribuable à charger sur les cartes AMD pour pouvoir être fonctionnel, comme sur le pilote RADEON.</p>
<p>Pour plus d’informations, vous pouvez regarder la <a href="http://www.x.org/wiki/Events/XDC2014/XDC2014DeucherAMD/">conférence d’Alex Deucher à l’<em>XDC 2014</em></a>, la conférence des développeurs X.Org qui s’est déroulée à Bordeaux en octobre dernier. Vous pouvez également <a href="http://lists.freedesktop.org/archives/dri-devel/2015-June/084083.html">consulter la demande d’intégration</a>.</p>
<h5 id="pilote-de-rendu-pour-les-anciennes-générations-pilote-radeon">Pilote de rendu pour les anciennes générations (pilote radeon)</h5>
<p>Avec l’introduction du pilote AMDGPU, la majorité des efforts de développement devrait maintenant se concentrer sur ce pilote. Le pilote <em>radeon</em> continuera à être maintenu et amélioré, mais à un rythme bien plus lent.</p>
<p>Cette nouvelle version du pilote apporte cependant une fonctionnalité importante, la gestion du codage vidéo avec le moteur matériel <a href="https://en.wikipedia.org/wiki/Video_Coding_Engine">VCE1</a>. Ce moteur a été ajouté fin 2011 aux processeurs graphiques AMD et permet de compresser directement des vidéos au format H.264 / MPEG-4 AVC. Cette fonctionnalité est destinée à permettre l’enregistrement de la sortie vidéo et la diffusion en temps réel de cette vidéo depuis un ordinateur puissant vers une machine plus économe située directement dans le salon de joueurs (voir la solution <a href="http://shield.nvidia.com/game-stream">GameStream de NVIDIA</a>). Elle permet également de diffuser ses exploits en direct sur Internet avec une perte de performance plus faible que les solutions traditionnelles de codage sur le processeur (voir <a href="https://steamcommunity.com/updates/broadcasting?l=french"><em>Steam Broadcast</em></a>).</p>
<p>Pour plus d’informations sur les nouveautés du pilote <em>radeon</em>, vous pouvez consulter la <a href="http://lists.freedesktop.org/archives/dri-devel/2015-May/083800.html">demande d’intégration <em>radeon</em></a>.</p>
<h5 id="pilote-hsa-pilote-amdkfd">Pilote HSA (pilote amdkfd)</h5>
<p>Le pilote <em>amdkfd</em> (<a href="//linuxfr.org/news/sortie-du-noyau-linux-3-19#amdati-pilote-radeon">inclus dans Linux 3.19</a>), qui permet de faire communiquer plus rapidement le processeur graphique et le processeur central, a reçu l’ajout d’un module de gestion d’interruptions et autres événements. Ce module permettra l’ajout d’un nouveau module dédié au débogage des applications <a href="https://en.wikipedia.org/wiki/Heterogeneous_System_Architecture">HSA</a>.</p>
<p>Un paramètre noyau a également été ajouté afin de spécifier si une application doit recevoir le signal SIGBUS lorsque le processeur graphique rencontre une exception liée à la mémoire et que l’application n’est pas en mesure de recevoir cette information, ou si un message doit être écrit dans le journal du noyau. Ce paramètre est activé par défaut.</p>
<p>Pour plus d’informations, vous pouvez consulter la <a href="http://lists.freedesktop.org/archives/dri-devel/2015-May/082896.html">demande d’intégration <em>amdkfd</em></a>.</p>
<h4 id="intel-pilote-i915">Intel (pilote i915)</h4>
<p>Comme d’habitude, le pilote <em>i915</em> a reçu beaucoup de modifications de la part des ingénieurs d’Intel. Les nouveautés principales sont la finalisation de la gestion dynamique des espaces d’adressage (voir la <a href="//linuxfr.org/news/sortie-du-noyau-linux-4-1#intel-pilote-i915">dépêche sur Linux 4.1</a>), ainsi que l’activation du vérificateur de commandes pour les processeurs Haswell. Ces modifications vont permettre d’activer des extensions OpenGL quand Mesa3D les gérera.</p>
<p>Du côté consommation d’énergie, le pilote a reçu des optimisations afin de réduire l’activité du processeur lors de la vérification des commandes envoyées par l’espace utilisateur. Le pilote a également affiné la configuration du processeur graphique en mode <em>boost</em> afin d’éviter son utilisation lorsque ce n’est pas nécessaire. La gestion des modes basse consommation pour le contrôleur d’affichage fait également son arrivée.</p>
<p>Toujours du côté de la gestion du mode graphique, la gestion atomique ne fait toujours pas partie de Linux 4.2. Mais le travail continue ! On peut cependant noter une gestion expérimentale des processeurs Broxton qui réutilise le bloc d’affichage des processeurs Skylake.</p>
<p>Les processeurs Skylakes et Broxtons sont toujours marqués comme expérimentaux et ne sont pas gérés par défaut. C’est ennuyeux car les processeurs Skylake sont maintenant disponibles à la vente. Espérons que Linux 4.3 éliminera cette limitation.</p>
<p>Toutes les nouveautés ne sont pas décrites ici. Pour plus d’informations, vous pouvez consulter la publication sur le <a href="http://blog.ffwll.ch/2015/06/neat-drmi915-stuff-for-42.html">blog de Daniel Vetter</a>, mainteneur <em>i915</em>.</p>
<h4 id="nvidia-pilote-nouveau">NVIDIA (pilote nouveau)</h4>
<p>Aucune nouveauté pour le pilote <em>nouveau</em>. Ben Skeggs, le mainteneur, a été très occupé à réorganiser le cœur du pilote pour que celui‐ci soit plus facile à utiliser et que le compilateur vérifie plus de choses à la compilation. Ce travail vient d’être accepté dans Linux 4.3 et nous partagerons plus d’informations à sa sortie !</p>
<p>Il est cependant à noter que les microcodes nécessaires au processeur graphique du Tegra K1 (GK20A) ont fait leur <a href="https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=899ebcb6812681b91cf2dfd390574b478c612442">entrée dans <em>linux-firmware</em></a>.</p>
<h4 id="virtio-pilote-virtio-gpu">VirtIO (pilote virtio-gpu)</h4>
<p>Le pilote graphique pour systèmes virtualisés gérant VirtIO fait son entrée dans le noyau. Celui‐ci exporte pour l’instant uniquement l’interface KMS, sans accélération graphique 3D. Cette interface est utilisable directement avec un compositeur Wayland ou via l’utilisation du pilote <em>xf86-video-modesetting</em>. Le pilote <em>virtio-gpu</em> a cependant pour vocation de proposer une accélération 3D via <a href="https://virgil3d.github.io/">Virgil3D</a>.</p>
<p>Pour plus d’informations, vous pouvez consulter la <a href="http://lists.freedesktop.org/archives/dri-devel/2015-June/084071.html">demande d’intégration <em>virtio-gpu</em></a>.</p>
<h4 id="pilotes-graphiques-pour-systèmes-monopuces">Pilotes graphiques pour systèmes monopuces</h4>
<p>Le pilote <em>Omapdrm</em> a été partiellement réécrit pour corriger des bogues (crash au déchargement des modules, cisaillements lors des changements de pages, etc.) présents depuis des années. Il en résulte un code plus lisible et maintenable, tout en étant plus stable et robuste. Le code a été majoritairement testé sur la <a href="http://pandaboard.org/">Pandaboard</a> OMAP4, avec un et deux écrans.</p>
<p>Le <strong>pilote DRM/MSM</strong> (pour les puces graphiques SnapDragon) voit l’ajout de la prise en charge de l’<a href="http://www.notebookcheck.net/Qualcomm-Adreno-306.126520.0.html">Adreno 306</a> que l’on retrouve dans le <a href="http://www.notebookcheck.net/Qualcomm-Snapdragon-410-MSM8916-SoC.111656.0.html">SnapDragon 400c</a>. Ce dernier promet d’être moins énergivore que son prédécesseur, l’Adreno 305.<br>
De plus, nous avons droit aux habituels correctifs (assez nombreux), et l’ajout de la prise en charge du format de tampon <a href="http://www.fourcc.org/yuv.php#NV12">NV12MT</a>.</p>
<h3 id="réseau">Réseau</h3>
<h4 id="suppression-du-cache-pour-les-routes-en-ipv6">Suppression du cache pour les routes en IPv6</h4>
<p>Si vous avez bonne mémoire, vous vous souvenez peut‐être de la suppression du cache des routes en IPv4, <a href="//linuxfr.org/news/sortie-du-noyau-linux-3-6#toc_11">décrite dans la dépêche sur le noyau Linux 3.6</a>.</p>
<p>C’est désormais au tour du système IPv6 de recevoir les mêmes changements, grâce à Martin KaFai Lau, développeur employé par Facebook. Son travail s’appuie sur la même idée et permet aux deux versions d’IP de converger à ce sujet dans le noyau Linux.</p>
<p>Ses modifications sont réparties en plusieurs séries, mais la plus importante est <a href="http://thread.gmane.org/gmane.linux.network/359140"><em>celle‐ci</em></a>. Elle contient notamment des indicateurs de performance, et des détails sur la nouvelle implémentation (qui continue de sauvegarder les routes avec des <a href="https://fr.wikipedia.org/wiki/MTU" title="Définition Wikipédia">MTU</a> différentes).</p>
<h4 id="lecture-des-entêtes-du-premier-paquet-tcp-syn-sur-une-interface-de-connexion">Lecture des en‐têtes du premier paquet TCP (SYN) sur une interface de connexion</h4>
<p>Lorsqu’un développeur d’applications ouvre une interface de connexion (<a href="https://fr.wikipedia.org/wiki/Berkeley_sockets"><em>socket</em></a>) avec le protocole TCP, il ne peut habituellement obtenir des informations sur la connexion qu’une fois que la poignée de main (SYN-ACK, ACK) est terminée.</p>
<p>Les informations contenues dans les en‐têtes du premier paquet reçu sont perdues, l’application ne peut pas y avoir accès.</p>
<p>Google semble avoir un cas d’utilisation d’étude de ces paquets, à des fins d’empreintes numériques. Les développeurs de Google ont donc <a href="https://lwn.net/Articles/645128/">proposé une modification</a> ajoutant une option pour faire sauvegarder les en‐têtes de ce paquet par le noyau, et pour demander à les lire ensuite.</p>
<p>Pour la petite histoire, les développeurs de chez Google indiquent utiliser depuis trois ans une approche équivalente en interne.</p>
<h4 id="un-nouvel-algorithme-de-gestion-de-congestion-pour-tcp">Un nouvel algorithme de gestion de congestion pour TCP</h4>
<p>La gestion de congestion de TCP est essentielle à tout réseau : c’est elle qui permet d’éviter de prendre toute la bande passante disponible avec une seule connexion. Son principe est d’augmenter progressivement la vitesse d’une connexion, et de détecter quand le réseau commence à être saturé. C’est à chaque client de vérifier l’état de congestion pour permettre un partage sain des capacités du réseau entre tous les utilisateurs, sans aucun mécanisme central.</p>
<p>Même en considérant que tous les clients vont coopérer correctement, ce problème est très loin d’être trivial, notamment pour une détection de saturation réseau correcte. La plupart des algorithmes se basent sur la détection de perte de paquets. Pour qu’un paquet soit considéré comme perdu, il faut d’abord être certain qu’il n’a pas été reçu (donc utiliser un délai de grâce, ce qui augmente la latence). Cette détection peut être compliquée par le fameux problème de saturation de tampon (<a href="//linuxfr.org/news/sortie-du-noyau-linux-3-3#toc_11"><em>buffer bloat</em></a>). Enfin, un réseau peut connaître de la perte naturelle de paquets, sans pour autant être congestionné.</p>
<p>Le nouvel algorithme introduit dans le noyau s’appelle <em>Delay-gradient congestion control</em>. Comme son nom l’indique, l’idée est de changer d’approche. Plutôt que de construire la détection de congestion sur la perte de paquets, mécanisme peu fiable, cet algorithme se base sur les variations du délai de transmission (RTT). Quand ce délai augmente de façon anormale, une congestion est détectée et l’émission de paquet est adaptée pour en tenir compte. Pour plus de détails, <a href="http://lwn.net/Articles/645115/">le site <em>LWN.net</em> a détaillé le mécanisme</a>.</p>
<p>Pour rappel, vous pouvez consulter les algorithmes disponibles sur votre noyau préféré avec <code>/proc/sys/net/ipv4/tcp_available_congestion_control</code>, et vérifier ou configurer l’algorithme utilisé avec <code>/proc/sys/net/ipv4/tcp_congestion_control</code>.</p>
<h4 id="meilleure-allocation-des-ports-tcpudp">Meilleure allocation des ports TCP/UDP</h4>
<p>Les ports TCP et UDP sont essentiels pour identifier de façon unique une connexion réseau entre deux équipements. Ces ports ne sont pas très nombreux, il ne peut y en avoir que 65 535 pour ces protocoles.</p>
<p>Cela pose un problème pour des serveurs très chargés avec énormément de connexions à ouvrir. Soit il n’y a plus de ports disponibles (et la connexion échoue), soit on peut passer un temps très important à trouver un port disponible, prenant des ressources à tout le monde.</p>
<p>Il y a cependant deux types de ports : ceux qui sont utilisés par un <em>socket</em> serveur ne peuvent être utilisés par quiconque d’autre. On n’a pas le contrôle sur les identifiants utilisés par les clients, on ne peut donc pas prendre le risque côté serveur de réutiliser ce port.</p>
<p>En revanche, pour les sockets client, on peut très facilement réutiliser les ports en maintenant l’unicité de l’identification réseau (basée sur les deux adresses IP, les deux ports, et le protocole utilisé) :</p>
<table>
<thead><tr>
<th>Adresse locale</th>
<th>Adresse distante</th>
<th>Port source</th>
<th>Port destination</th>
</tr></thead>
<tbody>
<tr>
<td>A</td>
<td>B</td>
<td>2000</td>
<td>80</td>
</tr>
<tr>
<td>A</td>
<td>C</td>
<td>2000</td>
<td>80</td>
</tr>
<tr>
<td>A</td>
<td>B</td>
<td>2001</td>
<td>80</td>
</tr>
</tbody>
</table><p>La solution proposée par Éric Dumazet est donc de séparer cet espace de ports en deux parties : une pour les utilisateurs de la fonction <code>connect()</code> (client), une autre pour les utilisateurs de la fonction <code>bind()</code> (serveur). En divisant ainsi l’espace, on fait gagner du temps à tout le monde (il est très probable que la fonction <code>connect()</code> pourra partager un port dans les premiers trouvés, tandis que la fonction <code>bind()</code> aura beaucoup moins de vérifications à faire). Si par hasard un des espaces était totalement utilisé, l’itération se poursuivrait sur le second [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=07f4c90062f8fc7c8c26f8f95324cbe8fa3145a5"><em>correctif</em></a>].</p>
<h3 id="sécurité">Sécurité</h3>
<h4 id="lsm">LSM</h4>
<p>Les modules de sécurité Linux (LSM) peuvent être « empilés » pour effectuer plus de contrôles de sécurité. Il n’est pour l’instant pas possible d’utiliser simultanément plusieurs modules « monolithiques » : les structures opaques de sécurité présentes un peu partout dans le noyau n’ont pas été dupliquées. Cela signifie donc qu’il est possible d’empiler plusieurs modules « simples » (pour l’instant il n’existe que Yama) avec d’autres modules « lourds » (SELinux, SMACK…).</p>
<p>Par la même occasion, les vérifications liées aux « <em>capabilities</em> » ont été regroupées dans un nouveau module générique qui est empilé par défaut avant tous les autres. Le code pour effectuer ces vérifications a été retiré de tous les autres modules, ce qui lève certaines ambiguïtés et évite la duplication du code.</p>
<p>(Correctifs : <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3c4ed7bdf5997d8020cbb8d4abbef2fcfb9f1284">1</a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f25fce3e8f1f15d6d2a22620ebf98a68a4641f06">2</a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e20b043a6902ecb61c2c84355c3bae5149f391db">3</a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b1d9e6b0646d0e5ee5d9050bd236b6c65d66faef">4</a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1ddd3b4e07a4be9fe3f1ce2441b01859154f4358">5</a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5413fcdbe9e7ca32ce3f00fd5251dfa560b7484b">6</a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e308fd3bb2e469c4939d3f4bd22b468de3ed04ae">7</a> ; <a href="http://lwn.net/Articles/635771/">article <em>LWN.net</em> : <em>Progress in security module stacking</em></a>).</p>
<h5 id="ima">IMA</h5>
<p>Les fichiers des systèmes de fichiers virtuels pour les <em>cgroups</em> et les espaces de noms ne sont plus vérifiés par défaut. Les autres systèmes de fichiers virtuels (devpts, SELinux, binfmt…) sont aussi suggérés comme « à ignorer » dans la politique de test par défaut, parce que les opérations effectuées par IMA ne sont pas pertinentes dans ce cas [correctifs : <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6438de9f3fb5180d78a0422695d0b88c687757d3"><em>1</em></a> et <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cd025f7f94108995383edddfb61fc8afea6c66a9"><em>2</em></a>].</p>
<p>Avec IMA, les signatures des fichiers sont automatiquement définies et mises à jour et ne doivent pas être modifiées à la main par un utilisateur. Dans certains cas, cette opération peut tout de même être nécessaire. Elle est donc limitée aux modes <code>fix</code> et <code>log</code> [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c68ed80c97d9720f51ef31fe91560fdd1e121533"><em>correctif</em></a>].</p>
<p>La nouvelle condition <code>euid</code> ajoutée pour les politiques de sécurité permet de vérifier l’intégrité des fichiers accédés par un processus avec un <code>euid</code> défini. Pour les fichiers <code>CAP_SETUID</code>, les <code>uid</code> et les <code>suid</code> sont pris en compte [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=139069eff7388407f19794384c42a534d618ccd7"><em>correctif</em></a>].</p>
<p>La règle de filtre <code>mask</code> est étendue pour filtrer les ouvertures de fichiers contenant un ou plusieurs modes <code>MAY_READ</code>, <code>MAY_WRITE</code> ou <code>MAY_APPEND</code> au lieu d’un seul uniquement. Par exemple, <code>mask=^MAY_READ</code> correspondra à l’ouverture de fichiers en lecture et écriture [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4351c294b8c1028077280f761e158d167b592974"><em>correctif</em></a>].</p>
<p>Une nouvelle politique nommée <code>tcb</code> est incluse par défaut. Elle est similaire à la politique <code>ima_tcb</code> existante mais ajoute des règles tirant parti des améliorations mentionnées ci‐dessus. Le changement de la politique <code>ima_tcb</code> aurait potentiellement cassé le fonctionnement des systèmes actuels. Donc, au lieu de définir une nouvelle politique à chaque changement des options par défaut, une nouvelle option de démarrage est définie (<code>ima_policy=</code>) pour spécifier quelle politique incluse utiliser. La politique <code>ima_tcb</code> n’est plus prise en charge [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=24fd03c87695a76f0517df42a37e51b1597d2c8a"><em>correctif</em></a>].</p>
<h5 id="selinux">SELinux</h5>
<p>La liste des classes de <em>sockets</em> <em>netlink</em> a été mise à jour pour tenir compte des nouveaux ajouts dans le noyau. Les classes désormais inutiles ont aussi été supprimées [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6c6d2e9bde1c1c87a7ead806f8f5e2181d41a652"><em>correctif</em></a>].</p>
<p>Les fichiers des systèmes de fichiers virtuels <code>sysfs</code>, <code>pstore</code> et <code>debugfs</code> peuvent être étiquetés chacun avec un contexte différent. L’utilisation de ces fichiers peut donc faire partie des contrôles d’une politique de sécurité. Cette amélioration est importante dans le cas d’Android, où certains fichiers de <code>debugfs</code> ont besoin d’être lus par des applications et le système doit donc être accessible par tous, ce qui induit un risque en termes de sécurité [correctifs : <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=134509d54e4e98888be2697a92cb4b48957b792b"><em>1</em></a> et <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8e01472078763ebc1eaea089a1adab75dd982ccd"><em>2</em></a>].</p>
<p>Un nettoyage de certaines définitions de permissions d’accès obsolètes a été réalisé [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=42a9699a9fa179c0054ea3cf5ad3cc67104a6162"><em>correctif</em></a>].</p>
<p>Une correction a été effectuée pour un bogue introduit par un précédent correctif, qui n’avait pas tenu compte du cas où un système de fichiers était en fait un montage NFS v4.2 [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9fc2b4b436cff7d8403034676014f1be9d534942"><em>correctif</em></a>].</p>
<p>Le stockage des catégories NetLabel est maintenant plus optimal, et cela corrige indirectement un bogue sur les systèmes 32 bits [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3324603524925c7727207027d1c15e597412d15e"><em>correctif</em></a>].</p>
<p>Un <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=66fc13039422ba7df2d01a8ee0873e4ef965b50b">correctif</a> ajouté dans le noyau 4.1 a introduit une régression qui entraînait la non exécution des vérifications de sécurité pour les accès aux zones de mémoire partagées anonymes. Un nouveau <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=892e8cac99a71f6254f84fc662068d912e1943bf">correctif</a> rétablit la situation.</p>
<h5 id="smack">SMACK</h5>
<p>Le partage de descripteurs de fichiers <a href="https://www.kernel.org/doc/Documentation/dma-buf-sharing.txt">DMA-Buf</a> ne fonctionnait pas car SMACK n’était pas capable de récupérer leurs attributs étendus. Cette situation est pour l’instant ignorée, ce qui autorise le partage de ces descripteurs de fichiers [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9777582e8d604f69ce3a93805065e451487e26b4"><em>correctif</em></a>].</p>
<p>Dans certains cas, les erreurs n’étaient pas remontées jusqu’à l’espace utilisateur, ce qui ne permettait pas de savoir d’où venait le problème. Cette situation est prise en charge par ce <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e774ad683f425a51f87711164ea166d9dcc41477"><em>correctif</em></a>.</p>
<p>SMACK peut limiter l’usage des capacités <code>CAP_MACADMIN</code> et <code>CAP_MAC_OVERRIDE</code> aux processus s’exécutant avec une étiquette spécifique. Mais n’avoir qu’une seule étiquette n’est pas suffisant dans certains cas (Tizen). L’interface <code>onlycap</code> peut désormais accepter plusieurs étiquettes [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c0d77c884461fc0dec0411e49797dc3f3651c31b"><em>correctif</em></a>].</p>
<h4 id="evm">EVM</h4>
<p>Pour éviter que les attributs étendus utilisés par EVM soient supprimés lorsque le système est éteint et régénérés automatiquement à l’exécution, EVM autorise uniquement les fichiers à recevoir une étiquette au moment de leur création. Mais comme les systèmes de fichiers virtuels ne sont pas persistants, la suppression de leurs attributs n’est pas un souci. Cette fonctionnalité est utilisée par certains modules LSM (SELinux ou SMACK, par exemple) [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5101a1850bb7ccbf107929dee9af0cd2f400940f"><em>correctif</em></a>].</p>
<h4 id="cryptographie">Cryptographie</h4>
<p>Cette nouvelle version du noyau prend en charge les Chacha20, Poly1305 et RFC7539 [correctifs : <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4db4ad26096c4c1e579f9a957ca7752fe02bf7b4"><em>1</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=71ebc4d1b27d345342bdcb32a29c8cc3da8c6654"><em>2</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=af2b76b53a0668ff85b34cb108fefa85d72bb9c6"><em>3</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c08d0e647305c3f8f640010a56c9e4bafb9488d3"><em>4</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3590ebf2b4c40aa4b663c4f2b9dfeb0a1e0b8f32"><em>5</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f979e014c50ce3f7467f133898dbea2243247a91"><em>6</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=eee9dc6162c537641a9259ae595193fa3c68c96e"><em>7</em></a> et <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5900758df19afa91026ad61f60a65164a41aac48"><em>8</em></a>].</p>
<p>L’implémentation de SHA-512 a été remplacée par celle, plus flexible, utilisée par le projet OpenSSL. Cette dernière contient une version accélérée pour ARM64 et une version générique [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c80ae7ca372606a3971dcdfa3420275cf17ef6b6"><em>correctif</em></a>].</p>
<h5 id="jitter-rng">Jitter RNG</h5>
<p>Une nouvelle source d’entropie pouvant être utilisée uniquement à l’intérieur du noyau a été introduite. Elle n’est donc pas exposée à l’espace utilisateur. Le « <em>jitterentropy RNG</em> » mesure certains intervalles de temps entre des accès mémoire et des instructions exécutées par le processeur pour générer une suite de bits qui vérifie certaines propriétés de non déterminisme. Cela ne permet pas de prouver que l’ensemble est réellement aléatoire, donc il va principalement être utilisé comme graine supplémentaire et non comme remplacement des autres sources d’entropie [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bb5530e4082446aac3a3d69780cd4dbfa4520013"><em>correctif</em></a> ; <a href="https://lwn.net/Articles/642166/">article <em>LWN.net</em> : <em>Random numbers from CPU execution time jitter</em></a> ; <a href="http://www.chronox.de/jent.html"><em>CPU Jitter Random Number Generator</em></a>].</p>
<h5 id="deterministic-random-bit-generator-drbg">Deterministic Random Bit Generator (DRBG)</h5>
<p>Le DRBG remplace le générateur de nombres aléatoires par défaut dans le noyau. Il est alimenté par le « <em>jitterentropy RNG</em> » comme source additionnelle [correctifs : <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=401e4238f35c7a21d32bc27370d4d045f7019c20"><em>1</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a5b151d11cdf8b88ccace32fa0bd23962cbca20a"><em>2</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=42ea507fae1ac4b4af0d9d715ab56fa4de2a0341"><em>3</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=57225e6797885e31302e76fc5926c0bedd7e5ad4"><em>4</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fbb145bc0a1c03b90a96cca99dc07c33aaad2318"><em>5</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51ee14227411c713c428f5ff6a70fae8b2b33daa"><em>6</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b8ec5ba42c4a3854e27c44e697d9b4f0b84b32bb"><em>7</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4c7879907eddd5b3ec09489bc980aab4f44e38dd"><em>8</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3d6a5f75d1340539dcdcec4609761fa4b836a1f2"><em>9</em></a> et <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8fded5925d0a733c46f8d0b5edd1c9b315882b1d"><em>10</em></a> ; <a href="http://www.chronox.de/drbg.html"><em>SP800-90A Deterministic Random Bit Generator (DRBG)</em></a>].</p>
<h5 id="nouvelle-api-de-chiffrement-de-clef-publique">Nouvelle API de chiffrement de clef publique</h5>
<p>Cette nouvelle interface logicielle permet l’implémentation de calcul déporté de manière asynchrone, lorsque le matériel requis est présent et pris en charge par l’API de chiffrement de Linux [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3c339ab83fc09d9d91fb7e8b4a60e8ddc91de417"><em>correctif</em></a>].</p>
<h5 id="matériel">Matériel</h5>
<p>La gestion du module d’opérations cryptographiques présent sur certaines cartes embarquées Marvell a été ajoutée [correctifs : <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f63601fd616ab370774fa00ea10bcaaa9e48e84c"><em>1</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=db509a45339fd786de355b11db34ff7421488cb1"><em>2</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7b3aaaa095b437bfcb4e4c761a19f50294659f3a"><em>3</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4ada483978237068bf21c0dc318af676145bfed5"><em>4</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7aeef693d18d359134f47bf7b6621ec303b570f9"><em>5</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f85a762e49bda3cba143ab0db8bde6d2bbe8baf9"><em>6</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=898c9d5ea2182287620f8995b32e457d7b3b54ca"><em>7</em></a>…].</p>
<h4 id="divers">Divers</h4>
<p>Tous les usages de structures <code>kernel_param_ops</code> utilisent désormais l’attribut <code>const</code> [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9c27847dda9cfae7c273cde62becf364f9fa9ea3"><em>correctif</em></a>].</p>
<h4 id="sysfs-proc-et-les-conteneurs">
<code>sysfs</code>, <code>/proc</code> et les conteneurs</h4>
<p>Le montage des arborescences <code>sysfs</code> et <code>/proc</code> a été modifié pour n’autoriser que certains dossier particuliers (notamment <code>/sys/debug</code>) à servir de point de montage pour d’autres systèmes de fichiers virtuels. Une nouvelle règle a été ajoutée pour s’assurer qu’une nouvelle instance de ces points de montage (par exemple dans un conteneur) utilise au minimum les attributs de montage utilisés par les instances existantes (<code>nodev</code>, <code>ro</code> et <code>atime</code>). Il avait été proposé d’obliger ces points de montage à être montés avec les options <code>noexec</code> et <code>nosuid</code>, mais cela a été retiré [correctifs : <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7236c85e1be51a9e25ba0f6e087a66ca89605a49"><em>1</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f9bb48825a6b5d02f4cabcc78967c75db903dcdc"><em>2</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=87d2846fcf88113fae2341da1ca9a71f0d916f2c"><em>3</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ea015218f2f7ace2dad9cedd21ed95bdba2886d7"><em>4</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=eb6d38d5427b3ad42f5268da0f1dd31bb0af1264"><em>5</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f9bd6733d3f11e24f3949becf277507d422ee1eb"><em>6</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fbabfd0f4ee2e8847bf56edf481249ad1bb8c44d"><em>7</em></a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8c6cf9cc829fcd0b179b59f7fe288941d0e31108"><em>8</em></a> et <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1b852bceb0d111e510d1a15826ecc4a19358d512"><em>9</em></a> ; <a href="http://lwn.net/Articles/647757/">article <em>LWN.net</em> : <em>Enforcing mount options for sysfs and proc</em></a>].</p>
<h4 id="liste-non-exhaustive-des-vulnérabilités-corrigées">Liste non exhaustive des vulnérabilités corrigées</h4>
<ul>
<li>CVE-2015-1333 <a href="https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-1333">NVD</a>, <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1333">Mitre</a> : <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ca4da5dd1f99fe9c59f1709fb43e818b18ad20e0"><em>correctif</em></a> ;</li>
<li>CVE-2015-3291 <a href="https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-3291">NVD</a>, <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3291">Mitre</a> : <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=810bc075f78ff2c221536eb3008eac6a492dba2d"><em>correctif</em></a> ;</li>
<li>CVE-2015-5157 <a href="https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-5157">NVD</a>, <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5157">Mitre</a> : correctifs <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=37868fe113ff2ba814b3b4eb12df214df555f8dc"><em>1</em></a> et <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b6e6a8334d56354853f9c255d1395c2ba570e0a"><em>2</em></a>, <a href="http://www.openwall.com/lists/oss-security/2015/07/22/7">discussion sur oss-security</a>, <a href="http://www.openwall.com/lists/oss-security/2015/08/04/8">explication complète</a> ;</li>
<li>CVE-2015-3290 <a href="https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-3290">NVD</a>, <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3290">Mitre</a> : <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b6e6a8334d56354853f9c255d1395c2ba570e0a"><em>correctif</em></a> ;</li>
<li>CVE-2015-5697 <a href="https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-5697">NVD</a>, <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5697">Mitre</a> : <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=21509084f999d7accd32e45961ef76853112e978"><em>correctif</em></a> ;</li>
<li>? : <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=892e8cac99a71f6254f84fc662068d912e1943bf"><em>correctif</em></a>.</li>
</ul><h3 id="systèmes-de-fichiers">Systèmes de fichiers</h3>
<h5 id="fuse">FUSE</h5>
<p>FUSE est une interface noyau qui permet d’implémenter des systèmes de fichiers en espace utilisateur. Malheureusement, son manque de performance est pointé régulièrement.<br>
Linus Torvalds a également fait remarquer que FUSE est un jouet destiné aux gens égarés. Malgré cela, de nombreux systèmes ont vu le jour, tels que SSHFS, WebDrive, boxfs, GlusterFS, jusqu’à ZFS. FUSE a été porté sur divers systèmes, tels qu’OS X, FreeBSD ou encore NetBSD.<br>
La montée en charge a été améliorée. Miklos Szeredi a expliqué que l’un des problèmes vient d’une connexion monolithique à FUSE. Le fait de cloner les connexions FUSE permet de ne plus avoir de lecture‐écriture requête‐réponse sur un seul descripteur de fichier et permet au démon FUSE d’avoir de multiples descripteurs, chacun pouvant être utilisé pour recevoir des requêtes et envoyer des réponses [<a href="http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.2-FUSE-Scaling">article sur <em>Phoronix.com</em></a>].</p>
<h5 id="btrfs">Btrfs</h5>
<p>La gestion des quotas sur les sous‐volumes a été mise à jour. La gestion des périphériques a été améliorée, et divers changements ont eu lieu, pour un total de 1 500 lignes de code changées [<a href="http://www.phoronix.com/scan.php?page=news_item&px=Btrfs-Linux-4.2-Updates">article sur <em>Phoronix.com</em></a>].</p>
<h5 id="f2fs">F2FS</h5>
<p>F2FS, le système de fichiers pour NAND et mémoire flash, gère désormais le chiffrement par fichier.<br>
Une amélioration de la gestion du <a href="https://fr.wikipedia.org/wiki/TRIM">TRIM</a> a été apportée, ainsi que la récupération des superblocs endommagés et diverses corrections [<a href="http://www.phoronix.com/scan.php?page=news_item&px=F2FS-Encryption-Linux-4.2">article sur <em>Phoronix.com</em></a>].</p>
<h5 id="gfs2">GFS2</h5>
<p><em>Global File System 2</em> (GFS2) est un système réseau distribué. Des améliorations de performance ont été faites, par exemple sur le renommage des fichiers. La consommation mémoire via les tampons a été réduite. Une meilleure gestion des verrous a abouti à un gain en performances [<a href="http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.2-GFS2-Performance">article sur <em>Phoronix.com</em></a>].</p>
<h5 id="ext4">ext4</h5>
<p>La stabilisation et le nettoyage d’ext4 se poursuivent, surtout suite à l’ajout de la gestion du chiffrement. Il est possible de remplir une partie d’un fichier avec des zéros grâce à l’option <code>FALLOC_FL_INSERT_RANGE</code> [<a href="http://www.phoronix.com/scan.php?page=news_item&px=EXT4-Updates-Linux-4.2">article sur <em>Phoronix.com</em></a>].</p>
<h5 id="ncq-trim">NCQ TRIM</h5>
<p>Dans la lancée des optimisations SSD faites par l’ordonnanceur, la prise en charge du <a href="https://en.wikipedia.org/wiki/Native_Command_Queuing">NCQ TRIM</a> a été améliorée. Il est maintenant activable ou désactivable au démarrage, mais dans beaucoup de micrologiciels le TRIM n’a pas été testé et peut provoquer erreurs et corruptions [<a href="http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.2-libata-NCQ-TRIM">article sur <em>Phoronix.com</em></a>].</p>
<h4 id="ext3-est-en-cours-de-suppression">ext3 est en cours de suppression</h4>
<p><a href="http://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Dropping-EXT3"><em>Assuming no major objections come up, the ext3 file-system driver will be dropped for the Linux 4.3 kernel</em></a>, confirmation de la <a href="https://lkml.org/lkml/2015/7/15/438">suppression d’ext3 au profit d’ext4 qui le gère, sur la <em>LKML</em></a>.</p>
<p><em>ext4</em> est rétro‐compatible avec <em>ext3</em> et <em>ext2</em>, donc cette suppression est sans conséquences. C’est le mainteneur d’<em>ext3</em> qui a poussé les correctifs. Le mainteneur d’<em>ext4</em> a déjà donné son accord.</p>
<h3 id="virtualisation">Virtualisation</h3>
<h4 id="kvm"><a href="https://lkml.org/lkml/2015/6/23/479">KVM</a></h4>
<ul>
<li>ARM : beaucoup de changements sont en cours, mais rien n’est encore prêt pour cette version, il y a juste des corrections de bogues et l’activation du <a href="https://www.kernel.org/doc/Documentation/vfio.txt">VFIO</a> qui permet d’avoir un pilote en espace utilisateur pour l’accès direct au matériel d’entrées‐sorties. Un point intéressant pour les performances des machines virtuelles.</li>
<li>s390 (ordinateurs centraux IBM) : des corrections de bogues et la prise en charge des pages mémoire de plus de 2 Gio.</li>
<li>x86 : l’hôte et l’invité peuvent utiliser <em>kvmclock</em> en tant qu’ordonnanceur ; prise en charge de l’écriture combinée ; prise en charge du <em>system management mode</em> (SMM), nécessaire au <em>secure boot</em> pour les invités ; implémentation des compteurs de performance virtualisés pour les processeurs AMD. L’allocation PCI <em>legacy</em> est obsolète et l’option de compilation est maintenant de ne pas inclure le mécanisme par défaut à la compilation (remplacé par VFIO). En plus de cela, il y a aussi le chargement opportuniste de contexte FPU pour les invités utilisant beaucoup le calcul à virgule flottante.</li>
<li>code commun : prise en charge de plusieurs espaces d’adressage. Pour l’instant, seul le code x86 SMM en profite, mais l’équipe derrière le s390 veut aussi l’utiliser.</li>
</ul><h4 id="xen"><a href="https://lkml.org/lkml/2015/6/30/319">Xen</a></h4>
<ul>
<li>Ajout de <code>make xenconfig</code> pour faciliter la création de noyaux pour invités Xen.</li>
<li>Préparation de l’intégration des pages mémoire de 64 Kio pour ARM.</li>
<li>Utilisation automatique de <code>hvc0</code> pour ARM.</li>
</ul><h2 id="le-bilan-en-chiffres">Le bilan en chiffres</h2>
<p>Linux 4.2 permet au noyau de passer le cap des 20 millions de lignes de code et plus de 50 000 fichiers. Cette version est la seconde en termes de nombre de modifications depuis l’introduction de Git. En effet, le noyau 3.15 reste malgré tout légèrement plus imposant, mais nous sommes ici en présence d’une grosse version. Outre le nombre de modifications, le nombre de lignes insérées dépasse le million (avec une moyenne de 700 000 depuis l’introduction de Git), alors que le nombre de lignes supprimées reste stable par rapport aux versions précédentes, soit environ 280 000 lignes (avec une moyenne de 300 000 depuis l’introduction de Git).</p>
<p>Cette fois, il faut remonter au noyau 2.6.28 pour espérer avoir une aussi grande variation du nombre de lignes de code. Ce dernier oscille généralement entre 200 000 et 300 000, alors que nous sommes ici à presque 800 000 lignes (moyenne de 230 000).</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f646f63732e676f6f676c652e636f6d2f7370726561647368656574732f642f315547774b47454654524f305f395030654c6561524476757139546232577970326f4444464f7279525f47552f70756263686172743f6f69643d33333639333439323126666f726d61743d696d616765/pubchart?oid=336934921&format=image" alt="Evolution des insertions et suppression dans le noyau depuis le 3.0" title="Source : https://docs.google.com/spreadsheets/d/1UGwKGEFTRO0_9P0eLeaRDvuq9Tb2Wyp2oDDFOryR_GU/pubchart?oid=336934921&format=image"></p>
<p>Bref, une nouvelle version riche de code, et un doublement du nombre de lignes depuis le 25 décembre 2008, où, pour la première fois, le noyau dépassa les 10 millions de lignes de code.</p>
<p>Si vous êtes intéressé par les chiffres bruts, mais bien mis en forme, Thorsten Leemhuis les a compilés dans un <a href="https://docs.google.com/spreadsheets/d/1_yH7lFmZxAoSWrtsd8tGu3befG4zIcMnytB1ml4pQQM/edit#gid=0">beau classeur à découvrir</a>.</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f646f63732e676f6f676c652e636f6d2f7370726561647368656574732f642f315547774b47454654524f305f395030654c6561524476757139546232577970326f4444464f7279525f47552f70756263686172743f6f69643d36373532363534363926666f726d61743d696d616765/pubchart?oid=675265469&format=image" alt="Evolution du nombre de ligne dans le noyau" title="Source : https://docs.google.com/spreadsheets/d/1UGwKGEFTRO0_9P0eLeaRDvuq9Tb2Wyp2oDDFOryR_GU/pubchart?oid=675265469&format=image"></p>
<h2 id="appel-à-volontaires">Appel à volontaires</h2>
<p>Cette dépêche a nécessité plus de 780 éditions (à l’heure de l’écriture de ces statistiques), et mobilisé 22 personnes du 21 juillet au 16 septembre 2015 dans l’espace de rédaction.</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f646f63732e676f6f676c652e636f6d2f7370726561647368656574732f642f315547774b47454654524f305f395030654c6561524476757139546232577970326f4444464f7279525f47552f70756263686172743f6f69643d383537353338333326666f726d61743d696d616765/pubchart?oid=85753833&format=image" alt="Répartition des éditions de cette dépêche" title="Source : https://docs.google.com/spreadsheets/d/1UGwKGEFTRO0_9P0eLeaRDvuq9Tb2Wyp2oDDFOryR_GU/pubchart?oid=85753833&format=image"></p>
<p>Cette dépêche est rédigée par plusieurs contributeurs, dont voici la répartition :</p>
<table>
<thead><tr>
<th></th>
<th>Mainteneur</th>
<th>Contributeur(s)</th>
</tr></thead>
<tbody>
<tr>
<td><strong>La phase de test</strong></td>
<td>Aucun</td>
<td><a href="//linuxfr.org/users/robin--2">Robin</a></td>
</tr>
<tr>
<td><strong>Architecture</strong></td>
<td><a href="//linuxfr.org/users/rperier">Romain Perier</a></td>
<td></td>
</tr>
<tr>
<td><strong>Développeurs</strong></td>
<td>Aucun</td>
<td></td>
</tr>
<tr>
<td><strong>Pilotes graphiques libres</strong></td>
<td><a href="//linuxfr.org/users/mupuf">Martin Peres</a></td>
<td></td>
</tr>
<tr>
<td><strong>Réseau</strong></td>
<td>Aucun</td>
<td><a href="//linuxfr.org/users/ffourcot">Florent Fourcot</a></td>
</tr>
<tr>
<td><strong>Systèmes de fichiers</strong></td>
<td>Aucun</td>
<td><a href="//linuxfr.org/users/alpha_one_x86">BRULE Herman</a></td>
</tr>
<tr>
<td><strong>Sécurité</strong></td>
<td><a href="//linuxfr.org/users/siosm">Timothée Ravier</a></td>
<td></td>
</tr>
<tr>
<td><strong>Virtualisation</strong></td>
<td><a href="//linuxfr.org/users/claudex">Xavier Claude</a></td>
<td></td>
</tr>
<tr>
<td><strong>Édition générale</strong></td>
<td>Aucun</td>
<td>
<a href="//linuxfr.org/users/eggman"><em>eggman</em></a>, <a href="//linuxfr.org/users/jcr83"><em>jcr83</em></a>, <a href="//linuxfr.org/users/m5oul"><em>M5oul</em></a>
</td>
</tr>
</tbody>
</table><p>Un peu de vocabulaire :</p>
<ul>
<li>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 ;</li>
<li>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.</li>
</ul><p>Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps et de volontaires.</p>
<blockquote>
<p>Nous sommes particulièrement à la recherche de mainteneurs pour les sections <em>Systèmes de fichiers</em> et <em>Réseau</em>, les précédents n’ayant pas donné de signes de vie pendant la rédaction des dernières dépêches.</p>
</blockquote>
<p>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 <em>commits</em> 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 !<br>
C’est un travail à faire au fil du temps, par ajouts successifs (une simple adresse URL ou un § enrichissent déjà le contenu et les sources), n’hésitez-pas !</p></div><div><a href="https://linuxfr.org/news/sortie-du-noyau-linux-4-2.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/106349/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/sortie-du-noyau-linux-4-2#comments">ouvrir dans le navigateur</a>
</p>
jcr83Davy DefaudesdeemM5oulrobinMartin PeresTiwazBAudSiosmNÿcopalm123alpha_one_x86Florent FourcotBenoît SibaudclaudexRomain PerierYves BourguignonFrédéric MassotfasthmantistressAlexandre Bellonipums974SurfooFrançoishttps://linuxfr.org/nodes/106349/comments.atom