Nouvelle version 2.6.32 du noyau Linux

Posté par patrick_g (site web personnel) le 03 décembre 2009 à 12:01. Édité par Benoît Sibaud. Modéré par patrick_g.

Étiquettes :

déc.

2009

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).

Le sommaire...

La phase de test
- RC-1
- RC-3
- RC-4
- RC-5
- RC-6
- RC-7
- RC-8
Les nouveautés
En bref
Le bilan en chiffres
Pour la suite

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 système de fichiers Btrfs, qui représente le futur du monde Linux, continue d'être amélioré dans cette nouvelle version du noyau. Par exemple la fiabilité des réservations d'espace est meilleure, la rapidité des suppressions d'instantanés (snapshots) est radicalement améliorée (la suppression se fait maintenant en parcourant le btree au lieu d'utiliser un bête rm -rf). On note aussi que la vitesse d'écriture, qui était bloquée à 400 Mo/s jusque là, peut maintenant dépasser le Go par seconde (il vous faudra toutefois une belle collection de disques pour atteindre un tel chiffre ;-)

Le système de fichiers virtuel sysfs, utilisé pour présenter des informations sur les périphériques aux applications vivant en espace utilisateur, prend maintenant en charge les labels de sécurité. Comme ces labels sont le coeur des modules de sécurité SELinux et SMACK il est donc possible de se servir de ces modules pour implémenter des restrictions fines sur le contenu de ce systèmes de fichiers virtuel.

La pile Wi-Fi mac80211 du noyau Linux 2.6.32 est désormais capable de faire du balayage (scanning) en tâche de fond. Le patch, qui est également évoqué par Dan Williams dans son blog, permet au noyau de faire un balayage de tous les point d'accès (AP) sur environ 30 secondes en revenant à chaque instant (selon le résultat de SCAN_DECISION) sur l'AP connecté afin de ne pas impacter le trafic actuel. Cette nouvelle fonction, qui génère donc une liste actualisée des points d'accès potentiels, est utile aux services de géolocalisation mais elle va surtout permettre d'améliorer l'itinérance (roaming). Grâce au balayage en tâche de fond on peut plus facilement basculer sur un nouveau réseau, ou sur un nouvel AP au sein du même réseau, car la liste est toujours mise à jour.

Afin de faciliter la compilation du noyau Linux il est maintenant possible de faire un "make localmodconfig" et le nouveau noyau compilé reprendra les modules qui sont actuellement chargés dans le noyau local. Si on préfère tout construire en dur il suffit d'utiliser "make localyesconfig" et les modules du noyau actuel seront compilés dans le nouveau noyau.
Il devient plus facile que jamais d'essayer un noyau amont afin de rapporter les bugs sur la liste de diffusion !

Jens Axboe a modifié l'API des périphériques en mode bloc. Maintenant, comme pour la pile réseau, il est possible de travailler sans s'appuyer sur des interruptions mais en utilisant uniquement le polling (qui consiste a vérifier en permanence l'état du périphérique). Le polling, pour qu'il soit une stratégie efficace, nécessite que du travail soit en permanence à faire dans la pile des entrées/sorties. Si c'est le cas, comme pour les lecteurs SSD qui sont capables de générer des dizaines de milliers d'IOPS, alors se passer des interruptions et utiliser le polling est une stratégie gagnante. La fonction s'active quand le périphérique fait un appel à blk_iopoll_enable et Jens rapporte les résultats d'un benchmark ou le nombre d'interruptions passe de 76000/s à seulement 55000/s.

La couche AHCI, qui permet de communiquer avec le contrôleur de bus SATA, peut maintenant exporter vers les applications différentes informations sur les capacités des périphériques. Le commentaire du patch mentionne ainsi le fait qu'il devient possible de signaler facilement, par l'intérmédiare de sysfs, qu'un port est utilisable à chaud ou pas, qu'il est utilisable pour les périphériques eSATA ou encore qu'il est conforme à la norme d'économie d'énergie ALPM (Aggressive Link Power Management).

L'ordonnanceur des entrées/sorties CFQ a été quelque peu modifié afin d'améliorer l'interactivité des processus. Comme l'explique Jens Axboe dans son commentaire sur le site LWN ce changement est effectué, un peu contre-intuitivement, en empilant "moins agressivement" les écritures asynchrones. De cette façon les applications sont moins affectées par les écritures qui se déroulent en arrière plan et leur réactivité s'en trouve améliorée.

Une nouvelle option de configuration du noyau, nommée MULTICORE_RAID456, permet de distribuer la gestion des disques RAID entre différents processeurs. Par exemple en mode RAID 5, où les volumes sont agrégés par bandes (stripe), il est maintenant possible d'affecter une bande par processeur de façon à répartir la charge. Comme l'indique le commit ce code est encore considéré comme expérimental.

Le travail d'optimisation du systèmes de fichiers ext4 se poursuit dans le noyau 2.6.32. Ted Ts'o a introduit la possibilité de faire des opérations de writeback de plus de 4 Mo. Cette limitation venait du fait qu'ext4 avait une limite de writeback à 1024 pages de 4 Ko. L'exemple d'XFS, qui peut faire des writeback par morceau de 16 Mo, a montré que cette limitation à 4 Mo était néfaste. Après plusieurs tests et benchmarks Ted a introduit une nouvelle option dans le système de fichiers afin de choisir la taille du writeback. L'option est nommée max_writeback_mb_bump et elle est paramétrée par défaut sur 128 Mo.

La fonction fcntl() qui sert à manipuler un descripteur de fichiers a été étendue par deux nouvelles options. Alors que F_GETOWN et F_SETOWN servaient respectivement à obtenir ou a forcer l'identifiant d'un processus recevant des entrées/sorties, le noyau 2.6.32 propose maintenant des options supplémentaires F_GETOWN_EX et F_SETOWN_EX. Avec ces opérations on peut maintenant obtenir ou forcer les entrées/sorties dans un thread particulier au sein d'un processus multithread. Bien entendu ces options sont également présentes dans la GNU libc maintenue par Ulrich Drepper.

Toujours dans les options nouvelles offertes aux développeurs pour créer des applications optimisées, on relève des changements dans les fonctions d'horloge et de temps du noyau Linux 2.6.32. En plus des horloges classiques CLOCK_REALTIME (qui est configurable) et CLOCK_MONOTONIC (qui n'est pas configurable) on a maintenant CLOCK_REALTIME_COARSE et CLOCK_MONOTONIC_COARSE. Comme "coarse" signifie "grossier" ou "peu précis" on se doute déjà de ce qu'apportent ces nouvelles horloges. Les applications qui ont besoin très rapidement d'une information de temps (au détriment de la précision) peuvent faire appel à ces horloges. On évite ainsi tout accès au matériel et même, en utilisant VDSO, tout appel système coûteux. Comme le dit John Stultz qui est l'auteur du patch: « Avec cette méthode les applications peuvent choisir au cas par cas le compromis approprié entre la précision et la vitesse ».

La développeuse allemande Stefani Seibold a soumis un patch qui complète et améliore la présentation des données incluses dans le système de fichiers virtuel procfs. Les changements sont listés dans le message de commit et, parmi eux, on relève qu'il est maintenant possible de voir la consommation mémoire de la pile d'exécution (stack usage) en allant lire la dernière ligne d'une commande "cat /proc/PID_du_processus/status".

Le tampon mémoire chargé d'empiler les écritures lors de l'examen poussé d'un noyau (tracing) a été entièrement réécrit. L'ancien ring-buffer était handicapé par des verrous qui faussaient en partie les statistiques sur les écritures se déroulant dans le noyau. Le nouveau tampon est complétement débarrassé des verrous (lockless ring-buffer) et le tracing du noyau est désormais bien plus fiable. Ce travail très complexe (prenez un double doliprane avant d'aller lire la documentation) a donné lieu à un dépot de brevet par Steven Rostedt qui travaille chez Red Hat. La politique de cette compagnie étant claire sur ce sujet on peut considérer que ce brevet est maintenant une arme de rétorsion en cas d'attaque sur les logiciels libres.

L'impressionnant outil graphique timechart, développé par Arjan van de Ven, a été incorporé au noyau. Cet outil se base sur perfcounters et, un peu comme bootchart, permet de générer des fichiers SVG pour mieux visualiser des situations complexes se déroulant sur la machine. Avec timechart, il est possible de zoomer à l'infini dans le SVG pour augmenter le niveau de détail et comprendre l'origine des latences dans de nombreuses situations.

Le mode KMS (Kernel Mode Setting) qui était entré dans le noyau 2.6.31 pour les modèles anciens est maintenant compatible avec les cartes Radeon de type R600 et R700 (c'est essentiellement le même type de carte avec juste des petites améliorations pour les R700). Attention cette prise en charge est assez préliminaire et il faudra sans doute attendre les noyaux suivants pour que les choses se stabilisent vraiment.

Les machines dotées de plusieurs cartes en interface VGA peuvent maintenant coopérer avec de multiples serveur X afin d'offrir un environnement multi-sièges de meilleure qualité. Cela s'effectue par l'intermédiaire d'un arbitre VGA (VGA Arbiter) qui s'occupe de router les informations vers chacun des serveurs X. Cette fonction, importante par exemple pour les écoles ayant des machines anciennes, nécessite un serveur X au moins en version 1.7.

Toujours dans le domaine graphique le pilote Intel i915 permet maintenant de réduire dynamiquement la fréquence de la carte graphique quand la charge de travail est réduite. Si on ajoute à ça la compression automatique du framebuffer (qui selon Jesse Barnes fait gagner un demi watt sur la consommation de la carte), on a un belle avancée pour les ordinateurs portables à base de processeur graphique Intel.

La seconde version de l'API vidéo du noyau Linux, sobrement nommée Video4Linux2, gère maintenant grâce à ce commit, les normes de télévision numérique ISDB-T et ISDB-S. Ces normes sont utilisés notamment au Japon et en Amérique du sud (Brésil, Argentine, Chili, etc.) et leur intégration dans le noyau va permettre l'utilisation dans ces pays des cartes de réception TV ISDB.

La version 4.0 de la norme de gestion de l'énergie ACPI prévoit la possibilité de mettre au repos forcé un processeur en cas d'urgence (surchauffe en dépit d'une réduction de la fréquence ou autre).
La norme (attention gros pdf !) intitule cette fonction "Processor Aggregator Device" et il faut reconnaitre que c'est une façon bien plus intelligente de faire face à un évènement inattendu que d'obliger le serveur à s'éteindre. Attention il ne s'agit pas de retirer complètement de la circulation le processeur par un appel à la fonction hotplug. Ici on veut pouvoir reprendre le travail qui était en cours avant la surchauffe et il faut donc simplement que le processeur cesse de travailler (se mette dans l'état idle).
Le développeur Len Brown à commencé par proposer une modification de l'ordonnanceur CFS pour implémenter cette fonction mais il a été renvoyé dans ses buts car c'est un changement trop complexe à insérer dans CFS pour une fonction qui sera peu utilisée. La solution adoptée est de créer un pilote ACPI spécialement dédié à cette fonction. Ce pilote va, en cas de surchauffe, générer un processus léger temps-réel (priorité maximum et ordonnancement SCHED_RR (NdM: remplacement par un lien archive.org)) qui va passer devant tous les autres pour prendre la main sur le processeur afin de le mettre au repos. Une fois l'alerte thermique passée le processus léger s'éclipse et le processeur se remet à travailler comme avant. Cette solution du pilote ACPI dédié a fait lever quelques sourcils mais Linus a apprécié le pragmatisme de l'approche : "Pourquoi diable devrions-nous ajouter une logique complexe comme ça dans l'ordonnanceur ? Tel qu'il est le pilote est indépendant et il n'affecte aucun autre sous-système".

La puce Qualcomm MSM/QSD du smartphone Android HTC Dream (ou HTC G1) est maintenant prise en charge par le noyau Linux officiel. Divers autres pilotes destiné au HTC Dream, par exemple pour l'appareil photo ou la puce DSP ou encore l'écran tactile, entrent également dans le noyau 2.6.32. Ce code est intégré par des développeurs employés par Google et c'est une bonne chose de voir que la coopération avec la branche principale s'améliore… cependant, on note que ces derniers pilotes font seulement partie de la branche -staging et qu'il reste donc du travail pour les amener aux standards de qualité du reste du code.

Après l'arrivée dans le noyau 2.6.29 de la technique du Read-Copy update hiérarchique (Tree RCU) il a été décidé que l'ancien code (RCU classique et RCU preempt) n'avait plus de justification réelle et pouvait être retiré du noyau. Le même sort funeste a été réservé au code des "kernel markers" qui n'est plus utilisé depuis que tracepoints est utilisé à la place.
Et hop, quelques milliers de lignes en moins, c'est important aussi de faire le ménage !

Vous serez sans doute heureux d'apprendre que votre mainframe IBM S390 a maintenant la possibilité d'envoyer un dernier cri d'agonie en cas de crash du noyau. En effet, ces machines ont une spécificité matérielle qui leur permet de signaler un kernel panic en envoyant une notification (et une trace complète du crash) au service client IBM avec lequel vous avez un contrat. Cette fonction, astucieusement nommée "Call home", est activable sous Linux par l'option de configuration CONFIG_SCLP_ASYNC.

Dans l'océan de modifications concernant l'architecture ARM on peut noter que le jeu d'instruction Thumb-2, une mise à jour du jeu d'instruction dense Thumb, est maintenant complètement pris en charge par le noyau 2.6.32. The Thumb-2 est notamment utilisé dans tous les processeurs ARM modernes comme le ARMv7 ou le Cortex-M3. Contrairement à Thumb qui se limite à des instructions sur 16 bits pour économiser au maximum la mémoire, le Thumb-2 permet aussi d'utiliser des instruction 32 bits. Selon ARM on obtient ainsi le meilleur des deux mondes en conciliant les performances et la densité du code.

En ce qui concerne les architectures SPARC, la grande nouveauté du noyau 2.6.32 est la prise en charge complète des processeurs LEON. Ces processeurs sont à la norme SPARC V8 mais il sont très particuliers, car ce sont des processeurs sous licence libre (plus exactement leur description en VHDL est sous une licence libre, la GPL pour le LEON3). Ces processeurs LEON ont été conçus par l'Agence Spatiale Européenne afin de pouvoir embarquer sur les satellites et les sondes de l'ESA. Une version LEON3-FT (Fault Tolerant) est ainsi disponible et si votre sonde doit s'aventurer dans un environnement à haute radiation comme autour d'Europe, la très fascinante lune de Jupiter, alors vous pouvez compter sur le LEON3FT-RTAX pour survivre jusqu'à 3000 Gray.
Linux: To infinity and beyond !

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.

Aller plus loin

Les nouveautés du noyau 2.6.32 (kernelnewbies) (327 clics)
Le bilan des ajouts partie 1 (25 clics)
Le bilan des ajouts partie 2 (5 clics)
Le bilan des ajouts partie 3 (5 clics)
Les articles de H-Online (6 clics)

# Ca y est...

Posté par Zenitram (site web personnel) le 03 décembre 2009 à 12:17. Évalué à 1.

...Je vais encore perdre une heure de lecture!
- [^] # Re: Ca y est...
  
  Posté par ChickenKiller le 03 décembre 2009 à 12:33. Évalué à 9.
  
  Personnellement je ne considère pas ça comme une perte de temps ...
  - [^] # Re: Ca y est...
    
    Posté par armanoid le 03 décembre 2009 à 13:29. Évalué à 8.
    
    Plutôt une perte de stupidité.
  - [^] # Re: Ca y est...
    
    Posté par FantastIX le 03 décembre 2009 à 14:57. Évalué à 7.
    
    Et moi non plus! Je viens d'ailleurs de constater que j'ai passé près de quatre heures sur cette page à farfouiner un peu partout dans les liens... et je ne le regrette pas!
    
    Merci encore une fois à Patrick G pour ses excellentes dépêches en direct du noyau.
  - [^] # Re: Ca y est...
    
    Posté par KiKouN le 03 décembre 2009 à 15:23. Évalué à 3.
    
    La perte de temps est inéluctable à moins de s'être cassé la gueule dans le WC.
    
    Reste à savoir si cette perte de temps nous en fera gagner plus tard.
- [^] # Re: Ca y est...
  
  Posté par cosmocat le 03 décembre 2009 à 13:30. Évalué à 10.
  
  c'est quoi ce gros "Preum's" déguisé...
  
  On lit la dépêche et après on commente! :)
# sympa !

Posté par djiock le 03 décembre 2009 à 12:44. Évalué à 5.

Chouette article, très détaillé et à la portée du profane, merci !
- [^] # Re: sympa !
  
  Posté par esdeem le 03 décembre 2009 à 15:52. Évalué à 5.
  
  Je confirme, c'est extra !
  
  Je n'ai aucune compétence en dev du noyau et pourtant, je viens de passer ¾ d'heure à lire la dépêche, comme un roman.
  
  Merci à patrick_g pour ses longs posts détaillés et suffisamment vulgarisés pour que le plus grand nombre y trouve son compte.
  0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
# BCM4312

Posté par mensoif_gerard le 03 décembre 2009 à 12:45. É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
- [^] # Re: BCM4312
  
  Posté par patrick_g (site web personnel) le 03 décembre 2009 à 12:48. Évalué à 6.
  
  Va voir le premier lien de la dépêche : http://kernelnewbies.org/Linux_2_6_32
  
  Ensuite paragraphe "13.3. Networking devices" et tu verra qu'il y a plusieurs commits sur le pilote b43.
  - [^] # Re: BCM4312
    
    Posté par mensoif_gerard le 03 décembre 2009 à 13:02. Évalué à 1.
    
    Ah merci, j'avais regardé les liens de LWN mais pas le premier.
  - [^] # Re: BCM4312
    
    Posté par zebra3 le 03 décembre 2009 à 13:10. Évalué à 3.
    
    Cool, la carte WiFi est le seul périphérique pour lequel j'ai besoin d'un pilote non-libre sur mon Lenovo. A plus qu'à attendre le 2.6.32 dans les dépôts Debian (sachant que la RC-8 est déjà dispo dans expérimental).
    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
- [^] # Re: BCM4312
  
  Posté par Grunt le 04 décembre 2009 à 01:57. Évalué à 3.
  
  Arf, cette saleté de carte Broadcom.. j'ai la même :/
  Au passage, y'a un firmware libre en cours de développement:
  http://www.ing.unibs.it/openfwwf/
  THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# Géolocation ??

Posté par floriang le 03 décembre 2009 à 13:15. É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])
- [^] # Re: Géolocation ??
  
  Posté par patrick_g (site web personnel) le 03 décembre 2009 à 13:19. Évalué à 4.
  
  Effectivement j'avais mis un terme anglais. C'est corrigé.
# Apparmor chez ubuntu ?

Posté par Misc (site web personnel) le 03 décembre 2009 à 13:25. É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 ?
- [^] # Re: Apparmor chez ubuntu ?
  
  Posté par collinm (site web personnel) le 03 décembre 2009 à 14:18. Évalué à 0.
  
  "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."
  
  ça donne l'impression que Canonical pousse que ça soit inclue dans le noyau et que le travail se fasse par autruie... ainsi une personne de plus peut rejoindre le département de marketing...
  www.solutions-norenda.com
  - [^] # Re: Apparmor chez ubuntu ?
    
    Posté par Julien Gilbert le 03 décembre 2009 à 14:47. Évalué à 6.
    
    Grouikk ??
    Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard
    - [^] # Re: Apparmor chez ubuntu ?
      
      Posté par Laurent Cligny (site web personnel) le 03 décembre 2009 à 15:28. Évalué à 3.
      
      "vous ne devez pas manger le bien qui est aux truies".
      
      cf. Astérix et obélix, la rose et le glaive.
  - [^] # Re: Apparmor chez ubuntu ?
    
    Posté par GeneralZod le 03 décembre 2009 à 15:14. Évalué à 3.
    
    > ça donne l'impression que Canonical pousse que ça soit inclue dans le noyau et que le travail se fasse par autruie
    
    Même si c'est la politique habituelle de la maison (1), sur ce coup-là, ils sont plutôt réglo. John Johansen a été embauché pour bosser spécifiquement sur AppArmor (et pas uniquement pour faire de l'intégration), et d'autres ingénieurs comme Steve Beattie (ancien d'Immunix), Kees Cook contribuent également. Le projet a d'ailleurs migré sur Launchpad.
    https://edge.launchpad.net/~apparmor-dev
    Reste que l'abandon d'AppArmor par Novell/Immunix a été un sacré coup dur au projet qui a peu évolué en deux ans. Je ne vois plus trop l'intérêt pour Canonical de perfuser AppArmor alors que SELinux est mature, activement maintenu, bien intégré et nettement plus robuste et complet.
    http://www.linux-magazine.com/w3/issue/69/AppArmor_vs_SELinu(...)
    
    (1) si vous voulez étriller Canonical, chercher du côté de X ou bien KVM, le décalage entre la propagande marketing et l'activité réelle est phénoménale. Mais ce n'est pas le sujet de la dépêche.
    - [^] # Re: Apparmor chez ubuntu ?
      
      Posté par Pierre Jarillon (site web personnel) le 04 décembre 2009 à 01:31. Évalué à -1.
      
      Dans la liste des contributeurs au noyau, j'ai trouvé Mandriva mais aucun Canonical ou Ubuntu.
      Vu le battage médiatique autour de Ubuntu, j'espérais en trouver une dizaine... Je comprends l'amertume des debianistes qui se plaignent du peu de contribution de Canonical.
      - [^] # Re: Apparmor chez ubuntu ?
        
        Posté par patrick_g (site web personnel) le 04 décembre 2009 à 08:26. Évalué à 8.
        
        >>> Dans la liste des contributeurs au noyau, j'ai trouvé Mandriva mais aucun Canonical ou Ubuntu.
        
        ???? Va voir ici : http://www.remword.com/kps_result/2_6_32_whole.html
        
        Moi je vois Canonical en quarantième position des firmes contributrices (en nombre de patchs) et Mandriva en quatre-vingt-douzième position.
        
        Si tu va voir ici (classement en nombre de lignes cette fois-ci) : http://www.remword.com/kps_result/2_6_32_whole_line.html
        
        On a Canonical en trentième position et Mandriva en quatre-vingt neuvième position.
        
        [^] # Re: Apparmor chez ubuntu ?
        
        Posté par dyno partouzeur de drouate le 04 décembre 2009 à 12:37. Évalué à 2.
        
        Et pour rigoler un peu:
        Première liste : Microsoft=76 ème, Debian=134 ème
        Deuxième liste : Microsoft=17 ème, Debian=183 ème
        
        Étonnant non ?
        
        [^] # Re: Apparmor chez ubuntu ?
        
        Posté par patrick_g (site web personnel) le 04 décembre 2009 à 12:46. Évalué à 5.
        
        Il suffit que la taille du ou des patchs de Microsoft soit très grosse pour expliquer ça : Pas beaucoup de patchs mais beaucoup de lignes.
        Et c'est exactement ce qui se passe avec l'inclusion du pilote Hyper-V puisque le patch est gros.
        
        [^] # Re: Apparmor chez ubuntu ?
        
        Posté par jve (site web personnel) le 04 décembre 2009 à 13:57. Évalué à 1.
        
        c'est pas la taille qui compte
        
        http://xkcd.com/664/
        
        et debian ne meurt pas, ils bossent toujours autant
        
        http://planet.debian.org/
        
        [^] # Re: Apparmor chez ubuntu ?
        
        Posté par liberforce (site web personnel) le 04 décembre 2009 à 12:38. Évalué à 4.
        
        Effectivement, on se rend compte en lisant les chiffres que les contributions au kernel de Canonical ont bien progressé depuis le 2.6.31 (en nombre de lignes de code). Ils sont bien placés pour le 2.6.29 et 2.6.30, mais en changesets car le nombre de lignes changées est très faible. J'aimerais bien savoir à quelles parties du kernel Canonical a contribué.
        
        Pendant ce temps là Mandriva est resté au même niveau (bon, c'est pas les mêmes moyens non plus).
        
        Vous pouvez comparer les deux de manière graphique:
        http://www.remword.com/kps_result/evolvement.php
        
        Mandriva
        commits : http://www.remword.com/kps_result/drawimg.php?action=commit&(...)
        place dans le classement : http://www.remword.com/kps_result/drawimg.php?action=rank&am(...)
        
        Canonical
        commits : http://www.remword.com/kps_result/drawimg.php?action=commit&(...)
        place dans le classement : http://www.remword.com/kps_result/drawimg.php?action=rank&am(...)
        
        Dommage qu'il ne soit pas possible de comparer plusieurs société sur un même graphique, car là les échelles sont différentes (Mandriva a un joli record personnel avec + de 14000 lignes de code contribuées pour le 2.6.14).
        
        [^] # Re: Apparmor chez ubuntu ?
        
        Posté par patrick_g (site web personnel) le 04 décembre 2009 à 12:49. Évalué à 2.
        
        >>> Effectivement, on se rend compte en lisant les chiffres que les contributions au kernel de Canonical ont bien progressé depuis le 2.6.31
        
        Peut-être que suite aux polémiques Mark a donné des instructions pour que toutes les contributions se fassent obligatoirement à partir d'une adresse Canonical. Cela augmenterait mécaniquement la visibilité de Canonical alors qu'avant les contributions étaient plus anonymes (faites à partir d'adresse perso et autres..).
        C'est juste une théorie, je n'en sais rien.
        
        [^] # Re: Apparmor chez ubuntu ?
        
        Posté par GeneralZod le 04 décembre 2009 à 13:20. Évalué à 2.
        
        La liste que tu as donnée ne se base pas sur l'adresse électronique pour identifier la provenance des commits. Par exemple, Kees Cook ingénieur sécurité de Canonical utilise son adresse personnel et quelques autres également.
        Canonical connait réellement un regain d'activité au niveau du kernel, d'une part à cause d'AppArmor (dont ils sont l'upstream maintenant), d'autre part le développement de leur offre commerciale (serveur, OEM, etc ...). Le partenariat avec Google (ChromeOS) doit également influer, pour rappel, Intel a rompu le partenariat sur Moblin à cause des résultats décevants de Canonical dans le développement du support hardware (même si officiellement, une autre raison a été invoqué).
        
        J'espère qu'ils continueront dans la bonne direction.
        
        [^] # Re: Apparmor chez ubuntu ?
        
        Posté par Albert_ le 04 décembre 2009 à 14:15. Évalué à 1.
        
        apparmor ne faisant pas encore partie du noyau cela ne peut absolument pas expliquer la contribution de canonical/ubuntu.
        
        [^] # Re: Apparmor chez ubuntu ?
        
        Posté par GeneralZod le 04 décembre 2009 à 14:53. Évalué à 2.
        
        Comme annoncé dans l'article, John Johansen est en train de pousser AppArmor dans le noyau, quand je parle du regain d'activité, je parle d'une tendance générale pas seulement de Linux 2.6.32.
        D'après les logs de la branche linus, ce serait même la première contribution significative de Canonical au noyau si AppArmor est effectivement intégré.
        
        [^] # Re: Apparmor chez ubuntu ?
        
        Posté par Pierre Jarillon (site web personnel) le 04 décembre 2009 à 12:41. Évalué à 1.
        
        Je me suis servi du lien http://www.remword.com/kps_result/2_6_32_petop.html que tu as donné dans le texte. J'y ai recherché les contributeurs de Mandriva; Canonical et Ubuntu.
        
        [^] # Re: Apparmor chez ubuntu ?
        
        Posté par patrick_g (site web personnel) le 06 décembre 2009 à 18:06. Évalué à 4.
        
        Bizarre parce qu'il y a bien des canonical dans la liste. Tu a fais ta recherche avec un Ctrl+F comme moi ?
# Fils ou pere?

Posté par reno le 03 décembre 2009 à 13:51. É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..
- [^] # Re: Fils ou pere?
  
  Posté par case42 (site web personnel) le 03 décembre 2009 à 14:23. Évalué à 9.
  
  Depuis quand les processus ont leur mot a dire sur l'ordonnancement dans un système d'exploitation multi-tache préemptif?
  
  Manifestement, que ce soit le père ou le fils qui ai la main en premier ne change rien au comportement des applications (sinon ils n'auraient pas pu faire ce changement sans que la moitié de l'user-land ne se casse la gueule), partant de la il n'y a donc qu'une bonne façon de faire: la plus rapide. Et c'est de laisser la main au père. Et c'est ce qu'ils font. CQFD.
  - [^] # Re: Fils ou pere?
    
    Posté par reno le 03 décembre 2009 à 14:32. Évalué à -10.
    
    Tu pourrais être plus respectueux dans le ton.
    
    D'autant plus que tu as tord: si une application forke un processus puis attend le résultat du fils alors "le pere tourne d'abord" n'est *pas* le plus rapide pour l'application.
    Avoir le bon comportement par défaut est important, autoriser une application a changer ce comportement quand le défaut ne lui convient pas est interessant aussi.
    - [^] # Re: Fils ou pere?
      
      Posté par Hobgoblins Master (Mastodon) le 03 décembre 2009 à 14:38. Évalué à 10.
      
      Si le père doit attendre son fils, il va s'endormir volontairement juste après le fork, on gagne donc beaucoup de temps au final en lui laissant la main, il fait son if, son wait et dégage, il on ne s'occupe plus de lui tant que la condition du wait n'est pas satisfaite (mort du fils).
      En basculant sur le fils dès le fork, on avait un changement de contexte, blablabla, puis re changement de contexte avec tout ce que ça implique pour revenir faire juste un if et un wait dans le père !
      - [^] # Re: Fils ou pere?
        
        Posté par Julien le 04 décembre 2009 à 01:26. Évalué à 9.
        
        D'un autre côté, lors d'un fork, le processus père et le processus fils ont chacun une copie de ce qui était la mémoire du père avant le fork.
        Dans les faits, c'est mis en oeuvre par du copy-on-write : les deux processus partagent les mêmes pages de mémoire qui sont marqué en lecture seule. Lors d'un accès en écriture, le noyau est prévenu, il effectue la copie, marque la page copié comme accessible en écriture et rend la main.
        
        Pour revenir à nos moutons (ou plutôt à nos processus dans le cas présent) lors d'un fork, le processus fils a tendance à effectuer un exec juste après le fork, c'est à dire qu'il va charger un exécutable et donc réinitialiser son espace mémoire.
        
        Que se passe-il alors si le père garde la main
        père : je fork
        noyau : ok, je te crée un fils et je te laisse la main
        père : je modifie la mémoire à tel endroit
        noyau : hep, hep ,hep, c'est protégé en écriture là, laisse moi copier ça à un endroit où tu emmerdera pas ton fils
        père : je modifie la mémoire à tel autre endroit ...
        (répéter quelques fois)
        noyau : bon, ça suffit là, je te préempte et je passe la main au fils
        fils : bon, balance moi toute cette mémoire qui m'est allouée et charge les données depuis /bin/pornviewer
        noyau : ah bah c'était bien la peine que je copie toutes ces pages mémoire pour rien
        
        On le voit bien, à la fin le noyal est dépité et c'est très certainement pour éviter ça que les développeurs avaient choisi de donner la main au fils en premier. Cependant aujourd'hui les évaluations de perf montrent qu'il vaut mieux ça que de payer le coût d'un changement de contexte.
        C'est peut être du à l'utilisation de solutions crées pour éviter ce problème de copies de pages inutiles comme l'utilisation de vfork au lieu de fork par exemple, mais je ne suis pas expert dans le domaine.
        
        [^] # Re: Fils ou pere?
        
        Posté par djano le 04 décembre 2009 à 15:26. Évalué à 3.
        
        C'est écrit dans la dépêche: comme les systèmes sont de plus en plus multicore, le père continue a s'exécuter sur le même core et le fils s'en va être exécuté sur un autre core.
        Ainsi il n'y a pas de changement de contexte pour le père qui peut s'exécuter tranquillement et le fils peut s'exécuter en parallèle.
        
        Néanmoins le problème que tu soulèves a propos des copies inutiles de pages mémoires me semble toujours être la. Est ce qu'il s'agit vraiment d'un gros problème? Peut être pas, d'où l'intérêt du patch en question.
        
        [^] # Re: Fils ou pere?
        
        Posté par reno le 05 décembre 2009 à 02:09. Évalué à 1.
        
        Merci pour ton analyse qui confirme ce que je pensais: dans certains cas, exécuter le père d'abord peut être sous-optimal..
        
        Pour ce qui est de l'utilisation de vfork je ne sais pas si c'est très utilisé: la manpage de vfork inclue:
        >>
        BOGUES
        Il est regrettable que Linux ait ressuscité ce spectre du passé. La page de manuel de BSD indique que cet appel système sera supprimé,
        <<
  - [^] # Re: Fils ou pere?
    
    Posté par Krunch (site web personnel) le 04 décembre 2009 à 00:43. Évalué à 9.
    
    > Depuis quand les processus ont leur mot a dire sur l'ordonnancement
    > dans un système d'exploitation multi-tache préemptif?
    
    Depuis que POSIX a défini sched_yield() ?
    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# linuxubuntufr.org

Posté par kowalsky le 03 décembre 2009 à 14:02. É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 ?
- [^] # Re: linuxubuntufr.org
  
  Posté par patrick_g (site web personnel) le 03 décembre 2009 à 14:06. Évalué à 6.
  
  >>> Il faudrait le dire pour toutes les distributions non ?
  
  Ben Ubuntu LTS c'est que une fois tous les 2 ans et Debian Stable c'est que une fois tous les..heu...quand c'est prêt.
  Maintenant c'est vrai aussi que le noyau qui va être choisi par la prochaine RHEL 6 sera également très important.
  - [^] # Re: linuxubuntufr.org
    
    Posté par ʭ ☯ le 03 décembre 2009 à 17:33. Évalué à 5.
    
    Ah! enfin un troll dans cette depêche! Je suppose que tu l'as glissé pour qu'elle soit accepté sur ce site?
    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
    - [^] # Re: linuxubuntufr.org
      
      Posté par patrick_g (site web personnel) le 03 décembre 2009 à 21:20. Évalué à 4.
      
      Le troll qui guette soigneusement sa proie c'est surtout la partie sur les contributions de Canonical.
- [^] # Re: linuxubuntufr.org
  
  Posté par 🚲 Tanguy Ortolo (site web personnel) le 03 décembre 2009 à 14:06. Évalué à 0.
  
  Ça risque d'être long…
# merci

Posté par brokensoul le 03 décembre 2009 à 14:38. Évalué à -2.

Merci beaucoup pour l'article, super intéressant !
# KMS sur un R700

Posté par Sphax le 03 décembre 2009 à 15:00. É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 le 03 décembre 2009 à 15:15. É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 !
# Boom !

Posté par Hrundi V. Bakshi le 03 décembre 2009 à 16:01. É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 ) ?
- [^] # Re: Boom !
  
  Posté par patrick_g (site web personnel) le 03 décembre 2009 à 16:18. Évalué à 4.
  
  Sur les stats par nation il y a ceci : http://www.remword.com/kps_result/nation.php
  
  Il n'y pas tous les pays (loin de là) mais ça reste intéressant.
  
  Sinon sur la montée en puissance de la Chine j'avais lu ça au moment de la sortie du 2.6.31 : http://www.remword.com/blog/?p=161
# Tests automatiques ?

Posté par Mat (site web personnel) le 03 décembre 2009 à 16:12. É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 ?
- [^] # Re: Tests automatiques ?
  
  Posté par Eno le 03 décembre 2009 à 16:30. Évalué à 4.
  
  Voilà c'est ici : http://www.youtube.com/watch?v=L2SED6sewRw
  ( par contre c'est que de l'anglais )
- [^] # Re: Tests automatiques ?
  
  Posté par Victor STINNER (site web personnel) le 03 décembre 2009 à 19:07. Évalué à 10.
  
  comment peut-on commit dans ce repo ?
  
  Le développement est hiérarchique : chaque sous-système a son dépôt, exemples : le réseau ou le son (ALSA). À vrai dire, il existe des dizaines et des dizaines de dépôts. Tu peux avoir un petit aperçu par ici : http://git.kernel.org/
  
  Par contre, pour le tarball du noyau Linux saveur vanille, c'est le dépôt Linus qui est utilisé :
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)
  
  Disons qu'il y a deux types de commits : patchs pour améliorer un sous-système dans un dépôt (autre que celui de Linus), et acceptation (merge) des modifications depuis un dépôt tiers dans le dépôt de Linus. Je dis que le développement est hiérarchique car tu peux avoir plusieurs "couches" de dépôts (ex: dépôt d'une personne qui contient un patch spécifique => dépôt du sous-système => dépôt de Linus).
  
  Beaucoup de code est écrit sous forme de patchs soumis sur des listes de diffusion, comme par exemple la "LKML", mais ça peut aussi être sur la liste de diffusion d'un sous-système. Ces patchs sont relus par tous les abonnés à la liste de diffusion qui sont intéressés par la fonctionnalité. Vu le nombre de messages quotidiens sur la LKML, je pense qu'il y a pas mal de monde qui relit les patchs (mais toutes les personnes postant sur la LKML ne sont pas capable de relire tous les patchs bien sûr).
  
  Si le patch ne respecte pas le style de code imposé par le noyau, utilise une ancienne API, n'est pas assez générique, etc. : un nouveau patch sera exigé. Si la fonctionnalité est critique, il peut avoir plus d'une dizaine de versions d'un patch avant qu'il soit appliqué. Le patch "eventfd" (noyau 2.6.22) a par exemple exigé 26 versions avant d'être commité :-)
  
  y'a t-il des tests unitaires ou à défaut des tests plus larges de non régression ?
  
  Les phases de RC visent à dégrossir les régressions. Le site Kernel Oops liste les régressions :
  http://www.kerneloops.org/
  (on y trouve des stat' intéressantes)
  
  Il y a beaucoup d'outils d'analyse statique du code : kmemcheck, kmemleak, Sparse, etc. (développés spécifiquement pour le noyau Linux) J'ai même vu des motivés qui ont portés Valgrind pour tester le noyau Linux (un truc avec QEMU, je me souviens mal).
  
  Pour les tests automatiques, je n'en connais pas, mais il en existe peut-être. Je pense que les bugs sur les composants critiques (ex: gestion de la mémoire ou ordonnanceur de processus) sont détectés très rapidement, un bug sur un pilote d'un matériel désuet sera détecté beaucoup plus difficile car qu'un testeur ait ce matériel.
  
  Comme le code source de Linux est ouvert, il y a énormément de monde qui le relit pour apprendre à programmer, pour valider le code d'un pilote, ou encore pour traquer des failles de sécurité. Il existe aussi des logiciels de fuzzing spécifiques au noyau.
  
  y'a t-il des relectures de code, si oui sur tous les commits ? qui relit ?
  
  Comme dit, les patchs soumis sur les listes de diffusion sont relus par plusieurs personnes différentes. Je doute qu'une ligne de code ne soit commité sans avoir été relue par plusieurs personnes. D'ailleurs, depuis que git est utilisé, un commit peut être signé par plusieurs personnes (peut-être que c'était déjà possible avec BitKeeper, je sais pas). Exemple sur l'avant dernier commit du dépôt de Linus :
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)
  
  Le commit a été signé par Julia Lawall (auteure du patch) et Ralf Baechle (qui a commité le patch). Tiens, ce patch corrige un bug trouvé par un autre outil d'analyse de code automatique : http://coccinelle.lip6.fr/
  
  --
  
  Je ne suis pas développeur noyau, juste spectateur, je peux donc raconter des conneries. Mais j'espère t'avoir éclairé un peu ;-) Sinon il existe des nombreux documents qui expliquent comment le noyau Linux est développé (y'a même des analyses sociologiques ;-)).
  - [^] # Re: Tests automatiques ?
    
    Posté par monde_de_merde le 03 décembre 2009 à 20:05. Évalué à 6.
    
    Tout récement (depuis le 01/12/2009), Michael Larrabel de Phoronix a mis en place un système automatique d'évaluation des performance du noyau couplé à un script qui réalise des "bisect" en cas de régressions importantes afin de localiser le commit source.
    
    Plus d'info ici : http://www.phoronix.com/scan.php?page=article&item=phoro(...)
  - [^] # Re: Tests automatiques ?
    
    Posté par patrick_g (site web personnel) le 03 décembre 2009 à 20:31. Évalué à 4.
    
    >>> Pour les tests automatiques, je n'en connais pas, mais il en existe peut-être.
    
    Y'a ça qui est maintenu par IBM: http://ltp.sourceforge.net/
  - [^] # Re: Tests automatiques ?
    
    Posté par fweisbec le 03 décembre 2009 à 22:12. Évalué à 10.
    
    Sparse est effectivement un analyseur statique de code (backend). Mais kmemcheck et kmemleak sont dynamiques (font des vérifications pendant que le noyau tourne).
    
    Le noyau est en fait truffé d'analyseur dynamiques.
    Liste non-exhaustive:
    
    Outils "j'me tourne les pouces et j'attends qu'on me detecte un problème":
    
    - Lockdep: vérifie les dépendances des verroux, prévient des possibilités de deadlocks.
    - Hung Task: Vérifie périodiquement les tâches qui sont bloquées en mode non-interruptible pendant trop longtemps
    - Soft-lockup: Vérifie que la tache courrante a été changée durant les dix dernières secondes
    - Nmi watchdog: Vérifie les hard lockups (coincé dans une interruption, ou code avec interruptions désactivées, ou deadlock de spinlock)
    - Kmemcheck: Detecte usage de memoire non initializée (lecture avant toute écriture)
    - Kmemleack: Detecte fuites de mémoires
    - Poisons: D'une manière générale, les poisons sont des codes répétitifs qu'on insère dans un zone de mémoire libérée, comme par exemple une répétition de 0x66666
    Lorsqu'on alloue une page mémoire et qu'elle a été modifiée (une partie des 666 a été modifiée), on le signale. Comme ça detecte les usages de pages libérées
    - Fault injection: Provoque beaucoup d'échecs d'allocations mémoire pour voir comment le kernel s'en sort avec peu de mémoire.
    
    Outils "ah zut faut encore que j'analyse les résultats":
    
    - Ftrace
    - Perf events
    - Plein de trucs
    
    Certains mainteneurs testent les patchs qu'on leur soumet, parfois 24h/24h comme Ingo Molnar qui teste des démarrages de configs de noyaux aléatoires automatiquement sur les arbres de developpement qu'il maintient.
    
    Ceci étant, avant qu'un patch soit commité dans l'arbre d'un mainteneur, avant même qu'il ne soit testé, il est d'abord passé en revue, par un quidam lambda qui passe par là (et qui peut délivrer un tag Reviewed-by:), et/ou par un mainteneur.
    
    C'est d'ailleurs souvent la chasse aux tags "Acked-by". Un diminutif pour acknowleged (inteprété ici comme "jugé acceptable par:"). Il s'agit d'un tag que donnent les mainteneurs d'un sous-système ou par simplement quelqu'un qui connait bien le code en question.
    
    Lorsqu'il y a un patch un peu sensible à soumettre, parce qu'il modifie des fonctionnalités clés, les Acked-by sont souvent le passeport pour que ce patch puisse passer.
    
    Et si personne ne se donne la peine de relire, commenter, "commiter" le patch en question, c'est Andrew Morton qui s'y colle :p
    
    Donc voilà, en règle générale, il faut envoyer son patch avec:
    - LKML et/ou la liste de diffusion du sous-système visé
    - Les mainteneurs, ou n'importe quelle personne qui connait un peu le code en question (on peut regarder dans l'historique des fichiers modifiés avec git-log). Sinon il suffit simplement de lancer le script suivant: "scripts/get_maintainer.pl patch_a_soumettre"
    
    Et ce sans compter les petites règles de base (Documentation/SendingPatches) et les règles moins de base (Documentation/DevelopmentProcess/) qui font qu'un patch est plus acceptable qu'un autre.
# vidéo Youtube sur le Kernel.

Posté par Eno le 03 décembre 2009 à 16:27. É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 Raoul Volfoni (site web personnel) le 03 décembre 2009 à 16:27. É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
- [^] # Re: Correction
  
  Posté par patrick_g (site web personnel) le 03 décembre 2009 à 17:14. Évalué à 2.
  
  Corrigé. Merci.
# Coquilles

Posté par claudex le 03 décembre 2009 à 16:39. É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)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: Coquilles
  
  Posté par patrick_g (site web personnel) le 03 décembre 2009 à 17:14. Évalué à 2.
  
  Bouh le "l'un deux" c'est vilain :-(
  J'ai corrigé les deux erreurs. Merci.
  - [^] # Re: Coquilles
    
    Posté par liberforce (site web personnel) le 03 décembre 2009 à 17:44. Évalué à 2.
    
    Une autre: Le problème c'est que que le type du code retour
    - [^] # Re: Coquilles
      
      Posté par patrick_g (site web personnel) le 03 décembre 2009 à 17:52. Évalué à 2.
      
      Argh décidément on peut relire 36 fois il en reste toujours.
      Merci de l'info. J'ai corrigé.
      - [^] # Re: Coquilles
        
        Posté par Victor STINNER (site web personnel) le 03 décembre 2009 à 19:08. Évalué à 4.
        
        On me demande vraiment à quoi servent les modérateurs si c'est pour laisser passer autant de fautes !
        
        [^] # Re: Coquilles
        
        Posté par Victor STINNER (site web personnel) le 03 décembre 2009 à 19:09. Évalué à 5.
        
        On se demande...
        
        (ah bah bravo, faudrait modérer les messages aussi, et en plus nohjan me fout la honte avec sa BD)
# Dénomination des versions RC !!??

Posté par Julien04 (site web personnel) le 03 décembre 2009 à 17:45. É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
- [^] # Re: Dénomination des versions RC !!??
  
  Posté par patrick_g (site web personnel) le 03 décembre 2009 à 17:57. Évalué à 9.
  
  Borf chaque projet a plus ou moins ses conventions de nommage.
  Faut voir aussi que les RC ne sont pas des alphas au sens ou ce ne sont pas des versions instables ou un code fait pour la première fois son apparition.
  Le nouveau code il est d'abord envoyé pour revue sur la LKML et il vit dans la branche Git spécifique du développeur.
  Une fois que tout est plus ou moins OK il va dans la branche Linux-Next pour vérifier plus en profondeur les interactions avec le reste. Enfin il est mergé par Linus dans une fenêtre de merge et il fait partie du cycle des RC.
  Les RC ne sont donc que les phases finales de pas mal de boulot amont.
  - [^] # Re: Dénomination des versions RC !!??
    
    Posté par Victor STINNER (site web personnel) le 03 décembre 2009 à 19:15. Évalué à 6.
    
    À ce que j'ai compris, il y a rarement du nouveau code ajouté durant les phases de RC. Seuls les nouveaux pilotes sont acceptés, vu qu'ils ne peuvent pas introduire de régression (vu qu'ils n'existaient pas dans la version précédente). Les phases de RC servent essentiellement à détecter les régressions. C'est cohérent avec la définition de Julien04.
    
    Si on reprend le vocabulaire alpha/béta/RC, je pense que ça ressemble à ça :
    
    Comme dit patrick_g, la version alpha d'un patch est développé sur la machine perso d'un développeur. Une fois qu'elle est assez stable, le patch est soumis pour relecture (phase béta). Le merge dans le dépôt de Linus est la dernière étape (phase RC).
    - [^] # Re: Dénomination des versions RC !!??
      
      Posté par Albert_ le 03 décembre 2009 à 21:07. Évalué à 2.
      
      Il me semble que Linus fait parfoit des exceptions comme pour les drivers radeons ou c'est en rc2 ou rc3 qu'un enorme patch a ete introduit.
      - [^] # Re: Dénomination des versions RC !!??
        
        Posté par glisse le 04 décembre 2009 à 11:57. Évalué à 1.
        
        C'est parceque le driver radeon était dans staging.
        
        [^] # Re: Dénomination des versions RC !!??
        
        Posté par Albert_ le 04 décembre 2009 à 12:25. Évalué à 2.
        
        je ne critique pas je faisais juste une constatation et en tout cas bravo pour le boulot effectue.
# ah ! merci

Posté par oau le 03 décembre 2009 à 18:18. É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.
- [^] # Re: ah ! merci
  
  Posté par FRLinux (site web personnel) le 03 décembre 2009 à 21:21. Évalué à 6.
  
  Cela dépends de quoi tu parles. Si tu parles sur le noyau uniquement ou l'applicatif. Je vais présumer que tu laisses l'applicatif de coté (y compris les solutions payantes genre DB2/Oracle/etc...) et que tu voudrais connaître les avancées technologiques des autres systèmes d'exploitation.
  
  Sur ce point, je ne dirais pas que Linux est plus en avance qu'un BSD ou un autre Unix, je dirais qu'il est juste plus adapté à une tâche ou une autre. Par exemple, imaginons que tu veuilles faire un routeur pour remplacer un cisco de faible charge (max 1Gb/s de traffic), qui fasse aussi du bgp/ospf ainsi que du dual stack IPv4/IPv6. Mon choix dans ce cas n'irais pas vers Linux mais vers OpenBSD, car les différents protocoles que je viens d'évoquer dans mon exemple sont bien supportés et documentés sur cet OS. Cela ne veut pas dire que Linux est en retrait, mais simplement que dans ce cas, je trouve OpenBSD plus adapté.
  
  Donc en résumé, c'est plus un point de vue qu'une compétition :)
  - [^] # Re: ah ! merci
    
    Posté par oau le 04 décembre 2009 à 12:30. Évalué à 2.
    
    On est d'accord. Je parlais en fait plutôt d'ordonnanceur, de fs de manière de gérer la mémoire, les écritures sur les disques etc. Tout ce qui me semble être le cœur du système. Linux semble beaucoup utiliser les arbres. Est -ce cas pour les autres os ? Existe il d'autres manière de faire ? Je me doute bien que la réponse ne doit pas être simple sachant que les informations pour les autres os ne sont pas publique. C'est pour ça que j'aime le libre. On sait comment ça marche. Enfin patrick_g sait comment ça marche et nous l'explique. J'aurais vraiment aimer avoir les même information concernant zindows et AIX.
    - [^] # Re: ah ! merci
      
      Posté par patrick_g (site web personnel) le 04 décembre 2009 à 12:55. Évalué à 7.
      
      >>> On sait comment ça marche. Enfin patrick_g sait comment ça marche et nous l'explique.
      
      Encore une fois, et comme je le précise rituellement à chaque fois, je ne suis pas un codeur et je me contente de compiler/tenter de comprendre/vulgariser/rédiger en français les informations qu'on trouve sur le net.
      Je n'ai donc absolument pas une connaissance de première main du fonctionnement du noyau...et c'est pour ça que l'avalanche de félicitations me met un peu mal à l'aise. Ce sont les 1240 contributeurs du 2.6.32 qu'il faut féliciter.
      - [^] # Re: ah ! merci
        
        Posté par liberforce (site web personnel) le 04 décembre 2009 à 16:24. Évalué à 10.
        
        En même temps tout ce qui aide à la compréhension du fonctionnement du noyau incite du monde à s'y mettre parce qu'ils trouvent dans chaque article une bonne dose d'informations essentielles. Et puis faciliter l'arrivée de nouveaux contributeurs n'est pas une activité moins noble que de coder.
        
        De même dans un milieu professionnel, ce type d'article permet rapidement de savoir ce que l'on peut espérer d'une mise à jour du noyau. De plus tes articles sont régulièrement repris dans la presse francophone (je vois régulièrement un lien sur generation-nt.com par exemple), car ce sont des articles de référence, et quasi-exhaustifs.
        
        Alors pas de fausse modestie, c'est mérité ;-)
# Et le lexique ?

Posté par Infernal Quack (site web personnel) le 03 décembre 2009 à 19:18. É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.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
- [^] # Re: Et le lexique ?
  
  Posté par Victor STINNER (site web personnel) le 03 décembre 2009 à 19:22. Évalué à 3.
  
  Quels acronymes / termes / autre n'as-tu pas compris ? En tant que modérateur, je serai intéressé de savoir ce qu'il faut améliorer, mais là tu es trop vague. Cette dépêche est bourrée de liens pour en savoir plus : je pense que tu trouveras des réponses en suivant les liens ;-)
  - [^] # Re: Et le lexique ?
    
    Posté par Infernal Quack (site web personnel) le 03 décembre 2009 à 20:42. Évalué à 5.
    
    a.x²+b.x+c
    L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
    - [^] # Re: Et le lexique ?
      
      Posté par Pierre Tramal (site web personnel) le 04 décembre 2009 à 06:31. Évalué à 4.
      
      ... avec a différent de 0.
      - [^] # Re: Et le lexique ?
        
        Posté par Infernal Quack (site web personnel) le 04 décembre 2009 à 09:42. Évalué à 3.
        
        Beaucoup semble penser que a est toujours à 0 icitte :(
        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
  - [^] # Re: Et le lexique ?
    
    Posté par Elfir3 le 03 décembre 2009 à 21:29. Évalué à 2.
    
    Je crois qu'il voulait juste faire plaisir à patrick_g qui doit en avoir marre de tant d'éloges à chaque fois qu'il rédige une dépêche. Je le salue bien bas d'ailleurs d'en avoir dit du mal, j'ai quelques difficultés à ne pas jeter des fleurs en te répondant :/
# Bonne dépêche

Posté par mathieui (site web personnel) le 03 décembre 2009 à 20:47. Évalué à 1.

Génial, comme d'habitude :).
# CC BY-SA

Posté par barmic le 03 décembre 2009 à 21:52. Évalué à 3.

C'est cool que la dépêche soit libre. Sous quel licences sont elles habituellement ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: CC BY-SA
  
  Posté par patrick_g (site web personnel) le 03 décembre 2009 à 23:45. Évalué à 6.
  
  >>> Sous quel licences sont elles habituellement ?
  
  Par défaut si ce n'est pas spécifié il parait que c'est juste le droit d'auteur qui s'applique.
  Là c'est baud123 qui m'a suggéré, quand la news était encore au chaud en phase de modération, que linuxfr montre l'exemple et de mettre la news sous CC-BY ou sous CC-BY-SA.
  J'ai trouvé que c'était une bonne idée.
- [^] # Re: CC BY-SA
  
  Posté par BAud (site web personnel) le 03 décembre 2009 à 23:48. Évalué à 2.
  
  "yet another licence" :)
  Plus sérieusement, il n'y a que les entretiens pour lesquels c'est correctement décrit :
  http://linuxfr.org/interviews/
  
  Sur http://linuxfr.org/association/ il y a "En bref, on se réserve le droit de faire ce qu'on veut." (dans un contexte un peu flou, il n'est pas précisé à quoi cela s'applique o_O).
  
  Et sinon en vrai, consulter http://linuxfr.org//tracker/630.html qui n'a pas encore été statué pour le choix d'une licence.
  
  Cette fois-ci, j'ai demandé à patrick_g s'il souhaitait préciser (comme cela, ça permettra de promouvoir les dépêches de sortie du noyau Linux au-delà de LinuxFr, la gloire, la richesse, les femmes \o/). Autant prendre de bonnes habitudes pour promouvoir le libre avec du libre ;-)
# Bonne petite lecture

Posté par Dup (site web personnel) le 03 décembre 2009 à 22:44. É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 feth le 03 décembre 2009 à 23:31. É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 04 décembre 2009 à 00:40. É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...
- [^] # Re: Les grosses copies de fichiers sous Linux
  
  Posté par Victor STINNER (site web personnel) le 04 décembre 2009 à 01:39. Évalué à 2.
  
  Tiens, ça me rappelle Windows 98 dès qu'on accédait au lecteur de disquette :-)
  
  Pour Linux 2.6.32, le mieux sera de tester je pense ;-)
- [^] # Re: Les grosses copies de fichiers sous Linux
  
  Posté par neologix le 04 décembre 2009 à 10:40. Évalué à 1.
  
  Essaie avec
  echo 0 > /proc/sys/vm/swappiness
  
  Sinon, pour réduir le temps de démarrage des applications après une grosse copie par exemple, il y a le patch swap-prefetch de Con Kolivas : http://ck.wikia.com/wiki/SwapPrefetch
  - [^] # Re: Les grosses copies de fichiers sous Linux
    
    Posté par sanao le 04 décembre 2009 à 14:38. Évalué à 2.
    
    Je viens de tester (sur une Kubuntu 8.10) l'abaissement du swapiness et j'ai l'impression que cela améliore un peu la réactivité, mais rien de bien notable.
  - [^] # Re: Les grosses copies de fichiers sous Linux
    
    Posté par windu.2b le 05 décembre 2009 à 12:06. Évalué à 1.
    
    C'est moi ou ce site a plus de pubs que de texte utile ?!? O_o
    - [^] # Re: Les grosses copies de fichiers sous Linux
      
      Posté par fweisbec le 05 décembre 2009 à 23:08. Évalué à 2.
      
      Conseiller swap prefetch à quelqu'un qui a des soucis de latence parce que ses programmes de bureau mettent du temps à charger après une grosse invasion dans le "page cache" (dur à une grosse écriture), ça me semble plutôt du texte utile. Même si ça m'etonnerais que ce patch s'applique proprement sur un noyau récent.
      - [^] # Re: Les grosses copies de fichiers sous Linux
        
        Posté par windu.2b le 06 décembre 2009 à 11:30. Évalué à 2.
        
        Je parlais de toutes les pubs qui apparaissent partout dans les pages de Wikia...
- [^] # Re: Les grosses copies de fichiers sous Linux
  
  Posté par Nicolas Boulay (site web personnel) le 04 décembre 2009 à 12:33. Évalué à 1.
  
  A une époque cela pouvait venir d'un contrôleur disque qui n'utilisait pas le DMA. Normalement, Linux s'est beaucoup améliorer la dessus.
  
  Si tu as un noyau récent et qu'une commande du style mets ton système à genoux, il y a un gros souccis quelques part.
  $ dd if=/dev/zero of=/dev/null bs=1024k
  
  C'est possible aussi que tu ais un setting pour serveur qui enlève la préemption du kernel pour gagner en bande passante ce que tu perds en basse latence.
  "La première sécurité est la liberté"
  - [^] # Re: Les grosses copies de fichiers sous Linux
    
    Posté par sanao le 04 décembre 2009 à 14:42. Évalué à 3.
    
    Un dd if=/dev/zero of=/dev/null bs=1024k ne ralentit pas ma machine de boulot (une Kubuntu 8.10). Et je pense que c'est normal puisque envoyer les 0 sur /dev/null ne doit jouer que sur la mémoire.
    
    Par contre un dd if=/dev/zero of=/tmp/toto bs=1024k ralentit sérieusement la machine.
    - [^] # Re: Les grosses copies de fichiers sous Linux
      
      Posté par Nicolas Boulay (site web personnel) le 04 décembre 2009 à 16:09. Évalué à 2.
      
      Tu es peut-être en ext4 ?
      "La première sécurité est la liberté"
      - [^] # Re: Les grosses copies de fichiers sous Linux
        
        Posté par sanao le 04 décembre 2009 à 17:25. Évalué à 2.
        
        Je suis bien en ext4 sur ma machine de boulot. Par contre j'ai ce problème depuis bien avant ext4.
        
        Je réessaierais le "stress test" avec le dd chez moi où j'ai des partitions ext3.
- [^] # Re: Les grosses copies de fichiers sous Linux
  
  Posté par krumtrash le 04 décembre 2009 à 18:18. Évalué à 2.
  
  Je valide.
  
  Le pire étant en passant sur un disque USB2 externe.
  Le processeur montre à 100% ( les 2 coeurs...), entre du SSD ext4 et du HDD ext3... pas glop...
  
  PS: c'est pas du matos exotique, que du intel + un linux récent.
  - [^] # Re: Les grosses copies de fichiers sous Linux
    
    Posté par Albert_ le 05 décembre 2009 à 00:58. Évalué à 3.
    
    un test "rigolo" faire du dd d'une image iso sur une cle usb cela rend le systeme inutilisable pendant looongtemps. Le probleme de ce bug c'est que cela fait longtemps qu'il existe et que personne n'arrive a donner un test case simple du coup le bug report degenere et un nouveau est cree pour centraliser tout le bousin etc. J'ai arrete de suivre ca car cela en etait impossible et je soupconne que malheureusement c'est le cas pour les devs aussi... d'ou sa presence recurente.
    - [^] # Re: Les grosses copies de fichiers sous Linux
      
      Posté par allcolor (site web personnel) le 07 décembre 2009 à 17:48. Évalué à 4.
      
      J'ai le même problème... en changeant le scheduler IO à anticipatory au lieu de cfq, je n'ai plus le problème.
      
      Donc faire soit: elevator=anticipatory dans la ligne de boot kernel ou au runtime dans
      
      echo "anticipatory" > /sys/block/sda/queue/scheduler
      
      Si le disque en question est sda.
# LinUS

Posté par Amine "nh2" Brikci-Nigassa (site web personnel) le 04 décembre 2009 à 01:20. É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
GNU's Not Unix / LINUX Is Not Unix Xernel
- [^] # Re: LinUS
  
  Posté par fweisbec le 04 décembre 2009 à 01:29. Évalué à 2.
  
  Arnold Shwarzenegger: 1
  Linus Torvalds: 0
  - [^] # Re: LinUS
    
    Posté par Amine "nh2" Brikci-Nigassa (site web personnel) le 04 décembre 2009 à 02:54. Évalué à 3.
    
    récemment découvert : Linus est le petit frère caché d'Arnold... http://distrowatch.com/weekly.php?issue=20090202#feature (voir la photo)
    il est d'ailleurs son conseiller : http://management.silicon.com/government/0,39024677,39123580(...)
    GNU's Not Unix / LINUX Is Not Unix Xernel
    - [^] # Re: LinUS
      
      Posté par fweisbec le 04 décembre 2009 à 03:05. Évalué à 1.
      
      Marf! :-)
- [^] # identité nationale
  
  Posté par bubar🦥 (Mastodon) le 04 décembre 2009 à 06:09. Évalué à 4.
  
  C est l autre troll caché qui attends sa victime ;-)
  
  Bravo pour cette présentation par pays, mesdames et messieurs du noyau :-)
  
  Ils vivent, travaillent, respectent les lois, adoptent les us et coutumes, d un pays différent de leur pays d origine. Ils enrichissent leurs pays d accueils par eux mêmes , simplement, par leur travail, et par leurs apports culturels.
  Leurs enfants grandissent ou grandiront dans leurs pays d accueils, et pour eux il s agira de leurs pays d origine.
  
  Le siècle précédent a connu l'évolution du sang vers la terre, notre siècle reconnaitra certainement l'évolution de la terre vers le choix. Parceque la terre est de plus en plus la Terre. L identité nationale peut être innée et acquise, pas seulement innée. Et plus aujourdhui : peut être acquise par choix culturel et personnel, par résultante économique, sans jamais aujourdhui venir se substituer à une autre. On ne remplace pas son identité culturelle par une identité nationale, on enrichie une nouvelle identité nationale par ses identités culturelles.
  - [^] # Re: identité nationale
    
    Posté par Thomas Douillard le 04 décembre 2009 à 11:53. Évalué à 2.
    
    L identité nationale peut être innée
    Il n'y a rien de génétique là dedans, c'est purement culturel, donc acquis après la naissance ...
    - [^] # Re: identité nationale
      
      Posté par bubar🦥 (Mastodon) le 04 décembre 2009 à 13:20. Évalué à 1.
      
      pas faux :-) même plutôt vrai :-)
      Dans le même temps innée est employé ici dans le sens oppposé à acquis : quelque chose que l'on ne choisi pas, mais que l'on a à la naissance.
      
      C'est là toute l'ambiguĩté du débat actuel : en choississant un postulat forcément polémique, on(ils) choisit de déplacer le débat vers un second terrain. Ils jouent avec la dépendances entre paquets.
      
      stop ;)
    - [^] # Re: identité nationale
      
      Posté par Amine "nh2" Brikci-Nigassa (site web personnel) le 04 décembre 2009 à 14:37. Évalué à 3.
      
      L identité nationale peut être innée
      Il n'y a rien de génétique là dedans
      innée != héréditaire
      GNU's Not Unix / LINUX Is Not Unix Xernel
      - [^] # Re: identité nationale
        
        Posté par Sylvain Sauvage le 06 décembre 2009 à 19:30. Évalué à 3.
        
        Reprenons un peu le vocabulaire, ça évitera l’enlisement :
        
        1. Il s’agit de nationalité (p! c’est quoi ça « identité nationale » pour un individu ?).
        
        2. Inné : depuis la naissance.
        
        3. Héréditaire : obtenu par droit de succession, donc de parenté, donc souvent génétique mais pas forcément.
        
        Dans l’application du « droit du sang », la nationalité est héréditaire (l’enfant est X parce que ses parents sont X), souvent génétique (les parents en droit sont souvent les parents biologiques), souvent innée (l’enfant est X dès sa naissance, c’est automatique).
        
        [^] # Re: identité nationale
        
        Posté par Thomas Douillard le 06 décembre 2009 à 21:13. Évalué à 2.
        
        Pas copmplètement d'accord, cf. Inne par exemple, il s'agit d'un caractère biologique, donc la nationalité est HS.
        
        Le wiktionnaire est un peu moins tranché, mais quand même, ça me semble pas tout à fait dans les clous : http://fr.wiktionary.org/wiki/inn%C3%A9
        
        Le tlfi confirme mon impression : http://atilf.atilf.fr/dendien/scripts/tlfiv5/advanced.exe?8;(...)
        
        [^] # Re: identité nationale
        
        Posté par Sylvain Sauvage le 08 décembre 2009 à 00:48. Évalué à 2.
        
        Non. Inné ne se limite pas au biologique.
        
        1. Inne. Dans son ensemble, l’article se place dans l’opposition inné – acquis, il ne se place pas comme une définition du vocabulaire (c’est une encyclopédie, pas un dictionnaire).
        Son introduction, en particulier, définit ce qu’est l’innéité d’un caractère biologique, elle ne dit pas qu’« inné » ne peut s’appliquer qu’aux caractères biologiques.
        
        2. Le wiktionnaire est très court et me semble confirmer ce que je dis : est inné ce que l’on a en naissant, on ne l’obtient pas, on l’a seulement par le fait de naître.
        
        3. Le TLFi (lien sans session : http://atilf.atilf.fr/dendien/scripts/fast.exe?inne ) indique que l’adjectif s’emploie, je cite : « En parlant d'un comportement ou d'une caractéristique le plus souvent psychique ». Je ne vois pas en quoi il ne pourrait s’appliquer à la nationalité qui est bien une caractéristique de l’individu.
        
        The devil can cite Scripture for his purpose. — Le marchand de Venise.
        ;oP
        
        [^] # Re: identité nationale
        
        Posté par Thomas Douillard le 08 décembre 2009 à 11:31. Évalué à 2.
        
        La nationalité n'a rien d'une caractéristique psychique. Ce n'est pas un trait de caractère. L'identité non plus, c'est un héritage culturel qui est construit pendant le développement de l'enfant puis de l'adulte.
        
        [^] # Re: identité nationale
        
        Posté par Sylvain Sauvage le 08 décembre 2009 à 19:26. Évalué à 3.
        
        La nationalité n'a rien d'une caractéristique psychique.
        
        « Le plus souvent psychique » ne veut pas dire que ce n’est jamais applicable à une caractéristique non psychique.
        
        Ce n'est pas un trait de caractère.
        
        Caractéristique ne veut pas dire trait de caractère.
        
        La nationalité est une propriété qui distingue un individu, donc une caractéristique. Si cette propriété est valide dès la naissance de l’individu et par le seul fait de cette naissance, alors elle est innée.
        
        L'identité non plus, c'est un héritage culturel qui est construit pendant le développement de l'enfant puis de l'adulte.
        
        Je parle bien de la nationalité, pas de l’« identité nationale » qui n’a, pour moi et comme je l’ai déjà remarqué, aucun sens pour un individu. Si tant est que cette locution ait un sens, il s’agirait de celui d’identité de la Nation, en tant qu’entité morale.
        La nationalité peut être acquise ou innée. De droit, un enfant né de parents français est français dès sa naissance, sans qu’aucun acte n’ait à être effectué. Dans ce cas, la nationalité est bien innée.
        
        [^] # Re: identité nationale
        
        Posté par Thomas Douillard le 08 décembre 2009 à 19:45. Évalué à 2.
        
        Tu ne me convainc pas. Les exemples du tlfi ne donnent aucun emploi dans le même sens que le tiens, l'emploi de "nationalité innée" dans google ne donnent presque aucun résultat. Les synonymes ne collent pas non plus avec la nationalité : naturel, instinctif, congénital, infus ...
        
        Le seul truc que je trouve qui pourrait coller c'est la "noblesse infuse", mais dans un débat pareil, je trouve l'expression pas neutre du tout
        
        [^] # Re: identité nationale
        
        Posté par Sylvain Sauvage le 09 décembre 2009 à 20:44. Évalué à 4.
        
        Tu sais, ce ne sont que des synonymes, s’ils existent, c’est qu’ils ont un sens ou une utilisation différents, sinon certains auraient disparu ou se serait rarifiés (remarque que, p.ex., congénital s’est restreint au médical et au péjoratif).
        
        Pour les résultats Google : je ne m’étalerai pas sur tout ce qu’on peut leur faire dire, je dirais juste qu’inné est un mot déjà peu utilisé, on utilise plutôt « à la naissance » et l’occasion de l’utiliser en relation avec la nationalité est sans doute rare. (Aussi, je préfère trois résultats sur des sites sérieux que 5000 blogs indigents.)
        
        Pour moi, et c’est tout ce que je défends ici, inné = dès/par la naissance, et s’oppose à acquis ; il peut donc s’appliquer pour la nationalité qui peut bien être à la fois acquise ou de naissance. Je ne dis pas que c’est un usage fréquent mais un usage possible, que c’est usage est compréhensible et ne choque ni le sens ni l’étymologie.
        
        Mais bon, si tu n’es pas convaincu, tant pis hein.
        
        [^] # Re: identité nationale
        
        Posté par Thomas Douillard le 09 décembre 2009 à 21:19. Évalué à 2.
        
        La phrase originale c'était L identité nationale peut être innée et acquise, pour revenir aux origines.
        
        Je ne suis toujours pas d'accord avec ça, qui sous entend qu'un gamin, de part sa naissance, possède l'identité du pays en question.
        
        Ben non, tu prends le même gamin, tu le fais adopter à la naissance ou peu après dans un autre pays, il va acquérir une identité toute autre.
# Époustouflant !

Posté par Pierre Jarillon (site web personnel) le 04 décembre 2009 à 02:05. É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 ?
- [^] # Re: Époustouflant !
  
  Posté par claudex le 04 décembre 2009 à 03:02. Évalué à 4.
  
  Est-ce qu'il existe une limite ?
  
  Une partie des améliorations vient du matériel qui évolue et des usages qui changent. Donc, s'il y a une limite elle est repoussée par les nouveaux matériels.
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Merci

Posté par MARY Julien (site web personnel) le 04 décembre 2009 à 03:58. É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.
- [^] # Re: Merci
  
  Posté par adonai le 04 décembre 2009 à 12:42. Évalué à 2.
  
  Encore un commentaire extrêmement inutile qui fait perdre du temps (et avec tous ces amis, une place énorme) et avec lequel (O_o) on se sent rien du tout de plus après qu'avant (à part peut-être vaguement énervé par cette vague de "trop trop bien, patrick_g< !").
  - [^] # Re: Merci
    
    Posté par Dabowl_92 le 04 décembre 2009 à 15:07. Évalué à -4.
    
    merci pour cette contribution.
    
    Que ton nom soit centifié de part les vallées et les montagnes.
    - [^] # Re: Merci
      
      Posté par windu.2b le 05 décembre 2009 à 12:03. Évalué à 1.
      
      "Que ton nom soit centifié"
      Le jeu du centage, c'est sur PCInpact...
      Ici, il faudrait plutôt dire "sanctifier"
  - [^] # Re: Merci
    
    Posté par Octabrain le 04 décembre 2009 à 22:59. Évalué à 3.
    
    C'est un très bon moyen de gagner du karma, du moment qu'on est dans les premiers à poster, on est sûr d'obtenir +10. En plus, c'est même pas la peine de se faire chier à lire la dépêche, c'est vraiment tout bénef'.
# Rebond sur l'API des pilotes réseaux

Posté par MARY Julien (site web personnel) le 04 décembre 2009 à 04:19. É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.
- [^] # Re: Rebond sur l'API des pilotes réseaux
  
  Posté par grid le 04 décembre 2009 à 11:00. Évalué à 5.
  
  Dans quel univers parallèle ?
# Quelques questions

Posté par Dreamkey le 04 décembre 2009 à 15:25. É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 :)
- [^] # Re: Quelques questions
  
  Posté par patrick_g (site web personnel) le 04 décembre 2009 à 15:39. Évalué à 3.
  
  Les pilotes, qu'il s'agisse du pilote Hyper-V de Microsoft ou des pilotes réseau, peuvent être chargés dynamiquement dans le noyau. Ce sont des modules qui sont chargés ou pas et donc il n'y a pas d'alourdissement du noyau pour les modules que tu n'utilise pas.
- [^] # Re: Quelques questions
  
  Posté par Boa Treize (site web personnel) le 04 décembre 2009 à 18:34. Évalué à 5.
  
  Au niveau de la taille des pilotes, quelques affirmations en vrac (pas le temps de faire mieux) :
  
  - un pilote peut être plus ou moins bien codé, et donc être plus ou moins gros, indépendamment de sa qualité
  
  - ce qui prend de la place, c'est de gérer tous les cas particuliers ; un pilote spécifique à un matériel, et un pilote générique à des matériels dont les constructeurs respectent bien les normes appropriées, n'ont pas de raison d'avoir des complexités très différentes (parce que dans le deux pilotes, on ne gère en fait qu'un seul "cas") ; le pire en théorie c'est un pilote générique qui essaie de dialoguer avec des matériels tous subtilement différents
  
  - comme l'a dit patrick_g, seuls les pilotes correspondant au matériel présent dans la machine sont chargés en mémoire ; les autres pilotes prennent de la place sur le disque dur, c'est tout
  
  - un pilote, c'est n'est pas qu'un bout de code qui s'exécute dans le noyau ; souvent, il faut aussi des bibliothèques de fonction, pour que les programmeurs ne se prennent pas trop la tête avec les détails, et des programmes pour que l'utilisateur soit face à un truc potable pour gérer son matériel ; sous Linux, c'est très standardisé, grâce à l'open source, par exemple Sane pour gérer tout ce qui ressemble à un scanner ; sous Windows, quand il n'y a pas de bibliothèque standard pour gérer quelque chose, les constructeurs sont souvent obligés de les coder eux-même ; pareil pour les programmes, c'est ce qui fait la distinction entre les constructeurs, donc chacun fait son truc de gestion avec plein d'images, de fonctionnalités, de modèles, de trucs lourds divers... Tout ça pèse nettement plus que le pilote de base ! Exemple, pilote HP "complet" pour ma LaserJet : 600 Mo (grosse appli lourde autour du pilote) ; pilote HP "light" (juste le pilote, et l'utilisateur se contentera des fenêtres standard Windows pour gérer son imprimante) : 15 Mo (et au sein de ces 15 Mo, le pilote lui-même ne représente peut-être que 1 ou 2 Mo)
  
  Bref, le poids des pilotes sous Windows, c'est surtout lié à la "valeur ajoutée" du fabricant, à tous les programmes qu'il fournit "en plus" du "vrai pilote".
  
  Oh, et les pilotes Windows sont "souvent" programmés avec des budgets limités, avec du temps limité, pas forcément par les meilleurs des meilleurs, avec juste le temps de pondre une version initiale et c'est tout ; bref, dès que le "gros truc" est pondu, on arrête et on passe à autre chose (surtout valable pour le matériel no-name taïwanais ou les entreprises géantes qui créent de nouveaux modèles en tous genres à tour de bras...)
# KMS pour radeon

Posté par riri le breton (site web personnel) le 04 décembre 2009 à 19:49. É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 :-)
- [^] # Re: KMS pour radeon
  
  Posté par Albert_ le 05 décembre 2009 à 01:02. Évalué à 3.
  
  Peut etre pourrais tu remercier directement un des gros responsable de cela vu qu'il traine sur ce site de temps en temps :)
  
  http://linuxfr.org/~glisse/
# comme d'habitude

Posté par Julien BALLET (site web personnel) le 07 décembre 2009 à 15:04. Évalué à -1.

un tres bon article patrick, comme d'habitude.
merci !
# Thumb2 : ARMv7 et Cortex

Posté par Aissen le 07 décembre 2009 à 15:17. É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 décembre 2009 à 18:48. É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.
- [^] # Re: Erreur d'interpretation sur l'API reseau
  
  Posté par patrick_g (site web personnel) le 15 décembre 2009 à 08:08. Évalué à 7.
  
  Salut,
  
  Comme je ne suis pas développeur ce serait cool que tu expliques en détail et pour le bénéfice de tous mon erreur (que je suis tout à fait prêt, par avance, à reconnaître).
  - [^] # Re: Erreur d'interpretation sur l'API reseau
    
    Posté par windu.2b le 15 décembre 2009 à 12:42. Évalué à 4.
    
    Je pense qu'il veut parler de ce passage-là :
    "It is even possible for an enum variable to hold an integer that does not represent any of the enumeration values."
    En gros, on pourrait y foutre n'importe quel 'int', vu qu'on peut mixer les 'enum' et les 'int' sans problème (belle connerie, selon moi).
    - [^] # Re: Erreur d'interpretation sur l'API reseau
      
      Posté par patrick_g (site web personnel) le 15 décembre 2009 à 13:14. Évalué à 7.
      
      OK mais si c'est bien ça que Littleboy veut dire alors ce n'est pas le sujet.
      
      Avant le type était int et les devs des pilotes étaient tentés de renvoyer n'importe quel code d'erreur puisque le type était int. Ils croyaient que c'était permis.
      
      Maintenant le type est enum et tous les pilotes qui renvoyaient de la merde ont été changés. Maintenant les devs des pilotes, en voyant le type enum, ne seront plus tentés de renvoyer des codes d'erreurs arbitraires (même si techniquement ils peuvent encore le faire). Le but c'était de présenter une meilleure API aux auteurs de pilotes. Une API moins ambiguë.
      - [^] # Re: Erreur d'interpretation sur l'API reseau
        
        Posté par windu.2b le 15 décembre 2009 à 14:42. Évalué à 4.
        
        Je suis d'accord avec toi sur le but recherché avec cette nouvelle API, mais on ne peut pas nier qu'il a raison de dire que ceux qui voudront faire de la merde et renvoyer n'importe quoi (comme avant) pourront toujours le faire, malheureusement...
        
        [^] # Re: Erreur d'interpretation sur l'API reseau
        
        Posté par kikicnrv le 15 décembre 2009 à 18:28. Évalué à 5.
        
        > (...) ceux qui voudront faire de la merde (...)
        En tenant compte du contexte (développement de pilote pour le noyau) je pense qu'on admettre que les développeurs ne veulent pas faire de la merde mais qu'ils se sont juste gourés, ce que la modification su-citée devrait permettre d'éviter.

Suivre le flux des commentaires

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