fs_initcall、early_initcall、__init宏

fs_initcall、early_initcall...分析

在内核代码中经常可以看到类似fs_initcall\early_initcall\late_initcall这样的宏，这些宏有什么作用？如何实现的？下面来具体分析

具体定义

在include/linux/init.h中可以找到这些宏的定义

/* * Early initcalls run before initializing SMP. * * Only for built-in code, not modules. */#define early_initcall(fn)      __define_initcall(fn, early)/* * A "pure" initcall has no dependencies on anything else, and purely * initializes variables that couldn't be statically initialized. * * This only exists for built-in code, not for modules. * Keep main.c:initcall_level_names[] in sync. */#define pure_initcall(fn)       __define_initcall(fn, 0)#define core_initcall(fn)       __define_initcall(fn, 1)#define core_initcall_sync(fn)      __define_initcall(fn, 1s)#define postcore_initcall(fn)       __define_initcall(fn, 2)#define postcore_initcall_sync(fn)  __define_initcall(fn, 2s)#define arch_initcall(fn)       __define_initcall(fn, 3)#define arch_initcall_sync(fn)      __define_initcall(fn, 3s)#define subsys_initcall(fn)     __define_initcall(fn, 4)#define subsys_initcall_sync(fn)    __define_initcall(fn, 4s)#define fs_initcall(fn)         __define_initcall(fn, 5)#define fs_initcall_sync(fn)        __define_initcall(fn, 5s)#define rootfs_initcall(fn)     __define_initcall(fn, rootfs)#define device_initcall(fn)     __define_initcall(fn, 6)#define device_initcall_sync(fn)    __define_initcall(fn, 6s)#define late_initcall(fn)       __define_initcall(fn, 7)#define late_initcall_sync(fn)      __define_initcall(fn, 7s)

可以看到它们利用了__define_initcall宏：

/* initcalls are now grouped by functionality into separate * subsections. Ordering inside the subsections is determined * by link order. * For backwards compatibility, initcall() puts the call in * the device init subsection. * * The `id' arg to __define_initcall() is needed so that multiple initcalls * can point at the same handler without causing duplicate-symbol build errors. */#define __define_initcall(fn, id) \    static initcall_t __initcall_##fn##id __used \    __attribute__((__section__(".initcall" #id ".init"))) = fn; \    LTO_REFERENCE_INITCALL(__initcall_##fn##id)

从上面的注释信息可以看出：initcalls这类函数会被分别放置到不同的subsections中，subsections中的先后顺序由linker来决定（但是subsections之间的顺序是能够确定的，由vmlinux.lds.S指定）；此外id的作用是防止duplicate-symbol错误，如果没有这个参数，那么两类不同的initcall使用同一个fn的话会发生symbol重复定义的错误。

__define_initcall宏的作用是定义了一个initcall_t类型(函数指针)的变量，并将它放在名为.initcall#id.init的subsection中。该变量指向函数fn。
这样一来的话，这些subsection中存储的都是些函数指针，可以通过这些值来调用对应的函数。那么何时调用这些函数？

调用时机

首先，我们需要理解几个变量：

static initcall_t *initcall_levels[] __initdata = {    __initcall0_start,    __initcall1_start,    __initcall2_start,    __initcall3_start,    __initcall4_start,    __initcall5_start,    __initcall6_start,    __initcall7_start,    __initcall_end,};

这几个__initcall开头的变量值实际上是在link阶段就被确定了。在内核的链接脚本中会记录这几个subsection的起始、结束地址，分别存在上述变量中。这样的话就可以在程序中通过这些变量来访问这些subsections。

在内核启动初始化过程中会有下列流程：

start_kernel --> rest_init

在rest_init函数中会创建一个内核线程，执行kernel_init，

kernel_init --> kernel_init_freeable --> do_pre_smp_initcalls                              |---> do_basic_setup --> do_initcalls

early_initcall需要在SMP初始化之前被调用，其在do_pre_smp_initcalls函数中被调用：

static void __init do_pre_smp_initcalls(void){    initcall_t *fn;    for (fn = __initcall_start; fn < __initcall0_start; fn++)        do_one_initcall(*fn);}

这个for循环只对early_initcall定义的函数进行调用，do_one_initcall函数中会调用fn指向的函数。

同理，在do_initcalls函数中会对其他initcall函数进行调用。

module_init

我们现在知道了上面的initcall是在内核初始化过程中被调用的，因此使用initcall定义的函数一定是built-in的。

在模块编程的时候会使用到module_init，它也有两种定义，在include/linux/module.h中：

#ifndef MODULE......#define module_init(x)  __initcall(x);......#else /* MODULE */....../* Each module must use one module_init(). */#define module_init(initfn)                 \    static inline initcall_t __inittest(void)       \    { return initfn; }                  \    int init_module(void) __attribute__((alias(#initfn)));......#endif

对于built-in的模块，其module_init对应的是__initcall，最终对应的是device_initcall(在include/linux/init.h中)：

#define __initcall(fn) device_initcall(fn)

这样，在内核初始化过程中就会调用到模块的初始化函数。

对于load的模块，我们暂时先不关心，以后分析模块子系统时再看。

链接脚本上相关内容

上面提到过各个subsections之间的顺序在链接脚本中指定的，我们现在就来看看链接脚本中有关的内容。在arch/x86/kernel/vmlinux.lds.S中有以下内容：

......#include <asm-generic/vmlinux.lds.h>......SECTIONS{  ......  INIT_DATA_SECTION(16)  ......}

进入include/asm-generic/vmlinux.lds.h文件，我们可以看到INIT_DATA_SECTION的定义：

#define INIT_DATA_SECTION(initsetup_align)              \    .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {       \        ......        INIT_CALLS                      \        ......    }

而INIT_CALLS的定义如下：

#define INIT_CALLS_LEVEL(level)                                         \                VMLINUX_SYMBOL(__initcall##level##_start) = .;          \                *(.initcall##level##.init)                              \                *(.initcall##level##s.init)                             \#define INIT_CALLS                                                      \                VMLINUX_SYMBOL(__initcall_start) = .;                   \                *(.initcallearly.init)                                  \                INIT_CALLS_LEVEL(0)                                     \                INIT_CALLS_LEVEL(1)                                     \                INIT_CALLS_LEVEL(2)                                     \                INIT_CALLS_LEVEL(3)                                     \                INIT_CALLS_LEVEL(4)                                     \                INIT_CALLS_LEVEL(5)                                     \                INIT_CALLS_LEVEL(rootfs)                                \                INIT_CALLS_LEVEL(6)                                     \                INIT_CALLS_LEVEL(7)                                     \                VMLINUX_SYMBOL(__initcall_end) = .;

这个宏中的顺序就是在最终内核镜像中subsections之间的顺序，并且可以看到对于每个subsection都导出了xxx_start值，而整个initcall的范围是_initcall_start、_initcall_end，这些变量在上面处理initcall的时候会被使用到。

__init分析

__init也是在include/linux/init.h中定义的：

#define __init          __section(.init.text) __cold notrace

通过__init定义的函数表示是在内核初始化期间被调用的，当初始化完成之后会将他们释放掉。它指明将该函数放到.init.text section中。那么这个section放置在什么地方？

在arch/x86/kernel/vmlinux.lds.S中有以下内容：

......#include <asm-generic/vmlinux.lds.h>......SECTIONS{  ......  INIT_TEXT_SECTION(PAGE_SIZE)  ......  INIT_DATA_SECTION(16)  ......}

INIT_DATA_SECTION我们在上面已经分析过了，这里还有INIT_TEXT_SECTION，这个宏在vmlinux.lds.h中定义：

......#define INIT_TEXT                                                       \        *(.init.text)                                                   \        MEM_DISCARD(init.text)......#define INIT_TEXT_SECTION(inittext_align)                               \        . = ALIGN(inittext_align);                                      \        .init.text : AT(ADDR(.init.text) - LOAD_OFFSET) {               \                VMLINUX_SYMBOL(_sinittext) = .;                         \                INIT_TEXT                                               \                VMLINUX_SYMBOL(_einittext) = .;                         \        }......

可以看到上述是对.init.text section如何放置的描述，并且导出了_sinittext、_einittext分别表示此section的起始、结束地址。

链接脚本展开后最终的效果如下：

* SECTIONS* {*      . = START;*      __init_begin = .;*      HEAD_TEXT_SECTION*      INIT_TEXT_SECTION(PAGE_SIZE)*      INIT_DATA_SECTION(...)*      PERCPU_SECTION(CACHELINE_SIZE)*      __init_end = .;**      _stext = .;*      TEXT_SECTION = 0*      _etext = .;**      _sdata = .;*      RO_DATA_SECTION(PAGE_SIZE)*      RW_DATA_SECTION(...)*      _edata = .;**      EXCEPTION_TABLE(...)*      NOTES**      BSS_SECTION(0, 0, 0)*      _end = .;**      STABS_DEBUG*      DWARF_DEBUG**      DISCARDS                // must be the last* }

我们现在只关注和init section相关的，即被_init_begin和_init_end所包围的内容，这篇我们关注的initcalls和_init可以看到都包括在其中。

在上面我们提到了内核初始化尾声创建了一个kernel_init内核线程，其中会执行free_initmem函数：

void free_initmem(void){    free_init_pages("unused kernel",            (unsigned long)(&__init_begin),            (unsigned long)(&__init_end));}

可以看到它会将_init_begin和_init_end之间的内存释放掉。