[Linux] __init & __setup 等宏的代码追踪
Platform:Linux 3.0.35
模仿 fbmem.c 的代码添加了 __setup 却无法触发效果(代码如下),所以原本的打算是追一下这个 __setup 的流程,结果还牵扯到了 kernel 初始化的一些相关知识,在此作简单记录。
static int __init my_video_setup(char *options) { printk("%s-------------------------%s\n",__FUNCTION__, options); return 1; } __setup("video=", my_video_setup);
__init_ & __init_data & __exit
先讲一下这两个宏,我们在很多地方都可以看到这两个宏对变量和方法的修饰,看一下宏的定义:
init.h
#define __init __section(.init.text) __cold notrace #define __initdata __section(.init.data) #define __initconst __section(.init.rodata) #define __exitdata __section(.exit.data) #define __exit_call __used __section(.exitcall.exit)
compiler.h
#define __section(S) __attribute__ ((__section__(#S)))
我没有对 __attribute__ 和 __section__ 做深入调查,但是它的作用就是将描述的变量或函数放入指定的段。
我们知道Linux可执行文件是ELF格式的,通过链接器和链接脚本将一个个的对象文件链接到一个ELF文件中,一个对象文件有很多段组成,如Text、Data、Bss等。
看一下__init,__initdata 是如何使用的:
static int __initdata text_int2 = 100; static int __init ch7036_init(void) { return i2c_add_driver(&ch7036_driver); } static void __exit ch7036_exit(void) { i2c_del_driver(&ch7036_driver); } module_init(ch7036_init); module_exit(ch7036_exit);
可以看到,我们对一个驱动模块的初始化函数统称都会添加 __init,对一个驱动模块的退出函数都会添加一个 __exit 来修饰。
被 __init 修饰的函数被放在 .init.text 段,__initdata 修饰的变量被放在 .init.data 段,在模块加载的时候会被调用,在模块加载初始化完成后,变量和函数占用的内存会被释放,整个.init 段都会被释放。
__exit 的作用类似 __init,只不过是在驱动模块卸载时调用。
下面这个例子可以验证我们上面所说的结论:
static int text_int1 = 10; static int __initdata text_int2 = 100; static ssize_t user_test(struct device *dev, struct device_attribute *attr, const char *buf, size_t count){ printk("----------------------text_int1----%d\n",text_int1); printk("----------------------text_int2----%d\n",text_int2); return count; } static DEVICE_ATTR(test, 644, NULL, user_test); static int __devinit dev_probe(struct i2c_client *client, const struct i2c_device_id *id){ ...... ......
printk("-------------ch7036_probe---------text_int2----%d\n",text_int2); return 0; ...... ...... }
结果是:
probe中可以输出 text_int2 的值 100; user_test中输出 text_int2 的值是0,因为 text_int2 在模块初始化结束后就已经释放了。
接下来看一下 module_init(), module_exit(),subsys_initcall() 这些函数是如何被调用的:
init.h
#define module_init(x) __initcall(x); #define module_exit(x) __exitcall(x); #define __initcall(fn) device_initcall(fn) #define __exitcall(fn) \ static exitcall_t __exitcall_##fn __exit_call = fn #define pure_initcall(fn) __define_initcall("0",fn,0) #define core_initcall(fn) __define_initcall("1",fn,1) #define core_initcall_sync(fn) __define_initcall("1s",fn,1s) #define postcore_initcall(fn) __define_initcall("2",fn,2) #define postcore_initcall_sync(fn) __define_initcall("2s",fn,2s) #define arch_initcall(fn) __define_initcall("3",fn,3) #define arch_initcall_sync(fn) __define_initcall("3s",fn,3s) #define subsys_initcall(fn) __define_initcall("4",fn,4) #define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s) #define fs_initcall(fn) __define_initcall("5",fn,5) #define fs_initcall_sync(fn) __define_initcall("5s",fn,5s) #define rootfs_initcall(fn) __define_initcall("rootfs",fn,rootfs) #define device_initcall(fn) __define_initcall("6",fn,6) #define device_initcall_sync(fn) __define_initcall("6s",fn,6s) #define late_initcall(fn) __define_initcall("7",fn,7) #define late_initcall_sync(fn) __define_initcall("7s",fn,7s) #define __define_initcall(level,fn,id) \ static initcall_t __initcall_##fn##id __used \ __attribute__((__section__(".initcall" level ".init"))) = fn
我们注意 __define_initcall 的定义,它就是将对应的 fn 放到了 ".initcall" level ".init" 段中,而这个 level 参数是传进来的,比如:
// level = 4,对应 .initcall4.init 段 #define subsys_initcall(fn) __define_initcall("4",fn,4) // level = 6,对应 .initcall6.init 段 #define device_initcall(fn) __define_initcall("6",fn,6)
根据前面的介绍,我们知道这些段必定会被链接器使用,而段的定义必定会在链接器脚本中:
vmlinux.lds.h:
#define INITCALLS \ *(.initcallearly.init) \ VMLINUX_SYMBOL(__early_initcall_end) = .; \ *(.initcall0.init) \ *(.initcall0s.init) \ *(.initcall1.init) \ *(.initcall1s.init) \ *(.initcall2.init) \ *(.initcall2s.init) \ *(.initcall3.init) \ *(.initcall3s.init) \ *(.initcall4.init) \ *(.initcall4s.init) \ *(.initcall5.init) \ *(.initcall5s.init) \ *(.initcallrootfs.init) \ *(.initcall6.init) \ *(.initcall6s.init) \ *(.initcall7.init) \ *(.initcall7s.init) #define INIT_CALLS \ VMLINUX_SYMBOL(__initcall_start) = .; \ INITCALLS \ VMLINUX_SYMBOL(__initcall_end) = .;
接下来的问题就是,kernel是如何定位到 init 段,以此执行每个 init 段中的函数呢,其实在kernel启动的时候会做这件事情:
kernel/init/main.c
start_kernel() -> rest_init() -> kernel_init() -> do_basic_setup() -> do_initcalls()
extern initcall_t __initcall_start[], __initcall_end[], __early_initcall_end[]; static void __init do_initcalls(void) { initcall_t *fn; for (fn = __early_initcall_end; fn < __initcall_end; fn++) do_one_initcall(*fn); }
从 __early_initcall_end 开始遍历到 __initcall_end,从上面 vmlinux.lds.h 中的代码中可以知道,其实就是从 .initcall0.init 开始遍历到 .initcall7s.init,依次调用这些段中的函数。
static int __init_or_module do_one_initcall_debug(initcall_t fn) { int ret; ... ... ret = fn(); ... ... return ret; }
上述就是对 __init 段的追踪,我们看到了驱动模块如何添加变量和方法到不同的 __init 段,链接脚本如何定义这些 __init 段,以及kernel何如遍历这些 __init 段并调用里面的函数。
TODO:驱动模块加载完成后,如何销毁内存;对 __exit 等其它段的追踪。
__setup 的实现
__setup 宏的作用是根据传入的字符串参数,与bootloader传递的参数进行匹配,从而调用传入的函数,如:
static int __init video_setup(char *options) { printk("%s\n", options); return 1; } __setup("video=", video_setup);
假如bootloader传给kernel的参数是“ video=xxxxx”,则会调用 video_setup 函数,printk 输出“xxxxx”。
看一下 __setup 的定义:
init.h:
#define __setup_param(str, unique_id, fn, early) \ static const char __setup_str_##unique_id[] __initconst \ __aligned(1) = str; \ static struct obs_kernel_param __setup_##unique_id \ __used __section(.init.setup) \ __attribute__((aligned((sizeof(long))))) \ = { __setup_str_##unique_id, fn, early } #define __setup(str, fn) \ __setup_param(str, fn, fn, 0)
以 “__setup("video=", video_setup);” 为例,可以简化为:
static const char __setup_str_video_setup[] __initconst __aligned(1) = "video="; static struct obs_kernel_param __setup_video_setup __used __section(.init.setup) __attribute__((aligned((sizeof(long))))) = { __setup_str_video_setup, video_setup, 0};
简单来讲就是定义了一个 obs_kernel_param 结构题变量,它的名字叫做 __setup_video_setup,里面有三个成员,分别是 char数组__setup_str_video_setup="video=" 、函数video_setup 、 一个叫做early的变量,此处的值为0。重点是,这个结构体变量被存放进了.init.setup 段。
联想到之前的 init 段,这个 .init.setup 段必然也是在kernel启动的时候被遍历。
先看一下链接器脚本文件 vmlinux.lds.h:
#define INIT_SETUP(initsetup_align) \ . = ALIGN(initsetup_align); \ VMLINUX_SYMBOL(__setup_start) = .; \ *(.init.setup) \ VMLINUX_SYMBOL(__setup_end) = .;
main.c
start_kernel() -> parse_early_param() / parse_args(...)
两个函数的本质一样,都是调用了 parse_args 函数。
前者:
parse_args("early options", cmdline, NULL, 0, do_early_param);
后者:
parse_args("Booting kernel", static_command_line, __start___param, __stop___param - __start___param, &unknown_bootoption);
params.c
int parse_args(const char *name, char *args, const struct kernel_param *params, unsigned num, int (*unknown)(char *param, char *val)) { char *param, *val; ... ... while (*args) { int ret; int irq_was_disabled; args = next_arg(args, ¶m, &val); irq_was_disabled = irqs_disabled(); ret = parse_one(param, val, params, num, unknown); ... ... } /* All parsed OK. */ return 0; }
看起来就是解析bootloader传给kernel的参数,在while循环里将参数一个个的取出,丢给 parse_one 函数。
比如(以空格做分隔做解析):
console=ttymxc1,115200 androidboot.console=ttymxc1 androidboot.hardware=freescale init=/init vmalloc=400M video=mxcfb0:dev=hdmi,1920x1080M@60,bpp=32
parse_one 函数的本质就是调用unkonwn函数,传递的参数就是param和val。
所以,两个函数本质分别是:
1. 遍历调用 do_early_param 函数,传入的参数有2个,格式是"xx=" 和 "xx",如:"console=" 和 "ttymxc1,115200" ; "androidboot.console=" 和 “ttymxc1” ; ... ...
2. 遍历调用 unknown_bootoption 函数,传入的参数同上。
static int __init do_early_param(char *param, char *val) { const struct obs_kernel_param *p; for (p = __setup_start; p < __setup_end; p++) { if ((p->early && strcmp(param, p->str) == 0) || (strcmp(param, "console") == 0 && strcmp(p->str, "earlycon") == 0) ) { if (p->setup_func(val) != 0) printk(KERN_WARNING "Malformed early option '%s'\n", param); } } /* We accept everything at this stage. */ return 0; }
首先定义了 struct obs_kernel_param *p, 还记得我们在分解 __setup 宏的时候提到过 名字叫做 __setup_video_setup 的 obs_kernel_param 变量,这个的指针p就是它。
然后从 __setup_start 开始遍历到 __setup_end,根据上面 vmlinux.lds.h 的代码知道,就是遍历整个 .init.setup 段。
看代码 “ (p->early && strcmp(param, p->str) == 0) ” 这边就体现了 early 的作用了,原来early 的值假如不为0,则会被更早得解析处理到。
随后,将param(从bootloader传过来的)和 p->str(__setup传进来的)进行匹配,若匹配成功,则调用 p->setup_func 方法,这个方法也是我们 __setup 自己定义传进来的。
unknown_bootoption 函数的功能类似,但它不会处理 p->early = 0 的数据。
基本逻辑就是这样,回到最初的问题,我在两个驱动模块中定义了 __setup("video=", my_video_setup),为什么模块1的函数能被触发,而模块2的函数无法被触发,原因很简单,因为当kernel拿着“video=”这个字串到 .init.setup 段中去遍历时,一旦遍历到匹配字串,就会调用对应函数,然后就终止遍历,所以始终只有一个匹配的 __setup 会被触发。