| 1 |
Am Samstag, 27. Dezember 2008 15:11:34 schrieb Harry Putnam: |
| 2 |
> Summary of request for help: |
| 3 |
> |
| 4 |
> Are there hardcore kernel builders in the house who can steer me to |
| 5 |
> a faster way of figuring out what the installed modules do... for |
| 6 |
> sure. |
| 7 |
|
| 8 |
What could help you here is a "make xconfig". It's similar to "make |
| 9 |
menuconfig" but has a nice QT user interface. I would recommend to browse |
| 10 |
through it once and look at the help texts which are shown in the lower right |
| 11 |
pane for each option you klick. Based on this information, you can then decide |
| 12 |
wether or not to enable that option or even compile it as module. |
| 13 |
|
| 14 |
> Details: |
| 15 |
> I'm at a point where any pared down kernel config I've built and tried |
| 16 |
> has some terrible thing wrong with it. Usually involving udev and |
| 17 |
> openrc someway or other... things not getting started or mounted etc |
| 18 |
> etc. |
| 19 |
|
| 20 |
With udev, those things usually work automatically. However, you must make |
| 21 |
sure that everything needed for accessing the root filesystem must be compiled |
| 22 |
into the kernel. That usually includes the driver for the chipset that |
| 23 |
operates your harddisks, harddisk support and the filesystem used for /. |
| 24 |
|
| 25 |
> I'd think there would be some kind of cross reference somewhere that |
| 26 |
> would connect module names to what they do, and what .config options |
| 27 |
> are associated. |
| 28 |
|
| 29 |
I don't know of any. But in most cases, the module name is listed in the help |
| 30 |
text. |
| 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 |
Somtimes, you can also simply guess by module name, for example: joydev.ko -> |
| 37 |
Joy(stick)Dev(ice). |
| 38 |
|
| 39 |
> But my god what a slow and painful way to find out what these modules |
| 40 |
> do. |
| 41 |
|
| 42 |
Yes, that's true. The browsing method may give you a rough overview within an |
| 43 |
hour or two. |
| 44 |
|
| 45 |
> Just rmmod is another way but again a very slow and painful way. |
| 46 |
> Maybe a module is used only occasionally and rmmodding may not show |
| 47 |
> what it was for right away. What ever fails may not happen |
| 48 |
> immediately. |
| 49 |
|
| 50 |
Or try modprobe + dmesg instead. Usually a driver module tells wether it has |
| 51 |
found some pice of supported hardware or not. |
| 52 |
|
| 53 |
HTH... |
| 54 |
|
| 55 |
Dirk |
Archives