利用工作之便，今天研究了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在获取到cmdline之后如何对cmdline进行解析。
依据我的思路(时间顺序，如何开始，如何结束)，首先看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中：
[cpp]
view plain copy 在CODE上查看代码片派生到我的代码片
.init.data
: {
*(.init.data) *(.cpuinit.data) *(.meminit.data) *(.init.rodata)
*(.cpuinit.rodata) *(.meminit.rodata) . = ALIGN(32); __dtb_star
.
= ALIGN(16); __setup_start = .; *(.init.setup) __setup_end = .;
__initcall_start = .; *(.initcallearly.init) __initcall0_start = .;
*(.initcall0.init) *(.initcall0s.init) __initcall1_start =
__con_initcall_start = .; *(.con_initcall.init) __con_initcall_end
= .;
__security_initcall_start = .; *(.security_initcall.init)
__security_initcall_end = .;
. = ALIGN(4); __initramfs_start = .; *(.init.ramfs) . = ALIGN(8);
*(.init.ramfs.info)
}
可以看到init.setup段起始__setup_start和结束__setup_end。
.init.setup段中存放的就是kernel通用参数和对应处理函数的映射表。在include/linux/init.h中
[cpp]
view plain copy 在CODE上查看代码片派生到我的代码片
struct
obs_kernel_param {
const char *str;
int (*setup_func)(char *);
int early;
};
#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)
#define
early_param(str, fn) \
__setup_param(str, fn, fn, 1)
可以看出宏定义__setup以及early_param定义了obs_kernel_param结构体，该结构体存放参数和对应处理函数，存放在.init.setup段中。
可以想象，如果多个文件中调用该宏定义，在链接时就会根据链接顺序将定义的obs_kernel_param放到.init.setup段中。
以console为例，在/kernel/printk.c中，如下：
[cpp]
view plain copy 在CODE上查看代码片派生到我的代码片
static
int __init console_setup(char *str)
{
.......
}
__setup("console=",
console_setup);
__setup宏定义展开，如下：
[cpp]
view plain copy 在CODE上查看代码片派生到我的代码片
Static
struct obs_kernel_param __setup_console_setup
__used_section(.init.setup)
__attribute__((aligned((sizeof(long)))) = {
.name =
“console=”,
.setup_func
= console_setup,
.early =
0
}
__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中，如下：
[cpp]
view plain copy 在CODE上查看代码片派生到我的代码片
__param
: AT(ADDR(__param) - 0) { __start___param = .; *(__param)
__stop___param = .; }
该段放在.rodata段中。
那该段中存放的是什么样的数据呢？
Driver中使用module_param来注册参数，跟踪这个宏定义，最终就会找到对__param段的操作函数如下：
[cpp]
view plain copy 在CODE上查看代码片派生到我的代码片
#define
__module_param_call(prefix, name, ops, arg, perm, level)
\
\
static int __param_perm_check_##name
__attribute__((unused)) = \
BUILD_BUG_ON_ZERO((perm) < 0 || (perm) >
0777 || ((perm) & 2)) \
+ BUILD_BUG_ON_ZERO(sizeof(""prefix) >
MAX_PARAM_PREFIX_LEN); \
static const char __param_str_##name[] = prefix
#name; \
static struct kernel_param __moduleparam_const
__param_##name \
__used \
__attribute__ ((unused,__section__
("__param"),aligned(sizeof(void *)))) \
= { __param_str_##name, ops, perm, level, { arg
} }
........
#define
module_param(name, type, perm) \
module_param_named(name, name, type, perm)
#define
module_param_named(name, value, type, perm) \
param_check_##type(name, &(value));
\
module_param_cb(name, ¶m_ops_##type, &value,
perm); \
__MODULE_PARM_TYPE(name, #type)
#define
module_param_cb(name, ops, arg, perm) \
__module_param_call(MODULE_PARAM_PREFIX, name,
ops, arg, perm, -1)
以driver/usb/gadget/serial.c中的use_acm为例，如下：
[cpp]
view plain copy 在CODE上查看代码片派生到我的代码片
static
bool use_acm = true;
module_param(use_acm,
bool, 0);
Module_param展开到__module_param_call，如下：
[cpp]
view plain copy 在CODE上查看代码片派生到我的代码片
Static
bool use_acm = true;
Param_check_bool(use_acm,
&(use_acm));
__module_param_call(MODULE_PARAM_PREFIX,
use_acm, ¶m_ops_bool, &(use_acm, 0, -1));
__MODULE_PARAM_TYPE(use_acm,
bool);
将__module_param_call展开，可以看到是定义了结构体kernel_param，如下：
[cpp]
view plain copy 在CODE上查看代码片派生到我的代码片
Static
struct kernel_param __moduleparam_const __param_use_acm
__used
__attribute__ ((unused,__section__
("__param"),aligned(sizeof(void *)))) = {
.name =
MODULE_PARAM_PREFIX#use_acm,
.ops =
¶m_ops_bool,
.Perm=0,
.level =
-1.
.arg =
&use_acm
}
很清楚，跟.init.setup段一样，kernel链接时会根据链接顺序将定义的kernel_param放在__param段中。
Kernel_param有3个成员变量需要注意：
(1)
ops=param_ops_bool，是kernel_param_ops结构体，定义如下：
[cpp]
view plain copy 在CODE上查看代码片派生到我的代码片
struct
kernel_param_ops param_ops_bool = {
.set = param_set_bool,
.get = param_get_bool,
};
这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中：
[cpp]
view plain copy 在CODE上查看代码片派生到我的代码片
* You
can override this manually, but generally this should match the
module name. */
#ifdef
MODULE
#define
MODULE_PARAM_PREFIX
#else
#define
MODULE_PARAM_PREFIX KBUILD_MODNAME "."
#endif
如果我们是模块编译(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，如下：
[cpp]
view plain copy 在CODE上查看代码片派生到我的代码片
g_serial-y
:= serial.o
....
obj-$(CONFIG_USB_G_SERIAL)
+= g_serial.o
最终是生成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(),如下：
[cpp]
view plain copy 在CODE上查看代码片派生到我的代码片
void
__init parse_early_options(char *cmdline)
{
parse_args("early options", cmdline, NULL, 0, 0,
0, do_early_param);
}
void
__init parse_early_param(void)
{
static __initdata int done = 0;
static __initdata char
tmp_cmdline[COMMAND_LINE_SIZE];
if (done)
return;
strlcpy(tmp_cmdline, boot_command_line,
COMMAND_LINE_SIZE);
parse_early_options(tmp_cmdline);
done = 1;
}
Parse_early_param拷贝cmdline到tmp_cmdline中一份，最终调用parse_args，如下：
int
parse_args(const char *name,
char *args,
const struct kernel_param
*params,
unsigned num,
s16 min_level,
s16 max_level,
int (*unknown)(char *param,
char *val))
{
char *param, *val;
pr_debug("Parsing ARGS: %s\n", args);
args = skip_spaces(args);
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,
min_level, max_level, unknown);
if
(irq_was_disabled && !irqs_disabled()) {
printk(KERN_WARNING
"parse_args(): option '%s' enabled "
"irq's!\n", param);
}
switch
(ret) {
case
-ENOENT:
printk(KERN_ERR "%s: Unknown
parameter `%s'\n",
name,
param);
return ret;
case
-ENOSPC:
printk(KERN_ERR
"%s: `%s'
too large for parameter `%s'\n",
name, val
?: "", param);
return ret;
case 0:
break;
default:
printk(KERN_ERR
"%s: `%s'
invalid for parameter `%s'\n",
name, val
?: "", param);
return ret;
}
}
return 0;
}
.....
void
__init parse_early_options(char *cmdline)
{
parse_args("early options", cmdline, NULL, 0, 0,
0, do_early_param);
}
Parse_args遍历cmdline，按照空格切割获取参数，对所有参数调用next_arg获取参数名param和参数值val。如console=ttyS0,115200，则param=console，val=ttyS0,115200。调用parse_one。如下：
[cpp]
view plain copy 在CODE上查看代码片派生到我的代码片
static
int parse_one(char *param,
char *val,
const
struct kernel_param *params,
unsigned
num_params,
s16
min_level,
s16
max_level,
int
(*handle_unknown)(char *param, char *val))
{
unsigned int i;
int err;
for (i = 0; i < num_params; i++) {
if
(parameq(param, params[i].name)) {
if (params[i].level <
min_level
|| params[i].level > max_level)
return 0;
if (!val &&
params[i].ops->set != param_set_bool
&& params[i].ops->set !=
param_set_bint)
return -EINVAL;
pr_debug("They are equal!
Calling %p\n",
params[i].ops->set);
mutex_lock(¶m_lock);
err =
params[i].ops->set(val, ¶ms[i]);
mutex_unlock(¶m_lock);
return err;
}
}
if (handle_unknown) {
pr_debug("Unknown argument: calling %p\n", handle_unknown);
return
handle_unknown(param, val);
}
pr_debug("Unknown argument `%s'\n", param);
return -ENOENT;
}
由于从parse_early_options传入的num_params=0，所以parse_one是直接走的最后handle_unknown函数。该函数是由parse-early_options传入的do_early_param。如下：
[cpp]
view plain copy 在CODE上查看代码片派生到我的代码片
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 && parameq(param, p->str)) ||
(strcmp(param, "console") ==
0 &&
strcmp(p->str, "earlycon") == 0)
) {
if (p->setup_func(val) !=
0)
printk(KERN_WARNING
"Malformed early option
'%s'\n", param);
}
}
return 0;
}
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自定义参数。接着往下看。代码如下：
[cpp]
view plain copy 在CODE上查看代码片派生到我的代码片
setup_arch(&command_line);
mm_init_owner(&init_mm,
&init_task);
mm_init_cpumask(&init_mm);
setup_command_line(command_line);
setup_nr_cpu_ids();
setup_per_cpu_areas();
smp_prepare_boot_cpu();
build_all_zonelists(NULL);
page_alloc_init();
printk(KERN_NOTICE
"Kernel command line: %s\n", boot_command_line);
parse_early_param();
parse_args("Booting
kernel", static_command_line, __start___param,
__stop___param - __start___param,
-1, -1,
&unknown_bootoption);
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，代码如下：
[cpp]
view plain copy 在CODE上查看代码片派生到我的代码片
static
int __init unknown_bootoption(char *param, char *val)
{
repair_env_string(param, val);
if (obsolete_checksetup(param))
return 0;
if (strchr(param, '.') && (!val ||
strchr(param, '.') < val))
return 0;
if (panic_later)
return 0;
if (val) {
unsigned
int i;
for (i =
0; envp_init[i]; i++) {
if (i == MAX_INIT_ENVS) {
panic_later = "Too many boot env vars at `%s'";
panic_param = param;
}
if (!strncmp(param,
envp_init[i], val - param))
break;
}
envp_init[i] = param;
} else {
[cpp]
view plain copy 在CODE上查看代码片派生到我的代码片
unsigned
int i;
for (i =
0; argv_init[i]; i++) {
if (i == MAX_INIT_ARGS) {
panic_later = "Too many boot init vars at `%s'";
panic_param = param;
}
}
argv_init[i] = param;
}
return 0;
}
首先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私有结构体的回调处理函数也有这个思想哇！
1552
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
