Comme d'habitude le code source de ce nouveau Linux stable est téléchargeable sur les serveurs du site kernel.org.
Détails des évolutions, nouveautés et prévisions dans la suite... La phase de test...
- La version candidate RC-1 a été annoncée le 28 juillet par Linus qui a souligné la taille impressionnante de cette version : "Cela fait deux semaines (et un jour) et la période des modifications est terminée. Je ne sais pas pourquoi mais j'ai l'impression que cette période aura été sacrément active. La taille du patch de la RC-1 soutient ce sentiment puisqu'avec 12 Mo il est environ 50% plus gros que le patch 2.6.26-RC-1.
Cette taille me rend un peu nerveux. C'est vrai cela signifie que nous sommes vraiment bons pour inclure toutes les nouveautés mais je dois dire que je me demande parfois si nous n'incluons pas trop de choses à la fois et si notre cycle de sortie (déjà court) n'est pas en fait trop gros. Mais bon cette discussion est pour une autre fois.
Il y a une tonne de nouveaux trucs là-dedans mais pour moi les choses les plus intéressantes sont la traque du verrou global et peut-être l'introduction de la fonction get_user_pages_fast() sans verrou.
D'autres trucs ? Le chargement des firmwares, le travail de fusion des branches x86 qui continue. De plus en plus de code qui devient générique. Le support des machines de 4096 processeurs, etc.
Allez sur kernelnewbies ou sur Linux Weekly News pour plus de détails. Moi je vais dormir pendant 24 heures ;)"
- Une semaine après cette première version candidate Linus a annoncé la version RC-2 :"Il y a plein de changements divers là-dedans et j'espère que nous allons commencer à ralentir un peu les choses. Il y a quand même un truc particulier qu'il est peut-être bon de souligner du fait des conséquences éventuelles : un certain nombre d'architectures ont utilisé "l'accalmie" après la RC-1 (Hah!) pour effectuer le renommage include/asm-nom-de-l'architecture => 'arch/nom-de-l'architecture/include/asm. (...) Sinon il y plein d'autres petits changements mais rien qui ne puisse provoquer un « Wow! ». Notez qu'à l'étape RC-2 il ne devrait de toute façon pas y avoir ce genre de truc donc je ne me plains pas."
- Les versions candidates RC-3 et RC-4 ont vu l'inclusion du pilote ath9k pour les cartes wifi basées sur des puces Atheros, le support du trackpad des nouveaux portables Apple ainsi que des corrections sur les systèmes de fichiers XFS et UBIFS.
- Le 28 août c'est la version RC-5 qui a été annoncée : « Nouvelle semaine (mes semaines semblent avoir 8 jours, c'est très bizarre) et nouvelle version candidate. Cette RC-5 comporte (...) un grand nombre de petits changements qui, je l'espère, corrigent pas mal de régressions. Le plus excitant (du moins pour moi — apparemment ma vie est ennuyeuse au-delà du concevable) est que nous avons eu des débordements de la pile (stack overflow) qui ont totalement corrompu les structure de données des threads. C'est excitant parce que nous n'avions pas eu cela depuis pas mal de temps. Bien sûr ce bug aurait impacté uniquement les gens un peu trop aventureux et ayant sélectionné l'option de configuration 4096 processeurs ! ».
- Les versions candidates RC-6 et RC-7 sont apparues respectivement le 9 et le 21 septembre, avec le Kernel Summit et la Linux Plumber Conference dans l'intervalle ce qui a un peu ralenti le rythme.
- La version RC-8 a été annoncée par Linus le 29 septembre : « Celle-ci devrait être la dernière. Nous ne sommes pas à court de régressions mais, en même temps, je dois faire un choix à un certain moment et dans l'ensemble les régressions ne semblent pas _trop_ effrayantes. Et évidemment la RC-8 en corrige la plupart. ».
Il est à noter que le bug vicieux qui affectait le pilote e1000e des cartes réseau Intel n'est plus dangereux mais que Linus n'en pense pas moins : « Le _vrai_bug est dans la conception du matériel qui permet de foutre en l'air ces cartes sans même avoir un bit de sécurité. J'espère qu'Intel ne va pas traiter ça comme étant juste un bug logiciel. Certains concepteurs de matériel devraient vraiment réfléchir à propos du genre d'orifice dans lequel ils ont mis leur tête ».
- Linus a finalement décidé de sortir une version RC-9 afin de bénéficier d'une petite période de test supplémentaire : « Je sais, je sais, j'avais dit que la RC-8 serait la dernière et que le noyau serait disponible ce weekend. J'ai menti. Faites-moi un procès. J'ai inclus deux corrections pour des bugs subtils aujourd'hui et, bien qu'ils semblent parfaitement corrects et aient été testés par les gens en charge des régressions, je n'ai pas pu me décider à leur coller le label "v2.6.27" sans faire un peu plus de tests. J'ai aussi pensé que c'était une bonne idée d'avoir une version candidate contenant les patchs qui devraient corriger la corruption du pilote e1000e ».
- Le contrôle d'intégrité des périphériques en mode bloc fait son apparition dans ce noyau. Certains systèmes de fichiers possèdent des fonctions de corrections d'erreurs basées sur le calcul de sommes de contrôle (checksums) mais, bien souvent, l'alerte de ces systèmes de fichiers est trop tardive pour être vraiment utile. La corruption n'est détectée que lors de la lecture et donc le problème peut n'être signalé que des mois après la disparition des données initiales. Ce qu'il faudrait c'est que les erreurs de transmission de données soient détectées le plus tôt possible, dès que la corruption se produit. C'est pour cela que de nombreux disques durs modernes sont maintenant équipés d'une surveillance matérielle de l'intégrité des données. Bien entendu ce contrôleur exige une coopération de la part du système d'exploitation et c'est ce support qui entre dans le noyau 2.6.27 pour les disques SATA et SCSI.
Concrètement une somme de contrôle de 8 octets est calculée pour chaque bloc de 512 octets. Le résultat (les données plus les méta-données d'intégrité) est donc stocké dans des secteurs de 520 octets sur le disque et une vérification est effectuée lors de chaque passage des données dans un périphérique (Host contrôleur, contrôleur RAID matériel, contrôleur réseau, etc). De même, quand les données sont lues par la suite, il y a également une vérification à chaque étape dans l'autre sens. On voit donc qu'avec cette méthode une corruption est détectée immédiatement et qu'il devient très facile d'identifier le composant fautif. La documentation explique très clairement la motivation de cette infrastructure de contrôle d'intégrité ainsi que les détails techniques associés. Une présentation de cette nouvelle fonction s'est déroulée lors du symposium Linux d'Ottawa et un fichier PDF intitulé "Linux Data Integrity Extensions" est disponible.
- Le système de fichiers UBIFS a été ajouté au noyau 2.6.27.
Conçu spécialement pour fonctionner avec les périphériques flash de type MTD ce système de fichiers abandonne tous les présupposés des systèmes dédiés aux disques durs (qui eux sont basés sur des secteurs). UBIFS (UBI File System) s'appuie comme son nom l'indique sur la couche UBI (Unsorted Block Images). Il s'agit d'une couche spécifique se trouvant dans drivers/mtd/ubi et qui joue le rôle de gestionnaire de volume (volume manager) et de répartiteur des écritures (wear-leveling) par dessus la mémoire flash.
La documentation explique clairement les avantages d'UBIFS (notamment l'emploi de la technologie de write back qui met en cache les données au moment de l'écriture afin d'augmenter les performances) et souligne qu'il est éventuellement prévu de développer une couche UBI2 (API compatible pour éviter de devoir toucher à UBIFS) afin de pouvoir avoir un temps de boot qui n'augmente pas linéairement avec la taille de la mémoire flash. Il est à noter que ce nouveau système de fichiers spécialisé UBIFS ne pourra vraiment montrer son potentiel que si les fabricants de périphériques Flash acceptent la possibilité de passer outre la FTL (Flash Translation Layer). Cette couche d'émulation de disque dur ne sert plus à rien dans le cas d'UBIFS mais il y a fort à parier que certains fabricants vont traîner des pieds avant de fournir les spécifications de leurs périphériques et de permettre la désactivation de la FTL.
En définitive UBIFS est donc le premier système de fichiers de nouvelle génération pour mémoire flash à faire son entrée dans le noyau et il le doit certainement au poids de la société Nokia qui finance son développement. Le concurrent LogFS n'a pas pu pour l'instant franchir ce pallier car il n'est quasiment écrit que par une seule personne (Jörn Engel). Même si rien n'est perdu pour LogFS cette situation est symptomatique du mode de développement actuel du noyau par des équipes dédiées et payées par les grandes entreprises.
- L'infrastructure ftrace (function tracer) permettant de suivre les appels système d'une commande donnée en paramètre est entrée dans le noyau 2.6.27. C'est un outil puissant d'analyse du comportement de Linux qui est ainsi mis à la disposition des programmeurs qui veulent comprendre les moindres détails du fonctionnement de leur code.
L'infrastructure ftrace utilise les marqueurs statiques présents dans le noyau par l'intermédiaire de fichiers virtuels se trouvant dans le répertoire /debugfs/tracing et produit ainsi le résultat de chaque fonction appelée dans le noyau. On peut également visualiser les temps de latences (avec le tracer wakeup), les interruptions (avec le tracer irqsoff), les préemptions (avec le tracer preemptoff), les changements de contexte (avec le tracer sched_switch), etc. Une documentation très détaillée est disponible et permet de se lancer dans le tracing de son noyau.
Aux cotés de ftrace on peut également noter l'inclusion du patch tracehook qui permet de gérer de façon unifiée le tracing dans le noyau. Le patch est apparu tardivement (sans passer par l'étape linux-next) mais les développeurs ont jugé que l'impact sur le code existant était minimal et que l'entrée dans le noyau 2.6.27 était possible. Avec tracehook, Roland McGrath a retravaillé l'appel système ptrace() afin de simplifier l'infrastructure future utrace. Une fois que utrace sera au point les développeurs pourront importer les patchs du projet SystemTap afin de parachever le travail.
Alors que, depuis des mois, certains s'inquiétaient du retard pris par rapport à l'outil de Sun,Dtrace, l'intégration de ftrace et tracehook est donc une indéniable avancée de Linux dans un domaine difficile. le noyau 2.6.27 démontre ainsi que les développeurs sont au travail (cet article du site LWN fait le point sur tous les projets de tracing) et que le retard sur Dtrace est peut-être sur le point d'être rattrapé.
- Une implémentation libre du système de fichiers OMFS a été accepté dans le noyau 2.6.27 en dépit d'une controverse ayant eu lieu sur la LKML. Le système OMFS (Optimized MPEG Filesystem) est un système de fichiers propriétaire ayant été utilisé sur des périphériques de type Rio Karma ou ReplayTV. Le développeur Bob Copeland a écrit une version libre d'OMFS en faisant de l'ingéniérie inverse et il a proposé l'inclusion d'OMFS dans la branche principale du noyau. La revue de code ayant été positive, tout semblait se dérouler sans accrocs quand Andrew Morton a soulevé la question du nombre d'utilisateurs d'OMFS. Comme ce système de fichiers n'a été utilisé que sur des périphériques qui ne sont plus en vente et comme les utilisateurs des patchs externes OMFS de Bob Copeland n'a jamais dépassé le nombre de 20, était-il raisonnable d'inclure ce système qui allait nécessiter une certaine maintenance au fil du temps ? La controverse est restée fort courtoise et les arguments ont été examinés les uns après les autres. Finalement, comme il semblait peu efficace de pousser OMFS en espace utilisateur et passant par FUSE et comme le code était simple et bien écrit, il a été décidé d'inclure OMFS dans la branche principale du noyau. Cet exemple est vraiment symptomatique du mode de développement de Linux qui privilégie les arguments techniques pour faire des choix en ayant toujours le service des utilisateurs comme but ultime.
- La technologie de cache de page sans verrou fait son apparition dans le nouveau noyau et permet d'augmenter significativement les performances et la montée en charge. Le cache de page est conçu pour garder dans la mémoire vive de la machine (RAM) des copies de fichiers présents sur le disque dur afin de permettre des accès rapides sans avoir à passer par le goulet d'étranglement des entrées/sorties d'un périphérique lent comme le disque dur.
Chacune de ces pages en cache possède son propre verrou d'accès pour permettre un fonctionnement efficace dans un environnement multiprocesseurs. Cela permet aux différents cœurs de traitement d'accéder aux différentes pages sans bloquer la machine, mais il restait un cas difficile à traiter. Imaginons que les différents processeurs tentent d'accéder à un même fichier, par exemple le cas très courant d'une bibliothèque partagée. Le premier processeur va donc poser son verrou et les autres vont devoir attendre que la ressource se libère. Nick Piggin, qui travaille chez Novell, a donc décidé d'utiliser la technologie de RCU (Read-Copy-Update) pour permettre aux différents processeurs d'accéder à la page de cache simultanément sans avoir à poser le moindre verrou. Le travail a été particulièrement long car c'est une partie sensible du noyau et parce que l'écriture de code sans utiliser de verrou est une tâche complexe. Le résultat est pourtant à la hauteur des espérances puisque dans son mail d'annonce du patch Nick a mesuré un gain très significatif lors de l'utilisation de la fonction find_get_page() qui permet de chercher si une page est dans le cache et si oui de l'utiliser. Avec le patch de cache de page sans verrou on ne dépense que 61 cycles de processeurs alors qu'il en fallait 143 auparavant (avec une architecture Core2).
Nick Piggin a également écrit la nouvelle fonction get_user_pages_fast() qui joue le même rôle que get_user_pages() mais sans verrou (plus besoin d'utiliser le sémaphore mmap_sem). Le gain est ici surtout visible pour les grosses machines très chargées et il a été évalué à environ 10% de performances en plus pour un octo-coeurs faisant tourner une grosse base DB2.
- En parlant de verrou le travail d'éradication du verrou global (BKL) qui avait été évoqué dans une précédente dépêche commence à porter ses fruits dans le noyau. La fonction open() des périphériques en mode caractères fonctionne désormais sans poser le moindre verrou sur le noyau. Ce travail en grande partie effectué par l'éditeur du site Linux Weekly News, Jonathan Corbet, continue dans la branche spécialisée bk-removal. C'est une tâche de longue haleine mais le nombre impressionnant de patchs ayant été incorporé dans ce noyau 2.6.27 incite à l'optimisme pour le moyen terme. Après avoir rendu de fiers services durant des années le verrou global du noyau Linux est devenu un frein à l'évolution et il vit sans doute ses derniers mois.
- Une toute nouvelle infrastructure de gestion de la mise en veille/hibernation est présente dans le noyau 2.6.27. L'infrastructure précédente était considéré comme n'étant pas suffisamment flexible et posant de nombreux problèmes dans le cas de pilotes déficients. Il n'était pas rare de constater des échecs lors du réveil de la machine du fait du manque d'informations en provenance des périphériques. Rafael J. Wysocki a donc proposé une nouvelle approche qui, après la revue critique des autres développeurs sur la liste de diffusion, est maintenant présente dans la branche principale du noyau.
Une nouvelle structure (pm_ops) fait son apparition et contient un ensemble de fonctions de rappel (callback) pour chacun des bus, des types de périphériques, des classes de périphériques et finalement pour les périphériques eux-mêmes. Les cas de la mise en veille (suspend to RAM) et de la mise en hibernation (suspend to disk) sont également séparés afin d'éviter les interférences entre ces deux opérations (ce qui avait été demandé par Linus depuis des mois à grand renforts de mails à base de « f*cking »). Le code se trouvant dans drivers/base/power/main.c a été adapté et les pilotes l'utilisant peuvent maintenant tirer profit de la nouvelle infrastructure de mise en veille/hibernation. Pour l'instant l'ancien code est toujours présent afin de permettre une compatibilité mais cela ne va pas durer puisque la conversion des pilotes présents dans le noyau est un des grands avantages permis par le modèle du logiciel libre. Il est à noter que le "coût" de cette toute nouvelle infrastructure est matérialisé par l'introduction d'un grand nombre de ces fonctions de rappel (callbacks) dans le noyau mais qu'il a été jugé que le jeu en valait la chandelle afin d'obtenir une mise en veille/hibernation plus fiable et de meilleure qualité. Une présentation technique détaillée des problèmes de l'ancienne infrastructure et des solutions adoptées par la nouvelle a été effectué lors du dernier symposium Linux. L'article au format pdf de Rafael J. Wysocki et Leonard Brown est disponible ici.
- Toujours dans le domaine de la mise en veille/hibernation le patch basé sur Kexec a été inclus dans le noyau 2.6.27 à titre de solution alternative. Le développeur Ying Huang a suivi une stratégie complètement différente pour implémenter la mise en hibernation (suspend-to-disk) puisqu'il a utilisé la fonction Kdump/Kexec en la détournant de son rôle habituel. En temps normal cette fonction est utilisée pour sauver l'état du noyau lors d'un crash du système. Un noyau sain (nommé "noyau de capture") est gardé en mémoire dans une zone spéciale séparée et, lors du crash, un appel à la fonction kexec() est effectué. Cet appel permet au noyau sain de prendre la main afin de sauvegarder sur le disque toutes les informations sur le noyau fautif (dump). Cette sauvegarde facilite grandement le débogage ultérieur qui sera effectué par les développeurs. Toute cette procédure, détaillée dans ce fichier pdf, ressemble fortement à une mise en hibernation (suspend-to-disk) puisqu'on a un système qui enregistre l'état exact de la machine à un moment donné et qui écrit sur le disque pour sauvegarder cet état précis. Ying Huang a donc décidé de modifier Kdump/Kexec afin de permettre au "noyau de capture" de rendre la main au noyau originel après avoir lu le dump sauvé sur le disque. On a ainsi une fonction complète d'hibernation et - avantage de cette solution élégante -, on unifie et on simplifie le code (plus besoin de mettre les processus au "freezer" comme avec l'hibernation actuelle).
Deux choses sont toutefois à noter: L'hibernation basée sur Kexec est actuellement envisagée comme alternative au code existant et il ne le remplace pas, même si cela pourrait arriver dans les futurs noyaux. Enfin cette solution alternative est seulement disponible pour les architectures x86 à l'heure actuelle.
- La pile réseau a été profondément modifiée pour permettre le support des queues multiples. Jusqu'à présent les paquets d'un périphérique réseau parcouraient la pile du noyau à la queue leu leu dans une sorte de "tuyau" unique mais il vite devenu évident que ce mode de fonctionnement devient de plus en plus limitant avec les besoins modernes. De nombreux périphériques réseau implémentent des classes de transfert différentes selon les besoins, par exemple une classe à haute priorité qui peut être utilisé pour transmettre de la vidéo ou de la voix et une classe à basse priorité pour les transferts pair-à-pair en arrière-plan. C'est ce qu'on nomme la gestion de la QoS (Quality of Service). Le fait de devoir entasser tous les paquets réseau d'un même périphérique dans une seule queue d'attente alors que les classes de ces paquets sont différentes est inefficace. La priorité des paquets est donc actuellement gérée dans le noyau de façon suboptimale et David Miller a décidé de réorganiser ce point particulier de la pile réseau en proposant un patch sur la liste de distribution. Le noyau 2.6.27 propose ainsi une implémentation des queues multiples qui sont ordonnancées de façon concurrente en fonction de la priorité des classes. Pour les périphériques qui gèrent ces queues multiples cela signifie une meilleure gestion de la QoS et pour les périphériques plus simples, qui ne gèrent pas les queues multiples, rien ne change et leur code n'a pas a être modifié. De nombreuses cartes wifi vont progressivement profiter de cette implémentation des queues multiples au fur et à mesure que leur code sera adapté. Il est à noter que cette implémentation du mécanisme des queues multiples, si elle est utile pour les réseaux sans fil, est également appréciable pour les réseaux à haut débit. Pour utiliser une ligne à 10 gigabits à son plein potentiel il est parfois utile d'avoir plus d'une queue d'attente afin de réduire les problèmes d'attente de libération des verrous (locking contention).
Pour aller plus loin dans la compréhension de ce mécanisme vous pouvez consulter la présentation pdf de David Miller ou bien aller sur son blog (souvent très technique).
- Du côté du système de fichiers Ext4 le travail continue et le remplacement officiel d'Ext3 dans nos machines se rapproche. Le leader du projet, Ted Ts'o, a posté sur son blog le résultat d'une vérification (check) du système de fichiers et il obtient des résultats plus qu'encourageants. Selon son test, une passe de vérification (fsck) sur un volume de 128 Go, Ext4 est près de sept fois plus rapide que Ext3 lors du check ! Quand on passe de 424 secondes à seulement 63 lors d'une vérification du système de fichiers on peut dire que le travail sur Ext4 a vraiment porté ses fruits.
Le dernier gros morceau technologique faisant partie de la todo list est également entré dans Ext4 sous la forme du patch implémentant l'allocation retardée (delayed allocation). Déjà utilisée par des systèmes de fichiers comme btrfs ou ZFS, cette technique consiste à ne pas allouer tout de suite les blocs sur le disque lors d'une opération d'écriture. On décrémente juste le compteur d'espace libre mais on ne réserve aucun bloc sur le disque et on marque le tampon mémoire comme étant alloué avec retard (BH_DELAY). Quand finalement le tampon est vidé (flushé) pour écrire sur le disque, le noyau va prendre toutes les pages marquées BH_DELAY et va allouer les blocs sur le disque de façon bien plus efficace puisqu'il aura une vision plus complète des écritures à effectuer. Avec cette technique on augmente les performances, on diminue encore plus la fragmentation puisque l'allocation est optimisée et on économise des cycles processeurs en ne faisant qu'une passe d'allocation au lieu de plusieurs.
Encore une fois un fichier pdf issu du symposium Linux d'Ottawa est disponible pour ceux qui voudront vraiment comprendre en profondeur le mécanisme d'allocation retardée utilisé par Ext4.
- L'ajout du pilote GSPCA qui regroupe le support d'une multitude de webcams fait son entrée dans le noyau. Après l'entrée du pilote UVC dans la version précédente de Linux voici maintenant l'arrivée de GSPCA (Generic Software Package for Camera Adapters) qui permet la gestion d'une longue liste de webcams. Maintenu par le français Michel Xhaard, ce projet GSPCA existe depuis de nombreuses années mais il n'avait jamais trouvé son chemin jusqu'au noyau officiel. Bien entendu l'acceptation dans la branche principale du noyau a nécessité un peu de travail de nettoyage. Il a en effet été nécessaire d'enlever les parties s'occupant du décodage des formats vidéos "exotiques" des constructeurs de webcams, un tel décodage n'ayant absolument rien à faire dans le noyau. Une bibliothèque de conversion en espace utilisateur, libv4l, a été écrite par Hans de Goede afin de s'occuper de ces taches de décodage vidéo.
Ces deux pilotes, UVC et GSPCA, permettent maintenant au noyau Linux de gérer l'immense majorité des webcams qui existent sur le marché.
- De nombreux pilotes présents dans le noyau 2.6.27 ont été modifiés afin d'utiliser le chargeur de micrologiciel (firmware). Le travail de David Woodhouse a consisté a généraliser l'utilisation de la fonction request_firmware() qui permet aux pilotes d'aller chercher leur micrologiciel dans le répertoire /firmware. À terme cela signifie la fin des nombreux pilotes qui implémentaient leur propre solution avec un firmware « en dur » dans le code du noyau puisque tous les micro-logiciels ont vocation à rejoindre ce répertoire /firmware. Pour les pilotes qui ont été modifiés la séparation est maintenant stricte entre leur code à proprement parler et le micro-logiciel (toutefois il reste encore les pilotes de drivers/net et drivers/scsi à convertir). Le résultat net c'est que le code noyau du noyau Linux est bien plus propre.
Cette solution permet également de faciliter le travail des distributions les plus puristes qui ne veulent pas distribuer avec le noyau des firmwares non-libres. Ici règne une incertitude juridique puisque personne ne sait vraiment si les firmwares peuvent être distribués avec un noyau sous licence GPL (sans parler des constructeurs qui ne veulent pas que leur micro-logiciel fassent partie d'un noyau GPL). Ces incertitudes lancinantes ne disparaissent pas magiquement avec la solution de David Woodhouse mais il est maintenant trivial pour les distributions de distribuer ou pas les firmwares avec le noyau. Il sera possible de distribuer un tarball séparé pour les micro-logiciels et chaque distribution fera son choix entre les deux solutions.
En bref....
- La fonction de hachage du consortium européen RIPE fait son entrée dans le code cryptographique du noyau. Les algorithmes RIPEMD-128, RIPEMD-160, RIPEMD-256, et RIPEMD-320 sont maintenant disponibles.
- Alors que le noyau précédent avait vu le retrait de la possibilité d'exécuter des binaires Solaris c'est maintenant la couche de compatibilité avec le système SGI IRIX qui a été enlevée (avec un patch intitulé "IRIX: Goodbye and thanks for all the fish"). Ce code, mal maintenu et non utilisé, a été supprimé au bénéfice de la simplification du noyau.
- Les processeurs de type x86-64 peuvent maintenant utiliser une taille de page de 1Go (en plus des tailles habituelles de 4Ko et 2Mo). Cette gestion des hugepages permet de moins solliciter le TLB (Translation lookaside buffer) puisque le cache du TLB peut gérer une plus grande quantité de mémoire. Les applications de bases de données devraient en tirer un bénéfice important.
- L'outil LatencyTOP (évoqué dans ce journal) peut désormais fonctionner sur les processeurs de type ARM. Un autre patch ajoute également le support des PowerPC.
- Dans la même veine le débogueur intégré dans le noyau 2.6.26 (et qui n'était compatible qu'avec les architectures x86 et SPARC) peut maintenant fonctionner avec les architectures ARM et PowerPC.
- Comme indiqué par Linus dans ses mails d'annonce des versions candidates il est désormais possible d'installer le noyau mainline sur des machines à 4096 processeurs
- L'infrastructure de test du mécanisme RCU (Read-Copy-Update), qui peut être activée par l'option CONFIG_RCU_TORTURE_TEST, a été améliorée. Paul E. McKenney, qui est l'auteur de rcutorture, a investi beaucoup de temps dans les divers patchs afin de rendre son outil plus agressif et plus complet dans ses tests. L'intitulé du patch est d'ailleurs parlant puisqu'il s'intitule "RCU : Make rcutorture more vicious".
- Après un travail de longue haleine les processeurs de type IA64 (Itanium) sont maintenant compatibles avec l'interface unifiée de virtualisation paravirt_ops.
- L'arrivée dans le noyau des premiers patchs permettant le support des futurs processeurs Power7 a provoqué pas mal de spéculations. Que ce soit le travail du noyau ou celui effectué dans binutils, la simple lecture du code soumis permet d'en savoir un peu plus sur la future bête de course d'IBM et sur son unité vectorielle VSX.
- Enfin vous serez sûrement contents d'apprendre que le noyau 2.6.27 vous permet maintenant d'ajouter et d'enlever à chaud des barrettes de mémoire vive sur votre petit mainframe S390 personnel (prix d'entrée de gamme aux alentours de 100.000 $).
Pour un bilan en chiffres (analyse statistique issue de cet article du site LWN) le noyau 2.6.27 aura incorporé plus de 10604 patchs (10100 pour les noyau 2.6.26). Cela représente un gain net de 218000 lignes (+826000 et -608000).
On peut noter que le français Jean-François Moine est le troisième contributeur en terme de lignes de code du fait de son important travail sur l'intégration et le nettoyage du pilote de webcam GSPCA.
Ces plus de dix mille patchs viennent de 1109 développeurs différents (1065 pour le noyau 2.6.26) travaillant pour plus de 150 entreprises.
Pour le futur...
- Dans le domaine des gestionnaire de mémoire pour les cartes graphiques il est probable que GEM va faire son entrée (dès la version 2.6.28 ou la suivante) et que TTM a perdu la bataille de l'intégration dans la branche principale. La comparaison entre les deux solutions qui a été effectuée par les développeurs Linux fait apparaître que TTM est une solution plus complexe, difficile à utiliser et ayant une API en partie conçue pour satisfaire les besoins spécifiques des pilotes propriétaires (ce qui évidemment ne plait à personne). C'est donc GEM qui a la faveur des développeurs (Jesse Bernes a annoncé qu'il allait proposer l'inclusion de GEM dans la branche Linux-next) et cela a provoqué l'émoi de ceux qui voient cette solution comme étant trop liée à Intel. Le futur est donc, provisoirement, encore ouvert mais les opposants à GEM ont intérêt, s'il n'est pas déjà trop tard, à proposer très rapidement une alternative crédible.
- le travail continue sur le système de fichiers btrfs et la version 0.16 a été annoncée par Chris Mason le 5 août dernier. Btrfs (prononcer butter fs) a l'ambition de devenir le système de fichiers de nouvelle génération des systèmes GNU/Linux et introduit beaucoup de nouveautés déjà décrites dans une dépêche précédente. Cette nouvelle version 0.16 fait disparaître le verrou global de btrfs au profit de nombreux petits verrous locaux afin de tirer parti des machines multiprocesseurs. Dans la même veine les tâches d'arrière plan diverses (comme le calcul des sommes de contrôle) sont maintenant exécutées par des threads séparés. La version 0.16 apporte également le support des attributs étendus (ACL) et un nouveau système de cache pour la gestion des snapshots. Le dépôt du code source est passé à Git afin de faciliter la future intégration dans la branche principale et continuer le développement directement en mainline. Andrew Morton a proposé une intégration rapide dans la branche linux-next en vue d'une entrée dès le noyau 2.6.29. Btrfs se positionne de plus en plus comme LA solution Linux pour avoir un système de fichiers de nouvelle génération.
- Néanmoins tout le monde n'est pas de cet avis et Daniel Phillips a posté le 3 juillet un long mail sur la mailing list du noyau afin d'expliquer les grandes lignes du design d'un système de fichiers alternatif nommé Tux3 ("Comme tout le monde semble bien s'amuser a développer des nouveaux systèmes de fichiers en ce moment j'ai pensé que je pourrai me joindre à la fête").
Le but de Tux3 est d'implémenter les idées originales de Daniel Phillips sur le versionning, on trouve par exemple les informations sur les versions dans le feuilles des arbres B alors que btrfs et ZFS choisissent de créer un arbre par version. Cela permettrait à Tux3 de faire une économie de place lors du stockage des méta-données par rapport à ses deux concurrents. Il est à noter que Matt Dillon, qui dirige le développement de DragonFlyBSD, a échangé plusieurs mails avec Daniel Phillips afin de comparer son système de fichiers HAMMER et Tux3.
Les deux systèmes partagent de nombreuses idées et la conversation, bien que très technique, a sans aucun doute été mutuellement enrichissante. Matt a toutefois gentiment prévenu Daniel qu'il s'embarquait peut-être dans un projet plus complexe que ce qu'il pensait : "Il semble que Tux3 utilise pas mal d'idées similaires à ce que je fais dans HAMMER. Je pense que tu est sur la bonne voie. J'ajouterai quand même un mot d'avertissement, venant de mon expérience lors de l'implémentation de HAMMER, parce que je pense que tu va être confronté aux mêmes problèmes. J'ai passé 9 mois sur le design d'HAMMER et 9 mois pour l'écrire. Durant l'implémentation j'ai fini par jeter l'équivalent de 80% de ce qui était dans le design original. Une bonne part de ce que j'ai du abandonner lors du passage du projet à la réalité était dans le but de diminuer la complexité. (..) Si j'ai une inquiétude à propos de ton implémentation cela serait dans le secteur de la complexité algorithmique."
Si les idées de Tux3 sont innovantes il n'en est toutefois absolument pas au même stade de développement que btrfs. Daniel Philips l'a exprimé avec humour dans un mail daté du premier septembre : "Les derniers patchs ont permis d'amener Tux3 jusqu'au point ou il commence indéniablement à se comporter comme un système de fichiers: On peut écrire des fichiers, partir un moment et, quand on revient, ces fichiers sont toujours là et on peut les relire." Le chemin est donc encore long avant de pouvoir envisager l'inclusion dans la branche principale du noyau.
- Enfin, preuve du bouillonnement actuel dans le domaine des systèmes de fichiers, un concurrent de plus vient d'apparaître. Répondant au doux nom de NILFS (New Implementation of a Log-structured File System) ce système se propose d'enterrer tous les autres systèmes en se basant sur la technique d'écriture des données « en flux » (sous forme de log) sans avoir à se préoccuper d'optimiser l'écrire les données les unes à coté des autres (ce qui prend beaucoup de temps). L'idée est que les lectures de données se font très souvent à partir de la RAM et qu'il est donc plus rationnel d'optimiser l'écriture plutôt que la lecture. Le code a été soumis sur la liste de diffusion et un fichier pdf comparant NILFS avec d'autres systèmes de fichiers est disponible.
NILFS semble particulièrement adapté aux nouveaux disques SSD et il constitue donc, aux cotés de LogFS, une alternative possible au tout nouveau UBIFS (quand l'accès direct à la mémoire flash sous-jacente sera possible).
L'inquiétude d'Andrew Morton sur le manque de travail des développeurs face à la vague future des disques SSD semble donc étonnante : "Il me semble entendre un silence assourdissant au sujet du support de ces périphériques SSD. J'ai la vague inquiétude que nous allons assister à une diffusion massive de ces SSD et que Linux y fera face avec le pantalon sur les chevilles."
Andrew Wilcox a été prompt a lui rétorquer qu'au contraire la situation était plutôt bonne et qu'il n'y avait pas de souci à se faire : "Je travaille (et je poste des patchs) sur le support des SSD Intel. Honnêtement nos pantalons évoluent actuellement dans la zone de l'aine."
Aller plus loin
- Les nouveautés du noyau 2.6.27 (23 clics)
- Le bilan des ajouts partie 1 (8 clics)
- Le bilan des ajouts partie 2 (3 clics)
- Le bilan des ajouts partie 3 (3 clics)
- Les prévisions pour l'avenir de Linux (1 clic)
# Impressionant
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 10.
1° Le kernel : ça m'a toujours épaté de voire la quantité d'ajouts fait à chaque release. C'est à se demander si il n'y avait rien du tout dans la version précédente. Et comme tout le monde sait que ce n'est pas le cas, ça doit vraiment devenir énorme et le boulot que Linus fait doit être assez impressionant (avoir une vue d'ensemble sur un monstre [en taille] pareil, vous imaginez ça vous ?).
2° patrick_g : Des dépèches de plus en plus longues et toujours aussi agréable à lire. Y doit y avoir une recette magique c'est pas possible autrement. En tout cas ça mérite une médaille et beaucoup de merci parce-que c'est pas mal de boulot tout ça.
[^] # Re: Impressionant
Posté par Skunnyk (site web personnel) . Évalué à 3.
Une chose intéressante (en tout cas pour moi) dans l'évolution de iwlwifi : le support du mode monitor pour les cartes intel 3945 !
C'était un manque par rapport au driver ipw3945 :-)
( voir http://kernelnewbies.org/Linux_2_6_27#head-92eedfd5b93a0926a(...) )
Et merci pour la news, claire, efficace, rapide !
[^] # Re: Impressionant
Posté par seginus . Évalué à 10.
Alors voilà Patrick, tu es une nano-merde indigne de souiller linuxfr avec ma misérable présence.
PS : et sinon, l'entretien s'est bien passé ?
[^] # Re: Impressionant
Posté par patrick_g (site web personnel) . Évalué à 10.
(pour ceux qui n'ont pas suivi : https://linuxfr.org/comments/971195.html#971195 )
PS : L'entretien s'est pas mal passé. Faudra voir lors de la restitution dans 3 mois pour voir si y'a un effet sur la fiche de paie.
[^] # Re: Impressionant
Posté par wr35nn89 . Évalué à 5.
Je pense qu'une version française de kernelnewbies ferait des heureux.....
et vivement le kernel mode setting (bientôt peut-être ?)......
[^] # Re: Impressionant
Posté par ß ß . Évalué à 3.
PS : et sinon, l'entretien s'est bien passé ?Je me demandais également comment il pouvait passer autant de temps à rédiger une telle dépêche sachant qu'il avait son entretien dans la même période. Surtout si rapidement (moins de 24 heures après l'annonce, temps de modération de la dépêche comprise !).Moi ça me prends déjà beaucoup de temps rien que pour lire la dépêche... (Bon ok j'ai besoin de relire plein de fois par ce que je suxe en kernel :)
Bon sinon ça fait plaisir toutes ces modifications. C'est impressionnant autant de changement d'un coup. Et je ne sais pas si c'est moi, mais j'ai l'impression que le développement du kernel ne cesse de s'accélérer. Est ce que ça va s'arrêter un jour ? Comment Linus peut trouver le temps de regarder tous ces patchs avant de les accepter ou les rejeter ?
git a beau être un excellent outil qui facilite grandement le développement, je trouve ce travail formidable.
Pour revenir sur l'article,
UBIFS ne pourra vraiment montrer son potentiel que si les fabricants de périphériques Flash acceptent la possibilité de passer outre la FTL (Flash Translation Layer)Justement je me posais la question. Si les fs implémentent du wear leveling et si c'est déjà fait au niveau hardware, ça risque de faire doublon et ça ajoute de la complexité et également du prix au matériel. Mais j'imagine que ça va être dur d'en trouver sans, car il y aura forcément des OS (suivez mon regard...) qui n'implémenterons pas de fs performants pour ça. Du coup proposer des cartes avec et sans ça induirait une complication pour le consommateur. La seule solution étant de se contenter d'un système désactivable... au moins pendant un temps de transition, le temps qu'il soit possible d'avoir les bon fs sur tous les OS.Que se passe-t-il d'ailleurs si jamais on utilise un tel fs sur une carte implémentant ce genre de choses ? Et ce qu'il y a un risque de perte de performances ou une perte quelconque ? Est ce que ça ne changera rien ? Est ce que ces fs sont utilisables sur des disques dur normaux ? Et si c'est le cas, est ce que c'est une mauvaise idée de le faire ?
L'outil LatencyTOP (évoqué dans ce journal)On peut également aller lire l'inteview[1] d'Arjan van de Ven par O'reillyEt enfin pour finir, une petite correction :
- avantage de cette solution élégant -[1] http://broadcast.oreilly.com/2008/09/how-powertop-latencytop(...)
[^] # Re: Impressionant
Posté par patrick_g (site web personnel) . Évalué à 10.
Heu...en fait je prépare les news noyau sur environ deux mois et je soumets la news sur le site environ une semaine ou deux avant la sortie pour bénéficier des corrections et améliorations de mes petits camarades (merci à baud123, Floxy, jerome_misc, pterjan et plic).
Donc la préparation de la dépêche (deux mois) n'interfère pas du tout avec la préparation de l'entretien (deux heures méthode la RACHE ;-)
[^] # Re: Impressionant
Posté par herodiade . Évalué à 10.
Tout à fait d'accord.
Mais, si je peux me permettre, et pour tenter de faire avancer le schmilblick, pourrai-t-on envisager d'appliquer, les prochaines fois, cette suggestion de Wikipédia concernant la qualité du style (WP:STYLE) :
« Évitez également les formulations du type "il est à noter que", elles alourdissent inutilement la phrase et relèvent du commentaire personnel. ».
Vérifiez l'astuce avec le texte de la dépêche : on peux enlever chacun des cinq « il est à noter que » sans dévoyer le sens mais en gagnant en légèreté. Sans quoi tout les linuxfriens ne tarderont pas à adopter ce tic de langage plus geek que littéraire ;).
Pour le reste évidement, la dépêche est superbe.
Une question maintenant. Le pilote out-of-tree GSPCA était maintenu par Michel Xhaard depuis des années, comme l'indique la dépêche. Pourtant Xhaard n'a participé à aucun des commits dans le récent répertoire drivers/media/video/gspca/ du noyau standard. La plupart des commits sont « Signed-off-by » Jean-Francois Moine et Mauro Carvalho Chehab. D'autre part le ChangeLog concernant GSPCA sur le site de Xhaard ([http://mxhaard.free.fr/news.html]) s'arrête abruptement au 24 december 2007. Est-ce que Michel Xhaard a abandonné le développement ? est-il contrarié par les modifications de son travail qu'implique l'intégration dans le noyau standard, ou la collaboration avec d'autres développeurs ?
[^] # Re: Impressionant
Posté par liberforce (site web personnel) . Évalué à 6.
Ça pourrait faire l'affaire d'un entretien LinuxFr...
http://linuxfr.org/interviews/
[^] # Re: Impressionant
Posté par ʭ ☯ . Évalué à 3.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Impressionant
Posté par lafeuil . Évalué à 2. Dernière modification le 24 août 2019 à 13:56.
C'est une question que je me suis posé aussi quand j'ai vu que le pilote GSPCA avait fait son entrée dans le kernel.
En googlant un peu, je me suis retrouvé sur la page d'un des mainteneurs : Jean François Moine. On se rend compte que sur son site (http://moinejf.free.fr/ ) , il parle du pilote GSPCA. On y apprend que le driver est passé en version 2 après son introduction dans la version main de linux. D'après le changelog, il semblerait que ce soit lui qui maintienne le code.
[^] # Re: Impressionant
Posté par ondex2 . Évalué à 5.
Les versions candidates RC-3 et RC-4 ont vu l'inclusion du pilote ath9k pour les cartes wifi basées sur des puces Atheros, le support du trackpad des nouveaux portables Apple
[^] # Re: Impressionant
Posté par Mildred (site web personnel) . Évalué à 0.
Ath9k, concrètement, ça veut dire que j'abandonne madwifi (qui ne se réveille pas bien au suspend) ou ndiswrapper (qui consomme beaucoup d'énergie). Donc j'attend avec impatience que la nouvelle version du kernel apparaisse dans ArchLinux (enfin, je n'attendrais peut être pas)
[^] # Re: Impressionant
Posté par patrick_g (site web personnel) . Évalué à 6.
C'est surtout que l'intégration de nouveaux pilotes ce n'est pas un changement très risqué puisque, par définition, ils n'étaient pas dans le noyau avant et qu'il n'y a donc pas risque de régressions.
Que ce soit pour le pilotes ou pour les systèmes de fichiers ce sont des pièces assez isolées qui peuvent entrer dans le noyau facilement (même lors d'une RC).
[^] # Re: Impressionant
Posté par Aefron . Évalué à 2.
... mais justement, si ath5k commence à vraiment être utilisable, il est encore loin d'être parfait (cf le journal que j'avais fait dessus [1]).
Il faut bidouiller pour le fixer à un taux de transfert fixe, car l'auto-négociation le fait jouer à la toupie... cela dit, avec ça, je le trouve bien moins sensible au bruit que madwifi, et ça me fait un truc à recompiler en moins aux mises à jour du noyal (Debian inside).
Mais comme ça fait depuis quelques versions qu'il est en mainstream, j'imagine qu'il risque d'en être de même avec ath9k...
Enfin, quoi qu'il en soit, l'amélioration du support libre est toujours une bonne nouvelle (là, maintenant, j'attends que le driver libre pour le wifi broadcom s'améliore, sur MIPS, où il a tendance à segfaulter, pour repasser à OpenWRT, plutôt que Tomato).
[1] http://linuxfr.org/~Aefron/27191.html
[^] # Re: Impressionant
Posté par paipai62 . Évalué à 0.
Pour le plaisir de le dire et de lire.
MERCI PATRICK_G
[^] # Re: Impressionant
Posté par brunus (site web personnel) . Évalué à 4.
Il est tombé dedans étant petit, maintenant on fait gaffe à ce qu'il en boive plus, on a peur que les dépêches deviennent des thèses complètes !
Enfin par contre si un jour il semble nécessaire d'écrire une dépêche sur Hurd, on lui en donnera un peu quand même...
# linux 3.0 ?
Posté par jardiland . Évalué à 8.
Lors de la sortie du précédent noyau, j'avais appris l'existence d'un débat pour un changement de numérotation du noyau pour être plus cohérent avec leur mode de développement rapide et incrémental. (Il n'y a en effet plus aucune raison de garder les numéros pairs = stable, impair = instable).
Quelqu'un aurait il suivit ce débat et pourrait me dire s'ils sont arrivés à un accord ?
Et puisqu'on est vendredi : quels serrait selon vous le système de numérotation le plus adapté au noyau ?
Moi je verrait bien un système basé sur la date de parution, par exemple, le premier numéro pourrait correspondre à l'année de parution et le second numéro au mois de parution. Du coup cette version là serait la 8.10. Toute ressemblance avec une distribution appeau à trolls ne serrait que pure coïncidence.
[^] # Re: linux 3.0 ?
Posté par CrEv (site web personnel) . Évalué à 6.
Je suis contre pour une raison très simple :
- ça ne représente rien d'intéressant : entre les version 8.4 et 8.10 combien y a-t-il eu de version par exemple ? entre une 2.6.18 et 2.6.27 on peut le savoir
Mais si je ne me trompe, la numérotation a été rediscuté il n'y a pas si longtemps et les choix on été fait (entre autre avec abandon du 4° chiffre qui est destiné maintenant aux version intermédiaires - je sais plus trop comment ils appelent ça, un news est passée il y a un moment ici même)
[^] # Re: linux 3.0 ?
Posté par jardiland . Évalué à 4.
- ça ne représente rien d'intéressant : entre les version 8.4 et 8.10 combien y a-t-il eu de version par exemple ? entre une 2.6.18 et 2.6.27 on peut le savoir
Pourtant une numérotation basée sur la data a un avantage : sais tu de quand date la version 2.6.18 ? avec une telle numérotation, on se rend vite compte a quel point son noyau est vieux.
[^] # Re: linux 3.0 ?
Posté par CrEv (site web personnel) . Évalué à 4.
En fait, je trouve surtout que les numérotation basées sur la date ne sont pas intéressantes car n'apprennent quasiment rien.
2.6.27 indique entre autre la branche (2.6) qui n'existe pas dans une numérotation par date (ou alors 2.6 2008.10 mais là... beurk)
Alors oui, pour bcp de personnes savoir que c'est une branche ou une autre ça change rien, mais je dirais que pour bcp connaître la version ne sert à rien puisque les gens utilisent celles de leur distrib...
[^] # Re: linux 3.0 ?
Posté par tinodeleste . Évalué à 3.
[^] # Re: linux 3.0 ?
Posté par pasBill pasGates . Évalué à 2.
Perso je ne vois pas l'interet de savoir si il est sorti en aout ou en novembre, j'aimerais savoir si c'est la derniere version, mais je me fiches de savoir quand il est sorti.
[^] # Re: linux 3.0 ?
Posté par Anthony Jaguenaud . Évalué à 3.
Ce que j'ai lu sur le kexec tendrai à prouver, qu'un effort minimal le permettrai.
Quand à une numérotation, je pense également que ce serai une erreur, car il faut faire le distinguo entre la 2.4 et la 2.6 par ex.
[^] # Re: linux 3.0 ?
Posté par foulmetal canette (site web personnel) . Évalué à -1.
Passage du code en langage de plus haut niveau : tout en C++, en python voire en Mono ?
Ou l’inverse tout en assembleur \o/
Le troll du dredi s’est éveillé en moi, désolé…
[^] # Re: linux 3.0 ?
Posté par Mildred (site web personnel) . Évalué à 1.
Bon, par contre il y a encore des petites choses à améliorer. Mais on y travaille :)
[^] # Re: linux 3.0 ?
Posté par windu.2b . Évalué à 1.
Je suis une grosse grosse bille en noyal, mais dans mon esprit cela ne devrait pas être si difficile que ça...
En gros, on aurait une fonction :
replace( oldDriver, newDriver );
cette fonction chargerait d'abord le nouveau driver en mémoire, déchargerait l'ancien, chargerait le nouveau, testerait que tout est ok, et sinon remet l'ancien à la place du nouveau (par un déchargement/rechargement là encore).
J'ai dit une connerie ? Ça vous semble impossible ?
[^] # Re: linux 3.0 ?
Posté par flagos . Évalué à 1.
[^] # Re: linux 3.0 ?
Posté par sanao . Évalué à 2.
Que faire si le périphérique est utilisé? Doit-on attendre? Si oui combien de temps?
Doit-on prévoir la possibilité de sauver l'état de tous les processus qui l'utilisent? Et si c'est le noyau on fait quoi?
Sinon est-ce qu'il existe des OS qui supportent cette fonctionnalité?
Il me semble même avoir lu qu'il existe des OS qui permette de mettre à jour le noyau sans redémarrer la machine. Si quelqu'un sait comment il font, je serais curieux de la savoir.
[^] # Re: linux 3.0 ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: linux 3.0 ?
Posté par YLD . Évalué à 2.
Un certain Linux le permet avec Ksplice: http://www.ksplice.com/ (pas encore testé).
[^] # Re: linux 3.0 ?
Posté par pasBill pasGates . Évalué à 2.
# Petite question: noyau monolithique?
Posté par Marc Dauwn . Évalué à 9.
Mes (faibles) connaissances en système m'amène à me poser une question:
Premièrement, mes hypothèses:
1- Les noyaux "monolithiques" (bien qu'hybride) ont de meilleur performance que les micro-noyaux à cause du mode protégé.
2- les ordinateurs sont de plus en plus souvent multi-processeurs (ou multi-coeur), ce qui nécessite, pour les noyaux monolithiques, de limiter la présence de verrous pour pouvoir en tirer partie.
3- la conception d'un micro-noyaux me semble beaucoup plus facilement parallélisable (i.e asynchrone)
D'où ma question:
A quoi bon encore un noyau monolithique? Leur performances devraient être grandement améliorées?
Marc
[^] # Re: Petite question: noyau monolithique?
Posté par abramov_MS . Évalué à 10.
[^] # Re: Petite question: noyau monolithique?
Posté par case42 (site web personnel) . Évalué à 5.
Si il y a un kernel hacker dans la salle pour nous donner quelques certitudes à ce propos...
[^] # Re: Petite question: noyau monolithique?
Posté par reno . Évalué à 8.
1) Normalement les x86 devraient être des grosses bouses au niveau performance comparé a des RISC, mais grace aux investissement monstrueux d'Intel et d'AMD ce n'est pas le cas bien au contraire!
2) DragonFly BSD a été créer avec un système en théorie plus performant que FreeBSD pour l'utilisation du parallélisme, mais comme il y a très peu de contributeurs sur DragonFly BSD, le résultat est que FreeBSD enterre DragonFly BSD sur ce point à l'heure actuelle.
Donc pour pouvoir comparer objectivement les performances d'un micro-noyau et du kernel Linux, il faudrait que l'investissement en effort soit le même dans les deux cas, ce qui n'est pas près d'arriver..
[^] # Re: Petite question: noyau monolithique?
Posté par Romeo . Évalué à 2.
Hurd ~18.
FreeBSD >18ans (pas trouvé la date exacte).
Ecrire un kernel prends du temps...
[^] # Re: Petite question: noyau monolithique?
Posté par pasBill pasGates . Évalué à 1.
Ce qui prend du temps c'est d'ecrire tout le reste de l'OS afin de rendre le kernel utilisable.
[^] # Re: Petite question: noyau monolithique?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: Petite question: noyau monolithique?
Posté par pasBill pasGates . Évalué à 3.
Suffit de voir ce qui s'est passe avec Hurd, du fait du design nombre de choses ont du changer dans les couches du dessus pour eviter des performances horribles ou tout simplement pour pouvoir fonctionner.
Notes que je parles pas du jeu de cartes sous KDE hein mais des couches directement au dessus du kernel (libc, etc...) qui forment l'API de l'OS
[^] # Re: Petite question: noyau monolithique?
Posté par reno . Évalué à 3.
Pour ce qui est de l'espace utilisateur, certes si ton nouveau noyau offre une interface 'a la Unix' alors tu peux réutiliser l'existant certes, mais cela implique aussi que ces appli n'utiliseront pas les nouvelles fonctionnalités de ton OS (au moins dans un premier temp).
[^] # Re: Petite question: noyau monolithique?
Posté par Guillaume Knispel . Évalué à 6.
De plus les systèmes asynchrones introduisent leur propres soucis (précisément du fait de l'asynchronisme) et dans la pratique ils sont de plus souvent partiellement encapsulés dans une couche supplémentaire pour fournir des services synchrones... L'overhead par rapport à un appel de fonction classique est ... grand.
Linux utilise aussi des primitives thread-safe lock-free très avancées et très performantes (ex: RCU) qu'il serait probablement très difficile (si ce n'est impossible) d'adapter pour l'userspace.
Dans certains cas les spinlocks conviennent tout à fait et la solution serait nécessairement plus complexe en userspace, par exemple pour de la communication ISR / partie synchrone d'un driver, sous certaines hypothèses.
Pour finir l'expérience a montré que le confinement des défaillances qu'on pensait être une des killer feature des micro-noyau n'est pas si effectif que cela (le système peut tout de même s'effondrer par effet domino dans de nombreux cas), en plus de n'être plus si nécessaire aujourd'hui (les noyaux modernes plantent peu).
[^] # Re: Petite question: noyau monolithique?
Posté par Victor STINNER (site web personnel) . Évalué à 4.
De quoi tu parles ? Les publications de Tanenbaum sur MINIX3 sont très positives. J'avais lu un papier qui montrait qu'on pouvait tuer les pilotes de la carte réseau toutes les 5 secondes tout en téléchargeant un image ISO : le téléchargement se fait sans aucun problème (wget). Papier qui explique un peu mieux les problèmes résolus par l'isolation des pilotes dans des processus indépendants :
http://www.cs.vu.nl/~jnherder/ir-cs-018.pdf
Aucun système n'est parfait, mais j'ai quand même tendance à penser que la conception de MINIX3 est plus solide face à Linux si on compare la tolérance aux pannes.
[^] # Re: Petite question: noyau monolithique?
Posté par Guillaume Knispel . Évalué à 6.
Un test plus intéressant consisterait à tuer le pilote du HD alors que le système est à pleine charge d'un peu tout et n'importe quoi (et en train de swapper, gniarf :P ) et de voir ce qu'il se passe.
Dans la série des problèmes ouverts il faudrait aussi voir comment intégrer les monstrueux pilotes actuels de carte graphique dans un tel environnement, avec de bonnes performances. Bref tout un programme, qui reste encore dans le domaine de la recherche.
la conception de MINIX3 est plus solide face à Linux si on compare la tolérance aux pannes.
Peut-être vis à vis de certaines défaillances soft ; mais de toute manière les systèmes fault-tolerant ont tendance à être complètement redondant au niveau matériel et il y a des cas où ça peut mitiger le risque de défaillance soft, alors est-ce que tous les inconvénients valent la peine, alors même que les systèmes Linux sont déjà très fiable (et rapide) ?
Je vois un domaine où les micro-noyaux peuvent apporter un énorme plus : les phases de développement et mise au point sont grandement facilitées.
[^] # Re: Petite question: noyau monolithique?
Posté par Thomas Douillard . Évalué à 10.
C'est pas très gentil pour les codeurs de Hurd.
[^] # Re: Petite question: noyau monolithique?
Posté par benja . Évalué à 4.
Qu'est-ce qui te fais dire cela ? J'aurais tendance à penser qu'ils deviennent de plus en plus complexes à l'instar des cartes: tcp/ip offloading, queue multiples, wifi-n, ...
[...] le support de l'userspace est probablement très bon dans sa globalité en ce qui concerne les coupures impromptues du réseau.
J'imagine que l'intérêt de la démonstration était justement que wget n'en sache rien, c.-à-d. que sa connexion tcp/ip n'a pas été coupée*. En ce qui concerne la gestion des coupures réseaux, c'est clairement une fonction de la pile tcp/ip qui, pour le noyau linux, ne se trouve pas dans l'"userspace" ! Tu peux débrancer-rebrancher ton cable réseau sans que tes connections tcp/ip ne se coupent mais cela ne marchera pas au point de faire un rmmod-insmod.
Le test que tu propose avec le pilote hdd suit aussi la même logique et ne devrait donc pas poser de problèmes majeurs. Le micro-serveur qui s'occuppe du FS n'a qu'a attendre que le pilote se recharge** avant de soumettre la suite de ses ordres. L'idée est justement de séparer les sous-système dépendants en serveur différents et, je suppose que, minix3 gère cette résillience de manière +/- générique pour n'importe quel pilote.
Même si dans l'hypothèse fort improbable que Linus décide d'implementer la possibilité de recharger un pilote sans déstabiliser les couches logicielles qui en dépendent, tu n'obtiendra jamais le niveau de résillience d'un micro-noyau parce qu'il n'y a pas de séparation d'espace mémoire entre les différents pilotes/sous-systèmes et que donc un bug dans un driver peut modifier le comportement d'une autre partie du noyau (dans le pire cas), voir le crasher (dans le meilleur, car je n'aimerais pas avoir mon fs détruit à cause d'un mauvais pilote résaux ou une carte réseaux détruite à cause d'un Xorg foireux ;-)).
*:Effectivement, wget s'en sort plustôt bien quand la connection est _coupée_ en essayant de reprendre le téléchargement. Il y a dans ce cas une nouvelle connection tcp/ip effectuée et la restauration de l'état précédant la coupure est effectué par _l' application_. C'est de très loin un comportement minoritaire parmis toutes les applications réseaux existantes et qui n'est permis que parce que le protocol http/ftp permet cet usage. Rien à voir avec l'exemple qui nous occupe où la connection n'est tout simplement pas coupée...
**:En admettant qu'il ne faille pas dépendre de ce pilote pour recharger le serveur/pilote. Je ne sais pas comment minix3 gère ce cas mais en théorie cela est tout à fait possible, il suffirait d'avoir un serveur "chargeur" qui garderait en mémoire les pilotes à recharger.
[^] # Re: Petite question: noyau monolithique?
Posté par pasBill pasGates . Évalué à 2.
C'est tres tres loin d'etre aussi simple.
Tu sais que ton driver de FS, le truc qui ecrit directement sur ton disque sans barriere de securite, a plante.
Tu as vraiment envie de le redemarrer et effectuer a nouveau l'operation X qui a de bonnes chances de l'avoir fait planter elle-meme au risque qu'il detruise ta partition ?
J'en doutes...
C'est un peu le meme probleme qu'un kernel panic ou un BSOD, dans un certain nombre de cas, c'est pas un crash pur et simple, mais le systeme qui s'est rendu compte que qqe chose ne collait pas et qui s'arrete de lui-meme.
Le FS c'est hyper-sensible, que le code qui le gere soit en user-mode ou kernel-mode n'y change pas grand chose, et un probleme la dedans est le plus souvent fatal.
Tu peux voir un peu la meme chose sous Unix avec X11, c'est un process qui tourne en user-mode, mais quand il plante, tous les softs avec interface graphique mordent le gazon.
[^] # Re: Petite question: noyau monolithique?
Posté par benja . Évalué à 3.
Ben non, le "driver de FS" n'écrit pas sur le disque dur, mais bien le driver (micro-serveur) "disque dur". Avec une architecture traditionnelle, quand ton pilote controleur disque dur plante, il entraîne ton pilote FS avec. Avec une architecture telle que minix3 ce n'est pas forcément vrai. Comme on dit, 90% des écrans de la morts sont dûs à de mauvais pilotes; j'ai la faiblesse de penser que les autres couches sont plus robustes.
Tu as vraiment envie de le redemarrer et effectuer a nouveau l'operation X qui a de bonnes chances de l'avoir fait planter elle-meme au risque qu'il detruise ta partition ?
Quand ton pilote FS s'est craché, redemarrage (de la machine) ou pas, je ne ferais pas trop confiance quant à la cohérence de ce qui reste sur ton disque dur...
Le FS c'est hyper-sensible, que le code qui le gere soit en user-mode ou kernel-mode n'y change pas grand chose, et un probleme la dedans est le plus souvent fatal.
Toutafé, mais nous discuttions de problèmes dûs aux pilotes et tu nous parles de problème de sous-systèmes indépendants du matériel. Au risque de me répéter, ton bug qui apparaît quelque part dans ton noyau peut impacter une toute autre partie de celui-ci (le temps qu'"il se rende compte que qq chose ne va pas"), entraînant des dégats collatéraux non déterminés/ables; ce qui n'arrive pas avec un micro noyau.
Tu peux voir un peu la meme chose sous Unix avec X11 [...] qui tourne en user-mode
Il tourne en user-mode mais le noyau lui permet de dialoguer directement avec le matos, le plaçant donc au niveau des autres pilotes. C'est à cause de cette dichotomie kernel/user mode qu'on se retrouve avec des trucs goret comme cela.
[^] # Re: Petite question: noyau monolithique?
Posté par pasBill pasGates . Évalué à 2.
C'est pas le probleme, le probleme c'est que t'as beau mettre les 3 couches du dessus dans un autre espace memoire(user), ce que ces couches font est tellement sensible (s'occuper d'ecrire sur le disque) que si elle plantent, les redemarrer n'est de toute facon pas une bonne idee.
Toutafé, mais nous discuttions de problèmes dûs aux pilotes et tu nous parles de problème de sous-systèmes indépendants du matériel. Au risque de me répéter, ton bug qui apparaît quelque part dans ton noyau peut impacter une toute autre partie de celui-ci (le temps qu'"il se rende compte que qq chose ne va pas"), entraînant des dégats collatéraux non déterminés/ables; ce qui n'arrive pas avec un micro noyau.
Cela arrive certes moins avec un micro-noyau, mais la difference au final n'est pas si grande qu'on veut bien le croire.
Tu jettes un oeil au kernel NT, a la base c'est un micro-kernel, le code central est vraiment petit est a rarement des problemes, ce qui merde d'habitude c'est le reste : IO manager, memory manager, FS, ...
Et quand un de ceux-ci plantent, meme si ils etaient hors du kernel, c'est qqe fois possible de redemarrer, c'est souvent dangereux.
Il tourne en user-mode mais le noyau lui permet de dialoguer directement avec le matos, le plaçant donc au niveau des autres pilotes. C'est à cause de cette dichotomie kernel/user mode qu'on se retrouve avec des trucs goret comme cela.
Justement non.
Quand X11 plante, c'est pas le kernel qui tombe, c'est X11, ton apache va tranquillement continuer a tourner.
Le probleme c'est que les apps graphiques dependent de X11, quand il claque, ben il peut redemarrer, mais comment faire pour garder la consistence avec ce que l'instance precedente avait emmagasine comme info ? C'est pour ca que les apps graphiques claquent, parce qu'elles ne peuvent pas tourner sans cette info qui a ete perdue lors du crash.
[^] # Re: Petite question: noyau monolithique?
Posté par Guillaume Knispel . Évalué à 2.
ok, envois ;)
a la base c'est un micro-kernel
rhum rhum - ptet il y a 20 ans sur le papier ? (quand il s'agissait de coder NT OS/2......)
Sous Linux aussi je pourrais regarder les répertoires kernel/ lib/ et mm/ ainsi que la pléthore de threads qui tournent et s'échangent des messages, et m'exclamer : "ouah, mais c'est un espèce de micro-noyau en fait !" - et j'aurais tout aussi tord car le concept de micro-noyau est vraiment une question d'isolation et d'espace d'adressage.
Si mes souvenirs sont bons les anti-virus venaient se hooker anarchiquement un peu n'importe où sous NT jusqu'à il n'y a pas si longtemps. Encore une raison de ne pas parler de micro-noyau : avec une vrai archi de micro noyau il n'y aurait probablement pas de hook anarchique ni même d'interface dédiée mais une simple utilisation des interfaces standards.
Enfin, comme sous Linux, on peut sous NT mettre du swap dans un fichier. Je ne pense vraiment pas que ça soit possible (où à la limite viable) avec un micro noyau sans faire de sérieuses concessions - qui ôteraient sans ambiguïté le titre de micro noyau au final.
[^] # Re: Petite question: noyau monolithique?
Posté par Victor STINNER (site web personnel) . Évalué à 2.
Dans un micro noyau, il est possible de redémarrer un pilote qui gère un système de fichier. Bien sûr, il est possible de détecter si le pilote est redémarré parce qu'il a craché. Dans ce cas, le pilote peut décider de faire les opérations appropriées comme lancer fsck.
Avec Linux, il n'est pas possible de faire ça : si un pilote plante, on ne peut rien faire et souvent on perd le contrôle de la machine. Bien que j'ai l'impression que Linux est capable d'attraper les erreurs et afficher un joli backtrace dans les logs du noyau, donc il pourrait très bien faire certaines opérations en cas de bug (ex: tuer le pilote, le relancer, etc.).
[^] # Re: Petite question: noyau monolithique?
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Petite question: noyau monolithique?
Posté par Victor STINNER (site web personnel) . Évalué à 4.
Tu sembles faire une fixation sur la pilote « qui gère toutes données ». Il me semble qu'un bug dans un pilote de la carte son ou même de ta souris va figer toute la machine, aussi bien sous Linux que sous Windows. Si la machine est figée, tu perds aussi « toutes tes données ».
/me retourne fuzzer sa souris USB avec Python 3000
[^] # Re: Petite question: noyau monolithique?
Posté par Guillaume Knispel . Évalué à 2.
Par exemple un module implémentant un pilote va typiquement enregistrer un ISR, gérer des appels synchrones en provenance de l'userspace, et des fois lancer des threads perso ou autre mécanisme d'exécution asynchrone (tasklet, etc...). Il va de plus s'allouer tout un tas de ressources qui ne sont pas forcement managées (je crois qu'il y a un peu de management possible dans les Linux modernes).
Les oops que tu vois avec backtrace sont dans un contexte en provenance de l'userspace. Le noyau tente dans ce cas d'éviter de paniquer, en tuant le processus appelant (et encore, uniquement quand certaines conditions sont vérifiées). Ce n'est qu'une manière de mitiger le problème ! Si tu vois un kernel oops, sauf si tu es absolument sûr de toi (donc entre autre que tu connais _très_ _très_ bien le code correspondant), sauve tout ce que tu peux et reboot immédiatement !
Maintenant si un pb se produit dans une ISR, ... il n'y a rien d'autre de malin à faire que de paniquer.
[^] # Re: Petite question: noyau monolithique?
Posté par Quzqo . Évalué à 1.
Je crois que les derniers pilotes Intel e1000 ne sont pas de ton avis.
https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008(...)
"Reports have been coming in that the e1000e ethernet driver for Intel GigE chipsets, as included upstream in Linux 2.6.27, may under certain conditions irreparably damage your ethernet hardware by corrupting the on-board firmware."
[^] # Re: Petite question: noyau monolithique?
Posté par Boa Treize (site web personnel) . Évalué à 1.
[^] # Re: Petite question: noyau monolithique?
Posté par Guillaume Knispel . Évalué à 2.
2. Il y a un workaround dans le 2.6.27 : le matos est explicitement configuré pour qu'il se s'auto-détruise pas.
3. Si un pilote en userspace décide de détruire du matériel en le flashant avec n'imp ou en corrompant violemment la NVRAM, et qu'il demande poliment au mécanisme quelqu'il soit d'effectuer cette opération, le matériel sera détruit.
4. Cela provient peut-être d'X.
5. Cela n'entraîne pas de crash de l'hôte.
Conclusion => très très faible probabilité d'avoir un rapport avec l'histoire de noyau micro / pas micro.
[^] # Re: Petite question: noyau monolithique?
Posté par patrick_g (site web personnel) . Évalué à 2.
# Linus, Intel, et sado-masochisme?
Posté par case42 (site web personnel) . Évalué à 3.
[^] # Re: Linus, Intel, et sado-masochisme?
Posté par bubar🦥 (Mastodon) . Évalué à 0.
D' ailleurs l' adjectif "stable" ne s' applique pas à toutes les plateformes ni à toutes les saveurs de cette release...
Patrcik_G, tu nous fait un billet pédagogique et instructif sur les IOMMU ? :p
IOMMU : de grave fuites mémoires sont constatées avec les dernières moutures AMD (quadri-coeurs pour du rt ou de la virt.) chip nvidia. C' est con quant même, avec de l' iommu, non ? :p Du coup amd commite à fond depuis qq semaines...
exemple :
-------------------------
* Joerg Roedel <joerg.roedel@amd.com> wrote:
> +static int calgary_device_supported(struct device *dev)
> +{
> + struct iommu_table *tbl;
> +
> + tbl = find_iommu_table(dev);
> +
> + return translation_enabled(tbl);
> +}
i guess this could be written as a simple:
> +static int calgary_device_supported(struct device *dev)
> +{
> + return translation_enabled(find_iommu_table(dev));
> +}
?
Ingo
--------------------------
Patrick, merci
[^] # Re: Linus, Intel, et sado-masochisme?
Posté par benja . Évalué à 2.
[^] # Re: Linus, Intel, et sado-masochisme?
Posté par liberforce (site web personnel) . Évalué à 2.
M'enfin je vois pas l'intérêt de parler de ce thread, il n'y a pas de bashing sur AMD...
[^] # Re: Linus, Intel, et sado-masochisme?
Posté par patrick_g (site web personnel) . Évalué à 5.
D'un autre coté Linus a posté un article dithyrambique sur son blog à propos des disques SSD Intel : http://torvalds-family.blogspot.com/2008/10/so-i-got-one-of-(...)
[^] # Re: Linus, Intel, et sado-masochisme?
Posté par gpe . Évalué à 5.
[^] # Re: Linus, Intel, et sado-masochisme?
Posté par case42 (site web personnel) . Évalué à 4.
[^] # Re: Linus, Intel, et sado-masochisme?
Posté par Larry Cow . Évalué à 2.
# Heise
Posté par patrick_g (site web personnel) . Évalué à 5.
Un boulot impressionnant !
[^] # Re: Heise
Posté par Dup (site web personnel) . Évalué à 1.
Ah oui bonne dépêche comme toujours et aussi sympa d'avoir mis des liens vers des pdf, je les ai téléchargé et regarderait ça plus tard, bien que ça risque de vite dépasser mes compétences ;)
# Heuu...
Posté par Snarky . Évalué à 10.
Ça veut dire qu'on surf plus vite sur les site de gang bang ?? :-D
Vraiment désolé... J'ai pas pu m'en empêcher...
~~~~> []
[^] # Re: Heuu...
Posté par Hugues (site web personnel) . Évalué à 5.
> Ça veut dire qu'on surf plus vite sur les site de gang bang ??
Nan!!! Juste que le screwdriver décharge plus vite.
# Étonnant...
Posté par Gof (site web personnel) . Évalué à 4.
[^] # Re: Étonnant...
Posté par Jean B . Évalué à 10.
[^] # Re: Étonnant...
Posté par Victor STINNER (site web personnel) . Évalué à 9.
- l'auteur principal de ReiserFS4 est en prison, je suppose que la société (dont le business reposait sur ReiserFS??) qui lui appartient n'est pas au meilleur de sa forme
- ReiserFS4 utilise une structure de données appelée « dancing trees » (arbres dansants) qui sont un genre de B-Tree avec des optimisations pour un système de fichier. Cette structure de donnée rend la restauration d'un système malade délicate. D'ailleurs, je crois qu'il y a peu/pas d'outil de restauration pour ReiserFS4.
- La majorité ou l'ensemble des nouveautés de ReiserFS4 sont maintenant reprises dans les nouveaux systèmes de fichier comme HAMMER, btrfs, tux, etc. Du coup, ReiserFS4 n'est plus aussi intéressant qu'à ses débuts.
- Côté performance, reiserfs4 n'est pas/plus le meilleur.
- Le système de greffon est complexe et ne sera jamais intégré dans le noyau Linux car les développeurs noyau veulent conserver un petit noyau qui ne fait que le strict minimum (voir l'exemple dans la dépêche de patrick avec le décodage vidéo des webcams déplace du noyau vers l'espace utilisateur avant l'inclusion d'un gros patch)
ReiserFS4 n'a jamais été inclu dans le noyau car son auteur, Hans Reiser, n'accepte pas les critiques, n'a jamais voulu faire de concession (ex: abandon du système de greffon) et avait plutôt tendance à fâcher les développeurs noyaux, ce qui n'est pas une bonne idée. On préfère donc un système un peu plus lent et moins innovant qu'un système avec un technologie récente et mal maitrisée (bugs d'implémentations).
Rappel : un système de fichier doit être parfait. On peut tolérer des bugs graphiques (suffit de relancer X), mais pas de bugs dans un FS (un fichier perdu est vraiment perdu).
Apparament, ReiserFS4 a provoqué plus de bruits (trolls) que n'a fait avancé la recherche sur les systèmes de fichier...
# Driver ou Firmware?
Posté par Andréas Livet . Évalué à 2.
Tout d'abord, je tenais à remercier patrick_g pour ses superbes dépêches sur le noyau linux, c'est toujours très intéressant!!
Je voulais poster mon commentaire depuis le jour de la sortie de la dépêche mais je n'ai eu mon compte qu'aujourd'hui (un problème avec gmail sûrement), donc je pose ma question maintenant ;).
Je ne m'y connais pas du tout en noyau linux mais je ne comprend pas bien ce que patrick entend par firmware. Les firmwares ne sont pas des sorte de drivers mais intégrés au hardware? Dans ce cas, comment se fait-il qu'il y' ait des firmwares dans le noyau? Quel est la différence (dans la nomenclature linuxienne) entre un firmware et un driver? Aussi, on parle souvent de driver propriétaires, or ici, patrick parle de firmwares propriétaires, est-ce pareil?
Merci d'avance pour vos éclaircissements,
Andréas
[^] # Re: Driver ou Firmware?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Contrairement à un pilote, dont le code est exécuté sur le processeur de la machine, un micrologiciel est exécuté (ou utilisé différemment, d'une manière ou d'une autre) directement par le périphérique concerné.
[^] # Re: Driver ou Firmware?
Posté par Boa Treize (site web personnel) . Évalué à 7.
Au tout début, les firmware étaient gravés dans une ROM. S'il y avait un bug, on ne pouvait rien y faire. Avec la complexité croissante des périphériques et des firmware, la possibilité de les mettre à jour est devenue très recherchée. Sont alors apparues les ROM réinscriptibles, et la possibilité de "flasher" les firmware, c'est à dire d'inscrire une nouvelle version du firmware dans la ROM, opération relativement risquée à ne pas interrompre en plein milieu, bien entendu. Enfin, certains se sont dit qu'avec la vitesse accrue des connexions aux périphériques (USB, etc.), il était plus simple et plus fiable d'envoyer le firmware au périphérique lors de sa connexion à l'ordinateur. C'est bien sûr le pilote du périphérique qui s'en charge. Comme ça, en cas de bug, le pilote peut être mis à jour (facilement, grâce aux fonctionnalités de mise à jour automatique des systèmes d'exploitation modernes), et le périphérique utilisera automatiquement une version corrigée du firmware dès qu'il sera reconnecté ou redémarré.
Maintenant tu devrais mieux comprendre ce qu'il se passe au niveau de Linux. Les firmwares dont on parle dans l'article ne sont pas vraiment "dans" le noyau, ils sont juste stockés sur le disque dur sous forme de fichiers binaires, prêts à être uploadés par le pilote Linux qui-va-bien quand le matériel qui-va-bien est branché sur le PC. Auparavant, l'endroit où ces fichiers sont stockés n'était pas standardisé : chaque pilote faisait comme il voulait, il y en avait un peu partout. Maintenant, il y a un répertoire standard dans lequel tous les firmware sont placés, c'est plus propre.
Enfin, il faut savoir que la plupart des firmwares sont fournis sans code source, vu qu'ils contiennent plein de détail intimes sur la manière dont le périphérique est conçu. Les fabricants n'ont aucune envie de diffuser leurs secrets de fabrication. En général d'ailleurs les firmwares ne sont même pas fournis pour Linux, les programmeurs les récupèrent au fond des pilotes Windows officiels du constructeur. De nombreuses personnes préféreraient disposer du code source de toute leur informatique, et n'apprécient donc pas les firmware "purement binaires", également dits "propriétaires". (Dans certains cas d'ailleurs, des programmeurs se sont aventurés à créer leur propre firmware pour leurs périphériques.)
[^] # Re: Driver ou Firmware?
Posté par abramov_MS . Évalué à 3.
[^] # Re: Driver ou Firmware?
Posté par Boa Treize (site web personnel) . Évalué à 2.
Il avait l'habitude d'avoir les sources et de les corriger en cas de problème, il s'est retrouvé face à un cas de pilote binaire dont les sources étaient distribuées sous conditions de confidentialité, il n'a pas apprécié du tout, et ça lui a fait prendre conscience du risque posé par ce genre d'approche.
[^] # Re: Driver ou Firmware?
Posté par Andréas Livet . Évalué à 1.
Je ne savais pas du tout que les firmwares étaient maintenant chargés à la connexion, je croyais qu'ils étaient toujours en mémoire ROM...
Donc, si j'ai bien compris, seul les drivers on un espoir d'être tous libres un jour, les firmware, trop complexes et trop liés au matériel ne pourront pas être implémentés par un "dev lambda". A moins que les entreprise release le code source de leurs firmwares... mais bon c'est une autre histoire!
Encore merci,
Andréas
[^] # Re: Driver ou Firmware?
Posté par Boa Treize (site web personnel) . Évalué à 1.
Déjà à la base, ça ne marche qu'avec du matériel qui n'est utilisé qu'exclusivement avec un PC (genre les p'tites imprimantes, les gadgets USB, les modems, etc.) Pour le matériel qui doit pouvoir fonctionner sans PC (genre imprimante réseau, modem-routeur-wifi ADSL, etc.), ça marche pas génial ce genre de technique. ;-)
Et puis j'imagine qu'il y a des parties parfois tellement sensibles que le fabricant ne veut même pas que le firmware soit disponible dans un fichier qui traîne au fond du PC et qu'un hacker pourrait s'amuser à venir déchiffrer.
Oui programmer un firmware est encore plus complexe que programmer un driver, et ils peuvent contenir des choses assez sensibles (par exemple une limitation des fréquences utilisées par du matériel wifi, pour respecter la loi... si on publie le code source, les utilisateurs vont-ils se mettre à ne rien respecter ?). Ceci dit, rien n'arrête certains dans leur quête de liberté absolue. Et c'est peut-être pour le plus grand bien général.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.