Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information

: Sortie du noyau Linux 2.6.24

Posté par patrick_g (page perso, ). Modéré le 25 janvier 2008.
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.

> Lire la dépêche (65 commentaires, moyenne: 4,9).  

Vous avez demandé le commentaire #899479.

...

Posté par Matthieu C () le 26/01/2008 à 14:05. (lien). É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 Aldoo (Jabber id, ) le 26/01/2008 à 15:12. (lien). É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 Matthieu C () le 26/01/2008 à 18:02. (lien). É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 Aldoo (Jabber id, ) le 26/01/2008 à 19:07. (lien). Évalué à 3.

        Donc en gros c'est une espèce de USB-light pour l'embarqué ?

        • [^]Re: ...

          Posté par phentex () le 27/01/2008 à 14:06. (lien). É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.

          --
          ggggnnnnnnnnnnnnnnnnn (interprétation libre)
          • [^]Re: ...

            Posté par Aldoo (Jabber id, ) le 27/01/2008 à 19:29. (lien). É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 Moonz () le 27/01/2008 à 19:49. (lien). Évalué à 3.

              Je pense qu'il voulait parler de RS232 ;)

              [^]Re: ...

              Posté par gpe () le 28/01/2008 à 02:33. (lien). É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 Batchyx () le 27/01/2008 à 20:15. (lien). Évalué à 3.

            Et encore, en RS232 t'a même pas de clock ...

            • [^]Re: ...

              Posté par Pierre Jarillon (page perso, ) le 28/01/2008 à 00:06. (lien). É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 gpe () le 28/01/2008 à 02:16. (lien). É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.