Linux系统启动过程中的initcall实现原理和调试方法

最新推荐文章于 2023-05-24 13:50:58 发布

man9953212_real

最新推荐文章于 2023-05-24 13:50:58 发布

阅读量1.1k

点赞数 1

分类专栏： Linux学习文章标签： linux Powered by 金山文档

原文链接：https://blog.csdn.net/weixin_43644245/article/details/122440246

版权

Linux学习专栏收录该内容

20 篇文章 0 订阅

订阅专栏

1. 介绍

在linux kernel启动过程中，通过initcall机制调用初始化函数。initcall作为kernel经典设计机制之一延续至今。在2018年，Steven Rostedt为了跟踪调试各个初始化函数的耗时，增加了tracing功能。

在本篇文章中，会介绍initcall的意义和使用方法、实现原理、执行流程以及调试方法。

2. 意义和使用方法

正如文章最开始的地方所描述的那样，其直接意义是在kernel启动过程中执行不同的初始化函数，涉及到不同架构下的CPU初始化以及各种外设驱动的初始化。由于使用initcalls不需要显示的传递、存储和调用函数指针，我们只需要将函数标记为合适的initcall类型，内核代码就帮助我们完成了各函数的遍历执行，因此，基于initcall机制，可以使得代码更具模块化属性以及更高的可维护性。

kernel中的基于initcall机制定义的初始化代码遵循固定的规则：使用__init进行修饰，然后通过xxx_initcall声明为不同的类型。

static int __init register_cpufreq_notifier(void)
{
...
}
core_initcall(register_cpufreq_notifier);

每一个initcall函数都通过不同的前缀加以修饰，例如：

pure_initcall
subsys_initcall
core_initcall
fs_initcall
arch_initcall
...

在kernel代码中存在着大量的*_initcall修饰的函数。不同种类的initcall函数进行统计，如下图所示：

3. 实现原理

总体来说，initcall是基于以下思路设计出来的：

在生成vmlinux的链接阶段为initcall创建特定的section

开发者创建相关的initcall函数，并使用xxx_initcall声明为不同类型

每一类initcall对应一组section

遍历执行initcall section中的initcalls

xxx_initcall的定义位于include/linux/init.h中，从这个文件的名字也可以看出xxx_initcall是针对初始化操作的。

#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)

从上面的宏定义可以发现，所有的xxx_initcall都是基于__define_initcall的，后者的定义位于同一个文件中，通过__define_initcall将各个xxx_initcall统一到一起，基于ID编号链接到不同的subsection，在同一个subsection中各个initcall的排序以链接的顺序为准。另外，__define_initcall中的ID编号还有另外一个作用，就是防止不同类型的xxx_initcall调用相同的符号引起编译错误。

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

以rockchip_grf_init()为例拆解分析xxx_initcall的实现细节，如下图所示，注意，在倒数第二个框图内可以看出来initcall机制使用到了GNU编译工具链的属性。

4. 执行流程

根据前面的介绍，当xxx_initcall被链接到目标文件后，会生成不同类别的section，包含不同的initcall函数，如下所示：

.initcallearly.init    0000000000000008 __initcall_trace_init_flags_sys_exitearly
.initcall0.init        0000000000000008 __initcall_ipc_ns_init0
.initcall1.init        0000000000000008 __initcall_map_entry_trampoline1
.initcall2.init        0000000000000008 __initcall_bdi_class_init2
.initcall3.init        0000000000000008 __initcall_dma_bus_init3
.initcall4.init        0000000000000008 __initcall_fbmem_init4
.initcall5.init        0000000000000008 __initcall_chr_dev_init5
.initcall6.init        0000000000000008 __initcall_hwrng_modinit6
.initcall7.init        0000000000000008 __initcall_deferred_probe_initcall7
.initcallrootfs.init   0000000000000008 __initcall_populate_rootfsrootfs

同一类的initcall执行顺序由编译顺序决定，不同类的initcall执行顺序在init/main.c中定义，如下所示：

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

在实际执行时，内核必须知道xxx_initcall section所在的位置，而在include/asm-generic/vmlinux.lds.h中将xxx_start和.initcall*.init链接到了一起，这样的话，do_initcalls()遍历不同ID的initcall时，基于xxx_start便可以找到想对应的.initcall entry，然后循环遍历里面的各个initcalls。

#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) = .;

在arch/arm64/kernel/vmlinux.lds中可以看到initcall的符号排布如下图所示，基于*_start可以定位到各个initcall函数所对应的符号。

基于以上分析，整理出initcalls的完整执行流程如下：

5. 调试方法

你可能会遇到kernel启动时间特别长，而kernel中又有如此多的initcall函数，又不知从何下手？那么，本文介绍的两种典型调试手段也许会对你有所帮助。

5.1 initcall_debug

CMDLINE中增加initcall_debug选项

console=ttyS0,115200...initcall_debug

打开CMDLINE选项

[root@rk3399:/]# dmesg | grep initcall
[    0.000000] Kernel command line: initcall_debug storagemedia=emmc androidboot.storagemedia=emmc androidboot.mode=normal  androidboot.slot_suffix= androidboot.serialno=d3143e5cd395b593  rw rootwait earlycon=uart8250,mmio32,0xff1a0000 swiotlb=1 console=ttyFIQ0 root=PARTUUID=614e0000-0000 rootfstype=ext4 coherent_pool=1m
[    0.126902] initcall trace_init_flags_sys_exit+0x0/0x1c returned 0 after 0 usecs
......
[    0.227475] initcall rockchip_grf_init+0x0/0x12c returned 0 after 976 usecs
[    0.227515] initcall rockchip_pm_domain_drv_register+0x0/0x20 returned 0 after 0 usecs
......
[   10.106112] initcall hci_uart_init+0x0/0x1000 [hci_uart_aw] returned 0 after 2840 usecs
[root@rk3399:/]#

虽然initcall_debug是一个不错的调试手段，可以用来检测哪些初始化调用花费了太多的时间。然而，当内核打印级别设置的不合适时，这些调试日志会直接打印在控制台上，并且和其他日志信息混杂到了一起，如果不借助字符串搜索功能，很难一目了然的找到我们想要的信息。

5.2 ftrace

如果是2018年以后的内核（4.16.0-rc4），则可以基于ftrace分析initcall的执行情况。

author    Steven Rostedt (VMware) <rostedt@goodmis.org>    2018-03-23 10:18:03 -0400
committer    Steven Rostedt (VMware) <rostedt@goodmis.org>    2018-04-06 08:56:54 -0400
commit    4ee7c60de83ac01fa4c33c55937357601631e8ad (patch)
---
init, tracing: Add initcall trace events
Being able to trace the start and stop of initcalls is useful to see where
the timings are an issue. There is already an "initcall_debug" parameter,
but that can cause a large overhead itself, as the printing of the
information may take longer than the initcall functions.

Adding in a start and finish trace event around the initcall functions, as
well as a trace event that records the level of the initcalls, one can get a
much finer measurement of the times and interactions of the initcalls
themselves, as trace events are much lighter than printk()s.

打开trace相关功能，CMDLINE中增加trace选项

console=ttyS0,...trace_event=initcall:initcall_level,initcall:initcall_start,initcall:initcall_finish

结果：

# mount -t debugfs nodev /sys/kernel/debug
# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 1090/1090   #P:4
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
          -0     [000] ....     0.000125: initcall_level: level=console
          -0     [000] ....     0.000136: initcall_start: func=con_init+0x0/0x220
          -0     [000] ....     0.000232: initcall_finish: func=con_init+0x0/0x220 ret=0
          -0     [000] ....     0.000235: initcall_start: func=univ8250_console_init+0x0/0x3c
          -0     [000] ....     0.000246: initcall_finish: func=univ8250_console_init+0x0/0x3c ret=0
       swapper/0-1     [000] ....     0.002016: initcall_level: level=early
       swapper/0-1     [000] ....     0.002026: initcall_start: func=trace_init_flags_sys_exit+0x0/0x24
 ...
[...]

Linux中的各种initcall总结

今天看Linux源码中的dma.c中，最后一句是arch_initcall(xxx)，心想怎么又出来一个init的函数。目前只见过module_init和subsys_init。于是想对init函数探一究竟，到底什么区别，都在什么时候用呢？

答案是：他们的区别仅仅是优先级不同。

如：

core_initcall(fn) .initcall1.init

postcore_initcall(fn) .initcall2.init

arch_initcall(fn) .initcall3.init

subsys_initcall(fn) .initcall4.init

fs_initcall(fn) .initcall5.init

device_initcall(fn) .initcall6.init

late_initcall(fn) .initcall7.init

上述7个initcall函数，从上到下优先级依次降低。

其中，level=6的device_initcall就是我们常用的module_init。

但是只知道了优先级，还是不知道在什么样的场合用多高优先级的init的啊？偶觉得只知道一些常用的就可以了，目前我只见过arch_initcall、subsys_initcall和module_init，只说这三个吧。

1、arch_initcall，level=3，用在arch级的初始化，比如machine_init，如目录/arch/arm/mach-s3cxx下。

2、subsys_initcall，level=4，顾名思义，用在子系统中，比如IIC、SPI、USB、SD、PCI等子系统的初始化，如子系统的总线驱动中，目录/drivers/i2c/busses下。

3、module_init，即device_initcall，level=6，用在设备驱动中，这个对于驱动开发者来说就比较熟悉了，用的比较多。

另：对于初始化有依赖关系的两个程序，被依赖的initcall优先级肯定不会比依赖它的程序initcall优先级低。

man9953212_real

关注

1
点赞
踩
10

收藏

觉得还不错? 一键收藏
0
评论
Linux系统启动过程中的initcall实现原理和调试方法

1. 介绍在linux kernel启动过程中，通过initcall机制调用初始化函数。initcall作为kernel经典设计机制之一延续至今。在2018年，Steven Rostedt为了跟踪调试各个初始化函数的耗时，增加了tracing功能。在本篇文章中，会介绍initcall的意义和使用方法、实现原理、执行流程以及调试方法。2. 意义和使用方法正如文章最开始的地方所描述的那样，其直接意义是在kernel启动过程中执行不同的初始化函数，涉及到不同架构下的CPU初始化以及各种外设驱动的初始化。
复制链接

扫一扫