The .config

The dot-config file is the configuration blueprint for building a Linux kernel image. You will likely spend significant effort at the start of your Linux project building a configuration that is appropriate for your embedded platform.Several editors, both text based and graphical, are designed to edit your kernel configuration. The output of this configuration exercise is written to a configuration file named .config, located in the top-level Linux source directory that drives the kernel build.

    You have likely invested significant time perfecting your kernel configuration, so you will want to protect it. Several make commands delete this configuration file without warning. The most common is make mrproper. This make target is designed to return the kernel source tree to its pristine, unconfigured state. This includes removing all configuration data from the source tree-and, yes ,it deletes your .config.

    As you might know, any filename in Linux preceded by a dot is a hiddden file in Linux. It is unfortunate that such an important file is marked hidden; this has brought considerable grief to more than one developer. If you execute make mrproper without having a backup copy of your .config file, you, too, will share our grief.(You have been warned -- back up your .config file!)

The .config file is a collection of definitions with a simple format. List 4.5 shows a snippet of a .config from a recent Linux kernel release.

LISTING 4-5

Snippet from Linux 2.6 .config

,,, #USB  support CONFIG_USB = m #CONFIG_USB_DEBUG is not set #Miscellaneous USB options # CONFIG_USB_DEVICEFS=y #CONFIG_USB_BANDWIDTH is not set #CONFIG_USB_DYNAMIC_MINORS is not set #USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m ,,,

    To Understand the .config file, you need to understand a fundameental aspect of the Linux kernel. Linux has a monolithic structure. That is , the entire kernel is compiled and linked as a single statically linked executable. However, it is possible to compile and incrementally link a set of sources into a single object module suitable for dynamic insertion into a running kernel. This is the usual method for supporting most common device drivers. In Linux, these are called loadable modules.  They are also genericaly called device drivers. After the kernel is booted, a special application program is invoked to insert the loadable module into a running kernel.

    Armed with that knowledge ,let's look again at Listing 4-5. This snippet of the configuration file (.config) shows a portion of the USB subsystem configuration. This first configuration option, CONFIG_USB=m, declares that the  USB subsystem is to be included in this kernel configuration and that it will be compiled as a dynamically loadable module(=m), to be loaded sometime after the kernel has booted. The other choice would have been =y,, in which case the USB module would be compiled nad statically linked as part of the kernel image itself. It would end up in the ../drivers/built-in.o composite binary. Ther astute reader will realize that if a driver is configured as a loadable module, its code is not included in the kernel proper, but rather exists as a stand-alone object module, a loadable module, to be inserted into the running kernel after boot.

    Notice the Listing 4-5 the CONFIG_USB_DEVICEFS=y declaration. This configuration option behaves in a slightly defferent manner. In this case, USB_DEVICEFS( as configuration options are commonly abbreviated) is not a stand-alone module, but rather a feature to be enabled or disabled in the USB driver. It does not necessarily result in a module that is compiled into the kernel proper(=y); instead, it enables one or more features, often represented as additional object modules to be included in the overall USB device driver module. Usually, the help text in the configuration editor or the hierarchy presented by the configuration editor, makes this distinction clear.

 

     Most kernel software modules also read the configuration indirectly via the .config file as follows. During the build process, the .config file is processed into a c header file found in the .../include/linux directory, called autoconf.h. This is an automatically generated file and should never be edited directly because edits are lost each time a configuration editor is run. Many kernel source files include this file directly using the #include preprocessor directive. List 4-6 reproduces a section of this header file that corresponds to the earlier USB example above. Note that, for each entry in the .config file snippet in Listing 4-5, a corresponding entry is created in autoconf.h. This is how the source files in the kernel source tree reference the kernel configuration.

Listing 4-6

Linux autoconf.h

/* *USB support */ #define CONFIG_USB_MODULE 1 #undef CONFIG_USB_DEBUG   /* Mkscellaneous UBS options*/ #define CONFIG_USB_DEVICEFS 1 #undef CONFIG_USB_BANDWIDTH #undef CONFIG_USB_DYNAMIC_MINORS /* USB Host Controller Drivers*/ #define CONFIG_USB_EHCI_HCD_MODULE 1