Depuis quelques années il existe des versions spécifiques du noyau Linux dont la maintenance est planifiée pour une durée plus longue que les autres. Il s’agit des longterm kernels. La semaine passée Greg Kroah-Hartman qui assure une part importante de la maintenance des noyaux stables et longterm a proposé d’établir de nouvelles règles de fonctionnement pour ces noyaux. La discussion est encore active, mais quelques remarques peuvent déjà être faites.

Situation précédente

Le principe actuel de mise à jour des kernels remonte au mois d’août 2004. A cette époque, le noyau 2.6 était utilisé depuis près d’un an et la phase classique de stabilisation des premiers mois avait été suivie par une première série d’évolutions plus ou moins importantes. Aucune branche de développement spécifique n’avait été ouverte contrairement aux noyaux précédents (pour en savoir plus sur les noyaux antérieurs aux 2.6) et la décision avait été prise de continuer à apporter des nouveautés régulièrement sur la branche 2.6.

Le 14 août 2004, le noyau 2.6.8 venait à peine d’être publié par Linus Tovalds qu’un bug grave fût relevé dans le système de fichiers NFS. Il fallait publier très rapidement un correctif, mais la faible ampleur des modifications ne justifiait toutefois pas la publication d’un nouveau noyau 2.6.9. Linus décida alors de publier l’après-midi un noyau 2.6.8.1 corrigeant le défaut.

Ce fut à partir de mars 2005, avec la sortie du noyau 2.6.11, que le choix de la numérotation sur 4 nombres s’établit définitivement. Un noyau dit stable serait publié régulièrement (à peu près tous les trimestres) avec une numérotation sur trois nombres (par ex. 2.6.12) puis un mainteneur serait désigné pour prendre le relai et regrouper les correctifs sous forme de versions à 4 nombres (2.6.12.4) publiées par le mainteneur du noyau stable. Une fois un nouveau noyau stable publié (ex. 2.6.13) le support sur le noyau précédent serait abandonné.

Cette méthode permettait de disposer d’un kernel flambant neuf (dit stable) tous les deux à trois mois, comportant de nouvelles fonctionnalités et les drivers pour les matériels les plus récents. En outre l’effort consacré à la maintenance et la correction des bugs pouvait se concentrer sur la dernière version stable, sans s’éparpiller sur les versions plus anciennes.

Cette méthode toutefois n’allait pas sans poser de problèmes. En effet, entre deux versions stables du noyau (à trois nombres) prenaient places de nombreuses modifications internes. Des éléments étaient ajoutés bien entendu (drivers, systèmes de fichiers, protocoles…) mais certains sous-systèmes étaient parfois très profondément modifiés. Par exemple le support des architectures x86/PAE dans le noyau 2.6.10 (permettant d’adresser plus de 4 Go de mémoire) impliqua une modification importante du sous-système Memory Management. En conséquence l’API interne du noyau – celle que l’on utilise pas exemple pour écrire des drivers – se trouve sensiblement modifiée entre deux versions stables. L’API externe – celle offerte par les appels-système – reste bien sûr stable pour ne pas casser la compatibilité avec les bibliothèques et applications de l’espace utilisateur.

Ainsi un driver écrit en dehors du noyau officiel doit être mis à jour (ou du moins vérifié) à chaque nouvelle version stable. Le fait de ne pas offrir de support pour un noyau stable précédent posait des problèmes aux distributions qui intègrent des drivers provenant d’autres sources que le noyau officiel. Pour bénéficier des correctifs (sécurité, performance etc.) il était nécessaire de changer regulièrement de noyau pour basculer sur la nouvelle version stable. En contrepartie les drivers supplémentaires obtenus ou développés indépendamment du noyau standard ne fonctionnaient plus et nécessitaient une mise à jour régulière.

Si les distributions les plus importantes pouvaient à la rigueur se permettre cet effort de suivi et support du kernel, cela n’était pas possible pour les plus petites d’entre-elles.

A l’occasion du noyau 2.6.16, Greg Kroah-Hartman (qui travaillait pour SUSE) décida de prendre en maintenance ce noyau sur une période suffisamment longue pour avoir une pérennité acceptable pour les entreprises ne souhaitant pas mettre à jour le noyau de leur parc informatique tous les trimestres. Il réalisa un long travail de maintenance sur ce noyau jusqu’en  2008 avec un 62ème correctif !

Courant 2008 le noyau 2.6.16, encore utilisé par de nombreuses distributions commençait à sembler ancien. De nombreuses fonctionnalités importantes (système tickless, nouvel ordonnanceur, gestion améliorée du cache mémoire, etc.) étaient apparues depuis. Quelques versions du noyau avaient été maintenues un peu plus longtemps que les autres (2.6.20, 2.6.22, 2.6.25) mais aucune n’avaient la longévité du 2.6.16.

Il fallu une nouvelle impulsion de Greg Kroah-Hartman pour choisir et figer une version avec maintenance étendue. Le noyau 2.6.27 fut choisi, et sa maintenance entamée par Greg est aujourd’hui (2.6.27.59) assurée par Willy Tarreau.

La nécessité de disposer de versions pérènes du kernel Linux  se faisant sentir de plus en plus – notamment avec la croissance du marché de Linux embarqué – un premier noyau (2.6.32) fut marqué officiellement  longterm et maintenu par Greg Kroah-Hartman. Puis un second kernel (2.6.33) et la méthode faisant des émules, d’autres mainteneurs se proposèrent pour deux autres versions (Paul Gortmaker pour le 2.6.34 et Andi Kleen pour le 2.6.35).

Situation actuelle et avenir

Avec le passage à la version 3 du kernel, Linus souhaite se débarrasser de la numérotation à quatre nombres, pour revenir à un schéma plus simple.

• Le noyau stable actuel est le 3.0
• Le niveau de correctif sur le noyau stable est 3.0.3
• Le prochain noyau stable sera le 3.1, une version release candidate 3.1-rc2 est disponible dès aujourd’hui, on peut donc s’attendre à une publication du 3.1 en septembre ou octobre.

Une fois un kernel stable publié, il n’y aura plus de maintenance assurée sur le noyau stable précédent (avec probablement quelques semaines de recouvrement quand même).

Greg propose à partir de maintenant de choisir tous les ans un noyau pour un support longterm qui sera assuré pendant deux ans. A chaque instant, il y aura donc deux kernels longterm et (au moins) un kernel stable disponible sur http://www.kernel.org/.

Ce système me semble assez avantageux pour tous. Les hackers et passionnés désireux de tester les dernières fonctionnalités du kernel pourront télécharger et compiler régulièrement le dernier noyau stable. Les distributions pourront proposer le dernier noyau longterm (pour bénéficier des nouveautés) ou le précédent (pour les plus conservateurs). Enfin, les administrateurs de parcs informatiques pourront programmer la mise à niveau biennale du kernel de leurs machines.

Certaines entreprises trouveront la durée de maintenance trop courte. En effet, il existe de nombreux domaines où l’on aime « geler » une version des logiciels pour toute la durée de vie du produit dans lequel on l’intègre. J’entends souvent mes interlocuteurs dans le domaine des systèmes embarqués dire :

« Notre fournisseur [d’OS temps-réel propriétaire payant] nous garantit une maintenance pendant 15 ans, comment peut-on avoir la même chose avec Linux ? »

La réponse est simple :

« En payant quelqu’un pour l’assurer au-delà de deux ans ! »

Si un bug dans un noyau longterm, non découvert au-delà des deux ans est soudainement révélé par un utilisateur d’un système embarqué pour lequel aucune évolution vers un noyau plus récent n’est envisageable (probabilité quand même assez réduite), de nombreuses sociétés spécialisées sur Linux (notamment Logilin pour qui je travaille) seront à même de proposer des prestations d’ingénierie pour corriger le défaut.

PS: Vacances et déplacements professionnels aidant, je n’ai pas posté beaucoup d’articles ce mois-ci. Je viens de terminer la rédaction de celui-ci dans une chambre d’hôtel sur Madison Avenue – NY  😉   J’espère reprendre un rythme un peu plus régulier à partir de la semaine prochaine.