Journal Contribuer au noyau Linux, tu peux le faire!

Posté par gnumdk (site web personnel) le 30 août 2026 à 13:45. Licence CC By‑SA.

Étiquettes :

août

2026

J'utilise GNU/Linux depuis 1999 et, durant toutes ces années, j'ai contribué à beaucoup de logiciels libres (Owncloud, KDE, GNOME, LineageOS…) et travaillé sur plusieurs projets perso (Lollypop, Mobile Power Saver…). Mais un composant m'a toujours fait peur : le noyau Linux. Dans ce journal, je vais montrer comment j'ai fini malgré moi par mettre le nez dedans, et pourquoi, pour du débogage, il n'est pas forcément nécessaire d'être une brute en programmation.

N'ayant pas fait de longues études (DUT info), je me suis toujours senti trop peu compétent pour espérer ne serait-ce que comprendre le code du noyau, surtout en n'y connaissant rien en électronique…

En 2021, je commence à m'intéresser au noyau Dora pour mon OnePlus 7 Pro. Je me mets à lire les commits de la communauté (Sultan Alsawaf, Danny Lin…) pour optimiser le fonctionnement du téléphone, et effectivement, comparé au noyau d'origine de OnePlus, Dora permet d'obtenir de bien meilleures performances pour une bien meilleure économie d'énergie.

C'est dans ce contexte que je travaille sur un petit module noyau, cpu-min-freq, basé sur cpu_input_boost de Sultan Alsawaf. Le but est de faire passer le CPU en basse consommation quand le téléphone ne fait rien. Rien de bien compliqué : le code de cpu_input_boost est assez simple, et je me rends compte que tant qu'on ne touche pas directement au matériel, j'arrive à comprendre du code noyau.

Je migre ensuite de LineageOS vers Droidian, et je continue à "moder" le noyau avec les commits de la communauté Android, mais sans retoucher moi-même au code du noyau.

Puis, l'année dernière, je ressors mon vieux OnePlus 6 sous postmarketOS. Les appels audio fonctionnent enfin, ou presque : une fois sur deux, le haut-parleur d'écoute (earpiece) ne fonctionne pas pendant les appels. Un peu mieux que trois ans auparavant, mais pas encore satisfaisant.

Comme le bug semble se situer côté noyau, je me décide à regarder de plus près. Je télécharge linux-next, j'applique les patchs linux-sdm845, et là, c'est le drame : l'audio fonctionne encore moins bien. Malgré tout, les logs du noyau me permettent de trouver rapidement le commit à l'origine du problème et de proposer un correctif :
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=8a066a81ee0c1b6cdbd81393536c3b2d19ccef25

Je peux enfin m'attaquer au bug du earpiece — ça va être long : un mois à déboguer le module wcd934x en cause. À force d'ajouter des messages de debug un peu au hasard, je remarque qu'un chemin d'exécution n'est pas emprunté quand je bascule vers le earpiece. À partir de là, je trouve rapidement le problème : un compteur de référence non décrémenté. Je corrige, et tout fonctionne enfin correctement :
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=f8d51e903a6c97d8d298f14d9f8b4fff808670e3

Je suis aux anges : je peux enfin utiliser un téléphone Linux (et non Linux + Android comme avec Droidian) comme téléphone principal. Tout n'est pas parfait, mais vu mon usage, ça fait largement l'affaire.

J'en profite pour continuer sur ma lancée en corrigeant deux traces qui traînaient dans le dmesg pendant le fonctionnement du téléphone :

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=961c900628fef77ad07b4bc4c868e47b9a1269c7
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=3367c5a129f74812806034fa0a106a1c3e4a3890

Il reste encore des bugs, en particulier un crash aléatoire au démarrage, mais je n'arrive pas à en récupérer les logs. Il faudrait que je monte un dispositif électronique connecté directement à la carte mère du téléphone, et là, sans aide, je me sens clairement incompétent.

De mon côté, je travaille depuis trois ans sur un projet, Mobile Power Saver, pour optimiser la consommation de batterie des téléphones sous Linux. Sous Droidian, avec un Redmi Note 9 Pro, j'arrive à deux jours d'autonomie ; mais sous postmarketOS, impossible de dépasser une journée.

J'identifie rapidement que Wireplumber utilise un moniteur libcamera qui laisse un sous-périphérique V4L2 ouvert. Je soupçonne un bug dans Pipewire ou Wireplumber, mais je n'ai pas le temps de lire le code de ces deux projets.

Puis, vendredi, je tombe sur un commentaire qui indique que la commande "rmmod i2c_qcom_cci" divise la consommation de la batterie par deux ! Je file sur le salon Matrix de Pipewire, où l'on m'explique que garder un sous-périphérique V4L2 ouvert ne devrait pas poser problème : pour eux, le bug est côté noyau.

Je commence à examiner /sys/kernel/debug/regulator/regulator_summary et je remarque que des régulateurs liés à la caméra sont bien actifs et consomment de l'énergie. Après de longues recherches, je comprends que le nom du régulateur contient son adresse physique, ce qui me permet de retrouver le nom du driver associé dans /sys/bus/i2c/devices/17-0074/name, à savoir lc898217xc.

Une fois le nom du module en main, je regarde le code : c'est assez clair. À l'ouverture du périphérique, on sort de veille ; à la fermeture, on y retourne. Cela correspond exactement à ce que j'observe : Wireplumber ouvre le sous-périphérique, et la consommation reste donc active même quand la caméra n'est pas utilisée. Je comprends aussi que ce module gère le moteur chargé de la mise au point.

Le code est assez simple à corriger : je déplace la gestion de la mise en veille vers la fonction qui gère la mise au point. En théorie, ça devrait suffire.
- Je redémarre : les régulateurs sont bien éteints.
- Je lance l'application caméra : ils s'allument.
- Je fais une mise au point : ça fonctionne !

https://gitlab.com/gnumdk/linux/-/commit/7d96fbc6437ffb6036795e7cabc460fea03601e3

Sauf qu'au bout d'une seconde, la mise au point revient à sa position initiale ! Après quelques recherches, je comprends le fonctionnement de ce genre de moteur : c'est un "ressort", et la mise au point ne tient que tant que le moteur est alimenté. Si je remets le module en veille au bout d'une seconde, la position revient donc à son état de repos.

J'avais déjà entendu parler d'une méthode pour lier des périphériques entre eux, et je finis par retomber sur cette documentation :
https://www.kernel.org/doc/html/latest/driver-api/device_link.html

Il existe aussi un mécanisme pour lier des périphériques média entre eux via le devicetree du noyau Linux (https://www.kernel.org/doc/html/latest/devicetree/usage-model.html). En ajoutant un nouveau flag, je peux ainsi lier le capteur de la caméra et le moteur de mise au point pour la gestion de la mise en veille : le moteur reste donc actif tant que la caméra l'est aussi.

Je redémarre : ça marche, chouette !

https://gitlab.com/gnumdk/linux/-/commit/1615085aecba5879df789c399b8ccceb10cdd0fe

Je teste le correctif pendant quelques jours, puis je vais envoyer mes deux patchs à la LKML :
- c'est bien old school d'envoyer un patch par e-mail, obligé de relire la doc à chaque fois :)
- même si mon correctif fonctionne, ce n'est pas forcément la bonne façon de faire

Voilà, en attendant les retours des mainteneurs de linux-media. Et pour conclure, si tu identifies un bug dans le noyau Linux, dis-toi que tu peux possiblement le corriger (si tu connais le C par contre).

# Extra !

Posté par Luc-Skywalker le 30 août 2026 à 14:40. Évalué à 10 (+8/-0).
Je me suis régalé à la lecture de ce journal, merci :)

Pas vraiment programmeur dans l'âme (encore moins en C), j'ai pourtant bien suivi le propos (ceci je pense, parce que, comme tout le monde j'ai été confronté à ce genre de désagréments de bas niveau).

Maintenant je regarde le dernier commit cité dans le journal:
```
if (IS_ERR(link))
        return PTR_ERR(link);

    if (sd->flags & V4L2_SUBDEV_FL_PM_LINK) {
        devlink = device_link_add(n->sd->dev, sd->dev,
                       DL_FLAG_PM_RUNTIME |
                       DL_FLAG_AUTOREMOVE_CONSUMER);
        if (!devlink)
            dev_warn(notifier_dev(n),
                 "failed to link power management of %s to %s\n",
                 dev_name(sd->dev), dev_name(n->sd->dev));
    }
```
j'ai compris le pb mais pas comment on le résoud en vrai, pourtant c'est écrit la !!!

Ça pourrait faire une dépêche bien rafraichissante pour la rentrée non ?

"Si tous les cons volaient, il ferait nuit" F. Dard
Répondre
- [^] # Re: Extra !
  
  Posté par gnumdk (site web personnel) le 30 août 2026 à 14:50. Évalué à 7 (+5/-0).
  Pour détailler, dans le dts de mon téléphone il y'a ça:
```
[~/Projets/pmos/git/linux](pmos)$ grep -r lens-focus arch/arm64/boot/dts/
arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi:        lens-focus = <&rear_cam_actuator>;
arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi:        lens-focus = <&sub_cam_actuator>;
```
  Cela crée un lien entre la caméra et le moteur du focus. J'ai pas cherché midi à quatorze heure, je suis parti du principe que c'est le meilleur endroit pour créer un lien au niveau gestion de l'énergie entre les deux périphériques. Je laisse juste le soin au driver du moteur de dire qu'il veut entre lié via le nouveau flag V4L2_SUBDEV_FL_PM_LINK, en particulier parce que pour l'option dts "flash-leds", cela ne fonctionne pas, on peut avoir la camera active et le flash inactif.
  
  Mais bon, comme je le dis, on va peut-être me dire que taper l'incruste dans cette fonction n'est pas la bonne façon de faire, et qu'il faudrait mieux rajouter une nouvelle option dts genre "link-pm", ça va vouloir dire un patch plus conséquent.
  Répondre
# Le noyau est moins spécial ou complexe qu'on ne le pense

Posté par Renault (site web personnel) le 30 août 2026 à 17:43. Évalué à 10 (+11/-0).

J'utilise GNU/Linux depuis 1999 et, durant toutes ces années, j'ai contribué à beaucoup de logiciels libres (Owncloud, KDE, GNOME, LineageOS…) et travaillé sur plusieurs projets perso (Lollypop, Mobile Power Saver…). Mais un composant m'a toujours fait peur : le noyau Linux. Dans ce journal, je vais montrer comment j'ai fini malgré moi par mettre le nez dedans, et pourquoi, pour du débogage, il n'est pas forcément nécessaire d'être une brute en programmation.

La noyau Linux est gros et un peu spécifique mais c'est loin d'être si complexe d'y contribuer, il ne faut clairement pas avoir peur d'y mettre son nez dedans. Il y a certainement des projets plus complexes fondamentalement selon la zone qui nous intéresse comme un navigateur web ou un compilateur.

Une partie de la difficulté du noyau c'est sa compilation, ça reste plus difficile de compiler et tester que la plupart des logiciels mais avec un peu de lecture et de connaissance générique en programmation ça n'est pas réellement un obstacle. Le test peut être plus difficile aussi, mais il y a maintenant beaucoup d'outils efficaces ou la possibilité d'utiliser des machines virtuelles par exemple pour s'en sortir. Je pense que la plupart des programmeurs même non experts du C ou C++ peuvent aborder cela avec un peu de lecture préalable.

Après niveau code, une bonne partie du noyau sont des pilotes de périphériques et c'est ce qui intéresse la plupart des personnes d'ailleurs. Nombre d'entre eux sont assez simples et se ressemblent ce qui aide à en écrire ou à corriger. Y toucher est relativement facile pour ceux là et ne sont pas plus complexes que beaucoup de code orienté objet qu'on peut croiser.

Pour les composants plus complexes (type carte graphique) ça peut être effectivement délicat, mais c'est souvent plus le périphérique lui même qui est complexe que le code noyau associé en tant que tel. Toucher aux sous systèmes entiers peut être aussi difficile car notamment le code est générique et couvre des sujets complexes, avec des optimisations et doit gérer des cas d'usage très variés. En général la meilleure approche c'est de se familiarisé par étape, par exemple si on veut toucher à la partie générique du système de fichiers (VFS), il peut être judicieux de d'abord s'attaquer à un système de fichiers simple avant de regarder le code générique qu'il appelle pour comprendre les contextes d'utilisation. Regarder l'historique des changements est aussi utile.

Par contre je pense que maintenir ces sous systèmes génériques est un grand challenge car il faut prendre en compte cette variété de cas d'usage et en avoir conscience des impacts potentiels de chaque changement ce qui n'est pas trivial du tout.

En tout cas n'hésitez pas à bidouiller un peu, si vous avez déjà programmé le noyau Linux n'est pas si spécial que ça, il n'a jamais été aussi facile de tester des changements rapidement et sans grandes conséquences. Le code est pour une bonne part pas si complexe qu'on pourrait le croire.

Répondre
- [^] # Re: Le noyau est moins spécial ou complexe qu'on ne le pense
  
  Posté par BAud (site web personnel) le 30 août 2026 à 20:32. Évalué à 6 (+4/-0).
  
  une bonne partie du noyau sont des pilotes de périphériques et c'est ce qui intéresse la plupart des personnes d'ailleurs
  
  et pour s'y retrouver : https://makelinux.github.io/kernel/map/
  
  oui, si tu restes niveau matériel « electronics » (tout en bas en gris) ou dans la colonne « human interface », c'est relativement compréhensible (surtout « user peripherals » et « network device drivers » àmha).
  la ligne « device control » est intéressante et un peu plus complexe.
  
  Répondre
  - [^] # Re: Le noyau est moins spécial ou complexe qu'on ne le pense
    
    Posté par gnumdk (site web personnel) le 30 août 2026 à 21:14. Évalué à 7 (+5/-0).
    
    Je crois vraiment que le truc le plus incompréhensible pour moi, c'est le scheduler du noyau. Et les commits qui corrigent les erreurs du commit x qui lui-même corrigeait les erreurs du commit y :-)
    
    Répondre
- [^] # Re: Le noyau est moins spécial ou complexe qu'on ne le pense
  
  Posté par abriotde (site web personnel, Mastodon) le 01 septembre 2026 à 01:39. Évalué à 7 (+5/-0). Dernière modification le 01 septembre 2026 à 01:39.
  
  Il faut quand même relativiser. On ne commence pas à publier dans le noyau Linux. Parce que déjà, avant de vouloir toucher dedans, il faut avoir repérer un problème dedans. Et comme l'erreur est le plus souvent entre la chaise et le clavier, le problème est plus souvent dans les logiciels autours.
  L'auteur de l'article, n'est d'ailleurs pas un novice de la publication, mais plus encore, quelqu'un qui passe beaucoup, beaucoup de temps sur des considérations bas niveau. Donc en plus d'avoir beaucoup publié, il a beaucoup installé des noyau, et "en embarqué" et beaucoup touché aux configurations du noyau. Il reste modeste, mais ce n'est qu'une étape de plus dans une longue avancée.
  
  Basiquement, oui, le noyau n'est pas inabordable. Mais avant de réussir à trouver quelque chose à toucher dans le noyau… il faut s'y mettre et ne pas compter ses heures.
  Mais je pense que c'est vrai partout, dans tous l'informatique. L'avantage de l'informatique, c'est qu'ils n'y a pas besoin de matériels coutant des dizaine de milliers d'euros (contrairement a bien des domaines - quoique). Juste du temps, de la patience et du travail.
  
  Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
  
  Répondre
  - [^] # Re: Le noyau est moins spécial ou complexe qu'on ne le pense
    
    Posté par gnumdk (site web personnel) le 01 septembre 2026 à 07:03. Évalué à 5 (+3/-0).
    
    Sur mon laptop, j'ai pas compilé un noyau depuis 2003, et encore moins regardé le code de ce dernier… C'est vrai que Linux sur téléphone c'est un bon moyen de rentrer dans le bousin parce que des bugs, y'en a plein.
    
    Répondre
    - [^] # Re: Le noyau est moins spécial ou complexe qu'on ne le pense
      
      Posté par par le 02 septembre 2026 à 08:14. Évalué à 2 (+1/-0).
      
      Du coup, je ne comprend pas. Comment tu vérifie ce que tu code, si tu ne compile pas les modifications du noyau que tu as faites ?
      
      Répondre
      - [^] # Re: Le noyau est moins spécial ou complexe qu'on ne le pense
        
        Posté par gnumdk (site web personnel) le 02 septembre 2026 à 08:43. Évalué à 4 (+2/-0).
        
        Parce que je code rien en lien avec mon laptop mais uniquement pour mon téléphone. Donc bien sûr que je build le noyau pour mon tel via pmbootstrap ;)
        
        Répondre
    - [^] # Re: Le noyau est moins spécial ou complexe qu'on ne le pense
      
      Posté par BAud (site web personnel) le 06 septembre 2026 à 21:28. Évalué à 4 (+2/-0).
      
      bof, depuis le noyau 2.6.x généralement recompiler un module noyau est largement suffisant (c'est ce que je me contentais de faire pour eagle_usb et ueagle_atm ensuite pour gérer le modem USB fast 800 fourgué par free).
      Moi aussi, j'ai compilé un noyau en 2003, eh bien ça m'a montré que ça bootait moins bien ensuite :D alors qu'au millénaire dernier c'était un peu obligatoire jusqu'au noyau 2.4…
      
      Ensuite j'ai fait l'erreur de tenter de compiler OpenOffice :p heureusement que Collabora a amélioré la situation avec LibreOffice (déjà mettre en œuvre make -j 4 pour utiliser les 4 cœurs de mon portable stait bien, moins pour les 16 Go de RAM qui auraient été nécessaires a minima pour ne pas swapper comme un goret et les 20 Gio voire 40 Gio pour gérer tous les fichiers temporaires générés par la compilation…).
      
      Répondre
# lien vers les discussions LKML ?

Posté par YvanM le 31 août 2026 à 21:47. Évalué à 3 (+2/-0).

Merci pour ce journal, et pour les patchs envoyés !

Mon téléphone est un OnePlus 6 sous postmarketOS, ces améliorations m'intéressent donc beaucoup : aurais-tu un ou plusieurs liens vers ces soumissions de patch ? J'aimerais bien pouvoir suivre les retours et (j'espère) l'inclusion dans la branche principale.

Répondre
- [^] # Re: lien vers les discussions LKML ?
  
  Posté par gnumdk (site web personnel) le 01 septembre 2026 à 07:01. Évalué à 6 (+4/-0).
  
  Tout les patches sauf les deux du gitlab sont déjà inclus dans Linux 7.3.
  
  Pour les deux derniers, pas eu le temps encore ;)
  
  Répondre
# Mise au point

Posté par cg le 05 septembre 2026 à 11:30. Évalué à 3 (+1/-0).

Merci pour ton journal, en plus du sujet principal, ça m'a permis d'apprendre qu'il y a donc une vraie mise au point mécanique et optique dans certains téléphones.

Répondre
# Tempus fugit

Posté par pieq (site web personnel, Mastodon) le 06 septembre 2026 à 21:04. Évalué à 4 (+3/-0).

Merci pour ce journal très intéressant. Je pense qu'il faut quand même une sacrée dose de patience et de curiosité pour en arriver à installer postmarketos sur un téléphone et se dire qu'on va le débugger quand un problème survient…

D'ailleurs, est-ce que tu as une idée du nombre d'heures que tu as passées sur ces différents problèmes ?

Et une autre question : comment sais-tu vers qui te diriger pour discuter et poser des questions ? Plus on creuse, plus il y a de couches qui interagissent entre elles, plus j'imagine qu'il est difficile de trouver le coupable ? (et je n'ose même pas imaginer quand le problème se situe entre deux couches qui communiquent mal et qui se rejettent la faute mutuellement…).

Répondre
- [^] # Re: Tempus fugit
  
  Posté par pulkomandy (site web personnel, Mastodon) le 08 septembre 2026 à 14:03. Évalué à 6 (+3/-0). Dernière modification le 08 septembre 2026 à 14:03.
  
  D'ailleurs, est-ce que tu as une idée du nombre d'heures que tu as passées sur ces différents problèmes ?
  
  La liberté n'a pas de prix!
  
  comment sais-tu vers qui te diriger pour discuter et poser des questions ? Plus on creuse, plus il y a de couches qui interagissent entre elles, plus j'imagine qu'il est difficile de trouver le coupable ?
  
  Ce n'est pas forcément très grave de demander au mauvais endroit. Les gens d'un projet seront même peut-être plus motivés pour démontrer que le problème n'est pas chez eux, que pour le corriger.
  
  Répondre
# et alors les retours ?

Posté par orfenor le 18 septembre 2026 à 10:33. Évalué à 2 (+0/-0).

Elle a dit quoi l'équipe de mainteneurs? Seulement "ok" ou bien c'était assorti de remarques?

Répondre

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.