Linux Initcall mechanism

the Linux system startup process is complex because it requires both the static loading mechanism of the module and the dynamic loading mechanism. The dynamic loading mechanism provides a great deal of flexibility to the system, and the driver can support the static compilation into the kernel or the dynamic loading mechanism. The initialization of devices and subsystems in a Linux system is performed at the end, and the main process can be expressed.

Figure 1

When the subsystem is initialized, the most complex and bizarre mechanism for initializing the device during the kernel init process is the do_initcalls () function call, which completes all initialization of the static loading module, requires the kernel module to be loaded statically, and needs to be handled with some specific macros. The following details describe some of the initcalls mechanisms in the Linux kernel.

Let's take a look at the Do_initcalls () function prototype:

Figure 2

The core part is between 639~671, which is a function pointer call that iterates through the _initcall_start~_initcall_end range and invokes the function pointer one at a time.

What is stored between the _initcall_start~_initcall_end, can be described in one of the following.

Figure 3

On the left is the address pointer, the right is the related macro, using the relevant macro processing function pointers, you can put the processed function pointer within a specific pointer range. For example, the network device layer initialization function is net_dev_init (), defined in NET/CORE/DEV.C, with a macro processing Subsys_initcall (net_dev_init) below the function, which completes NET_DEV_ The INIT function pointer is placed in the. Initcall4.init segment, when the Do_initcalls () function is called, it is _initcall_start~_initcall_end directly, so Net_dev_init () is called.

This mechanism is quite ingenious, but also more difficult to understand, designed to achieve a common start-up process, so that when porting or extension, only need to start loading the module for macro processing.

Here's a detailed look at how this mechanism is implemented.

Let's talk first. GCC support for manual location of code snippets, _attribute_ is a key word for GCC, which instructs the compiler to set specific properties for symbols. After compiling the input to the linker is a file with the symbol table, the linker on the individual files to reposition the symbol, _attribute_ at this stage, the specified symbol is placed in a link to the specific location of the file segment, not only refers to the code snippet, but also includes data segments, such as the system initialization often see _ InitData to place the specified symbol at a specific location in the data segment.

Of course, the specific paragraphs are generated, and there are files to configure, that is, in the link profile arch/xxx/vmlinux.ds.s.

Figure 4

In the 2.6.16 kernel, Initcalls has been directly replaced by the

* (. Initcall1.init) * (. initcall2.init) * (. initcall3.init) * (. initcall4.init) * (. initcall5.init) * (. Initcall6.init) * ( . Initcall7.init)

This corresponds to the structure in Figure 3. Next look at what macro definitions the kernel provides to handle specific function pointers and data. In the Include/linux/init.h file, include a variety of common packaging.

#define __define_initcall (LEVEL,FN)     static initcall_t __initcall_# #fn __attribute_used__     __attribute__ ((__ Section__ (". Initcall" Level ". Init")) = Fn#define Core_initcall (FN)       __define_initcall ("1", fn) #define Postcore_ Initcall (FN)   __define_initcall ("2", fn) #define Arch_initcall (FN)       __define_initcall ("3", fn) #define Subsys_ Initcall (FN)     __define_initcall ("4", fn) #define Fs_initcall (FN)         __define_initcall ("5", fn) #define Device_ Initcall (FN)     __define_initcall ("6", fn) #define Late_initcall (FN)       __define_initcall ("7", FN)

As can be seen, the kernel to meet different levels of initialization, the design of 1~7 a total of 7 levels, different levels of initialization code with the corresponding macro processing, the reader can be compared to the table to understand. There are other macros that are used for various task requirements, such as module add-in Module_init (), Module_exit (), which are handled slightly differently and can be understood by the reader.

In general, the Initcalls mechanism provides an excuse for kernel developers or driver developers to add their own functions to the kernel initialization list and process them in the final phase of kernel initialization.

Original link: http://blog.csdn.net/u012497906/article/details/46234675

Linux Initcall mechanism