linux kernel的cmdline参数解析原理分析
来源:互联网 发布:萨克斯怎么挑选知乎 编辑:程序博客网 时间:2024/05/17 04:14
FROM:http://blog.csdn.net/skyflying2012/article/details/41142801
利用工作之便,今天研究了kernel下cmdline参数解析过程,记录在此,与大家共享,转载请注明出处,谢谢。
Kernel 版本号:3.4.55
Kernel启动时会解析cmdline,然后根据这些参数如console root来进行配置运行。
Cmdline是由bootloader传给kernel,如uboot,将需要传给kernel的参数做成一个tags链表放在ram中,将首地址传给kernel,kernel解析tags来获取cmdline等信息。
Uboot传参给kernel以及kernel如何解析tags可以看我的另一篇博文,链接如下:
http://blog.csdn.NET/skyflying2012/article/details/35787971
依据我的思路(时间顺序,如何开始,如何结束),首先看kernel下2种参数的注册。
第一种是kernel通用参数,如console=ttyS0,115200 root=/rdinit/init等。这里以console为例。
第二种是kernel下各个driver中需要的参数,在写driver中,如果需要一些启动时可变参数。可以在driver最后加入module_param()来注册一个参数,kernel启动时由cmdline指定该参数的值。
这里以drivers/usb/gadget/serial.c中的use_acm参数为例(这个例子有点偏。。因为最近在调试usb虚拟串口)
一 kernel通用参数
对于这类通用参数,kernel留出单独一块data段,叫.ini.setup段。在arch/arm/kernel/vmlinux.lds中:
可以看到init.setup段起始__setup_start和结束__setup_end。
.init.setup段中存放的就是kernel通用参数和对应处理函数的映射表。在include/Linux/init.h中
可以看出宏定义__setup以及early_param定义了obs_kernel_param结构体,该结构体存放参数和对应处理函数,存放在.init.setup段中。
可以想象,如果多个文件中调用该宏定义,在链接时就会根据链接顺序将定义的obs_kernel_param放到.init.setup段中。
以console为例,在/kernel/printk.c中,如下:
__setup宏定义展开,如下:
__setup_console_setup编译时就会链接到.init.setup段中,kernel运行时就会根据cmdline中的参数名与.init.setup段中obs_kernel_param的name对比。
匹配则调用console-setup来解析该参数,console_setup的参数就是cmdline中console的值,这是后面参数解析的大体过程了。
二 driver自定义参数
对于driver自定义参数,kernel留出rodata段一部分,叫__param段,在arch/arm/kernel/vmlinux.lds中,如下:
该段放在.rodata段中。
那该段中存放的是什么样的数据呢?
Driver中使用module_param来注册参数,跟踪这个宏定义,最终就会找到对__param段的操作函数如下:
以driver/usb/gadget/serial.c中的use_acm为例,如下:
Module_param展开到__module_param_call,如下:
将__module_param_call展开,可以看到是定义了结构体kernel_param,如下:
很清楚,跟.init.setup段一样,kernel链接时会根据链接顺序将定义的kernel_param放在__param段中。
Kernel_param有3个成员变量需要注意:
(1)
ops=param_ops_bool,是kernel_param_ops结构体,定义如下:
这2个成员函数分别去设置和获取参数值
在kernel/param.c中可以看到kernel默认支持的driver参数类型有bool byte short ushort int uint long ulong string(字符串) charp(字符串指针)array等。
对于默认支持的参数类型,param.c中提供了kernel_param_ops来处理相应类型的参数。
(2)
Arg = &use_acm,宏定义展开,可以看到arg中存放use_acm的地址。参数设置函数param_set_bool(const char *val, const struct kernel_param *kp)
将val值设置到kp->arg地址上,也就是改变了use_acm的值,从而到达传递参数的目的。
(3)
.name=MODULE_PARAM_PREFIX#use_acm,定义了该kernel_param的name。
MODULE_PARAM_PREFIX非常重要,定义在include/linux/moduleparam.h中:
如果我们是模块编译(make modules),则MODULE_PARAM_PREFIX为empty。
在模块传参时,参数名为use_acm,如insmod g_serial.ko use_acm=0
正常编译kernel,MODULE_PARAM_PREFIX为模块名+”.”
如果我们在传参时不知道自己的模块名是什么,可以在自己的驱动中加打印,将MODULE_PARAM_PREFIX打印出来,来确定自己驱动的模块名。
所以这里将serial.c编入kernel,根据driver/usb/gadget/Makefile,如下:
最终是生成g_serial.o,模块名为g_serial.ko。.name = g_serial.use_acm。
kernel传参时,该参数名为g_serial.use_acm
这样处理防止kernel下众多driver中出现重名的参数。
可以看出,对于module_param注册的参数,如果是kernel默认支持类型,kernel会提供参数处理函数。
如果不是kernel支持参数类型,则需要自己去实现param_ops##type了。
这个可以看drivers/video/uvesafb.c中的scroll参数的注册(又有点偏。。。无意间找到的)。
参数注册是在kernel编译链接时完成的(链接器将定义结构体放到.init.setup或__param中)
接下来需要分析kernel启动时如何对传入的cmdline进行分析。
三 kernel对cmdline的解析
根据我之前写的博文可知,start_kernel中setup_arch中解析tags获取cmdline,拷贝到boot_command_line中。我们接着往下看start_kernel。
调用setup_command_line,将cmdline拷贝2份,放在saved_command_line static_command_line。
下面调用parse_early_param(),如下:
Parse_args遍历cmdline,按照空格切割获取参数,对所有参数调用next_arg获取参数名param和参数值val。如console=ttyS0,115200,则param=console,val=ttyS0,115200。调用parse_one。如下:
由于从parse_early_options传入的num_params=0,所以parse_one是直接走的最后handle_unknown函数。该函数是由parse-early_options传入的do_early_param。如下:
Do_early_param遍历.init.setup段,如果有obs_kernel_param的early为1,或cmdline中有console参数并且obs_kernel_param有earlycon参数,则会调用该obs_kernel_param的setup函数来解析参数。
Do_early_param会对cmdline中优先级较高的参数进行解析。我翻了下kernel源码找到一个例子,就是arch/arm/kernel/early_printk.c,利用cmdline参数earlyprintk来注册最早的一个console,有兴趣大家可以参考下。
如果想kernel启动中尽早打印输出,方便调试,可以注册str为earlycon的obs_kernel_param。
在其setup参数处理函数中register_console,注册一个早期的console,从而是printk信息正常打印,这个在后面我还会总结一篇kernel打印机制来说这个问题。
do_early_param是为kernel中需要尽早配置的功能(如earlyprintk earlycon)做cmdline的解析。
Do_early_param就说道这里,该函数并没有处理我们经常使用的kernel通用参数和driver自定义参数。接着往下看。代码如下:
Parse_early_param结束后,start_kernel调用了parse_args。这次调用,不像parse_early_param中调用parse_args那样kernel_param指针都为NULL,而是指定了.__param段。
回到上面看parse_args函数,params参数为.__param段起始地址,num为kernel_param个数。
Min_level,max_level都为-1.unknown=unknown_bootoption
Parse_args还是像之前那样,遍历cmdline,分割获取每个参数的param和val,对每个参数调用parse_one。
回看Parse_one函数源码:
(1)parse_one首先会遍历.__param段中所有kernel_param,将其name与参数的param对比,同名则调用该kernel_param成员变量kernel_param_ops的set方法来设置参数值。
联想前面讲driver自定义参数例子use_acm,cmdline中有参数g_serial.use_acm=0,则在parse_one中遍历匹配在serial.c中注册的__param_use_acm,调用param_ops_bool的set函数,从而设置use_acm=0.
(2)如果parse_args传给parse_one是kernel通用参数,如console=ttyS0,115200。则parse_one前面遍历.__param段不会找到匹配的kernel_param。就走到后面调用handle_unknown。就是parse_args传来的unknown_bootoption,代码如下:
首先repair_env_string会将param val重新组合为param=val形式。
Obsolete_checksetup则遍历-init_setup段所有obs_kernel_param,如有param->str与param匹配,则调用param_>setup进行参数值配置。
这里需要注意的一点是repair_env_string将param重新拼成了param=val形式。后面遍历匹配都是匹配的”param=”而不是“param”。
如之前分析kernel通用参数所举例子,__setup(“console=”, console_setup)。
Console=ttyS0,115200,obsolete_checksetup是匹配前面console=,如果匹配,则跳过console=,获取到其值ttyS0,115200,调用其具体的setup函数来解析设置参数值。
可以想象,parse_one对于parse_args传来的每一个cmdline参数都会将.__param以及-init.setup段遍历匹配,匹配到str或name一致,则调用其相应的set或setup函数进行参数值解析或设置。
Start_kernel中Parse_args结束,kernel的cmdline就解析完成!
总结下kernel的参数解析:
(1)kernel编译链接,利用.__param .init.setup段将kernel所需参数(driver及通用)和对应处理函数的映射表(obs_kernel_param kernel_param结构体)存放起来。
(2)Kernel启动,do_early_param处理kernel早期使用的参数(如earlyprintk earlycon)
(3)parse_args对cmdline每个参数都遍历__param .init.setup进行匹配,匹配成功,则调用对应处理函数进行参数值的解析和设置。
还有一点很值得思考,kernel下对于这种映射处理函数表方式还有很多使用。比如之前博文中uboot传参给kernel,kernel对于不同tags的处理函数也是以该种方式来映射的。
kernel下driver私有结构体的回调处理函数也有这个思想哇!
- linux kernel的cmdline参数解析原理分析
- linux kernel的cmdline参数解析原理分析
- linux kernel的cmdline参数解析原理分析
- linux kernel的cmdline参数解析原理分析
- linux cmdline参数解析
- Linux Kernel command line 内核输入参数/proc/cmdline
- cmdline参数解析
- Linux Kernel Boot CMDLINE Processing
- module_param_call宏的作用解析 cmdline解析分析
- CMDLINE的解析
- c++:改造cmdline用于MSVC下的命令行参数解析
- kernel cmdline
- linux cmdline解析过程说明
- kernel cmdline的几种传递方式
- android 利用cmdline,将参数从preloader传递到kernel
- [Misc]利用cmdline,将参数从preloader传递到kernel
- android 利用cmdline,将参数从preloader传递到kernel
- Linux cmdline 解析(CMA 预留内存)
- 修改文件权限修改的思索
- 分布式系统的时间
- hdu 2102 A计划(BFS)(H)
- MS决策树分析算法
- 高通LCD lk代码跟踪分析
- linux kernel的cmdline参数解析原理分析
- json对象细节
- oc中Class是个啥
- 操作系统中颠簸(thrashing)解决办法
- Mybatis 源码解析 -事务模块
- 论文阅读:Network in Network
- c++中vector存在==
- iOS MAC终端 ~ sqlite3简单使用
- Android Canvas沿着Path绘制文字