Logiciel : Sortie du noyau Linux 2.6.24
Posté par patrick_g (page perso, ). Modéré le 25 janvier 2008.
- 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.
![[en]](../images/en.png)
Les nouveautés du noyau 2.6.24 (2881 hits)-
Le bilan des ajouts partie 1 (564 hits)
-
Le bilan des ajouts partie 2 (394 hits)
-
Les prévisions pour le futur de Linux (1191 hits)
> Lire la dépêche (65 commentaires, moyenne: 4,9).
Vous avez demandé le commentaire #899249.
Run by 
Cette page a été générée par Templeet en 0.0663s (dont 0.0065 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Une petite correction
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
>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
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
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
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
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
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
OK, je comprends mieux, merci pour la clarification.
[^]Re: Une petite correction
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
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
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
Ah flûte, tout d'un coup la commande 'svn blame' perd de son charme :(