Reprint: Initcall

Transferred from: http://blog.chinaunix.net/uid-29570002-id-4387097.html

Linux The 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 entering subsystem initialization, in kernel Init The most complex and bizarre mechanism for device initialization in the process is do_initcalls () function call, which completes all the initialization of the static loading module, requires a static load of the kernel module, need to use some specific macros to handle, the following detailed to illustrate some of the linux kernel initcalls mechanism.

Let's take a look . do_initcalls () function Prototypes:

Figure 2

the core part is 639~671 between, this part is a function pointer call, traversing _initcall_start~_initcall_end range, calling function pointers one by one.

that _initcall_start~_initcall_end what is stored between them, 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 isNet_dev_init (), defined innet/core/dev.c, a macro is processed below the functionSubsys_initcall (Net_dev_init), the macro completes theNet_dev_initThe function pointer is placed in the. Initcall4.initsection, indo_initcalls ()when a function is called, it is in the_initcall_start~_initcall_enddirectly, soNet_dev_init ()It was called in this way.

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.

first say GCC " Span style= "font-family:"courier new"" > support for manual location of code snippets, _attribute_ Yes GCC _attribute_ _initdata

of course, how these paragraphs are generated is also a file to be configured, that is, in the link configuration file ARCH/XXX/VMLINUX.DS.S. in , as follows

Figure 4

in 2.6.16 " Span style= "font-family:"courier new"" > kernel Initcalls has been directly replaced with

* (. initcall1.init) * (. initcall2.init) * (. initcall3.init) * (. initcall4.init) * (. initcall5.init) * (. initcall6.init) * (. initcall7.init)

this and the figure 3 is the corresponding structure in the. 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) \     Staticinitcall_t __initcall_# #fn __attribute_used__ \ __attribute__ ((__section__ (". Initcall" Level". Init")) = fn #defineCore_initcall (FN) __define_initcall ("1", FN) #definePostcore_initcall (FN) __define_initcall ("2", FN) #defineArch_initcall (FN) __define_initcall ("3", FN) #defineSubsys_initcall (FN) __define_initcall ("4", FN) #defineFs_initcall (FN) __define_initcall ("5", FN) #defineDevice_initcall (FN) __define_initcall ("6", FN) #defineLate_initcall (FN) __define_initcall ("7", FN)

as you can see, the kernel is designed to meet different initialization levels. 1~7 Total 7 level, 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.

Overall, 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.

Reprinted: Initcall