Shulou(Shulou.com)06/01 Report--

This article is about what the secret of Kconfig/kbuild in Linux is. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Kconfig

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

Configuration goal interpretation config updates current configuration using command-line programs nconfig updates current configuration using ncurses menu-based programs update current configuration xconfig updates current configuration with Qt-based front-end programs gconfig updates current configuration with GTK+-based front-end programs oldconfig updates current configuration based on provided .config update current configuration, disable unloaded modules localyesconfig to update current configuration Convert local modules to core defconfig new configuration savedefconfig with defconcig default values provided from the schema savedefconfig saves the current configuration as. / defconfig (minimum configuration) allnoconfig all options answer no new configuration allyesconfig all options answer yes new configuration allmodconfig choose new configuration for all modules as far as possible new configuration alldefconfig all symbols (options) set to default new configuration randconfig all options randomly selected new configuration listnewconfig lists new options olddefconfig as oldconfig But set the new symbol (option) as its default without asking kvmconfig to enable additional options for KVM guest kernel modules xenconfig enable dom0 for xen and additional options for guest kernel modules tinyconfig configure the kernel as small as possible

I think menuconfig is the most popular of these goals. These goals are handled by different main programs, host program, which are provided by the kernel and built during kernel construction. Some targets have GUI (for user convenience), while most don't. The tools and source code related to Kconfig are mainly located under scripts/kconfig/ in the kernel source code. As you can see from scripts/kconfig/Makefile, there are several main programs, including conf, mconf, and nconf. With the exception of conf, each is responsible for a GUI-based configuration target, so conf handles most of the targets.

Logically, the infrastructure of Kconfig has two parts: one implements a new language to define configuration items (see the Kconfig file under kernel source code), and the other parses the Kconfig language and handles configuration operations.

Most configuration targets have roughly the same internal process (as shown below):

Note that all configuration items have default values.

The first step is to read the Kconfig file in the root of the source code to build the initial configuration database, and then it reads the existing configuration file to update the initial database according to the following priority:

.config

/ lib/modules/$ (shell,uname-r) / .config

/ etc/kernel-config

/ boot/config-$ (shell,uname-r)

ARCH_DEFCONFIG

Arch/$ (ARCH) / defconfig

If you do GUI-based configuration through menuconfig or command-line-based configuration through oldconfig, update the database according to your customization. Finally, the configuration database is dumped to the .config file.

But the .config file is not the final material for kernel construction; that's why the syncconfig target exists. Syncconfig used to be a configuration target called silentoldconfig, but it didn't do what its old name said, so it was renamed. In addition, because it is for internal use (not applicable to users), it has been removed from the above list.

Here is what syncconfig does:

Syncconfig takes .config as input and exports many other files, which fall into three categories:

Auto.conf & tristate.conf is used for makefile text processing. For example, you can see this statement in the makefile of a component: obj-$ (CONFIG_GENERIC_CALIBRATE_DELAY) + = calibrate.o.

Autoconf.h is used as the source file for C language.

The empty header file under include/config/ is used for configuration dependency tracking during kbuild. It will be explained below.

After the configuration, we will know which files and code snippets are not compiled.

Kbuild

Component builds, called recursive make, are a common way for GNU make to manage large projects. Kbuild is a good example of recursive make. By dividing the source file into different modules / components, each component is managed by its own makefile. When you start building, the top-level makefile calls the makefile of each component in the correct order, builds the components, and collects them into the final executor.

Kbuild points to different types of makefile:

Makefile is located at the top-level makefile of the source code root.

.config is the kernel configuration file.

Arch/$ (ARCH) / Makefile is the makefile of the architecture, which complements the top-level makefile.

Scripts/Makefile.* describes the common rules for all kbuild makefile.

Finally, there are about 500 kbuild makefile.

The top-level makefile includes the schema makefile, reads the .config file, goes down to the subdirectory, calls make on the makefile of each component with the help of the routines defined in scripts/ Makefile.*, builds each intermediate object, and links all intermediate objects as vmlinux. The kernel document Documentation/kbuild/makefiles.txt describes all aspects of these makefile.

As an example, let's look at how to generate vmlinux on x86-64:

Vmlinux overview

(this illustration is based on Richard Y. Steven's blog. It has been updated and used with the author's permission. )

All .o files that enter vmlinux first enter their own built-in.a, which is represented by the variables KBUILD_VMLINUX_INIT, KBUILD_VMLINUX_MAIN, KBUILD_VMLINUX_LIBS, and is then collected into the vmlinux file.

With the help of the following simplified makefile code, learn how to implement recursive make in the Linux kernel:

# In top Makefilevmlinux: scripts/link-vmlinux.sh $(vmlinux-deps) + $(call if_changed Link-vmlinux) # Variable assignmentsvmlinux-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.ainit-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.6Phony Targets" of `info make` $(sort $(vmlinux-deps)): $(vmlinux-dirs) # Variable vmlinux-dirs is the directory part of each built-in.avmlinux-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

The recipe for recursive make recipe is extended as follows:

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

This means that make will enter the scripts/Makefile.build to continue building each built-in.a. With the help of scripts/link-vmlinux.sh, the vmlinux file ends up in the source root directory.

Comparison between vmlinux and bzImage

Many Linux kernel developers may not be aware of the relationship between vmlinux and bzImage. For example, this is their relationship in x86-64:

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

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

Dependency tracking

Kbuild tracks three kinds of dependencies:

All required documents (* .c and * .h)

CONFIG_ options used in all prerequisite files

Command line dependencies used to compile the target

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

# ifdef CONFIG_SMP__boot_cpu_id = cpu;#endif

This code should be recompiled when the CONFIG_SMP changes. The command line that compiles the source file is also important because different command lines may result in different target files.

When the .c file uses the header file through the # include directive, you need to write the following rules:

Main.o: defs.h recipe...

You need a lot of these rules when managing large projects; writing them all down can be tedious. Fortunately, most modern C compilers can write these rules for you by looking at the # include line in the source file. For the GNU compiler collection (GCC), just add one command line argument:-MD depfile

# In scripts/Makefile.libc_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 main program fixdep then handles the other two dependencies by taking the depfile file and the command line as input, and then outputs a.. cmd file in makefile format, which records all prerequisites (including configuration) for the command line and the target. It looks like this:

# The command line used to compile the targetcmd_init/init_task.o: = gcc-Wp,-MD,init/.init_task.o.d-nostdinc. # The dependency filesdeps_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.

In the recursive make, the.. cmd file is included to provide all dependency information and to help decide whether to rebuild the target.

The secret behind this is that fixdep parses depfile (.d files), then parses all dependent files inside, searches for the text of all CONFIG_ strings, converts them to corresponding empty header files, and adds them to the target. Each time the configuration changes, the corresponding empty header file is also updated, so kbuild can detect the change and rebuild the target that depends on it. Because the command line is also recorded, it is easy to compare the last and current compilation parameters.

Thank you for reading! This is the end of the article on "what is the Secret of Kconfig/kbuild in Linux". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.