[Noyau] 2.6.25

Hanz0 · Le 18/04/2008, à 09:53

Une nouvelle version du noyau est disponible depuis hier.

Je ne vais me permettre d'essayer de mieux faire que Monsieur patrick_g tant ses articles sur le noyau sont un régal

Monsieur patrick_g, c'est à vous:

Les versions candidates
* La version RC-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 la RC-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 les RC-3, RC-4 et RC-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.
* La RC-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 la RC-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 la RC-8 qui devait être la dernière version candidate avant que Linus n'annonce le 11 avril la sortie d'une RC-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 module SMACK (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'infrastructure LSM 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 architectures DAC (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 architectures MAC (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 type label-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é du contrô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. Ce fichier 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é. Les discussions 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 Linus siffle 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'un article détaillé du site Linux Weekly News.
* Le mécanisme de Read-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 donc la 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 par Paul 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 du temps réel plusieurs avancées sont apportées par le nouveau noyau 2.6.25. L'ordonnanceur CFS 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.
* La mesure 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.
* Le systè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 des verrous 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ème spin_lock(). Si un nouveau processus arrive et veut utiliser la ressource il va faire son spin_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 patch est 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 des bus 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 diffusion socketcan 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'outil LatencyTOP 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çon très simple les processus en les classant par ordre décroissant de temps de latence (en millisecondes). Comme son prédécesseur PowerTOP, 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érer l'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 dans la 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, a retravaillé 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'interface mal conçue. En effet, lors de l'é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.
o La régulation thermique proposée par la norme ACPI 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 documentation est 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.
o Le noyau 2.6.25 voit, pour la première fois, l'inclusion des pilotes 2D pour les cartes AMD Radeon de type R500.
o La mise en veille ou en hibernation des systèmes ayant une carte Intel i915 fonctionne désormais correctement.
o De nombreux pilotes OSS 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'architecture ALSA.
o L'algorithme de chiffrement de flux proposé par Daniel J. Bernstein, Salsa20, est ajouté à la pile cryptographique du noyau. On note également l'inclusion de l'algorithme de compression de données LZO qui est conçu pour être particulièrement rapide lors de l'opération de décompression.
o Le protocole réseau ISATAP est maintenant inté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 le multicast.
o Le travail de fusion des fichiers de la nouvelle branche arch/x86 continue (plus de 1200 changements depuis le noyau 2.6.24).
o Les exécutables de plus de 2 Go sont maintenant utilisables par le noyau.
o Après Ext3 et Ocfs2 c'est au tour du système de fichiers XFS de devenir compatible avec le nouvel appel système fallocate() ayant été décrit dans le compte-rendu du noyau 2.6.23.
o 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'écrire diffé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.
o Une nouvelle architecture fait son entrée dans le noyau. Il s'agit des processeurs Panasonic 32 bits de la série MN103 qui sont utilisés dans le monde de l'embarqué (lecteurs de disques, systèmes de navigation, machines à laver...etc).
o De même les SoC (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.
o Dans la grande tradition libriste de support des matériels anciens on peut noter que le noyau 2.6.25 gère maintenant officiellement les lecteurs propriétaires GD-ROM présents dans les consoles de jeu Sega Dreamcast.
o Diverses fonctionnalités de sécurité issues de la branche exec-shield maintenue par Ingo Molnar font leur entrée dans le noyau officiel. On peut citer, pour l'architecture x86, la randomisation de la pile ou encore celle 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 de Kernelnewbies. En revanche l'inclusion de KGDB, dont il avait un temps été question, semble s'être fracassée sur la résistance acharnée de Linus et son dédain pour les debogueurs intégrés au noyau.

Le site Linux Weekly News propose une analyse 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 vers la page de prévisions maintenue par Jonathan Corbet.
* L'outil de tracing de nouvelle génération utrace, 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'outil SystemTap (le concurrent du DTrace 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 de marqueurs statiques légers afin d'instrumenter le fonctionnement de Linux. Cette intégration reste néanmoins aléatoire depuis la 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 le système de fichier btrfs continue et la version 0.13 apporte de nombreuses optimisations de performances. Une première comparaison avec le système de fichiers XFS a été effectuée et les résultats semblent plus que prometteurs.

Donc je répond déjà à la question que certains pourraient se poser: non cette version du noyau ne sera pas celle d'Ubuntu 8.04.
Je reviens également sur le futur standard des systèmes de fichiers à savoir l'ext4, qui lui sera incorporé par défaut dans Fedora 9, tout comme le noyau 2.6.25.
Fedora 9 sort le 13 Mai soit moins de 3 semaines après Ubuntu 8.04 ...

Source: http://linuxfr.org/2008/04/17/23919.html

Dernière modification par Hanz0 (Le 22/04/2008, à 08:31)

roxnin · Le 18/04/2008, à 10:24

o Dans la grande tradition libriste de support des matériels anciens on peut noter que le noyau 2.6.25 gère maintenant officiellement les lecteurs propriétaires GD-ROM présents dans les consoles de jeu Sega Dreamcast.

'tain, mais c'est que ça mine de rien ça peut être grave interessant

theoxyd · Le 18/04/2008, à 11:11

roxnin a écrit :

o Dans la grande tradition libriste de support des matériels anciens on peut noter que le noyau 2.6.25 gère maintenant officiellement les lecteurs propriétaires GD-ROM présents dans les consoles de jeu Sega Dreamcast.
'tain, mais c'est que ça mine de rien ça peut être grave interessant

c'est vrai dis donc
Moi c'est surtout la gestion du i915 améliorée qui me plait ...

Dernière modification par theoxyd (Le 18/04/2008, à 11:11)

R@ND@LL · Le 18/04/2008, à 20:00

A quand la gestion améliorée des puces graphiques des premières Game Boy?

JYCombes · Le 18/04/2008, à 21:03

Hanz0 a écrit :

Donc je répond déjà à la question que certains pourraient se poser: non cette version du noyau ne sera celle d'Ubuntu 8.04.
Je reviens également sur le futur standard des systèmes de fichiers à savoir l'ext4, qui lui sera incorporé par défaut dans Fedora 9, tout comme le noyau 2.6.25.
Fedora 9 sort le 29 Avril soit 5 jours après Ubuntu 8.04 ...
Source: http://linuxfr.org/2008/04/17/23919.html

NIET !

La Fedora 9 sortira mi-mai, le 13 pour être plus précis :

http://www.redhat.com/archives/fedora-devel-announce/2008-April/msg00011.html

"At today's regularly scheduled meeting, the Fedora Engineering
Steering Committee (FESCo) decided that Fedora 9 release will be
slipping by exactly two weeks."

Sûrement pour mieux intégrer le 2.6.25...

Quant au Ext4fs en standard dans Fedora9, j'attend pour voir

bloublou · Le 18/04/2008, à 23:45

JYCombes a écrit :

Hanz0 a écrit :
Donc je répond déjà à la question que certains pourraient se poser: non cette version du noyau ne sera celle d'Ubuntu 8.04.
Je reviens également sur le futur standard des systèmes de fichiers à savoir l'ext4, qui lui sera incorporé par défaut dans Fedora 9, tout comme le noyau 2.6.25.
Fedora 9 sort le 29 Avril soit 5 jours après Ubuntu 8.04 ...
Source: http://linuxfr.org/2008/04/17/23919.html
NIET !
La Fedora 9 sortira mi-mai, le 13 pour être plus précis :
http://www.redhat.com/archives/fedora-devel-announce/2008-April/msg00011.html
"At today's regularly scheduled meeting, the Fedora Engineering
Steering Committee (FESCo) decided that Fedora 9 release will be
slipping by exactly two weeks."
Sûrement pour mieux intégrer le 2.6.25...

Non, pour corriger des bugs de dernières minutes (enfin, semaine) mais qui présentent quand même des soucis importants.
Le noyau 2.6.25 est déjà dans la beta de Fedora 9 depuis longtemps (en RC*, mais elle y est)
Et on a 2.6.24, sous fedora 8, NOUS

Quant au Ext4fs en standard dans Fedora9, j'attend pour voir

Moi aussi, et je me fais pas de soucis

Dernière modification par louizatakk (Le 18/04/2008, à 23:45)

Dert Ung · Le 18/04/2008, à 23:53

J'ai mal à la tête...

JYCombes · Le 19/04/2008, à 07:10

louizatakk a écrit :

JYCombes a écrit :
Hanz0 a écrit :
Donc je répond déjà à la question que certains pourraient se poser: non cette version du noyau ne sera celle d'Ubuntu 8.04.
Je reviens également sur le futur standard des systèmes de fichiers à savoir l'ext4, qui lui sera incorporé par défaut dans Fedora 9, tout comme le noyau 2.6.25.
Fedora 9 sort le 29 Avril soit 5 jours après Ubuntu 8.04 ...
Source: http://linuxfr.org/2008/04/17/23919.html
NIET !
La Fedora 9 sortira mi-mai, le 13 pour être plus précis :
http://www.redhat.com/archives/fedora-devel-announce/2008-April/msg00011.html
"At today's regularly scheduled meeting, the Fedora Engineering
Steering Committee (FESCo) decided that Fedora 9 release will be
slipping by exactly two weeks."
Sûrement pour mieux intégrer le 2.6.25...
Non, pour corriger des bugs de dernières minutes (enfin, semaine) mais qui présentent quand même des soucis importants.

Ah ?

Le noyau 2.6.25 est déjà dans la beta de Fedora 9 depuis longtemps (en RC*, mais elle y est)
Et on a 2.6.24, sous fedora 8, NOUS

Je sais. Et je me rappelle d'un 2.6.23 qui foutait une mouise monstrueuse : X gelé entre autre...

Et quand j'étais sous ArchLinux, j'avais toujours le dernier noyau stable...

Quant au Ext4fs en standard dans Fedora9, j'attend pour voir
Moi aussi, et je me fais pas de soucis

Encore faudra-t-il savoir ce qu'il apporte pour le pékin moyen... Et tant que l'ext4 ne sera pas activé dans les options de compilation, hein...

Hanz0 · Le 19/04/2008, à 08:33

JYCombes a écrit :

NIET !
La Fedora 9 sortira mi-mai, le 13 pour être plus précis :

Comme disait un prof:"C'était pour voir ceux qui suivaient"
Donc j'edit, elle est prévue pour le 13 mai, et la Preview est sortie hier (18/04/08).

JYCombes a écrit :

Encore faudra-t-il savoir ce qu'il apporte pour le pékin moyen... Et tant que l'ext4 ne sera pas activé dans les options de compilation, hein...

The ext4 filesystem is the evolution of ext3 - more scalable and better performing, thanks to a new on-disk extent format and new allocator heuristics. New features include:
* Extent-based disk format
* 48-bit block numbers
* Multiblock Allocation
* Delayed Allocation (not in initial release)
* Break 32000 subdirectory limit
* Directory Inodes reservation
* Nanosecond timestamps
* Inode version on disk
* Uninitialized groups (not in initial release)
* Journal checksumming
* Persistent preallocation
* Online Defragmentation (not in initial release)
These features are in various states of completion today. Fedora 9 has a preview of ext4; the installer will allow users to install onto an ext4 filesystem by adding "ext4" to the installer boot commandline, and choosing custom partitioning.
Note that admin tools (e2fsprogs) will not fully support ext4 when Fedora 9 is released, so this is still for testing/preview.

ext4 Wikipedia: http://fr.wikipedia.org/wiki/Ext4
Source: http://fedoraproject.org/wiki/Features/Ext4
Les nouveautés: http://fedoraproject.org/wiki/Releases/9/FeatureList
Développement: http://fedoraproject.org/wiki/Releases/9/Schedule

Dernière modification par Hanz0 (Le 19/04/2008, à 08:38)

JYCombes · Le 19/04/2008, à 15:25

Je me suis renseigné sur l'ext4. Mais je pense que le filesystem ne sera l'option par défaut que d'ici fin 2009, début 2010.

Car changer de filesystem, cela ne se fait pas du jour au lendemain.

Dempiller · Le 21/04/2008, à 20:36

Bonjour a tous. Je suis un petit nouveau qui a essayé la gutsy gibbon mais qui(j ai honte) a laissé tomber car pas mal de problemes (nottement ma 3d sous ati 2600xt ne fonctionnai pas et mon son..) et surtout manque de temps pour les resoudre.cependant je suis bien decidé a m'y remettre avec Hardy Heron.Enfin soit tout ca pour demander; Est-ce que le nouveau noyau serra installable via une mise a jour?si oui est-ce stable? ensuite; Pourrons nous passer de ext3 a ect4 par une "simple" conversion et n'est-ce pas risqué?

Merci d'avance de vos réponses ;-)

Zergy · Le 21/04/2008, à 22:33

Dempiller a écrit :

Bonjour a tous. Je suis un petit nouveau qui a essayé la gutsy gibbon mais qui(j ai honte) a laissé tomber car pas mal de problemes (nottement ma 3d sous ati 2600xt ne fonctionnai pas et mon son..) et surtout manque de temps pour les resoudre.cependant je suis bien decidé a m'y remettre avec Hardy Heron.Enfin soit tout ca pour demander; Est-ce que le nouveau noyau serra installable via une mise a jour?si oui est-ce stable? ensuite; Pourrons nous passer de ext3 a ect4 par une "simple" conversion et n'est-ce pas risqué?
Merci d'avance de vos réponses ;-)

Non et non
Un fois la distribution sortis, les seules mises à jour concernent la sécurité.
Quand à ext4, il est encore trop tôt pour être utilisable sereinement.

Dernière modification par Zergy (Le 21/04/2008, à 22:34)

yurek · Le 21/04/2008, à 22:56

Moi j'ai adoré le fait que la mise en veille sera complètement opérationnel.

ilcorseronero · Le 21/04/2008, à 23:01

eh yurek

le hanzo c'est lui ou toi
moi je dirai toi

Dempiller · Le 21/04/2008, à 23:02

Hum ok dommage. Je demandais car sous mandriva j'avai "mis a jour mon noyau(kernel)"
Mais cela me fais dire (a propos du noyau)Hrdy heron serat dons en reetard sur la fedora 9 par exemple? C est dommage pour une Lts...
En tout cas je vous remercie de vos reponses ;-)

yurek · Le 21/04/2008, à 23:36

ilcorseronero
Mais d'où est ce que sortent tous ces safinaz (les nazs) ?
:lol::lol::lol:

Hanz0 · Le 22/04/2008, à 08:45

Dempiller a écrit :

Mais cela me fais dire (a propos du noyau)Hrdy heron serat dons en reetard sur la fedora 9 par exemple? C est dommage pour une Lts...

Ubuntu à toujours un noyau et un Xorg de retard.
Ils freez très / trop tôt les versions des softs et du noyau.
Je préférerais de loin attendre encore une quinziane de jours pour pouvoir profiter du dernier noyau et du dernier Xorg, alors que ce sont 2 points essentiels dans une distribution
Fedora / Red Hat à toujours affiché haut et fort son côté "High Tech" et la rapidité des releases.

Ce qui est surtout dommage, c'est que chez Fedora y a vraiment une équipe complète qui ne s'occupe que du design et que pour Hardy, il n'y ait même pas un nouveau thème pour une LTS.
Sur ce dernier point, la communauté est vraiment très déçue ...

Par exemple sur ma machine de travail (CF ci-dessous), Ubuntu ne passe qu'à moitié depuis la beta de Hardy, alors que Fedora 8 sortie en Novembre 2007, s'installe comme un charme.
Donc je dirais que pour ceux qui ont du matos "Next gen", d'abord essayer Fedora

Ceci dit, chez mes clients, c'est toujours Ubuntu que j'installe

NooP · Le 22/04/2008, à 13:24

Je ne suis pas d'accord !

Que la LTS ait un noyau de retard n'est pas handicapant ! C'est une LTS, et sous le pseudo 'Long Term Support' se cache en fait son vrai atout : STABILITE !!!

On ne peut pas se permettre de sortir une version succeptible d'intéresser les entreprises en mettant les derniers logiciels geeks dessus. C'est la stablilté qui prime dans cette version.

Essayez donc de faire un serveur en prod avec une fedora ... Bonjour la galère pour les mises à jour.

Dernière modification par NooP (Le 22/04/2008, à 13:26)

bloublou · Le 22/04/2008, à 14:07

NooP a écrit :

Je ne suis pas d'accord !
Essayez donc de faire un serveur en prod avec une fedora ... Bonjour la galère pour les mises à jour.

En même temps, un serveur sous Ubuntu...

(wouhou, troll pourri \o/)

Je pense que y'a pas de raison d'être déçu, ceux qui veulent avoir les derniers trucs Hi-tech, utilisez fedora et voilà

Dempiller · Le 22/04/2008, à 17:15

Pour finir je me perds un peu dans tout ces dires.Quelqu'un sait-il si on pourrai mettre a jour le kernel ou si ils sortiront une version de Hardy Heron doté de base de ce nouveau noyau? Ce nouveau noyau a vraiment l'air prometteur et il serait donc genial de pouvoir tourner dessus avec Hardy Heron.

Hanz0 · Le 22/04/2008, à 17:26

Bugmaster a écrit :

(si la stabilité primait sur le développement y'aurait pas FF3 dessus, quoi)

+1
Je ne vais pas entrer dans le débat car Ubuntu est vraiment une bonne distribution, mais c'est clair qu'alors faudrait faire le ménage dans les versions des applications choisies.
Si je ne me trompe pas, la version 7.10, il y avait OpenOffice en RC et Gimp en RC.
Et justement, pour une LTS, j'aurais choisi de la sortir par exemple du côté de la mi-mai, pour pouvoir profiter du dernier noyau et du dernier Xorg.
Sachant qu'en plus Xorg à un développement de 6 mois à peu prêt équivalent à celui de Gnome.

Quoi que Xorg en serveur n'est pas installé pour des raisons de sécurité
Va-t-en sécurisé 16 millions de lignes de codes ...

En fait Fedora a été jusqu'ici beaucoup plus sécurisée qu'Ubuntu et est clairement orientée VPN réseau etc ...
C'est seulement dans cette version d'Ubuntu que SeLinux est incorporé avec des optimisations de noyau pour les techniques de débordement de mémoire.

Bref, comme je dis toujours:"Les goûts et les couleurs ...".
Chacune ont des avantages et des inconvénients.

Selon le cas j'installe une des 3 plus grande distro disponible à savoir: Fedora, Ubuntu ou OpenSuse.
Comme je l'ai déjà dis, Ubuntu représente 90% de mes installations, mais je ne comprends pas toujours certains choix fait au sein de Canonical.

Minøs · Le 22/04/2008, à 17:37

Whaaa ! Linux 2.6.25-14rc4 est sorti ! C'est la fête !

Hanz0 · Le 22/04/2008, à 17:41

Dempiller a écrit :

Pour finir je me perds un peu dans tout ces dires.Quelqu'un sait-il si on pourrai mettre a jour le kernel ou si ils sortiront une version de Hardy Heron doté de base de ce nouveau noyau? Ce nouveau noyau a vraiment l'air prometteur et il serait donc genial de pouvoir tourner dessus avec Hardy Heron.

La version de noyau de Hardy est 2.6.24.4.

Si tu veux ce noyau dans ta distribution, plusieurs solutions:
- Tu attends Ubuntu 8.10 et tu mets à jour (à vue de nez ce sera 2.6.27)
- Tu télécharges le dernier noyau et tu le compiles toi-même
- Tu choisis une autre distribution qui intègre cette version de noyau (Fedora, OpenSuse, ...)

Cordialement.

Dempiller · Le 22/04/2008, à 17:50

Merci Hanz0 cependant je ne sais pas compiler ni meme installer un paquet avec le terminal je n'ai encore aucune experiance en gnu/linux(bon j ai bien installé une ubuntu et une mandriva mais j ai pas encore fais grand chose dessus j attend Hardy Heron).maisdonc si je met Hardy Heron puis dans 6 mois la 8.10 en mettant a jour est-ce bien stable et propre ou mieux vaut il reinstaller complettement la 8.10?Enfin soit donc mettre hardy Heron est quand meme judicieux?

Hanz0 · Le 22/04/2008, à 18:05

Si tu es un débutant, je te conseil vivement ce livre ainsi que la formidable documentation de ce site.
Les 2 cumulés devraient faire de toi un vrai Ubunteros d'ici peu

Tu peux sans souci installer Hardy et concernant les mises à jours de version, tu dois d'abord mettre ta version actuelle à jour, pour ensuite partir sur une nouvelle version et donc un nouveau noyau, un nouveau Xorg, etc.
D'autres repartent tous les 6 mois avec la dernière version en ayant conservé le dossier /home.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 18/04/2008, à 09:53

[Noyau] 2.6.25

#2 Le 18/04/2008, à 10:24

Re : [Noyau] 2.6.25

#3 Le 18/04/2008, à 11:11

Re : [Noyau] 2.6.25

#4 Le 18/04/2008, à 20:00

Re : [Noyau] 2.6.25

#5 Le 18/04/2008, à 21:03

Re : [Noyau] 2.6.25

#6 Le 18/04/2008, à 23:45

Re : [Noyau] 2.6.25

#7 Le 18/04/2008, à 23:53

Re : [Noyau] 2.6.25

#8 Le 19/04/2008, à 07:10

Re : [Noyau] 2.6.25

#9 Le 19/04/2008, à 08:33

Re : [Noyau] 2.6.25

#10 Le 19/04/2008, à 15:25

Re : [Noyau] 2.6.25

#11 Le 21/04/2008, à 20:36

Re : [Noyau] 2.6.25

#12 Le 21/04/2008, à 22:33

Re : [Noyau] 2.6.25

#13 Le 21/04/2008, à 22:56

Re : [Noyau] 2.6.25

#14 Le 21/04/2008, à 23:01

Re : [Noyau] 2.6.25

#15 Le 21/04/2008, à 23:02

Re : [Noyau] 2.6.25

#16 Le 21/04/2008, à 23:36

Re : [Noyau] 2.6.25

#17 Le 22/04/2008, à 08:45

Re : [Noyau] 2.6.25

#18 Le 22/04/2008, à 13:24

Re : [Noyau] 2.6.25

#19 Le 22/04/2008, à 14:07

Re : [Noyau] 2.6.25

#20 Le 22/04/2008, à 17:15

Re : [Noyau] 2.6.25

#21 Le 22/04/2008, à 17:26

Re : [Noyau] 2.6.25

#22 Le 22/04/2008, à 17:37

Re : [Noyau] 2.6.25

#23 Le 22/04/2008, à 17:41

Re : [Noyau] 2.6.25

#24 Le 22/04/2008, à 17:50

Re : [Noyau] 2.6.25

#25 Le 22/04/2008, à 18:05

Re : [Noyau] 2.6.25

Pied de page des forums