Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche. La phase de test...
- La version RC-1 (nom de code "Killer Bat of Doom") est apparue juste deux semaines après la sortie du noyau stable précédent. Linus, comme c'est devenu son habitude, a récapitulé dans son annonce les statistiques sur le nombre de changements : "Cela fait deux semaines donc il est temps de refermer la période de merge. La RC-1est maintenant disponible et, avec un peu de chance, tout est nickel.
Les changements de cette RC-1 sont (comme d'habitude) trop nombreux pour être énumérés et concernent en majorité les pilotes (comme d'habitude là encore). C'est encore plus vrai depuis que nous avons incorporé la branche staging.
3.3% arch/arm/
14.2% arch/
3.1% crypto/
4.0% drivers/media/
3.7% drivers/net/wireless/
10.3% drivers/net/
6.5% drivers/staging/me4000/
8.5% drivers/staging/slicoss/
4.8% drivers/staging/wlan-ng/
29.7% drivers/staging/
63.6% drivers/
3.3% include/
4.6% net/
4.6% sound/
Pour cette RC-1 il y a eu 880 auteurs différents, 340 d'entre eux avec juste un changement et 183 auteurs ont 10 changements ou plus à leur actif. Le prix de l'horloge la plus pourrie est attribué à Greg Kroah-Hartman pour son patch 51b90540 qui est, soit disant, du 9 avril... mais d'il y a six ans ! Et qui corrige un pilote qui n'a été intégré qu'en juillet dernier ! Pas mal Greg."
- Dès le 26 octobre Linus a annoncé la version candidate RC-2 : "Cela ne fait pas encore une semaine mais nous avons eu des bugs ennuyeux et honteux (brown-paper-bugs) dans la RC-1 qui empêchaient les gens de tester sans appliquer des patchs. Donc plutôt que d'attendre une semaine je vais juste sortir une RC-2 plus tôt avec les corrections des problèmes.
Hé peut-être que nous pourrions _continuer_ ce super modèle des "petites corrections après la RC-1" ! Je sais que ça semble fou mais c'est un vrai plaisir pour une fois de faire une RC-2 qui corrige des vrais problèmes pour les vrais gens. Quel concept !".
- Les délais de parution sont par la suite revenu à la normale et les versions RC-3, RC-4 et RC-5 se sont succédé sans aucun souci particulier. Lors de l'annonce de la version RC-6 Linus a annoncé qu'il allait profiter de quelques jours de vacances : "Tout a été très calme et j'espère que ça va continuer car je suis en congé pour mes vacances annuelles palmes-tuba. Donc avant que je ne parte (pas d'emails sous-marins) voici une nouvelle version candidate.
J'espère vraiment que je vais avoir une semaine tranquille et qu'au moment ou je serai de retour vous aurez testé cette version intensivement et vous m'aurez envoyé les corrections pour toutes les régressions. Ne me décevez pas !".
- N'ayant pas été déçu à son retour de vacances Linus a sorti le premier décembre une version RC-7 sans histoire. Cependant lors de l'annonce de la version RC-8 un problème de calendrier s'est posé puisque Linus a réalisé qu'une sortie de version stable vers la fin d'année aurait impliqué une période de merge durant les vacances : "Je ne pense pas que quiconque veuille une période de merge autour des vacances donc le problème revient à choisir entre :
-(a) Juste continuer à faire des RC pendant encore quelques semaines et sortir le 2.6.28 après Noël. J'aime bien ça car les gens pourront déboguer plus longtemps et nous aurons un 2.6.28 plus stable.
ou
-(b) Sortir la version stable d'ici une semaine ou deux mais allonger la période de merge du fait des gens qui seront complètement bourrés pendant les vacances. J'aime bien cette solution aussi car, ne nous le cachons pas, nous avons de bien meilleurs rapports de bugs après la sortie de la version stable et tout _devrait_ être prêt pour le merge *bien avant* l'ouverture de toute façon.
ou
-(c) Une autre solution complètement barge sortie de l'esprit d'un mec défoncé aux drogues.
Je ne me suis pas encore décidé mais je suis ouvert à toutes les suggestions".
- Linus a finalement décidé de faire une dernière RC-9 mais a opté pour une sortie du noyau avant Noël en allongeant la période de merge (solution (b) pour ceux qui suivent) :"Il n'y a vraiment _rien_ d'intéressant dans cette version candidate. Juste des petits changements (...) et si vous pouvez lire jusqu'à la moitié de la liste sans vous endormir alors vous vous serez prouvé à vous même que vous avez suffisamment de caféine dans le sang. En fait c'est ça la partie la plus excitante de cette RC-9: La révolution médicale qu'elle apporte en tant que test de déficience en caféine !
Je pense que le 2.6.28 sera sorti pour Noël (ou Hanukkah, Kwanzaa, le Solstice, Insérez vos vacances favorites) car franchement je vais devenir fou si je continue à sortir des versions aussi ennuyeuses pendant 2 semaines. La période de merge sera plus longue pour les gens qui préfèrent se bourrer la gueule au glögg plutôt que d'être des développeurs du noyau utiles. En fait vous pouvez faire les deux: Préparez avant Noël votre branche pour le merge et ensuite vous pourrez être dans un état de stupeur alcoolique tout en vous sentant _aussi_ un membre productif de la société pendant les vacances".
Les nouveautés...
- Le gestionnaire de mémoire pour cartes graphiques GEM (Graphics Execution Manager) est finalement entré dans le noyau.
Ce morceau de code, contribué par Intel, permet de décharger les pilotes de cartes graphiques (GPU) de l'obligation de gérer la mémoire et présente l'avantage d'être beaucoup plus simple et logique que son concurrent TTM (Translation Table Maps) de Tungsten Graphics. Dans GEM l'allocation des tampons mémoires d'objets graphiques se fait en utilisant la banale mémoire en espace utilisateur (ce qui facilite la gestion du swaping ou de la mise en veille). TTM de son coté gère la mémoire de façon plus complexe en allouant des "buffer objects" et en les mappant sur la mémoire. Cette solution oblige a gérer également la cohérence des mémoires caches et il s'avère en définitive que cela pose de nombreux problèmes. Initialement l'alternative GEM a été perçue comme étant spécifiquement écrite pour les cartes graphiques Intel et il y a eu une certaine résistance de la part des autres développeurs. L'inclusion dans le noyau clôt le débat et signifie sans aucun doute que les pilotes libres vont être adaptés pour tirer profit de ce nouvel outil et que TTM ne rentrera pas dans le noyau. Le pilote graphique xf86-video-intel 2.5.0 utilise d'ailleurs GEM et le pilote libre Radeon est en cours de modification.
Il est à noter que GEM n'est qu'une des pièces de la profonde rénovation du système graphique qui est en cours dans l'écosystème Linux et dont la prochaine étape sera, sans doute dès le noyau 2.6.29, l'inclusion du Kernel mode setting. Avec GEM et KMS le noyau sera fin prêt pour accueillir une nouvelle génération de pilotes graphiques libres.
- La version 2.6.28 de Linux propose une nouvelle infrastructure de gestion des domaines réglementaires des réseaux sans fil.
Sous ce nom opaque se cache le système qui permet au noyau Linux de faire respecter les diverses législations nationales dans le domaine des fréquences d'émission radio et de l'énergie rayonnée par ces émissions. Plutôt que d'obliger chaque pilote de carte wifi à écrire sa propre gestion des obligations réglementaires, il est préférable d'avoir une infrastructure centralisée pour que les pilotes puissent y faire appel afin de savoir quelles sont les lois applicables. La précédente infrastructure était peu pratique puisque seul trois domaines étaient gérés (US, JP et EU) et que les règles étaient incluses statiquement dans le noyau. La toute nouvelle infrastructure présente dans la version 2.6.28 de Linux permet de gérer les lois de tous les pays par l'intermédiaire d'un programme en espace utilisateur (nommé CRDA pour Central Regulatory Domain Agent) qui utilise udev pour "parler" au noyau. On peut ainsi mettre à jour les règles de gestion, à partir d'une base qui peut être signée numériquement, sans avoir à mettre à jour le noyau lui-même. Dans l'espoir d'arriver à une gestion unifiée de ces problèmes de régulations le programme CRDA a été mis sous licence ISC (semblable à la BSD) pour qu'il puisse être largement réutilisé par la communauté du libre. Le nouveau mécanisme est décrit dans ce fichier et le code de CDRA est téléchargeable sur ce site. On peut espérer qu'avec l'introduction de ce mécanisme de gestion centralisé et sécurisé les constructeurs de périphériques sans fils auront une excuse de moins pour ne pas proposer des pilotes libres.
- Le noyau 2.6.28 améliore grandement la capacité de montée en charge (scalability) de la gestion de la mémoire.
Depuis plus d'un an le développeur Rik van Riel a travaillé sur un design visant à améliorer le fonctionnement des systèmes ayant de très grandes quantités de mémoire vive. Pour Rick la tâche a été difficile car la gestion de la mémoire est une zone sensible du noyau et il lui a fallu convaincre les autres développeurs de la qualité de son travail avant d'arriver à l'inclure dans la branche principale. Le problème qu'il s'agissait de résoudre était que, pour les systèmes ayant plus de 128 Go de RAM, l'algorithme de gestion pouvait parfois dépenser littéralement des heures (!) à passer en revue les pages mémoires. En temps normal le noyau essaye de tirer parti de toute la mémoire qui est disponible en laissant "en cache" dans la mémoire toute les données sur lesquelles il y a eu un accès. Le noyau garde deux listes : celle des pages actives et celle des pages inactives qui n'ont pas été réclamées par un processus depuis un certain temps (le choix se fait à l'aide de l'algorithme LRU pour "Least Recently Used"). Quand il est nécessaire de trouver de nouvelles pages mémoires disponibles le noyau parcourt la liste des pages inactives afin de choisir celles qui devront libérer la place (on parle d'éviction) en étant écrites sur le disque (swap). Linux utilise ainsi l'espace libéré par ces pages pour charger en mémoire vive les nouvelles pages mémoires.
L'ennui c'est que le parcours de ces listes peut être très long puisqu'il y a, par exemple, 256 millions pages de 4 Ko dans un système ayant 1 To de RAM. Le patch de Rick découpe plus finement les deux listes mentionnées plus haut en pariant sur le fait qu'ainsi les listes seront plus petites et pourront donc être lues plus rapidement. Ce découpage se fait entre les pages de fichiers (file pages) et les pages de processus (process-memory pages) qui ont maintenant chacune leurs propres listes de pages actives/inactives. La situation est compliquée par le fait qu'il existe des pages pouvant être marquées comme non évincables (avec l'appel système mlock()) et qu'il est nécessaire de garder aussi une liste des ces pages spéciales devant absolument rester en mémoire vive.
Le résultat net du travail de Rick est que maintenant les systèmes ayant de grandes quantités de RAM n'ont plus l'occasion de passer des heures à scanner interminablement leur mémoire pour trouver les pages mémoires à libérer. Les machines ayant largement plus de 128 Go de mémoire vive sont encore assez rares mais il est bon de savoir que le noyau Linux n'est plus victime de ce comportement pathologique occasionnel.
- Toujours dans le domaine de la gestion de la mémoire le développeur Nick Piggin a procédé à la modification de la fonction vmap() afin de mieux tirer parti des systèmes multiprocesseurs.
La fonction vmap() est utilisée dans le noyau pour présenter (mapper) de façon virtuellement continue un ensemble de pages mémoires qui sont en réalité physiquement discontinues. Cette fonction est une proche cousine de vmalloc() qui permet, elle, d'allouer de la mémoire virtuellement contiguë. C'est très utile par exemple pour charger des modules dans le noyau car ces derniers doivent absolument résider dans un espace d'adressage mémoire continu. Nick a noté que le coût d'appel de ces fonctions est élevé car, par exemple, l'espace d'adressage de vmalloc() est gardé dans une liste protégée par un verrou global qui bloque tous les processeurs. On peut également citer comme autre point noir le fait que la libération mémoire dans cet espace d'adressage nécessite un vidage, par tous les processeurs, du TLB (Translation Lookaside Buffer) qui est une sorte de cache aidant à la traduction des adresses virtuelles en adresses physiques.
Le challenge était donc clair : modifier ces fonctions afin de réduire autant que possible ces problèmes. Nick a commencé par enlever la liste protégée par un verrou global et à utiliser à la place un arbre bicolore qui recherche les espaces adressables libres sans avoir à parcourir une longue liste. Des micro-listes par processeur sont utilisées afin de ne plus être bloqué par le verrou (on utilise ces micro-listes avec le nouvel appel vm_map_ram()). Pour le problème du vidage (flush) des TLB, Nick a opté pour une solution ingénieuse qui consiste a ne procéder à ce vidage que lorsque les adresses sont vraiment utilisées ailleurs et non lorsqu'elles sont seulement libérées. Cela permet d'accumuler tous les flushs à effectuer dans un tampon afin de ne procéder à ces opérations de vidage qu'en une seule fois.
Tout ce travail a payé puisque dans son annonce du patch Nick dévoile quelques benchmarks impressionnants. Dans un test non réaliste conçu pour mettre en évidence la différence avec l'ancien code, Nick observe un gain d'un facteur 25 (passage de 70631 nanosecondes à 2900) pour un système à 8 coeurs. Dans un test plus réaliste (la modification du système de fichiers XFS afin d'allouer de la mémoire pour un gros répertoire sur une machine 64 coeurs) ce gain n'est, hélas, plus que d'un facteur 20 ;-)
- La pile réseau du nouveau noyau Linux supporte maintenant la norme UWB (Ultra wideband). Cette norme permet des liaisons point-à-point à courte distance (10 m) en utilisant des impulsions radios de très courte durée. C'est cette compression des impulsions qui augmente la bande passante et qui permet au protocole UWB d'atteindre jusqu'à 60 Mo par seconde quand la distance n'excède pas quelques mètres. La norme UWB sera utilisée pour transporter d'autres protocoles de liaison comme par exemple Ethernet-over-UWB, Bluetooth-over-UWB ou encore Wireless USB (ce dernier mode de communication fait également son entrée dans le noyau). Le futur de cette technologie est néanmoins incertain du fait de problèmes réglementaires d'allocation de fréquences, de prix et de consommation d'énergie. Intel a d'ailleurs abandonné le consortium et le constructeur de composant Wiquest a fermé ses portes car il n'arrivait pas à réduire le coût de ses puces UWB.
- Le système de fichiers Ext4, en développement depuis longtemps, a maintenant été jugé suffisamment stable pour ne plus être marqué par le statut "en cours de développement" qui le caractérisait depuis le noyau 2.6.19 (novembre 2006).
C'est son développeur principal, Ted Ts'o, qui a proposé ce patch pour enlever le préfixe "dev" qui était appliqué jusqu'à présent au système de fichiers Ext4. Cette nouvelle version, compatible avec Ext3, repousse la limite de taille du système de fichiers à 1024 pétaoctets, propose les extents (zone contiguë qui est réservée chaque fois qu'un fichier est enregistré) et la préallocation d'espace. La vérification du système lors du montage (fsck) est également beaucoup plus rapide, des points de traçage statiques sont intégrés et les timestamps sont plus précis.
Cette suppression du flag "dev" n'est bien entendu pas une étape technique, c'est en fait une étape symbolique qui est franchie ici puisqu'il s'agit d'un signal à l'attention des distributions Linux qui ont maintenant le feu vert pour utiliser Ext4.
Ted Ts'o a également indiqué que le système de fichiers Ext4 était considéré comme une solution intérimaire en attendant le vrai système de nouvelle génération que sera Btrfs : "Une chose que vous ne savez peut-être pas est qu'il y a environ un an (les 12 et 13 novembre 2007) un petit groupe de développeurs de systèmes de fichiers s'est réuni pour un workshop sur le système de fichiers de nouvelle génération ("Next Generation Filesystem" ou "NGFS"). Il y avait là des ingénieurs employés par HP, Oracle, IBM, Intel et Red Hat, et dont l'expertise couvrait des systèmes comme ext2, ext3, ext4, ocfs2, lustre, btrfs, advfs, reiserfs, et xfs. A la fin de ce workshop il y a eu un accord unanime (y compris de votre serviteur) pour déclarer que (a) Linux avait besoin d'un système de fichiers de nouvelle génération, (b) Le système Btrfs de Chris Mason (avec quelques changements/améliorations) était la meilleure solution à long terme en tant que NGFS, (c) La création d'un système de fichiers robuste qualifié pour les besoins des entreprises prenait toujours plus de temps que prévu et que, même en tenant compte de ce facteur, les entreprises étaient lentes à accorder leur confiance à un nouveau système destiné à accueillir leurs données les plus critiques. Ext4 était donc le pont qui allait faire le lien entre la situation actuelle et l'arrivée du NGFS".
- Comme évoqué par Linus dans son message d'annonce de la RC-1, la branche -staging a été intégrée au noyau. C'est le résultat d'une longue lutte entre les partisans de l'inclusion rapide des pilotes de périphériques afin de les améliorer plus facilement et ceux qui préfèrent attendre que ces pilotes soient fiables et mûrs avant de les intégrer dans Linux.
Le 10 juin dernier le développeur Greg Kroah-Hartman a annoncé la création d'une branche spéciale, linux-staging, destinée à accueillir ces pilotes non finalisés et à accroître leur visibilité afin de susciter l'intérêt des testeurs et des relecteurs de code. Cette stratégie a bien fonctionné et plusieurs pilotes ont pu ainsi intégrer la branche principale alors qu'ils stagnaient depuis des années quand ils étaient gérés complètement à l'écart du modèle de développement de Linux. L'étape logique suivante était donc d'intégrer cette branche -staging directement dans le noyau officiel (dans drivers/staging) afin d'accroître encore plus la visibilité des pilotes et d'obtenir des améliorations sous forme de patchs et de relecture critique. Bien entendu il a fallu prévoir les cas où ces pilotes seraient effectivement chargés et utilisés par des têtes brulées aventureuses et provoqueraient des plantages de la machine. Pour aider au deboguage un nouveau drapeau d'alerte (TAINT_CRAP qu'on pourrait traduire par "Souillé par de la saleté") a été introduit qui permet de déceler les noyaux qui utilisent les pilotes de la branche -staging.
- L'infrastructure de traçage de bas niveau a été intégrée dans le noyau 2.6.28.
Depuis plusieurs années les développeurs sont conscients qu'un des points à améliorer dans le noyau Linux est l'infrastructure de traçage des événements. Solaris mène la danse avec DTrace et Linux est en retard sur ce sujet et, même si les candidats sont nombreux (ftrace, LTTng, SystemTap, Tracepoints, etc), aucun vainqueur clair n'a encore émergé. Lors du dernier sommet Linux de septembre il a été décidé qu'un des premiers pas pour améliorer la situation serait de créer une interface de bas niveau sur laquelle viendraient se brancher tous les candidats. Au moins cela éviterait la duplication du travail et les diverses solutions devraient donc utiliser un seul mécanisme de collecte des traces et d'envoi vers l'espace utilisateur. Le gros avantage, outre le regroupement des efforts, est que ce tampon unifié des traces permet d'utiliser simultanément plusieurs solutions de traçage ce qui permet de combiner leurs qualités respectives afin d'avoir une meilleure vue des événements en train de se dérouler dans le noyau.
La création de cette infrastructure de traçage de bas niveau a été techniquement complexe car il a fallu utiliser tous les "trucs" techniques possibles et imaginables afin d'avoir la plus grande efficacité et d'éviter de perturber le fonctionnement normal du noyau qu'il s'agit d'observer. Le tampon circulaire de traçage est donc éclaté en un ensemble de petits tampons par processeurs qui permettent l'addition d'événements sans poser de verrous. Le format de stockage de ces événements est très compact et il n'est jamais copié pour éviter toute surcharge de travail, etc.
Avec cette solution unifiée maintenant en place on peut dire que le travail de bas-niveau est maintenant terminé. Ne reste plus qu'à améliorer le fonctionnement et la facilité d'utilisation des outils de traçage de haut niveau...
- Avec le noyau 2.6.28 il est maintenant possible de "congeler" des groupes de processus afin, par exemple, de gérer des ensembles de batchs sur un cluster.
Cette fonction se base sur l'infrastructure Control Group (introduite dans le noyau 2.6.24) et sur le code de mise en hibernation Swsusp. La première étape consiste à monter son système de fichiers avec l'option freezer ce qui crée un fichier freezer.state qui sera utilisé pour spécifier l'action à accomplir. Par défaut cette action est positionnée sur RUNNING pour tous les processus du groupe de contrôle mais il suffit, comme l'explique le message de commit, d'un echo FROZEN > /containers/0/freezer.state pour "congeler" les processus si on veut procéder à une suspension de l'exécution d'un groupe de contrôle.
- Le patch des timers haute résolution avec fenêtre temporelle (Range hrtimers) est entré dans le noyau 2.6.28.
Le nom peut sembler barbare mais le bénéfice qu'en retire l'utilisateur sera sans doute substantiel puisqu'il s'agit ne pas "réveiller" trop souvent le microprocesseur afin d'économiser de l'énergie. Diverses fonctions (select() et poll() entre autres) du noyau Linux permettent à une application d'attendre qu'une ressource soit disponible. Ces fonctions utilisent un paramètre pour fixer la limite du temps d'attente mais, bien souvent, il importe peu que la tâche soit effectuée précisément au moment spécifié. Le patch proposé par Arjan van de Ven permet de spécifier non plus une limite de temps d'attente mais une fenêtre de temps d'attente. Ainsi la limite basse (soft timeout) sera utilisée pour spécifier le début de la période d'attente et la limite haute (hard timeout) marquera la fin de cette période.
Pour implémenter cela il a fallu modifier la façon dont fonctionnent les timers haute résolution de Linux en ajoutant les nouvelles fonctions hrtimer_set_expires_range et hrtimer_get_softexpires. Par défaut les soft et hard timeout sont identiques ce qui permet de maintenir le comportement précédent pour ceux qui ne veulent pas utiliser ces nouvelles fonctions. Les applications désireuses de profiter des timers haute résolution avec fenêtre temporelle pourront spécifier la période souhaitée et le noyau optimisera ainsi son fonctionnement. N'étant plus obligé de servir l'application à un moment très précis le noyau peut regrouper plusieurs tâches et les traiter en une seule fois ce qui ne réveille qu'une fois le processeur qui va passer le reste de son temps à "dormir" dans un des modes d'économie d'énergie.
- La couche en mode bloc du noyau Linux 2.6.28 a été largement améliorée en prévision de l'arrivée des disques SSD. La bibliothèque libata, qui est utilisée pour le support des controlleurs et périphériques ATA dans le noyau, a été modifiée afin de permettre aux disques SSD d'indiquer leur nature. Cela permet aux pilotes libata de transmettre ensuite cette information à la couche générique en mode bloc afin qu'elle puisse améliorer les performances. Ainsi l'ordonnanceur des entrées/sorties n'a plus besoin de prévoir un temps d'attente pour que les têtes de lecture se positionnent et il peut lancer le transfert immédiatement.
D'autre part la couche en mode bloc peut maintenant recevoir, par l'intermédiaire des systèmes de fichiers se trouvant "au dessus" d'elle, l'information indiquant que certains secteurs sont inutilisés. Le système de fichier utilise la nouvelle fonction blkdev_issue_discard pour spécifier les secteurs qui ne sont plus utilisés et qui peuvent être réutilisés. C'est particulièrement important dans le cas des disques SSD qui peuvent ainsi prendre de meilleures décisions quand ils procèdent à la répartition des écritures (Wear levelling).
En bref....
- Un nouveau fichier sysfs fait son apparition. Nommé unload_heads il permet à un processus vivant en espace utilisateur d'indiquer à un disque dur ATA de rétracter ses têtes de lecture. Si on couple cette fonction avec l'utilisation d'un accéléromètre on obtient un mécanisme permettant de préserver les disques durs en cas de chute.
- Le générateur de nombres pseudo-aléatoires (PRNG en anglais) de type ANSI X9.31A.2.4 fait son entrée dans la couche cryptographique du noyau. Ce générateur se base sur les algorithmes bien connus triple-DES et AES.
- Le noyau 2.6.28 se dote d'un visualiseur de boot puisqu'il est désormais possible, si le noyau est compilé avec CONFIG_BOOT_TRACER, de générer des images au format SVG afin de visualiser tous le processus de boot. Cela permet de voir les appels bloquants et d'optimiser le temps de démarrage du noyau.
- L'implémentation générique des verrous d'exclusions (mutex) a été optimisée par Nick Piggin. Le gain est relativement conséquent puisque sur un lock/unlock on passe de 590 cycles processeur à seulement 203 (testé sur un processeur PowerPC 970).
- Les pilotes graphiques Intel et AMD ne déclencheront plus des interruptions en permanence ce qui réveillait le processeur et dépensait inutilement de l'énergie. Maintenant ces interruptions ne seront lancées que lors des attentes de vblank (Vertical blanking interval).
- Phonet, le protocole par paquets créé par la firme Nokia, est entré dans le noyau. Il permet au noyau Linux de recevoir les données émises par les téléphones cellulaires de la marque sous la forme de connexions infrarouges, USB ou Bluetooth.
- Le pilote ath5k des cartes wifi Atheros est maintenant capable de gérer les réseaux maillés (mesh network).
- Tous les pilotes Video4Linux2 ont été modifiés afin que l'utilisation de la fonction open() ne pose plus un verrou global. Ces modifications, pour le plus grand bénéfice du fonctionnement sur des machines multiprocesseurs, n'ont été possibles que pour les pilotes se trouvant dans le noyau. Tous les pilotes extérieurs devront donc être modifiés par les malchanceux développeurs qui n'ont pas encore compris la philosophie de développement de Linux.
- Dans le cadre du projet Linux-Tiny divers patchs destinés à réduire la taille du noyau ont été soumis par Thomas Petazzoni (qui est également modérateur sur LinuxFR).
Le mécanisme des entrées-sorties asynchrones peut maintenant ne plus faire partie du noyau ce qui permet à ceux n'ayant pas l'utilité de ce mécanisme de compiler leur noyau sans cette fonction. Cela représente 7 Ko de moins. Un patch concernant le sous-système PCI permet d'économiser 12 Ko et un autre patch autorise à ne pas compiler la fonction de verrou de fichiers quand elle n'est pas nécessaire. C'est encore 11 Ko de gagné pour les systèmes embarqués toujours à la recherche de la moindre petite économie.
Pour le futur...
- Après l'entrée du gestionnaire de mémoire pour cartes graphiques GEM dans le noyau 2.6.28 la seconde étape sera l'intégration de KMS (kernel-based mode-setting) dès le prochain noyau. Actuellement les modes graphiques sont initialisés lors du démarrage du serveur X. Avec KMS cette initialisation se fera dans le noyau ce qui permettra de nombreuses améliorations : on évite les différentes bascules de modes d'affichage au boot par exemple, le changement d'utilisateur est plus rapide (plus besoin de changer de terminal virtuel), les messages de panique du noyau peuvent être graphiques (fonction surnommée "Blue Penguin of Death"), etc.
À noter que les utilisateurs de la distribution Fedora 10 utilisent déjà par défaut KMS qui a été rétroporté par les développeurs dans le noyau 2.6.27.
- Après la déclaration de stabilité de Ext4 les développeurs réfléchissent à l'inclusion de Btrfs dans le noyau afin de permettre à de nombreux utilisateurs de tester et de rapporter les bugs. La procédure serait la même que celle qui a été employée pour Ext4 c'est à dire qu'un avertissement très clair serait affiché pour indiquer que Btrfs est en développement et ne dois pas être utilisé pour autre chose que pour des tests. C'est l'auteur de Btrfs, Chris Mason, qui a proposé cette inclusion rapide sur la liste de diffusion du noyau. Cette proposition a été chaudement soutenue par Andrew Morton : "J'ai encouragé Chris à proposer Btrfs pour inclusion. L'envoyer dans Linux-next aussi vite que possible et l'inclure dans le 2.6.29. Mon idée est que Btrfs a probablement un brillant avenir et qu'une inclusion rapide permettra d'accélérer son développement et d'augmenter sa base de contributeurs. Si pour une raison ou une autre ça foire nous pourrons toujours le supprimer. Pour diverses raison cette approche n'est pas recommandée en tant que politique par défaut mais je pense que Linux a besoin depuis un certain temps d'un nouveau système de fichiers et Btrfs pourrait bien être Celui Là. Cela vaut bien un traitement spécial".
Aller plus loin
- Les nouveautés du noyau 2.6.28 (28 clics)
- Le bilan des ajouts partie 1 (1 clic)
- Le bilan des ajouts partie 2 (0 clic)
- Le bilan des ajouts partie 3 (1 clic)
- Les prévisions pour l'avenir de Linux (4 clics)
# Now Hell
Posté par Vincent (site web personnel) . Évalué à 10.
# Grand merci à patrick_g
Posté par YLD . Évalué à 10.
[^] # Re: Grand merci à patrick_g
Posté par Pierre Alain B. . Évalué à 3.
[^] # Re: Grand merci à patrick_g
Posté par jujubickoille . Évalué à 2.
Excellent travail, comme d'habitude =)
[^] # Re: Grand merci à patrick_g
Posté par Dup (site web personnel) . Évalué à 2.
[^] # Re: Grand merci à patrick_g
Posté par rpnpif . Évalué à -8.
[^] # Re: Grand merci à patrick_g
Posté par windu.2b . Évalué à 9.
[^] # Re: Grand merci à patrick_g
Posté par rpnpif . Évalué à -2.
# HUmm ?
Posté par Kévin Belliz . Évalué à 2.
Bah c'est la 2.26.28 ? ou 2.26.29 ? *-)
Sinon Merci pour ce super résumé :)
[^] # Re: HUmm ?
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 10.
Es-tu développeur ?
[^] # Re: HUmm ?
Posté par Kévin Belliz . Évalué à 5.
Oui oui je suis "développeur" ( Amateur pour le moment on va dire ^^ ) Je vois très bien ce principe de compter à partir de Zéro héhé !
[^] # Re: HUmm ?
Posté par Anonyme . Évalué à 9.
[^] # Re: HUmm ?
Posté par KiKouN . Évalué à 2.
# Une petite coquille
Posté par Ambroise . Évalué à 2.
Une petite erreur dans le dernier chapitre : le Kernel-based Mode Setting, j'aurais plutôt mis KMS et non KSM.
[^] # Re: Une petite coquille
Posté par Maxime (site web personnel) . Évalué à 2.
Très bon article comme d'habitude. Merci Patrick !
# GEM précisions
Posté par glisse . Évalué à 10.
[^] # Re: GEM précisions
Posté par IsNotGood . Évalué à 1.
Oui et non. Les choses restent encore très ouvertes et/ou floues (en tout cas pour moi).
Certes GEM est insuffisant pour d'autres cartes graphiques. Mais Intel n'a jamais été contre des ajouts à GEM afin de l'accomoder à d'autres cartes graphiques.
TTM permettait de contenter les besoins de beaucoup de cartes graphique. Mais il était peu utilisé...
[^] # Re: GEM précisions
Posté par med . Évalué à 6.
Il me semble pourtant que nouveau et radeon (hd?) utilisaient TTM. Seul intel utilisait GEM donc il était encore moins utilisé. Par contre je pense que comme les besoin d'intel étaient plus faibles GEM était plus simple à intégrer dans le noyau, dont acte et TTM se retrouve le bec dans l'eau. Radeon doit utiliser une API GEM tout en restant TTM en interne si je ne m'abuse. Je suis curieux de voir comment ça va finir. Le chantier de ravalement de la partie graphique de linux dure depuis pas mal de temps maintant j'espère qu'on va bientôt enfin voir les résultats concrets et pas seulement pour intel. Vivement que KMS, VA API, DIR2 et gallium3D (et j'en oublie) tournent sur toutes les cartes ! Cependant ce petit test chez phoronix m'inquiète un peu http://www.phoronix.com/scan.php?page=article&item=intel(...) . J'espère que l'explication est que tout a été compilé avec -O0 …
[^] # Re: GEM précisions
Posté par Gwenole Beauchesne . Évalué à 2.
[^] # Re: GEM précisions
Posté par herodiade . Évalué à 4.
[^] # Re: GEM précisions
Posté par IsNotGood . Évalué à 1.
Je ne prétend pas être un spécialiste en carte graphique et OS. J'ai simplement lu que GEM n'était pas destiné à être uniquement pour les cartes Intel. Il me semble bien avoir lu Dave Airlie disant que GEM présentait un intérêt pour ATI (et que certains drivers ATI utilisé GEM (en plus de TTM). Peut-être GEM ne sera utilisé que par les cartes Intel.
Si tu veux dire qu'il est plus sage de prendre en compte les propres de glisse et ignorer les miens, je suis d'accord.
[^] # Re: GEM précisions
Posté par glisse . Évalué à 6.
Après, pour les générations futures le problème est encore plus compliqué (enfin plus simple d'un certain côté), les nouvelles cartes ont un MMU qui peut générer des pagefault, on se rapproche donc d'une gestion comme sur le CPU et la l'interface GEM c'est peut être pas ce qu'on voudra.
# Très bonne news !
Posté par verdesroches (site web personnel) . Évalué à 3.
Trêve de plaisanterie, news très bien faite et bien expliquée, comme d'hab :) . Merci aussi de nous faire partager l'humour de geek de Linus, ça me fait toujours bien rire, on en redemande ;-) . J'm'inscrirais bien sur la mailing list de Linux pour en profiter en temps réel, mais bon, je n'aurais jamais le temps de tout lire...
# Course à l'innovation
Posté par jmelyn . Évalué à 10.
Cette course effrénée à l'innovation va épuiser tous les concurrents de Linux. Comment en effet suivre un OS développé par de plus en plus de programmeurs? Il existe encore des domaines où Linux est souvent modifié comme les très gros serveurs, mais les améliorations régulières rendent ces modifications de moins en moins nécessaires. Lorsque l'on compare Linux à Windows XP sorti en 2001 et encore largement utilisé sept années plus tard avec bien peu de changements fonctionnels, la différence est flagrante. Je ne peux imaginer Linux dans sept ans!
C'est donc avec plaisir que je retrouve les explications de patrik_g tous les trois mois pour constater les changements.
[^] # Re: Course à l'innovation
Posté par liberforce (site web personnel) . Évalué à 5.
Exemple récent: http://bugzilla.kernel.org/show_bug.cgi?id=11727
[^] # Re: Course à l'innovation
Posté par IsNotGood . Évalué à 7.
Quelle bande de branleur ces développeurs Linux... On entend ça depuis des années (rapport de bug à l'appuis).
> Parce que depuis le changement de modèle de développement, la qualité en a pris un coup quand même...
Ben prend un 2.4 ...
Pourquoi tu prends un 2.6 si tu en penses du mal ?
Le nouveau modèle de développement est connu depuis un bon moment. Il est plébicité par les développeurs. Si tu veux une distribution rock-solid, ben il ne faut pas prendre une distribution blending edge. Tu veux le beurre et l'argent du beurre.
En passant, il semble que le bug que tu pointes a été corrigé dans Linux 2.6.28.
[^] # Re: Course à l'innovation
Posté par liberforce (site web personnel) . Évalué à 6.
2. Je n'ai jamais dit que c'étaient des branleurs
3. Je pointe un problème qui, que tu le veuilles ou non, existe.
Le nouveau modèle de développement amène plus de nouveautés, mais aussi plus de régressions, sur des versions supposées stables. Le kernel laisse la stabilisation finale du kernel aux distributeurs, et je trouve cela un peu problématique... Certains utilisateurs de distributions Linux (et je fais partie de ceux là) pointent le fait qu'il est très dur d'avoir une distrib qui est stable et sans trop de bug. Pour corriger certains bugs, tu t'entends répondre "t'as qu'à upgrader". Sauf que la version n+1 de ta distrib corrige bien ton problème, mais casse autre chose au passage. L'upgrade n'est donc pas une solution, elle ne fait que reporter le problème. Et si un bug a été introduit en 2.6.27 et que le correctif existait avant la sortie du 2.6.28, tu dois quand même passer au 2.6.28, quitte peut être à casser autre chose... Je t'avoue que je n'ai pas compris que ce genre de bug grossier ait pu passer au travers des mailles de la validation...
[^] # Re: Course à l'innovation
Posté par jmelyn . Évalué à 0.
Par contre, je suis très heureux de voir le graphisme s'améliorer, la gestion de la mémoire faire des progrès, ext4 arriver, les hrtimers prendre soin de la batterie des portables, les SSD pris en compte. Et ce en une seule version.
Je crois que BSD, à travers FreeBSD, OpenBSD et NetBSD sont plus orientés vers la stabilité, la sécurité. Mais la performance et l'évolution sont un peu moins bonnes. Question de choix.
[^] # Re: Course à l'innovation
Posté par IsNotGood . Évalué à 2.
Merci.
> 2. Je n'ai jamais dit que c'étaient des branleurs
Mouaif... Tu dis "seulement" qu'ils ne sont pas foutus de corriger les bugs...
Mais admettons.
> 3. Je pointe un problème qui, que tu le veuilles ou non, existe.
Quel problème ? Un bug... Les logiciels de cette taille/complexité ont toujours des bugs.
Qu'en logiciel on n'a jamais assez de moyen ?
Ben oui, on n'a jamais assez de moyen. Avec les moyens disponibles, il faut faire un compromis entre ce qui est affecté au développement et ce qui est affecté à la maintenance. Et en fait dans le logiciel libre (sur la base du volontariat), tu ne peux pas décider. S'il y a beaucoup de personne pour participer au développement, ben il y aura beaucoup de ressource pour le développement. S'il n'y a presque personne pour la maintenance, ben il n'y aura presque personne. Pour kernel.org, c'est principalement du développement. Et les développeurs tu ne vas pas les faire poiroter durant des moins à uniquement corriger des bugs obscures. Enfin, les développeurs ne sont pas à ta botte.
> Le nouveau modèle de développement amène plus de nouveautés, mais aussi plus de régressions
Ben le passage de 2.4 à 2.6 n'a pas été une merveille et il a fallu attendre de long mois pour avoir quelque chose de correcte (idem de 2.2 à 2.4). Ceci avant que le "nouveau modèle de développement" n'arrive.
> sur des versions supposées stables.
Quel est ta définition de "stabilité" ?
Un 2.6.26 ou 2.6.27 ou 2.6.28 ou 2.6.x est un noyau stable ! D'ailleurs il y a une équipe (Greg K-H) pour corriger les noyaux stables. Le 2.6.27.10 est sorti il y a quelques jours. Pas d'ajout de fonctionnalité, pas d'API cassée, dans les 2.6.x.y il n'y a que des corrections de bug.
> Le kernel laisse la stabilisation finale du kernel aux distributeurs, et je trouve cela un peu problématique... Certains utilisateurs de distributions Linux (et je fais partie de ceux là) pointent le fait qu'il est très dur d'avoir une distrib qui est stable et sans trop de bug.
Faux problème. Ces distributions promettent ce qu'elle ne peuvent tenir. Ses utilisateurs se font avoir. Maintenant espérons qu'ils n'aient pas la bêtise de jeter la faute sur les développeurs (kernel.org).
Tu veux du rock-solid, prends une RHEL (ou une Centos si tu n'as pas de tune). Pour info, le support par version est passé à 10 ans ! Le tout reste compatible source et binaire. C'est "merveilleux", mais ce n'est pas gratuit (ben oui, Red Hat ne promet pas ce qu'il ne peuvent pas tenir, s'il faut du pognon, du pognon sera demandé). Ce n'est pas gratuit car pratiquement personne ne veut travailler gratuitement à seulement maintenir des sources.
On peut dire que les Fedora, Mandriva et autres Ubuntu ont un support trop court et des changements d'API trop fréquents. Mais ce n'est pas de la faute aux développeurs sur kernel.org. Ils sont là pour développer, pour faire évoluer le noyau. Pas pour faire une distribution à la RHEL ou SLE.
En passant, Fedora avait lancé le projet Fedora Legacy. Ben il a été abandonné car ça n'intéressait presque personne d'y participer.
Faut arrêter de croire que le logiciel libre a des ressources infinies (pour 0 €) et peut tout faire.
Si tu veux dire que les ressources bénévoles pour Linux sont insuffisantes (notamment pour ce qui lié à la maintenance), je suis d'accord. Mais je ne vois pas en quoi ça remet en cause le nouveau modèle de développement de Linux (qui n'est pas là pour faire de la maintenance).
On peut aussi dire que les utilisateurs d'Ubuntu, Fedora, etc sont des pingres qui veulent tout à 0 €. Le logiciel libre, comme tout logiciel, a un coût. Si tu veux améliorer le logiciel libre : participes ou casses ta tirelire.
J'utilise Fedora depuis FC1. Oui, ça merde parfois. Mais je suis content d'avoir le dernier cri. Je trouve remarquable (je pèse le mot) la qualité de Fedora (on peut probablement dire de même pour Ubuntu, Mandriva, OpenSuse, etc) compte tenu des développements qui y ont lieu.
Un fois ma carte tv n'a plus marché durant 2 mois après une mise à jour. Ben c'est la vie, je n'ai rien payé.
> Je t'avoue que je n'ai pas compris que ce genre de bug grossier ait pu passer au travers des mailles de la validation...
Mais combien de bug sont corrigés... Probablement des centaines, mais tu fais une fixation sur LE bug qui n'a pas été corrigé. Le compromis ressources/innovation/qualité de Linux est tout simplement exceptionnel.
Ici j'ai une F10 avec système de fichier en ext4. Je sais que je prend des risques et devrait attendre avant d'utiliser ext4. Mais que veux-tu, je suis comme toi : un petit con qui veut du bleeding edge.
> Certains utilisateurs de distributions Linux
Ces même distributions qui ne participent pratiquement pas en upstream à Linux... Faut pas s'étonner de les voir jeter la pierre au développeur upstream...
[^] # Re: Course à l'innovation
Posté par liberforce (site web personnel) . Évalué à 5.
Merci de savoir ce que je veux mieux que moi. Moi je veux juste un truc qui marche quand c'est déclaré stable.
[^] # Re: Course à l'innovation
Posté par Rémi Birot-Delrue . Évalué à -3.
[^] # Re: Course à l'innovation
Posté par mansuetus (site web personnel) . Évalué à 4.
Et je préfère (moi) avoir le 2.6.28 ce jour, plutot qu'il sorte à la date (hypothétique) de la sortie du 2.6.28.9.
Chaque distrib peut ensuite faire son choix.
# Whaouu
Posté par Snarky . Évalué à 3.
...
Ha ben si !! C'est noël !
[^] # Re: Whaouu
Posté par Rémi baudruche . Évalué à 4.
Sait tu comment fonctionne un ecrant LCD ?
En simplifiant, tu as une lampe derrière et des filtres qui bloquent ou non la lumière. En conséquence il n'y a aucune différence de consomation entre un ecran tout blanc ou un ecrant tout noir. Du moment que l'écran est allumé, il consomera toujours autant autant.
la seule solution pour réduire la consomation d'un écran est de diminuer la luminositée ou de l'éteindre
amicalement et joyeux noël à tous
Rémi
[^] # Re: Whaouu
Posté par briaeros007 . Évalué à 2.
Maintenant dans la version "réel", il y a de plus en plus d'écran qui diminue ou augmente la luminosité du rétro éclairage pour s'adapter à ce qui est affiché.
Cela permet d'augmenter artificiellement le taux de contraste et donc d'avoir de meilleur perfs 'technique'.
[^] # Re: Whaouu
Posté par Rémi baudruche . Évalué à 3.
parce que le rétro éclairage est me semble t'il uniforme sur l'écran,
donc si le rétroéclairage change pour afficher une page noir, ça voudrai dire que la luminositée de la bare de tache (par exemple) vas baisser également.
Ce qui me semblerai absurde.
As tu des sources pour expliquer ce que tu dis ?
[^] # Re: Whaouu
Posté par tiot (site web personnel) . Évalué à 2.
Pas forcément, tu peux en même temps augmenter la transparence des pixels de la barre des taches.
Il y a aussi des éclairages à LED (pour les télévisions LCD haut de gamme) qui permet d'éclairer seulement certaines zones de l'écran. Les zones sombres sont moins éclairées que les zones claires, d'où une augmentation du contraste.
[^] # Re: Whaouu
Posté par Rémi baudruche . Évalué à 1.
Pas forcément, tu peux en même temps augmenter la transparence des pixels de la barre des taches.dans ce cas là tu elimine les couleurs les plus lumineuses, les blanc deviendra moins blanc. Le blanc c'est déja le niveau maximum de transparence, tu peut pas avoir plus. A moins que tu lave plus blanc que blanc :-)
Il y a aussi des éclairages à LED (pour les télévisions LCD haut de gamme) qui permet d'éclairer seulement certaines zones de l'écran. Les zones sombres sont moins éclairées que les zones claires, d'où une augmentation du contraste.à moins qu'il y ai une led derière chaques pixels ce deviendrai un écrant a led et non plus un ecran LCD alors chaques led éclaire donc un ensemble de pixels, donc tu ne pourrai baisser que la luminositée d'une zone d'une forme prédeffini... ça me semble très difficile à gerrer sans perdre de la qualitée.
Mais si tu as des document qui m'explique que j'ai tors je suis prenneur
[^] # Re: Whaouu
Posté par briaeros007 . Évalué à 2.
C'est surtout que j'ai un écran qui a ce genre d'artifice ;) (et ça se voit pas trop, je crois que je l'ai aperçu une seule fois!)
http://en.wikipedia.org/wiki/Display_contrast#Dynamic_contra(...)
L'idée derrière c'est que lorsque tu affiche une image très noir sans pixel "très lumineux", dans ce cas tu peux diminuer le backlight pour avoir un noir plus "profond" , tout en modifiant aussi les réglages de contraste de l'écran pour respecter l'image.
(pour la techno utilisé dans mon écran : http://en.wikipedia.org/wiki/Digital_Fine_Contrast )
[^] # Re: Whaouu
Posté par claudex . Évalué à 2.
De plus, pour en revenir au sujet de départ, je me demande si la différence de consommation est significative.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Whaouu
Posté par claudex . Évalué à 4.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Whaouu
Posté par briaeros007 . Évalué à 2.
# Yeeepeeee §!
Posté par Rémi Birot-Delrue . Évalué à -7.
Joyeux aaaanniiiveeeeersaiiiiire !
Joyeuux aaaaaanniiiiiiiiveeeersaiiiiire <Jesus/Mahomet/Buddah/Linus/RMS/any other prophet> !
Joyeux aaaanniiiiiveeeeersaiiiiiire §!
# Demande de précision..
Posté par Grunt . Évalué à 2.
Est-ce que ça veut dire que le noyau Linux, par défaut, s'occupera de brider les chipsets Wifi? Sera-t-il possible de contourner toutes les limitations, sans re-compiler, ou en re-compilant, afin d'utiliser toutes les possibilités du matériel? Je n'arrive pas à savoir dans quel sens va cette intégration, s'il s'agit de plus de liberté, ou de moins de liberté.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Demande de précision..
Posté par Boa Treize (site web personnel) . Évalué à 2.
(Ce qui inévitablement, facilitera son non-respect par ceux qui le veulent. Non pas que c'était bien difficile à contourner auparavant.)
[^] # Re: Demande de précision..
Posté par Grunt . Évalué à 2.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Demande de précision..
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 2.
Dès lors je ne vois aucune raison (techniquement) qui devrait t'empêcher de désinstaller ce programme (dans le cas ou il serait installé par défaut par ta distro) et donc de faire sauter le blocage.
# compatible avec Ext3
Posté par IsNotGood . Évalué à 2.
Mouaif. Ext4 (le code du noyau) peut utiliser du ext3. Mais ext3 ne peut pas monter de partition ext4 et il n'y a pas d'outils pour convertir une partition ext4 en ext3.
Actuellement, et à ma connaissance, la compatibilité est uniquement ascendante. Une fois passé à ext4, c'est "trop tard".
[^] # Re: compatible avec Ext3
Posté par Boa Treize (site web personnel) . Évalué à 3.
Ou alors si tu n'as pas l'espace disque, et si tu as confiance dans ton disque dur externe, tu reformattes et tu recopies depuis ton disque dur externe de backup.
[^] # Re: compatible avec Ext3
Posté par IsNotGood . Évalué à 2.
[^] # Re: compatible avec Ext3
Posté par FantastIX . Évalué à 2.
C'est déjà pas mal que le code noyau EXT4 puisse monter un système en EXT3. J'avais cru lire à l'époque que EXT3 et EXT4 serait incompatibles. Mais bon, tu as lu ce qu'expose Boa Treize; suffit de considérer EXT4 comme «juste un autre système de fichiers», au même titre que ReiserFS, XFS, JFS ou 3615QuiNenVeutFS...
Et puis, pour ma part, j'estime que tar est le meilleur outil de conversion qu'on ait jamais inventé, puisqu'il fonctionne aussi avec des systèmes de fichiers qui n'avaient pas encore été inventés à cette époque. Que demande le peuple? ;-)
[^] # Re: compatible avec Ext3
Posté par IsNotGood . Évalué à 2.
Ils sont incompatibles pour le format sur disque. Ça a été annoncé, c'est comme ça aujourd'hui. Le "pilote" ext4 prend en compte ext3 pour facilité la montée en version. Mais ext3 ne pourra jamais lire du ext4.
Concrètement si je te donne une clé USB formatée avec ext4 et que tu n'as "que" du ext3, tu ne pourras pas lire ma clé USB.
Donc quand on annonce qu'ext4 est compatible avec ext3, il faut y aller avec des pincettes.
> Et puis, pour ma part, j'estime que tar est le meilleur outil de conversion qu'on ait jamais inventé
Je préfère rsync (sauf si le FS de backup n'est pas un FS digne de ce nom). Question de gout peut-être.
[^] # Re: compatible avec Ext3
Posté par Octabrain . Évalué à 2.
# A propos du tracing
Posté par fweisbec . Évalué à 10.
ftrace, Lttng, et systemtap sont présentés ici comme étant en compétition, or c'est faux, ils sont complémentaires. Et ils ont des rôles différents.
ftrace permet d'appliquer une fonction qui hooke quasiment toutes les fonctions du kernel. C'est lourd mais complet, tandis que les tracepoints ne s'appliquent qu'à des fonctions particulières.
Remarquez, ftrace permet aussi de ne tracer que certaines fonctions mais c'est un truc à régler côté utilisateur.
En somme les tracepoints sont prévus pour du débuggage chirugical. On vise une ou quelques fonctions mais c'est tout.
ftrace est plutôt prévu pour tracer massivement, ou tracer seulement certaines fonctions à partir de certains critères (du style avec expression régulière, en choisissant tel préfixe ou suffixe, ou encore tracer uniquement une tâche etc....)
Les tracepoints font partie du projet LTTng.
Pour ce qui est de systemtap c'est encore différent, il s'agit de scripts que l'on peut produire côté utilisateur et donc les instructions sont executées côté kernel.
Si vous êtes interessés, pour plus de détails, je vous conseille une interview de Mathieu Desnoyers: http://www.linuxfoundation.org/events/node/153 qui explique bien le caractère complémentaire de ces 3 systèmes.
Et enfin concernant le ring buffer, il n'est pas encore sans vérrou :-)
Il utilise des spinlocks en interne lors de l'insertion d'un évenement.
Et il ne le sera pas non plus pour le 2.6.29, par contre il y a de grandes chances pour 2.6.30 :-)
[^] # Re: A propos du tracing
Posté par FantastIX . Évalué à 1.
[^] # Re: A propos du tracing
Posté par fweisbec . Évalué à 5.
Au démarrage du noyau, ajoute le paramètre initcall_debug.
Après démarrage, monte un repertoire debugfs:
mount -t debugfs /debug debug
Ensuite rends toi dans le repertoire scripts des sources de ton noyau, puis:
bootgraph.pl < /debug/tracing/trace > mon_graph.svg
Et hop tu peux afficher ton svg avec ce que tu veux, Gimp, Firefox tc.... Dedans tu y verras un graph de boot....qui ne concerne que l'intérieur du noyal bien entendu!A savoir les différentes parties du noyau qui s'initialisent...
[^] # Re: A propos du tracing
Posté par fweisbec . Évalué à 2.
[^] # Re: A propos du tracing
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: A propos du tracing
Posté par fweisbec . Évalué à 2.
# Captures d'écran du visualiseur de boot
Posté par koxinga . Évalué à 4.
http://www.fenrus.org/before.svg
http://www.fenrus.org/after.svg
[^] # Re: Captures d'écran du visualiseur de boot
Posté par fweisbec . Évalué à 4.
Le but étant en fait d'analyser ce qui se passe lorsque fasboot est activé.
Fastboot étant une fonctionnalité du noyau permettant aux fonctions d'initialisation (initcalls) du
noyau de s'executer de manière de manière asynchrone, c'est à dire en même temps en quelques sortes, plutôt que de les executer les unes après les autres.
Par exemple quand un initcall bloque/dort en attente d'une opération d'entrée sortie, ou une allocation mémoire etc... ça permet à un autre initcall de prendre la main sur le processeur, permettant ainsi de gagner du temps sur la suite au lieu de laisser le processeur se tourner les pouces.
# Recompiler la glibc avec les nouveau headers linux...
Posté par blubliblo . Évalué à 4.
# Integration du pilote touchpad Elantech
Posté par Erwan . Évalué à 3.
http://arjan.opmeer.net/elantech/
Ca va enfin nous permettre d'utiliser Synaptics sur les EEEPC :)
D'ailleurs s'il y a des gens de Mandriva qui lisent: s'ils vous plait, compilez le noyau de façon à ce que ce pilote soit disponible ! Au moins pour 2009.1...
# Enfin !!
Posté par Grunt . Évalué à 3.
Premier constat: ça démarre un peu plus vite. Toujours bon à prendre.
Deuxième constat: "RMS would be proud".. plus de blop binaire pour le chipset Atheros. Et le pilote libre "ath5k" est d'excellente qualité !!
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.