linux内核initcall放置在各个section中函数执行流程

前言

linux以及嵌入式一些代码，我们看到core_initcall、device_initcall等等需要链接器分配各个section，并且在启动该模块时候执行。下面我们详细追溯一下路径

作者：良知犹存

转载授权以及围观：欢迎关注微信公众号：羽林君

或者添加作者个人微信：become_me

---

正文

fs_initcall函数介绍：

Linux内核中的fs_initcall函数：用于在引导过程中进行文件系统等初始化。

1. 初始化注册：

   • 当文件系统模块被加载时，它使用fs_initcall宏注册其初始化函数。
   • 该宏将初始化函数添加到__initcall_fs部分。

2. 内核引导过程：

   • 在引导过程中，在基本硬件初始化和内存设置之后，内核开始执行初始化函数。

3. 执行fs_initcall函数：

   • fs_initcall函数按照其注册顺序依次执行。
   • 这些函数初始化各种文件系统并执行必要的设置任务。

4. 文件系统初始化：

   • 每个fs_initcall函数负责设置和初始化特定的内容。
   • 这可能涉及初始化数据结构、注册文件系统类型、准备缓存和其他相关任务。

5. 完成和交接：

   • 一旦所有fs_initcall函数都执行完毕，内核会继续完成引导过程，包括启动用户空间和初始化设备。

下面是一个简单的示例代码，展示了fs_initcall函数的使用和文件系统初始化的过程：

#include 
#include 

static int __init my_filesystem_init(void) {
    // 执行文件系统特定的初始化任务
    printk(KERN_INFO "My Filesystem: Initializing\n");
    // 其他初始化操作...

    return 0;
}

fs_initcall(my_filesystem_init);

MODULE_LICENSE("GPL");

这其中my_filesystem_init函数被注册为fs_initcall函数。当模块加载时，该初始化函数将被执行，完成特定文件系统的初始化任务。实际的文件系统模块会包含更多复杂的初始化逻辑，这个例子只是用来展示fs_initcall函数的基本用法。

fs_initcall函数调用的层次：

在Linux内核中，fs_initcall宏实际上是通过__define_initcall来定义的。下面是__define_initcall的定义：

#define __define_initcall(fn, id) \
    static initcall_t __initcall_##fn##id __used \
    __attribute__((__section__(".initcall" #id ".init"))) = fn

这段代码展示了__define_initcall的定义方式。在这里，__define_initcall宏创建了一个静态的initcall_t类型变量，并将其放置在特定的.initcall节(section)中。这样，在内核初始化时，这些函数就会按照其在源代码中出现的顺序被依次调用。

fs_initcall实际上是通过__define_initcall宏来实现的，它们共同构成了Linux内核中初始化调用机制的一部分。

fs_initcall函数被放置的section的位置

在Linux内核中，.initcall节(section)是通过链接脚本（linker script）定义的。链接脚本指定了可执行文件的内存布局，包括代码、数据和其他段的放置位置。

对于.initcall节(section)，它通常由链接脚本中的一些规则来定义。这个节用于存放初始化函数的地址，以便在内核启动时按照顺序执行这些初始化函数。

具体的定义可能会因内核版本和架构而异，但通常可以在内核源代码的arch//kernel/vmlinux.lds.S或类似的文件中找到相关的链接脚本定义。在这些文件中，我们可以看到下面的内容：

.initcall.init : {
    INIT_CALLS
}

文件位置：\linux-xxx\arch\arm\kernel\vmlinux.lds.S

文件位置：\linux-xxx\include\asm-generic\vmlinux.lds.h

：

           __initcall_start = .;
           .initcall.init : {
                 *(.initcall1.init)
                ...
                 *(.initcall7.init)
                 }
           __initcall_end = .;

上面是INIT_CALLS对应的函数，*(.initcall##level##.init),这个函数就对应了__define_initcall宏里面的__section__(".initcall" #id ".init"),继续查看fs_initcall，对应的level就是这个部分__define_initcall(fn, 5)的5。

上述示例中的INIT_CALLS通常会包含对.initcall节(section)的定义，规定了将哪些符号放入该节中。这些定义可能会随着不同的内核版本和架构而有所不同，但其基本思想是相似的：将初始化函数的地址放入特定的节(section)中，以便在启动时按顺序执行这些函数。

__define_initcall这个宏也是可以设置多个初始化函数，并将它们放置在不同的.initcall节(section)中。

假设我们有两个初始化函数：init_function_1和init_function_2，我们可以使用上述宏定义来将它们分别放置在不同的.initcall节(section)中。

// 定义多个初始化函数
static void __init init_function_1(void) {
    // 初始化函数1的内容
}

static void __init init_function_2(void) {
    // 初始化函数2的内容
}

// 使用 __define_initcall 宏定义来设置多个函数
__define_initcall(init_function_1, 1);
__define_initcall(init_function_2, 2);

在这个例子中，init_function_1被放置在.initcall1.init节(section)中，而init_function_2则被放置在.initcall2.init节(section)中。这样，在内核启动时，这些函数就会按照其在源文件中出现的顺序依次被调用。

通过使用带有不同标识符的宏定义，可以将多个初始化函数放置在不同的.initcall节(section)中，从而实现按顺序执行多个初始化函数的目的。

以af_inet.c里面的fs_initcall(inet_init);fs_initcall(ipv4_offload_init);介绍放置的情况：
怎么在section放置的

在这个例子中，fs_initcall宏用于将inet_init和ipv4_offload_init函数放置在.initcall.init节(section)中。这样，在内核启动时，这些函数就会按照其在源文件中出现的顺序依次被调用。

下面是简化版本的代码:

// 定义要初始化的函数
static void __init inet_init(void) {
    // inet_init的初始化内容
}

static void __init ipv4_offload_init(void) {
    // ipv4_offload_init的初始化内容
}

// 使用 fs_initcall 宏将函数放置在 .initcall.init 节(section)中
fs_initcall(inet_init);
fs_initcall(ipv4_offload_init);

上述代码，inet_init和ipv4_offload_init函数会被放置在.initcall.init节(section)中，以便在内核启动时按照其在源文件中出现的顺序依次被调用。

通过这个例子，我们明白了如何使用fs_initcall宏将这两个函数放置在.initcall.init节(section)中.

每个section空间排布情况是如何的？

还是上面inet_init和ipv4_offload_init函数来介绍，由于fs_initcall宏使用了__attribute__((__section__(".initcall.init")))，这将导致这些函数被放置在.initcall.init节(section)中。这样，在链接时，这些函数的地址将按照其在源文件中出现的顺序排布在该特定的节(section)内。

这些函数位于可执行文件的内存中的某个位置，它们的排布情况如下所示：

|---------------------|
|     .text section   |
|---------------------|
|    ... other sections ...   |
|---------------------|
|  .initcall.init section  |
|---------------------|
|       inet_init      |
|---------------------|
|  ipv4_offload_init   |
|---------------------|
|    ... other functions ...   |
|---------------------|
|       .data section  |
|---------------------|
|      ... other sections ...    |
|---------------------|

在这个示例中，.initcall.init节(section)包含了inet_init和ipv4_offload_init函数，它们会按照它们在源代码中出现的顺序排布在该节(section)中。这样，在内核启动时，这些函数就会按照它们在.initcall.init节(section)中的排布顺序依次被调用。

这里section的大小是随机按照大小自动分配还是需要开发者设置好

在一般情况下，.initcall.init这样的特殊节(section)的大小是由链接器自动分配的，而不是由开发者手动设置的。当链接器处理可执行文件时，它会根据各个节(section)中的内容以及链接脚本中的规则来确定每个节(section)的大小和排布。

对于.initcall.init节(section)，其大小将取决于其中包含的初始化函数的数量和大小。链接器会根据这些函数的地址和大小来动态地分配空间，以便容纳所有的初始化函数。

因此，开发者通常无需手动设置.initcall.init节(section)的大小。相反，链接器会根据实际情况自动进行分配，确保所有的初始化函数都能被正确地安置在这个特定的节(section)中，并且在内核启动时按照顺序被调用。

如何自己设置section的大小

在一般情况下，开发者通常不需要手动设置节(section)的大小。链接器会根据链接脚本中的规则和可执行文件中各个部分的大小自动进行分配。

如果我们有特殊需求，希望手动设置某个节(section)的大小，可以通过链接脚本来实现。在链接脚本中，我们可以定义节(section)的起始位置、大小以及其他属性。

以下简单的模板，在链接脚本中手动设置一个名为.my_section的节(section)的大小：

.my_section : {
    /* 定义节(section)的起始位置 */
    start = .;
    /* 设置节(section)的大小为固定值（例如0x1000）*/
    input_section(.text);
    input_section(.data);
    /* 其他内容... */
    end = .;
} > RAM

在这个示例中，.my_section节(section)被手动设置为包含.text和.data节(section)的内容，并且其大小被设置为固定值。当链接器处理可执行文件时，它将按照这些规则来分配空间并确定这个特定节(section)的大小。

需要注意的是，手动设置节(section)的大小可能需要对链接脚本和链接过程有深入的了解，因此在大多数情况下，开发者无需手动设置节(section)的大小，而是依赖于链接器自动进行分配。

这个是我实际应用的一款芯片的链接修改：

FUN 0x400 （0x10000-0x400）
{
    ;cpu.o (+RO)
    xlib.a (+RO)
}

上面这部分我使用的链接脚本中一部分内容。为FUN的节(section)中，它的起始地址为0x10000，大小为0x400。

在这个节(section)中包含了两个文件：cpu.o 和 xlib.a，它们都被标记为只读（Read-Only）。链接器会将这两个文件的只读部分放置在由FUN定义的地址范围内。

链接脚本用于指导链接器如何组织可执行文件的各个部分，包括节(section)的排布和属性。这个片段也是属于链接脚本的一部分，这个里面链接器会将cpu.o和xlib.a的只读部分放置在从0x10000开始、大小为0x400的范围内。

只是一个demo示例，如果进一步操作这个链接脚本，我们要参考特定的链接器文档以及相关的目标平台和工具链的文档，以确保正确地设置节(section)的属性和排布。芯片之间区别挺大的。

内核执行顺序是？

介绍完了section片段，我们再来说一下，这些函数的初始化位置以及执行顺序。

上面我们介绍了vmlinux.lds.S中的INIT_CALLS就是我们定义好的那些函数，那他们怎么被调用的呢
在Linux内核启动过程中，INIT_CALLS（包括subsys_initcall，fs_initcall，device_initcall等）会在不同的阶段被执行。这些初始化调用是通过链接器脚本和特定的内核宏来安排的。

具体来说，INIT_CALLS的执行时机如下：

1. 在内核启动的早期阶段，start_kernel函数会调用rest_init。
2. 在rest_init中，会触发do_basic_setup函数的执行，其中包括对文件系统的基本设置。
   
3. 在do_basic_setup函数中，会调用do_initcalls函数。
   
4. 在do_initcalls函数中，各种初始化函数会按照链接器脚本中的顺序被执行。
   
5. fs_initcall函数是其中之一。

看到了执行过程，其中是按照各个level进行调用的，而__define_initcall(level,fn)的作用就是指示编译器把一些初始化函数的指针(即:函数起始地址)按照顺序放置一个名为 .initcall.init 的section中，这个section又被分成了n个子section，它们按顺序排列。在内核初始化阶段，这些放置到这个section中的函数指针将供do_initcalls() 按顺序依次调用，来完成相应初始化。

而函数指针放置到的子section由宏定义的level确定，对应level较小的子section位于较前面。而位于同一个子section内的函数指针顺序不定，将由编译器按照编译的顺序随机指定。同理，如果我们想先执行一些定义的函数，那就可以把它们放置于level比较小的定义中。

结语

这就是我自己对于linux内核initcall放置在各个section中函数执行流程的一些分享。如果大家有更好的想法，也欢迎大家加我好友交流。

---

作者：良知犹存，白天努力工作，晚上原创公号号主。公众号内容除了技术还有些人生感悟，一个认真输出内容的职场老司机，也是一个技术之外丰富生活的人，摄影、音乐 and 篮球。关注我，与我一起同行。

                              ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧  END  ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧

推荐阅读

【1】jetson nano开发使用的基础详细分享

【2】Linux开发coredump文件分析实战分享

【3】CPU中的程序是怎么运行起来的 必读

【4】cartographer环境建立以及建图测试

【5】设计模式之简单工厂模式、工厂模式、抽象工厂模式的对比

本公众号全部原创干货已整理成一个目录，回复[ 资源 ]即可获得。