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 GG (site web personnel) . Évalué à 8.
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
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Réaction chimique
Posté par Pinaraf . Évalué à 8.
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 benoar . Évalué à 2.
Rappel : votre premier réflexe doit être d'enlever la batterie du bouzin.
# Quelles diodes?
Posté par claudex . Évalué à 1.
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 imr . Évalué à 3.
[^] # Re: Quelles diodes?
Posté par claudex . Évalué à 2.
« 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 Pinaraf . Évalué à 7.
# doc' à foison
Posté par BAud (site web personnel) . Évalué à 6.
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...)
[^] # Re: doc' à foison
Posté par Pinaraf . Évalué à 6.
[^] # Re: doc' à foison
Posté par BAud (site web personnel) . Évalué à 2.
comme http://svn.gna.org/viewcvs/ueagleatm/trunk/ueagle-atm/Makefi(...)
# commit
Posté par B16F4RV4RD1N . Évalué à 10.
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 Florent Fourcot . Évalué à 6.
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.
[^] # Re: Allergique à Git, n'ayez pas peur
Posté par wahnby . Évalué à 4.
# Bon ben...
Posté par windu.2b . Évalué à 3.
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 patrick_g (site web personnel) . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.