Modules compilés en dur

Version imprimable

13/05/2008, 23h45
Fluxy

Modules compilés en dur

Bonsoir,

Après plusieurs recherche, je ne trouve pas comment faire pour lister les modules compiler en dur dans le noyau ?

Connaissez-vous la commande qui va bien ?

Je connais modprobe -l pour lister les modules disponibles.

Je suis sous debian.

Merci.

Bonne soirée.

++
Fluxy__
14/05/2008, 10h50
Pilru

Si c'est compiler "un dur" dans le noyau, ce ne sont plus des modules.

Le seul moyen que je connaisse pour savoir ce qui est intégré dans le noyau, c'est de faire un grep sur le fichier .config. Chaque options est marquée par un tag suivant qu'elles intégrée au noyau, compilé en module ou mise de coté. N'ayant pas de .config sous la main, je ne peut être plus précis.

Et pour infos, modprobe -l ou lsmod ne liste que les modules en cours d'utilisation. Ce n'est donc pas exhaustif.
14/05/2008, 12h39
Fluxy
Je te remercie pour ta réponse,

cependant si je prend l'exemple suivant sur ma machine :
Code:

1 2 3 4 5 lsmod | grep "8139" 8139cp 19072 0 8139too 23936 0 mii 4864 2 8139cp,8139too
ok, donc mii est utilisé par 8139cp.
Est-ce qu'il est chargé au démarrage de la machine ?

Code:

find /etc/mod* -print0 | xargs -0 grep "8139"

Pas de réponse, donc doit être en dur.
Je tente de le déchargé
Code:

1 2 3 4 5 6 modprobe -r 8139cp lsmod | grep "8139" 8139too 23936 0 mii 4864 1 8139too
Donc on peux décharger un module compilé en dur dans le noyau ??

Autre chose, si je fait :

Code:

grep -i "sd_mod" /boot/.config

pas de réponse cependant
Code:

1 2 3 4 5 6 modprobe sd_mod lsmod | grep "sd_mod" sd_mod 20480 0 scsi_mod 115148 1 sd_mod
Donc je peux monté dans module qui n'ont pas été choisi à la compilation du noyau ??

Je suis un peu paumé...

++
Fluxy__
14/05/2008, 16h11
Pilru

Le noyau est capable de charger lui même les modules dont il a besoin, en temps voulu.

Les modules sont dans /lib/modules/<num noyau>/
14/05/2008, 16h31
Fluxy

ca je l'est bien compris et je sais que les modules sont dans ce répertoire ma question est :

Comment savoir si une fonctionnalité (vu que tu ne veux pas que je l'est appelle module) est compilée en dur dans le noyau ?

A part l'utilisation d'un grep sur le /boot/.config, existe-t-il une autre solution ?

Merci et bonne journée.
14/05/2008, 16h40
valefor

Citation:

Envoyé par Pilru

modprobe -l ou lsmod ne liste que les modules en cours d'utilisation. Ce n'est donc pas exhaustif.

Je pense bien que "modprobe -l" donne une liste exhaustive de tous les modules disponibles.

Ensuite, par rapport à la question d'origine, il faudrait connaitre le but de ton opération pour trouver d'éventuelles astuces...

Code:

1 2 3 4 5 6 7 8 ok, donc mii est utilisé par 8139cp. Est-ce qu'il est chargé au démarrage de la machine ? Code : find /etc/mod* -print0 | xargs -0 grep "8139" Pas de réponse, donc doit être en dur.
Pas forcement. Cela peut aussi signifier que le module n'est pas explicitement chargé au démarrage. Pour savoir qu'il ne s'agit pas d'un module, il faut s'assurer qu'il n'y a pas de fichier .ko dans /lib/modules/...

Citation:

Je tente de le déchargé

Code :

modprobe -r 8139cp

lsmod | grep "8139"

8139too 23936 0
mii 4864 1 8139too

Donc on peux décharger un module compilé en dur dans le noyau ??

Si tu as pu le déchargé, c'est qu'il s'agit d'un module.

Citation:

Autre chose, si je fait :

Code :

grep -i "sd_mod" /boot/.config

pas de réponse cependant

Code :

modprobe sd_mod

lsmod | grep "sd_mod"

sd_mod 20480 0
scsi_mod 115148 1 sd_mod

Donc je peux monté dans module qui n'ont pas été choisi à la compilation du noyau ??

Cela veut peut-être dire que dans le fichier .config le module qui sera généré sous le mon de sd_mod.ko n'est pas référencé sous ce nom.

Citation:

Comment savoir si une fonctionnalité (vu que tu ne veux pas que je l'est appelle module) est compilée en dur dans le noyau ?

Un module, par définition, est compilé comme une extension au noyau (un fichier .ko). Ce qui est dans le noyau, n'est donc pas un module à proprement parlé. Soyons précis sur les termes. Sinon, on ne va pas se comprendre.

Citation:

A part l'utilisation d'un grep sur le /boot/.config, existe-t-il une autre solution ?

Par déduction, si tu vois le nom d'un module dans lsmod, et qu'il n'y a pas dans .ko correspondant dans /lib/..., c'est qu'il s'agit d'une fonction du noyau.

Citation:

Je pense bien que "modprobe -l" donne une liste exhaustive de tous les modules disponibles

Au temps pour moi.

14/05/2008, 23h05
D[r]eadLock

Une solution:

Code:

find -L /usr/src/linux -name "Kconfig" -exec grep -B 2 "tristate" {} \; | grep "^config" | cut -d " " -f2 | xargs -I NAME grep "[^#].*NAME=y" /usr/src/linux/.config

Explications:
-[find -L /path/to/linuxsrc -name ] je ne vois pas comment a part chercher dans les Kconfig ceux qui se déclarent en "tristate" et non "bool" (voire autre chose pour les valeurs numériques, donc on cherche les fichier Kconfig)

Citation:

Envoyé par /usr/src/linux/drivers/gpio/Kconfig

config GPIO_PCA953X
tristate "PCA953x I/O ports"
depends on I2C

-[grep -B 2 ] le config associé est sur la ligne précédent, voire une ligne encore au dessus (et peut-être même plus, on peu donc en rater ;( ), donc on affiche 2 lignes avant
-[grep "^config"] on ne garde que les lignes qui on config au début
-[cut -d " " -f2] on prend le deuxième champ (i.e. GPIO_PCA953X)
-[xargs -i NAME "] et on applique pour tous ces noms:
-[grep "[^#].*NAME=y /usr/src/linux/.config] on cherche dans le .config les champs qui sont mis à y (# au début indique une ligne commentée, et =m indique un module)

Rq:
- les fichiers ils peuvent être ailleurs (le .config notamment)
- mais au fait, pourquoi as-tu besoin de ça, comme dit précédemment, modprobe gère lui-même les dépendances (deload tous tes modules (par exemple 8139cp, 8139too et mii) et fait un modprobe -v 8139cp, il devrait aussi loader mii)

Citation:

Envoyé par Pilru

Citation:
>Comment savoir si une fonctionnalité (vu que tu ne veux pas que je l'est appelle module) est compilée en dur dans le noyau ?
Un module, par définition, est compilé comme une extension au noyau (un fichier .ko). Ce qui est dans le noyau, n'est donc pas un module à proprement parlé. Soyons précis sur les termes. Sinon, on ne va pas se comprendre.

Citation:
>A part l'utilisation d'un grep sur le /boot/.config, existe-t-il une autre solution ?
Par déduction, si tu vois le nom d'un module dans lsmod, et qu'il n'y a pas dans .ko correspondant dans /lib/..., c'est qu'il s'agit d'une fonction du noyau.

Euh, plutôt pas d'accord, si lsmod te donne un truc c'est que c'est un module (et devrait correspondre à un .ko dans /lib/modules)

En gros c'était pour recompiler le noyau et désactiver les fonctionnalitées activé en dur dans le noyau qui ne me serve pas.

J'avais penser à les chercher avec un script du genre

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#!/bin/bash
repBoot="/boot/config-$(uname -r)"
repConfModule="/etc/mod*"
mesModulesInutiles=$(lsmod | awk -F " " '{ if ($3 == 0) print $1 }')
for var in $mesModulesInutiles ; do
        echo "Recherche du module $var"
        grep -i "$var" -R $repConfModule
        if [ $? == 1 ] ; then
                echo "Le Module $var nest pas active au demarrage"
        else
                echo "Le Module $var est active au demarrage"
        fi
 
        echo "Recherche de la chaine $var dans $repBoot"
        grep -i "$var" $repBoot
        if [ $? == 0 ] ; then
                echo "Le module a bien ete compile en module..."
        else
                module=$(modprobe -l | grep -i "$var")
                if [ $? == 0 ] ; then
                        echo "Le module $var semble correspondre au fichier $module"
                else
                        echo "Aucun fichier trouve pour $var"
                fi
        fi
        echo "--------------------------------"
        echo
done

++ Fluxy__

15/05/2008, 09h46
valefor

Très intéressant !

Je cherchait un truc du genre. Mais je partais dans l'autre sens.

On compile un noyau avec tout activé et tout ce qui est compilable en module, en module.

On aurait ensuite un script qui regarde les modules chargés et qui regarde les drivers utilisés, etc. Le script tournerait pendant assez longtemps pour caractériser une utilisation typique du système.

Enfin on aurait un .config qui reflète au mieux (c'est impossible d'être exact je pense), notre configuration.

Bon, tout cela pour dire que c'est un sujet intéressant et que des résultats dans cette direction manque je trouve...