Journal De l'écriture d'un pilote Linux pour un gadget - suite

Posté par .
47
17
août
2010
Cher journal

Je t'ai expliqué tantôt un à-peu-près guide (plutôt une rétrospective) sur l'écriture d'un pilote Linux pour un gadget plutôt débile : les diodes d'un PC portable Toshiba (cf. https://linuxfr.org/~PieD/29986.html pour tout relire si ça vous dit, mais c'est long et y'a quand même quelques fautes).
J'ai fait chier proposé sur les mailing lists le pilote, sous forme de patch, et il a été intégré dans le noyau aux environs du 3 août, et est donc présent dans le noyau 2.6.36-rc1.
Bon, par contre, la mauvaise nouvelle, c'est que je ne peux pas tester sur le PC portable de mon pote. La réaction chimique suivante a eu lieu : PC + H2O = PC cassé.

Je vais indiquer tout de même ici la démarche que j'ai suivi pour le test et la soumission du pilote.

0) Environnement requis
- Le nécessaire pour compiler un pilote (gcc, make, les en-têtes du noyau...)
- Git (attention, si vous êtes allergiques à git, vous n'avez aucune chance de contribuer au noyau)
- Le matériel pour tester votre pilote, quand même un peu...

Ensuite, configurez git et récupérez le dernier noyau pour la branche de votre pilote. Dans mon cas, le pilote toshiba_acpi est dans drivers/platform/x86, ce qui correspond à la branche platform-drivers-x86 du noyau.
Voici les manipulation pour la configuration et la récupération du noyau :
- git config user.name <votre nom>
- git config user.mail <votre adresse mail>
- git clone git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86.git

1) Compilation du pilote tout seul
Par défaut, les pilotes doivent être "intégrés" dans l'arbre du noyau, dans le sous-dossier drivers. Ce côté tout-en-un est très très pratique, mais je ne me voyais pas recompiler un noyau différent pour faire les tests... (En vertu d'un paramètre majeur : la flemme).
Donc j'ai extrait le pilote toshiba_acpi du dernier noyau pour le compiler à part (il contient juste un fichier, toshiba_acpi.c), avec juste un makefile tout bête.
Voici le fichier Makefile correspondant :

obj-m += toshiba_acpi.o

all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean


Donc la compilation se fait avec un simple make, et cela fait apparaître un fichier toshiba_acpi.ko. Il suffit ensuite de le charger/décharger avec les classiques insmod/rmmod.
Nous avons donc le pilote toshiba_acpi, dans sa dernière version, compilable, bidouillable, testable à souhait.

2) Patcher le pilote
Le patch du pilote est la partie la plus fun.
Rappelez-vous, vous êtes en espace noyau, allez-y doucement, ne faîtes pas les cons...
Dans mon cas, le patch était très simple, j'ai procédé en deux étapes :
a) écriture des fonctions pour allumer/éteindre les diodes, avec des appels dans la fonction d'initialisation du module pour tester directement au insmod si ça marche ou pas
b) implémentation de la classe led
Si possible, utilisez git proprement pour commiter (utilisez l'option -s pour ajouter les "Signed-off") lorsque vous atteignez des étapes importantes (si toutefois votre travail nécessite plusieurs étapes).

3) Envoi du patch
Bon, je me suis auto-flagellé pour ne pas avoir lu la documentation incluse dans le noyau sur l'envoi de patchs, alors je le dis ici : suivez ce guide, le guide du noyau (Documentation/SubmittingPatches) ou tout guide officiel, mais surtout pas votre "instinct".
La méthode est simple : c'est basé à 100% sur git... (Qui est définitivement plus qu'un simple gestionnaire de versions, vu qu'il gère tout le workflow du noyau Linux...)
- commitez vos modifications (sans dec')
git commit -sa
- préparez un patch ou un ensemble de patchs à partir de vos commits :
git format-patch origin -o /home/moi/working_directory/patchs
- récupérez, à l'aide d'un script du noyau, la liste des mainteneurs du code que vous modifiez
./scripts/get_maintainer.pl /home/moi/working_directory/patchs/*
- lancez une vérification de vos patchs (hou qu'elle est méchante elle)
./scripts/checkpatch.pl /home/moi/working_directory/patchs/*
- envoyez le patch par mail à la mailing list...
git send-email --to=<mailing list principale> -cc=<mainteneur 1> -cc=<mainteneur ...> -cc=<mainteneur N>

4) Soyez content
Voilà, vous avez contribué à l'un des plus grands projets libres, l'un des plus célèbres en tout cas.
Pour info, vous trouverez le pilote pour les diodes toshiba dans le noyau 2.6.36-rc1... Et si vous pouviez tester, ça me ferait plaisir ....


À (très) bientôt pour de nouvelles aventures (hé oui, mon pote a acheté une nouvelle machine...)
  • # Réaction chimique

    Posté par (page perso) . Évalué à 8.

    Bonsoir,

    normalement, en faisant sécher le tout, ça devrait repartir une fois bien sec.

    Pour les écrans RTC j'attend(ai)s une semaine avant allumage.

    Bon courage et merci pour le retour, c'est toujours intéressant à lire.
    G
    • [^] # Re: Réaction chimique

      Posté par . Évalué à 8.

      Bonsoir

      Mon pote a, je pense, pas eu les bons réflexes, résultat il y a eu un court-circuit au niveau de la carte mère... et PAF quoi...
      • [^] # Re: Réaction chimique

        Posté par . Évalué à 2.

        D'ailleurs, je me demande toujours pourquoi le premier réflexe des gens est de rallumer le machin quand celui-ci vient de « sauter » à cause d'une bêtise comme ça.
        Rappel : votre premier réflexe doit être d'enlever la batterie du bouzin.
  • # Quelles diodes?

    Posté par (page perso) . Évalué à 1.

    Pour info, vous trouverez le pilote pour les diodes toshiba dans le noyau 2.6.36-rc1... Et si vous pouviez tester, ça me ferait plaisir ....

    J'ai un portable toshiba, donc je pourrais tester mais ça correspond à quoi cette histoire de diode? Je n'ai pas de problème de diode, je ne suis pas concerné? Ou c'est pour les faire clignoter?

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Quelles diodes?

      Posté par . Évalué à 3.

      tu as un Toshiba Qosmio G50 122 ou similaire?
      • [^] # Re: Quelles diodes?

        Posté par (page perso) . Évalué à 2.

        Non, c'est un Satellite.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Quelles diodes?

      Posté par . Évalué à 7.

      Il s'agit de diodes éclairant le PC, sur le côté, autour du clavier... Toshiba appelle ça "illumination". Elles peuvent être éteintes, sous Windows, à l'aide d'un bouton sur le clavier. Sous Linux, elles restaient allumées en permanence, c'était pénible.
  • # doc' à foison

    Posté par (page perso) . Évalué à 6.

    Effectivement toute la doc' est livrée avec le code source du noyau c'est _très_ utile ;-)
    et comme pour certains des URLs sont plus pratiques :
    http://www.kernel.org/doc/Documentation/SubmittingPatches

    et plus globalement, une vraie mine d'or : http://www.kernel.org/doc/Documentation/

    par ailleurs, une carte (ou un plan) du noyau est aussi dispo http://www.makelinux.net/kernel_map
    Vous trouverez encore d'autres liens sur
    http://cookerspot.tuxfamily.org/wikka.php?wakka=Blog20080509(...) sur lequel j'avais pris des notes

    ah sinon,
    Il suffit ensuite de le charger/décharger avec les classiques insmod/rmmod.
    ou modprobe et modprobe -r (comme remove) ;-) (bon si tu n'as pas de dépendances à d'autres pilotes, pas trop besoin...)
  • # commit

    Posté par . Évalué à 10.

    pour ceux qui voudraient voir le commit en question, c'est ici :

    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)

    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # Allergique à Git, n'ayez pas peur

    Posté par . Évalué à 6.

    Je voudrais tout de même nuancer un peu le propos. Git est loin d'être obligatoire, un patch fait avec "diff" peut largement suffire. C'est certain que c'est plus propre de suivre les règles et de suivre la documentation, mais pour quelqu'un de discret les développeurs du noyaux sont tout de même relativement compréhensifs (pour en tout cas mon expérience individuelle).

    Bravo en tout cas pour ces explications pas à pas, je pense que la peur de mal faire peut bloquer beaucoup de contributeurs à franchir le pas.
  • # Bon ben...

    Posté par . Évalué à 3.

    Y a plus qu'à attendre la dépêche du noyau 2.6.36. J'espère que, juste pour le fun, patrick_g nous en touchera un mot :-)

    Ah tiens, petite question comme ça : combien de DLFPiens ont déjà participé au dév du noyau ? Et pour quelle(s) branche(s) ?

    PS : à propos de branches, c'est normal cette inversion des mots ?
    "le pilote toshiba_acpi est dans drivers/platform/x86, ce qui correspond à la branche platform-drivers-x86 du noyau."
    • [^] # Re: Bon ben...

      Posté par (page perso) . Évalué à 2.

      >>> J'espère que, juste pour le fun, patrick_g nous en touchera un mot :-)

      Bien entendu c'est déjà prévu et ce sera l'objet d'une brève.

Suivre le flux des commentaires

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