Participez au développement du noyau Linux : c’est à votre portée !

Le noyau Linux fait peur. On l’imagine réservé à une élite bardée de diplômes. Pourtant, après des années d’open source, j’ai découvert que ce monolithe de code source est plus accessible qu’on ne le croit.

Premiers pas dans le kernel avec un smartphone

Mon aventure commence en 2021 avec un OnePlus 7 Pro. Je m’intéresse au noyau Dora, une alternative au kernel d’origine. La communauté autour de Sultan Alsawaf et Danny Lin fourmillent d’optimisations.

Je me mets à lire les commits et, à ma grande surprise, je comprends une bonne partie du code. Je développe un petit module nommé cpu-min-freq, basé sur cpu_input_boost. L’idée est simple : faire passer le CPU en basse consommation quand le téléphone ne fait rien.

Tant qu’on ne touche pas au matériel, le développement logiciel du noyau reste compréhensible. C’est mon premier pas concret dans le monde du kernel. Et cette réussite m’a donné envie d’aller plus loin.

Un bug audio en cascade, ou comment plonger dans le code

En 2025, je ressors mon vieux OnePlus 6 sous postmarketOS. Les appels fonctionnent enfin, sauf que le haut-parleur d’écoute ne s’active qu’une fois sur deux. Le bug semble venir du système d’exploitation, plus précisément du kernel.

Je télécharge linux-next et j’applique les patchs linux-sdm845. Là, c’est le drame : l’audio fonctionne encore moins bien. Mais grâce aux logs, je remonte rapidement au commit fautif.

J’ai passé un mois à déboguer le module wcd934x. À force d’ajouter des messages de debug au hasard, j’ai repéré un chemin d’exécution qui n’est pas emprunté. Le problème, c’est un compteur de référence non décrémenté.

Une fois le correctif appliqué, tout fonctionne enfin. Vous pouvez voir la modification dans ce commit. J’en ai profité pour nettoyer deux traces dmesg, comme le montrent ces deux correctifs.

La chasse aux watts avec le noyau Linux

Sur mon Redmi Note 9 Pro, postmarketOS ne tient qu’une journée au lieu de deux. Je suspecte Wireplumber de garder un sous-périphérique V4L2 ouvert. Un commentaire sur Matrix me met la puce à l’oreille : la commande rmmod i2c_qcom_cci divise la consommation de moitié.

Le coupable : le module de mise au point

J’examine regulator_summary et je repère des régulateurs liés à la caméra toujours actifs. Le nom du driver associé est lc898217xc. Ce module gère le moteur de mise au point.

Le code est assez clair. À l’ouverture du périphérique, le module sort de veille. À la fermeture, il y retourne, sauf que Wireplumber garde le périphérique ouvert.

Je déplace donc la gestion de la veille vers la fonction qui gère la mise au point. Je redémarre et les régulateurs sont bien éteints. Je lance l’appareil photo et tout se rallume normalement.

Sauf qu’au bout d’une seconde, la mise au point revient à sa position initiale. Ce moteur est un ressort : il ne maintient la position que tant qu’il est alimenté. Si je le remets en veille, la position revient à zéro.

C’est là que j’ai pensé aux device links. Cette mécanique permet de lier des périphériques entre eux pour la gestion de la veille. En ajoutant un flag, je lie le capteur de la caméra au moteur de mise au point.

Résultat : le moteur reste actif tant que la caméra est ouverte. Je redémarre et ça marche. Deux jours d’autonomie enfin !

Les deux correctifs sont visibles dans mes dépôts GitLab, ici et là. J’ai testé le tout pendant plusieurs jours avant de les envoyer à la liste de discussion du noyau. C’était une expérience enrichissante de bout en bout.

L’envoi des patchs à la LKML, une dernière étape old school

Une fois les correctifs testés, il reste à les envoyer à la LKML, la liste de diffusion du noyau. On envoie un patch par e-mail, c’est très old school. J’ai du relire la documentation plusieurs fois, mais j’ai réussi à publier mes deux modifications.

Bien sûr, ma solution n’est pas forcément la meilleure. Les mainteneurs de linux-media peuvent demander des ajustements. Mais l’important est d’avoir participé à la collaboration autour du noyau.

Si vous identifiez un bug dans le noyau Linux, pourquoi ne pas tenter de le corriger ? Il faut juste connaître la programmation en C et accepter de se tromper. La communauté Linux est beaucoup plus accueillante qu’on ne l’imagine.

Source: linuxfr.org