mercredi 28 juillet
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Nouvelle version 2.6.32 du noyau Linux

Posté par patrick_g (page perso, ). Modéré le 03 décembre 2009.
95
La sortie de la version stable 2.6.32 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.
Ce noyau 2.6.32 est particulièrement important car il sera intégrée dans la prochaine version Ubuntu avec support à long terme (Ubuntu 10.04 LTS) et dans la prochaine version Debian 6.0 "Squeeze".

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

> Lire la suite (140 commentaires, moyenne: 3,3).   [dépêche : 73198 caractères]

Le sommaire...


La phase de test (↑)

RC-1

La sortie de la RC-1 a été annoncée par Linus le 27 septembre :

« Cela fait deux semaines (et même un peu plus – mais la semaine dernière c'était la conférence Linux et ensuite la Plumber conf donc j'ai rallongé de quelques jours) et comme d'habitude cela signifie que la période de merge est terminée. La RC-1 est disponible donc essayez-là.
Qu'est-ce que je peux dire ? 67% des changements concernent les pilotes (avec le plus gros concernant la branche staging mais il y a d'autres changements dans tous les sens), 10% les micrologiciels, 10% sont spécifiques aux diverses architectures (avec une domination de ARM mais aussi du MIPS, Power, SH, x86 et aussi la nouvelle architecture SCore), 5% de documentation et le reste réparti sur tous les autres trucs (systèmes de fichiers, noyau, réseau, etc).
Pour une fois je ne pense pas que nous ayons de nouveau système de fichiers… mais nous avons des mises à jour des systèmes existants (ocfs2, btrfs, nfs, nilfs, xfs, gfs2, ext4 – autant que vous voulez).
Certains des changements les plus intéressants (mais c'est peut être juste moi) concernent les machines virtuelles (le retour de ZERO_PAGE) et le travail de Jens et des autres sur le writeback.
Précipitez-vous, testez et informez-nous de chaque régression que vous trouvez ».

RC-3

Linus s'est un peu loupé sur le processus de sortie de cette RC-1 puisqu'il y avait dans le makefile, par erreur, la mention "RC-2" au lieu de "RC-1". Une fois informé, il a d'abord gémi :

« Oh nnooooooooooooo-(reprise de respiration)-ooooooooooooonnnn...
Putain. Je n'avais pas réalisé. Je suis vraiment un crétin ».

Puis, il a ensuite décidé de sauter l'étape RC-2 pour éviter les risques de confusion. Le 4 octobre, c'est donc directement une RC-3 qui a été annoncée :

« Oui, c'est vraiment la RC-3 parce que j'ai pris la décision de sauter la RC-2 complètement.
Enfin, pas complètement car, comme beaucoup de gens l'ont remarqué, j'ai été un peu négligent et la version RC-1 portait le nom RC-2 dans son fichier makefile. Le résultat, c'est que maintenant je ne veux pas faire une version RC-2 car les rapports de bugs seraient accueillis avec pas mal de confusion : "Est-ce que vous parlez de la RC-2 du makefile (c'est-à-dire la RC-1) ou de la vraie RC-2 ?".
Donc, j'évite complètement cette confusion et je considère que la RC-1 était aussi la RC-2 et donc, une semaine plus tard, nous voilà à la RC-3. Espérons que je ne vais plus avoir de "moment d'absence" comme ça. Quoique je suis certain de pouvoir saloper une livraison de beaucoup de façons différentes.
Bon, en ce qui concerne les changements cela a été assez calme. Le plus gros changement a été effectué sur le pilote réseau e1000 mais il y a aussi des mises à jour DRM (sur le nouveau pilote Radeon expérimental) et d'autres trucs.
Une chose qui mérite d'être mentionnée (même si c'est très petit) est qu'il y a eu des réglages sur la latence des entrées-sorties dans la couche en mode bloc (l'ordonnanceur CFQ). J'espère que cela constituera un changement notable et que les gens constateront un meilleur temps de réponse ».

RC-4

Le 11 octobre la RC-4 est apparue sur les serveurs :

« Nouvelle semaine, nouvelle RC. Environ 60% du patch se concentre dans un seul pilote SCSI Fibre channel gros et bouffi (ouais j'ai été a deux doigts de ne pas l'inclure du tout) et si vous regardez tous les pilotes et le répertoire arch/blackfin cela représente environ 97% du total des changements depuis la RC-3.
La prochaine RC sera vraiment plus petite, non seulement parce que je vais vraiment refuser ces pilotes-sortis-de-l'enfer mais, plus important, parce que cela va être une "petite semaine". Le sommet annuel du noyau s'approche et je ne veux pas sortir une version depuis Tokyo quand je serai abruti par le décalage horaire. ce sera donc certainement une RC-5 le jeudi ».

RC-5

C'est donc dès le 15 octobre, juste avant de s'envoler, que Linus a annoncé la sortie de la version candidate RC-5 :

« Comme mentionné dans les notes de la RC-4, cela a été une petite semaine pour cette version car je pars demain matin pour le sommet annuel du noyau. Évidemment beaucoup de mainteneurs sont déjà partis ou bien vont le faire sous peu donc je m'attends / j'espère que la semaine prochaine sera aussi calme.
90% des changements sont dans les pilotes avec en particulier deux nouveaux pilotes réseau (stmmac and vmxnet3). À part ça il y a environ 300 commits et la plupart sont des changements d'une ou de quelques lignes : (ARM, powerpc, x86), systèmes de fichiers (surtout btrfs), la documentation, le réseau, etc.
Quelques régressions de corrigées et, on l'espère, pas de nouvelle régression introduite ("Ouais, comme si ça n'arrivait jamais") ».

RC-6

Du fait de ces conférences lointaines dans des pays exotiques, il a fallu attendre un peu plus longtemps que la normale pour la RC-6 pointe le bout de son nez :

« Cela fait plus de deux semaines depuis la RC-5, en partie parce qu'il y a eu une semaine très tranquille car de nombreux développeurs (dont moi) étaient à Tokyo pour le sommet annuel du noyau. Il y a eu aussi un ennuyeux problème de corruption sur le système de fichiers ext4 après une extinction brutale.
Il s'est avéré que ce problème était "juste" parce que les sommes de contrôle avaient été activées en test sur les transactions du journal (en mode restauration). La correction a consisté à désactiver à nouveau cette fonction. Les développeurs ext4 vont maintenant passer une loooongue et dure période pour comprendre ce qui a causé ce problème sans même générer un printk d'alerte.
Merci beaucoup à Eric Sandeen qui a bissecté ce bug difficile à reproduire et à tous les gens qui ont aidé pour les tests. Une fois que cela a été identifié, la correction a été triviale mais les problèmes de corruption des systèmes de fichiers me rendent toujours très nerveux.
Il y a aussi de mises à jour d'architectures (powerpc, arm, ia64 et mips) et le reste consiste en petits changements, surtout dans les pilotes mais aussi dans la documentation ».

RC-7

Le 12 novembre, après une traque au bug haletante, Linus a annoncé que la version RC-7 était disponible sur les serveurs de kernel.org :

« Cette fois j'ai un peu retenu la RC car j'avais peur d'une horrible régression dans la fonction de sortie de veille sur laquelle Rafael était en train d'enquêter. Finalement au lieu d'être quelque chose de vilain et de fondamental cela s'est révélé être un bug trivial de pilote (ici "trivial" signifie "vilain et difficile à détecter mais n'impliquant pas le cœur du code").
Donc maintenant c'est corrigé ainsi que pas mal d'autres petites régressions ».

RC-8

Après une ultime version RC-8 de stabilisation Linus a publié le noyau 2.6.32 définitif.

Les nouveautés (↑)

Écriture des données par BDI

Après plusieurs mois de travail Jens Axboe a incorporé son travail permettant l'écriture des données par BDI.

Dit comme ça, cela semble assez ésotérique, mais si on se penche sur les détails de cette série de patchs alors on comprendra mieux les tenants et les aboutissants des efforts de Jens.

Quand les applications s'exécutant au dessus du noyau veulent écrire des données alors Linux place ces données dans un cache nommé "page cache". Au fur et à mesure que les données sont mises dans une queue d'entrées/sorties allant conduire à l'écriture sur le périphérique elles sont marquées par un indicateur dirty. Enfin les données étant vraiment en train d'être écrites sur le périphérique sont identifiées comme étant en writeback.

Vous pouvez voir ce qui se passe sur votre noyau à un moment donné en faisant un simple cat /proc/meminfo. Par exemple voici le résultat de cette commande sur ma machine (pour faciliter la lisibilité je n'ai laissé que les lignes qui nous intéressent) :
patrick@laptop:~$ cat /proc/meminfo
MemTotal: 2067360 kB
Cached: 1170880 kB
Dirty: 6496 kB
Writeback: 0 kB

Ma mémoire totale est de 2 Go, j'ai 1,17 Go en cache et il y a 6,5 Mo qui sont marqués comme dirty, c'est à dire qu'ils sont en chemin pour être écrits sur le disque. Enfin aucune écriture ne se fait en ce moment.

On comprend bien que ces données dirty et writeback sont donc très transitoires et qu'un cat /proc/meminfo s'effectuant quelques secondes plus tard donnera un autre résultat.

Pour passer de l'état dirty à l'état writeback les données doivent commencer à être effectivement écrites. Au temps du noyau Linux 2.4 c'était un seul processus, nommé bdflush, qui s'occupait de cette tâche.

Le noyau 2.6 a apporté une belle innovation avec pdflush puisqu'au lieu d'un processus unique on est passé à une architecture basée sur des processus légers noyau (entre 2 et 8) qui se chargent d'écrire les données. La règle est de commencer avec deux et d'attendre une seconde. Si les deux processus légers pdflush sont occupés alors un troisième est créé… et on continue ainsi jusqu'à huit. Si au bout d'une seconde un processus léger est resté inactif alors on le supprime et on peut ainsi redescendre jusqu'à deux.

Pour voir combien vous avez de processus légers pdflush s'exécutant actuellement sur votre machine faites donc un petit cat /proc/sys/vm/nr_pdflush_threads.

Bien qu'elle représente un progrès par rapport à l'antique bdflush du noyau 2.4, cette technique a également des limitations. Par exemple le groupe de processus légers (thread pool) est commun à tous les périphériques en mode bloc. Comme il doit donc travailler pour tous les périphériques en même temps, il ne lui est pas permis de bloquer sur l'un d'eux et il y a des situations où il ne peut satisfaire tout le monde (request starvation). Il existe également des périphériques très rapides qui voudraient qu'un groupe de processus légers leur soit entièrement dédié.

C'est ici qu'intervient le travail de Jens Axboe qui propose, au lieu d'un bête groupe commun de processus légers noyau, qu'il y ait un groupe de processus légers par périphérique (ou plutôt par BDI ce qui signifie Backing Device Info et qui représente une sorte d'abstraction au dessus des périphériques réels). Pour faire bonne mesure on monte à 32 le nombre de processus légers pouvant être créés dans les groupes affectés à chacun de ces BDI.

Avec cette nouvelle solution, il n'y a plus de risque de ne plus satisfaire les périphériques et les écritures peuvent s'effectuer plus rapidement puisque chaque processus léger (ou groupe de processus légers) d'un BDI peut se bloquer sur lui sans impacter les autres.

Jens Axboe, outre ses messages sur la liste de diffusion du noyau, a présenté son travail lors de la dernière Linux Plumber Conference et il existe également un fichier PDF très détaillé sur ce patch.

Le gain en performance apporté par cette technique d'écriture des données par BDI est assez important. Chris Mason a ainsi posté des graphiques concernant cinq disques SATA en LVM et formatés avec le système de fichiers XFS. Lors des écritures on passe de 277 Mo/s à 388 Mo/s. Jens indique que ses tests indiquent une amélioration de 8% pour un simple disque SATA et de 25% pour un ensemble de dix disques formatés en Btrfs.

Changements dans l'ordonnanceur CFS

Le noyau 2.6.32 propose de nombreux changements dans l'ordonnanceur CFS qui touchent les options par défaut et qui corrigent des dysfonctionnements. En effet l'arrivée du concurrent BFS, proposé par Con Kolivas, a provoqué une soudaine activité de tests et de comparaisons ce qui a permis d'améliorer CFS et l'ordonnancement des processus dans le noyau Linux.

Le premier changement concerne l'option CHILD_RUN_FIRST qui est maintenant à false. Cette option contrôle le comportement de l'ordonnanceur CFS juste après un fork, c'est à dire juste après la création d'un nouveau processus par un processus parent. Auparavant CFS passait la main le plus vite possible au processus fils, ce qui explique le nom de l'option CHILD_RUN_FIRST, et ce comportement avait été choisi à l'époque lointaine du noyau 2.4.4 (le patch date de 2001) avec l'idée que quand on fait un fork c'est pour exécuter un certain travail donc le processus fils doit passer devant.

Avec ce changement de comportement par défaut introduit dans le noyau 2.6.32 c'est maintenant le processus père qui garde la main ce qui, au vu des tests, améliore substantiellement les performances. Cela s'explique, entre autres, par le fait que le processus parent s'exécute déjà dans le processeur et que vider les caches (le TLB) pour faire de la place au processus fils prend du temps. Cela pouvait avoir du sens au moment du noyau 2.4.4 sur une machine simple processeur mais maintenant, à l'ère des double et quadri-cœurs, il vaut mieux garder le processus père sur le premier processeur et envoyer directement le fils sur un autre processeur et les tests montrent que c'est plus efficace.

L'opération "grand ménage de printemps" sur l'ordonnanceur a continué avec la désactivation par défaut de l'option NO_NEW_FAIR_SLEEPERS qui donnait un petit crédit de temps à un processus juste après son réveil. Ce changement améliore grandement l'interactivité des applications.

Un vilain bug de CFS sur des machines multi cœurs, évoqué dans ce journal Linuxfr, a également été corrigé grâce à Jason Garrett-Glaser qui est un développeur du codec x264. Celui-ci avait remarqué que BFS, le bébé de Con Kolivas, pouvait avoir jusqu'à 80% de performances en plus sur un codage x264 par rapport à CFS. Ce comportement pathologique ne pouvait s'expliquer que par un bug et il a donc posté sur la liste de diffusion du noyau un compte-rendu et une procédure pour reproduire le bug. Dès le lendemain un patch corrigeait le bug et améliorait les performances de CFS d'environ 70%. Dans les jours qui ont suivi un autre gain supplémentaire de 10% a été obtenu pour la plus grande joie de Jason (mais aussi des autres applications comme PostgreSQL ou MySQL ainsi que le démontre ce benchmark de Mike Galbraith).

Enfin, le dernier changement notable dans le code d'ordonnancement du noyau 2.6.32 concerne la gestion des phases de repos du processeur.

Actuellement, cette gestion est déléguée à un "gouverneur" qui détermine quand et comment le processeur doit s'endormir, changer de fréquence, se réveiller, etc. On croit souvent que l'algorithme de gestion d'un tel gouverneur est assez simple (pas de travail à faire : on s'endort ; du travail à faire : on se réveille et on monte la fréquence), mais en réalité c'est loin d'être le cas.

Il faut tenir compte du coût en énergie et en temps des transitions entre les nombreux états possibles des divers processeurs. Par exemple un processeur Intel de type T7300 met 100 nanosecondes à sortir de l'état de sommeil C2 et revenir à l'état normal C0. L'avantage c'est qu'en phase C2 il ne consomme que 30% de ce qui est consommé en C0. Si vous voulez économiser encore plus alors le processeur peut entrer en phase C4 ou la consommation est réduite à seulement 2% mais le désavantage est qu'il faut 160000 nanosecondes pour repasser en phase C0.

On voit donc que la politique à appliquer se doit d'être subtile et bien adaptée car, en réalité, le processeur n'a aucun moyen de savoir la quantité de travail qu'il va devoir effectuer à l'instant suivant. Le gouverneur est donc éternellement condamné à tenter de deviner, par des heuristiques ou des statistiques, ce qu'il y aura à faire à l'instant T+1.

Jusqu'à présent le code marchait "assez bien" mais le processeur Intel Nehalem, avec sa gestion de l'énergie particulière, a permis de mettre en évidence des problèmes dans ce code.

Après avoir réfléchi à la question et procédé à de longs tests, Arjan van de Ven a proposé un patch complexe destiné à améliorer les performances du gouverneur du noyau 2.6.32. Le code de ce patch est très commenté afin de permettre de comprendre comment se fait vraiment le calcul.

En résumé, Arjan est parti de l'idée que si le processeur ne peut pas deviner le futur, il peut au moins savoir à quel moment va avoir lieu la prochaine interruption programmée. Son algorithme calcule donc la différence entre ce qui avait été programmé (la borne supérieure donc) et l'interruption réelle ayant eu lieu parce qu'il y avait soudain du travail à faire. Le code d'Arjan maintient ainsi des statistiques à propos de cet écart moyen et il intègre aussi un facteur multiplicateur en fonction des entrées/sorties en cours ou en fonction de la charge de travail des processeurs. La formule donnant ce coefficient multiplicateur est "1 + 20 fois la charge moyenne du processeur (load_average) + 10 fois l'attente moyenne des entrées/sorties (iowait_count)".

Ce coefficient multiplicateur est alors appliqué à une table qui recense les temps de latence qui affectent les différents types de processeurs pour sortir de leurs différents états d'endormissement. Le résultat de tout ce calcul est alors comparé aux statistiques obtenues précédemment et le gouverneur d'Arjan prend finalement la décision d'endormir ou non le processeur en fonction de ce résultat.

Tout ceci peut sembler bien compliqué mais le résultat brut est très impressionnant puisque le benchmark fio utilisé par Arjan sur une machine à base de Nehalem donne ceci :

# Aucune gestion de l'énergie
1 disque 107 Mb/s
2 disques 215 Mb/s
12 disques 590 Mb/s

# Gouverneur actuel du noyau Linux
1 disque 85 Mb/s
2 disques 123 Mb/s
12 disques 320 Mb/s

# Gouverneur amélioré d'Arjan
1 disque 105 Mb/s
2 disques 209 Mb/s
12 disques 585 Mb/s

On voit bien que le gouverneur amélioré permet, tout en conservant les économies d'énergie de l'ancien gouverneur, de retrouver quasiment les mêmes performances qu'une machine qui tourne en permanence à la fréquence maximum ce qui constitue donc une belle avancée.

HWPOISON

Dans le contexte d'une gestion améliorée des barrettes de mémoire RAM défectueuses une solution technique innovante, le patch HWPOISON, a été incorporée au nouveau noyau.

Ce code permet d'aller au delà de la protection qui est permise par la technique ECC. Avec une mémoire protégée par ECC la protection n'est que très relative puisque cela permet de corriger une erreur quand elle affecte un seul bit mais qu'on doit se contenter d'une détection l'erreur, sans correction possible, quand l'erreur concerne deux bits. Comme cette double erreur est très susceptible d'entraîner un crash de la machine, la motivation des développeurs du noyau était forte pour essayer d'améliorer la situation.

L'idée générale est qu'une défaillance devrait tout au plus provoquer une invalidation de certaines zones mémoires et pas un horrible crash. De cette façon, l'erreur est contenue et ne peut plus affecter le reste de la machine.

Andi Kleen a donc travaillé sur le patch HWPOISON afin d'implémenter cette idée qui marche de la façon suivante (si le noyau a été compilé avec l'option MEMORY_FAILURE) : le processeur détecte une erreur non corrigible et, au lieu d'envoyer une demande de seppuku au noyau, se contente de mettre un indicateur sur cette zone mémoire afin de se souvenir qu'elle n'est plus fiable (d'où le nom du patch, la page mémoire est considérée comme "empoisonnée"). La machine peut ainsi continuer à fonctionner normalement, jusqu'à ce qu'un processus quelconque veuille lire ou écrire dans cette zone mémoire empoisonnée. On évite ainsi le crash qui était inévitable auparavant.

Quand un processus réclame l'accès à la page mémoire empoisonnée, c'est le code HWPOISON qui intervient afin de décider ce qu'il faut faire. Il peut introduire un délai afin de voir si l'erreur mémoire n'était que transitoire (ce qui arrive assez souvent) et réessayer plus tard. Il peut aussi essayer d'isoler la page mémoire en erreur pour protéger les applications et recharger les données si une copie non modifiée existe sur le disque. Enfin, le code HWPOISON peut prendre la difficile décision, pour sauver le système d'exploitation, de tuer les processus affectés par l'erreur mémoire (assassinat précoce, si on utilise l'option vm.memory_failure_early_kill et assassinat après un délai de grâce, si on utilise l'option vm.memory_failure_recovery).

Une limitation de HWPOISON est que cette technique nécessite une coopération entre le noyau et le processeur sous-jacent. Seuls des processeurs dotés de fonctions spéciales de détection et d'isolation, MCA pour Machine Check Abort, pourront donc en profiter (le très récent Intel Nehalem-EX fait partie de la liste). Actuellement le patch n'est compatible qu'avec les machines x86 et x86-64 mais comme les processeurs SPARC et IA-64 sont dotés des mêmes raffinements techniques il est fort probable qu'ils profiteront eux-aussi bientôt de HWPOISON.

Gestion dynamique de l'énergie

Une grosse nouveauté introduite dans le noyau 2.6.32 est le patch de gestion dynamique de l'énergie (runtime power management) proposé par Rafael Wysocki.

Selon Rafael, on peut considérer la mise en veille de la machine comme un problème résolu et, en ce qui concerne les phases de travail de l'ordinateur, la gestion d'énergie du processeur est très efficace...alors que reste-il à faire dans ce domaine ?

L'idée derrière son patch est de s'attaquer, par un code unifié, aux divers périphériques d'entrées/sorties qui jusqu'à présent ne bénéficiaient pas d'une bonne gestion de l'énergie.

Rafael a implémenté une infrastructure centralisée de gestion de l'énergie qui permettra de mettre en veille et de rallumer à la volée les divers périphériques d'une machine afin de gagner en consommation d'énergie. Ce travail de fond a été tout particulièrement scruté par les développeurs du noyau puisqu'il y a eu plus de 17 révisions depuis la proposition initiale de Rafael. La nouvelle infrastructure est décrite en détail dans la documentation technique et elle consiste à ajouter, pour chaque type de bus d'entrées/sorties, des fonctions que va pouvoir utiliser le noyau et les pilotes des périphériques. Un appel à la fonction runtime_suspend() basculera le périphérique en mode veille et il ne reviendra à la vie qu'à la suite d'un runtime_resume()/

Il est à noter que ce travail sera sans doute complété dans les noyaux suivants par une réécriture et une adaptation des divers pilotes afin de profiter pleinement de cette nouvelle infrastructure de mise en veille à la volée.

Gestion d'intégrité TXT

Le mécanisme de gestion d'intégrité TXT d'Intel a été ajouté dans le noyau 2.6.32.

Cette fonction ne doit pas être confondue avec l'architecture de contrôle d'intégrité (IMA pour Integrity Management Architecture) qui a fait son entrée dans le noyau 2.6.30 et qui s'occupait de faire vérifier par le noyau que des fichiers ou des exécutables n'avaient pas été modifiés. Mais évidemment IMA, en tant que mécanisme faisant partie du noyau, repose sur la confiance qu'on accorde au noyau lui-même quand il procède à la vérification. Comment être certain que le noyau n'a pas été compromis ?

C'est ici qu'entre en scène la nouvelle gestion d'intégrité basée sur TXT (Trusted Execution Technology). L'idée d'Intel est d'interposer un petit hyperviseur entre le noyau et le matériel. Cet hyperviseur se nomme tboot (pour Trusted Boot) et il constitue le cerbère qui va vérifier toutes les étapes de lancement du noyau Linux. Son fonctionnement est détaillé dans ce message de Joseph Cihula mais l'idée générale est la suivante : Grub lance tboot comme si c'était le noyau normal et tboot vérifie ensuite que le matériel gère bien la technologie TXT de gestion d'intégrité. Si ce n'est pas le cas, le noyau est lancé sans plus aucun contrôle. Si TXT est bien présent sur la carte mère, alors tboot vérifie toute la chaine logicielle depuis le BIOS, les micrologiciels, etc jusqu'à ce que le noyau soit effectivement lancé. Cette vérification de tous les maillons de la chaîne de confiance se fait par comparaison avec des empreintes (hash) présentes dans la puce de stockage sécurisée (TPM pour Trusted Platform Module). Il est également possible, à l'aide d'un fichier indiquant les préférences de l'utilisateur (user-defined launch policy), de modifier le comportement de tboot.

tboot refait surface lors des mises en veille ou en hibernation, car il fait des signatures cryptographiques des prises d'empreintes (hash) de la mémoire. Cela permet d'éviter une attaque sur le noyau qui serait effectuée durant ces phases d'hibernation de la machine.

La gestion d'intégrité basée sur TXT peut certainement constituer une couche de protection intéressante pour certains utilisateurs, mais il est probable que tout le monde ne sera pas ravi de l'utiliser. Le pilote de la carte compatible TXT est un binaire signé par Intel (Q35_SINIT_17.BIN) et le code gérant le matériel à très bas niveau (system management mode ou SMM) n'est lui non plus pas disponible, ce qui inquiétera les plus paranoïaques d'entre nous.

devtmpfs

Un ajout assez controversé au noyau 2.6.32 est celui de devtmpfs par les développeurs Kay Sievers et Greg Kroah-Hartman.

Aux temps anciens et vénérables (avant 2003), le noyau Linux utilisait un mécanisme nommé devfs qui était chargé d'énumérer, dans un système de fichiers spécial, tous les périphériques d'entrées/sorties présents sur la machine. Devfs était vu comme un progrès par rapport à un répertoire /dev statique, mais il n'était pas sans poser - lui aussi - des problèmes épineux. Outre sa grande complexité, avec devfs chaque périphérique avait un nom différent (non persistant) en fonction de son ordre de détection, la politique de nommage faisait partie du noyau, devfs ne respectait pas la norme LSB et enfin de nombreuses situations de compétition (race conditions) venaient fragiliser le système.

Pour sortir de ce guêpier, il a été décidé de ne plus utiliser devfs et de s'en remettre à un démon en espace utilisateur nommé udev développé notamment par Greg Kroah-Hartman. Avec lui, on peut répondre a toutes les déficiences de devfs puisque la lourde politique de nommage est sortie du noyau, que les noms sont persistants quel que soit l'ordre de détection, que la norme LSB est complètement respectée, que le démon, puisqu'il vit en espace utilisateur, peut être mis en swap, etc.

La situation avec udev était donc bien meilleure qu'avant… c'est pourquoi l'annonce d'une sorte de retour de devfs dans le noyau a surpris tant de monde et a provoqué tant de chaudes discussions sur les listes de diffusion !

Alors, comment fonctionne devtmpfs et quel est le raisonnement qui a poussé ses auteurs a écrire leur code ? Selon l'explication donnée par Kay Sievers, et comme on peut facilement le deviner en voyant son nom, devtmpfs s'appuie en fait sur un fichier temporaire tmpfs qui n'est utilisé que pour l'énumération des périphériques le plus tôt possible par le noyau, lors de l'amorçage. L'avantage est que pour les environnements embarqués et, tout en gardant le caractère dynamique de /dev, il n'y a pas de nécessité d'attendre le lancement d'un lourd démon en espace utilisateur. Comme en plus, udev peut reprendre la main à la suite de devtmpfs et profiter de son travail, les utilisateurs normaux vont profiter d'une amélioration du temps d'amorçage.

C'est d'ailleurs cette dernière qualité qui a été mise en avant par Greg Kroah-Hartman quand Andrew Morton, après avoir accueilli le patch initial d'un ironique "Lol, devfs", lui a demandé quelle était la justification de devtmpfs : « Boot speed, boot speed, boot speed. Oh, et aussi réduction de la complexité des scripts d'init et épargner aux systèmes embarqués le fait de devoir implémenter correctement un /dev dynamique ».

En dépit des objections de Christoph Hellwig et d'Eric Biederman le code de devtmpfs a été incorporé dans le nouveau noyau par Linus. Outre les contre-arguments présentés par Greg il est probable que Linus a été sensible au fait que les distributions semblaient intéressées par cette fonction (SuSE l'utilisant même depuis longtemps en tant que patch externe) et que le code était sans aucun impact sur le reste du noyau et tout petit (à peine 300 lignes de code).

Devtmpfs est donc loin d'être le retour du cauchemar qu'avait fini par représenter devfs pour les développeurs du noyau. C'est plutôt une nouvelle possibilité, propre et non intrusive, qui est offerte aux utilisateurs de Linux.

Kernel Shared Memory

La fonction KSM (pour Kernel Shared Memory) a été ajoutée au noyau 2.6.32 et va permettre de réduire la consommation mémoire des machines utilisant la virtualisation KVM.

L'idée de départ de ce travail est simple à comprendre. Sur une machine hôte qui héberge de nombreuses instances virtuelles KVM, il est fort probable – pour ne pas dire certain – que les instances invitées vont utiliser de nombreuses pages mémoires pour stocker des données identiques. Cette duplication des données est un gaspillage et les développeurs du noyau ont décidé de s'y attaquer.

La première idée a été de prendre une empreinte (hash) des pages mémoires et, au cas ou plusieurs pages se révèlent identiques, de les fusionner en mode copy-on-write afin qu'elles n'occupent plus qu'une fraction de l'espace précédent. Bien entendu dès qu'une instance virtuelle modifie une page alors une séparation automatique a lieu (d'ou l'utilité du copy-on-write).

Cette première approche posait deux problèmes. En premier lieu, si une collision de hash pouvait être générée par un attaquant alors l'hôte des machines virtuelle ne pourrait plus garantir leur séparation totale. Le second problème est que la société VMWare, en dépit du fait que cette technique existait auparavant en tant que patch externe au noyau 2.2.9, avait déposé un brevet sur la technique de comparaison par prise d'empreintes visant à fusionner les pages mémoires.

Plutôt que de se lancer dans une longue bataille juridique, propre à engraisser des bataillons d'avocats, les développeurs de KSM ont décidé de changer leur fusil d'épaule et de ne plus utiliser de prise d'empreintes. De cette façon, pas de risque de collision et pas de risque non plus d'avocats scandaleusement engraissés.

La nouvelle technique utilise deux arbres binaires de recherche, plus spécifiquement deux arbres bicolores, où sont stockées les informations qui vont permettre la fusion des pages. Le premier, l'arbre instable, est utilisé pour lister les pages susceptibles d'être fusionnées (on utilise la fonction memcmp pour comparer les données) et le second arbre, le stable, stocke les pages effectivement partagées entre les instances virtuelles.

Ce partage est complètement transparent pour les processus car c'est un partage dynamique qui scanne périodiquement les pages mémoire afin de reconstruite l'arbre instable. L'arbre stable de son côté est… hem… stable et il n'est donc pas reconstruit régulièrement. Le noyau se contente de le mettre à jour quand une séparation de page est nécessaire.

Si on veut profiter du Kernel Shared Memory en dehors du cas d'une virtualisation, par exemple parce que de nombreux processus partagent les mêmes données, il est possible à une application de faire un appel direct à KSM afin de lui demander d'activer sa fonction de fusion de pages.
En outre, précision importante pour les gens qui n'ont pas l'utilité de cette fonction, l'ajout de KSM n'a aucun impact sur les performances si le code n'est pas activé. Comme expliqué dans l'annonce du patch cette activation s'effectue avec un simple echo 1 > /sys/kernel/mm/ksm/run.

Les développeurs de KSM ont écrit un article de présentation détaillée, disponible au format pdf, pour le dernier sommet Linux. Dans cet article on apprend que le CERN utilise déjà KSM pour la grille de calcul qui a été mise en place afin d'analyser les données du LHC (Large Hadron Collider). Comme les jobs d'analyse et de reconstruction des collisions de protons partagent de nombreuses données, il est intéressant d'activer KSM afin d'économiser la mémoire.

Quand deux jobs de 2 Go sont lancés, il est possible de partager 750 Mo de données avec KSM (seulement 250 Mo sans KSM). Les ingénieurs du CERN signalent ainsi que sur une machine typique ayant 4 Go de RAM, on peut faire tourner 3 jobs au lieu de 2 en temps normal. Un gain significatif quand on connaît le déluge de données que va générer le LHC !

API des pilotes réseau

Enfin, dernière nouveauté détaillée ici, l'API des pilotes réseau a été modifiée afin de permettre d'unifier les codes retour. Ce changement n'est pas très important ni très intéressant en lui même et il n'a strictement aucune conséquence sur les performances… alors pourquoi en parler ?

En réalité ce commit de Stephen Hemminger est une belle illustration de la puissance du modèle du logiciel libre et c'est pour cette raison qu'il mérite qu'on s'y attarde.

La fonction ndo_start_xmit() est utilisée par la pile réseau du noyau pour passer un paquet au pilote de la carte réseau et il ne devrait y avoir que deux résultats possibles en retour. Soit un NETDEV_TX_OK pour dire que tout s'est bien passé et que le paquet a été accepté par le pilote, soit un NETDEV_TX_BUSY pour signifier au noyau que le pilote était occupé ailleurs et qu'il va falloir songer à renvoyer le paquet.

Le problème c'est que le type du code retour a été défini en int et donc que certains pilotes utilisent, vicieusement, cette possibilité pour renvoyer des codes erreurs barbares au noyau alors que celui-ci attend juste un OK ou un BUSY.

La solution, dans le monde du logiciel libre, est très simple. On change le type int en type enum qui contient juste les codes retour attendus par le noyau. Ensuite on change tous les pilotes réseau présents dans le noyau afin de prendre en compte cette modification. Comme les pilotes sont libres et font directement partie du noyau un tel changement est certes fastidieux mais facile à faire.

Dans le monde propriétaire, où les pilotes ne sont bien souvent pas dans le système d'exploitation de base et doivent être téléchargés sur le site du constructeur de la carte réseau, un tel changement serait impossible ou bien exigerait d'immondes hacks au détriment de la simplicité et de l'élégance du code.

Pour Greg Kroah-Hartman, qui s'exprime dans un entretien publié sur le site "How Software is Built", c'est cette optimisation permanente des API qui explique la qualité du code Linux et la vitesse de son évolution :

« Notre pilote pour Linux représente seulement un tiers de la taille du pilote Windows donc, même avec un tel taux de changement, écrire un pilote pour Linux, c'est moins de travail que ça ne l'est pour les autres systèmes d'exploitation.
Dans Linux, nous avons réécrit la pile USB trois ou quatre fois. Windows a fait la même chose, mais ils doivent garder toutes les vieilles piles USB et aussi un paquet de vieux code, afin que les anciens pilotes puissent fonctionner. Donc leur charge de maintenance ne fait qu'augmenter avec le temps, alors que ce n'est pas le cas pour la nôtre ».

Encore une illustration de la salubrité de ce modèle de développement libre choisi par les développeurs Linux et une occasion de relire le fameux texte de Greg Kroah-Hartman sur l'inanité des API stables.

En bref (↑)



Le bilan en chiffres (↑)

Côté statistiques, l'habituel article récapitulatif 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.32 le nombre de patchs était de 10 944 au 2 décembre (10 814 pour le 2.6.31). C'est donc un cycle tout à fait typique qui a eu lieu ces trois dernier mois.
Il faut tout de même se forcer à garder à l'esprit que le rythme de changement de Linux est incroyablement rapide et sans commune mesure avec ses concurrents quels qu'ils soient. En effet un rapide calcul prenant en compte le nombre de jours nous séparant de la sortie de la version précédente (83 jours) et le nombre de lignes modifiées dans le noyau 2.6.32 (1 785 732) aboutit au chiffre ahurissant de 15 changements de lignes de code noyau par minute et ce 24h sur 24 et 7 jours sur 7.

Le nombre de développeurs ayant contribué au nouveau noyau s'établit à 1 240 (en augmentation par rapport aux 1 151 du noyau 2.6.31) et on voit sur le graphique du bas que sur le long terme la croissance reste soutenue. Une nouveauté intéressante disponible sur la page des contributeurs est l'indication de leur nationalité (la colonne de droite). Selon ce classement le premier contributeur français est Éric Dumazet...mais on peut s'interroger sur la fiabilité de cette classification quand on voit que Paul Mundt, un canadien vivant au japon, est considéré comme japonais.

Une petite polémique a débuté entre les lecteurs de l'article Linux Weekly News à propos du classement par entreprise. Si le haut du classement reste stable, avec juste un petit recul relatif de Red Hat, on peut constater que Microsoft fait son entrée dans la liste des contributeurs du noyau. C'est bien entendu l'inclusion des quelques 20 000 lignes du pilote Hyper-V dans la branche -staging qui fait ainsi entrer Microsoft en dix-septième position de la liste. Cette entrée est utilisée par certains commentateurs pour se moquer de la faible contribution de Canonical au noyau (trentième position en nombre de lignes). D'autres intervenants soulignent le fait que Canonical contribue plus dans les couches hautes de l'écosystème du libre (dans Gnome par exemple) et qu'il vaut mieux une seule ligne de code noyau utile plutôt que 20 000 lignes pour faire tourner des instances Linux sur un système d'exploitation propriétaire.

En tout cas, le contrôle du noyau est toujours fermement entre les mains des mêmes personnes puisque la répartition des tags "signoffs" (les tags qui autorisent ou pas l'entrée du code dans la branche principale) reste la même. Les cinq principales entreprises qui emploient les auteurs des tags "signoffs" restent Red Hat, Novell, Intel, Google et IBM. Si on compte ces autorisations d'intégration de patchs, on constate que ces cinq firmes majeures représentent environ 72% des autorisations (68,5% dans le noyau 2.6.31).

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.

fsnotify

L'infrastructure de notification fsnotify, qui avait fait son apparition dans le noyau 2.6.31, a toujours été conçue par son développeur comme devant déboucher sur un module de scan de fichiers nommé fanotify. En dépit des patchs d'Eric Paris il ne lui a pas été possible d'intégrer fanotify dans le noyau 2.6.32, mais on peut parier qu'il tentera à nouveau sa chance lors de l'ouverture de la prochaine fenêtre de merge. Il est cependant à noter que fanotify ne déchaîne pas l'enthousiasme des foules en délire. Beaucoup de développeurs considèrent que que le scan de fichiers, utilisé comme technique de sécurité, est fondamentalement une mauvaise solution. La guerilla est donc rude sur ce sujet et comme en plus il existe d'autres critiques techniques, il va falloir qu'Eric se montre très convaincant s'il veut que son bébé intègre le noyau.

AppArmor

AppArmor, le module de sécurité basé sur le chemin que l'on croyait mort et enterré depuis le licenciement de ses développeurs par Novell, a refait une apparition sur la LKML. L'arrivée de TOMOYO dans le noyau 2.6.30 a démontré qu'il était possible à un module de sécurité basé sur le chemin (pathname-based) d'entrer dans la branche principale et que la vie ne se restreignait pas à SELinux et Smack. AppArmor est réputé plus simple à utiliser que les modules basés sur des labels et cela explique peut-être son intégration dans la distribution Ubuntu. Canonical a donc intérêt à ce qu'AppArmor intègre officiellement Linux car cela fera un patch externe de moins à maintenir (et cela redorera son blason de contributeur au noyau). C'est donc John Johansen, employé par Canonical, qui a proposé une série de 12 patchs sur la LKML afin de tâter le terrain et de voir quelles sont les perspectives à ce sujet. Pour l'instant les réactions sont peu nombreuses mais nul doute qu'une fois de plus le combat pour l'intégration va être rude.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Ca y est...

Posté par Zenitram (page perso, ) le 03/12/2009 à 11:17. (lien). Évalué à 1.

...Je vais encore perdre une heure de lecture!

sympa !

Posté par djiock () le 03/12/2009 à 11:44. (lien). Évalué à 5.

Chouette article, très détaillé et à la portée du profane, merci !

BCM4312

Posté par mensoif_gerard () le 03/12/2009 à 11:45. (lien). Évalué à 4.

Jai lu ceci sur le site linuxwireless.org :
BCM4312 802.11b/g, AKA BCM 4310 USB - This device has an LP PHY. Work on this device has begun, and the device now works in wireless-testing (and will be supported in 2.6.32)

Mais je n'ai pas vu de mention du driver b43. Qqn a-t-il plus d'infos?

Merci

Géolocation ??

Posté par Ner0lph (Jabber id, ) le 03/12/2009 à 12:15. (lien). Évalué à 4.

@patrick_g : Tu parles de « Géolocation », ne voulais-tu pas dire « [[Géolocalisation]] » ?



(Lien qui fonctionne : [http://fr.wikipedia.org/wiki/G%C3%A9olocalisation])

Apparmor chez ubuntu ?

Posté par Misc (page perso, ) le 03/12/2009 à 12:25. (lien). Évalué à 5.

j'aurais plus tendance à dire que Ubuntu a chois apparmor car ils ont débauché Andreas Hasenack de Mandriva. Andreas avait déja décidé de pousser apparmor à l'epoque ( ie y a 3 ans ), donc ça ne m'étonne qu'à moitié que ça soit pareil chez son nouvel employeur.

Si Canonical avait voulu reprendre AppArmor, ils auraient pu embaucher l'equipe de novell, directement, non ?

Fils ou pere?

Posté par reno () le 03/12/2009 à 12:51. (lien). Évalué à 0.

D'abord merci pour cette article vraiment très détaillé, je vais me regaler.

Ensuite cette histoire de paramétrage globale sur qui tourne en premier m'agace: je pense qu'elle est un signe comme quoi l'API pour créer des processus est défaillante: cela devrait être lors de la création d'un processus que l'on indique si on préférerai passer la main immédiatement au fils ou bien si on préférerai que le père garde la main..

linuxubuntufr.org

Posté par kowalsky () le 03/12/2009 à 13:02. (lien). Évalué à 9.

Ce noyau 2.6.32 est particulièrement important car il sera intégrée dans la prochaine version Ubuntu avec support à long terme (Ubuntu 10.04 LTS)

Il faudrait le dire pour toutes les distributions non ?

[+] merci

Posté par brokensoul () le 03/12/2009 à 13:38. (lien). Évalué à -2.

Merci beaucoup pour l'article, super intéressant !

KMS sur un R700

Posté par Sphax () le 03/12/2009 à 14:00. (lien). Évalué à 6.

Ca fait environ deux semaines que j'utilise un 2.6.32-rc8, avec KMS d'activé, et ça marche très bien. Les switch entre les tty et le serveur X sont très rapides.
En plus, avec les versions git de mesa et du driver xf86-video-ati, la 3d fonctionne bien.
Bon, c'est encore super lent pour les grosses applis 3d (2-3 fps dans Celestia ou Warsow),

Sinon, dépêche très intéressante, merci !

[+] Bordel Patrick_g ...

Posté par jujubickoille (page perso, ) le 03/12/2009 à 14:15. (lien). Évalué à -1.

Je croule sous le taff, mais, je n'ai pas pu m'empêcher de te lire : comme toujours, une sucrerie qu'on se délectes de lire :)


bon, maintenant au boulot !

--
Gentoo un jour, Gentoo toujours !

Boom !

Posté par Hrundi V. Bakshi () le 03/12/2009 à 15:01. (lien). Évalué à 4.

Est-ce qu'il y a quelque part des graphiques qui montre si oui ou non les pays dits émergents font une grosse montée en puissance dans le noyal et les couches supérieures ?

L'inde / la Chine / Brésil et plein de pays asiatiques doivent quand même bourriner pas mal en terme de capacité informatique. Ces dernières années, ils doivent produire du hacker vachement plus rapidement que "l'occident".

Cependant, en terme d'organisation, je comprends que pour des raison historiques les EU et l'Europe trustent le top de contributions.
Et pour des raisons certainement de culture/langue, je conçois que toute une partie du monde reste invisible aux yeux d'un monde anglophonocentré.

La question qui me vient est : Qu'est ce qui se passe donc dans ces pays, est ce que y a une masse qui va envoyer du lourd dans les années qui viennent ?
Est-ce qu'il y a des gugusses qui ce sont amusés à faire de la prospective sur le rythme de dev que GNU va atteindre dans les prochaines années (Gartner est un peu trop centré sur Microsoft :D ) ?

Tests automatiques ?

Posté par Mat (page perso, ) le 03/12/2009 à 15:12. (lien). Évalué à 4.

Le noyau est un projet qui me sidère par sa taille et son nombre de développeurs.
Je ne me suis pas vraiment penché sur la question, mais je suppose qu'il y a un certains nombre de règles pour pouvoir participer.

Du coup je me pose les questions suivantes :
* comment peut-on commit dans ce repo ?
* y'a t-il des tests unitaires ou à défaut des tests plus larges de non régression ?
* y'a t-il des relectures de code, si oui sur tous les commits ? qui relit ?

En gros quel est le travail de QA effectué sur le noyau ?

[+] vidéo Youtube sur le Kernel.

Posté par Eno () le 03/12/2009 à 15:27. (lien). Évalué à -6.

Il y a une vidéo sur Youtube très intéressante à ce sujet ( dev du Kernel ) Il faudrait que je l'a retrouve.

Correction

Posté par Christophe Garault (page perso, ) le 03/12/2009 à 15:27. (lien). Évalué à 2.

Merci Patrick pour ce superbe boulot comme à l'habitude. Une coquille s'est néanmoins glissée sur l'url du travail de Jens Axboe, c'est http://oss.oracle.com/~axboe/lpc2009.pdf

Coquilles

Posté par Xavier Claude () le 03/12/2009 à 15:39. (lien). Évalué à 1.

Bravo pour la dépêche.

J'ai relevé deux coquilles:

pas permis de bloquer sur l'un deux (d'eux)

Devs (Devfs)

--
Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. (R. Devos)

Dénomination des versions RC !!??

Posté par Julien04 (page perso, ) le 03/12/2009 à 16:45. (lien). Évalué à 6.

J'imagine que c'est un sujet qui a déjà été débattu, mais je ne trouve rien dessus, donc je pose la question :

Pourquoi les RC sont ainsi nommées ?

J'imagine que vous connaissez déjà le schéma classique, maios pour la forme :
- alpha : pas encore fini, c'est bagdad, on travail
- beta : tout est la, mais on sait très bien qu'il y a plein de bug
- RC (release candidate) : a priori c'est bon, si on ne trouve rien, c'est la finale !

Quand Microsoft annonce qu'un produit (Office ou Windows pour les plus médiatisés) va avoir 2 beta et 2 RC (par exemple), ça choque d'entendre qu'on déclare une planning de version RC d'avance (!), en sous-entendant donc quelle que soit sa qualité se sera une RC, donc en fait c'est une beta (voir une alpha si tout n'est pas implémenté!!)...

Mais c'est pareil pour le kernel linux.
Quelle est cet étrange habitude de tout nommer RC? Alors que tout n'est même pas encore intégré !
Est-ce pour avoir une plus grande "couverture médiatique" pour obtenir plus de tests grandeur nature ?

Merci d'avance pour l'éclairage,
Julien

ah ! merci

Posté par OAUDRY () le 03/12/2009 à 17:18. (lien). Évalué à 6.

dire que j'ai grave de taf en ce moment. Mais c'est toujours un vrai plaisir. Ce que j'aime particulièrement ce sont les nouveautés et la beauté (à mon sens) des solutions trouvées.

Mon regret c'est de ne pas avoir en face de chacune des nouveautés l'existence ou non chez la concurrence (nt aix hp solaris etc) de la dites nouveauté. C'est bien dommage qu'on ne puisse pas avoir ces informations ça nous (me) permettrais de savoir un peu ou en est Linux (on dit Linux la hein ?) par rapport aux autre. Bref j'ai tendance à penser que Linux est technologiquement bien en avance sur les autres mais j'en ai pas la preuve.

Et le lexique ?

Posté par \_o< QUACKKKKKKKKKKK !!!!! (Jabber id, page perso, ) le 03/12/2009 à 18:18. (lien). Évalué à 8.

Mais que font les modérateurs ?
Accepter une telle news sans un lexique c'est inadmissible ! C'est un appel d'air à des news mal rédigées et incomplètes.

Bonne dépêche

Posté par mathieui (Jabber id, page perso, ) le 03/12/2009 à 19:47. (lien). Évalué à 1.

Génial, comme d'habitude :).

CC BY-SA

Posté par Barret Michel (Jabber id, page perso, ) le 03/12/2009 à 20:52. (lien). Évalué à 3.

C'est cool que la dépêche soit libre. Sous quel licences sont elles habituellement ?

--
Debian Squeeze

Bonne petite lecture

Posté par Dup (page perso, ) le 03/12/2009 à 21:44. (lien). Évalué à 0.

Ça fait toujours plaisir de lire un article sur le nouveau noyau linux en français.

Il me reste à parcourir les liens maintenant, je garde ça pour une seconde lecture.

Merci.

It's not about speed, as stated many many times. Please read the archive

Posté par ptifeth (page perso, ) le 03/12/2009 à 22:31. (lien). Évalué à 5.

devfs, finalement, si j'ai bien lu les archives,

* permet d'avoir sous la main les fichiers spéciaux attendus par tout programme UNIX, ie /dev/null, /dev/zero, /dev/tty, avec les permissions correctement placées (suite à interventions sur la ML) sans udev
* et aussi d'avoir facilement des fichiers spéciaux complètement personnalisés et pas du tout dans la hierarchie UNIX comme les adorent les devs de l'embarqué, toujours sans udev.


(udev, lancé ensuite, continuera de faire notre bonheur)

Les grosses copies de fichiers sous Linux

Posté par sanao () le 03/12/2009 à 23:40. (lien). Évalué à 7.

Si j'ai bien compris, la modification de Jens Axboe sur l'ordonnanceur des entrées/sorties CFQ va rendre le système plus réactif. Est-ce que cela s'applique également aux grosses copies de fichiers?

Car actuellement, quelque soit la distribution ou version du noyau que j'utilise (Debian, Kubuntu, Arch, Mandriva et RedHat), Linux se met à ramer comme un veau dès que je fait une grosse copie de fichiers (de quelques Go par exemple).

Je n'ai jamais pris la peine de me pencher sur le sujet, mais c'est un peu embêtant à l'utilisation...

LinUS

Posté par Amine "nh2" Brikci-Nigassa (page perso, ) le 04/12/2009 à 00:20. (lien). Évalué à 3.

No.61 Linus Torvalds <torvalds () linux-foundation ! org> 40(0.37%) @Linux Foundation @American

Le scoop ! Linus s'est naturalisé américain !

on peut s'interroger sur la fiabilité de cette classification quand on voit que Paul Mundt, un canadien vivant au japon, est considéré comme japonais.
...ah non...

quoique... http://www.linux.com/archive/articles/31149

--
http://LibreTlemcen.org

Époustouflant !

Posté par Pierre Jarillon (page perso, ) le 04/12/2009 à 01:05. (lien). Évalué à 1.

Patrick_g nous permet d'apprécier le travail gigantesque que représente le kernel. Sans ses articles dont la réputation n'est plus à faire, je n'aurais connu que quelques bribes de l'activité au niveau du noyau. Tous les superlatifs sont permis pour décrire ce chef d'œuvre.

Après la lecture de l'article de Patrick, il me tarde de pouvoir utiliser ce nouveau noyau et tous ses raffinements. En même temps je me demande si il est encore possible de faire mieux et de trouver d'autres améliorations. Les courbes tendent à prouver que oui, mais jusqu'à quand ? Est-ce qu'il existe une limite ?

[+] Merci

Posté par MARY Julien (page perso, ) le 04/12/2009 à 02:58. (lien). Évalué à -1.

Encore un article extrêmement bien documenté qui fait gagner un temps énorme et avec lequel on sent plus intelligent après qu'avant.

[+] Rebond sur l'API des pilotes réseaux

Posté par MARY Julien (page perso, ) le 04/12/2009 à 03:19. (lien). Évalué à -1.

C'est exactement ce genre d'argument qui me fait dire que tôt au tard Windows sera une distribution Linux ou BSD à l'instar de OSX.

Économiquement cela se justifie, techniquement certainement aussi.

Quelques questions

Posté par Dreamkey () le 04/12/2009 à 14:25. (lien). Évalué à 2.

Bonjour,
merci pour cet article très intéressant, il explique bien en détail des choses que je n'aurais jamais pu comprendre en lisant le changelog. J'ai toutefois deux questions à ce propos :
- comment se fait-il que Microsoft ai participé au développement de ce noyau ? J'ai bien compris que c'est pour faire tourner Linux dans leur machine virtuelle (et donc ne pas se faire reprocher de ne pas gérer la compatibilité avec Linux), mais est-ce que ça n'alourdit pas le noyau de quelque chose qu'une grande partie des utilisateurs n'aura pas l'utilité ?
- la partie sur l'harmonisation de l'API des pilotes réseau montre bien que l'open-source est une solution viable, mais je ne comprends pas comment sont fait les drivers. Pour qu'une installation de Linux soit aussi légère, cela veut dire qu'il utilise des drivers générique, contrairement aux Windows (car c'est la seule hypothèse que j'ai pour comprendre qu'ils prennent autant de place) ?! Je ne dis pas que les drivers propriétaires sont forcément mieux, mais dans le sens où c'est la même société qui construit le matériel et qui met à disposition le driver, ce dernier devrait logiquement avoir plus de fonctionnalités qu'un driver générique, non ?
En tout cas merci d'éclairer ma lanterne :)

KMS pour radeon

Posté par riri le breton (page perso, ) le 04/12/2009 à 18:49. (lien). Évalué à 2.

La killer feature que j'attendais de manière officielle était le support des cartes AMD sur chipset R6xx en ce qui concerne KMS. J'ai testé rapidement sur une Fedora 12 qui a backporté l'implémentation sur un 2.6.31, et je dois dire que c'est un régal (si on a les bons mesa et xorg qui vont bien).

Voilà, juste pour dire que j'étais content, comme sûrement beaucoup de possesseurs de cartes graphiques AMD relativement récentes :-)

--
La liberté d'une personne s'arrête là où commence celle des autres.

[+] comme d'habitude

Posté par Julien BALLET () le 07/12/2009 à 14:04. (lien). Évalué à -1.

un tres bon article patrick, comme d'habitude.
merci !

Thumb2 : ARMv7 et Cortex

Posté par Aissen (page perso, ) le 07/12/2009 à 14:17. (lien). Évalué à 1.

ARMv7 est le jeu d’instruction qui englobe Thumb-2, les processeurs basé sur ce jeu d’instruction ARMv7 sont les Cortex M{0,1,3}, A{5,8,9}, R4. (cf http://www.arm.com/products/CPUs/ )

À noter que le processeur ARM1156 (ARMv6) supporte aussi l’extension Thumb-2.

Erreur d'interpretation sur l'API reseau

Posté par Littleboy () le 14/12/2009 à 17:48. (lien). Évalué à 1.

Le problème c'est que le type du code retour a été défini en int et donc que certains pilotes utilisent, vicieusement, cette possibilité pour renvoyer des codes erreurs barbares au noyau alors que celui-ci attend juste un OK ou un BUSY.

Puisque tu prends justement cet exemple pour montrer la superiorite du LL sur le logiciel proprio (et plus particulierement le fait d'avoir tous les pilotes dans le meme arbre source que le noyau), peut-etre que tu peux nous expliquer exactement ce que le fait d'avoir un enum va changer aux codes d'erreurs barbares...

As-tu lu le fil en question par ailleurs, parce que dans ce cas particulier: un tel changement serait impossible ou bien exigerait d'immondes hacks au détriment de la simplicité et de l'élégance du code est totalement a cote de la plaque! Lire l'article wikipedia (la version anglaise) que tu cites serait un bon debut. C'est dispo la: http://en.wikipedia.org/wiki/Enumerated_type#C_and_syntactic(...)

Par ailleurs le reste de l'article est tres interessant, mais il y a pourtant assez d'autres exemples de changement d'API qui pourrait montrer la superiorite du modele Linux pour ne pas prendre cet exemple la.

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.4102s (dont 0.0504 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !