Petite question pour sl33p3r (et ceux qui ont compris la répartition des rôles
entre eaglectrl / le module, je suis pas tout à fait sûr d'en faire partie
d'ailleurs).
Ce que j'en ai compris :
- module => firmware => modem
- eaglectrl => code DSP (bnm) => module => modem (ou alors eaglectrl direct
vers modem sans passer par le module ?)
après ya ethX => module => modem ???
J'ai du mal à comprendre les interfaces (j'ai pas lu le code, non plus...),
j'ai (quasi ?) bon ?
Bref, ma demande d'évol' : Il y a eaglectrl -v qui donne maintenant la version
utilisée pour compiler eaglectrl. Or mcoolive me faisait à raison remarquer
que dans ses paquets pour debian,
- eaglectrl a de grande chance de ne pas avoir été recompilé (donc ce serait
la version du compilo de mcoolive)
- et le module - lui - une très grande chance d'avoir été recompilé (ouais ok
Gentoo powaaa mais bon tout le monde n'a pas une distrib' aussi évoluée ;-) )
Donc serait-il possible d'obtenir (par eaglestat ???) la version de gcc
utilisée pour compiler le module eagle-usb ?
La question qui suit est - logiquement - pourquoi le compilo a moins d'impact
sur eaglectrl que sur le module ? ya pas de structure gérée par eaglectrl ?
les interfaces avec le module sont mieux normalisées ? Et oui je comprends
tout à fait que le module étant dans le kernel, il vaut mieux l'avoir compilé
avec la même version que le kernel :
- c'est flagrant entre le 2.95 et les 3.x
- parfois entre le gcc 3.3 et le 3.4 ça joue pas tant que ça (même si cela
semble provoquer plus d'erreur d'urb donc avec l'usb...)
Cela permet au passage de sensibiliser au fait que le compilateur utilisé pour
compiler le kernel - dans le meilleur des mondes - devrait être disponible sur
chaque distrib' (comme le fait debian d'ailleurs en gardant deux versions : un
gcc-2.95 et un gcc quasi à jour). M'enfin après j'imagine les soucis avec la
libc ;-)
> - eaglectrl a de grande chance de ne pas avoir été recompilé (donc ce serait
> la version du compilo de mcoolive)
> - et le module - lui - une très grande chance d'avoir été recompilé
Pour être plus précis c'est compilé chez MOI pour les paquets que JE mets en
ligne. Ceux sur les serveurs ftp Debian ont été recompilés sur une machine des
machines dédiés (plusieurs archis, fermes de compilation...)
Enfin le problème est le même: eaglectrl -v ne permet pas de connaître le
compilateur ayant compilé le module (note: c'est pour eaglediag).
> La question qui suit est - logiquement - pourquoi le compilo a moins d'impact
> sur eaglectrl que sur le module ? ya pas de structure gérée par eaglectrl ?
> les interfaces avec le module sont mieux normalisées ?
Ça je sais (je crois).
Deux manière de communiquer avec le noyau : ioctcl, système de fichier.
eaglectrl utilise ioctcl (seulement ?). En gros le module a enregistré des
fonctions dans une grosse table de pointeurs de fonctions.
Je me souviens plus des détails ne l'ayant pas eu l'occasion de le manipuler. Je
suppose que l'on empile les paramètres sur la pile (c'est typé IOCTL ?) et on
déclenche un appel système avec une entrée dans la fameuse table dans un
certain registre (et il y a une macro qui écrit ça pour nous).
Donc en dehors de l'ordre dans lequel on empile les paramètres sur la pile
d'exécution (défini par l'ABI C) je ne vois pas de contrainte.
> Et oui je comprends
> tout à fait que le module étant dans le kernel.
Là non plus je suis pas expert. Je DEVINE que le chargement de module c'est de
l'édition de liens dynamique. Autrement dit, en compilant un module noyau on
fait de la compilation séparée. Compiler un programme avec UN compilateur
semble effectivement normale (pb avec les noms internes, optimisation sur les
alignements et diverses conventions).
Question pour les experts: je suppose qu'on ne doit jamais stripper un module.
Vrai ?
> Question pour les experts: je suppose qu'on ne doit jamais stripper un module.
> Vrai ?
euh si, tu dois pouvoir le stripper (c'est simplement gagner de la place en
enlevant les équivalences adresse/libellé) mais alors déjà que les Oops sont pas
parlants...
D'ailleurs à ce propos pour les Oops ce serait pas mal d'avoir le module
eagle-usb.ko utilisé pour analyser un peu mieux
En revanche, je vois pas quel outil utiliser ?
Par exemple, comment gdb pourrait-il retrouver ses petits
- dans un module d'une part,
- qui n'est pas foncièrement compatible avec le kernel sur lequel on analyse
d'autre part...
En plus ce n'est pas comme l'analyse d'un core dump ?
Un gdb eagle-usb.ko core ça fonctionnerait ? eagle-usb.ko n'est pourtant pas un
programme en tant que tel ?! Et s'il est en ko.gz ??
| Ce que j'en ai compris :
| - module => firmware => modem
C'est ca ... Lorsqu'un modem pre-firmware est detecte le module lui
envoie le firmware.
| - eaglectrl => code DSP (bnm) => module => modem (ou alors eaglectrl direct
| vers modem sans passer par le module ?)
eaglectrl envoie le code DSP (bnm "compile") au module qui le
receptionne, commence la sequence de boot du modem, et lui envoie la
premiere page de code BNM. Ensuite le modem demande les autres pages a
la volee ... Apparamment il peut les demanedr n'importe quand c'est
pourquoi le driver garde le code BNM en memoire.
| après ya ethX => module => modem ???
Oui ... Enfin ca depend (ca depasse): avec PPPoA par exemple y'a:
(prog) => (pppd) => (pppoa) => (eth) => (module) => (modem)
| j'ai (quasi ?) bon ?
Yop.
|
| Bref, ma demande d'évol' : Il y a eaglectrl -v qui donne maintenant la version
| utilisée pour compiler eaglectrl. Or mcoolive me faisait à raison remarquer
| que dans ses paquets pour debian,
| - eaglectrl a de grande chance de ne pas avoir été recompilé (donc ce serait
| la version du compilo de mcoolive)
| - et le module - lui - une très grande chance d'avoir été recompilé (ouais ok
| Gentoo powaaa mais bon tout le monde n'a pas une distrib' aussi évoluée ;-) )
|
| Donc serait-il possible d'obtenir (par eaglestat ???) la version de gcc
| utilisée pour compiler le module eagle-usb ?
Oui. Il suffirait de garder la version de gcc dans le code ... Ensuite
le plus simple serait de le faire afficher par eaglestat ...
|
| La question qui suit est - logiquement - pourquoi le compilo a moins d'impact
| sur eaglectrl que sur le module ? ya pas de structure gérée par eaglectrl ?
| les interfaces avec le module sont mieux normalisées ? Et oui je comprends
| tout à fait que le module étant dans le kernel, il vaut mieux l'avoir compilé
| avec la même version que le kernel :
| - c'est flagrant entre le 2.95 et les 3.x
| - parfois entre le gcc 3.3 et le 3.4 ça joue pas tant que ça (même si cela
| semble provoquer plus d'erreur d'urb donc avec l'usb...)
Je me suis pas vraiment penche sur le probleme a vrai dire....
| Voilà c'était la pensée du soir et une demande d'évol' (si
| réalisable).
C'est realisable ... ;)
| Ça je sais (je crois).
| Deux manière de communiquer avec le noyau : ioctcl, système de fichier.
|
Meme plus si on veut faire tordu .. Pour le moment y'a: ioctl, procfs,
sysfs ...
| eaglectrl utilise ioctcl (seulement ?).
Pas seulement: il utilise qq ioctl pour le sens user -> driver (par
exemple pour les options, le code DSP, les flags de debug), et le procfs
pour les infos generales (eaglestat)
| En gros le module a enregistré des
| fonctions dans une grosse table de pointeurs de fonctions.
| Je me souviens plus des détails ne l'ayant pas eu l'occasion de le manipuler. Je
| suppose que l'on empile les paramètres sur la pile (c'est typé IOCTL ?) et on
| déclenche un appel système avec une entrée dans la fameuse table dans un
| certain registre (et il y a une macro qui écrit ça pour nous).
|
C'est a peu pret ca .. sauf qu'avec l'USB y'a un niveau d'indirection
supplementaire .. L'ioctl est un ioctl catche par le module USB, qui
dispatch le parametre de cet ioctl. Parametre qui lui indique au module
eagleusb la commande a executer ainsi que les parametres eventuels.
| D'ailleurs à ce propos pour les Oops ce serait pas mal d'avoir le module
| eagle-usb.ko utilisé pour analyser un peu mieux
Plus "simple" : le code assembleur genere (quoique meme ca parfois c'est
limite), avec en commentaire le code C associe ...
| En revanche, je vois pas quel outil utiliser ?
T'en as plusieurs : objdump, gdb, ...
|
| Par exemple, comment gdb pourrait-il retrouver ses petits
| - dans un module d'une part,
| - qui n'est pas foncièrement compatible avec le kernel sur lequel on analyse
| d'autre part...
In ASM we trust.
| En plus ce n'est pas comme l'analyse d'un core dump ?
| Un gdb eagle-usb.ko core ça fonctionnerait ? eagle-usb.ko n'est pourtant pas un
| programme en tant que tel ?! Et s'il est en ko.gz ??
sleeper@hal driver $ gdb eagle-usb.ko
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i686-pc-linux-gnu"...(no debugging symbols
found)...Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) disassemble eu_user
Dump of assembler code for function eu_user:
0x000013c3 <eu_user+0>: push %ebp
0x000013c4 <eu_user+1>: mov %esp,%ebp
0x000013c6 <eu_user+3>: sub $0x3ec,%esp
....
> > Donc serait-il possible d'obtenir (par eaglestat ???) la version de gcc
> > utilisée pour compiler le module eagle-usb ?
> [/lib/modules/2.6.7a/misc]# strings -a eagle-usb.ko | grep gcc
> vermagic=2.6.7a preempt PENTIUMIII REGPARM 4KSTACKS gcc-3.4
nan nan je fais du reverse engineering sur sl33p3r pas sur le pilote ;-) (ça
s'appelle un transfert de compétence et c'est pas encore interdit par les lois
qui passent ces derniers temps).
Autant avoir des interfaces propres quand c'est possible.
> Seul probleme:
> # gcc --version
> gcc (GCC) 3.4.1
>
> (pas 3.4)
>
> mais peut-etre ca sera suffisant?
autant maîtriser ce qui est fourni : dans eaglediag je me galère avec les
distributions localisées (le kernel est compilé par gcc sur serveur en
anglais, le résultat est affiché dans la locale où ça s'exécute...) je préfère
n'avoir que le n° de version (ça m'évite gawk et les sed horribles de
mcoolive).
et si mcoolive strippe le module ça n'apparaîtra (peut-être) plus...
| Ne pourrait-on pas mettre la version de gcc dans le 'description' lisible
| par modinfo eagle-usb?
| Au moins, on serait certain du gcc utilisé pour compiler le module.
Oui c'est une idee ... mais je pense aussi le mettre dans le eaglestat,
etant donne que eaglestat ne fait qu'un cat /proc/....
