Sortie du noyau Linux 4.5

La sortie de la version stable 4.5 du noyau Linux a été annoncée le 13 mars 2016 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org.

Le détail des évolutions, nouveautés et prévisions se trouve dans la seconde partie de la dépêche (qui est sous licence CC BY-SA, Attribution — Partage dans les Mêmes Conditions).

Sommaire

• En bref
• Annonces des RC par Linus Torvalds
  • RC1
  • RC2
  • RC3
  • RC4
  • RC5
  • RC6
  • RC7
  • Version finale
• Les nouveautés
  • Gestion de la mémoire
  • Architecture
    • Gestion d’énergie
    • ARM SoC
      • Retravail massif des architectures ARM v6 et ARM v7
    • En bref
    • MIPS
  • Développement et traçage
    • Prise en charge de l’option Sanitizer (-fsanitize=undefined) de GCC
    • Introduction d’un nouvel appel système copy_file_range()
  • Pilotes graphiques libres
    • AMD (pilotes amdgpu et radeon)
      • Prise en charge expérimentale de PowerPlay
    • Broadcom (pilote vc4 pour RPi)
    • Intel (pilote i915)
    • NVIDIA (pilote nouveau)
    • Autres
  • Réseau
    •  Paramètres TCP keepalive configurables par espace de noms réseau
    •  Ajout des compteurs paquets/octets au module Netfilter nft_ct
  • Sécurité
  • Périphériques en mode bloc (block devices)
  • Systèmes de fichiers
    • Btrfs
    • ext4
  • Virtualisation
    • KVM
      • S390
      • ARM
      • x86
  • Cgroups
• Le bilan en chiffres
• Systématisation du choix du noyau destiné à être maintenu à long terme
• Appel à volontaires

En bref

Annonces des RC par Linus Torvalds

RC1

La version RC1 est sortie le dimanche 24 janvier 2016 :

La fenêtre de fusion est close et la RC1 est là. Allez‐y, testez !

C’est une version relativement normale — ni anormalement grande, ni anormalement petite. Les statistiques sont également relativement normales, avec les pilotes un peu au-dessus de 70 % de l’ensemble (le gros des pilotes étant les pilotes graphiques, le réseau, le son, staging, fbdev, mais il y en a un peu partout). Le journal abrégé est trop gros et indigeste pour être joint au message ; mais, je joins mon « journal de fusion » qui crédite les mainteneurs avec lesquels j’ai effectué les fusions — mais pas nécessairement les personnes qui ont fait chacun des correctifs.

Outre les pilotes, nous avons les mises à jour d’architectures (plus de la moitié d’entre elles étant pour ARM — 32 et 64 bits cette fois‐ci, le reste se composant des PowerPC, x86, MIPS, S390). Concernant les architectures, il est probablement utile de mentionner qu’apparemment, les gens d’ARM (!) ont finalisé leurs travaux sur la plate‐forme et que vous pouvez vraiment construire un noyau ARM générique pour toutes les plates‐formes ARMv6/7 (et décrire le matériel avec devicetree). Ça a pris de nombreuses années pour y arriver. Beau boulot.

Il y a, évidemment, les habituelles mises à jour de documentation, de systèmes de fichiers, de réseau et celles du noyau de base. Un certain nombre de jolis nettoyages de MM sont venus d’Andrew cette fois‐ci, par exemple, et Al Viro a fait en sorte que les recherches de chemin (pathname lookup) restent en mode RCU, même lors des traversées de chemins symboliques (symlink traversal).

Il y en a un peu pour tout le monde.

Linus

RC2

La version RC2 est sortie le dimanche 31 janvier 2016 :

Pas plus tard que vendredi, je comptais parler de combien il est agréable de voir cette nouvelle tendance de petites RC2, parce qu’il n’y avait vraiment pas eu beaucoup de demandes d’intégration.

Mais il s’avère que les demandes d’intégrations étaient juste fortement décalées vers la fin de la semaine et que la 4.5-rc2 n’est pas particulièrement petite après tout. Elle a quasiment doublé dans le week-end.

Ce n’est pas si gros que ça de toute façon et le décalage vers la fin de la semaine est probablement logique pour une RC2 — ça prend un certain temps pour commencer à trouver les problèmes que la fenêtre d'intégration a apportés. Ainsi, ce comportement bizarre ne m’inquiète pas : ça me parait assez naturel.

Pour le type de corrections que nous avons ici, le journal abrégé donne plus de détails, mais il y en a un peu partout. Les mises à jour de pilotes et d’architectures représentent seulement la moitié environ des modifications, avec des correctifs de performance et de nouveaux auto-test de virtio représentant la plupart de ce qui reste. Il y a également des correctifs de btrfs.

Rien de tout cela n’est vraiment important de toute façon.

Allez‐y, testez.

Linus

RC3

La version RC3 est sortie le dimanche 7 février 2016 :

C’est dimanche après-midi et tout est normal. Donc ça signifie qu’il y a une nouvelle RC pile dans les temps.

Elle est légèrement plus grosse que j’aurais aimé, mais pas excessivement (ni même inhabituellement). La majorité des correctifs sont assez petits, bien que les modifications soient totalement dominées par la (grosse) suppression des pilotes RDMA en staging qui n’allaient nulle part. Ces correctifs de suppression représentent 90 % du changement.

Les 10 % restants sont constitués principalement des pilotes (réseau, pilotes graphiques, son, USB), et de divers autres choses (réseau de base, quelques correctifs VM d’Andrew, ceux des systèmes monopuces ARM, la crypto, etc.).

Donc, ce n’est peut‐être pas une petite RC, mais il n’y a rien non plus de particulièrement inquiétant.

Le journal abrégé est joint, pour les personnes qui veulent un aperçu plus détaillé.

Linus

RC4

La version RC4 est sortie le dimanche 14 février 2016 :

C’est la Saint-Valentin, donc je prépare un cadeau pour tous, sous la forme d’une RC habituelle.

Tout a l’air normal, il y a un problème en attente et non expliqué pour l’instant, avec des modifications concernant les VM dans cette version (en particulier le nettoyage transparent des huge pages), mais cela semble concerner uniquement l’architecture S390, donc cela ne devrait pas bloquer tout le monde.

Et sinon tout semble normal. La taille est normale, comparée aux récentes RC4, et rien ne ressort en particulier. Un peu moins des 2/3 concerne les pilotes (DRM, son, SCSI, réseau… C’est assez réparti), et le reste est habituel : mises à jour d’architectures, (ARC, MIPS, ARM) et diverses choses (cryptographie, réseau et noyau…).

Comme d’habitude, le journal abrégé est attaché, on peut le parcourir pour avoir une idée de ce qui se passe.

Donc, à part vous occuper de votre chéri(e), vous pouvez y aller et tester.
Je voyagerai la semaine prochaine, mais j’aurai mon ordinateur portable, et si les choses restent tranquilles et normales comme jusqu’ici, il ne devrait pas y avoir de problèmes.

Linus

RC5

La version RC5 est sortie le samedi 20 février 2016 :

Tout continue à être normal et a été bien calme. D’accord, le nettoyage de la VM THP semble toujours poser problème sur S390, mais à part cela, je ne vois rien d’inquiétant.

Une autre semaine, une autre RC. La modification a l’air tout à fait normale, avec 55 % de pilotes (DRM et clk surtout, mais ils ne sont pas seuls) et presque 20 % de mises à jour d’architectures (ARM, m68k, PowerPC, S390, x86). Le reste est réparti entre systèmes de fichiers (ext4, EFI, CIFS), quelques mises à jour de noyau et en‐têtes de fichiers. Et des mises à jour de documentation. Tout a l’air normal.

Le journal abrégé est joint.

Linus

RC6

La version RC6 est sortie le dimanche 28 février 2016 :

J’aurais souhaité une RC-6 plus petite mais, en même temps, je suis plutôt soulagé que Kirill ait trouvé et corrigé le problème avec le nettoyage du code des THP qui nous avait frappé pendant ce cycle de publication. Donc, je ne peux pas vraiment me plaindre. S’ajoute à mon grand soulagement un autre rapport de bogue effrayant qui s’est avéré ne pas être du tout un bogue du noyau, mais un problème de microcode. Ce qui pourrait peut‐être être pire, mais au moins ce n’est pas quelque chose dont nous sommes responsables (et maintenant que c’est connu, c’est évitable).

Les statistiques des changements paraissent bizarres cette fois, parce qu’il y a un gros correctif concernant les fichiers d’en‐tête des pilotes réseau, qui donne l’impression que le dossier des include représente quasiment 40 % des changements. Mais ce correctif ne fait que renommer une tonne de champs réservés, aucun code n’est effectivement modifié.

Si l’on ignore cette bizarrerie statistique, tout semble plutôt normal : principalement des pilotes (le réseau et l’USB dominent, mais il y a également quelques modifications de pilotes graphiques, son, ACPI), avec les habituelles mises à jour d’architecture (ARC, ARM, x86) et un peu de réseau de base. Quelques travaux de performance et quelques corrections de systèmes de fichiers (NFS, DAX et un peu de VFS de base).

J’aimerais pouvoir dire que nous sommes sur la bonne voie pour respecter le calendrier habituel de publication, mais attendons de voir l’avancement la semaine prochaine. Si la RC-7 n’a pas commencé à diminuer, je pourrais décider finalement que cette version est l’une de celles où l’on fait aussi une RC-8. C’est trop tôt pour le dire. Il n’y a rien de particulièrement effrayant, mais j’aurais aimé une RC encore plus calme cette semaine.

Le journal abrégé est joint, comme d’habitude, pour les personnes qui veulent un aperçu des détails.

Linus

RC7

La version RC7 est sortie le dimanche 6 mars 2016 :

Les choses se sont calmées la semaine dernière et je pense que l’on aboutira à une version normale, où la RC-7 est la dernière RC.

Bien sûr, je me réserve le droit de changer d’avis, au cas où nous trouverions quelque chose de fâcheux, mais dans l’ensemble, ça me paraît bien. Nous avons eu des changements plus importants que je n’aimerais à ce stade, mais ils concernaient pour la plupart des pilotes individuels. La plupart des modifications sont triviales, d’une ou deux lignes, avec peut‐être juste la couche bloc qui se distingue par de plus gros changements (et plus gros relativement au reste, pas particulièrement gros dans l’absolu).

Les changements sont très épars, mais environ 3/4 touchent les pilotes (la suppression d’un pilote USB redondant représente le plus gros morceau, mais il y a un peu de tout, y compris des correctifs de compatibilité de son, de pilotes graphiques, watchdog, libdata, RDMA, etc.). Le reste correspond à des correctifs d’architectures (SPARC, x86, MIPS, ARM) et de systèmes de fichiers (JFFS, CIFS, Ceph, Btrfs, mais aussi un joli petit correctif dans le code de dentry qui non seulement corrige un bogue, mais nettoie aussi pas mal de choses).

Donc, allez‐y, testez, parce que nous devrions avoir pratiquement terminé à ce point pour cette version et les choses semblent aller très bien.

Le journal abrégé est joint comme d’habitude, pour les personnes qui veulent des informations plus détaillées à propos des choses qui ont eu lieu cette semaine,

Linus

Version finale

La version finale est sortie le dimanche 13 mars 2016 :

C’est un peu tard pour un dimanche, plus tard que mon horaire habituel, parce que je n’arrivais pas à décider si je devais faire une RC-8 ou pas et j’ai tergiversé à ce sujet. En fin de compte, j’ai évidemment décidé de publier, mais il aurait pu en être autrement.

Nous avons eu une méchante régression qui a été réparée hier. Les dernières corrections de la couche réseau envoyées en début de semaine étaient plus grandes que je ne l’aurais souhaité. Mais la couche bloc devrait être parfaite maintenant. David a relu toute sa demande de modification de la couche réseau une nouvelle fois pour me rassurer à ce sujet. Donc, à la fin, je ne vois rien pour retarder ce cycle de sortie plus longtemps que d’habitude.

Dans l’ensemble, tout semble plutôt petit. Le diffstat paraît un peu plus gros pour un correctif de XFS, parce qu’il a trois correctifs de travail de nettoyage qui le précèdent. Il y a aussi un correctif de modèle de type d’accès (?) dans la couche son qui générait beaucoup de bruit, mais tout est très simple en fin de compte.

En plus de ce qui précède, il y a de petits correctifs un peu partout — le journal abrégé est joint pour les gens qui veulent parcourir les détails, comme d’habitude.

Allez‐y, testez. Et, évidemment, avec la publication de la 4.5, je vais ouvrir la fenêtre de fusion pour la 4.6.

Linus

Les nouveautés

Gestion de la mémoire

Architecture

Gestion d’énergie

La gestion d’énergie du noyau est améliorée (et le sera davantage pour la prochaine version 4.6), grâce à une meilleure gestion du processeur graphique, de l’ACPI et du PCI express. Si vous aimez les chiffres et les jolies courbes, Phoronix montre l’amélioration de la consommation, en milliwatts. En résumé, nous avons un gain moyen de 9 % pour la version 4.5 par rapport à la version 4.4 et, logiquement, la température globale baisse d’un même facteur. Des gains de 10 % à 12 % supplémentaires sont à attendre pour la version 4.6.

ARM SoC

Retravail massif des architectures ARM v6 et ARM v7

Ce travail est le résultat de cinq ans pour unifier les architectures ARM v6 et ARM v7 et permettre l’utilisation du même noyau. Cela fait suite au grand nettoyage et travail d’abstraction de la plate‐forme via la création de sous‐systèmes. Cela permet, entre autres, de faire démarrer différentes plates‐formes avec un seul et même noyau, alors que, jusqu’à présent, il était nécessaire d’avoir un noyau par plate‐forme.

Référence : commit.

En bref

• prise en charge des processeurs ARM Cortex-A9Tango4, spécialisés pour les plates‐formes multimédia « sécurisées » de Sigma Designs ;
• prise en charge du Broadcom BCM2836 (système monopuce du Raspberry Pi 2) et de la gestion de puissance (power management) via le microcode interne ;
• activation de cpufreq sur le Freescale i.MX7D ;
• Rockchip : prise en charge du SMP pour le rk3036, prise en charge générale pour le rk3228 ;
• prise en charge du SMP pour les systèmes monopuces Broadcom Kona et NSP ;
• nettoyage du côté OMAP en supprimant l’ancien code IOMMU ;
• ajout de la prise en charge de l’Orange Pi Plus (puce Allwinner).

MIPS

• Début de prise en charge du système monopuce à base de MIPS Microchip PIC32MZDA, actuellement seulement le Device Tree, les pilotes viendront pour Linux 4.6 ;
• prise en charge des structures nvram pour BCM963xx ;
• beaucoup de travail sur la prise en charge de la norme IEEE Std 754 (math-emu) ;
• prise en charge du MediaTek MT7621.

---

Développement et traçage

Prise en charge de l’option Sanitizer (-fsanitize=undefined) de GCC

Cette option, disponible à partir de GCC 4.9, est un outil de débogage qui insère du code d’instrumentation durant la compilation. Ce code permet de faire des vérifications à l’exécution, et de prévenir en amont les comportements dits « indéfinis ». Désormais, le noyau 4.5 prend en charge l’activation de cette option.

Introduction d’un nouvel appel système copy_file_range()

Ce nouvel appel système copy_file_range() permet de faire des copies « sans charge ». S’il n’apporte que peu d’avantage en local, ce nouvel appel permet, dans le cas de systèmes de fichiers réseau, d’effectuer la copie sans passer par le client dans le cas d’un transfert sur le même serveur. Par exemple, pour une copie en NFS, il peut éviter de faire transiter le flux du fichier sur le réseau.

Pilotes graphiques libres

AMD (pilotes amdgpu et radeon)

Prise en charge expérimentale de PowerPlay

La prise en charge expérimentale de PowerPlay apporte de meilleures performances au pilote amdgpu. Les cartes graphiques modernes démarrent en mode économie d’énergie et faible performance. Pour avoir les meilleures performances, la carte doit dynamiquement changer ses fréquences d’horloge.

Linux 4.5 ajoute la prise en charge de la technologie PowerPlay dans le pilote amdgpu pour les processeurs graphiques Tonga et Fiji, ainsi que pour les processeurs graphiques embarqués Carrizo et Stoney.

PowerPlay est le nom commercial d’un ensemble de technologies de gestion de l’énergie réalisées dans plusieurs processeurs graphiques AMD. Il est disponible via le pilote propriétaire Catalyst et a pour but de remplacer la gestion de l’énergie actuellement utilisée sous Linux dans le pilote amdgpu.

Pour les processeurs graphiques ayant la possibilité de changer les fréquences d’horloge, les performances seront bien meilleures.

PowerPlay n’est pas activé par défaut pour le matériel pris en charge, à cause de soucis de stabilité. Il est cependant activable en ajoutant l’option « amdgpu.powerplay=1 » au démarrage.

Voir : https://lists.freedesktop.org/archives/dri-devel/2015-November/094230.html.

Broadcom (pilote vc4 pour RPi)

Intel (pilote i915)

• ajout d’une prise en charge basique de Kabylake ;
• ajout de l’identificateur PCI pour le SKL GT4 ;
• ajout de la prise en charge de DP MST (Display Port Multi-Stream Transport) côté processeur graphique, pour l’audio.

NVIDIA (pilote nouveau)

• prise en charge du changement de vitesse du PCI Express ;
• suppression de l’interface pstate, ajout de debugfs ;
• améliorations diverses.

Autres

Ajout du pilote DRM etnaviv pour cœur 3D basé sur Vivante, utilisé dans de nombreuses cartes ARM.

Réseau

 Paramètres TCP keepalive configurables par espace de noms réseau

Les paramètres réseaux par défaut (tcp_keepalive_time, tcp_keepalive_intvl, tcp_keepalive_probes) gérant les paquets TCP keepalive sont maintenant configurables par espace de nommage réseau (network namespace) grâce à Nikolay Borisov ([1], [2] et [3]).

Les espaces de nommage réseau, dont les conteneurs sont friands, sont des copies de la pile réseau, avec leurs propres interfaces, routes, règles pare‐feu, mais aussi leurs propres paramètres réseaux accessibles par le pseudo‐système de fichiers /proc, par exemple.

Pour rappel, le principe des paquets keepalive est de détecter les déconnexions et de maintenir les connexions actives malgré les équipements réseau rencontrés (pare‐feu, NAT…). Ainsi, lorsqu’un socket est configuré avec l’option SO_KEEPALIVE, ce qui n’est pas le cas par défaut, un chronomètre est activé à chaque réception de paquet. Après une certaine durée — tcp_keepalive_time — sans avoir reçu de nouveau paquet de l’hôte distant, un paquet sonde keepalive est émis, afin de solliciter une réponse. Sans réponse, de nouveaux paquets sondes keepalive sont réémis à intervalle de temps régulier tcp_keepalive_intvl. Passé un certain nombre d’essais tcp_keepalive_probes, la connectivité est considérée comme perdue si aucun paquet n’a été reçu.

 Ajout des compteurs paquets/octets au module Netfilter nft_ct

Les expressions de suivi de connexion ct (conntrack) dans les règles nftables acceptent maintenant deux paramètres supplémentaires, packets et bytes, qui permettent par exemple de filtrer les connexions « suivies » respectivement par nombre de paquets ou par nombre d’octets échangés.
Si la direction (original ou reply) n’est pas précisée, ces compteurs représentent la somme des valeurs dans les deux sens. Amélioration proposée par Florian Westphal [1].

Sécurité

Périphériques en mode bloc (block devices)

Correction pour la couche MD (dont le mainteneur quitte son rôle de mainteneur) pour la prise en charge des horodatages de 64 bits pour le bogue de l’année 2038.

Amélioration de la stabilité de BCache pour former une sorte de disque hybride à partir d’un SSD et d’un disque rotatif.

Diverses améliorations sur l’implémentation des normes NVM Express (NVMe) et lightNVM, qui sont bien plus adaptées pour le transfert vers les disques non‐rotatifs comme les SSD.

Systèmes de fichiers

Btrfs

Une nouvelle gestion du système de cache de l’espace libre permet d’être plus performant. Cela se ressent surtout sur les larges volumes de plus de 30 Tio. Cette fonctionnalité peut être testée via l’option « space_cache=v2 ».

ext4

Diverses corrections, surtout autour du chiffrement, ont été récemment ajoutées. Ajout du projet de quota.

Virtualisation

Il y a peu de changements avec cette version. Espérons que ça nous réserve de plus grands changements pour la suite.

KVM

S390

Prise en charge du runtime instrumentation pour les invités. Cela permet de faciliter le traçage et le débogage d’applications. Cela est utilisé par des outils comme Valgrind.
Un invité peut maintenant avoir 248 processeurs virtuels.

ARM

Réécriture du world switch de l’architecture ARM64 en C. Prise en charge des identifiants de machine virtuelle sur 16 bits. Les compteurs de performances de la virtualisation devaient être introduits avec cette version, mais ils ont raté la fenêtre de fusion.

x86

Introduction de nouvelles fonctionnalités Hyper-V (synthetic interrupt controller, un des blocs du bus des périphériques paravirtualisés), nettoyage du code des MMU.

Cgroups

Stabilisation de l’unification de la hiérarchie des cgroups : Les cgroups, introduits depuis le noyau 2.6.24, ont été retravaillés pour obtenir une nouvelle implémentation disponible depuis le noyau 3.16. Cette nouvelle version n’était disponible jusqu’à présent que via une option de montage spécifique (-o DEVEL_sane_behavior), attestant de son caractère expérimental.

Ce code est considéré comme suffisamment stable pour être désormais exposé plus directement, via le type de système de fichiers cgroup2, montable directement sans option spécifique.

Le bilan en chiffres

Selon le site LWN.net, l’article de Jonathan Corbet indique que cette version 4.5 a impliqué 1 528 développeurs, alors que pour la version 4.4, il y en avait eu 1 575.

Pour cette version 4.5, la palme du développeur le plus actif a été remportée par Linus Walleij, si l’on s’appuie sur le nombre de commits (236 changesets), ou par Doug Ledford, si l’on s’appuie sur le nombre de lignes modifiées (53 086 lignes).

Si l’on se réfère aux entreprises impliquées dans le noyau, Intel l’emporte haut la main, notamment devant Red Hat, Linaro, Samsung et AMD, en nombre de commits, même si Red Hat est premier d’une courte tête en nombre de lignes modifiées.

Systématisation du choix du noyau destiné à être maintenu à long terme

L’annonce a été faite durant ce cycle : dorénavant le premier noyau à sortir chaque année sera automatiquement désigné comme étant la version LTS annuelle, comme développé dans ce journal.

Appel à volontaires

Cette dépêche a nécessité plus de 410 éditions (à l’heure de l’écriture de ces statistiques), et mobilisé 23 personnes du 24 février 2016 au 13 avril 2016 dans l’espace de rédaction.

Graphe
Cette dépêche est rédigée par plusieurs contributeurs, dont voici la répartition :

	Mainteneur	Contributeur(s)
En bref	Aucun	rogo
La phase de test	Aucun	Aucun
Arch	Aucun	Tiwaz
IPC	Aucun	ariasuni
Développement	Aucun	rogo
Pilotes graphiques libres	Martin Peres	Aucun
Réseau	Aucun	Florent Fourcot, Tiwaz
Block devices	Aucun	rogo
Systèmes de fichiers	Aucun	ariasuni
Sécurité	Aucun	rogo
Virtualisation	Xavier Claude	Aucun
Édition générale	Aucun	jcr83, Moul, eggman

Un peu de vocabulaire :

• le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie, il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer ;
• un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche, sans aucune forme d’engagement pour le futur.

Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps et de volontaires.

Nous sommes particulièrement à la recherche de mainteneurs pour les sections Systèmes de fichiers, Réseau, Développement et IPC les précédents n’ayant pas donné de signes de vie pendant la rédaction des dernières dépêches.

Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les commits intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau !
C’est un travail à faire au fil du temps, par ajouts successifs (une simple adresse URL ou un paragraphe enrichissent déjà le contenu et les sources), n’hésitez pas !

Aller plus loin

• Dépêches des noyaux précédents (378 clics)
• Site officiel du noyau Linux (317 clics)
• La liste des nouveautés sur Kernelnewbies.org (444 clics)