1 |
Summary of request for help: |
2 |
|
3 |
Are there hardcore kernel builders in the house who can steer me to |
4 |
a faster way of figuring out what the installed modules do... for |
5 |
sure. |
6 |
|
7 |
Details: |
8 |
I'm at a point where any pared down kernel config I've built and tried |
9 |
has some terrible thing wrong with it. Usually involving udev and |
10 |
openrc someway or other... things not getting started or mounted etc |
11 |
etc. |
12 |
|
13 |
A full on genkernel build seems to be the quickest way to get a working |
14 |
kernel. That done, I'm now plodding along with build after build |
15 |
trying to discover what it is the genkernel has that my pared down |
16 |
versions do not. |
17 |
|
18 |
Trying to discover what all the 80 or so installed modules do seems |
19 |
like a really slow process. Take the module name and try to find |
20 |
something like it in .config |
21 |
|
22 |
I've even written a perl script to allow me to input the module names, |
23 |
or parts thereof and grep out the section name and lines that match inside |
24 |
.config. |
25 |
|
26 |
This is at least a weak start at knowing what the module is about. |
27 |
|
28 |
I'd think there would be some kind of cross reference somewhere that |
29 |
would connect module names to what they do, and what .config options |
30 |
are associated. |
31 |
|
32 |
Another path is to find the *.ko names in /lib/modules and use the |
33 |
absolute name to track them down in the kernel sources where there is |
34 |
usually a README of some sort in the tree leading to the *.ko. |
35 |
|
36 |
But my god what a slow and painful way to find out what these modules |
37 |
do. |
38 |
|
39 |
Just rmmod is another way but again a very slow and painful way. |
40 |
Maybe a module is used only occasionally and rmmodding may not show |
41 |
what it was for right away. What ever fails may not happen |
42 |
immediately. |