Sortie du noyau Linux 2.6.24

Posté par (page perso) . Modéré par Pascal Terjan.
0
25
jan.
2008
Noyau
Après un cycle de développement inhabituellement long la sortie de la vingt-cinquième version stable de la branche 2.6 du noyau Linux vient d'être annoncée. Le code source du noyau est maintenant téléchargeable sur les serveurs du site kernel.org.

  • Cette version 2.6.24 se caractérise essentiellement par l'ampleur des changements, en terme de lignes de codes, avec la version précédente. Le 23 octobre, dans son mail d'annonce de la RC-1, Linus écrit :
    Cela doit être l'une des plus grosses versions candidates de tous les temps. C'est monstrueux. D'habitude, pour la RC-1, la taille du fichier compressé des différences est de l'ordre de 3 à 5 Mo. Certains sont plus petits que ça et on a occasionnellement des pointes à 6 Mo. Celle-ci fait *onze* méga-octets.
    En bref nous avons juste eu un grand nombre de merges, et pas seulement pour x86 mais aussi des tonnes de nouveaux pilotes (surtout pour le wifi mais pas seulement - dvb, réseau classique, mmc..etc) ainsi qu'une bonne quantité de travail sur les diverses architectures, les systèmes de fichiers, le réseau etc.
    Donc il y a juste beaucoup de nouvelles choses.
  • En dépit de ces nombreux changements le cycle des versions candidates n'a pas été excessivement douloureux. Le 6 novembre Linus a annoncé la RC-2 :
    Ouais, ne m'en parlez-pas - c'est en retard. Il n'y a rien eu de particulier pour retenir cette version aussi longtemps. J'ai juste simplement oublié de faire une RC-2 la semaine dernière. Il n'y a pas beaucoup de trucs vraiment excitants ici. Des mises à jour d'architectures : MIPS, arm, blackfin, x86, sparc64, sh, s390. Également des mises à jour de pilotes : libata, IDE, réseau, DVB. Rien de vraiment révolutionnaire dont je puisse me souvenir. La liste des modifications est encore trop grosse pour la limite de la liste de diffusion mais, franchement, ce n'est pas du Tolstoï. Si vous avez des problèmes pour vous endormir vous pouvez essayer de l'imprimer et de la prendre au lit avec vous.
  • La RC-3, apparue le 16 novembre, a vu, en plus de beaucoup de petites corrections, la touche finale au processus de fusion des branches i386 et x86-64 qui constitue l'une des grandes nouveautés du noyau 2.6.24 :
    En plus des autres mises à jour il y a également le dernier nettoyage du patch d'unification. Le reste peut attendre après le 2.6.24 mais avec ce dernier patch la configuration x86 est vraiment fusionnée et les architectures i386 et x86-64 sont vraiment juste des cas spéciaux de l'architecture globale "x86" lors de la configuration.
  • La RC-4 n'a été annoncée que le 3 décembre par Linus :
    Nous devrions avoir seulement une semaine entre chaque version candidate mais, à l'occasion de Thanksgiving, j'étais parti pour une semaine (comme certains autres développeurs du noyau) ce qui fait que celle-ci est un peu en retard.
    Comme d'habitude, c'est devenu rituel lors des cycles de développement, il a ensuite protesté devant le grand nombres de patchs qui continuent d'arriver alors que le noyau devrait être en mode stabilisation :
    La différence par rapport à la RC-3 est de presque de 36000 lignes (...) Je vais blâmer la période de deux semaines qui s'est écoulée mais, même en tenant compte de ce délai, c'est un peu décourageant. J'espère vraiment que nous allons ralentir et que la RC-5 ne sera pas aussi grosse. Ceci dit aucun des changements n'est vraiment excitant ou vraiment effrayant.
  • Une semaine pile après la version candidate précédente voici la RC-5 :
    Cela fait une semaine et comme j'ai promis d'être un bon garçon et d'essayer de suivre mes propres règles de sortie, voici la version candidate suivante.
    Les choses ont ralenti mais je mentirais si je disais que nous avons toutes les régressions bien en main et sous contrôle. C'est en cours de résolution et la liste diminue mais, si je devais deviner, nous ne pourrons certainement pas avoir un 2.6.24 avant Noël sauf si le père Noël met un peu plus d'elfes pour travailler sur ces régressions.
    Donc pour tous les elfes là dehors, merci de continuer à bosser.
  • Malheureusement le père Noël n'a pas été coopératif et Linus, dans l'annonce de la RC-6, a reconnu que la nouvelle cible était début janvier :
    La liste des régressions continue à se réduire donc nous sommes dans les clous pour une sortie du 2.6.24 début janvier... en supposant que nous ne fassions pas trop d'excès de boustifaille pendant les vacances et que les gens continuent à bosser. Mais nous savons tous que les vacances sont le moment où on peut couper avec l'ennuyeux "travail réel" et enfin passer 24 heures sur 24 à hacker le noyau n'est-ce pas ?
  • Après le break des vacances Linus a annoncé la sortie de la version RC-7. Cette dernière consiste principalement en de multiples petites corrections et le changement par rapport à la RC-6 n'est pas énorme. Linus l'a expliqué à sa façon à lui :
    Je vais être charitable et prétendre que c'est parce que les choses se stabilisent et pas parce que nous avons tous été perdus dans les brumes de l'alcool durant les vacances
  • La seconde hypothèse s'étant révélée être la bonne il a été nécessaire d'ajouter une RC-8 pour corriger divers petits problèmes de dernière minute :
    Je déteste faire des RC pendant si longtemps, mais je déteste encore plus annoncer une sortie quand je sens que les choses n'ont pas mitonné suffisamment.

Vous trouverez plus de détails sur les nouveautés dans la suite de cette dépêche.
  • La fonction d'ordonnancement de groupe, qui a été évoquée lors de la sortie du précédent noyau, est maintenant intégrée dans cette version. Cela permet à l'ordonnanceur de nouvelle génération CFS de gérer plus finement l'allocation des ressources de calcul aux différents processus s'exécutant sur la machine. Avec l'ordonnancement de groupe on peut diviser à volonté le temps processeur selon deux politiques : Soit entre les utilisateurs soit entre les groupes de tâches.
    • La première option (sélectionnable avec CONFIG_FAIR_USER_SCHED) divise le temps processeur entre les différents utilisateurs d'une machine. Celui qui lance 30 processus ne sera plus avantagé par rapport à celui qui n'en lance qu'un seul et chacun des deux utilisateurs aura équitablement la moitié du temps de calcul. Un avantage additionnel relevé par Ingo Molnar est que cela limite drastiquement les risques de Fork Bomb.
    • La seconde option (sélectionnable avec CONFIG_FAIR_CGROUP_SCHED) divise le temps processeur entre différents groupes de tâches. La documentation décrit très bien cette nouvelle fonction : on peut par exemple créer le groupe "multimédia" et le groupe "bureautique" et décider que le premier groupe aura 75 % du temps de calcul alors que le second n'aura que 25 %. L'administrateur a ainsi a sa disposition un outil très souple pour créer tous les groupes qu'il désire et y rattacher les processus à volonté.
    En plus de cet enrichissement fonctionnel apporté par l'ordonnancement de groupe, CFS a également été amélioré sur le plan de la taille du code et de la rapidité. L'empreinte mémoire du code compilé a été réduite puisqu'on passe de 29 145 octets à 26 666 octets (-8,5 %) sur un système multiprocesseur et de 15 633 octets à 13 379 (-14,4 %) sur un système mono-processeur. Cette réduction de taille est cruciale pour le monde de l'embarqué ou Linux est devenu un système incontournable. Diverses micro-optimisations ont également permis de réduire les latences de l'ordonnanceur. Ingo Molnar a mesuré ces latences à l'aide de l'outil lmbench : le noyau 2.6.22 (ne contenant pas CFS) atteignait 0,64 microsecondes. Le noyau 2.6.23 (contenant la première version de CFS) avait régressé à 0,72 microsecondes (+12 %). Le nouveau noyau 2.6.24 et son code optimisé permet de redescendre à 0,62 microsecondes (soit -3 % par rapport à l'ordonnanceur non équitable d'ancienne génération). On voit donc que le caractère complètement équitable et extrêmement robuste du nouvel ordonnanceur CFS n'aura rien coûté en performances.

  • Pour permettre, entre autre, l'ordonnancement de groupe le noyau 2.6.24 propose l'infrastructure Control Group. Elle permet de définir de façon très générique des groupes de contrôle (ou cgroups) afin de gérer les ressources disponibles de la machine et de définir des quotas d'utilisation. L'administrateur utilise les cgroups pour créer des hiérarchies de processus au travers, comme c'est l'habitude sous Linux, d'un système de fichier virtuel se trouvant dans /dev/cgroup. Ces cgroups associent des listes de tâches avec des listes de paramètres pour les divers gestionnaires des ressources (les processeurs, les utilisateurs, les disques, le réseau, etc.).
    Pour simplifier évoquons un exemple (tiré directement de la documentation) : l'administrateur du serveur d'une université désire gérer finement les ressources de sa machine. Il crée donc deux cgroups, l'un pour les professeurs et l'autre pour les étudiants. Une fois que c'est fait l'administrateur peut utiliser la nouvelle infrastructure Control Group afin de définir des quotas et des limites pour chaque groupe. Par exemple, 50 % de la mémoire pour les professeurs, 30 % pour les étudiants et le reste pour le système. Observez sur le schéma ci-dessous l'application d'une hiérarchie des quotas pour les ressources réseau. La navigation web a une allocation de 20 % de la bande passante qui est elle-même divisée inégalement entre professeurs et étudiants.
               /         \
    
    cgroup1 cgroup2
    | |
    (Profs) (Etudiants)
    Mémoire : Profs (50%), étudiants (30%), système (20%)
    Disques : Profs (50%), étudiants (30%), système (20%)
    Réseau : navigation web (20%), accès par NFS (60%), autre (20%)
    / \
    Prof (15%) étudiants (5%)

    Cette nouvelle infrastructure de quotas et de groupes de contrôle est utilisée par CFS pour l'ordonnancement de groupe des processus évoqué plus haut. Ainsi CFS évite de dupliquer du code et profite du mécanisme générique se trouvant dans le nouveau noyau.

  • L'unification des architectures i386 et x86-64 est réalisée pour la première fois au sein du noyau 2.6.24. Quand on regarde le code source de Linux on constate que le répertoire arch contient le code spécifique aux divers processeurs qui sont supportés par le noyau (PowerPC, i386, ARM, SPARC, etc.). Ce nombre de sous-répertoires est important (plus de 25 architectures différentes) et les développeurs ont intérêt à essayer de fusionner au maximum ce qui peut l'être afin de partager le plus de code possible. Comme il existe de nombreuses ressemblances entre les i386 et les x86-64 (essentiellement l'architecture passe de 8 à 16 registres et ces registres passent de 32 à 64 bits) un projet de fusion a vu le jour. Actuellement une correction de bug sur l'une des branches doit être dupliquée sur l'autre. Quand une nouveauté est introduite, il faut l'incorporer à l'autre branche, etc. Ce processus de double maintenance est très lourd et provoque de nombreuses erreurs. La décision a donc été prise de faire comme pour l'architecture PowerPC : les variantes 32 et 64 bits ont fusionné à l'occasion de la sortie du noyau 2.6.15 et, avec le recul, cela s'est avéré être une très bonne décision.
    Thomas Gleixner et Ingo Molnar, dans un mail très argumenté, ont donc proposé un méga patch (près de 2 000 fichiers sont impactés) qui renomme tous les fichiers spécifiques avec le suffixe _32 ou _64 et les déplace dans le nouveau répertoire unifié x86. C'est une sorte de "Big Bang" au niveau des répertoires de arch mais cela ne change rien au niveau du code lui-même. De cette façon le travail d'unification, qui a déjà commencé, peut se faire progressivement (en fusionnant les fichiers toto_32.C et toto_64.c en un unique toto.c) avec chaque nouvelle version du noyau.
    Cette décision a néanmoins provoqué une controverse car Andi Kleen, le mainteneur de la branche x86-64, n'était pas d'accord avec l'unification. Il a défendu son point de vue sur la liste de diffusion :
    Vous connaissez ma position à ce sujet. Je pense que c'est une mauvaise idée car cela signifie que nous ne pourrons jamais plus nous débarrasser des vieilleries. La branche arch/x86_64 est significativement plus propre et plus simple que arch/i386 et je voudrais préserver cela. [...] Ce n'est pas vraiment la même plate-forme : l'une est une architecture PC remontant à la nuit des temps et contenant des zillions de bugs, l'autre est une plate-forme PC moderne avec bien moins de bugs et de bizarreries.
    Linus n'était pas de cet avis:
    Je pense qu'il est *bien* plus difficile de gérer ce genre d'héritage dans un vieux répertoire que presque personne n'utilise (ce n'est probablement pas vrai à l'heure actuelle mais, pour la plupart des développeurs, je parie que cela sera vrai dans un an). Spécialement si ce vieux répertoire se contente de dupliquer 99% du boulot. Il n'y a pas tant de vieilleries que ça. Il y a certes des choses bizarres ici et là, mais chaque fois que j'entends l'argument (théorique) selon lequel nous économiserions du temps et des efforts en ayant ce code dupliqué ailleurs je pense à tout le temps que nous perdons réellement en corrigeant le même bug deux fois (et je m'inquiète pour les fois ou nous ne le faisons pas).
    Andi n'a pas été convaincu par Linus et il a décidé de ne pas assurer la maintenance de la nouvelle branche fusionnée x86. Les nouveaux mainteneurs sont donc Thomas Gleixner, Ingo Molnar, et H. Peter Anvin.

  • Un changement concernant les entrées/sorties de type scatter/gather a provoqué quelques soucis dans le nouveau noyau. La technique de scatter/gather permet d'utiliser un seul appel système pour écrire séquentiellement des données depuis plusieurs tampons mémoires ou pour lire des données dans plusieurs tampons mémoires. Ce mécanisme, qu'on pourrait traduire imparfaitement par Rassemblement/Dispersion, élimine l'obligation de copier les données dans un seul gros buffer et permet d'utiliser beaucoup de petits tampons dispersés. Cela permet d'augmenter les performances et d'éviter d'avoir à créer un gros buffer d'une seule pièce (ce qui est parfois difficile). La technique scatter/gather est très efficace et pratique puisqu'une seule instruction permet de faire plusieurs choses simultanément. Cela explique pourquoi cette technique est aussi connue sous le nom d'entrées/sorties vectorielles. La liste des multiples tampons est présente dans un tableau mais celui-ci ne peut pas excéder la taille d'une page mémoire. Afin de faire sauter cette limitation contraignante le noyau 2.6.24 a introduit la possibilité de chaîner ces listes. Le but est d'augmenter encore les performances d'entrées/sorties mais ce changement a été douloureux et a provoqué le dysfonctionnement de plusieurs pilotes. Jonathan Corbet a même indiqué que
    le chaînage des listes scatter/gather a sans doute été le changement le plus problématique du noyau 2.6.24, en dépit du fait qu'il s'agit d'un nombre réduit de lignes de code
    L'API scatter/gather doit aussi encore être améliorée afin de simplifier son utilisation. Deux directions sont envisagées pour inclusion dans le noyau 2.6.25 afin d'avoir une API qui permette d'écrire plus facilement à l'avenir du code haute-performance.

  • Le support de l'espace de noms pour les processus fait son entrée dans le nouveau noyau.
    Cette fonction est liée à la problématique de la création de conteneurs afin de pouvoir exécuter des applications dans des boites virtuelles séparées. Le concept est similaire aux Jails de FreeBSD ou aux Zones de Solaris et cela permet de renforcer la sécurité en élevant des barrières étanches entre les divers processus tournant sur une machine. Pour cela il est nécessaire de masquer toutes les ressources globales du noyau (systèmes de fichiers, identifiants des processus, interfaces réseaux etc.) derrière une couche d'abstraction. Ainsi chaque conteneur pourra avoir sa propre vue des ressources globales et il s'exécutera normalement, c'est à dire sans conflit avec les autres conteneurs. Le noyau 2.6.24 propose ainsi un espace de noms qui permet d'attribuer le même identifiant (le PID) à des processus qui sont dans différents conteneurs. Il devient alors facile de migrer ce conteneur d'un ordinateur à l'autre sans rencontrer des problèmes de conflit d'identifiants.
    Pour créer un nouvel espace de noms on utilise l'appel système clone avec le flag CLONE_NEWPID. Comme l'espace de nommage est hiérarchique le premier processus à se lancer aura le PID 1 et quand ce premier processus se terminera alors tout l'espace de nommage se terminera également (en fait il joue un peu le rôle d'init sur une machine classique). Le pseudo-système de fichier procfs devra être monté autant de fois qu'il y a d'espaces de noms et on pourra ensuite utiliser la commande ps à l'intérieur de ces instances de procfs pour lister les processus tournant dans le conteneur.
    Il est à noter que ce travail de masquage des ressources globales du noyau n'est pas encore terminé. Le support de l'espace de noms pour les interfaces réseaux, qui s'utilise avec le flag CLONE_NEWNET et qui permet aux conteneurs d'avoir chacun une vue différente de la pile réseau, a fait son entrée dans ce noyau 2.6.24 mais toutes les fonctions ne sont pas implémentées. De même ce support de l'espace de noms pour les processus est pour l'instant encore marqué comme "expérimental" afin de prévenir les développeurs que l'interface de programmation est susceptible de changer. La finalisation définitive de l'API est prévue pour la version 2.6.25 et elle pourrait bien annoncer le début de la fin pour les patchs externes du type Vserver. Quand tout ces mécanismes de gestion de conteneurs seront inclus dans la branche principale, Linux possédera une solution plus puissante et plus générique que ses concurrents. On peut noter à titre d'exemple que les Zones de Solaris ne possèdent pas d'espace de noms pour le réseau.

  • L'interface Virtio qui permet de proposer aux différentes solutions de virtualisation une couche commune pour gérer les entrées/sorties a été développée par Rusty Russell et le patch a été inclus dans le nouveau noyau Linux. Comme il existe plusieurs solutions de virtualisation utilisables avec Linux (Xen, Lguest, KVM, etc.) il est apparu nécessaire de chercher à mutualiser une partie du code et à proposer une couche d'abstraction pour éviter une divergence des outils. Virtio est une interface virtuelle qui permet de gérer les entrées/sorties et évite ainsi la prolifération anarchique des pilotes virtuels. Interrogé sur l'utilité réelle de Virtio, Rusty a répondu que :
    personne ne veut maintenir cinq pilotes virtuels différents pour le réseau, cinq pilotes virtuels différents en mode bloc, etc. En fait à un moment la communauté du noyau va se rebeller [...] Nous pouvons donc au moins simplifier pour chaque technologie de virtualisation le fait d'implémenter le nouveau périphérique XYZZY.
    Virtio reste volontairement simple car la technique de virtualisation des entrées/sorties change rapidement et il ne faut pas que cette nouvelle interface devienne un facteur limitant par la suite...ou comme le dit plus brutalement Rusty:
    Of course, the new interface must not suck.
  • La gestion dynamique des tranches de temps pour l'architecture x86-64 et pour l'architecture PPC fait maintenant partie du code du noyau Linux. Cette technologie est apparue dans le noyau 2.6.21 mais elle était jusqu'à présent réservée aux processeurs i386 et aux SPARC64. Elle permet (quand on utilise l'option CONFIG_NO_HZ) d'éviter d'avoir une fréquence fixe de "réveil" du processeur et donc de le laisser plus longtemps dans des modes d'économie d'énergie. Cela se traduit par moins de chaleur dissipée et plus de durée d'utilisation pour les ordinateurs portables (c'est également intéressant pour la gestion des machines virtuelles). Les nombreux utilisateurs de distributions x86-64 peuvent donc maintenant découvrir les bienfaits d'un noyau "tickless".

  • le support de la norme Secure Digital Input Output fait son entrée au sein du code permettant de gérer les cartes mémoires MMC et SD. Cette modification autorise le branchement sur un port SD de divers gadgets: Récepteurs GPS, adaptateurs Wi-Fi ou Bluetooth ou Ethernet, Lecteurs de code-barre, Tuners FM ou TV, Appareils photos, etc.
    Pierre Ossman, qui est le mainteneur officiel du sous-système MMC/SD, a annoncé que trois pilotes SDIO étaient déjà inclus dans le noyau et que le travail continue pour inclure de nombreux autres pilotes. Néanmoins il tient à avertir les développeurs que son implémentation de SDIO force à écrire proprement le code des pilotes :
    Cette implémentation oblige à une stricte séparation des couches et masque tous les détails du protocole. Cela pourra en ennuyer certains qui voulaient porter plus facilement les pilotes entre différentes implémentations mais je crois que le résultat final sera un système bien plus robuste au lieu de n'être qu'une collection de hacks et de bidouilles.
  • L'infrastructure Kernel Markers est maintenant en place dans le noyau 2.6.24. Depuis plusieurs mois les développeurs ont entrepris d'améliorer les fonctions de tracing, c'est à dire d'enregistrement d'informations lors de l'exécution de la machinerie interne de Linux. Ce "tracing" est très important pour diagnostiquer d'éventuels problèmes et pour régler finement les performances du noyau. La société Sun propose l'outil Dtrace dans son système d'exploitation Solaris et la sophistication de cet outil a provoqué un très grand intérêt dans le monde informatique au point que le projet FreeBSD a décidé de porter Dtrace vers son propre environnement. La puissance du logiciel de Sun a provoqué un sentiment d'envie chez les développeurs Linux qui, pour revenir à parité, ont accéléré leurs efforts. Le premier résultat est Kernel Markers qui permet d'insérer des points de contrôles statiques dans le noyau. Le fait que ces points soient statiques est important car cela leur permet d'être insensibles aux modifications de code qui les rendraient obsolètes à très court terme et cela rend négligeable leur impact sur les performances. Maintenant que cette infrastructure est en place les outils concurrents de Dtrace (comme SystemTap ou LTTng) vont pouvoir s'appuyer dessus pour devenir compétitifs.

  • Une autre nouveauté de ce noyau est le mécanisme d'autorisation des périphériques USB. Dans un futur proche la nouvelle norme Wireless USB (c'est à dire le branchement des périphériques par ondes radio) va faire son apparition. Cela pose évidemment un problème de sécurité nouveau qu'il faut résoudre dès maintenant. Actuellement quand un utilisateur branche par exemple un disque dur USB le noyau suppose que ce périphérique est autorisé et il est automatiquement configuré et rendu disponible. Avec le WUSB et ses connexions sans fil à distance il faut mettre en place un mécanisme d'authentification similaire au WPA qui existe pour les réseaux Wi-Fi. La spécification WUSB a pris en compte ce problème et le noyau 2.6.24 implémente maintenant ce mécanisme qui permettra d'éviter que votre voisin puisse se connecter sur votre disque dur WUSB tout neuf. Pour entrer un peu plus dans les détails la partie authentification est laissée à un programme en espace utilisateur alors que la partie autorisation relève du noyau. Cela permet de bien séparer les fonctions et d'éviter de faire entrer dans le noyau un grand nombre de lignes de code qui peuvent tout aussi bien rester à l'extérieur. Maintenant chaque périphérique USB a trois flags supplémentaires: wusb, authorized, et authenticated et l'administrateur de la machine peut changer librement la valeur de ces flags. On voit immédiatement le profit pour la gestion des périphériques USB classiques qui peut être tiré de cette infrastructure introduite pour accueillir le Wireless USB. Par exemple maintenant un administrateur peut décider que les souris et les claviers sont autorisés (en leur passant le flag authorized à 1) alors que les imprimantes et les périphériques de stockage sont interdits (valeur 0 dans leur flag). Ce mécanisme d'autorisation introduit donc beaucoup de souplesse dans la gestion fine des périphériques sous Linux.

  • Le patch permettant le réglage intelligent de la vitesse d'écriture a été intégré au noyau. Avant ce patch l'écriture sur un disque se passait de la façon suivante: Une application voulant écrire des données utilise la fonction write() et le noyau copie ces données dans la mémoire vive en mettant un flag "dirty". Ce flag signifie que ces pages mémoire ne doivent pas être réutilisées tant que le disque dur n'aura pas effectivement écrit toutes les données. Le danger c'est que l'application continue d'écrire dans la mémoire plus rapidement que le disque ne peut absorber. La conséquence c'est que de plus en plus de pages mémoires deviennent "dirty" ce qui peut, dans des cas extrêmes, mettre en danger la stabilité de la machine qui n'aurait plus assez de mémoire vive. Pour éviter cette fâcheuse situation le noyau contrôle en permanence la quantité totale de pages "dirty" et, en cas de besoin, il force le processus à écrire directement sur le disque (ce qui est lent) au lieu d'écrire dans la mémoire. Jusqu'à présent ce mécanisme de contrôle n'était pas intelligent et il forçait tous les processus à ralentir ! Ainsi une clé USB très lente, ne pouvant donc pas absorber assez vite les pages "dirty", va entraîner le déclenchement par le noyau du processus de contrôle ce qui va ralentir tous les processus écrivant sur des périphériques.
    Peter Zijlstra a donc proposé un patch qui permet un contrôle pour chaque disque (et non plus global). Ainsi quand le contrôle de vitesse se déclenche pour le processus écrivant sur la clé USB, les autres processus, ceux qui écrivent sur des disques rapides, peuvent continuer à remplir des pages "dirty" dans la mémoire vive. Bien entendu la partie difficile de cette solution est d'arriver à déterminer le moment exact où doit se déclencher le contrôle autoritaire. Pour bien faire les choses un processus écrivant sur un disque rapide devrait avoir droit à plus de pages "dirty" qu'un autre écrivant sur un périphérique lent et le contrôle ne devrait pas se déclencher avec le même seuil. Pour prendre ces décisions délicates Peter Zijlstra a introduit la bibliothèque "Floating Proportions". Cette dernière permet de suivre le nombre d'écritures effectives sur chaque disque et d'accorder des quotas de pages "dirty" en fonction de ces résultats. Ce réglage intelligent de la vitesse d'écriture permet ainsi d'améliorer les performances et la robustesse des entrées/sorties sous Linux.

  • Outre les nouveautés décrites ci-dessus, une multitude d'autres nouveautés sont présentes dans ce noyau.
    • De très nombreux pilotes Wi-Fi utilisant la nouvelle pile mac80211 (introduite dans le 2.6.22) entrent enfin dans la branche principale. Cela représente 2,3 Mo de code source ce qui donne une indication du nombre de pilotes. On trouve notamment celui de la carte Intel PRO/Wireless 3945ABG/BG ou encore de la carte Broadcom BCM43xx.
    • Après la correction de quelques problèmes de jeunesse le nouvel allocateur de mémoire SLUB, inclus dans le noyau 2.6.22, a été optimisé par Christoph Lemeter. On observe un gain de 10 à 20% quand l'allocation est de la même taille que la page mémoire et de 50% quand la libération est de la même taille que la page mémoire.
    • Pour des raisons de sécurité il n'est plus possible de charger des modules à chaud par l'intermédiaire de l'interface LSM. Les modules de sécurité devront donc être inclus lors de la compilation du noyau (ce qui va évidemment poser des problèmes aux firmes diaboliques qui utilisaient LSM pour brancher leurs modules propriétaires).
    • Toujours dans le domaine de la sécurité l'algorithme de chiffrement symétrique SEED, très répandu en Corée, est inclus dans le noyau.
    • L'allocation de port pour les protocoles UDP et SCTP se fait maintenant de façon non prévisible comme c'était déjà le cas avec TCP et ce afin de renforcer la sécurité.
    • Les disques SATA utilisent désormais par défaut la gestion de l'économie d'énergie par ACPI (même si le commentaire lapidaire et humoristique du commit laisse craindre le pire ;-)
    • Le patch LRO (Large receive offload) permet d'agréger les multiples paquets TCP reçus en un seul gros paquet ce qui permet de réduire le travail de la pile réseau et donc d'augmenter les performances de la machine. Les pilotes réseau seront modifiés progressivement pour tirer partie de cette nouvelle fonction.
    • L'API de la couche d'abstraction des systèmes de fichiers (VFS) a été modifiée afin d'éviter un risque d'interblocage. Les mainteneurs de systèmes de fichiers qui ne sont pas dans la branche principale de Linux vont devoir, à moyen terme, adapter leur code.
    • Le système de fichiers CIFS inclus dans le noyau devient compatible avec les listes de contrôle d'accès (ACL).
    • Il est maintenant possible d'utiliser la fonction de multiplicateurs de ports de la norme SATA. Cela permet à plusieurs disques d'utiliser simultanément le même port SATA.
    La liste détaillant toutes les nouveautés (réseaux, systèmes de fichier, pilotes disques, cartes son, vidéo, Bluetooth, etc.) est disponible sur le site de Kernelnewbies.

Comme c'est devenu l'usage le site Linux Weekly News propose un article résumant les multiples contributions durant ce cycle. On apprend ainsi que le plafond des 10000 patchs a été dépassé (seulement 6200 patchs pour le 2.6.23) et que le nombre de contributeurs a été de 950 contre 860 pour le noyau précédent. Si on regarde le bilan global de l'année 2007 ce sont plus de 1900 développeurs qui sont intervenus sur le noyau en produisant plus de 30000 patchs (ce qui représente 5000 modifications de lignes de code par jour).
De nombreuses autres statistiques très intéressantes sont également présentes dans cet article et la conclusion est rassurante à lire :
L'image qui résulte de tous ces chiffres est celle d'une communauté de développement saine et diversifiée. Le noyau est vraiment une ressource commune avec littéralement des milliers de personnes qui travaillent pour l'améliorer. Et il ne montre aucun signe de ralentissement de sitôt.

Pour la suite...
En ce qui concerne le futur du noyau Linux on peut se tourner vers la page spécifique maintenue par Jonathan Corbet.
  • L'outil de tracing utrace, qui était pressenti pour faire son entrée dans le 2.6.24, a été retardé mais il devrait être présent dès la prochaine mouture de Linux.
  • Le module de sécurité SMACK (Simplified Mandatory Access Control Kernel), qui est développé par Casey Schaufler, pourrait entrer en mainline et faire concurrence à SELinux en proposant moins de fonctions mais une configuration bien plus simple. Casey propose régulièrement des mises à jour de version qui intègrent la branche de test -mm sans problèmes ce qui est de bon augure pour le futur de ce module.
  • Le système de fichier de nouvelle génération ext4 continue sa phase de développement et il incorpore de nouvelles fonctions. Cette fois-ci c'est UBG (uninitialized block groups) qui est annoncé. Cela consiste à contrôler si un bloc disque a été initialisé ou pas. Si le bloc n'a jamais été utilisé alors le programme fsck n'aura pas besoin de le vérifier lors de son passage suivant. Cela permet potentiellement de gagner beaucoup de temps lors du boot (entre 2 et 20 fois plus rapide) quand on doit procéder à l'examen d'un disque.
  • Le support des bus de données de type CAN (Controller Area Network) est en cours de développement par des ingénieurs de la société Volkswagen. Cette nouvelle infrastructure PF_CAN devrait faire son entrée dans le noyau 2.6.25 ou 2.6.26 et faciliter ainsi l'utilisation de Linux au sein de l'industrie automobile .
  • Enfin le vieux serpent de mer du débogueur interactif intégré au noyau refait surface. Selon les prévisions de Jon Corbet il y a une chance non nulle qu'en dépit de la mauvaise volonté de Linus, qui n'aime pas les débogueurs intégrés (voir le fameux post "because i'm a bastard"), le patch KGDB puisse faire partie du prochain noyau 2.6.25.
  • # bravo

    Posté par (page perso) . Évalué à 10.

    Comme d'habitude, c'est riche d'informations, clair, synthétique.
    Une dépêche de très grande qualité comme on aime les lire :-)
    • [^] # Re: bravo

      Posté par . Évalué à 10.

      Bref : du "patrick_g" comme à son habitude !
      Encore bravo pour cette dépêche :-D
      • [^] # Re: bravo

        Posté par . Évalué à 10.

        Nan, mais faudrait arrêter ce genre de news sur ce site pour plusieurs raisons :
        - avec des news aussi claires, détaillées, et rapides (annonce sur le site kernel.org le 24, news sortie sur ce site le 25), linuxfr pourrait devenir un site d'information incontournale, et en plus, on pourrait y apprendre des choses.
        - patrick_g place la barre extrémement haute, ce qui pourrait en rebuter certains... Il y a a mon avis trop de travail fourni sur cette news, une fois de plus, et c'est à se demander si patrick_g est humain, et si il dort la nuit.
        - enfin, avec ce genre d'article aussi détaillé, bien rédigé, et complet, on arriverai presque à apprécier les news cinéma !



        Bon, blague à part, c'est évidement un énorme travail (celui des développeurs du kernel bien sûr, mais aussi celui du (des) rédacteur(s), des relecteurs et des modérateurs de ce site) que je voulais saluer à mon tour, j'espère que vous l'aurez compris.
        • [^] # Re: bravo

          Posté par (page perso) . Évalué à 5.

          « une fois de plus, et c'est à se demander si patrick_g est humain, et si il dort la nuit. »

          Je crois que le cycle de développement de la version .24 lui a laissé le temps de préparer tout ça. KernelTrap et LWM sont également d'excellentes sources pour suivre le développement !

          Attention, j'applaudis également patrick_g des deux mains, je ne cherche pas à dénigrer son travail. Je voulais juste expliquer qu'on peut arriver à son niveau en dormant la nuit.

          Comme exercice, je vous laisse préparer les dépêches pour les sorties de Firefox3 et d'Hurd 1.0.
          • [^] # Re: bravo

            Posté par (page perso) . Évalué à 10.

            Ces news sur le noyau sont basées presque uniquement sur kernelnewbies et sur les nombreux articles de LWN.
            Moi je ne fais que de la compilation des informations, de la reformulation/explication/vulgarisation et de la traduction.
            J'ai rédigé au fil de l'eau sur une durée d'un mois environ. Ensuite je l'ai posté sur le site le 03 janvier et depuis il n'y a eu que des petites corrections et quelques ajouts.
            • [^] # Re: bravo

              Posté par . Évalué à 10.

              "Moi je ne fais que de la compilation des informations"
              Tant de modestie en un seul homme, c'est pas humain... :-D
              • [^] # Re: bravo

                Posté par (page perso) . Évalué à 10.

                C'est pas de la modestie, c'est la réalité.
                Je ne suis pas un codeur donc aucune des infos de cette news n'est de première main. Le boulot que je fais c'est juste de reformuler les infos se trouvant sur le net.
                Certes je reconnais que cela représente pas mal de travail d'essayer de faire une news la plus complète et la plus compréhensible possible. Mais le fait de devoir rédiger m'aide moi même à comprendre ce dont il s'agit (sur le scatter/gather j'ai pas mal galéré) et c'est donc bénéfique pour moi aussi.

                Et puis ne pouvant contribuer par du code au logiciel libre j'essaye d'aider autrement.
      • [^] # Re: bravo

        Posté par . Évalué à 9.

        Moi je propose que patrick_g devienne officiellement en charge des news kernel sur linuxfr.

        Clair, concis, c'est tellement bon qu'on en redemande.

        Merci Patrick
        • [^] # Re: bravo

          Posté par . Évalué à 9.

          "c'est tellement bon qu'on en redemande. "
          Transmis aux dév. du Kernel, qui m'ont promis de plus mettre 3 mois à sortir une nouvelle version :-p

          Nanmého!!!
        • [^] # Re: bravo

          Posté par . Évalué à 10.

          moi je propose la création d'un fork de linuxfr :

          linuxfr.org pour continuer à troller
          patrick_gfr.org pour s'informer ;)

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: bravo

          Posté par (page perso) . Évalué à 6.

          J'ai eu le privilège (je suis relecteur) de voir dans l'espace de modération cet article qui y attendu fort longtemps la sortie du noyau 2.6.4. J'ai ainsi eu tout loisir de le lire il y a plusieurs semaines et j'en connaissais l'excellence.

          Cet article représente plusieurs jours de travail. Patrick, as-tu estimé le temps que tu as pu passer à faire cet article ?

          Remarque : nous sommes tous invités à écrire des articles sur Linuxfr. Il faut en prendre le temps et avoir la patience de bien le peaufiner avant de l'envoyer.
          Il est dommage de devoir refuser des articles mal rédigés alors que le sujet est intéressant. Cela nous arrive trop souvent. Certes, nous pouvons corriger quelques fautes d'orthographe ou refaire une phrase mal fichue, mais quand l'article est rempli de sigles et de franglais, que la première phrase ne permet pas de savoir de quoi il s'agit et que le contenu n'explique pas l'intérêt du sujet, nous ne pouvons pas tout reconstruire.
          • [^] # Re: bravo

            Posté par (page perso) . Évalué à 10.

            >>> Patrick, as-tu estimé le temps que tu as pu passer à faire cet article ?

            Non pas vraiment. Mais j'aime faire ces news noyau donc je ne compte pas ;-)
    • [^] # Re: bravo

      Posté par (page perso) . Évalué à 6.

      Je sais que ça a déjà été dit, mais tant pis, je me joint à l'ovation générale pour cette dépêche, vraiment top. Merci !
    • [^] # Re: bravo

      Posté par (page perso) . Évalué à 5.

      Oui et alors ce super boulot, qu'on aime lire, parfois plus sur papier que sur écran, devrait pouvoir être imprimable via une version prévue pour...du coup c'est peut être le moment de voter massivement pour la tâche :
      https://linuxfr.org/tracker/479.html

      :-D
      • [^] # Re: bravo

        Posté par (page perso) . Évalué à 4.

        bin t'as la réponse : tout est question de CSS, tu peux trouver comment récupérer le code / contribuer pour envoyer un patch sur http://wiki.eagle-usb.org/wakka.php?wiki=SuggestionsLecteurL(...) (lire jusqu'en bas)
        • [^] # Re: bravo

          Posté par (page perso) . Évalué à 3.

          C'est bien...
          Mais j'espère que qqun d'autre s'y mettra, parceque ce n'est pas mon domaine de compétences et je suis déjà trop occuppé par d'autres projets libres pour avoir le temps d'apprendre ce que je dois savoir pour pouvoir réaliser ce patch.
    • [^] # Re: bravo

      Posté par (page perso) . Évalué à 2.

      Je me joins à tous ces gens pour féliciter Patrick pour cette dépêche très claire !
      Très bel effort de vulgarisation ! Passionnant ! Et avec quelques bonnes nouvelles :)
    • [^] # Re: bravo

      Posté par (page perso) . Évalué à 2.

      http://linuxfr.org/comments/898721,1.html

      Ça y est ... j'ai compris
  • # Patch anti-fragmentation

    Posté par (page perso) . Évalué à 7.

    Salut,

    il y a aussi un correctif pour limiter la fragmentation :
    http://kernelnewbies.org/Linux_2_6_24#head-eacf0c267f25660d4(...)

    Je suis pas un caïd du noyau, donc si quelqu'un a un complément d'info sur les avantages (ou les inconvénients) de ce patch, merci :)
    • [^] # Re: Patch anti-fragmentation

      Posté par (page perso) . Évalué à 3.

      Correctif pour limiter la fragmentation... de la mémoire :-)
      http://lwn.net/Articles/224829/

      À ce que j'ai compris, la fragmentation est surtout douloureuse lorsqu'on veut allouer une grosse zone mémoire contigüe, nécessaire pour certaines pilotes (pour les échanges par DMA ?). Comme effet de bord : on peut supprimer de la mémoire à chaud, point intéressant pour la virtualisation (du style OpenVZ ?).

      Pour info, la gestion de la mémoire sous Linux a son site web dédié !
      http://linux-mm.org/

      Le système de fichier EXT2 (et ses amis EXT3 et EXT4) ont déjà des méchanismes pour limiter la fragmentation. Plusieurs personnes m'ont assuré que si si, ça fragmente, mais peu.
  • # Very good

    Posté par . Évalué à 8.

    Excellente dépêche, bien détaillée. Merci beaucoup.
  • # Une petite correction

    Posté par . Évalué à 4.

    Tout d'abord, bravo pour la grande qualité de cette dépeche.

    Juste une petite correction mineure, il faudrait traduire 'scatter/gather' par Dispersion/Rassemblement et pas Rassemblement/Dispersion.
    • [^] # Un autre point

      Posté par . Évalué à 5.

      >le projet FreeBSD a décidé de porter Dtrace vers son propre environnement

      Le projet FreeBSD a effectivement porté Dtrace, mais par contre ils ne l'ont pas intégré dans leur dernière version car ils ne veulent pas intégré de code non BSD dans leur noyau et les header de Dtrace sont en CDDL (ils ont demandé a Sun de changer la licence des header, sans résultat).

      Après il y a eu un 'débat' avec les dev de Sun qui considèrent eux que la license de fichier header n'a pas d'importance, je ne suis pas juriste donc j'ignore qui a raison mais en tout cas FreeBSD n'a pas intégré Dtrace dans leur dernière version..

      Un autre point gênant de Dtrace est que pour profiter au maximum de Dtrace, il faut rajouter une instrumentation des interpréteurs(VM), GC, etc.
      Quand Linux aura son propre mécanisme, j'imagine que ça veut dire qu'il faudra dupliquer ce code pour avoir la même chose, <soupir/>..
      • [^] # Re: Un autre point

        Posté par (page perso) . Évalué à 5.

        Sauf que le port de Dtrace sous FreeBSD a été repris de 0 par la même personne que le premier port (sponsorisé par cisco) et ce coup ci, il devrait être intégrable dans FreeBSD.

        cf http://dtrace.what-creek.com/ et
        http://marc.info/?l=freebsd-current&m=120113328805223&am(...)
        • [^] # Re: Un autre point

          Posté par . Évalué à 2.

          Merci pour l'information, mais je me demande bien pourquoi il fait ça:
          -si je comprends bien c'est une réimplementation en BSD et plus un port du code CDDL, c'est donc une forme de 'reverse engineering' et comme c'est le même gars qui avait fait le port, il prend un risque: ce n'est clairement pas du 'clean room' reverse engineering puisqu'il avait fait le port..

          -il reste alors le problème des patentes: Sun en a sur ZFS, j'imagines que Sun en a aussi sur Dtrace et en tant que réimplementation, ce n'est plus couvert par l'accord de licence de Sun..

          Je me demande si FreeBSD va intégré la nouvelle version.

          La seule chose qui limite le risque d'attaque de Sun, c'est que du point de vue 'image', ce serait désastreux pour Sun, s'ils attaquaient le developpeur ou FreeBSD..
          • [^] # Re: Un autre point

            Posté par (page perso) . Évalué à 3.

            Non c'est le port qui est repris de 0, c'est pas du reverse engineering, c'est bien le même Dtrace qui sera disponible (et qui d'ailleurs est déjà disponible sous forme de patch pour 8-CURRENT).

            Concernant les brevets je ne sais pas ce qu'il en est, mais SUN, mais le cas de ZFS comme Dtrace a plutôt été ouvert au port sur FreeBSD, est même plutôt colaboratif sur le plan technique.
            • [^] # Re: Un autre point

              Posté par . Évalué à 2.

              Si c'est le même port, alors il n'y a pas de probleme de patente: Sun met a disposition les patentes correspondant (je sais plus si c'est intégré dans la CDDL ou si c'est un accord indépendant).

              Ce que je ne comprends pas trop, c'est que la dernière l'explication de l'arret du dev était un probleme de license, je ne vois pas comment continuer a faire du dev peut résoudre un probleme de license, bah on verra bien..
              • [^] # Re: Un autre point

                Posté par . Évalué à 6.

                Ce que je ne comprends pas trop, c'est que la dernière l'explication de l'arret du dev était un probleme de license, je ne vois pas comment continuer a faire du dev peut résoudre un probleme de license, bah on verra bien..


                On va faire simple ;-) Pour que dtrace fonctionne, il faut rajouter un peu partout du code sous CDDL, qui va "polluer" le code sous BSD du kernel. ZFS n'a pas ce probleme car c'est 1 module kernel. Pour Dtrace c'est la meme chose. Pour reprendre l'exemple de John Birrell. afin que drtace ait connaissance des etats internes au kernel, il faut rajouter un element dans la structure qui definit un thread. Et donc inclure du code CDDL dans du code 100% BSD. L'astuce du ifdef ne tient pas la ni pour des raisons legales, ni technique (ca casse l'ABI).
                Toute l'astuce du port reside dans l'isolation du code sous CDDL et donc eviter le conflit de licence. Dans le cas de la structure d'un thread, c'est de rajouter un mecanisme (kernel-wide) qui permet d'avoir un element "opaque" qui sera exploite par dtrace, qui au final ne sera plus qu'un module a part.
                • [^] # Re: Un autre point

                  Posté par . Évalué à 2.

                  OK, je comprends mieux, merci pour la clarification.
    • [^] # Re: Une petite correction

      Posté par . Évalué à 5.

      Autre petite correction à apporter : "exciting" est un faux-ami, et trop de gens pensent que cela se traduit naïvement par "excitant". Or, "exciting" signifie "passionnant".

      Rien de bien grave en soi mais, au milieu d'une dépêche d'une telle qualité, cela détonne un peu.

      Amicalement.
      • [^] # Re: Une petite correction

        Posté par . Évalué à 3.

        Dans la même veine.

        s/Je vais blâmer la période de deux semaines/Je vais mettre ça sur le compte de la période de deux semaines

        par exemple
        • [^] # Re: Une petite correction

          Posté par (page perso) . Évalué à 7.

          Ouais je sais, je sais, je suis pas un killer en anglais.
          Pour la dernière news noyau y'a baud123 qui était passé derrière ma traduction pour l'améliorer.
          C'est donc sa faute si les traductions sont moins bonnes cette fois-ci ;-)
        • [^] # Re: Une petite correction

          Posté par . Évalué à 5.

          Ah flûte, tout d'un coup la commande 'svn blame' perd de son charme :(
  • # Asus EEE

    Posté par (page perso) . Évalué à 10.

    Et là où on voit l'extrême rapidité de Linus, il nous sort le 24 un noyau qui intègre la gestion de la carte son pour l'Eee qui sort le 26 en France ;-)

    Son : "Add support for ASUS P701 eeepc"

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # ça a sûrement déjà été auparavant...

    Posté par . Évalué à 10.

    Mais j'imagine bien le coup qui risque d'arriver, quand je lis ça :

    "Par exemple maintenant un administrateur peut décider que les souris et les claviers sont autorisés (en leur passant le flag authorized à 1) alors que les imprimantes et les périphériques de stockage sont interdits (valeur 0 dans leur flag)."

    "Ben m*** mon clavier USB a le flag 0 !!!"



    (bon, vous me direz que par ssh ou via un Live-CD ça doit être récupérable, certes. Mais rien que l'idée de le faire à quelqu'un m'a amusé :-) )
  • # Un grand merci pour cet article

    Posté par (page perso) . Évalué à 1.

    Comme beaucoup d'autres le disent, les articles de patrick_g sont clair, détaillé et agréable à lire.


    Merci encore :)
  • # Très bon

    Posté par (page perso) . Évalué à 0.

    Très bonne dépèche, synthétique et tout.

    Encore, encore !
  • # Historique des RC...

    Posté par (page perso) . Évalué à 1.

    Était-il vraiment nécessaire de « copier/coller » l'historique des sorties des RC de cette version (avec les commentaires de Linus) en première partie de cette dépêche ?
    Un sommaire relatant la partie détaillée de celle-ci n'aura-ti-il pas été plus approprié ?
    • [^] # Re: Historique des RC...

      Posté par . Évalué à 10.

      Perso, j'aime bien. Ca donne un coté un peu humain à la news.

      Après, je peux comprendre que ça à un coté non académique qui peut déplaire :-)
    • [^] # Re: Historique des RC...

      Posté par (page perso) . Évalué à 9.

      Moi ça m'a fait pêter de rire. Comme quasiment tous les mails de Linus.
    • [^] # Re: Historique des RC...

      Posté par (page perso) . Évalué à 4.

      J'ai pas bien compris si c'est le fait de citer l'historique des sorties des RC qui te déplais ou si c'est le fait de mettre cet historique en première partie (ce qui, je le reconnais, prend beaucoup de place sur la front-page du site) ?
      • [^] # Re: Historique des RC...

        Posté par . Évalué à 8.

        oui ca prend beaucoup de place mais bon en meme temps c'est 1) agreable a lire 2) problablemnet la seule depeche relatif au nom du site qui sera publie de tout le mois... alors on peut lui mettre un peu de "visibilite" surtout vu son "facteur" qualite.

        Je joins mes felicitations naturellement.
      • [^] # Re: Historique des RC...

        Posté par (page perso) . Évalué à 4.

        Le fait qu'il soit en première partie.
        • [^] # Re: Historique des RC...

          Posté par (page perso) . Évalué à 4.

          Oui je suis d'accord avec toi, c'est trop long pour une première partie.
          Je vais changer ça pour la news du 2.6.25 en ramenant le résumé des RC en seconde partie.
    • [^] # Re: Historique des RC...

      Posté par . Évalué à 3.

      Bah si c'est marrant de voir l'accouchement un poil douloureux.
      Et puis ça me fait penser à la rétrospective des 10 ans de LWN, avec ses "remember, the 2.4 kernel is in deep freeze."
  • # Concurence

    Posté par (page perso) . Évalué à -7.

    L'image qui résulte de tous ces chiffres est celle d'une communauté de développement saine et diversifiée. Le noyau est vraiment une ressource commune avec littéralement des milliers de personnes qui travaillent pour l'améliorer. Et il ne montre aucun signe de ralentissement de sitôt.

    Les pourfendeurs de monopoles, les défenseurs de la concurrence saine libre et non faussés, les moqueurs de communautés, les drogués de croissance, nous dirons qu'après la mort des Unix, il est temps de privatiser, libéraliser tout ça et que ça saute. Soulevons du capital, investissons, produisons et vendons...

    Comment ça un bien commun ?!?

    PS : Y'a des entreprises qui travaillent sur linux, je sais. Y'a des modèles économiques du libre, je sais. Mandriva est côté en bourse, je sais. Y'en a même qui disent que le libre est pure concurrence... je sais malheureusement aussi.
  • # Merci

    Posté par (page perso) . Évalué à 1.

    Énorme news. Merci de ce travail remarquable.
  • # ...

    Posté par . Évalué à 4.

    le support de la norme Secure Digital Input Output fait son entrée au sein du code permettant de gérer les cartes mémoires MMC et SD. Cette modification autorise le branchement sur un port SD de divers gadgets: Récepteurs GPS, adaptateurs Wi-Fi ou Bluetooth ou Ethernet, Lecteurs de code-barre, Tuners FM ou TV, Appareils photos, etc.

    Il faut tout de même que le contrôleur sd-card soit compatible sdio.
    Il y a des différences entre le protocole sd-card et sdio. La sdio peut émettes des IT, les transferts sont de taille variable, ...

    Pierre Ossman, qui est le mainteneur officiel du sous-système MMC/SD, a annoncé que trois pilotes SDIO étaient déjà inclus dans le noyau et que le travail continue pour inclure de nombreux autres pilotes. Néanmoins il tient à avertir les développeurs que son implémentation de SDIO force à écrire proprement le code des pilotes :

    Le problème vient parfois du hardware (controlleur sdio ou carte sdio) qui oblige a faire certains hacks (par ce qu'il ne sont pas forcement 100% conforme à la norme).
    C'est l'éternel problème on cherche à respecter à 100% la spec ou on supporte un max de hardware.
    Sachant que le sdio est plutôt utilisé dans l'embarqué, je crains malheureusement des hacks pour s'adapter au contrôleur sélectionner par les acheteurs (ceux qui sont les moins cher).

    De plus quand je vois que pour l'acpi on en arrive à copier le comportement windows, je sais pas si ce modèle tiendra .

    PS : d'ailleurs je crois que openmoko ont abandonné l'idée d'utiliser cette stack, pour utiliser celle libéré par atheros (ou montavista).
    • [^] # Re: ...

      Posté par . Évalué à 10.

      Mais au fait, pourquoi SDIO plutôt que USB (question naïve) ?

      On avait, dans le temps, des cartes mémoires de différents formats. Pendant ce temps-là, la norme USB s'installait peu à peu.
      Puis la déferlante des clés USB est arrivée. Déjà à l'époque, je me suis demandé pourquoi on continuait à utiliser toutes ces cartes mémoire incompatibles entre elles si USB pouvait unifier tout ça. Pire, on inventait de nouveaux formats.

      Maintenant, on étend une norme de carte mémoire (SD), pour en faire un port d'extension générique, qui, de mon point de vue, offre des fonctionnalités similaires à USB.
      Mais à quoi ça rime ???
      Est-ce que SDIO a des caractéristiques tellement uniques que ça justifie une n+1-ième norme ?
      • [^] # Re: ...

        Posté par . Évalué à 9.

        Est-ce que SDIO a des caractéristiques tellement uniques que ça justifie une n+1-ième norme ?
        L'usb host est assez lourd (a la fois en taille dans le chip et a la fois au niveau soft).
        Avec l'usb host il faut gérer les hubs, les périphériques de différentes vitesse. En plus l'usb host qui coordonne le tout doit constamment faire une sorte de pooling sur les périphériques. C'est soit fait en hard (mais le controlleur est cher), soit en soft (mais bonjour les perfs).

        Au contraire la sd/sdio c'est tout con : c'est quatre fil de data, un de commande et un autre d'horloge.
        • [^] # Re: ...

          Posté par . Évalué à 3.

          Donc en gros c'est une espèce de USB-light pour l'embarqué ?
          • [^] # Re: ...

            Posté par . Évalué à 5.

            moi une poignée de fils de data et un fil synchro tout con, ça me fait plutôt penser à du bon vieux port série.
            • [^] # Re: ...

              Posté par . Évalué à 2.

              "Série", comme dans Universal Serial Bus ?
              Donc oui, un USB-light... ou un bon vieux port série, si tu veux ;-)
              • [^] # Re: ...

                Posté par . Évalué à 3.

                Je pense qu'il voulait parler de RS232 ;)
              • [^] # Re: ...

                Posté par . Évalué à 6.

                L'USB porte un bien mauvais nom car il n'a d'universel que le nom et est sans rapport avec le bon vieux port série et ne pourra jamais le remplacer complètement. D'ailleurs dans tout un tas de systèmes embarqués le bon port série régne en maître. A tel point que là où je bosse on pense sérieusement à passer de 2 à 4 ports RS232 sur nos produits.
                L'USB c'est du maître/esclaves, ça coûte cher, demande pas mal de logiciel derrière (pour faire un maître), ça répond très bien aux besoins d'un PC qui est maître sur lequel tu veux brancher plein de périph. mais ça ne remplace pas pour moi le bon vieux port série qui est du full duplex, pas de notion de maître ou d'esclave, et point à point, donc beaucoup plus simple à gérer mais qui est limité en débit. Il reste donc de la place pour un bus simple à "haut" débit (dans la tranche 10 à 100Mbit/s) pour faire communiquer simplement des équipements autonomes entre eux.
            • [^] # Re: ...

              Posté par . Évalué à 3.

              Et encore, en RS232 t'a même pas de clock ...
              • [^] # Re: ...

                Posté par (page perso) . Évalué à 3.

                Si, il y avait des RS232 avec horloge ! Mais uniquement avec les prises modem 25 broches.
                Voir http://www.tavernier-c.com/serie.htm
                • [^] # Re: ...

                  Posté par . Évalué à 3.

                  Le RS232 couvre à la fois le synchrone (nécessite un signal d'horloge) et l'asynchrone (pas d'horloge). Mais l'usage le plus courant est l'asynchrone, couramment réduit à un connecteur 9 broches et n'utilisant pas les signaux d'horloge.
  • # KASSKOOYE

    Posté par . Évalué à -10.

    J'aime bien suivre les évolutions du noyal, mais là c'est carrément casse coucougnettes. Trop long.

Suivre le flux des commentaires

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