Understanding the Relationship Between Makefile, Kconfig, and .config in Linux Kernel

❞The Linux kernel source code files are numerous, and it’s hard to understand the relationship between Makefile, Kconfig, and .config. Without understanding the kernel compilation system, it can be difficult to compile and modify the kernel, integrate your own drivers, or configure the kernel. These issues are all related to Makefile, Kconfig, and .config. Below, we will briefly discuss Makefile, Kconfig, and .config. I hope this will inspire you.

Functions of the Three:

In simple terms, it’s like ordering dishes in a restaurant: Kconfig is the menu, Makefile is the recipe, and .config is the dish you’ve ordered.

Makefile: A text file that defines how to compile source files.

Kconfig: A text file that serves as the kernel configuration menu.

.config: The configuration file used for compiling the kernel.

Syntax of the Three

1. Makefile

Reference: linux-3.4.2/drivers/Makefile

Function: Defines which components are compiled as modules and under what conditions. The subdirectory Makefile is included by the top-level Makefile.

(1) Direct Compilation

obj-y += xxx.o  

This indicates that xxx.c or xxx.s is compiled into xxx.o and directly integrated into the kernel.

(2) Conditional Compilation

obj -$(CONFIG_HELLO)  += xxx.o   

This determines whether the file is compiled into the kernel based on the CONFIG_XXX in the .config file.

(3) Module Compilation

obj-m +=xxx.o

This indicates that xxx is compiled as a module, meaning it will only be compiled when executing make modules.

2. Kconfig

Each config menu item has a type definition: bool (boolean type), tristate (built-in, module, or removed), string, hex, and integer.

Function: Determines the menu items displayed during make menuconfig.

Reference: linux-3.4.2/drivers/leds/kconfig:

config LEDS_S3C24XX
       tristate "LED Support for Samsung S3C24XX GPIO LEDs"
       depends on LEDS_CLASS
       depends on ARCH_S3C24XX
       help
         This option enables support for LEDs connected to GPIO lines
         on Samsung S3C24XX series CPUs, such as the S3C2410 and S3C2440.

LEDS_S3C24XX: The name of the configuration option, omitting the prefix “CONFIG_”.

Tristate:

This indicates whether the item is compiled into the kernel or as a module. It is displayed as < >. If selected to compile as a kernel module, a configuration of CONFIG_HELLO_MODULE=m will be generated in .config. Choosing Y means it will be compiled directly into the kernel, generating CONFIG_HELLO_MODULE=y in .config. The string following tristate is the name displayed during make menuconfig.

bool:

This type can only be selected or not selected, displayed as [ ] during make menuconfig, meaning it cannot be configured as a module.

dependon:

This option depends on another option; the prompt for the current configuration item only appears when the dependency is selected, allowing the current option to be set.

select:

This indicates a reverse dependency; when this option is selected, it also selects the item defined after select.

help:

Help information.

Directory Hierarchy Iteration:

Kconfig contains statements like: source “drivers/usb/Kconfig”, which includes (or nests) new Kconfig files, allowing each directory to manage its own configuration content without writing all configurations in a single file, making it easier to modify and manage.

3. .config

Reference: linux-3.4.2/.config

From the analysis of the first two files, the meaning of .config is already clear: it is a reference file for kernel compilation; checking its contents reveals which drivers have been compiled into the kernel.

There are three ways to configure the kernel (choose one):

(1) make menuconfig

(2) make xxx_defconfig

(3) directly modify .config

Note: If you directly modify .config, it may not take effect because some configurations may have dependencies. During make, rules are checked based on these dependencies, and direct modifications to .config may sometimes be ineffective, so direct modifications are not recommended.

What has been discussed may be a bit abstract; let’s illustrate it with an example:

Write a simple entry function to output hello world and compile it into the kernel.

Steps:

(1) Create a new folder named hello in the drivers directory, where you will implement hello.c, Makefile, and Kconfig.

hello.c:

#include <linux/module.h>  
#include <linux/kernel.h> 
#include <linux/init.h>  
static int first_drv_init(void)  
{ 
   printk("------------------hello world !--------------------");  
   return 0;  
} 
static void first_drv_exit(void) 
{  
    printk("------------------exit hello world !--------------------"); 
}  
module_init(first_drv_init); 
module_exit(first_drv_exit); 
MODULE_LICENSE("GPL");

Makefile:

obj-$(CONFIG_HELLO) += hello.o  

Kconfig:

config HELLO  
   tristate "Hello World for fengyuwuzu"  
   help  
     Hello for fengyuwuzu  

config HELLO determines the name: CONFIG_HELLO.

Hello World for fengyuwuzu: Determines the name displayed during make menuconfig.

(2) Modify the upper-level (Linux-3.4.2/drivers) Makefile and Kconfig.

Makefile:

obj-y  += hello/  

Kconfig:

source  "drivers/hello/Kconfig"  

(3) make menuconfig

(4) make uImage and then burn it to the development board. Check the kernel startup log, and the great hello world appears! This indicates hello.c has been successfully integrated into the kernel:

Feel free to refer to this experiment; I believe you will gain a clearer understanding of the kernel’s organizational structure.