[Noyau] 2.6.26

Hanz0 · Le 18/07/2008, à 12:00

Souvent imité jamais égalé, voici le nouveau compte rendu du nouveau noyau par Patrick_g.

Bonne lecture.

La phase de test...
* Selon Linus cette version 2.6.26 n'est techniquement pas très risquée et le 3 mai, dans son courriel d'annonce de la RC-1, il écrit : "La période de merge a été mouvementée car il y a eu beaucoup de discussions et de disputes mais, dans le même temps, je pense que sur un angle technique nous avons intégré des choses moins effrayantes que cela n'était le cas auparavant. Beaucoup de changements mais rien de vraiment fragile.
Une autre fonctionnalité qui est notable, non par sa taille mais parce que les gens avaient essayé de me le faire intégrer depuis longtemps, est le support de kgdb. Cela s'est révélé être du code vraiment petit et propre, une fois que les gens ont commencé à orienter leurs efforts pour que cela soit le cas. Kgdb est le nom d'un débogueur du noyau Linux au niveau code source.
* La RC-2 du 12 mai a confirmé ce sentiment d'une version du noyau sans problèmes notables de stabilité : "Si vous lisez le résumé des corrections et en retirez le sentiment qu'il s'agit d'une liste de petits trucs barbants vous aurez raison. Il n'y a pas grand chose d'excitant là-dedans.
* Le 18 mai, pour la sortie de la version candidate RC-3, Linus a évoqué un anniversaire assez inattendu : "Une chose intéressante (du moins pour moi) est que nous utilisons git depuis presque la même durée que nous avons utilisé BitKeeper - un peu plus de trois ans. Nous avons commencé à utiliser BK en février 2002, avec un point final pour la version 2.6.12-rc2 au début avril 2005. Le premier commit avec git a pris place deux semaines plus tard.
Donc, du fait de cet évènement, j'ai regardé quelques statistiques de l'époque BK et de l'époque git. La différence la plus frappante (...) est que nous développons plus vite et avec plus de gens. Pendant les années 2002->2005 il y a eu 63428 commits attribués à environ 1560 auteurs différents. Pendant les trois dernières années il y a eu 96885 commits attribués à environ 4068 auteurs différents.
Cette petite recherche statistique effectuée par Linus prouve que la communauté des développeurs du noyau est plus active que jamais. Avec +52,7% pour les commits et +160,7% pour les auteurs on a la preuve que le processus de développement actuel résiste à la charge et que le travail sur le noyau Linux augmente d'année en année.
* Les versions candidates suivantes sont apparues au rythme normal et habituel d'une par semaine environ. La RC-4 le 26 mai (avec un Linus poussant un petit grognement contre les "pervers" qui utilisent un noyau 32 bits alors qu'ils ont un processeur 64 bits et plus de 4 Go de mémoire), la RC-5 le 4 juin et la RC-6 le 12 juin.
* La version candidate RC-7 du 20 juin a vu l'inclusion (très tardive dans le cycle) des pilotes 3D pour les cartes Radeon R500 et la mise à jour des pilotes pour les cartes Intel de type GMA-4. Cette inclusion de dernière minute n'a pourtant pas soulevé de protestations particulières : "Je ne suis pas vraiment heureux de la date d'inclusion de ces nouvelles cartes mais en même temps je déteste retarder l'inclusion de nouveaux pilotes. Évidemment l'espoir est que cela ne causera aucune régression car le code qui a été ajouté est presque entièrement pour des trucs qui n'étaient de toute façon pas supportés auparavant.
* Dès le 24 juin est apparue la RC-8 : "Je sais, cela ne fait pas une semaine depuis la RC-7 et la liste des changements est très réduite, mais comme je ne vais pas être joignable durant les prochains jours je sors juste cette RC-8 en espérant que ce sera la dernière. Ou pas. Cela dépendra du fait de savoir si vous êtes efficaces quand je ne vous surveille pas.
* Le 5 juillet Linus a annoncé la sortie de la RC-9 :"OK, la dernière RC n'était pas la dernière après tout puisqu'en voilà une nouvelle. Il y a eu suffisamment de changements pour que nous ayons besoin d'une version de plus. Mais cela devrait fermer de nombreuses entrées dans la liste des régressions donc ce n'est pas plus mal.
Il y a aussi quelques patchs de nettoyage tardifs qui me viennent d'Al. Pas cool, Al. Mais quand Al m'envoie des patchs je les applique. Cela m'inquiète de penser à ce qui pourrait arriver si je ne le faisais pas.

Les nouveautés...
* Le support de PAT (Page Attribute Table) a été ajouté dans le noyau pour l'architecture x86. Cette technologie a eu une longue et difficile gestation (depuis 2006 !) mais son arrivée va permettre au système d'exploitation libre de gérer plus finement les caches mémoire. Auparavant c'était seulement la technique MTRR (Memory Type Range Registers) qui était utilisée. Elle permettait de changer le comportement des caches mémoire mais seulement pour un nombre limité d'adresses physiques. PAT est bien plus souple d'utilisation et permet de définir des attributs sur chacune des pages mémoire ce qui va constituer un complément utile de MTRR. La documentation permet de comprendre plus précisément comment fonctionne cette notion d'attributs au niveau des pages mémoires.
* Le noyau 2.6.26 corrige une faiblesse sur la fonction mount --bind. Cette fonction permet très facilement de monter une arborescence sur un second point de montage. Si par exemple j'ai un disque dur qui se trouve dans "/mnt/sda1" et que je veux le mettre aussi dans "/mon_conteneur/plop", je dois créer le dossier de destination et lancer la commande "mount --bind /mnt/sda1 /mon_conteneur/plop". On peut par exemple utiliser le mount --bind pour exporter une arborescence dans un conteneur.
L'ennui c'est que ce second point de montage aura exactement les mêmes options de mount que le premier. Si je veux monter mon mount --bind en lecture seule alors que le premier montage a été fait en lecture/écriture cela n'est pas possible (ce qui est gênant car il est souvent nécessaire de pouvoir exporter en lecture seule dans un conteneur virtuel). Le noyau 2.6.26 offre donc maintenant la possibilité d'avoir des options de montage différentes sur son mount --bind. Pour des raisons techniques il faut monter une première fois le mount --bind en lecture/écriture puis le remonter ensuite en lecture seule. Les développeurs du noyau ont donc du prévoir le cas tordu ou un processus ouvre un fichier en écriture juste entre les deux opérations de mount. L'article de LWN explique bien tous les petits détails sordides dont il a fallu tenir compte pour permettre de gérer ce problème potentiel.
En définitive la possibilité de faire des mount --bind en lecture seule va permettre de monter de façon plus souple et plus riche les systèmes de fichiers et cela sera certainement fort utile en cas d'utilisation intensive des conteneurs virtuels.
* Le patch implémentant la notion de bit de sécurité par processus a été ajouté au noyau 2.6.26. Ainsi, au lieu d'avoir des applications qui fonctionneront avec les droits de root (applications "setuid"), il devient possible de ne plus élever les privilèges de ces applications de façon exorbitante. Actuellement cette fonction est désactivée par défaut et il faut compiler son noyau avec CONFIG_SECURITY_FILE_CAPABILITIES pour l'activer.
* Étant donnée l'inclusion dans le noyau précédent du module de sécurité SMACK il faut maintenant gérer la cohabitation avec SELinux qui est l'autre module existant dans la branche principale. Un nouveau paramètre de boot fait donc son apparition pour savoir quel module doit être chargé par LSM (Linux Security Modules): En utilisant le paramètre "security=" il devient possible de choisir quel module sera chargé dans le noyau (SELinux ou SMACK) et si ce paramètre n'est pas renseigné c'est le premier module à faire la demande qui sera chargé par LSM.
* Toujours dans les paramètres de boot il est maintenant possible de tester la mémoire lors du démarrage de la machine. Avec ce nouveau noyau 2.6.26 il suffit de passer "memtest=4" au boot pour que cette fonction s'active (si le noyau a été compilé avec l'option MEMTEST_BOOTPARAM). Bien entendu cette nouveauté ne vise pas à remplacer le très complet memtest mais il permet d'avoir un outil basique intégré dans le noyau (qui donc potentiellement pourra par la suite fonctionner sur de multiples architectures alors que memtest est limité aux x86).
* Le débogueur kgdb a été finalement intégré au noyau pour l'architecture x86, après des années de pression de la part de nombreux développeurs et une âpre résistance de la part de Linus Torvalds qui a souvent exprimé son dédain pour cette solution. Pour passer le barrage de Linus il a été nécessaire de modifier kgdb afin de s'assurer de la parfaite propreté du code et de l'absence d'impact sur le reste du noyau. Une fois que Linus a été convaincu que le patch était aussi peu intrusif que possible il a donné son feu vert pour l'inclusion.
le débogueur KGDB s'utilise avec deux machines (seulement architecture x86 ou SPARC pour l'instant) : l'une est la machine de test qui exécute le noyau qu'il faut déboguer et l'autre exécute une instance de gdb et est reliée à la première par liaison rs232 ou ethernet.
Une documentation au format DocBook a été ajoutée et permet de débuter dans le monde merveilleux du déboguage noyau.
* L'implémentation des sémaphores a été radicalement simplifiée dans le noyau 2.6.26. En effet depuis le noyau 2.6.16 un large mouvement de conversion de code a été entrepris afin de changer les sémaphores pour les remplacer par des mutex. Les sémaphores permettent de contrôler l'accès a des ressources quand plusieurs processus se font concurrence. Pour cela les sémaphores embarquent un compteur mais pourtant dans la pratique la limite est presque toujours fixée à 1 (un seul processus doit avoir accès à la ressource à un moment donné). Pourquoi alors s'embêter avec des sémaphores complexes et leur compteur quand dans la plupart des cas on ne doit autoriser qu'un seul processus à la fois ? Plutôt qu'un sémaphore il vaut mieux mettre un mutex (mutual exclusion) qui, comme son nom l'indique, ne permet qu'à un seul processus d'accéder à la ressource. C'est ce qui a été fait à partir du noyau 2.6.16 et maintenant les seuls sémaphores qui restent dans le noyau sont (théoriquement) ceux pour lesquels il est vraiment indispensable d'avoir un compteur. Comme ils ne sont plus critiques pour les performances on peut remplacer tout leur code très optimisé écrit en assembleur pour chaque architecture par du code générique écrit en C. Le patch des sémaphores génériques écrit par Matthew Wilcox supprime donc plus de 7000 lignes de code complexe et les remplace par à peine 300 lignes (ce qui facilite grandement la lisibilité et la maintenabilité du noyau).
* Le début du support des réseaux en maille (Mesh networking) fait son entrée dans le noyau. Ces réseaux se caractérisent par le fait que tous les hôtes sont connectés de proche en proche sans aucune hiérarchie centrale (plus de point d'accès privilégié au réseau donc). On se souvient que la possibilité de constitution de réseaux de ce type est une des grandes forces du projet One Laptop per Child. L'IEEE est en train de travailler sur la future norme 802.11s et c'est le second draft de cette future norme qui est implémenté dans la pile wifi mac80211 du noyau Linux. Le code est le résultat du travail du consortium Open80211s qui regroupe plusieurs entreprises afin de produire une implémentation libre de la norme 802.11s.
Actuellement l'implémentation est très préliminaire et seuls les pilotes b43 et zd1211rw sont capables de fonctionner en mode mesh. Si vous possédez une carte utilisant ces pilotes vous pouvez suivre ce howto et rapporter vos résultats sur la liste de diffusion linux-wireless.
* Les périphériques PCI Express sont maintenant capables d'utiliser la fonction Active State Power Management (ASPM). Avec ASPM le lien PCI Express peut réduire sensiblement sa consommation de courant (au détriment toutefois de la latence pour repasser en mode performance maximum). Il est possible de choisir sa politique ASPM en passant des valeurs à /sys/module/pcie_aspm/parameters/policy. La valeur "default" s'en tient aux réglage par défaut du BIOS, la valeur "powersave" active toutes les fonctions d'économies d'énergie tandis que la valeur "performance" désactive ASPM au profit de la rapidité. Selon le message du commit la différence entre "powersave" et "performance" peut atteindre 1.3w dans un système contenant 3 liens PCI Express ce qui est loin d'être négligeable.
* Concernant les disques durs traditionnels le système de fichiers Ext4 continue sa longue marche vers la stabilité afin de pouvoir sortir de son statut expérimental.
On peut noter que la technologie des barrières a été activée par défaut pour Ext4. Cette technologie améliore la fiabilité du système de fichiers en s'assurant que les données sont écrites dans le journal de façon cohérente avant que le disque ne puisse continuer son travail. L'ennui c'est que cette fonction qui existe aussi pour Ext3 n'est que rarement activée car l'impact sur les performances peut être sévère (Andrew Morton indique que la dernière fois que l'activation avait été tentée un ralentissement de 30% avait été observée sur certaines applications et qu'il avait donc rejeté le patch avec horreur). Ce ralentissement devrait être moins important avec Ext4 du fait de sa technologie et la fonction des barrières a donc été activée par défaut.
De manière générale le travail sur Ext4 avance de façon satisfaisante et Ted Ts'o, qui est le développeur principal, se sent maintenant assez confiant pour utiliser exclusivement Ext4 sur son ordinateur personnel. Quand on connaît sa minutie et son perfectionnisme on ne peut qu'être confiant sur la robustesse du nouveau système de fichiers.
* Un support basique des lecteurs d'écran en braille a été intégré directement dans le noyau. Cet outil est très simple et ne peut se comparer aux lecteurs braille en espace utilisateur. Néanmoins cette fonction peut être très utile pour personnes déficientes visuelles en cas d'échec du boot ou si / ne peut pas être monté. Dans ces cas, le lecteur braille habituel (fonctionnant en mémoire utilisateur) ne peut pas être lancé et il est alors précieux d'avoir un support basique intégré au noyau. Une documentation est disponible et elle précise que le seul lecteur qui est pour l'instant supporté est VisioBraille.
* L'outil intégré de virtualisation KVM fonctionne désormais sur les architectures IA64, PPC et S390 alors qu'auparavant il était limité aux x86 et x86-64.
Du côté de Xen, l'autre grande solution de virtualisation, le noyau 2.6.26 apporte la possibilité de faire varier dynamiquement la mémoire alloué aux domaines gérés par l'hôte. Ce "baloon driver" permet donc à l'hyperviseur Xen de distribuer la mémoire entre les domaines de façon plus souple. Une limitation existe toutefois puisque la quantité de mémoire du domaine ne peut actuellement qu'être réduite ou ré-augmentée jusqu'à la taille de départ. Un patch futur permettra d'augmenter la taille mémoire des domaines par rapport à leur taille initiale.
* En bref....
o La fonction d'ordonnancement de groupe, introduite dans le noyau 2.6.24, voit ses fonctions de support du temps réel améliorées.
o Il est désormais possible de faire de la traduction d'adresse réseau (NAT) avec les protocoles UDP-Lite, DCCP et SCTP.
o Plusieurs patchs complètent le support de l'espace de noms pour les interfaces réseaux. C'est donc la continuation du long travail visant à masquer toutes les ressources globales du noyau (systèmes de fichiers, identifiants des processus, interfaces réseaux etc.) derrière une couche d'abstraction afin de pouvoir gérer des conteneurs séparés.
o La possibilité d'exécuter des binaires de SunOS et de Solaris a été supprimée. Le code était non maintenu et ne fonctionnait pas bien ce qui a provoqué le retrait de cette fonction (très peu utilisée).
o On peut maintenant attacher des périphériques IDE à chaud. Selon l'exemple donné dans la documentation pour changer le périphérique du port idex il suffit de faire un echo -n "1" > /sys/class/ide_port/idex/delete_devices puis d'enlever l'ancien périphérique et de brancher le nouveau en faisant un echo -n "1" > /sys/class/ide_port/idex/scan.
o Les processeurs de type Sun Niagara ont maintenant le support NUMA (Non Uniform Memory Access).
o Le noyau intègre maintenant divers pilotes spécifiques au portable Asus eeepc: le pilote global contrôle les hotkeys, le réseau et la caméra; le pilote écran s'occupe du rétroéclairage et le pilote hardware contrôle le ventilateur.
La liste détaillant toutes les autres nouveautés (réseaux, systèmes de fichier, pilotes disques, cartes son, vidéo, Bluetooth, etc.) est comme d'habiture disponible sur le site de Kernelnewbies.

Pour un bilan sous forme de statistiques le noyau 2.6.26 aura incorporé plus de 10100 patchs venant d'environ 1065 développeurs. Le nombre de lignes de code ajoutées dans le noyau dépasse les 169000.
À titre indicatif voici le nombre de patchs intégrés pour les sept derniers noyaux :
2.6.20 => 4983 patchs
2.6.21 => 5349 patchs
2.6.22 => 6648 patchs
2.6.23 => 7075 patchs
2.6.24 => 10353 patchs
2.6.25 => 12707 patchs
2.6.26 => 10132 patchs
Sachant que l'intervalle entre chaque noyau est de moins de trois mois on constate que le rythme de développement reste très soutenu et que le monde du libre n'a pas à s'inquiéter d'une éventuelle stagnation de Linux.
Pour le futur....
Comme d'habitude la page spécifique maintenue par Jonathan Corbet est un atout précieux pour avoir une idée les développements à venir dans le noyau Linux. Néanmoins, le travail de prévision est rendu bien plus précis cette fois-ci par l'arrivée de la nouvelle branche linux-next maintenue par Stephen Rothwell. Cette branche est destinée à jouer un rôle de "tampon" entre la très expérimentale branche -mm d'Andrew Morton et la première release candidate de Linus. Tous les patchs du futur noyau 2.6.27 ont donc déjà migré dans la branche linux-next afin que les problèmes de conflits de code puissent être résolus le plus tôt possible. Un article du site LWN fait le point sur cette branche et explique bien le long cycle de développement du nouveau code : Dépôt privé du développeur -> Branche expérimentale -mm -> Branche linux-next -> Versions release-candidate -> Noyau Linux officiel -> Branches -stable -> Intégration dans les distributions.
Pour savoir ce qui va rentrer dans le noyau 2.6.27 jetons donc un coup d'oeil rapide sur linux-next :
* Comme il était annoncé dans cette dépêche un grand nombre de patchs supprimant des appels au verrou global du noyau sont d'ores et déjà programmés pour inclusion. Le travail est cependant loin d'être fini et l'éradication du verrou global va sans doute s'étaler sur plusieurs mois.
* Une grande réorganisation du répertoire arch/ppc est prévue avec la suppression d'une grande partie du code au profit d'une organisation plus générique.
* Le système de fichiers UBIFS qui est spécialisé pour les disques SSD fait l'objet d'une revue de code à la demande des ingénieurs de Nokia pour une future inclusion dans le noyau. Comme le résultat semble positif il est presque certain qu'UBIFS va intégrer le 2.6.27.
* L'outil ftrace permettant de suivre les appels système d'une commande donnée en paramètre est programmé pour faire son entrée et va améliorer les possibilités offertes pour contrôler le fonctionnement du noyau.
* Enfin un mot au sujet des autres outils de tracing utrace et SystemTap qui continuent de se faire désirer. Il subsiste des problèmes techniques qui empêchent l'inclusion d'utrace dans la branche principale de Linux et cela bloque donc également l'entrée d'une partie des fonctionnalités de SystemTap. L'aiguillon que constitue le "concurrent" DTrace est cependant une motivation puissante pour les développeurs de SystemTap afin de résoudre ces problèmes. Tout le monde est bien conscient de cette concurrence et une longue discussion à ce sujet a eu lieu sur la liste de diffusion des sommets du noyau Linux. Selon l'un des développeurs de SystemTap une partie de la facilité d'utilisation de DTrace vient du fait que le noyau Solaris de Sun ne change pas beaucoup et qu'il pratique une stricte politique de compatibilité binaire (ABI). Le noyau Linux se développe à une vitesse sans commune mesure et a en plus choisi de ne pas rester prisonnier ad vitam aeternam d'une compatibilité binaire. Selon lui il est donc normal que le noyau Linux doive payer le prix de son succès par une implémentation plus difficile des outils de tracing.

A noter que c'est cette version de noyau qui a été retenue pour Ubuntu 8.10.

Source: http://linuxfr.org/2008/07/14/24297.html
Information complémentaires sur les ajouts de support de matériel: http://kernelnewbies.org/Linux_2_6_26

Dernière modification par Hanz0 (Le 18/07/2008, à 12:21)

blahnotblahblah · Le 18/07/2008, à 21:09

bah j'essaie d'installer ce noyau
avec la méthode
http://www.infos-du-net.com/forum/263428-10-tuto-compiler-kernel-ubuntu:P

et pour l'instant ça marche pas !:|

Ekroz · Le 19/07/2008, à 15:57

Sois pas pressé et attends une mise à jour.

Renault · Le 19/07/2008, à 17:17

Ekroz a écrit :

Sois pas pressé et attends une mise à jour.

Vous ne l'aurez que dans la prochaine Ubuntu...

Ekroz · Le 19/07/2008, à 20:12

Ce que je veux dire c'est que si son Ubuntu marche correctement inutile de se presser.

Sumol · Le 19/07/2008, à 21:52

Hanz0 a écrit :

avec un Linus poussant un petit grognement contre les "pervers" qui utilisent un noyau 32 bits alors qu'ils ont un processeur 64 bits et plus de 4 Go de mémoire

Qu'est-ce qu'il veut dire par la ?

jajaX · Le 20/07/2008, à 00:11

excellent =>

(avec un Linus poussant un petit grognement contre les "pervers" qui utilisent un noyau 32 bits alors qu'ils ont un processeur 64 bits et plus de 4 Go de mémoire)

j'ai que 2 Go de RAM ouf !!

Luckynow · Le 20/07/2008, à 23:09

Sumol a écrit :

Hanz0 a écrit :
avec un Linus poussant un petit grognement contre les "pervers" qui utilisent un noyau 32 bits alors qu'ils ont un processeur 64 bits et plus de 4 Go de mémoire
Qu'est-ce qu'il veut dire par la ?

Ben que c'est jouer mesquin quand on a 4GB de ram de pas passer en 64 bits alors que c'est sûrement la plateforme qui aurait besoin de plus de test. (on peut pas exploiter 4GB de ram avec un 32 bits).

EDIT: Après avoir lu l'annonce de la rc4, en fait il s'agissait d'un bug qui est survenu parce que un programmeur du kernel avait omis ce cas d'utilisation particulier. Ce qui causait pas mal de plantage.

Dernière modification par Luckynow (Le 20/07/2008, à 23:15)

magiccerbere · Le 22/07/2008, à 14:50

Une meilleur gestion des webcam! Peut etre que la mienne marchera enfin...
L'espoir fait vivre!

^^

Hanz0 · Le 31/07/2008, à 09:21

magiccerbere a écrit :

Une meilleur gestion des webcam! Peut etre que la mienne marchera enfin...
L'espoir fait vivre!
^^

La liste pour le noyau 2.6.26, regarde si elle est dedans.

Sinon Fedora pense à toi et utilisera un noyau 2.6.27

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 18/07/2008, à 12:00

[Noyau] 2.6.26

#2 Le 18/07/2008, à 21:09

Re : [Noyau] 2.6.26

#3 Le 19/07/2008, à 15:57

Re : [Noyau] 2.6.26

#4 Le 19/07/2008, à 17:17

Re : [Noyau] 2.6.26

#5 Le 19/07/2008, à 20:12

Re : [Noyau] 2.6.26

#6 Le 19/07/2008, à 21:52

Re : [Noyau] 2.6.26

#7 Le 20/07/2008, à 00:11

Re : [Noyau] 2.6.26

#8 Le 20/07/2008, à 23:09

Re : [Noyau] 2.6.26

#9 Le 22/07/2008, à 14:50

Re : [Noyau] 2.6.26

#10 Le 31/07/2008, à 09:21

Re : [Noyau] 2.6.26

Pied de page des forums