On me demande souvent comment se gère la qualité des releases du noyau Linux. Voici une étude de cas:

Thu, 10 Dec 2009 10:10:41 +0100: Jens Axboe rapporte sur la LKML une régression sur son système contenant un "Nehalem-EX" (le processeur octo-core d'Intel actuellement en développement). Son système ne démarre plus.

Jens entreprend d'effectuer une "bisection". git bisect permet d'automatiser partiellement ou totalement la recherche d'une régression. Pour cela, on présente à git-bisect un espace de révisions à analyser. On sait que la révision la plus ancienne fonctionne et que la plus récente ne fonctionne pas. git-bisect va alors effectuer une recherche par dichotomie sur l'ensemble des patchs. A chaque étape, git-bisect présentera la version du noyau correspondante. Optionnellement, on peut automatiser le test de la régression. Classiquement, dans le cas de Jens, il pourra compiler le noyau, l'installer sur la cible et redémarrer la cible automatiquement. Il devra ensuite indiquer manuellement à git bisect si le noyau démarre ou pas. La recherche dichotomique permet de réduire le nombre de test à log(nb_patchs). Ainsi, il faut 10 test pour rechercher une régression sur plus de 1000 patchs. De plus, git-bisect gèrera automatiquement les cas ou le kernel ne compile pas.

Thu 10 Dec 2009 11:39:45 +0100: Résultats des tests pour Jens. Le coupable est b24c2a925a9837cccf54d50aeac22ba0cbc15455. Jens ajoute que le kernel fonctionne bien si on retire le commit et propose donc de le reverser. Pour faire ce test, Jens à utilisé git revert. git-revert permet retirer un commit de l'historique. Pour cela, il se place juste avant le commit et réapplique l'historique sans le commit fautif. Cette approche permet de supprimer des commit introduits il y a très longtemps.

A l'aide de git show, on peut avoir des information sur le patch problématique. Remontons dans le passé:


Tue 24 Nov 2009 02:48:18 -0800: Yinghai Lu a écrit le patch b24c2a925a9837cccf54d50aeac22ba0cbc15455. Ce patch est intégré dans le repository de l'architecture x86, maintenu par Ingo Molnar.

Thu, 3 Dec 2009 22:02:46 +0100: Nous sommes dans la fenêtre de merge pour la version 2.6.33. Cela signifie que Linus Torvald permet aux contributeurs (plus particulièrement aux mainteneurs des sous-systèmes) d'intégrer des patchs dans la future version stable du noyau. Ingo Molnar envoie un mail sur la Linux Kernel Mailing List demandant à Linus "to pull" la version de son sous-systeme qu'il a préparé pour la version 2.6.33.

Tue, 8 Dec 2009 13:27:33 -0800: Dans le commit e33c01972239fee4696679ae5f7d1f340f424999, Linus Torvalds "pull" la branche x86-mm-for-linus du repository de l'architecture x86.

Revenons à notre bug.


Thu, 10 Dec 2009 17:06:40 +0100: Réaction d'Ingo, le maintener du sous-système concerné: On peut reverter le commit de la branche stable du kernel. Cela signifie que le patch sera surement corrigé et soumit plus tard (2.6.34, par exemple).

Thu, 10 Dec 2009 09:26:45 -0800: Réaction de Yinghai, le commiter. D'après les traces, il voit d'où vient le problème, même si c'est un peu cryptique: "mptable mpc is [12 - f011]. what a BIOS !".

Thu, 10 Dec 2009 10:41:42 -0800: Réaction de Roland Dreier. Il est en relation directe avec les développeur du BIOS en question. Il demande quelques détails.

Thu, 10 Dec 2009 10:42:00 -0800: Yinghai propose un patch, sans succès.

Thu, 10 Dec 2009 13:07:22 -0800: Yinghai fait une seconde tentative.

Fri, 11 Dec 2009 09:19:02 +0100: Réponse de Jens sur le patch de Yinghai: Ca marche.

Fri, 11 Dec 2009 09:32:07 +0100: Remerciement de Ingo Molnar. Le patch sera bientôt intégré au repository de Linus. 74h après le pull, 24h après l'alerte, le problème est réglé.

En parallèle, Roland gère le problème avec le équipe de développement du Bios.