Retrouvez cet article dans : Linux Magazine 96

Nous vous présentons, cette fois-ci, la vingt-deuxième révision du noyau Linux 2.6. Très riche en évolutions, elle introduit la petite révolution tant attendue dans le monde du Wifi avec l’inclusion de la pile Devicescape, une nouvelle couche firewire, une infrastructure de signalisation d’événements en espace noyau et utilisateur, un bond en avant dans la gestion du méconnu système de fichiers AFS, tourne sur une nouvelle famille de processeurs, sait utiliser encore plus de webcams... Sans compter les évolutions subies par KVM et les nouveaux timers « retardables ». Du nouveau pour tous les goûts et tous les profils d’utilisateurs donc. Nous essayons, comme à notre habitude, de synthétiser et d’expliquer les principaux points qui marquent cette nouvelle version.

[Actualité] Le noyau 2.6.22

Le Wifi

À peu près un an après la médiatisation de l’événement (cf. KC 85), Linux intègre officiellement la pile générique 802.11 développée à l’origine par la société Devicescape et placée sous GPL. Elle a été choisie pour apporter une infrastructure solide et commune aux pilotes de périphériques Wifi, qui, jusqu’à présent, devaient chacun « réinventer la roue » pour fournir les fonctions dont ils avaient besoin. En particulier, les périphériques dits « SoftMAC » (Software Medium Access Control), qui délèguent au logiciel certaines tâches étant normalement dévolues au matériel (scan, authentification, association...). Cette nouvelle pile va remplacer à moyen terme l’implémentation SoftMAC actuelle du noyau (ieee80211softmac). Elle apporte un ensemble de fonctionnalités complètes et va ainsi permettre rapidement de disposer de pilotes plus complets, en soulageant les développeurs de la nécessité de coder eux-mêmes ces fonctionnalités. Appelée mac80211 dans sa version intégrée à notre noyau favori, elle offre, côté utilisateur :

• La gestion des modes ad hoc (connexion point à point entre deux équipements), monitor (capture du trafic d’un réseau), infrastructure (client se connectant à un point d’accès), Master/access-point (l’interface gérée par mac80211 est alors un point d’accès auquel peuvent se connecter des stations clients).
• La gestion des en-têtes Radiotap, qui permettent une remontée standardisée d’informations sur les paquets du trafic. Par exemple : puissance du signal en réception et émission, bruit, atténuation, canal...
• Pour les geeks, férus d’audits de sécurité et amateurs de wardriving/piggybacking, le support de l’injection de paquets. Des patchs mac80211 pour aircrack/aireplay sont d’ores et déjà disponibles.
• Le support des interfaces virtuelles : pour se connecter à plusieurs réseaux simultanément, dans plusieurs modes différents...

L’ancienne pile du noyau, ieee80211, va coexister pendant un temps encore ; elle est en effet pour l’instant la seule à prendre en compte les périphériques FullMAC, qui, par opposition à ceux dits « SoftMAC », sont capables de gérer plus de choses directement, sans recourir au pilote.
La nouvelle infrastructure est accompagnée par une nouvelle interface de configuration qui remplace les Wireless Extensions. Dans son implémentation, elle abandonne les appels ioctl() pour être basée sur Netlink (communication noyau-userland de type socket). Elle est formée de deux parties : cfg80211 en espace noyau, chargé d’interagir avec mac80211, et la bibliothèque nl80211 en espace utilisateur, utilisée par les outils d’administration. Afin de supplanter rapidement l’interface précédente, elle maintient une compatibilité avec celle-ci, de sorte que le portage des applications existantes soit aisé.
En l’état actuel, n’espérez pas juste compiler ce tout nouveau noyau et profiter directement de mac80211 : aucun pilote l’utilisant n’a été inclus dans la branche officielle de Linux 2.6.22. Il vous faudra télécharger le pilote séparément et le compiler. Il en existe déjà plusieurs. C’est l’occasion de faire une petite synthèse de l’avancement de leur portage sur la nouvelle infrastructure et des fonctionnalités présentes et attendues. Le tableau suivant récapitule pour la plupart des chipsets wifi gérés sous Linux, ou en passe de l’être, l’état du portage vers Devicescape/mac80211, ainsi que les fonctionnalités disponibles du pilote actuel et disponibles/en cours sous la nouvelle pile mac80211. Certains d’entre eux sont des projets séparés de la branche wireless de John Linville. Les matériels ne fonctionnant que via un pilote NDIS Windows, sans pilote Linux disponible, ne sont pas mentionnés. Il est bien sûr impossible d’être exhaustif, et il faut noter que la gestion des matériels USB est en général un peu à la traîne par rapport à ceux de type PCI ou Cardbus.

Les informations présentées sont amenées à évoluer assez rapidement en ce qui concerne les fonctionnalités des pilotes mac80211. En attendant que le noyau officiel inclue ces nouveaux drivers, vous pouvez tester l’avancement du projet en utilisant la branche noyau de John Linville, mainteneur officiel du Wifi sous Linux ; elle se récupère via un simple $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git. Vous récupérez ainsi un noyau complet, qui ne demande qu’à être compilé. Quant aux Fedoristes ayant fait l’installation ou l’upgrade vers FC7, ils ont l’honneur de pouvoir tester directement le fonctionnement de leur matériel sous Devicescape/mac80211.

Le réseau

La liste des évolutions dans le domaine du réseau n’est pas terminée. Notamment, deux nouveaux algorithmes de gestion de congestion TCP font leur apparition : TCP Illinois et Yeah TCP. La congestion est ce nom donné au phénomène qui se produit quand plusieurs communications réseau sur un même lien en arrivent à dépasser la capacité en débit de ce lien : les paquets ne peuvent donc plus passer tous en même temps ; ils sont alors mis en queue, et, si cette queue s’avère être pleine, ils sont tout simplement ignorés. L’émetteur ne reçoit alors pas l’ACK (accusé de réception du lot de paquets). Le nombre maximal de paquets que l’on peut envoyer sans retour ACK est appelé « la fenêtre TCP ». S’il est atteint, cela signifie qu’il y a congestion : quelque chose peine à recevoir ou faire suivre les paquets. Le comportement du protocole est alors de réduire cette fenêtre afin de transmettre moins de paquets d’un coup avant d’exiger un accusé de réception. À l’inverse, lorsqu’il n’y a pas d’erreur depuis un certain temps, la taille de la fenêtre est augmentée progressivement, ce qui se traduit par une augmentation du débit de transfert. Les constatations ayant abouti aux deux algorithmes faisant leur entrée dans cette version du noyau sont que l’augmentation de cette taille de fenêtre est trop longue et trop prudente sur les liens à grand capacité (100 MB, gigabit). Ils utilisent chacun une approche différente afin d’être plus agressifs.
Enfin, l’ancien module Netfilter de suivi de connexion, ip_conntrack, est retiré comme prévu au profit du nouveau module nf_conntrack générique à IPv4 et IPv6.

Les systèmes de fichiers

Cette fois-ci, le plus chouchouté est le discret AFS (Andrew FileSystem), ce qui nous donne l’occasion d’en faire une brève description. Il fait peu parler de lui chez le commun des mortels, mais est prisé de certains milieux professionnels ; « It’s like NFS on steroids », nous informe la documentation Gentoo. C’est un système de fichiers partagé, ce qui le rapproche de NFS ; les deux sont des surcouches à un système de fichiers physique. Il est en outre distribué : différents filesystems physiques sur plusieurs nœuds du réseau (appelés « cellules ») peuvent être « agglutinés » en un seul système de fichier global. Développé à l’origine par IBM et l’université de Carnegie Mellon, il dispose de clients sous plate-forme Unix, mais aussi Windows et Mac OSX. Outre cette vision unifiée d’un ensemble d’espaces de stockages locaux ou distants, il offre une très bonne gestion des permissions d’accès (ACL), ainsi qu’une authentification basée sur Kerberos, un système de cache local (un fichier déjà consulté une fois est copié localement afin d’offrir d’excellentes performances lors des prochains accès), une migration des données à chaud (les contenus peuvent être déplacés d’un nœud serveur à un autre sans aucune reconfiguration ni perturbation des accès du côté client). Bluffant ? Certes, mais ce n’est pas encore fini. La gestion de la redondance est également transparente pour l’utilisateur : les données peuvent être répliquées sur plusieurs cellules, et au cas où l’une d’entre elles deviendrait indisponible, le basculement sur une autre serait automatique.
Alors, pourquoi NFS n’est-il pas mort étouffé sous ce concurrent de poids ? Il faut avouer que le noyau Linux n’implémente que la partie cliente, limitée jusqu’à maintenant à la lecture seule et sans gestion des ACL. Il faut en outre installer des utilitaires clients, un démon en espace utilisateur pour la partie serveur, et il ne suffit pas de remplir un /etc/exports pour la configurer :-). Ce FS souffre également d’un déficit de publicité et d’un manque de soutien commercial au profit de NFS. Ce qui fait apparition dans le noyau 2.6.22 est un support marqué expérimental de l’écriture de fichiers, de la création de répertoires, de la gestion de l’authentification et l’implémentation de la fonction statfs()(statistiques variées sur un point de montage). Pour plus de détails, je ne peux que vous conseiller le site du projet officiel : http://www.openafs.org/ et la FAQ disponible sur http://www.angelfire.com/hi/plutonic/afs-faq.html. Pour les curieux, désireux de monter un serveur AFS, une documentation basique et simple est disponible sur http://www.gentoo.org/doc/en/openafs.xml.
FUSE profite, quant à lui, du support par le noyau des sous-types de FS. Au final, Linux accepte des entrées telles que fuse.zfs, fuse.ftpfs dans /etc/fstab et sera capable d’afficher le sous-type dans /proc/mounts par exemple. Cette mesure est essentiellement d’ordre pratique, car le noyau n’a pas besoin d’avoir connaissance du sous-système de fichiers ou du protocole employé, qui est géré en espace utilisateur. Signalons également :

• Après NFS depuis Linux 2.6.21, c’est au tour de CIFS de gérer IPv6. Il est également possible de forcer l’utilisation des extensions Unix CIFS sur un montage dont les UID/GID des propriétaires ne correspondent pas à des valeurs existantes sur le système client.
• UDF supporte les fichiers de plus de 1 Go.
• NFS peut utiliser un nouveau gestionnaire de procédures distantes, Rpcbind, amené à remplacer Portmapper, ce qui permet un meilleur support d’IPv6 et des fonctionnalités utiles notamment à NFSv4.
• Les médias de stockage de type Flash/MTD disposent maintenant d’une infrastructure nommée UBI assurant la gestion de volumes, les créations/suppressions/redimensionnages de partitions à chaud. UBI remplit le même rôle que LVM, mais les spécificités des mémoires Flash ne permettent pas de mutualiser le code. Pour résumer grossièrement, les périphériques dits « de type NAND » (les plus répandus) ne peuvent être accédés que séquentiellement, c’est-à-dire qu’il est impossible, au contraire d’un disque dur, de lire directement la valeur située à telle ou telle adresse. Il faut au minimum charger une page entière en RAM et la parcourir ensuite. Ils ne répondent pas vraiment à un des deux types de périphériques existant sous Unix (bloc ou caractère). De plus, le nombre d’écritures sur un bloc donné est limité. Il faut une logique pour détecter que des blocs deviennent défectueux et un pool de blocs libres réservés pour accueillir leurs données une fois qu’ils sont marqués « sinistrés pour de bon ». UBI se charge de cette tâche et soulage ainsi le système de fichiers (JFFS2 en général) de cette tâche. À noter que les cartes de type CompactFlash ou les clefs USB ne sont concernées ni par UBI, ni par JFFS2, car elles contiennent une couche matérielle de transition flash<-->périphérique bloc.

[Actualité] Le noyau 2.6.22

La gestion de la mémoire

Le SLUB allocator

Sous Linux, le buddy allocator (portant le nom de l’algorithme) est l’allocateur de plus bas niveau traitant directement avec l’allocation de pages physiques. Les sous-systèmes du noyau, les pilotes de périphériques, etc. n’appellent pas directement cet allocateur lorsqu’ils ont besoin de mémoire, mais passent par un allocateur de plus haut niveau, le slab allocator (implémenté pour la première fois dans Solaris 2.4). Il se charge de leurs requêtes, souvent au travers de la primitive kmalloc(). Cet allocateur gère des caches d’objets de taille spécifique (les descripteurs de processus, etc.), afin que leur allocation s’effectue rapidement et, cela, en minimisant la consommation mémoire. Aussi, le cache matériel est considéré avec attention dans les fonctions d’allocation. Ainsi, lors de leur exécution, le cache est conservé le plus possible dans son état original (on dit que l’empreinte – sur le cache – de la fonction est minimale).
Le bon fonctionnement de cet allocateur est d’une importance capitale quant aux performances globales du système. Malgré ses performances reconnues, il est des situations souffrant des caractéristiques de cet allocateur. C’est ce que Christoph Lameter explique en considérant la machine qu’il utilise dans son entreprise SGI : un calculateur d’un millier de nœuds/processeurs. Dans cette situation, le slab allocator actuel (SLAB) consomme énormément de mémoire juste pour stocker les références des objets dans ses nombreuses listes utilisées (il paraîtrait qu’il s’agisse de plusieurs gigaoctets de mémoire). Le passage à l’échelle pour ce genre de système semble donc problématique. C’est pourquoi Christoph Lameter a proposé un nouveau slab allocator nommé « SLUB » réglant le problème décrit et apportant de nombreuses améliorations que nous allons passer rapidement en revue.
Le code de SLAB a été énormément allégé (de trois quarts) et simplifié, notamment en éliminant l’utilisation des différentes files d’objets. L’utilisation des lignes du cache matériel s’en trouve ainsi minimisée.
SLAB stocke les métadonnées (le descripteur) d’un slab au début de celui-ci. Il empêche ainsi un alignement naturel au début d’un slab, gaspillant de la mémoire. SLUB stocke ces métadonnées directement dans les descripteurs des pages physiques contenant les slabs (les struct page se voient modifiées par l’ajout d’union – afin de ne pas modifier la taille prise par ces structures). Ainsi, l’utilisation de la mémoire est minimisée.
SLUB traite de façon simple la gestion des systèmes NUMA (Non Uniform Memory Access). Alors que SLAB dispose pour chaque cache (d’objets) créé, une liste de slabs partiels par nœud, SLUB utilise un pool global de slabs partiels. Cela entraîne une diminution de la fragmentation par rapport à SLAB. En effet, les listes de slabs partiels de SLAB ne peuvent être réutilisées que si l’allocateur s’exécute sur les nœuds appropriés.
SLUB propose une fonctionnalité très intéressante de fusion des caches de slabs. Celle-ci répond à la présence de nombreux caches de slabs ayant des paramètres voisins. Ainsi, SLUB détecte ces cas et fusionne ces caches dans des caches généraux. Christoph Lameter annonce une diminution d’environ 50% de tous les caches. Cela implique également une diminution de la fragmentation de la mémoire, car les slabs partiels ont ainsi tendance à se remplir plus.
SLUB dispose d’outils de diagnostic évolués et ne nécessitant pas une recompilation du noyau ni un redémarrage de la machine. En fait, le code de débogage est toujours présent en mémoire, mais il est laissé en dehors des chemins critiques du code. Ce diagnostic peut s’effectuer seulement sur un cache de slabs ou encore un groupe de caches de slabs, c’est-à-dire en conservant les performances courantes du système, rendant plus probable la reproduction de race conditions notamment.
Parmi ces outils de débogage, notons la possibilité de tracer l’utilisation d’un cache de slabs (c’est-à-dire les actions s’y appliquant) et de dumper le contenu des objets lors de leur libération.
SLUB dispose également d’une « option » de sûreté de fonctionnement lui permettant (si elle est activée) de détecter les conditions d’erreurs classiques et de se rétablir du mieux possible afin que le système continue de s’exécuter correctement.
Finalement, notons que les différents benchmarks utilisés (notamment Kernbench) attestent d’un gain de rapidité de 5 à 10% par rapport à SLAB. Christoph Lameter annonce également que ces performances peuvent encore être accrues, notamment avec l’utilisation du patch d’anti-fragmentation de la mémoire.

Les quicklists

Les quicklists sont de nouvelles listes créées par CPU, afin de conserver en mémoire des pages de tables de pages (PGD, PUD, PMD, PT) ayant un état spécifique lors de leur allocation ou de leur libération. Elles fournissent un gain de rapidité très significatif lors de l’allocation de telles pages et diminuent l’utilisation des lignes du cache matériel.
Les quicklists s’accommodent parfaitement des systèmes NUMA. Elles se fondent sur le fait que les accès aux pages de tables de pages sont par nature éparpillés. La récupération d’une page dans ces listes diminue l’utilisation des lignes du cache tout en s’affranchissant de la surcharge créée par le slab allocator. Cela est particulièrement utile pour les PGD qui contiennent le plus souvent les mappings standards. Il n’est nul besoin dans ces conditions de réinitialiser les pages. Ainsi, récupérer une page de tables de pages dans une quicklist nécessite l’utilisation de seulement 2 lignes de cache dans le chemin de code le plus rapide. Cela est à comparer aux 32 lignes touchées (en supposant des lignes de 128 octets) dans les versions antérieures de Linux qui effacent complètement la page en passant par le page/buddy allocator.
Pour finir, plusieurs architectures implémentent des quicklists à leur niveau. Avec ce patch, ces mécanismes sont transférés dans le cœur du gestionnaire générique des quicklists, facilitant ainsi la maintenance et la cohérence du fonctionnement des quicklists.

La gestion du temps

Une nouvelle fonctionnalité, dans la continuité de dyntick (cf. Kernel Corner 94), évite les déclenchements d’interruptions inutiles du timer lorsque la CPU est oisive (idle). Ainsi, lorsqu’une routine appelée par un timer peut attendre jusqu’au prochain évènement sans problème, l’utilisation des nouveaux deferable timer (c’est-à-dire un timer qui peut être différé) est préconisée. Ces timers ne sont pas sélectionnés lorsque la CPU recherche le prochain timer (via la primitive __next_timer_interrupt()) pour lequel elle doit se réveiller. Ainsi, un timer qui peut être différé n’est exécuté que lorsqu’un timer qui ne peut être différé l’est. Cela réduit ainsi la consommation d’énergie de la CPU, en lui permettant de rester plus longtemps dans ses états oisifs.
Notons la primitive employée pour initialiser un tel timer : init_timer_deferrable(). Elle dispose du même prototype que la classique init_timer().

La notification des évènements

Trois nouveaux appels système sont implémentés : signalfd(), timerfd(), eventfd(). Ils proposent la livraison d’évènements au travers de descripteurs de fichiers. Pour les deux premiers, nous pouvons employer les appels système standards sur les descripteurs renvoyés par ces fonctions : read(), select(), poll, epoll(). Pour le dernier, l’appel système, write() est également disponible.
Avant de voir le fonctionnement de ces trois appels système, attardons-nous sur un détail ;) Un fichier est normalement lié à un inode, sauf que, dans le cas présent, il n’est nul besoin d’inode. Ainsi, un premier patch implémente une source d’inodes anonymes. Un inode anonyme est une sorte de coquille vide créée uniquement dans le but de pouvoir créer un fichier (une struct file nécessite un inode). Ainsi, cette source d’inode est employée dans les trois mécanismes cités que nous allons maintenant présenter.

L’appel système signalfd()

int signalfd(int ufd, const sigset_t *mask, size_t masksize);

Cet appel système met en place une livraison de signaux via l’utilisation d’un descripteur de fichier. Le processus appelant va ainsi, par exemple, se mettre en attente sur le descripteur renvoyé afin de recevoir les signaux qu’il souhaite traiter (paramètre mask).
La récupération des signaux se fait depuis la même file que celle employée par le processus. Ainsi, les deux mécanismes sont en concurrence. Afin de rendre sûre la livraison des signaux par signalfd, il est nécessaire de les bloquer dans le mécanisme classique via sigprocmask(SIG_BLOCK).
Notons que ufd doit être positionné à -1 pour déclencher la création d’un nouveau descripteur de fichier, sinon le descripteur de fichier passé est « re-programmé » (sans avoir à passer par un cycle de fermeture/libération).
Pour finir, montrons le type de structure renvoyée suite à la réception d’un signal après lecture sur le descripteur de fichier (celui retourné par signalfd) :

struct signalfd_siginfo {
__u32 signo; /* si_signo */
__s32 err; /* si_errno */
__s32 code; /* si_code */
__u32 pid; /* si_pid */
__u32 uid; /* si_uid */
__s32 fd; /* si_fd */
__u32 tid; /* si_fd */
__u32 band; /* si_band */
__u32 overrun; /* si_overrun */
__u32 trapno; /* si_trapno */
__s32 status; /* si_status */
__s32 svint; /* si_int */
__u64 svptr; /* si_ptr */
__u64 utime; /* si_utime */
__u64 stime; /* si_stime */
__u64 addr; /* si_addr */
};

L’appel système timerfd()

int timerfd(int ufd, int clockid, int flags, const struct itimerspec *utmr);

Cet appel système permet la livraison d’évènements provenant de timers au travers d’un descripteur de fichier (comme précédemment).
Le paramètre clockid renseigne sur le type de l’horloge que le timer doit employer (CLOCK_MONOTONIC ou CLOCK_REALTIME). Le paramètre utmr->it_value contient l’échéance du timer et le paramètre utmr->it_interval correspond à la période séparant la génération des ticks. Par défaut, les valeurs sont fournies en temps relatif, sinon il faut positionner le paramètre flags à TFD_TIMER_ABSTIME pour travailler en temps absolu. Le paramètre ufd est analogue à celui de signalfd.
La valeur retournée lors d’une lecture sur le descripteur de fichier renvoyé par l’appel système correspond au nombre de ticks générés depuis la dernière lecture.

L’appel système eventfd()

    int eventfd(unsigned int count);

Cet appel système crée un descripteur de fichier comme un moyen permettant de dispatcher des évènements en espace noyau et utilisateur ou encore d’en attendre pour l’espace utilisateur. Lorsqu’il s’agit de notifier la survenance d’un évènement (la terminaison d’une écriture par exemple), l’utilisation de ce mécanisme est préférable à l’appel système pipe(), car il ne crée qu’un seul descripteur de fichier « léger » (les descripteurs anonymes dont nous avons parlé).
Si ce mécanisme est employé depuis le noyau, il peut servir de passerelle faisant transiter via un descripteur de fichier la notification de terminaisons d’opérations diverses (que nous pouvons trouver par exemple dans les KAIO – Kernel Asynchronous Input Output – ou encore les syslets/threadlets – non encore inclus dans la mainline, cf. le Kernel Corner 93 à ce sujet). De manière générale, il sert de moyen de notification conforme aux attentes POSIX, c’est-à-dire via l’utilisation de poll()/select().

eventfd() prend en paramètre un « compteur ». Lors de l’utilisation de poll() sur le descripteur créé, la fonction retourne POLLIN lorsque le compteur interne est supérieur à zéro, retourne POLLOUT s’il est possible d’écrire au moins la valeur 1 à ce compteur ou, sinon, renvoie, POLLERR si un dépassement de capacité (overflow) du compteur est détecté.

La lecture via l’appel système read() sur ce descripteur entraîne la réinitialisation du compteur interne à la valeur 0, alors que l’écriture via write() ajoute au compteur la valeur passée en paramètre. Un write() ne peut jamais entraîner un dépassement de capacité du compteur interne, car il est bloquant ou sinon l’appel système renverra l’erreur -EAGAIN.
Le noyau pour notifier un évènement à l’espace utilisateur va employer la primitive eventfd_signal() qui ajoute la valeur passée en paramètre au compteur interne associé à un certain descripteur. Contrairement à l’utilisation de write() depuis l’espace utilisateur, elle peut provoquer un dépassement de capacité du compteur interne, car cette primitive n’est pas censée « dormir » durant son exécution. Notons qu’elle peut ainsi être appelée depuis n’importe quel contexte.

La virtualisation

KVM et digressions

L’activité autour de KVM est toujours débordante (cf. Kernel Corner 90 pour un bref développement sur KVM). C’est déjà la révision 22 du projet qui est incluse au noyau. Au programme des réjouissances, notons l’augmentation du nombre de systèmes invités supportés (dernièrement Windows Vista 32 bits), une amélioration des performances, la correction de divers bugs (notamment depuis la révision 22, celle d’un bug de longue date qui doublait la « vitesse » du déroulement du temps sur x86_64 !) et l’amélioration, seulement, de l’interface utilisateur...
Bien que la stabilisation de cette API avec la version 2.6.22 du noyau était planifiée, elle a du être remise à la version suivante. Encore une fois, Linus Torvalds a tiré la sonnette d’alarme en spécifiant énergiquement à Avi Kivity (leader du projet) qu’il ne serait pas permis de patchs autres que des corrections de « bug » après la diffusion de la -rc1. Voici la réponse de Linus au mail d’Avi qui témoigne de la rigueur appliquée au bon déroulement du cycle de développement du noyau :

On Fri, 1 Jun 2007, Avi Kivity wrote:
>
> Please pull from the repository and branch
No. Not after -rc1. Not for something that changes core code
and isn’t a core feature, and wasn’t a regression.

> The core issue is that we need a notification [...]

No. The core issue here is that people need to understand that if you miss the merge window, and it’s new development, YOU DAMN WELL WAIT FOR THE NEXT ONE.

Don’t send me pull requests like this. And absolutely do NOT send them as resends. I just  get grumpy.

If all the added code had been KVM-only, I might not care. But when the bulk of the code touches core files, you had better explain why this is so important that it cannot wait for the next merge window.

                        Linus

La parole importante de Linus à retenir (pour les non anglophones ;) est qu’il n’est pas envisageable, à un stade du cycle de développement post -rc1, d’intégrer du code touchant à des fichiers majeurs du noyau et non juste du code spécifique à KVM (ou tout autre sous-système), sans expliquer pourquoi cela ne pourrait pas attendre la prochaine fenêtre de tir.

Paravirtualisation

Au niveau de la paravirtualisation, beaucoup de travail a également été fourni. Mis à part l’ajout d’une nouvelle option de boot (noreplace-paravirt) empêchant la mise à jour des méthodes bas niveau dans paravirt_ops (la mécanique générique de patching dynamique des méthodes en mémoire a d’ailleurs été implémentée), de nombreux changements dans ces méthodes ont été effectués. Aussi, un fait important, paravirt_ops n’est plus à présent une variable exportable uniquement à du code GPL.
Notons que les modifications apportées à paravirt_ops sont notamment effectuées pour faciliter l’inclusion de Xen. Comme exemple de modifications, citons l’ajout d’un nouveau hook pour la configuration des tables de pages initiales du noyau. Il s’agit ici de laisser le choix à l’hyperviseur sur l’environnement de pagination qu’il souhaite employer pour ses systèmes invités. Xen emploie une configuration de pagination incompatible avec celle du noyau Linux. Ainsi, ce hook et les modifications qu’il entraîne au sein des fonctions d’initialisation du noyau, s’avèrent, entre autres, nécessaires au support de Xen.
Nous ne détaillons pas plus les modifications apportées à ce niveau, tant elles sont nombreuses. Nous renvoyons le lecteur aguerri aux patchs respectifs accessibles facilement depuis l’interface gitweb du noyau. Il vous suffit pour cela de vous rendre à cette adresse : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary, et de taper ensuite dans la zone de recherche le terme « paravirt ». Vous venez de visiter la caverne d’Ali Baba^W^Wdu noyau ;)

Les spécificités des architectures

Le nombre d’architectures supportées s’étend à nouveau, avec l’apparition de la gestion de la famille de CPU Blackfin, développés conjointement par Analog Devices et Intel. Destinée au monde de l’embarqué, leur architecture est de type RISC 32 bits disposant d’instructions orientées multimédias. L’hibernation ou suspend-to-disk, ainsi que le Hotplug CPU, fonctionnent désormais pour les G5. Dynticks, apparu dans Linux 2.6.21 (cf. KC 94), est disponible sur les architectures ARM. Pour rappel, son but est la suppression des interruptions d’horloge sous certaines conditions, ce qui économise l’utilisation du processeur : on y gagne en consommation d’énergie et en chaleur dissipée.

L’infrastructure Firewire

Gros changement dans le monde des périphériques firewire, puisqu’ils se voient désormais confiés à une toute nouvelle infrastructure chargée de leur gestion. Complètement réécrite, elle se veut plus simple et plus légère en termes de code (8000 contre 30000 pour l’implémentation qui était en vigueur jusqu’à maintenant), et moins gourmande en ressources : abandon de l’utilisation des threads noyau, une programmation simplifiée pour les transferts zero-copy, création d’une entrée par périphérique connecté afin de permettre une gestion des permissions d’accès plus souple sur les matériels. Pour l’instant, seule la gestion des périphériques de stockage (protocole SBP2) est disponible sous cette nouvelle implémentation ; l’ancienne et la nouvelle cohabiteront donc le temps que le reste (gestion des périphériques vidéo, réseau) soit porté. Pour la tester avec votre disque dur externe, il vous faut activer les options CONFIG_FIREWIRE, CONFIG_FIREWIRE_OHCI et CONFIG_FIREWIRE_SBP2 qui produiront les modules fw-core, fw-ohci et fw-sbp2. L’ancien sous-système devra être désactivé s’il est compilé « en dur » ou sinon les anciens modules déchargés (ieee1394, ohci1394 et sbp2).

Les pilotes de périphériques

Voici les principales évolutions amenées par notre noyau 2.6.22 :

• Apparition d’un pilote pour les cartes d’acquisition vidéo basées sur les puces cx23416 et cx23415 (matériels Hauppauge), activable via l’option CONFIG_VIDEO_IVTV. Elle s’appuie sur V4L2.
• La gestion des « clefs » wifi USB Marvell 8388 (option CONFIG_LIBERTAS_USB). Le chipset 8388 est celui utilisé dans le projet OLPC « un ordinateur pour 100$ ».
• Inclusion du pilote pour les webcams basées sur les puces Zoran zr364xx, rencontrées dans de très nombreux matériels comme les Creative PcCam880, Aiptec Fidelity3200, Maxell Maxcam PRO DV3... (option CONFIG_USB_ZR364XX). Il utilise V4L2.
• Le support de SMC sur les MacBook Pro et Mac mini Intel. Permet la lecture de la température et de l’accéléromètre, le contrôle du ventilateur et du rétroéclairage (option CONFIG_SENSORS_APPLESMC).
• La gamme de matériels Wifi à puces Zydas gérée par le pilote zd1211rw (apparu dans Linux 2.6.18) s’agrandit.
• Les contrôleurs SATA Marvell 7042 sont maintenant reconnus et utilisables sous Linux par le module sata_mv déjà existant. Les contrôleurs CMD640 sont utilisables via le sous-système PATA.
• Les sondes de température des processeurs Intel Core, ainsi que les sondes I2C Simtec sont gérées.

Divers

Il est possible de se faire une idée de la mémoire consommée par un processus, grâce à l’ajout d’une ligne Pgs_Referenced dans /proc/<pid>/smaps, qui indique combien de pages sont utilisées ou accédées pour chaque région de mémoire virtuelle (VMA) qu’il utilise. Ces VMA sont des portions de mémoire contiguës représentant les différents segments du binaire associé au processus (.text, .data, .bss, le heap, les bibliothèques mappées suite à l’appel de mmap(), etc.). Selon l’exemple donné par l’auteur des patchs, l’évolution de la consommation mémoire d’un processus pourra donc être suivie en effectuant un echo 1 > /proc/<pid>/clear_refs, puis en additionnant les valeurs Pgs_Referenced de chaque VMA, le tout à intervalles réguliers.
Suite à un coup de gueule de Linus Torvalds, le code gérant le suspend-to-RAM et le suspend-to-disk a été séparé en deux parties. Les deux procédés étant bien différents, Linus a jugé que c’était une aberration de chercher à factoriser leur code et que c’était une cause de leur fonctionnement problématique.
Des améliorations inspirées du nouvel ordonnanceur de tâches d’Ingo Molnar (CFS) ont été apportées à l’ordonnanceur d’entrées/sorties (abandon des listes doublement chaînées pour une structure en red-black tree).
Signalons à toutes fins utiles que les changements dans l’organisation de sysfs pour les circuits i2c peuvent perturber vos utilitaires lm_sensors, s’ils ne sont pas au moins en version 2.10.3 (coucou Etch !).