Nouvelle version 2.6.34 du noyau Linux

Posté par patrick_g (site web personnel) le 17 mai 2010 à 12:57. Modéré par Nÿco.

Étiquettes :

mai

2010

La sortie de la version stable 2.6.34 du noyau Linux vient d'être annoncée par Linus Torvalds. Le nouveau noyau est, comme d'habitude, téléchargeable sur les serveurs du site kernel.org.

Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche (qui est sous licence CC BY-SA).

Le sommaire...

La phase de test
- RC-1
- RC-3
- RC-4
- RC-5
- RC-6
- RC-7
Les nouveautés
En bref
Une flame war d'un fort beau gabarit
Le bilan en chiffres
Pour la suite

La phase de test (↑)

RC-1

Comme il l'avait annoncé lors du cycle précédent, Linus a décidé de fermer la période de merge plus tôt que d'habitude. Le plan était de donner une leçon en claquant la porte au nez des récalcitrants qui persistaient à envoyer leurs patchs au tout dernier moment. C'est donc seulement 11 jours après la sortie du noyau 2.6.33 que la version RC-1 a été annoncée :
« Voilà c'est dispo maintenant. J'ai encore quelques branches pour lesquelles j'ai des demandes de pull et que je veux scruter d'un peu plus près (ceph, branche gdb, etc) et il est possible que j'ai laissé passer quelques autres demandes. Si vous pensez que vous avez été oublié alors faites-moi signe, mais à part ça la période de merge est terminée.
Comme promis si vous pensiez attendre le dernier jour de la fenêtre des 15 jours pour envoyer votre demande eh bien maintenant vous devrez attendre le 2.6.35.
Plus ou moins 850 développeurs ont contribué jusqu'à présent, plus de 6 500 fichiers modifiés, plus de 400 000 lignes ajoutées et environ 175 000 supprimées. En d'autres termes trop de trucs pour en faire un résumé.
Un truc qui m'a impacté, comme ce sera sans doute le cas pour d'autres personnes, c'est qu'en cas d'utilisation de Nouveau vous devrez aussi installer les nouvelles versions de libdrm/nouveau_drv.
À part ça si quelque chose ne marche pas c'est le moment de brailler ! ».

Certains développeurs se sont fait avoir par la fermeture précoce de la période de merge et, naïfs comme ils sont, ils ont protesté auprès de Linus en soulignant que la date de fin était devenue imprévisible. Bien entendu la seule réponse de Linus a été un tonitruant "THAT WAS THE WHOLE F*CKING POINT!" (que je traduirai poliment en "Cher ami, c'était bien le but de la manœuvre").

RC-2

Assez curieusement Linus a rendu disponible la version candidate RC-2 sans l'accompagner d'un mail descriptif comme il en a l'habitude en temps normal. En fouillant la liste de diffusion du noyau on trouve quand même une explication dans un autre de ses mails :
« Désolé pour le long délai. J'ai passé 5 jours à assister à deux présentations Intel lors des 2 dernières semaines et cela a monopolisé une bonne part de mon temps ».

Cette absence temporaire ne l'a pas empêché de déployer toute sa verve quand il a eu à analyser les patchs qui lui avaient été soumis en son absence:
« Je _déteste_ absolument quand je vois du code de compatibilité pour une fonction qui vient juste d'être ajoutée. Ma réaction immédiate c'est What The Fuck ? Quelle sorte d'abruti ne prendrait même pas la peine d'écrire dès le début un code compatible 64 bits ? Il faut juste que l'interface fonctionne proprement au lieu d'ajouter cette couche de compatibilité merdique ».

RC-3

C'est dans le mail de la version RC-3, le 30 mars dernier, que Linus s'est expliqué sur ses décisions concernant les deux versions candidates précédentes et sur le fait qu'il avait finalement été magnanime en acceptant les patchs tardifs:
« OK, donc la RC-2 a été bordélique, aucun doute là-dessus. Je suis trop tendre pour bloquer le travail de gens donc ma tentative de donner une bonne leçon lors de la RC-1 n'a pas vraiment fonctionné comme je l'espérais. Mais la _prochaine_ fois ! Attention à vous cette fois !
Bon de toute façon, à partir d'une RC-2 bordélique nous avons maintenant une RC-3 qui devrait être en bien meilleur état. De nombreuses régressions sont corrigées et le shortlog est suffisamment court pour être posté sur la liste de diffusion ».

Linus évoque ensuite un important bogue potentiel pour les utilisateurs de SELinux sous Ext3 qui auraient utilisé les versions candidates précédentes. Il explique comment corriger la corruption des labels de sécurité et conclut enfin qu'il est peu probable que ce bug touche beaucoup de monde:
« Bien entendu je suspecte que la plupart des gens qui font tourner des noyaux expérimentaux sont aussi ceux qui ont désactivé SELinux il y a longtemps tellement c'est emmerdant. Ou bien que ces personnes ont probablement fait le saut vers Ext4 (qui n'a pas le bug) depuis des lustres...mais bon qu'est-ce que j'en sais après tout ? ».

RC-4

Après la RC-3 il a fallu attendre deux longues semaines pour que Linus annonce le 12 avril la sortie de la quatrième version candidate. Ce retard s'explique par un bug mystérieux détecté dans la RC-3:
« Cela fait deux semaines au lieu d'une comme d'habitude parce que nous avons chassé une régression vraiment ennuyeuse dans le code de la mémoire virtuelle et que je ne voulais pas sortir la RC-4 avec ce bug.
Des _super_ remerciements pour Borislav Petkov qui a signalé le problème et qui non seulement a été capable de le reproduire de façon régulière mais aussi de tester immédiatement de nouveaux patchs pour isoler le bug. Ce truc nous a pris dix jours d'aller-retours d'emails et Borislav a été disponible en permanence, jour et nuit, pour nous aider à trouver la cause du problème ».

Pour ceux qui seraient curieux au sujet du bug vicieux évoqué par Linus, le site LWN a publié un article explicatif (dose d'aspirine fortement recommandée). Comme le dit l'article de façon imagée cette chasse au bug a été intense et compliquée: "the most intensive head-scratching which has been seen on the list".
Ce que Linus ne dit pas dans son message de RC-4 c'est que c'est lui, parmi tous les autres développeurs chassant le bug, qui a finalement trouvé l'origine du problème. Après des espoirs déçus à la suite de la correction d'autres bugs sans que le problème d'origine ne disparaisse, il a semblé sur le point de se résigner au retour arrière sur tout le patch.
Dur, dur quand même de jeter l'éponge après une telle chasse: « Je détesterai avoir à faire un revert sur tout le patch du fait des heures que j'ai passé à lire ce code (au point que je pense même le comprendre) ».
N'étant pas touché par le oops il n'a pas pu tester lui-même ni déboguer directement. Il a dû se contenter de lire le code gérant la mémoire virtuelle et regarder le contenu des registres du dump posté par Borislav pour imaginer d'où pouvait bien venir ce problème qui mystifiait tous les développeurs. Ayant des super-pouvoirs il a fini par se douter de l'origine du oops et il a proposé une théorie explicative à laquelle personne d'autre n'avait pensé et qui s'est révélée parfaitement correcte.

RC-5

Avec l'annonce de la RC-5 du 19 avril dernier on est revenu à une situation plus normale:
« Nouvelle semaine, nouvelle RC. Cette fois il n'y a pas eu de grosse régression bien vilaine sur laquelle se pencher et c'est juste une RC tout à fait classique. Des petites corrections un peu partout. La plus notable pour les gens qui ont eu le problème est une correction pour les soucis de boot (Problème de division par zéro dans ACPI: Bugzilla du noyau 15749)...mais il y a des patchs pour plein d'autres trucs ».

RC-6

C'est dans la version RC-6 du 29 avril que Linus a, entre autres choses, dévoilé le nouveau nom de code du noyau. Fidèle a son habitude d'utiliser des noms d'animaux absurdes (voir la liste) il a choisi cette fois Sheep on Meth (ce qui en français donne quelque chose comme "Moutons drogués à la méthamphétamine"). Il est évident que ce n'est pas avec ça qu'il va détrôner le "Homicidal Dwarf Hamster" du noyau 2.6.20.

RC-7

Enfin, neuf semaines après la première version candidate de ce cycle, c'est le 9 mai que Linus a annoncé RC-7:
« Je pense que c'est la dernière RC. Tout a été particulièrement calme sur le front des patchs, même si il y a eu des discussions assez animées sur la liste ».

Les nouveautés (↑)

Système de fichiers Ceph

La partie client du système de fichiers distribué Ceph fait son entrée dans le noyau Linux.
Ceph est issu de la thèse de doctorat de Sage Weil qui a ensuite continué à développer son bébé pour arriver à un niveau de maturité lui permettant de demander son intégration dans la branche principale.
Ce qui distingue Ceph c'est que les données et les métadonnées sont séparées dans des serveurs distincts. On a ainsi des serveurs MDS (pour MetaData Server) et des serveurs OSD (pour Object Storage Devices) qui font de la répartition intelligente et qui s'adaptent à la charge. La sémantique d'accès aux données est sans surprise puisqu'elle répond à la norme POSIX et, en cas de gros problème, la récupération de ces données se fait à partir de plusieurs disques simultanément et à destination de plusieurs autres disques (mode N-way replication).
On pourrait penser que Ceph est proche du système de fichiers à haute performance Lustre, très utilisé sur les superordinateurs et développé par Oracle. C'est vrai car Lustre sépare lui aussi les données et les métadonnées dans des serveurs différents. Néanmoins, il existe plusieurs différences (outre le fait que Lustre n'est pas encore intégré officiellement dans le noyau).
- Les noeuds de stockage locaux de Ceph utilisent le très moderne système btrfs ce qui permet de profiter de ses fonctions de sommes de contrôle ou de réplication.
- L'administration de Ceph est plus simple que celle de Lustre. Pour obtenir de la haute disponibilité il suffit d'indiquer qu'on veut x réplications de données et le système s'occupe tout seul de copier les données en cas de crash d'un nœud. La syntaxe à utiliser est très claire puisqu'un niveau de réplication impliquant un quadruplage des données s'ordonne ainsi : ceph osd pool set data size 4.
- Les noeuds de métadonnées et de données de Ceph fonctionnent avec des démons en espace utilisateur alors que pour Lustre tout est entièrement en espace noyau. De plus, Ceph utilise des serveurs de métadonnées répartis sur plusieurs machines quand Lustre ne peut utiliser qu'un seul serveur de métadonnées.

Au bilan Lustre reste imbattable sur son créneau des hautes performances pour lequel il est parfaitement adapté mais Ceph offre une alternative de système de fichier distribué plus simple à administrer et intégrant "de base" plus de fonctions. Le fait qu'il se base en local sur des noeuds utilisant btrfs est une très bonne idée car cela permet de réutiliser du code sans réinventer la roue. Sage Weil a d'ailleurs participé à l'amélioration de btrfs avec plusieurs patchs. Pour aller plus loin dans la découverte de Ceph on peut consulter cette présentation au format odp et lire cet article de linux-mag qui fait le point et rappelle que le système est encore considéré comme expérimental (comme btrfs d'ailleurs).

Système de fichiers LogFS

LogFS, le système de fichier spécialisé dans la mémoire Flash, est entré officiellement dans cette version 2.6.34 du noyau Linux.
LogFS est basé sur l'idée que les systèmes de fichiers classiques sont conçus principalement pour des disques rotatifs magnétiques alors que le stockage de données sur mémoire flash ne devrait pas avoir besoin de tout le code extrêmement complexe qui tente d'éviter la fragmentation des fichiers. L'approche suivie est donc basée sur une écriture purement séquentielle des données comme un log (log structured) ce qui explique le nom qui a été choisi.
LogFS a été écrit presque entièrement par un seul développeur, Jörn Engel, ce qui explique le temps qu'il a mis a être intégré dans la branche principale. Depuis la proposition initiale d'inclusion en mai 2007 il a fallu trois ans pour convaincre les sourcilleux gardiens du noyau que la qualité du code était suffisante.
Ce nouveau système de fichiers a vocation à remplacer dans le monde de l'embarqué le vieillissant JFFS2 qui oblige à faire un scan complet du volume au montage. Avec LogFS toute la structure du système de fichiers est présente directement dans le disque ce qui accélère considérablement le montage. D'après les tests de Jörn, sur un disque NAND flash d'une capacité de 1 Go, on passe de 3,3 secondes pour le montage sous JFFS2 à 60 millisecondes avec LogFS.
Par rapport à NILFS, qui est un autre système de fichiers basé sur l'approche "log structured", la fonction de ramasse-miette est entièrement dans le noyau au lieu d'être en espace utilisateur avec NILFS. Ainsi, une suppression de fichier sous LogFS mettra immédiatement à disposition cet espace libre alors que pour NILFS il faudra attendre que le démon de garbage collection en espace utilisateur se déclenche.

Il est important de comprendre que LogFS n'est pas vraiment prévu pour s'adapter parfaitement aux disques SSD actuels (même si cela fonctionnera). Le but de Jörn c'est d'attaquer directement la flash sans passer par les couches d'émulation:
« Iggy Pop a expliqué un jour pourquoi tant de ses chansons sont devenues des hits 10 ans après leur sortie. C'est parce qu'il ne s'est jamais préoccupé du goût du public tel qu'il était mais plutôt du goût du public tel qu'il devrait être.
En un sens je fais la même chose. Le disque SSD que vous pouvez acheter en magasin a une interface SATA et il cache sa flash derrière une couche d'abstraction. Il tente de se faire passer pour un disque normal. Entre l'OS et le média physique, il y a un sacré nombre de couches passant du CPU au PCI ou PCIe puis SATA puis le bus interne du SSD jusqu'à l'interface NAND. Chaque étape ajoute de la latence.
Les disques SSD que nous devrions pouvoir acheter n'ont pas besoin de ces couches superposées. Enlevons le SATA et attachons-le directement au PCIe. Enlevons le PCIe et connectons-le directement au port hypertransport de la carte. Il faut aller le plus près possible du processeur et de la RAM.
Le support pour les périphériques en mode blocs n'est là que parce que je dois moi aussi vivre dans le présent et que c'est plus difficile et cher de créer son propre disque SSD que de modifier le système de fichiers. Mais ça ne veut pas dire que j'aime la situation actuelle. Et vous non plus vous ne devriez pas l'aimer ».

Même si ces fameux disques SSD de nouvelle génération permettant d'attaquer directement la mémoire flash sont encore inexistants à l'heure actuelle, il est rassurant de voir que le noyau Linux est déjà fin prêt à les accueillir et à les exploiter au maximum de leur potentiel.

Mise en veille asynchrone

Le patch de mise en veille asynchrone des périphériques a été intégré dans le noyau 2.6.34.
Dans la version 2.6.32 de Linux, le développeur Rafael Wysocki avait incorporé une gestion dynamique de l'énergie (runtime power management) pour les périphériques rattachés à l'ordinateur. Avec cette infrastructure, il devenait possible de mettre en veille et de rallumer à la volée les divers périphériques inutilisés d'une machine afin de gagner en consommation d'énergie.
Continuant dans cette voie Rafael a écrit un nouveau patch visant à rendre ces transitions asynchrones afin de gagner en rapidité.
Avant ce patch, les changements d'état des périphériques étaient synchrones, ce qui signifie qu'ils devaient se dérouler de manière purement séquentielle, les uns après les autres. C'est évidemment une méthode lente et ce d'autant plus que le nombre de périphériques est élevé. Avec le patch mise en veille asynchrone des périphériques inutilisés, on peut procéder aux extinctions ou aux rallumages de plusieurs périphériques en parallèle. Comme les mises en veille et les rallumages se font plus rapidement il est évident qu'au final on gagne en consommation.
Le problème évident avec cette méthode, c'est qu'il existe des dépendances entre certains périphériques. Par exemple, une dépendance existe entre un contrôleur PCI et les périphériques actuellement branchés sur les ports PCI. Il n'est pas possible d'éteindre à la volée le contrôleur sans avoir d'abord éteint tout ce qui lui est attaché. Inversement, il n'est pas possible de rallumer des périphériques PCI sans prendre la précaution de rallumer en premier le contrôleur.
Le patch de Rafael, très complexe, prend donc bien soin d'examiner la topologie complète des périphériques afin de prendre des décisions pertinentes quant à leur gestion asynchrone.
Le problème c'est que Linus Torvalds, inflexible gardien de la propreté du code, a détesté le patch initial de Rafael :
« Je pense que le patch est complètement et totalement pourri. À la fois d'un point de vue implémentation _et_ d'un point de vue conceptuel. Nous n'avons pas besoin de ces initialisations de flags par périphérique, pas plus que nous n'avons besoin que les pilotes "activent" le code asynchrone.
Pourquoi le code de mise en veille/réallumage a besoin de toute cette m*rde ?
Ce serait bien plus naturel d'introduire un hook qui s'occuperait de la phase de pré-mise en veille et parcourrait l'arbre des périphériques pour faire le boulot asynchrone.
En d'autres termes, je ne vais certainement pas inclure cette folie ».

Selon Linus, le code Rafael était bien trop compliqué et, durant toute la longue discussion qui a suivi sur la liste de diffusion, il a poussé pour avoir la solution la plus simple possible:
« OK les gars, arrêtez de balancer des idées folles sur la liste. Ce n'est pas comme si notre infrastructure de mise en veille était devenue si stable et ennuyeuse et que nous voulions la rendre à nouveau peu fiable.
Pourquoi est-ce que vous fabriquez tous ces trucs qui sont bien plus complexes qu'ils ne devraient ? ».

Après avoir tenté une première approche basée sur un sémaphore posé sur chaque nœud de l'arbre des périphériques, Linus a finalement accepté en bougonnant une version qui se base sur la notion de "complétion".
La technique est détaillée dans le message de commit mais schématiquement cela consiste à associer une structure de complétion à chacun des noeuds de l'arbre (dev->power.comp). Par défaut cette structure est positionnée sur "not_complete". De plus, les périphériques qui implémentent la fonction de mise en veille asynchrone doivent faire appel à la fonction device_enable_async_suspend() pour activer un flag. Lors d'une mise en veille, l'infrastructure de gestion de l'énergie de Rafael va lancer des threads et attendre que tous les périphériques ayant le flag asynchrone se mettent en veille avant d'éteindre le bus maître.

Jon Corbet, qui a analysé toute cette affaire dans un article du site LWN, conclut lucidement par ces mots:
« Cet épisode peut être vu comme une marque de dédain pour le temps de développement qui a été consacré à un patch. Il n'est pas rare que du code qui a demandé beaucoup de travail finisse par être mis au rebut ou complètement réécrit. Ce modèle de développement peut sembler tout à fait dispendieux et il ne fait aucun doute qu'il peut être très frustrant pour les développeurs impliqués. Mais c'est aussi un élément fondamental des procédures de contrôle de qualité qui existent dans le modèle de développement du noyau. L'infrastructure de mise en veille a été nettement améliorée par ce remaniement de dernière minute ».

Mécanisme de sécurité GTSM

Le mécanisme de sécurité GTSM (Generalized TTL Security Mechanism) entre dans le noyau.
Décrite dans la RFC 5082, cette protection est destinée à contrer des attaques de type déni de service permises par le protocole de routage BGP (Border Gateway Protocol).
Ce protocole BGP permet aux équipements réseau de définir la route que doivent parcourir les paquets. Mais comment s'assurer que le routeur supposé ami avec qui on est en train de dialoguer et d'échanger des routes n'est pas en réalité une machine lointaine sous le contrôle d'un vil pirate ? Pour le savoir, les sessions BGP utilisent une signature cryptographique basée sur MD5. Et là, paf, c'est le drame car avec cette solution le méchant n'a plus qu'à envoyer pleins de paquets forgés pour mettre à genoux le pauvre petit routeur. Calculer le hash MD5 de la signature prend du temps et, si le routeur est bombardé de paquets forgés, son processeur ne suffira pas à la tâche.
C'est pour contrer ce déni de service potentiel que le mécanisme GTSM a été introduit.

GTSM utilise un champ sur 8 bits qui est présent dans les paquets IPv4, le champ TTL (Time-to-live) qui compte le nombre de routeurs que traverse le paquet avant d'arriver à destination.
Ce champ a été introduit à l'origine pour éviter que des paquets ne tournent en boucle à l'infini dans le réseau. Au moment de l'envoi, on positionne le champ à une certaine valeur (souvent 64) et chaque routeur décrémente le champ de un lors de son passage. Au bout de 64 sauts de machine en machine le champ est à zéro et le paquet peut être jeté aux oubliettes.

Avec le mécanisme de sécurité GTSM, un routeur va devoir positionner le champ TTL à 255, le maximum permis par la taille de 8 bits, avant de l'envoyer au routeur avec qui il communique. Sachant que deux routeurs BGP sont presque toujours adjacents sur le réseau (ils sont seulement à un "saut" l'un de l'autre) la machine qui reçoit le paquet aura ainsi un moyen facile de vérifier que le paquet n'est pas forgé. S’il a un TTL de 255, alors c'est qu'il n'a rien traversé entre-temps et on peut lui faire confiance. Si le TTL est inférieur à 255 alors le paquet est forgé et on peut le jeter sans même avoir à calculer un couteux hash MD5.

L'activation du mécanisme se fait via l'option IP_MINTTL qui permet de définir le TTL minimum (évidemment, on doit choisir 255 pour que ça marche).
Le message de commit signale que pour l'instant l'option équivalente pour IPv6 (IPV6_MINHOPLIMIT) n'est pas encore implémentée et, autre limitation provisoire, que seuls les paquets TCP sont concernés.
À noter que le mécanisme GTSM, simple et astucieux, était déjà présent chez les noyaux BSD (par exemple depuis la version 7.0 de FreeBSD) et que Linux ne fait donc ici que rattraper son retard sur ses cousins libres.

Lockdep-RCU

Le patch "lockdep RCU", permettant la vérification automatique des appels au code RCU dans le noyau, a été accepté dans le noyau 2.6.34.
La technique du Read-Copy Update est un mécanisme de synchronisation spécialisé qui permet à de multiples threads de lire et modifier simultanément une donnée sans que le processus écrivant n'ait besoin de poser un verrou bloquant sur la donnée. Le RCU autorise donc à lire une ressource partagée comme si on était seul à y accéder. L'idée de base c'est que quand une opération d'écriture, et non plus de lecture, est demandée par un thread alors la ressource est copiée ailleurs avant d'être modifiée. L'original continue d'exister jusqu'à ce que les threads de lecture aient fini leur travail.

Paul McKenney est le grand gourou Linux de la technique RCU qu'il améliore et peaufine dans presque chaque nouveau noyau. Après le RCU hiérarchique de Linux 2.6.29 et le Tiny RCU du 2.6.33, voici maintenant arriver le patch de lockdep-RCU.

Pour tenter de comprendre ce qu'apporte ce patch il faut savoir que la technique RCU, assez simple à décrire brièvement, est en réalité relativement complexe dans ses détails techniques. Si les processus lisant la donnée s'exécutent dans des sections délimitées par des appels à rcu_read_lock() et rcu_read_unlock() il faut aussi que le code offre de plus fortes garanties de cohérence de la donnée. En effet certaines architectures de processeur (Alpha par exemple) réordonnent les accès mémoire et c'est pareil pour les compilateurs qui peuvent, lors d'optimisations agressives, réordonner le code assez librement. Il faut donc que le mécanisme de RCU tienne compte cette absence de garantie et propose une solution technique.
Cette solution c'est le mécanisme de publication-souscription (Publish-Subscribe). Le processus utilisant la fonction de RCU va faire un appel à rcu_assign_pointer() et à rcu_dereference() pour forcer le processeur ou le compilateur à respecter l'ordre désiré.

Le bon usage de toute cette "triperie" technique n'est pas simple à vérifier et il serait certainement utile d'avoir un outil permettant d'automatiser autant que possible la vérification.
La technique du RCU a été introduite dans le vénérable noyau de développement 2.5.43 en 2002 et dans le noyau 2.6.10 de décembre 2004 il n'y avait que 38 occurrences de rcu_dereference() dans le code. La vérification de tous ces appels pouvait donc encore se faire artisanalement "avec les yeux".
Dans le noyau 2.6.32 il y a plus de 230 appels à rcu_dereference() et on atteint les limites puisque les développeurs constatent que l'utilisation du RCU n'est pas toujours parfaite dans le code des périphériques (voir ce mail récapitulatif de Thomas Gleixner).

Paul McKenney, aidé de Peter Zijlstra et de Thomas Gleixner, a donc choisi de modifier l'outil lockdep d'Ingo Molnar pour lui permettre de détecter les utilisations fautives de RCU. Lockdep est déjà utilisé largement par les hackers du noyau pour valider les utilisations des verrous dans Linux afin de détecter les interblocages. Quand lockdep est actif dans un noyau alors une instrumentation du code est effectuée et chaque synchronisation est interceptée à la volée pour vérification.
À partir du noyau 2.6.34, toute utilisation de lockdep transformera la fonction rcu_dereference() en rcu_dereference_check() et toute utilisation de cette fonction sera soumise à la vérification vigilante des conditions définies par les développeurs.

Le patch lockdep-RCU introduit dans le nouveau noyau va permettre de fiabiliser encore plus les primitives de Read-copy Update. Selon Paul McKenney: « nous n'en sommes qu'au début des primitives RCU vérifiées par lockdep. Elles ont été appliquées au code de la pile réseau, au système de fichiers virtuel et à l'ordonnanceur. Dans le futur le lockdep-RCU devrait être très utile pour détecter encore mieux les bugs d'usage du RCU ».

VGA-Switcheroo

Le patch vga_switcheroo intègre le noyau pour permettre de basculer entre des GPU différents.
Depuis plusieurs mois apparaissent des ordinateurs portables qui possèdent deux cartes graphiques différentes. L'une est une puce dite "discrète", c'est-à-dire une carte AMD ou NVidia classique, dotée d'une mémoire dédiée, et qui est utilisée pour jouer ou pour faire de la 3D. Habituellement cette carte chauffe et consomme pas mal de courant. L'autre carte est une puce "intégrée" bien plus basique (incluse dans le processeur pour les dernières générations) et qui sert essentiellement à toutes les tâches ne nécessitant pas de gestion performante de la 3D.
Les systèmes d'exploitation propriétaires gèrent déjà ces machines hybrides à double GPU (gestion à chaud pour Windows 7 et via un redémarrage de session pour MacOS X) mais Linux ne pouvait pas les exploiter jusqu'à présent.
Pour permettre de prendre en charge ces nouvelles sortes de machines le développeur Dave Airlie (responsable de la partie "Direct Rendering Manager" du noyau) a travaillé sur une fonction de bascule entre les cartes graphiques baptisée "vga_switcheroo".
Dave a décrit l'avancée de son patch dans plusieurs articles successifs sur son blog (1 - 2 - 3 - 4 - 5) et l'utilisation de la fonction semble assez simple.
Tout se passe dans le répertoire /sys/kernel/debug/vgaswitcheroo dans lequel se trouve un fichier switch. On va pouvoir écrire quatre commandes différentes dans ce fichier (outre ON et OFF pour éteindre complètement une puce):

echo DIS > switch => bascule immédiate vers le GPU discret (la puce puissante)
echo IGD > switch => bascule immédiate vers le GPU intégré (la puce basique)
echo DDIS > switch => bascule retardée vers le GPU discret (la puce puissante)
echo DIGD > switch => bascule retardée vers le GPU intégré (la puce basique)

La bascule immédiate ne marchera que si X n'est pas lancé. On utilisera donc bien plus souvent les fonctions de lancement avec retard (DDIS et DIGD) qui enregistrent la demande de changement de GPU pour la rendre effective lors du redémarrage de X.
En effet une limitation importante de vga_switcheroo c'est qu'il oblige à redémarrer le serveur X si on veut que la bascule soit effective. Cela est dû au fait que X n'a pas été prévu à l'origine pour autoriser ce genre d'acrobatie.
Pour mieux comprendre pourquoi le serveur X ne sera sans doute jamais adapté pour permettre la gestion "à chaud" de ces nouveaux portables bi-GPU allez lire ce post LinuxFr très intéressant de Stéphane Marchesin dans la dépêche "Du côté de chez Xorg".
Même si le changement complètement transparent de carte semble pour l'instant hors de portée, il reste tout de même assez rapide de basculer d'un GPU à l'autre. Dave Airlie a ainsi enregistré une petite vidéo afin de montrer au monde entier le switch de carte graphique sur sa machine. La vidéo est visible sur le site Dailymotion.
Pour les réfractaires à la ligne de commande il est parfaitement envisageable de rendre plus "jolie" la bascule en créant un lanceur sur sa barre de tâche qui pointerait vers un petit script shell du type utilisé par Dave dans sa vidéo. Ainsi un utilisateur voulant lancer un jeu cliquerait d'abord sur un simple bouton et le changement de GPU + redémarrage de X de ferait automatiquement en quelques secondes.
À noter que Linus, décidément fort prodigue en gueulantes lors de ce cycle, a objecté sur l'option de configuration à "Yes" par défaut dans le patch initial qui lui a été proposé:
« Pourquoi est-ce que vga_switcheroo est activé par défaut ? On ne fait pas des trucs comme ça. Les nouveaux pilotes et les nouvelles fonctions ne sont _pas_ activées par défaut.
Le "default y" est une habitude de me*de. Un développeur pense toujours que _son_ code est tellement spécial et important qu'il devrait être activé par défaut, MAIS C'EST FAUX.
Donc prière de s'en souvenir : a moins que votre nouvelle fonction ne guérisse le cancer, elle ne devrait certainement pas être activée par défaut ».
Ce sera donc aux distributions de choisir de configurer ou pas vga_switcheroo dans leurs versions du noyau.

Refus des patch SquashFS

Pour donner une plus juste appréciation du travail des développeurs du noyau, il ne faut pas seulement parler des nouveautés qui entrent dans un noyau, il faut également parler du code qui est bloqué et refusé par ces mêmes développeurs.
En effet, il est crucial que les standards d'acceptation de code soient élevées si on veut que Linux maintienne son niveau de qualité.
Dans le rôle du dragon cracheur de feu on retrouve souvent, et c'est bien normal, Linus lui-même. L'innocente brebis qui a été dévorée cette fois-ci est Phillip Lougher qui avait proposé diverses améliorations de Squashfs, un système de fichiers compressé et en lecture seule qui est entré dans le noyau 2.6.29. Dans la dépêche LinuxFr sur cette version il était indiqué que SquashFs utilisait la compression gzip mais qu'il existait un projet pour utiliser l'algorithme lzma à la place. Avec lzma il est possible de compresser encore plus un système de fichiers et donc de faire tenir plus de logiciels sur un LiveCD par exemple.
Phillip Lougher, l'auteur de Squashfs, a donc écrit une série de patchs pour ajouter ce support de lzma et a proposé à Linus de rapatrier sa branche Git. À l'évidence il ne s'attendait pas à s'entendre rétorquer un cinglant:
« Bordel mais c'est quoi ces fichiers complètement illogiques et monstrueux ? Il n'est pas question que je merge ça. ».
Linus n'a pas aimé que le code de décompression spécifique soit incorporé dans un header (dans include/linux/decompress/unlzma_mm.h) et il a protesté avec son ton habituel:
« Cette façon débile de cacher une implémentation pourrie de malloc dans un fichier de header me fait juste vomir.
Je refuse de voir l'inclusion de trois nouvelles copies de ce truc dégoûtant (bunzip, inflate et lzma).
C'est déjà assez dégueulasse comme ça dans compress/mm.h (ce truc devrait d'ailleurs être mis en orbite à coup de bombes nucléaires, c'est le seul moyen d'en être débarrassé) mais quand je vois qu'on essaye de répandre cette horreur un peu partout dans le noyau je passe en mode attaque zombie et je cours tout nu dans tous les sens avec ma tronçonneuse ».

Une telle perspective ayant de quoi effrayer le hacker le plus endurci, Phillip Lougher a dû remballer la majeure partie de son code. Il a sauvé ce qui pouvait être sauvé (surtout du nettoyage de code) et il a annoncé qu'il allait s'atteler à la modification des fichiers désignés par Linus. Comme cette modification touche plusieurs architectures il faudra attendre un peu pour pouvoir profiter de l'algorithme de compression lzma dans Squashfs.

En bref (↑)

Btrfs, le futur système de fichiers star de nos distributions puisqu'il a vocation à remplacer ext4, a été largement amélioré dans cette nouvelle version du noyau.
Une fonction très appréciable de btrfs, c'est la possibilité de faire des instantanés du système (snapshots). Jusqu'à présent il y avait des limitations en terme de sous-volume bootable ce qui réduisait l'intérêt du système. Avec le 2.6.34 cette limitation saute et il deviendra bien plus facile pour les distributions de faire des instantanés pour sécuriser une mise à jour en permettant de redémarrer sur un sous-volume sain.
La fonction de défragmentation intégrée à btrfs permet maintenant de défragmenter des parties d'un fichier dans un certain intervalle au lieu de devoir tout défragmenter. Au niveau de la compression, là aussi on accède à plus de granularité puisqu'on peut compresser certains fichiers (avec force_compress:1) sans devoir imposer cette option à tout le volume.
Enfin un appel système permettant de chercher des fichiers modifiés dans le volume (c'est l'ioctl find-new) a été ajouté dans les fonctions de btrfs. Il permettra aux programmes en espace utilisateur de l'utiliser pour retrouver rapidement tout fichier ayant été modifié récemment. Chris Mason a fait un test sur un dépôt Git contenant toutes les sources du noyau en modifiant un unique fichier. Un petit "find -newer" lui sort le fichier en 9 secondes alors le nouveau ioctl de btrfs se contente de 0.04 secondes.
Un autre système de fichier, XFS, a lui aussi été amélioré substantiellement dans le noyau 2.6.34. Les améliorations sont toutes purement internes et les utilisateurs devraient uniquement en sentir les effets en constatant une amélioration du débit des entrées/sorties. Par exemple l'algorithme chargé de placer les inodes a été complètement réécrit, ce qui augmente les performances de lecture des métadonnées. Le code permettant d'agrandir un volume XFS a été lui aussi réécrit pour être plus générique et supprimer des limitations internes. Selon Christoph Hellwig, mainteneur du système de fichiers XFS, cela facilitera l'inclusion de la future fonction de contraction des volumes.
Le système de fichiers ExoFS, qui était entré dans le noyau 2.6.30, et qui utilise le nouveau mode de stockage réseau OSD (Object Storage Device) peut maintenant fonctionner en mode RAID 0. Cette amélioration décrite dans le message de commit permet aussi de définir des "striping-groups", c'est à dire que seuls certains disques du système utiliseront l'option de striping RAID 0. Si l'on en croit le message de Boaz Harrosh la prochaine étape prévue pour ExoFS sera le support des modes RAID 5 et RAID 6.
L'interface utilisée pour la virtualisation, virtio, a été améliorée par l'ajout du module vhost_net. Ce module, écrit par Michael Tsirkin, implémente un périphérique en mode caractère afin de réduire le nombre d'appels systèmes (syscalls) entre l'hôte et le système invité. On gagne ainsi en performances réseau sans devoir changer quoi que ce soit sur le système invité puisque vhost_net élimine 4 syscalls pour chaque paquet échangés. D'après la page consacré à vhost_net sur le site de KVM, les performances réseau du guest, testées avec TCP_STREAM, passent de 72 Mo/s à 78 Mo/s (81 Mo/s en natif). Pour le test TCP_RR on passe de 395 µs/transaction à seulement 86 µs/transaction (48 µs/transaction en natif).
Si vous vous intéressez aux cartes graphiques Intel, alors vous serez contents d'apprendre que le pilote KMS du noyau 2.6.34 intègre d'ores et déjà le support du nouveau coeur graphique de Sandy Bridge. Ce processeur qui sortira en fin d'année incorporera le coeur graphique sur le même die que le CPU classique. En effet, pour réduire la consommation et utiliser le "budget transistor" que permet la loi de Moore, la mode est à la "fusion" des CPU et des GPU. Intel, souvent critiqué pour la faible puissance de ses coeurs graphiques, promet que Sandy Bridge permettra d'au minimum doubler les performances actuelles.
Pour les cartes existantes le travail a surtout porté sur la gestion efficace de l'énergie (-0.8W en mode économie) et sur la fonction d'overclocking des puces Ironlake présentes dans les Core i5 et Core i7.
Habitué à la maintenance des outils de monitoring du noyau - il travaille aussi sur SystemTap - le développeur Masami Hiramatsu a décidé d'optimiser le code des kprobes. Il s'agit de sondes qui sont injectées dans le noyau afin de générer des informations et des statistiques sur son fonctionnement interne. La documentation explique que les kprobes utilisent, sur les machines x86 et x86-64, l'instruction breakpoint pour intercepter les informations voulues. Dans son message de commit Masami Hiramatsu explique qu'il a utilisé un jump au lieu du breakpoint. Cela consomme un petit peu de mémoire en plus mais le gain en performances est très sensible puisque le coût d'un kprobe passe, sur un Xeon 2.33 GHz en mode 64 bits, de 0,91 microsecondes à seulement 0,06 microsecondes.
Introduit dans le 2.6.31 l'outil perf est chargé du tracing dans le noyau Linux. Dans cette version perf peut maintenant générer également des statistiques sur l'utilisation des verrous. C'est Hitoshi Mitake qui a soumis le patch permettant l'utilisation de cette toute nouvelle commande "perf lock".
Dans le 2.6.34 on trouve également un support des scripts écrits en Python pour perf. Alors qu'avant seul Perl était disponible, Tom Zanussi a écrit le patch ajoutant le scripting Python. Plusieurs scripts sont déjà prêts à être utilisés et vous les trouverez dans tools/perf/scripts/python. Une documentation complète est également disponible.
Toujours en chantier le pilote KMS Radeon intégré dans le noyau 2.6.34 supporte maintenant les cartes de type Evergreen R800 (toutes les cartes connues sous le nom commercial HD 5000). Ce support est très préliminaire puisqu'il ne permet pas encore l'accélération 2D/3D mais au moins les cartes sont reconnues. Le développeur Alex Deucher a détaillé sur son blog les 13 patchs qui ont été nécessaires à cette intégration des cartes Evergreen dans le noyau. La publication par AMD des spécifications des cartes R800 va certainement permettre au pilote libre d'avancer et les patchs implémentant l'accélération sont déjà disponibles pour la prochaine version. En ce qui concerne les cartes plus anciennes, la gestion de l'énergie est améliorée, le support audio HDMI arrive pour les R700 et un vérificateur de commandes (Command Checker) est maintenant activé pour les cartes R600/700 afin de renforcer la fiabilité et la sécurité.
Le code gérant la mémoire virtuelle a été amélioré pour faciliter la montée en charge. Ce patch, celui-là même qui contenait le fameux bug résolu par Linus, change la complexité algorithmique du parcours des pages mémoires anonymes (celles qui sont créées à la demande d'un processus unique). Avant on était en 0(n) (complexité linéaire) et avec le patch de Rik van Riel, on passe en complexité constante 0(1). Le message de commit indique que sur le benchmark AIM7, qui sert à mesurer le débit de jobs lancés par des utilisateurs, on passe de 9 700 users à 29 700 users sur la même machine ayant 16 Go de mémoire.
Le code de l'ordonnanceur des entrées/sorties CFQ a été retouché afin d'améliorer encore un peu ses performances. En premier lieu l'algorithme plaçant les requêtes dans les listes d'attente a été modifié afin de prendre en compte les disques SSD. Jusqu'à présent CFQ groupait les requêtes sans tenir compte du fait que le périphérique était de type rotatif (disque dur) ou pas (SSD). Maintenant l'algorithme sait qu'il ne doit pas tenir compte de la localisation de la requête pour les disques SSD et le placement dans la liste d'attente devient donc plus équitable qu'avant.
Ensuite le code de gestion des périphériques rotatifs permet, grâce à ce patch, de mieux distinguer les cas de requêtes séquentielles par rapport aux requêtes nécessitant de déplacer aléatoirement la tête de lecture (seek). L'heuristique est plus performante et elle garde maintenant un historique des 32 dernières requêtes pour améliorer encore plus la précision.
Enfin une optimisation simplissime pour réduire l'empreinte mémoire a été effectuée sur la structure cfq_queue dans le cas des noyaux 64 bits. La taille passe ainsi à 256 octets ce qui permet de la faire tenir plus facilement dans le cache de l'allocateur kmem_cache.
Le module lkdtm, qui propose une fonctionnalité rarement utile pour l'utilisateur de base puisqu'il sert à faire planter le noyau, a été amélioré dans cette nouvelle version de Linux. Utile aux développeurs pour tester la fiabilité des dumps générés après un crash, ce module s'utilise en passant des arguments lors du chargement (au moment du insmod). Maintenant on peut également l'utiliser avec debugfs qui est un système de fichier spécial utilisé pour le déboguage. La documentation indique qu'on peut faire joujou en demandant des plantages différents du type PANIC ou bien CORRUPT_STACK ou encore WRITE_AFTER_FREE. Des heures de fous rires en perspective !

Une flame war d'un fort beau gabarit (↑)

Le pilote libre Nouveau, écrit pour remplacer le binaire propriétaire des cartes graphiques NVidia, a été intégré dans la précédente version du noyau Linux. Depuis cette intégration l'interface externe de Nouveau a changé et tout le code qui existait en espace utilisateur est devenu incompatible avec l'ancienne API. Pour utiliser Nouveau dans le noyau 2.6.34 il faut donc obligatoirement avoir une version compatible de la libdrm (Direct Rendering Manager library).
En soi ce changement n'est pas suffisamment important pour nécessiter un paragraphe explicatif mais ce qui est intéressant c'est qu'il a provoqué des échanges animés (lire flame war) entre Linus et les responsables du patch.
Cette conversation, et l'argumentation utilisée par les uns et les autres, offre une perspective sur diverses questions intéressantes: Quel est le but de la branche -staging ? L'inclusion par les distributions de pilotes absents de Linux est-elle une bonne chose ? Faut-il versionner les API ?
C'est pour ça qu'il m'a semblé utile de traduire les mails les plus significatifs de cette polémique sur la LKML. Je me suis parfois permis de fusionner plusieurs extraits de mails en un seul paragraphe pour condenser les échanges.

Ce qu'il faut bien garder en mémoire, c'est que le pilote Nouveau est encore dans la branche -staging de Linux. Cette branche, très spécifique, est destinée à accueillir les pilotes encore en développement et qui avant cela stagnaient un peu partout sur le net. Cela permet une centralisation de ces pilotes au sein de la branche principale du noyau (mainline) et cela incite à un développement plus coordonné au lieu d'avoir du code dispersé de tous les côtés.
La branche -staging possède des règles précises mais, à lire le texte de Greg Kroah-hartman, il n'est pas écrit noir sur blanc qu'un changement d'interface externe avec l'espace utilisateur est autorisé. Toutefois l'interprétation qui est généralement retenue est qu'il est permis de changer une telle API externe puisque les pilotes dans -staging sont justement là pour être lourdement modifiés et rejoindre les standards de qualité du noyau.

C'est pour cette raison que les développeurs de Nouveau et de la couche graphique du noyau ont été fort surpris de la réaction de Linus suite à l'annonce du changement d'API:

« Ce changement rend impossible le _test_ d'un nouveau noyau. Upgrader en même temps X et le noyau de façon forcée n'est pas envisageable, pleins de gens utilisent juste une distribution quelconque (Fedora 12 dans mon cas) et vous venez juste de tout casser. Nous ne pouvons pas casser ainsi la configuration des gens. Ce pilote est, que vous le vouliez ou non, utilisé par Fedora 12 (et probablement par d'autres distributions). Il est peut-être défini comme "staging" mais cela ne change pas le fait qu'il est utilisé en production par des grosses distributions ».

Linus a été particulièrement énervé par cette modification car elle l'empêche, lui comme tous les autres contributeurs potentiels, de faire des tests avec l'outil bisect de Git. Cette fonction est fort utile puisqu'elle permet de retrouver relativement facilement le patch fautif ayant introduit un bug:

« Est-ce qu'il y a une version de la libdrm qui peut gérer les _deux_ API pour permettre aux gens d'utiliser bisect ? C'est à dire, même si on a une version récente de libdrm est-ce qu'elle marchera aussi avec le vieux noyau ? La rétro-compatibilité c'est super important ».

À la suite de cette tirade Jesse Barnes lui a répondu:

« Bien sûr que la rétrocompatibilité c'est important. Mais ce pilote est clairement du type "À utiliser à vos risques et périls". Cela signifie que tant qu'il se trouve en staging il est obligatoire de garder une synchronisation noyau/userspace si on veut changer le noyau.
Maintenant si le fait d'être en staging ne permet plus de changer l'API quand on a besoin de le faire alors il n'y aura pas d'autre choix que de retirer le pilote du noyau et de ne le soumettre à nouveau pour inclusion qu'une fois que l'interface sera stable ».

Linus n'a pas vraiment apprécié cette obligation de changer simultanément le noyau et la libdrm puisqu'elle réduit drastiquement le nombre de testeurs des nouveaux noyaux :

« Le fait est que vous n'avez même pas _essayé_ de garder la compatibilité.
Sérieusement qu'est-ce que vous voulez que je fasse dans cette situation ? Je ne vais pas sortir un noyau que je ne peux pas tester. Donc si je ne peux pas avoir une libdrm qui fonctionne dans mon environnement je vais _devoir_ faire un revert sur le patch que vous m'avez demandé d'inclure.
Vraiment. Regardez ça de mon point de vue. Regardez ça du point de vue de n'importe quel développeur du noyau. Ce serait complètement irresponsable pour moi de sortir le 2.6.34 sans avoir eu la possibilité de le tester moi-même sur ma propre machine ».

Cette fois c'est Ben Skeggs qui a tenté de raisonner Linus:

« C'est *toi* qui as poussé pour que Nouveau intègre la branche staging avant que ses développeurs ne soient prêts. Nous n'avons aucune intention de garder des API foireuses quand elles ne répondent pas aux besoins. L'idée même de staging c'est de permettre ce genre de chose alors pourquoi cette surprise ? Je suis d'accord que c'est galère de faire un bisect mais c'est loin d'être une fonction utilisée par des masses de gens ».

Matthew Garrett a enfoncé le clou:

« Quand tu a demandé que Nouveau soit inclus les gens t'ont dit explicitement que l'interface était instable et que les applis en espace utilisateur devraient s'adapter. Tu as demandé que ce soit incorporé quand même et maintenant tu n'es pas content parce que l'interface a changé et que l'espace utilisateur doit s'adapter ? ».

Réponse immédiate de Linus:

« Est-ce que c'est si dur que ça de comprendre les règles basiques de développement du noyau ?
Nouveau était déjà dans Fedora 12. Les gens peuvent se cacher derrière tous les "c'est juste en staging" et les "tu nous l'as demandé" qu'ils veulent mais cela ne change rien au simple fait fondamental: Les distributions devraient s'assurer que les pilotes sont présents en upstream. Les gens dépendent de ces pilotes.
À ce propos j'espère me débarrasser de ma carte nVidia merdique très bientôt...mais cela ne change pas mon objection. Je n'ai pas demandé que Nouveau soit mergé en staging pour le plaisir. Je l'ai demandé parce qu'une distribution majeure l'utilisait déjà ».

Ingo Molnar a fait quelque peu dévier la conversation en soulignant le fait qu'un changement d'API avec l'espace utilisateur était presque toujours une grave erreur. Selon lui c'est le résultat d'une tendance à créer des interfaces inutiles entre des composants:

« Ma conclusion est claire comme le cristal. Changer une API d'un coup est une erreur, c'est dommageable, cela limite la base des développeurs, cela limite la base des testeurs, c'est une perte de temps et d'efforts. C'est une mauvaise décision technique. C'est du masochisme. Il y a peu de règles inconditionnelles dans le monde du libre mais cela en est une.
Tout ça est souvent le résultat d'une _autre_ mauvaise décision technique : la sur-modularisation.
Xorg, mesa/libdrm et les pilotes DRM du noyau ne représentent pas vraiment trois ou quatre projets séparés mais un seul méta-projet abstrait ».

Stéphane Marchesin, le créateur du projet Nouveau, lui a répondu que c'était facile à dire mais qu'aucune solution technique réelle n'était vraiment envisageable à court terme :

« Tu sais quoi ? Tous les développeurs des pilotes graphiques sont d'accord sur ce diagnostic, mais il n'y a pas de solution évidente. Voici les interfaces qui sont impliquées dans le problème:
- L'interface drm
- L'interface d'accélération de X.Org
- L'interface Mesa
Toute solution implique de fusionner ensemble deux ou plus de ces composants afin d'enlever une interface ».

Stéphane a ensuite examiné les trois paires possibles de composants qu'on pouvait essayer de fusionner (drm-xorg; drm-mesa, xorg-mesa). Après avoir souligné tous les problèmes techniques que cela posait il a conclu que ce n'était pas pour demain :

« Dans un futur lointain je peux seulement espérer que toute l'accélération (2D et 3D) se fera seulement via OpenGL. Cela voudra dire qu'on peut supprimer entièrement DDX. Nous parlons de ça depuis environ 6 ans mais c'est encore loin d'être le cas ».

Après ces considérations prospectives la conversation est revenue sur le sujet chaud. Sans autre solution, Linus a dû rapatrier les sources de libdrm sur sa machine et bidouiller pour pouvoir tester le noyau incluant le patch de changement d'API de Nouveau. Évidemment cette contrainte, et surtout la perte d'autres testeurs potentiels qu'elle implique, l'a fait grogner:

« Franchement je persiste à penser que je ne devrais pas avoir à faire ce genre de contorsions. Le versionnage devrait être prévu. Et je persiste aussi à penser que "staging" n'est pas une excuse pour dire "c'est un truc tout pourri et on s'en fout ».

Les échanges auraient pu s'arrêter là mais Daniel Stone a cru bon d'essayer de tirer un bilan et son mail a remis le feu aux poudres:

« Peut-être que la leçon que nous devons tirer de tout ça est: "Si les développeurs ne veulent pas merger quelque chose parce que ce n'est pas encore prêt et qu'ils prévoient de gros problèmes dans le futur alors il faut les écouter au lieu de se foutre de leur avis" ».

Jeff Garzik lui a retorqué:

« Le cheval s'est échappé de l'écurie quand Fedora a sorti une version stable avec Nouveau dedans, pas quand Linus l'a mergé dans sa branche ».

David Miller a lui aussi contesté le jugement de Daniel Stone:

« Si nous n'avions pas incorporé le pilote alors les utilisateurs de Fedora n'auraient pas du tout été capables de tester les nouveaux noyaux amont.
< Si on réfléchit à la situation il n'y a qu'une et une seule action qui aurait permis que tout se passe bien: Incorporer le pilote en upstream et ne pas changer l'API externe. En fait j'irai même jusqu'à dire qu'à partir du moment ou Nouveau est arrivé dans Fedora et a été activé par défaut alors on aurait du geler l'interface externe ».

En définitive l'origine de cette flame war est à chercher dans le fait que plusieurs développeurs ont considéré qu'après l'incorporation dans Fedora puis dans Linux le changement d'API avait été introduit de manière désinvolte et sans tenir compte de l'écosystème global de Linux. C'est Fedora qui a été pointé du doigt pour avoir oublié cette règle cardinale du modèle de développement du libre: Les changements doivent se faire en amont sinon tout le monde en pâtit.
Ted Ts'o a tenté de tirer la morale de cette histoire dans deux mails sévères (fusionnés ici):

« Quelqu'un chez Red Hat/Fedora a pris la décision de rendre disponible ce pilote dans une distribution très populaire afin d'avoir plus de retours de tests. Et cela a été fait sans mettre en place le versionnage nécessaire pour que les développeurs puissent tester les nouveaux noyaux. C'est, selon moi, un truc anti-social qui a été fait là.
La raison pour laquelle ce thread a fait autant de traffic c'est qu'il est fondamentalement au sujet des normes communautaires. Il y a plein de choses qui ne sont pas illégales mais qui sont en même temps anti-sociales.
Ce qui est arrivé c'est que quelqu'un a dit "Je veux expérimenter sur un paquet d'utilisateurs mais je ne veux pas fournir les efforts pour faire ça de manière correcte. Je veux prendre un raccourci. Je ne veux pas me préoccuper du fait qu'il sera impossible de tester les nouveaux noyaux sans utiliser des combinaisons de patches à la Frankenstein entre Fedora 13 et Fedora 12".
Le vrai problème c'est que Fedora et la communauté de Nouveau agissent de façon incroyablement égoïste. Ils voient les choses uniquement de leur petit point de vue et se fichent des inconvénients qu'ils infligent au processus de développement du noyau et aux autres développeurs du noyau.
C'est _légal_ cependant c'est anti-social.
Fedora n'est pas la seule bien entendu. Ubuntu a fait ça également, et pire même, avec des pilotes binaires. Mais ce n'est pas parce que Ubuntu a fait pire qu'il ne faudrait rien dire sur Fedora dans ce cas là ».

Pour conclure sur ce psychodrame, et malgré le ton abrasif de Ted Ts'o, je pense qu'il faut ramener les chose à une plus juste proportion. Le ton de la LKML est très franc, brutal parfois, car les hackers du noyau ne sont pas des droïdes de marketing pratiquant la langue de bois. Cela n'empêche pas les gens de travailler ensemble et Linus, en dépit de sa gueulante, a incorporé le patch de Nouveau, testé son noyau et continué a sortir les versions candidates de son cycle habituel.
Cette poussée de fièvre s'explique en partie par le fait que le projet Nouveau est scruté de très près. Pour beaucoup de gens Nouveau représente enfin la solution qui va permettre le support libre des cartes graphiques d'un acteur majeur du marché.
Je crois que c'est Mike Galbraith qui a trouvé le mot de la fin approprié:

« Si on veut voir les choses du bon côté tout ce vacarme a envoyé un message très positif à l'équipe de développement de Nouveau: Hé les mecs, votre travail est important !
À leur place je serai fier comme un paon :) ».

Le bilan en chiffres (↑)

Côté statistiques ce noyau a vu l'intégration d'un peu moins de patchs par rapport aux précédents. L'article récapitulatif pour le 2.6.34 du site LWN est disponible et on pourra également se reporter au site dédié aux statistiques du noyau Linux.

Pour le noyau 2.6.34, le nombre de patchs était de 9 100 au 5 mai (10 863 pour le 2.6.33). On constate donc une certaine réduction du nombre de patchs lors de ce cycle (bien visible sur ce graphique). À priori cela ne s'explique pas par la fermeture anticipée de la période de merge car Linus a accepté par la suite les demandes de merges des contributeurs. Peut-être est-ce simplement qu'il y avait moins de nouveautés à intégrer cette fois-ci ?
Si on fait un bref récapitulatif des huit derniers noyaux, cela donne :

2.6.27 => 10 625 patches
2.6.28 => 9 045 patches
2.6.29 => 11 696 patches
2.6.30 => 11 984 patches
2.6.31 => 10 881 patches
2.6.32 => 10 997 patches
2.6.33 => 10 863 patches
2.6.34 => 9 100 patches

En nombre de développeurs, le 2.6.34 aura vu les contributions de 1 129 personnes différentes (1 201 pour le noyau 2.6.33). Parmi ces développeurs 263 sont des primo-contributeurs (postant un patch pour la première fois depuis le 2.6.12-RC2 qui est le point de départ des statistiques du site remword). En moyenne ces 1 129 développeurs ont proposé 7 patchs (mais la "traine" est assez longue puisque 552 personnes n'ont posté qu'un seul patch).

Pour la suite (↑)

En ce qui concerne les futures nouveautés des prochaines versions du noyau on peut se tourner vers la page spécifique de la Fondation Linux.

Big Kernel Lock

En 2008 un travail de longue haleine avait été entrepris par les développeurs de Linux pour supprimer du code du noyau le fameux verrou géant (BKL pour Big Kernel Lock). Ce verrou bride les performances des machines multiprocesseurs et tout le monde souhaite avec ferveur sa disparition.
Deux ans plus tard le travail se poursuit et Arnd Bergmann a récemment annoncé une nouvelle offensive pour faire reculer l'hydre du BKL.
Sa branche Git s'intitule bkl-removal et Arnd a travaillé sur des parties du noyau assez diverses. D'autres développeurs, comme Frédéric Weisbecker, ont participé à la discussion et ont proposé des stratégies pour faciliter la transition (même Linus s'est invité pour indiquer, crûment, sa préférence).
Parmi les nouveautés à attendre dans les prochaines versions du noyau on trouve ainsi un nouveau mutex (bkldev_mutex) qui est posé dans la couche en mode bloc (block layer) sur tous les pilotes qui faisaient auparavant appel au BKL.
Dans TTY c'est également un mutex local (le "Big TTY Mutex") qui a été posé sur ce sous-système en remplacement du Big Kernel Lock global.
Les appels aux fonctions ioctl() et llseek() qui reposaient dans certains cas sur le BKL ont été audités et les fonctions ont été nettoyées dans la perspective d'une éradication complète dans l'avenir.
Le code présent dans init/main.c et qui utilisait sans raison particulière le verrou global a été retiré.
Outre le travail de fond d'Arnd Bergmann il y a également Andi Kleen qui a travaillé sur la couche USB et Frédéric qui se penche sur la situation de procfs.
Un article du site LWN évoque également la possibilité d'une option de configuration CONFIG_BKL qui permettrait, peut-être dès le noyau 2.6.35, d'enlever complètement le support du verrou géant du noyau. C'est une bonne méthode pour repérer facilement tout ce qui repose encore sur le BKL et qui ne marche plus quand on l'enlève.
Pour documenter tous ces nouveaux efforts d'éradication du BKL une page spéciale du wiki de kernelnewbies a été créée. Cette page vous permettra d'approfondir le rapide survol esquissé ici et, peut-être, vous incitera à vous lancer à votre tour dans le combat glorieux contre le BKL !

Aller plus loin

Les nouveautés du noyau 2.6.34 (70 clics)
Le bilan des ajouts partie 1 (8 clics)
Le bilan des ajouts partie 2 (5 clics)
Les articles de H-Online (7 clics)
Les prévisions pour l'avenir de Linux (15 clics)

# Attention

Posté par 2PetitsVerres le 17 mai 2010 à 13:08. Évalué à 9.

Tous ceux qui vont dire merci patrick_g< t'es trop génial (ou approchant) je les moinsse.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
- [^] # Re: Attention
  
  Posté par monde_de_merde le 17 mai 2010 à 13:16. Évalué à -8.
  
  merci patrick_g< t'es trop génial (ou approchant) je les moinsse.
- [^] # Re: Attention
  
  Posté par Anonyme le 17 mai 2010 à 13:38. Évalué à -10.
  
  mince patrick_g j'en ai marre de la longueur de ces news, c'est imbuvable.
  - [^] # Réponse à prendre au 1er degré
    
    Posté par tom120934 le 17 mai 2010 à 15:07. Évalué à 5.
    
    J'ai souvent tendance à remercier patrick_g pour la qualité de ses news / journaux, mais là je dois reconnaître qu'il fait très fort.
    
    C'est le premier article de sortie d'un nouveau kernel que je lis (oui ok honte sur moi) et j'ai été _ravi_. Oui la répartie des kernel hackers est distrayante (Linus en tête) et c'est ainsi plus enthousiasmant/facile à lire. Mais au delà de ça, les explications techniques sont un mine d'infos pour un profane (mes années de C/C++ sont loin derrière moi) et me fait encore plus apprécier le travail caché derrière ma distrib.
    
    Donc, véritablement au 1er degré : MERCI POUR LE POISSON !
    
    Lâchez vos moinssages :)
- [^] # Re: Attention
  
  Posté par rewind (Mastodon) le 17 mai 2010 à 14:12. Évalué à 10.
  
  approchant !
  
  J'ai bon ?
- [^] # Re: Attention
  
  Posté par Colin Pitrat (site web personnel) le 17 mai 2010 à 15:40. Évalué à 5.
  
  Tout à fait d'accord, c'est tellement évident que patrick_g est un faux compte et qu'il y a une armée de journalistes techniques derrière ... C'est du stakhanovisme !
  - [^] # Re: Attention
    
    Posté par JP Martin le 18 mai 2010 à 23:39. Évalué à -2.
    
    c'est clair !
    
    Et c'est avec un réel plaisir que je lis son journal à chaque sortie de noyau.....
    
    Merci patrick_g pour ton formidable travail de pigiste
    
    NB : vivement le prochain
    - [^] # Re: Attention
      
      Posté par windu.2b le 19 mai 2010 à 00:42. Évalué à 7.
      
      Pigiste ?!?
      J'ai déjà lu des articles de fond de journalistes renommés être bien moins creusés que ça...
# Le jeu du lundi

Posté par patrick_g (site web personnel) le 17 mai 2010 à 13:54. Évalué à 10.

Toi aussi cherche le mot magique caché dans la dépêche : https://linuxfr.org/comments/1125652.html#1125652
- [^] # Re: Le jeu du lundi
  
  Posté par Jehane le 17 mai 2010 à 13:58. Évalué à 5.
  
  Trouvé
  
  Je le mets ici ?
  - [^] # Re: Le jeu du lundi
    
    Posté par patrick_g (site web personnel) le 17 mai 2010 à 14:14. Évalué à 8.
    
    En ROT13 alors.
    - [^] # Re: Le jeu du lundi
      
      Posté par khivapia le 17 mai 2010 à 15:07. Évalué à 10.
      
      cerzvrerf yrggerf qrf cerzvref cnentencurf qr yn cnegvr "Ra oers"
      - [^] # Re: Le jeu du lundi
        
        Posté par imr le 17 mai 2010 à 17:38. Évalué à 9.
        
        Holy Cow, batman! Je n'aurais jamais trouvé.
        Et les 3 "L" à la fin, pour "le logiciel libre", c'est carrément subversif, ça dénonce grave. Il va avoir des problèmes avec les GNU/commissaires politiques.
# Dallas...

Posté par gnumdk (site web personnel) le 17 mai 2010 à 13:55. Évalué à 10.

Je ne sais pas ce qui est le plus intéressant, la partie technique ou la partie sociale de la nouvelle :)

En tout cas, je ne sais plus quel "kernel hacker" (1) définissait Linus comme "le dictateur bienfaisant" mais cela semble proche de la réalité :)

(1) C'est dans la vidéo "The code", la monsieur qui explique ce qu'est un noyau.
- [^] # Re: Dallas...
  
  Posté par Zenitram (site web personnel) le 18 mai 2010 à 05:53. Évalué à 9.
  
  "le dictateur bienfaisant" mais cela semble proche de la réalité :)
  
  Il y a une grosse différence très intéressante sur les dictatures dans le cas du libre : si suffisamment de monde n'est pas content du dictateur qui ferait des choses débiles, il peut élire un autre qui devra montrer qu'il est meilleur au final et amène plus de monde avec lui.
  Et ça, c'est quelque chose qui n'existe pas dans la vraie vie où on a des dictateurs... Dictateur, oui, mais qui peut dégager rapidement si il fait trop n'importe quoi, les avantages de la dictature (réactivité etc...) sans (trop) les inconvénients en quelque sorte, que du bonheur!
  - [^] # Re: Dallas...
    
    Posté par Boa Treize (site web personnel) le 18 mai 2010 à 09:52. Évalué à 5.
    
    > Dictateur, oui, mais qui peut dégager rapidement si il fait trop n'importe quoi
    
    Ça dépend comment le projet est organisé. Avec une infrastructure moderne décentralisée à base de Git entre autres, c'est tout à fait vrai. Dans certains vieux projets où toute l'infrastructure (serveurs, mailing lists) est dans les mains de quelques uns, les choses sont beaucoup plus compliquées. On peut toujours forker, mais il faut repartir de presque zéro.
    - [^] # Re: Dallas...
      
      Posté par reno le 18 mai 2010 à 12:03. Évalué à 5.
      
      Ce qui est amusant, c'est que Linus a fortement poussé (*) pour justement décentraliser l'infrastructure autour de Linux: un "dictateur" qui soutient les outils qui permettraient de le remplacer en fait..
      
      *: bon il faut dire qu'il y a eu une période ou Linus était considéré comme un goulet d'étranglement pour Linux (je n'ose même pas imaginer le nombre de patch qu'il devait recevoir chaque jour): ca fait une bonne motivation pour décentraliser le système..
  - [^] # Re: Dallas...
    
    Posté par windu.2b le 18 mai 2010 à 13:31. Évalué à 10.
    
    Si on se réfère au sens qu'avait le mot "'dictateur"[1] sous la Rome antique, on est déjà un peu plus dans le vrai : un homme, désigné par le Sénat, qui reçoit les pleins pouvoirs de ce dernier, mais peut le perdre tout aussi vite et qui, de toute façon, ne l'a que pendant une durée limitée (pouvant être reconduite).
    Linus est un dictateur dans le sens où la communauté le reconnait comme le maître du noyau Linux et c'est à lui que sont confiés les décisions finales (commit des patches, ...). Mais si demain la communauté venait à en choisir un autre, Linus ne pourrait pas faire grand chose contre ça...
    
    1 http://fr.wikipedia.org/wiki/Dictateur_%28Rome_antique%29
    - [^] # Re: Dallas...
      
      Posté par FantastIX le 19 mai 2010 à 18:33. Évalué à 2.
      
      Disons que dans la Rome antique, dégager le dictateur en cours s'avérait souvent fatal pour lui... Heureusement on a quelque peu progressé depuis ;) .
  - [^] # Re: Dallas...
    
    Posté par Gof (site web personnel) le 18 mai 2010 à 19:37. Évalué à 2.
    
    Si suffisamment de monde n'est pas content du dictateur, il y peut y avoir une révolution.
# enfin

Posté par exolin le 17 mai 2010 à 14:08. Évalué à 2.

J'attendais l'article avec impatience après avoir eu l'écho des «soucis » qui s'étaient produits avec nouveau. Après lecture le problème reste assez flou: il est demandé aux développeurs de réaliser tout changement dans l'interface externe avant l'inclusion dans le noyau?

Sinon est-il prévu un jour l'accélération 3D pour le pilote radeon (pour une vielle X800 notamment)?

Bon article plaisant à lire comme toujours :)
- [^] # Re: enfin
  
  Posté par glisse le 17 mai 2010 à 14:25. Évalué à 4.
  
  l'accel 3D sur X800 est dispo dans mesa depuis 5-6ans de memoire ...
  - [^] # Re: enfin
    
    Posté par Thomas Douillard le 17 mai 2010 à 15:11. Évalué à 1.
    
    gni ?
    
    Pour quelqu'un qui n'est pas à fond dedans, c'est quoi les sous entendu de ta réponse ?
    - [^] # Re: enfin
      
      Posté par ʭ ☯ le 17 mai 2010 à 15:17. Évalué à 8.
      
      Que tu n'as probablement pas essayé un logiciel 3D dans ta distribution favorite depuis 5 ans ;-)
      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
    - [^] # Re: enfin
      
      Posté par glisse le 17 mai 2010 à 16:27. Évalué à 3.
      
      Au debut je voulais faire une blague sur la necessite de faire des apt-get update/upgrade un peu plus souvent puis je me suis dis que c'etait pas drole. Cela etant dis je suis sidere que des gens ne se rendent pas compte que des drivers 3d existe, 5 ans apres. En faite je me demande ou les gens vont chercher leur informations ...
      
      J'avais aussi oublie de remercier Patrick pour sa depeche. Allez bonne journee a tous.
  - [^] # Re: enfin
    
    Posté par ʭ ☯ le 17 mai 2010 à 15:16. Évalué à 9.
    
    C'est le module DRI r300 qui les gère, ça fait exactement depuis le 19 Mai 2005 que la X800 est annoncée comme fonctionnant sans blocages - donc 5 ans et 2 jours!
    
    Source : http://r300.sourceforge.net/
    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
    - [^] # Re: enfin
      
      Posté par Ph Husson (site web personnel) le 17 mai 2010 à 23:02. Évalué à -1.
      
      L'IPoT fait des ravages. (ou alors un an = 365jours ?)
  - [^] # Re: enfin
    
    Posté par exolin le 17 mai 2010 à 16:47. Évalué à 2.
    
    Ubuntu doit avoir oublier de m'installer 2-3 trucs depuis quelques releases alors (ou il aime faire souffrir le pauvre processeur qui sait!)
    
    Merci pour les informations en tout cas ;)
    - [^] # Re: enfin
      
      Posté par VINDICATORs le 18 mai 2010 à 16:04. Évalué à 1.
      
      Fedora intègre les dernières évolution du pilote xorg-x11-drv-ati "radeon" avec mesa-dri-drivers depuis Fedora 12.
      
      L'accélération est matériel avec les évolutions de mesa qui intègre une bonne partie des développement de Galium3D.
      
      Tout n'est pas parfais, mais cela avance dans le bon sens.
      
      Je parle bien sur du pilote en version 2.6.13, de mesa 7.7 et +.
      
      Par contre pour Ubuntu...
# Coquilles

Posté par Tsomi le 17 mai 2010 à 15:39. Évalué à 6.

Ploup,

>> et bien maintenant vous devrez attendre le 2.6.35.
=>
>> eh bien maintenant vous devrez attendre le 2.6.35.

>> Tu a demandé que ce soit incorporé quand même et maintenant tu n'est pas content
=>
>> Tu as demandé que ce soit incorporé quand même et maintenant tu n'es pas content

>> C'est *toi* qui a poussé pour que Nouveau intègre la branche staging
=>
>> C'est *toi* qui as poussé pour que Nouveau intègre la branche staging

Et sinon, dépêche de qualité, comme d'hab.
a systems programmer has seen the terrors of the world and understood the intrinsic horror of existence
- [^] # Re: Coquilles
  
  Posté par patrick_g (site web personnel) le 17 mai 2010 à 15:52. Évalué à 3.
  
  Fautes corrigées, merci (sauf la première pour laquelle je ne suis pas convaincu, il y a une règle officielle là-dessus ?).
  - [^] # Re: Coquilles
    
    Posté par Tsomi le 17 mai 2010 à 16:13. Évalué à 1.
    
    Ah, dans « l'officiel » je trouve bien ça :
    [http://tinyurl.com/35ywemr]
    
    ...mais je dois avouer que je ne trouve rien de l'Académie qui réprouve explicitement l'orthographe « et bien ». Ça m'étonne, venant d'eux !
    
    Donc ça sera un... au temps pour moi :)
    a systems programmer has seen the terrors of the world and understood the intrinsic horror of existence
    - [^] # Re: Coquilles
      
      Posté par Tsomi le 17 mai 2010 à 16:18. Évalué à 2.
      
      Arf, Templeet n'a pas l'air trop copain avec les liens à rallonge de Google books, et tinyurl ne s'en sort pas mieux.
      
      On va dire Dictionnaire de l'Académie française, Volume 1, page 186, alors.
      
      Encore désolé.
      a systems programmer has seen the terrors of the world and understood the intrinsic horror of existence
  - [^] # Re: Coquilles
    
    Posté par windu.2b le 17 mai 2010 à 16:26. Évalué à 6.
    
    Dans le genre "officiel", je peux te proposer ce passage d'une (célèbre) fable de La Fontaine :
    
    Vous chantiez? j'en suis fort aise:
    Eh bien! dansez maintenant.
    - [^] # Re: Coquilles
      
      Posté par patrick_g (site web personnel) le 17 mai 2010 à 16:49. Évalué à 4.
      
      Il n'y a pas plus officiel que La Fontaine donc je rends les armes.
      Faute corrigée.
  - [^] # Re: Coquilles
    
    Posté par Renault (site web personnel) le 17 mai 2010 à 21:37. Évalué à 1.
    
    Petite faute « Fedora n'est pas la seule bien entendu. Ubuntu a fait ça également, et pire même, avec des pilotes binaires. Mais ce n'est pas parce que Ubuntu à fait pire qu'il ne faudrait rien dire sur Fedora dans ce cas là ». »
    - [^] # Re: Coquilles
      
      Posté par patrick_g (site web personnel) le 17 mai 2010 à 23:06. Évalué à 2.
      
      Corrigé. Ah vivement un beau correcteur grammatical sous Linux.
      - [^] # Re: Coquilles
        
        Posté par ʭ ☯ le 18 mai 2010 à 10:30. Évalué à 7.
        
        En tout cas, il est pointilleux, celui de Linuxfr! Le jour où j'ai un texte à faire relire, je le mets dans un journal ;-)
        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
  - [^] # Re: Coquilles
    
    Posté par liberforce (site web personnel) le 18 mai 2010 à 21:08. Évalué à 2.
    
    breackpoint => breakpoint
    - [^] # Re: Coquilles
      
      Posté par patrick_g (site web personnel) le 18 mai 2010 à 21:53. Évalué à 2.
      
      Corrigé.
- [^] # Re: Coquilles
  
  Posté par Naha (site web personnel) le 17 mai 2010 à 16:57. Évalué à 2.
  
  Et d'autres :
  
  s/pleins/plein/ (exemple : « Il y a plein de pichets pleins »)
  
  s/à besoin/a besoin/
  
  s/du le Big Kernel Lock/du Big Kernel Lock/
  - [^] # Re: Coquilles
    
    Posté par patrick_g (site web personnel) le 17 mai 2010 à 16:59. Évalué à 2.
    
    Merci, c'est corrigé.
- [^] # Re: Coquilles
  
  Posté par Donk le 17 mai 2010 à 18:00. Évalué à 2.
  
  Section "Système de fichiers Ceph", le lien vers le fichier odp n'est pas bon.
  Ainsi que le lien vers la vidéo de Dailymotion dans la section "VGA-Switcheroo"
  - [^] # Re: Coquilles
    
    Posté par patrick_g (site web personnel) le 17 mai 2010 à 18:26. Évalué à 2.
    
    C'est corrigé. Encore Templeet qui avait mangé des balises.
- [^] # Re: Coquilles
  
  Posté par Dreamkey le 17 mai 2010 à 18:03. Évalué à 1.
  
  Deux autres :
  Partie "RC-4" : Borislav pour imaginer d'où pouvait
  Partie "Une flame war" : autant de traffic c'est qu'il est fondamentablement au sujet
  
  Mais je n'ai pas encore pu tout lire, peut-être d'autres se cachent :p
  - [^] # Re: Coquilles
    
    Posté par patrick_g (site web personnel) le 17 mai 2010 à 18:29. Évalué à 2.
    
    Corrigé. Merci d'avoir signalé les fautes.
    Je propose que tu utilises la tribune rédacteur [https://linuxfr.org/redacteurs/] pour signaler les autres afin d'éviter de poster trop de commentaires d'ortho sous la news.
    - [^] # Re: Coquilles
      
      Posté par windu.2b le 17 mai 2010 à 18:37. Évalué à 3.
      
      Autre faute, enfin si j'ai bien tout compris : le nom du noyau (Sheep on Meth) est annoncé dans la section "RC-6", alors que lorsqu'on regarde le diff, c'est lors de la sortie de la RC-5 qu'il semble avoir choisi ce nom.
      D'ailleurs, le diff en question date du 19/04 (date de la RC-5) et non du 29/04...
      - [^] # Re: Coquilles
        
        Posté par Davy Defaud le 17 mai 2010 à 18:49. Évalué à 1.
        
        Une autre dans le paragraphe sur la RC5 :
        
        « La plus notable pour les gens qui eu le problème »
        
        [^] # Re: Coquilles
        
        Posté par patrick_g (site web personnel) le 17 mai 2010 à 18:54. Évalué à 4.
        
        Corrigé. Merci de me l'avoir signalé.
        Je pense qu'il va falloir trouver un système plus intelligent pour signaler toutes les (innombrables) coquilles sans poster des commentaires dans la news.
        La tribune rédacteur peut-être ?
        
        [^] # Re: Coquilles
        
        Posté par Sytoka Modon (site web personnel) le 18 mai 2010 à 20:13. Évalué à 4.
        
        Moi j'aime bien ces corrections en direct pour deux raisons :
        
        - je vois qu'il y a pas que moi qui fait des fotes ;-)
        
        - je lis et j'apprends en voyant les corrections proposées
        
        Bref, tout cela est très pédagogique et très communautaire.
        
        [^] # Re: Coquilles
        
        Posté par patrick_g (site web personnel) le 18 mai 2010 à 21:07. Évalué à 3.
        
        Certes...mais à chaque fois mon moral en prend un coup. Avoir imprimé la news pour la relire et avoir laissé passé autant de trucs c'est déprimant.
        M'enfin bon le principal c'est que la news s'améliore à chaque correction ;-)
      - [^] # Re: Coquilles
        
        Posté par patrick_g (site web personnel) le 17 mai 2010 à 18:50. Évalué à 3.
        
        Ouaip, après vérification je confirme que tu as raison. Un véritable oeil de lynx ;-)
        Je laisse comme ça car ce n'est pas une pure faute d'ortho ou de grammaire et ça nécessiterait de reprendre l'organisation des RC.
- [^] # Re: Coquilles
  
  Posté par moi1392 le 18 mai 2010 à 15:09. Évalué à 2.
  
  puisqu'on est dans les coquilles :
  
  "tu nous l'aS demandé"
  - [^] # Re: Coquilles
    
    Posté par patrick_g (site web personnel) le 18 mai 2010 à 17:24. Évalué à 2.
    
    Done.
- [^] # Re: Coquilles
  
  Posté par Zarmakuizz (site web personnel) le 18 mai 2010 à 17:10. Évalué à 2.
  
  Patch great_patrickg_kernel_2.6.34_ortho9 :
  En effet une limitation importante de vga_switcheroo c'est qu'il oblige a redémarrer le serveur X si on veut que la bascule soit effective.
  =>à
  Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
  - [^] # Re: Coquilles
    
    Posté par patrick_g (site web personnel) le 18 mai 2010 à 17:24. Évalué à 2.
    
    Fait. Merci.
- [^] # Re: Coquilles
  
  Posté par Dreamkey le 18 mai 2010 à 21:29. Évalué à 1.
  
  J'en ai encore trouvé :
  Partie "Mise en veille asynchrone" : décisions pertinentes quant à leur gestion
  "En bref" : tête de lecture (seek). L'heuristique
  "En bref" : ce module s'utilise soit en passant des arguments lors du chargement (au moment du insmod). Maintenant [... ] -> il manque un soit
  
  Sinon il me semble qu'il manque un "pour" quelque part, mais je n'arrive pas à retrouver où.
  - [^] # Re: Coquilles
    
    Posté par patrick_g (site web personnel) le 18 mai 2010 à 21:54. Évalué à 2.
    
    On s'approche asymptotiquement de la perfection !
    Merci pour les remarques, c'est corrigé.
# perf trace -s timechart.py

Posté par Pierre le 17 mai 2010 à 15:42. Évalué à 4.

a noter en passant le support de perf scripting python par pytimechart, une interface graphique rapide pour regarder les donnees extraites avec timechart.

http://lkml.org/lkml/2010/5/11/367

Le mieux est de regarder un peu ces screencast pour ce faire une idee:

a look at mplayer startup:
http://tardyp.free.fr/pytimechart/mplayer_start.mp4
a look at ubuntu boot:
http://tardyp.free.fr/pytimechart/boot.mp4
- [^] # Re: perf trace -s timechart.py
  
  Posté par fweisbec le 17 mai 2010 à 18:12. Évalué à 2.
  
  Oui et ce serait bien de l'avoir upstream ;-)
# Erreur : HTML invalide

Posté par Pinaraf le 17 mai 2010 à 18:08. Évalué à 6.

Belle dépêche, à un détail près qui pique les yeux dans Konqueror : y'a des erreurs dans le code HTML pour le premier titre, je cite :
«<h2><a name="test">La phase de test</a> (<a href="#sommaire">↑</a>)</h2<h3><a name="rc1">RC-1</a></h3><br />»

Il manque un > pour le </h2>…
- [^] # Re: Erreur : HTML invalide
  
  Posté par patrick_g (site web personnel) le 17 mai 2010 à 18:32. Évalué à 2.
  
  ça devrait être bon maintenant.
# Encore un probleme pour l'affichage..

Posté par reno le 17 mai 2010 à 18:16. Évalué à 2.

Décidément le matériel évolue tellement rapidement pour l'affichage que le logiciel est (encore une fois) dépassé: même pas le temps d'exploiter (enfin) correctement l'accélération 3D, que le changement a chaud des GPU arrive et s'avère aussi incompatible avec l'architecture existant..

Je me demande si les futurs CPUs qui intègreront la carte graphique (un concept que je trouve plutôt curieux d'ailleurs car le CPU a une bande passante mémoire bien inférieure a celle d'un GPU) vont encore nécessiter de tout casser????
- [^] # Re: Encore un probleme pour l'affichage..
  
  Posté par lolop (site web personnel) le 17 mai 2010 à 20:37. Évalué à 9.
  
  Est-ce que ça ne serait pas plutôt les futurs GPU qui intègreront un petit CPU :-)
  Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Antisocial

Posté par Frank-N-Furter le 17 mai 2010 à 18:20. Évalué à 5.

Faidora saymal, elle perd son sang froid.
Depending on the time of day, the French go either way.
- [^] # Re: Antisocial
  
  Posté par imr le 17 mai 2010 à 20:22. Évalué à 4.
  
  redhat fail:
  http://linuxfr.org/~GeneralZod/29685.html
  avec Theodore T'so (kernel hacker bien connu) dans le rôle du boomerang.
  
  Ce que j'ai trouvé intéressant, c'est que ce que pas mal de monde disait sur les drivers libres expérimentaux ou pulse audio dans pleins de posts quand ils sont enfoncés de force Dans Les Computers des utilisateurs qu'ils transforment en bétas testeurs malgrè eux, à savoir que ça ne sert pas le libre mais red hat, trouve ici son exacte correspondance avec les hackers du noyau:
  
  They only care about their narrow point of view, and don't care about the pain they are inflicting on the kernel development process and other kernel developers. This is _legal_. It is, however, anti-social."
  
  A noter qu'il parle de douleur et pas d'inconvénients comme dans la traduc de l'article, c'est beaucoup plus fort. Douleur + comportement anti social, on parle bien là de violence.
  - [^] # Re: Antisocial
    
    Posté par Gniarf le 17 mai 2010 à 21:08. Évalué à 1.
    
    comme KDE 4, quoi :)
    - [^] # Re: Antisocial
      
      Posté par imr le 17 mai 2010 à 22:07. Évalué à 3.
      
      Oui, aussi. :(
    - [^] # Re: Antisocial
      
      Posté par grid le 18 mai 2010 à 15:00. Évalué à 4.
      
      oui, mais la faute n'incombe pas à KDE4 ou au driver Nouveau, c'est parce que les distributions font la course à la nouveauté (pure raison marketting et non technique)
      
      Slackware est plus conservateur dans les technologies, ce qui fait que c'est souvent plus stable.
      - [^] # Re: Antisocial
        
        Posté par reno le 18 mai 2010 à 15:50. Évalué à 0.
        
        Bof, se plaindre qu'une distribution comme Fedora faite par RedHat pour tester des nouveautés fasse la course a la nouveauté, cela me fait bien rire..
        
        Après oui il y a des distributions "grand publiques" telle Ubuntu qui font n'importe quoi en incluant du code pas vraiment mature (je pense a PulseAudio) dans leur nouvelles versions..
        
        [^] # Re: Antisocial
        
        Posté par barmic le 18 mai 2010 à 18:23. Évalué à 2.
        
        J'avais cru comprendre que ce n'était plus comme ça qu'il fallait la voir depuis que c'est devenue un projet communautaire. Il faut continuer de la voir comme une bêta de Red Hat ?
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Antisocial
        
        Posté par barmic le 18 mai 2010 à 15:50. Évalué à 6.
        
        Je ne connaît pas la vénérable, mais Debian est vachement bien foutu à ce niveau. Il est possible pour les développeurs de créer des paquets pour Sid et ainsi faciliter les tests sans pour autant pourrir la version stable.
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Antisocial
    
    Posté par patrick_g (site web personnel) le 17 mai 2010 à 22:35. Évalué à 1.
    
    >>> A noter qu'il parle de douleur et pas d'inconvénients comme dans la traduc de l'article
    
    Je pense que j'aurai du traduire par "le mal qu'ils infligent".
  - [^] # Re: Antisocial
    
    Posté par Mildred (site web personnel) le 18 mai 2010 à 13:09. Évalué à 7.
    
    En même temps ce n'est pas comme si chez Fedora ils ne disaient pas que le but de la distribution c'est de mettre en avant de nouvelles technologies, pas encore forcément disponibles dans les branches principales des projets upstream.
    
    C'est un des buts de Fedora, et je me vois mal les critiquer pour ça.
    
    Maintenant, c'est vrai que tester de nouveaux kernels sous Fedora n'est peut être pas évident. Pour ça, ce que je verrais de mieux, c'est faire un rapport de bugs, expliquant qu'il est impossible de tester un nouveau kernel sans douleur. Pas de critiquer sans fin Fedora.
    
    Les bugs, ça arrive à tout le monde.
    - [^] # Re: Antisocial
      
      Posté par VINDICATORs le 18 mai 2010 à 16:00. Évalué à 2.
      
      J'allais le dire ;), Fedora est un laboratoire en perpétuel développement. C'est bien défini depuis sa sortie!
      
      Pour les nouveaux noyau il suffit d'aller les chercher au bon endroit, style ici :-> http://koji.fedoraproject.org/koji/index . Après un nouveau noyau officiel, directement télécharger depuis le site officiel, peut s'installer sans problème.
      
      Après KDE4 est stable depuis un bon moment, en plus vous pouvez le configurer totalement pour retrouver ce qui était possible sous la version 3.xxx!
      
      Mais bon... Il y a des têtus qui n'aiment pas qu'ont leur disent leur quatre vérités...
    - [^] # Re: Antisocial
      
      Posté par imr le 19 mai 2010 à 02:19. Évalué à 8.
      
      En même temps ce n'est pas comme si chez Fedora ils ne disaient pas que le but de la distribution c'est de mettre en avant de nouvelles technologies
      C'est un des buts de Fedora, et je me vois mal les critiquer pour ça.
      
      Pas de critiquer sans fin Fedora. Les bugs, ça arrive à tout le monde.
      
      Tu fais une double attaque à l'épouvantail.
      http://en.wikipedia.org/wiki/Straw_man
      http://fr.wikipedia.org/wiki/%C3%89pouvantail_%28rh%C3%A9tor(...)
      Personne n'a dit ce à quoi tu réponds.
      
      Les kernel hackers n'ont pas attaqué fedora parce que son implémentation de nouveau est bugguée, mais parce que la nature des problèmes qu'elle a montre un manque de respect pour son upstream.
      
      Personne n'a attaqué fedora ici parce qu'elle est expérimentale mais parce que certains de ses utilisateurs ont pourri ubuntu pour exactement la même raison: manque de respect pour l'upstream.
      
      Or, depuis longtemps la situation est celle ci:
      d'un coté redhat contribue au desktop en promouvant des nouveautés en développement très expérimentales comme nouveau ou pulse audio, de l'autre une campagne de fond a lieu pour pourrir ceux qui ne les implémentent pas. Si tu implémentes pulse audio immédiatement, c-a-d si tu contribues upstream, tu es un bon citoyen.
      
      C'est une imposture intellectuelle de dire d'un coté, tu n'es pas obligé d'utiliser ces drivers/sous systèmes et de l'autre d'attaquer ceux qui ne le font pas sur les mêmes bases. C'est encore plus une imposture d'attaquer ensuite les distros d'être de mauvais citoyens parce que ces sous systèmes ne fonctionnent pas bien, c'est qu'ils ne contribuent pas assez, comme ubuntu est souvent attaquée ici.
  - [^] # Re: Antisocial
    
    Posté par Grunt le 18 mai 2010 à 19:19. Évalué à 0.
    
    C'est monstrueux, tu veux dire que des utilisateurs qui ont une carte graphique 3D pour bosser plus efficacement avec Compiz-Fusion se font imposer de force des pilotes buggés?
    Ils devraient réclamer le remboursement de leur licence OEM!
    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# Il parle de la transition KDE3 -> KDE4 la, non?

Posté par zaurus (site web personnel) le 17 mai 2010 à 20:38. Évalué à -9.

« Ma conclusion est claire comme le cristal. Changer une API d'un coup est une erreur, c'est dommageable, cela limite la base des développeurs, cela limite la base des testeurs, c'est une perte de temps et d'efforts. C'est une mauvaise décision technique. C'est du masochisme. Il y a peu de règles inconditionnelles dans le monde du libre mais cela en est une. »

Je ne m'en suis toujours pas remis personnellement.
Au boulot je garde un KDE3 qui est parametre de maniere a ce que je sois
hyper efficace, chez moi je teste d'autres WM pour dire adieu a KDE... :(
- [^] # Re: Il parle de la transition KDE3 -> KDE4 la, non?
  
  Posté par Tonton Benoit le 18 mai 2010 à 15:16. Évalué à 5.
  
  Il parle de la transition KDE3 -> KDE4 la, non?
  Non il parle de la migration Gnome 1.xx > 2 ^^
# Ceph, ca a l'air interessant ce systeme de fichiers!

Posté par zaurus (site web personnel) le 17 mai 2010 à 20:40. Évalué à 5.

C'est vrai que les FS distribues qui demandent pas un admin
a plein temps a configurer, ca se fait un peu attendre pour
les clusters...
# Patrick_G ?

Posté par bghflt (site web personnel) le 17 mai 2010 à 20:52. Évalué à -1.

Maintenant c'est confirmé, Patrick_G est un robot à architecture multi-scalaire.

Une analyse si détaillée ne peut provenir que de la NSA.
- [^] # Re: Patrick_G ?
  
  Posté par Littleboy le 18 mai 2010 à 02:22. Évalué à 2.
  
  Il est surtout abonne a LWN.net (d'ailleurs on peut le voir troller de temps en temps, genre sur Theora, mais ca marche beaucoup moins bien que sur LinuxFR...)
  - [^] # Re: Patrick_G ?
    
    Posté par Guillaume Knispel le 18 mai 2010 à 03:37. Évalué à 5.
    
    Contrairement à ici, la tradition de lwn n'est pas vraiment aux énormes trolls débridés dans les commentaires.
    
    J'aime les deux approches :P
  - [^] # Re: Patrick_G ?
    
    Posté par Sytoka Modon (site web personnel) le 18 mai 2010 à 09:44. Évalué à 7.
    
    Un abonnement LWN ne suffit pas à écrire de bonnes dépêches sur DLFP ;-)
    - [^] # Re: Patrick_G ?
      
      Posté par WhiteCat le 18 mai 2010 à 16:02. Évalué à 1.
      
      Oui, il faut se taper tous les mails de la LKML, et ça je suis pas encore tout à fait prêt à le faire tout seul ^^
# A propos de l'USB

Posté par freejeff le 17 mai 2010 à 22:04. Évalué à 5.

Ça fait longtemps que je me pose la question, mais est ce qu'il existe une pile usb préemptive ?

Sans vouloir dire de bétises, il me semble que Ingo Molnar a introduit la possibilité d'avoir une version RT d'un noyau classique avec l'option CONFIG_PREEMPT_RT (Attention, je ne saurais être précis la dessus) appelée "hard-realtime scheduling". Cette option permet notament aux gens faisant de l'audio de réduire drastiquement la latence. Je citerai Linus :

"Controlling a laser with Linux is crazy, but everyone in this room is crazy in his own way. So if you want to use Linux to control an industrial welding laser, I have no problem with your using PREEMPT_RT." -- Linus Torvalds

J'ai utilisé de manière tout à fait satisfaisante le noyau packagé par debian linux-rt dans le cadre d'une version d'ubuntu-studio avec des cartes d'acquisitions PCI, mais je n'ai jamais eu de bons résultats (voir bien pire qu'avec la version classique du noyau) avec une carte usb.
Il semble que cette pile (je ne sais pas si ce terme convient, j'aurais a priori dit "driver" sans conviction) ne soit pas capable de fonctionner sans aberrations i.e : valeur d'acquisitions erratiques, j'avais trouvé USB4RT, mais ça date de 2005 et le patch de Ingo n'a été introduit qu'à partir de fin 2007 !

Je me permets donc (vu que c'est LA news ou je peux le faire) de demander aux gens qui sont un peu plus dans la technicité que moi s'ils connaissent des moyens de faire de l'USB en RT, et si oui est il possible de le faire sans un gros hack condamnant le pc à ne plus subir aucune mis à jour.

Est-ce que quelqu'un a déjà vu ça passer ce sujet sur la LKML (oui, je sais, je pourrais chercher moi même), suis-je le seul à me poser cette question ?

Pour info la granularité temporelle que j'ai réussi à atteindre sur une carte PCI est de l'ordre de 100 kHz stable (limite de la carte d'acquisition) sans buffer et de 1 kHz avec des erreurs en USB.
- [^] # Re: A propos de l'USB
  
  Posté par Guillaume Knispel le 18 mai 2010 à 03:45. Évalué à 6.
  
  Les noyaux généralistes ne sont pas vraiment conçus pour faire du temps réel dur déterministe. Rien que 1kHz avec quelques centaines de us de jitter peut-être dur à atteindre (et même sur du PCI), selon le hard présent dans la machine et les driver, et même le code de la CM qui fait des trucs derrière le dos de l'OS en mode de management.
  
  Donc même sans considérer le noyau, les PC généralistes (style station, laptop ou serveur quelconque) ne sont pas vraiment conçus pour faire du temps réel. On peut avoir de la chance, ... ou non !
  
  Tant mieux si tu as réussis à atteindre 100kHz stable sur une carte PCI, mais ne t'attend pas à ce que ce résultat soit largement reproductible sur pleins de PC différents, voire peut-être même deux version de Linux différente si tu as pas trop de bol.
  - [^] # Re: A propos de l'USB
    
    Posté par freejeff le 18 mai 2010 à 09:12. Évalué à 3.
    
    N'était ce pas la raison du patch du noyau ?
    
    Il me semble de plus que même si linux est un noyau "généraliste", sa base est massivement utilisée dans l'embarqué avec les processeur arm de type 7, 9 et cortex A8. Je sais qu'il y a quelques changements, mais ça n'en est pas moins un linux.
    - [^] # Re: A propos de l'USB
      
      Posté par Nicolas Boulay (site web personnel) le 18 mai 2010 à 13:01. Évalué à 5.
      
      Les patch RT sont fait pour diminuer le jitter pour les timer d'une précision autour de la milliseconde.
      
      En gros pour des timer à 1 ms, tu peux avoir 1ms de jitter sur un linux normal qui tombe à qq dizaine de µs en RT.
      
      Rien n'est magique. J'avais entendu parler il ya longtemps de drivers proprio nvidia qui pouvait utiliser le bus PCI pendant 300ms !
      "La première sécurité est la liberté"
      - [^] # Re: A propos de l'USB
        
        Posté par freejeff le 18 mai 2010 à 17:47. Évalué à 2.
        
        Il me semble que même sur un noyau non RT, il existe des High Resolution Timer qui permettent d'avoir une granularité d'une µs ?
        
        Je pense que cette granularité couplée à un jitter de 10 µs est largement suffisante pour beaucoup d'applis non ?
        
        [^] # Re: A propos de l'USB
        
        Posté par Nicolas Boulay (site web personnel) le 19 mai 2010 à 12:46. Évalué à 2.
        
        Le timer a la granularité mais cela ne veut pas dire que Linux va le respecter.
        
        Il y a plein de raisons : driver avec fonction longue non interruptible, attente de BKL/sémaphore/mutex/spinlock/..., transfert PCI long, etc...
        "La première sécurité est la liberté"
# Encore un noyau ? / Linus geule à la place de parler calmement?

Posté par DrBuenol le 17 mai 2010 à 22:06. Évalué à -10.

Aves la centaine de systéme de fichier et pilotes et autres, c'est plus un noyau....(à mon sens)

Et le fait que Linus geule sur tous et (on dirait) tent d'imposé son opinion....c'est pire que tout
- [^] # Re: Encore un noyau ? / Linus geule à la place de parler calmement?
  
  Posté par WhiteCat le 18 mai 2010 à 16:08. Évalué à 7.
  
  Tu es sûrement plus compétent pour définir ce que devrait être un "noyau" ?
  
  Linus gueule sur tout, mais visiblement tous les développeurs (et les sociétés qui les embauchent) semblent s'en accommoder. Et je pense qu'ils se foutent pas mal du genre d'avis que tu donnes, vu que tu n'as sûrement jamais contribué à Linux (vu ta 1ère remarque je pense pouvoir l'affirmer).
- [^] # Re: Encore un noyau ? / Linus geule à la place de parler calmement?
  
  Posté par liberforce (site web personnel) le 18 mai 2010 à 21:14. Évalué à 6.
  
  Toi t'es nouveau par ici...
# btrf compress_force

Posté par john_labite le 19 mai 2010 à 15:54. Évalué à 2.

salut,

l'option BTRFS au mount 'compress-force' dont tu parles, si j'ai bien compris, fait en sorte que tous nouveaux fichiers écrits sur la partoche soient compressés
Btrfs utilise un heuristique pour déterminer si un fichier offrira un bon ratio de compression (en analysant les quelques premiers octets d'un fichiers je crois notamment), et désactive la compression sinon.

Il ne me semble pas que ce soit -encore- possible de le faire fichier par fichier (même s'il existe un flag COMPRESS par inode)

ma petite correction, sur le bon -et excellent- article cette fois
etienne
- [^] # Re: btrf compress_force
  
  Posté par patrick_g (site web personnel) le 19 mai 2010 à 17:33. Évalué à 3.
  
  >>> Il ne me semble pas que ce soit -encore- possible de le faire fichier par fichier
  
  Tu est sûr ? Ce n'est pas comme ça que je comprends ce commit (mais je me gourre peut-être) : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)
  
  Il y a aussi le mail de pull de Chris Mason qui en parle : http://thread.gmane.org/gmane.linux.kernel/961862
  
  "I added the ability to compress a single file on demand and defrag only a range of bytes in the file".
  - [^] # Re: btrf compress_force
    
    Posté par john_labite le 20 mai 2010 à 15:51. Évalué à 1.
    
    ha, excellent!
    si je comprend bien, il faut 'juste' defragmenter un fichier pour activer la compression dessus (même si j'ignore comment passer comme argument le flag de compression);
    il va falloir tester :)
    
    a+
# Module toshiba-acpi et hotkeys

Posté par Jllc le 24 mai 2010 à 22:26. Évalué à 1.

J'ai un petit problème avec ce noyau 2.6.34 et les touches spéciales (hotkeys) sur mon portable Toshiba.

On peut voir dans le changeLog qu'il y a eu des évolutions au niveau du module toshiba-acpi, qui (comme son nom l'indique) gère l'ACPI des Toshiba :

toshiba-acpi: fix multimedia keys on some machines
toshiba_acpi: Add full hotkey support

Avec ces évolutions, les combinaisons de touches avec Fn ne marchent plus (mise en veille notamment). Jusqu'à présent, c'était géré par le démon fnfxd. Si j'ai bien compris les différences de code C avec le noyau précédent, ces touches sont directement gérées par l'ACPI.

Problème, je ne sais pas quels programme doit maintenant les gérer (et j'ai bien cherché sur mon moteur de recherche favori). Quelqu'un saurait me dire quel démon je dois installer ou mettre à jour pour gérer à nouveau ces touches spéciales avec ce nouveau noyau ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.