Peu avant la sortie du 2.6.24 les divers mainteneurs des sous-systèmes ont indiqués sur la liste de diffusion du noyau leursintentions sur lespatchs suffisamment stables pour pouvoir migrer de la branche de test d'Andrew Morton (la -mm) vers la branche de Linus. La période d'intégration de ces milliers de patchs doit durer deux semaines et elle permet l'ajout de toutes les nouveautés prévues dans le nouveau noyau.
Cette fois-ci le démarrage a été rendu un peu plus lent car la plupart des développeurs participaient à laconférence Linux en Australie à la fin du mois de janvier. Une fois la fenêtre d'intégration d'environ quinze jours refermée la saga des "releases candidates" a pu commencer.Les versions candidates
- La versionRC-1 est donc apparue juste dix-sept jours après la sortie du noyau stable précédent. Linus s'est amusé dans son annonce à faire quelques statistiques sur le nombre de changements:
"C'est une RC sacrément grosse (comme le fut la RC1 du noyau précédent) probablement parce que le cycle de sortie du 2.6.24 a été plus long que prévu et que les gens avaient pleins de choses en attente. Le diff est d'environ 11 Mo et représente 1,4 millions de lignes, avec la majorité concernant les pilotes et les mises à jour d'architectures.
Juste pour le fun j'ai fait quelques statistiques triviales et, sur les 1,4 millions de lignes, 38% (soit 530.000) concernent les diverses architectures et 44% (soit 610.000) concernent les pilotes. Le reste est bien plus petit mais on peut noter le réseau (8% pour 110.000 lignes), les systèmes de fichiers (4%) et la documentation pour environ 2%." - Pour laRC-2 Linus nous a sorti un de ses mails "spéciaux" et je ne résiste pas à la tentation de le citer largement:
"OK ce noyau est un "winner". Juste pour vous montrer à quel point c'est un "winner", il lui a été décerné un très convoité nom de série basé sur "belette", ce qui vous indique la qualité que va avoir ce noyau. C'est un nom révéré dans l'histoire du noyau Linux et, en tant que tel, il ramène aux bons vieux jours ou si vous trouviez un bug c'était presque certainement une erreur due au fait que vous aviez fait quelque chose de travers.
Mais bon, vous pouvez essayer de me prouver que j'ai tort si vous l'osez.
Pour avoir une vue des diff on peut utiliser la fonction git "dirstat" qui donne un bon aperçu général. En particulier cela montre que presque la moitié des mises à jours concernent les pilotes, avec les pilotes réseau représentant un tiers du patch global.
C'est vraiment une super fonctionnalité de git. Cela me permet de gagner une heure par semaine à rester avachi en sirotant une boisson tropicale (ce qui porte mon total hebdomadaire de stupeur alcoolique à environ 168,5 heures) puisque je n'ai plus à faire manuellement le travail des statistiques de diff.
Enfin bon voilà le résultat :
2.1% Documentation/
3.7% arch/cris/
7.0% arch/sh/configs/
4.4% arch/sh/kernel/
4.9% arch/sh/mm/
17.8% arch/sh/
23.8% arch/
33.5% drivers/net/
6.0% drivers/scsi/lpfc/
7.1% drivers/scsi/
4.5% drivers/sh/maple/
49.5% drivers/
8.1% fs/
2.5% include/linux/
4.5% include/
7.2% kernel/
2.0% net/
509 files changed, 14470 insertions(+), 6986 deletions(-)
Vous devez admettre que cela fait très manager, même si vous n'avez absolument aucune foutue idée de ce dont il est question (ce qui fait également très manager). Maintenant il ne me reste plus qu'à transformer tout ceci en quelques camemberts dans une présentation Powerpoint bien colorée et alors je pourrai _vraiment_ éteindre mon cerveau.
J'ai confiance dans le fait que ce cycle noyau ne sera pas aussi douloureux que le précédent et c'est pour ça que je vais profiter de ce long week-end et rester sur la plage. Soyez gentils pendant que je sirote mon Mai Tai. Celui avec un parasol.
Linus
PS : En Oregon nous n'utilisons pas ces mignons petits parasols en papier. Nous on a les bons gros parasols pour être sûr et certain que nos boissons ne sont pas trop délayées par de l'eau. Ah les plages de l'Oregon en février ! - Linus a eu raison et les releases candidates suivantes sont apparues à l'heure dite sans problèmes particuliers. Entre le 24 février et le 9 mars lesRC-3,RC-4 etRC-5 ont été annoncées avec à chaque fois la visualisation "managériale" générée par Git que Linus semble apprécier particulièrement.
- LaRC-6 a été un peu plus longue: "Bon j'ai perdu un jour et demi cette semaine à cause d'un de mes disques qui a décidé d'avoir des erreurs de lecture à la suite d'une malencontreuse coupure de courant. J'ai dû passer pas mal de temps à reconstruire mon environnement normal mais je ne pense pas avoir perdu le moindre mail."
- Le 25 mars Linus a annoncé la sortie de laRC-7 et a demandé un dernier effort sur les tests pour que le noyau 2.6.25 définitif soit vraiment bien stable.
Le premier avril a été annoncée laRC-8 qui devait être la dernière version candidate avant que Linus n'annonce le 11 avril la sortie d'uneRC-9:
"Je n'ai vraiment pas envie de faire ça et j'avais en fait l'espoir de fournir le noyau 2.6.25 le week-end dernier (ce qui explique pourquoi la RC-9 a quelques jours de retard - c'est parce que j'espérais ne pas avoir à la sortir du tout) mais j'ai été obligé de sortir une RC-9. La raison de ce retard du 2.6.25, c'est que certaines personnes se sont inquiétés à propos de l'allocateur mémoire SLAB. Je voulais sortir quelque chose cette semaine mais je ne me sentais pas confiant au point de faire une version finale.
Cela dit, je pense que, quoi qu'il en soit, je vais sortir le 2.6.25 au début de la semaine prochaine parce que nous ne pouvons tout simplement pas retenir éternellement les choses. À un moment donné cela devra devenir une question relevant des versions 2.6.25.X et les développeurs ayant du code de prévu pour la prochaine version pourront commencer à l'envoyer.
Linus
PS. La dernière semaine a été un peu frustrante. Donc, si je me suis comporté de façon encore moins polie que d'habitude en public ou dans des e-mails privés, je vous fait mes excuses. Les intéressés se reconnaîtront.
Les nouveautés
- Le moduleSMACK (Simplified Mandatory Access Control Kernel) a été ajouté au noyau 2.6.25 afin d'offrir une alternative simplifiée àSELinux.
Ces deux modules de sécurité utilisent l'infrastructureLSM afin de permettre des restrictions d'accès très spéciales pour améliorer la résistance aux attaques et définir des politiques de sécurité lors de l'utilisation. Traditionnellement les systèmes de type Unix se basent sur des architecturesDAC (Discretionary access control) c'est à dire que les actions sont autorisées en fonction de l'identité du demandeur ou du groupe auquel il appartient. Avec les architecturesMAC (Mandatory access control) on ne se base plus sur l'identité du demandeur mais sur des attributs étendus qui sont attachés aux différents objets du système (les fichiers, les répertoires, les ports...etc). SELinux est un module très puissant mais il est malheureusement assez complexe à configurer et à gérer au quotidien. En dépit des efforts méritoires de ses promoteurs pour simplifier son utilisation au fil du temps, il y a toujours eu un mécontentement chez une partie des utilisateurs. Ces derniers ont exercé une pression afin qu'une solution plus simple apparaisse et SMACK est le résultat de cette pression. Bien entendu la complexité de SELinux est inhérente à la définition d'une politique de sécurité complète et cohérente et SMACK paye sa simplicité par une moindre puissance et une moindre généralité. Techniquement SMACK fonctionne, comme SELinux, en écrivant des labels (des chaines ASCII) qui sont attachés aux différents objets du système. Il lit ensuite les règles d'accès qui sont présentes dans dans /smack/load et ont une syntaxe de typelabel-du sujet label-de-l'objet droit-d'accès.
SMACK restreint l'accès en fonction du label attaché au sujet et du label attaché à l'objet auquel le sujet essaye d'accéder. C'est cette syntaxe qui constitue la grande simplification par rapport à son concurrent SELinux (avec également la disparition de la possibilité ducontrôle d'accès à base de rôles). Seule la comparaison de règles est possible et il n'y a pas de caractère joker ou de gestion des expressions régulières. Cefichier pdf de Casey Schaufler, l'auteur de SMACK, explique plus en détail le fonctionnement de cette nouvelle architecture.
Les développeurs de SELinux, qui étaient jusqu'à présent les seuls utilisateurs de l'infrastructure LSM, ont opposé une âpre résistance à l'inclusion de SMACK dans le noyau. Selon eux il suffisait d'encapsuler SELinux dans une couche destinée à cacher sa complexité plutôt que d'ajouter une toute nouvelle infrastructure de sécurité. Lesdiscussions sur la liste de diffusion ont été chaudes et James Morris, l'un des développeurs de SElinux, a étéparticulièrement opiniâtre. Il a fallu que Linussiffle brutalement la fin de la récréation en décrétant que SMACK avait sa place dans le noyau et que l'infrastructure LSM resterait aussi: «Quand je verrai les spécialistes de la sécurité utiliser des arguments rationnels et se mettre d'accord sur un truc les choses changeront peut-être. Mais franchement je m'attends à ce que l'enfer gèle et que les cochons nichent dans les arbres avant que cela n'arrive. Mais bon, je peux toujours espérer. »
Toute cette controverse a fait l'objet d'unarticle détaillé du site Linux Weekly News. - Le mécanisme deRead-copy update a été significativement amélioré afin de pouvoir répondre aux exigences du temps réel. La technique RCU, introduite en 2002 dans le noyau, permet de synchroniser rapidement les accès à des données dans un environnement multiprocesseurs. Les processus légers vont par exemple pouvoir lire ces données sans poser de verrou spécial (un lock) ce qui est très intéressant en terme de charge processeur car un verrou est coûteux en ressources. Si un autre processus léger veut modifier les données alors une copie de ces données est faite et la modification s'effectue sur la copie. L'original, lui, ne sera effacé qu'au moment ou le dernier des processus lecteurs aura terminé son travail.
La technique Read-copy update avait néanmoins un désavantage significatif puisqu'il n'était pas possible d'avoir des garanties sur les latences introduites lors de la phase d'update. Le noyau 2.6.25 introduit doncla possibilité de "préempter" le RCU, c'est à dire qu'un processus prioritaire peut prendre la main et passer devant les autres ce qui n'était pas possible avec les implémentations RCU antérieures. Le code, écrit parPaul McKenney, a maturé un certain temps au sein de la branche -rt maintenue par Ingo Molnar et son introduction dans la branche principale permet de se rapprocher un peu plus d'une capacité complète à supporter le temps réel avec le noyau Linux. - Toujours dans le domaine dutemps réel plusieurs avancées sont apportées par le nouveau noyau 2.6.25. L'ordonnanceurCFS a été rendu plus agressif dans le déplacement des processus entre les coeurs de calcul. Maintenant, dans le cas d'une compétition entre des tâches temps réel pour accaparer un seul coeur, le noyau migrera plus efficacement certaines tâches vers les autres processeurs afin d'éviter les temps d'attente. D'autre part le verrou global du noyau (big kernel lock) est maintenant préemptible par défaut et l'option permettant de ne pas le rendre préemptible va sans doute disparaître. Les timers à haute résolution peuvent maintenant être utilisés pour calculer les priorités entre les processus ce qui rend l'ordonnanceur plus précis lors de ses allocations de temps. On peut également noter que la fonction d'ordonnancement de groupe, introduite dans le noyau précédent, gagne des fonctions de support du temps réel.
- Lamesure de la consommation mémoire des processus a été raffinée par l'introduction de plusieurs patchs de Matt Mackall. La situation jusqu'à présent était peu satisfaisante puisque le mécanisme de cache proposée par le noyau, très efficace, brouillait les statistiques sur la consommation mémoire réelle des applications.
Avec la nouvelle technique disponible dans le noyau 2.6.25 un fichier est créé (dans /proc/$PID/pagemaps) pour chaque processus en cours. Le fichier contient la localisation physique des pages mémoires de l'application ce qui permet de comparer avec les autres et de déduire les pages partagées en mémoire et les pages spécifiques utilisées par un seul processus. On obtient ainsi de nouvelles statistiques précises pour l'occupation mémoire. Le PSS (proportional set size) d'un processus est le nombre de pages qu'il utilise avec chaque page divisée par le nombre de processus la partageant. Par exemple un processus ayant 1000 pages uniques et 200 pages partagées avec 4 autres processus aura un PSS de 1040 (1000 + (200/5)). Une autre statistique est le USS (unique set size) qui compte uniquement les pages non partagées d'un processus. Ce sont en fait les pages mémoires qui redeviendront vraiment disponibles en cas de fermeture du processus. Matt Mackall travaille dans le domaine de l'embarqué où la mémoire est souvent une ressource rare et précieuse. Ses patchs vont certainement aider à mieux estimer la taille des applications et donc à permettre de prendre des décisions plus judicieuses sur les compromis à effectuer. - Lesystème de fichier Ext4 continue d'être amélioré afin de pouvoir, dans quelques mois, être activé par défaut dans toutes les distributions Linux. Dans la version incluse dans le noyau 2.6.25 on peut noter que la taille des blocs mémoires, qui était auparavant fixée à 4 Ko, est maintenant adaptable et peut atteindre 64 Ko au maximum. Des sommes de contrôle sont effectuées sur le journal du système de fichier afin d'augmenter la résistance aux corruptions de données. L'allocation des blocs pour les extends se fait maintenant par groupe de plusieurs blocs. Cette allocation multiple des blocs est très complexe et de nombreuses heuristiques sont utilisées afin d'optimiser au maximum les performances.Selon Thed Ts'o, qui dirige l'effort de développement d'Ext4, ces changements sont les derniers à impacter le format des systèmes de fichiers Ext4 sur les disques durs. Toute future modification sera sans conséquences sur le format ce qui est le signe que les choses commencent à se stabiliser et qu'Ext4 sera bientôt disponible pour tous.
- L'implémentation desverrous tournants a été revue. Jusqu'à présent ce système de "spinlock" permettait à un processus léger de tourner dans une boucle infinie en attendant patiemment que le verrou sur la ressource auquel il voulait accéder soit libéré. L'ennui avec ce mécanisme c'est qu'il n'est pas équitable. Expliquons pourquoi: Quand une ressource est libre elle a une valeur égale à 1 et ce nombre est décrémenté de 1 quand un processus pose un verrou sur elle en utilisant l'appel systèmespin_lock(). Si un nouveau processus arrive et veut utiliser la ressource il va faire sonspin_lock() et se rendre compte que le résultat n'est pas 0 (ce qui indiquerait une ressource disponible) mais -1. Il va donc se mettre dans une boucle et attendre la libération de la ressource. Plusieurs processus peuvent ainsi tourner en attendant la libération et il est facile de voir que plus la valeur sera négative et plus cela indique que la compétition est rude pour utiliser cette ressource. Quand enfin le tout premier processus libère la ressource (en repositionnant la valeur à 1) c'est le premier thread tournant à tester la valeur qui va réussir à poser son verrou. Ce petit chanceux passe ainsi devant tous les autres mêmes si ces derniers tournaient dans la boucle depuis plus longtemps que lui. Cet état de fait, outre qu'il choque notre sens inné de la justice, conduit à une forte réduction des performances (jusqu'àune multiplication par deux du temps d'exécution d'un thread).
Le noyau 2.6.25 introduit donc un mécanisme destiné à résoudre ce problème fondamental. Nick Piggin a proposé et implémenté la notion de "verrous tournants avec tickets" qui consiste à utiliser une valeur de 16 bits pour stocker l'ordre d'arrivée des processus et ainsi permettre de prioriser ceux qui sont en attente depuis plus longtemps que les autres (le même système que les tickets d'attente dans les guichets de l'administration). On utilise 8 bits pour le processus courant et 8 bits pour le processus suivant dans la file d'attente. Bien entendu une valeur stockée sur 8 bits limite à 255 le nombre de processus pouvant utiliser le nouveau mécanisme des "verrous tournants avec tickets". Pour les machines ayant plus de 255 coeurs de calcul une version spéciale du patchest disponible. Elle stocke la valeur sur 32 bits (soit 16 bits pour le processus courant et 16 bits pour le suivant) ce qui permet aux machines ayant moins de 65536 coeurs de calcul de profiter des "verrous tournants avec tickets". En cas de besoin futur cette valeur sera une nouvelle fois agrandie mais pour l'instant il y a de la marge. - Le support desbus de données de type CAN (Controller Area Network) a été ajouté au noyau 2.6.25. Ce format de transfert de données est utilisé dans l'industrie automobile et a été développé spécifiquement pour répondre à la problématique du temps réel embarqué dans un environnement perturbé electro-magnétiquement. Les données sont complètement protégées par des sommes de contrôle et le protocole est simplifié au maximum afin d'éviter les erreurs. Pour implémenter le bus CAN la première solution avait été de passer par le bus série traditionnel et de mettre les détails spécifiques au protocole en espace utilisateur. C'est la solution rapide et vilaine car elle ne permet pas de profiter de tous les avantages de la pile réseau Linux (mise en queue, maintien de la qualité de service, utilisation de l'API socket traditionnelle...etc) et elle oblige le développeur à coder toutes ces fonctions lui-même. La vraie solution est bien entendu d'implémenter ce format CAN de transfert de données au sein même du noyau et c'est à cette tâche que se sont attelés des ingénieurs de la société Volkswagen. Les patchs implémentant la nouvelle infrastructure PF_CAN ont été réécrits plusieurs fois car les développeurs noyau et les ingénieurs automobiles viennent de deux mondes différents et ont eu des difficultés à communiquer.
Jonathan Corbet a demandé à l'auteur principal de PF_CAN de résumer ses problèmes: "Plusieurs développeurs de CAN avaient l'habitude des micro-contrôleurs et avaient des difficultés à comprendre l'approche orientée réseaux. D'un autre côté les gens des réseaux ont souvent trouvé le design de PF_CAN étrange et difficile à comprendre (pas d'adresses, pas vraiment de couches) par rapport aux autres protocoles. En conséquence, cela nous a pris plus d'un an de discussion sur la liste de diffusionsocketcan avant de nous mettre d'accord sur l'architecture actuelle."
Naturellement, étant donné les cycles longs de l'industrie automobile, il va falloir attendre un certain temps avant de trouver du Linux+PF_CAN dans nos autos mais on ne peut que se féliciter de l'approche choisie par Volkswagen de collaborer avec le monde du libre au lieu de développer ses outils dans le secret et sous une licence propriétaire. - Les patchs permettant à l'outilLatencyTOP de fonctionner sont maintenant intégrés dans la branche principale du noyau Linux.Proposé par Arjan van de Ven en janvier, LatencyTOP est un programme en espace utilisateur qui mesure les temps de latence et des patchs noyau qui permettent d'annoter les diverses opérations du kernel pour pouvoir ensuite les compter. Ce sont ces patchs qui, après relectures, corrections et améliorations, font maintenant partie du noyau 2.6.25. Cet outil permet de présenter de façontrès simple les processus en les classant par ordre décroissant de temps de latence (en millisecondes). Comme son prédécesseurPowerTOP, le nouvel outil LatencyTOP a déjà permis de détecter plusieurs situations de latences anormales et de corriger des bugs gênants.
- Le noyau 2.6.25 permet de gérerl'utilisation de la mémoire dans des containers. Pour pouvoir exécuter des applications dans des boites virtuelles séparées, que l'on nomme "containers", la communauté Linux a choisi d'implémenter progressivement les diverses briques technologiques. Le noyau 2.6.25 apporte donc la capacité de gérer la quantité de mémoire qui est utilisée par chaque container en fixant des limites et en contrôlant l'usage de la mémoire par les applications qui s'exécutent dans le container. Bien entendu cette gestion s'effectue à l'aide de l'infrastructure générique "Control Group" qui a été introduite dans le noyau 2.6.24 (l'option est sélectionnable avec CONFIG_CGROUP_MEM_CONT). La syntaxe utilisée, bien expliquée dansla documentation fournie, est très simple puisque pour limiter à 400 Mo la mémoire utilisée par le groupe de contrôle 0 il suffit de faire un:
echo -n 400M > /cgroups/0/memory.limit_in_bytes
Avec cette gestion de la mémoire c'est une nouvelle partie de l'infrastructure globale des containers qui prend sa place dans le noyau. - Davide Libenzi, l'auteur du mécanisme de notification eventfd, aretravaillé l'API du l'appel système timerfd. Ce dernier avait été introduit dans le noyau 2.6.22 mais immédiatement désactivé dès le noyau suivant pour cause d'interfacemal conçue. En effet, lors del'écriture des pages man de cette interface, il est apparue que celle-ci pouvait poser des problèmes et qu'une désactivation/refonte était nécessaire. Cette désactivation visait à empêcher l'écriture de programmes se basant sur l'API fautive et de devoir ensuite vivre éternellement avec le nécessaire maintien de la compatibilité. Maintenant que l'API timerfd refondue est bien propre les utilisateurs sont de nouveau invités à utiliser sereinement timerfd. Selon Jonathan Corbet la morale de cette histoire est qu': «un des meilleurs moyens de trouver les problèmes d'une API consiste à tenter de la documenter complètement. Si la communauté du noyau Linux veut résoudre ce genre de choses à l'avenir elle ne devra plus accepter aucune nouvelle API sans une documentation complète. »
- Outre les nouveautés décrites ci-dessus, une multitude d'autres nouveautés sont présentes dans ce noyau.
- La régulation thermique proposée par la normeACPI 2.0 est dorénavant complètement implémentée dans le noyau 2.6.25. Cette interface permet de gérer, à l'aide de divers senseurs, des zones thermiques différentes au sein de la machine et de réguler finement leur température. Une documentationest disponible qui explique de façon détaillée toute cette machinerie complexe de la gestion des zones de températures par la norme ACPI.
- Le noyau 2.6.25 voit, pour la première fois, l'inclusion despilotes 2D pour les cartes AMD Radeon de type R500.
- La mise en veille ou en hibernation des systèmes ayant une carte Intel i915 fonctionne désormais correctement.
- De nombreux pilotesOSS de cartes son (comme par exemple i810_audio ou via82cxxx_audio) ont été supprimés du noyau car ils ont été remplacés par des pilotes utilisant l'architectureALSA.
- L'algorithme dechiffrement de flux proposé par Daniel J. Bernstein,Salsa20, est ajouté à la pile cryptographique du noyau. On note égalementl'inclusion de l'algorithme de compression de donnéesLZO qui est conçu pour être particulièrement rapide lors de l'opération de décompression.
- Le protocole réseauISATAP est maintenantintégré dans le noyau 2.6.25. ISATAP est un mécanisme de transition permettant de faciliter le passage àIPv6. Contrairement à6over4 il ne nécessite pas que le réseau IPv4 sous-jacent supporte lemulticast.
- Le travail de fusion des fichiers de la nouvelle branche arch/x86 continue (plus de 1200 changements depuis le noyau 2.6.24).
- Les exécutables de plus de 2 Go sontmaintenant utilisables par le noyau.
- Après Ext3 et Ocfs2 c'est au tour du système de fichiersXFS dedevenir compatible avec le nouvel appel systèmefallocate() ayant été décrit dans lecompte-rendu du noyau 2.6.23.
- Le test des fonctions de mise en veille ou d'hibernation est rendu enfantin dans le nouveau noyau du fait de l'introduction d'une infrastructure spécialisée. Il suffit d'écriredifférents mots clés dans /sys/power/pm_test pour déclencher des actions précises portant sur les processus ou les périphériques...etc. Cette infrastructure de test permettra d'améliorer rapidement ce qui reste à l'heure actuelle un des points faibles de Linux.
- Une nouvelle architecture fait son entrée dans le noyau. Il s'agit des processeurs Panasonic 32 bits de lasérie MN103 qui sont utilisés dans le monde de l'embarqué (lecteurs de disques, systèmes de navigation, machines à laver...etc).
- De même lesSoC (System On Chip) de type Orion, qui sont largement présents dans les disques durs reliés par le réseau (network-attached storage), sont maintenant parfaitement gérés par le nouveau noyau 2.6.25.Cet article du site Linuxdevices fait le point sur la situation et liste les nombreux matériels utilisant la puce Orion.
- Dans la grande tradition libriste de support des matériels anciens on peut noter que le noyau 2.6.25gère maintenant officiellement les lecteurs propriétaires GD-ROM présents dans les consoles de jeu Sega Dreamcast.
- Diverses fonctionnalités de sécurité issues de labranche exec-shield maintenue par Ingo Molnar font leur entrée dans le noyau officiel. On peut citer, pour l'architecture x86, larandomisation de la pile ou encorecelle des exécutables. Comme cette mesure de sécuritéempêche quelques vieux logiciels de fonctionner il faut explicitement décocher l'option CONFIG_COMPAT_BRK pour qu'elle soit effective.
La liste détaillant de nombreuses autres nouveautés (réseaux, systèmes de fichier, pilotes disques, cartes son, vidéo, Bluetooth, etc.) est disponible sur le site deKernelnewbies. En revanche l'inclusion deKGDB, dont il avait un temps été question, semble s'être fracassée surla résistance acharnée de Linus et son dédain pour les debogueurs intégrés au noyau. - La régulation thermique proposée par la normeACPI 2.0 est dorénavant complètement implémentée dans le noyau 2.6.25. Cette interface permet de gérer, à l'aide de divers senseurs, des zones thermiques différentes au sein de la machine et de réguler finement leur température. Une documentationest disponible qui explique de façon détaillée toute cette machinerie complexe de la gestion des zones de températures par la norme ACPI.
Le site Linux Weekly News propose uneanalyse statistique faisant le point sur les multiples contributions durant le cycle du noyau 2.6.25.
Alors que les changements du noyau précédent étaient considérés comme inhabituellement nombreux il semble qu'il va falloir modifier nos critères de ce qui est normal et de ce qui ne l'est pas. En effet la tendance semble se poursuivre et même s'accélérer puisque le noyau 2.6.25 intègre plus de 12000 patchs écrits par 1174 développeurs différents (10000 patchs écrits par 950 développeurs pour le noyau 2.6.24 ce qui avait été qualifié de "monstrueux" par Linus).
Ce déluge de contributions est néanmoins relativisé par le léger allongement des délais entre les versions (ce qui mécaniquement augmente le nombre de patchs inclus dans chaque nouveau noyau).
En définitive le développement de Linux fonctionne donc à plein régime et l'organisation du travail mise en place permet d'intégrer rapidement toutes les nouveautés sans compromettre la stabilité et la fiabilité.
Mais la plus belle réussite est que le noyau: "incorpore le travail d'une communauté de plus en plus large de développeurs qui sont vraiment capables de travailler en coopération en dépit du fait que leurs employeurs sont en compétition acharnée. Il y a très peu de projets qui sont dans ce cas."
Pour la suite
En ce qui concerne les évolutions futures du noyau Linux on peut se tourner avec profit versla page de prévisions maintenue par Jonathan Corbet.
- L'outil de tracing de nouvelle générationutrace, destiné à remplacer le peu apprécié ptrace, a une nouvelle fois été retardé et n'a pu embarquer dans le noyau 2.6.25. Il reste des problèmes de gestion des verrous mais le travail continue vigoureusement car utrace serait un apport de qualité pour l'outilSystemTap (le concurrent duDTrace de Sun).
- Pour continuer dans la problématique de traçage de l'activité du noyau, Mathieu Desnoyers a proposé plusieurs patchs pour intégration dans le nouveau noyau 2.6.26. Ces patchs permettent l'intégration demarqueurs statiques légers afin d'instrumenter le fonctionnement de Linux. Cette intégration reste néanmoins aléatoire depuisla forte opposition qu'a soulevé Ingo Molnar. Selon lui ces marqueurs n'ont de "légers" que le nom puisqu'ils induiraient un surcoût inacceptable (4 bytes per marker per fastpast is _NOT_ acceptable in any way). La discussion est ensuite devenue très technique entre Mathieu et Ingo mais cela augure mal de l'intégration rapide des marqueurs statiques dans le noyau.
- Enfin le travail sur lesystème de fichier btrfs continue et la version 0.13 apporte denombreuses optimisations de performances. Une première comparaison avec le système de fichiers XFSa été effectuée et les résultats semblent plus que prometteurs.
Aller plus loin
- Les nouveautés du noyau 2.6.25(94 clics)
- Le bilan des ajouts partie 1(61 clics)
- Le bilan des ajouts partie 2(56 clics)
- Le bilan des ajouts partie 3(43 clics)
- Les prévisions pour l'avenir de Linux(36 clics)
