Exploring the Linux Kernel: The Secrets of Kconfig

Get a deep understanding of how the Linux configuration/build system works.

The Linux kernel configuration/build system (also known as Kconfig/kBuild) has been around for a long time, ever since the Linux kernel code was migrated to Git. However, as supporting infrastructure it has received little attention; even kernel developers who use it in their daily work never really think about it.

To explore how the Linux kernel is compiled, this article will delve into the Kconfig/kBuild internals, explain how .config files and vmlinux/bzImage files are generated, and introduce a smart trick for dependency tracking.

Kconfig

The first step in building a kernel is always configuration. Kconfig helps make the Linux kernel highly modular and customizable. Kconfig provides the user with a number of configuration targets:

I think menuconfig is the most popular of these targets. Targets are handled by different host programs, which are provided by the kernel and generated during the kernel build process. Some targets have a GUI (for user convenience), while most do not. The kconfig-related tools and source code are mainly located in scripts/kconfig/ in the kernel source code. We can start from scripts/kconfig/makefile, there are several host programs, including CONF, mconf, and nconf. With the exception of conf, each of them is responsible for one of the GUI-based configuration targets, so conf deals with most of them.

Logically, there are two parts to the Kconfig infrastructure: one that implements the new language to define configuration items (see the Kconfig files under the kernel source code), and something else that parses the Kconfig language and handles configuration operations.

The internal flow for most configuration targets is roughly the same (as shown below):

Note that all configuration items have a default value.

The first step reads the Kconfig files under the source root to construct the initial configuration database; then reads the existing configuration files to update the initial database according to this priority:

• .config
• /lib/Module/$(shell,uname -r)/.config
• /etc/kernel-config
• /boot/config-$(shell,uname -r)
• ARCH_DEFCONFIG
• ARCH/$(ARCH)/Defconfig

If you are doing GUI based configuration, via menuconfig or command line based configuration, oldconfig, the database will be updated with your customizations. Finally, dump the configuration database into a .config file.

But .config files are not the final product of a kernel build; that's why the syncconfig target exists. syncconfig used to be a file called silentoldconfig, but it didn't do what the old name said, so it was renamed. Also, since it is for internal use (and not for users), it was removed from the list.

Here is an example of what syncconfig does:

syncconfig takes .config as input and outputs a number of other files, which fall into three categories:

auto.conf & tristate.conf are used to generate files for text processing. For example, you might see a statement like this in a component's makefile:

obj-$(CONFIG_GENERIC_CALIBRATE_DELAY) += calibrate.o


autoconf.h is used in C language source files.

The empty header file include/config/ is used for configuration dependency tracking during kbuild, which is explained below.

After profiling, we will know which files and code segments are not compiled.

KBuild

Component-wise building, called recursive make, is a common approach in GNU. Make and manage a large project. KBuild is a good example of recursive make. By dividing the source files into different modules/components, each component is managed by its own Makefile. When you start a build, the top-level Makefile calls each component's makefile in the correct order, builds the components, and collects them into the final executable.

KBuild refers to different types of makefiles:

• The Makefile is located at the top makefile in the source root.
• .config is the kernel configuration file.
• ARCH/$(ARCH)/Makefile is the arch Makefile, which is a complement to the top makefile.
• scripts/Makefile* describes common rules for all kbuild makefiles.
• In the end, there are about 500 Kbuildmakefiles.

The top makefile contains the archmakefile, which reads the .config file, goes into the subdirectory, calls make, and implements each component makefile with the help of the routines defined in it. scripts/Makefile*, builds each intermediate object and links all intermediate objects into vmlinux. The core file Documentation/kbuild/makefiles.txt describes all aspects of these makefiles.

For example, let's see how to spawn vmlinux on x86-64:

(Illustration based on Richard Y. Steven's blog. Updated and used with permission from the author.)

All .o files that go into vmlinux first go into their own built-in.a, which is represented by the variable. KBUILD_VMLINUX_INIT, KBUILD_VMLINUX_Main, KBUILD_VMLINUX_LIBS, and then collect them into the vmlinux file.

Let's see how recursive make is implemented in the Linux kernel, with the help of a simplified Makefile code:

# In top Makefile
vmlinux: scripts/link-vmlinux.sh $(vmlinux-deps)
        +$(call if_changed,link-vmlinux)
# Variable assignments
vmlinux-deps := $(KBUILD_LDS) $(KBUILD_VMLINUX_INIT) $(KBUILD_VMLINUX_MAIN) $(KBUILD_VMLINUX_LIBS)
export KBUILD_VMLINUX_INIT := $(head-y) $(init-y)
export KBUILD_VMLINUX_MAIN := $(core-y) $(libs-y2) $(drivers-y) $(net-y) $(virt-y)
export KBUILD_VMLINUX_LIBS := $(libs-y1)
export KBUILD_LDS := arch/$(SRCARCH)/kernel/vmlinux.lds
init-y := init/
drivers-y := drivers/ sound/ firmware/
net-y := net/
libs-y := lib/
core-y := usr/
virt-y := virt/
# Transform to corresponding built-in.a
init-y := $(patsubst %/, %/built-in.a, $(init-y))
core-y := $(patsubst %/, %/built-in.a, $(core-y))
drivers-y := $(patsubst %/, %/built-in.a, $(drivers-y))
net-y := $(patsubst %/, %/built-in.a, $(net-y))
libs-y1 := $(patsubst %/, %/lib.a, $(libs-y))
libs-y2 := $(patsubst %/, %/built-in.a, $(filter-out %.a, $(libs-y)))
virt-y := $(patsubst %/, %/built-in.a, $(virt-y))
# Setup the dependency. vmlinux-deps are all intermediate objects, vmlinux-dirs
# are phony targets, so every time comes to this rule, the recipe of vmlinux-dirs
# will be executed. Refer "4.6 Phony Targets" of `info make`
$(sort $(vmlinux-deps)): $(vmlinux-dirs) ;
# Variable vmlinux-dirs is the directory part of each built-in.a
vmlinux-dirs := $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \
           $(core-y) $(core-m) $(drivers-y) $(drivers-m) \
           $(net-y) $(net-m) $(libs-y) $(libs-m) $(virt-y)))
# The entry of recursive make
$(vmlinux-dirs):
        $(Q)$(MAKE) $(build)=$@ need-builtin=1

Recursive recipe expansion, for example:

make -f scripts/Makefile.build obj=init need-builtin=1


This means make will go into scripts/Makefile.build and continue building each built-in.a. With the help of scripts/link-vmlinux.sh, the vmlinux files are finally located under the sources root.

Understanding vmlinux and bzImage

Many Linux kernel developers may not be clear about the relationship between vmlinux and bzImage. For example, here's how they relate in x86-64:

The source root vmlinux is stripped, compressed, put into piggy.S, and then other peer objects are linked into arch/x86/boot/compressed/vmlinux. At the same time, a file named setup.bin is generated in arch/x86/boot. There may be an optional third file containing relocation information, depending on config_x86_RELOCS.

A command called build is provided by the kernel that builds these two (or three) parts into the final bzImage file.

Dependency Tracking

KBuild tracks three kinds of dependencies:

1. All prerequisite files (*.c and *.h)
2. CONFIG_ options used in all prerequisite files
3. Command-line dependencies for compiling the target.

The first one is easy to understand, but what about the second and third? Kernel developers often see code snippets like this:

#ifdef CONFIG_SMP
__boot_cpu_id = cpu;
#endif

When CONFIG_SMP is changed, this code should be recompiled. The command line you use to compile your source files is also important, because different command lines can result in different object files.

When the .C file is included via the #include directive, you need to write a rule like this:

main.o: defs.h
recipe...

When managing a large project, you need a lot of these rules; all of them can get tedious. Fortunately, most modern C compilers can tell by looking at the #include lines in your source files. For the GNU Compiler Collection (GCC), just add a command line argument: -MD depfile

# In scripts/Makefile.lib
c_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \
         -include $(srctree)/include/linux/compiler_types.h \
         $(__c_flags) $(modkern_cflags) \
         $(basename_flags) $(modname_flags)

This will generate a .D file with the following contents:

init_task.o: init/init_task.c include/linux/kconfig.h \
include/generated/autoconf.h include/linux/init_task.h \
include/linux/rcupdate.h include/linux/types.h \
...

The host program fixdep then takes care of the other two dependencies by fetching them. The depfile takes a command line as input and then outputs a .cmd file in Makefile syntax that records the target's command line and all prerequisites (including configuration). It looks like this:

# The command line used to compile the target
cmd_init/init_task.o := gcc -Wp,-MD,init/.init_task.od -nostdinc ...
...
# The dependency files
deps_init/init_task.o := \
$(wildcard include/config/posix/timers.h) \
$(wildcard include/config/arch/task/struct/on/stack.h) \
$(wildcard include/config/thread/info/in/task.h) \
...
 include/uapi/linux/types.h \
 arch/x86/include/uapi/asm/types.h \
 include/uapi/asm-generic/types.h \
...

A .cmd file will be included in the recursive build process, providing all dependency information and helping decide whether to rebuild the target.

The secret behind this is that Fixdep will parse the depfile (.d file), then parse all dependency files inside it, search for the text of all config_strings, convert them to corresponding empty header files, and add them to the prerequisites of the target. Every time the configuration changes, the corresponding empty header file will also be updated, so kbuild can detect that change and rebuild the targets that depend on it. Because the command line is also recorded, it is easy to compare the last compilation parameters with the current compilation parameters.

Looking ahead

Kconfig/kbuild remained unchanged for a long time until a new maintainer, Masahiro Yamada, joined in early 2017, and now KBuild is under active development again. Don’t be surprised if you quickly see something different than what’s in this article.

Summarize

The above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. Thank you for your support of 123WORDPRESS.COM. If you want to learn more about this, please check out the following links