If you want to find the name of the configuration variable that is used to enable a module, you can search the kernel make files for the line that adds the module to the build. The following command searches all the make files for a module.
$ find . -name Makefile | xargs grep "moduleName.o" /dev/null | grep CONFIG
For example, if you use this command to find the module named "thermal", it produces the following output. From this you can see that the configuration variable that enables the module is CONFIG_ACPI_PROCESSOR. (Note: When used in the source code, configuration option names are prefixed with "CONFIG" to prevent them from conflicting with other symbolic names.)
./drivers/acpi/Makefile:obj-$(CONFIG_ACPI_THERMAL) += thermal.o
Note: This technique works most of the time, but there are places where the entry in the make file does not conform to the style shown above. In that case, you will have to find the make file where the module is built and then examine it to figure out which configuration option is used to control whether or not the module is built.
If the option you need to select in the configuration dialog is missing or it is not active (gray), it means that the option is dependent upon another option that is not enabled. If it is not visible at all and you are using xconfig or gconfig, there is an option on the menu bar to show all the options (Option->Show All Options). This will allow you to see all the options even if they are not active. However, if the option you need is not active, you still must find its dependency and enable it first.
If you cannot determine the dependency of an option by looking at the dialog messages, you will have to find the definition for the option in the source code. The definition will list its dependencies. Go back to the directory where you found the option in the make file (see previous section). Look in the file Kconfig in that directory for the definition of the option.
For example, in the previous section, we found the configuration option for the module thermal in the drivers/acpi directory. In the Kconfig file in that directory, you can also find the definition for the ACPI_THERMAL configuration option, which is shown below. Here you can see that the this option is dependent on the ACPI_PROCESSOR configuration option. If that configuration option is not enabled, the ACPI_THERMAL configuration option will not be active.
tristate "Thermal Zone"
depends on ACPI_PROCESSOR
This driver supports ACPI thermal zones. Most mobile and
some desktop systems support ACPI thermal zones. It is HIGHLY
recommended that this option be enabled, as your processor(s)
may be damaged without it.
To compile this driver as a module, choose M here:
the module will be called thermal.
When building a new kernel for an existing system, you have the advantage that you can examine the existing system to determine name of the module that implements the driver for a particular device. The following commands show how you can find the name of the module by examining the device configuration on the current system.
$ cd $(find /sys –name “deviceName” | head -1)
$ cd device/driver
$ basename $(pwd -P)
The find command in the first line searches the /sys directory for an entry with the same name as the device. This search may find several entries, but they should all be links to the same location. Therefore, the output from the find command is passed to the head command, which passes the first line and deletes everything else. The result is the name of the directory for the device, which becomes the target of the cd command. For example, the find command finds the following entries on my system when I search for the first SCSI disk.
$ find /sys –name sda
After executing the fist command, you will be in the directory for the device. The second command changes directories to the subdirectory for the device driver. These are actually symbolic links, so, in the last command, you need to use the pwd command with the -P option to find the actual name of the directory. The name of this directory is also the name of the module that implements the driver.
Copyright © 2009 by Bruce Blinn