linux kernel的cmdline參數解析原理分析【轉】

轉自：https://blog.csdn.net/skyflying2012/article/details/41142801

版權聲明：本文為博主kerneler辛苦原創，未經允許不得轉載。 https://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在獲取到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中：

 

1.  
   .init.data : {
2.  
   *(.init.data) *(.cpuinit.data) *(.meminit.data) *(.init.rodata) *(.cpuinit.rodata) *(.meminit.rodata) . = ALIGN( 32); __dtb_star
3.  
   . = ALIGN( 16); __setup_start = .; *(.init.setup) __setup_end = .;
4.  
   __initcall_start = .; *(.initcallearly.init) __initcall0_start = .; *(.initcall0.init) *(.initcall0s.init) __initcall1_start =
5.  
   __con_initcall_start = .; *(.con_initcall.init) __con_initcall_end = .;
6.  
   __security_initcall_start = .; *(.security_initcall.init) __security_initcall_end = .;
7.  
   . = ALIGN( 4); __initramfs_start = .; *(.init.ramfs) . = ALIGN(8); *(.init.ramfs.info)
8.  
   }

 

可以看到init.setup段起始__setup_start和結束__setup_end。

.init.setup段中存放的就是kernel通用參數和對應處理函數的映射表。在include/linux/init.h中

1.  
   struct obs_kernel_param {
2.  
   const char *str;
3.  
   int (*setup_func)(char *);
4.  
   int early;
5.  
   };
6.  
    
7.  
   /*
8.  
   * Only for really core code. See moduleparam.h for the normal way.
9.  
   *
10.  
    * Force the alignment so the compiler doesn't space elements of the
11.  
    * obs_kernel_param "array" too far apart in .init.setup.
12.  
    */
13.  
    #define __setup_param(str, unique_id, fn, early) \
14.  
    static const char __setup_str_##unique_id[] __initconst \
15.  
    __aligned(1) = str; \
16.  
    static struct obs_kernel_param __setup_##unique_id \
17.  
    __used __section(.init.setup) \
18.  
    __attribute__((aligned((sizeof(long))))) \
19.  
    = { __setup_str_##unique_id, fn, early }
20.  
     
21.  
    #define __setup(str, fn) \
22.  
    __setup_param(str, fn, fn, 0)
23.  
    /* NOTE: fn is as per module_param, not __setup! Emits warning if fn
24.  
    * returns non-zero. */
25.  
    #define early_param(str, fn) \
26.  
    __setup_param(str, fn, fn, 1)

可以看出宏定義__setup以及early_param定義了obs_kernel_param結構體，該結構體存放參數和對應處理函數，存放在.init.setup段中。

可以想象，如果多個文件中調用該宏定義，在鏈接時就會根據鏈接順序將定義的obs_kernel_param放到.init.setup段中。

以console為例，在/kernel/printk.c中，如下：

1.  
   static int __init console_setup(char *str)
2.  
   {
3.  
   .......
4.  
   }
5.  
   __setup( "console=", console_setup);

__setup宏定義展開，如下：

1.  
   Static struct obs_kernel_param __setup_console_setup
2.  
   __ used_section(.init.setup) __attribute__((aligned((sizeof(long)))) = {
3.  
   .name = “console=”,
4.  
   .setup_func = console_setup,
5.  
   .early = 0
6.  
   }

__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中，如下：

 

__param : AT(ADDR(__param) - 0) { __start___param = .; *(__param) __stop___param = .; }

 

該段放在.rodata段中。

那該段中存放的是什么樣的數據呢？

Driver中使用module_param來注冊參數，跟蹤這個宏定義，最終就會找到對__param段的操作函數如下：

1.  
   /* This is the fundamental function for registering boot/module
2.  
   parameters. */
3.  
   #define __module_param_call(prefix, name, ops, arg, perm, level) \
4.  
   /* Default value instead of permissions? */ \
5.  
   static int __param_perm_check_##name __attribute__((unused)) = \
6.  
   BUILD_BUG_ON_ZERO((perm) < 0 || (perm) > 0777 || ((perm) & 2)) \
7.  
   + BUILD_BUG_ON_ZERO( sizeof(""prefix) > MAX_PARAM_PREFIX_LEN); \
8.  
   static const char __param_str_##name[] = prefix #name; \
9.  
   static struct kernel_param __moduleparam_const __param_##name \
10.  
    __used \
11.  
    __attribute__ ((unused,__section__ ("__param"),aligned(sizeof(void *)))) \
12.  
    = { __param_str_##name, ops, perm, level, { arg } }
13.  
    ........
14.  
    #define module_param(name, type, perm) \
15.  
    module_param_named(name, name, type, perm)
16.  
     
17.  
    #define module_param_named(name, value, type, perm) \
18.  
    param_check_##type(name, &(value)); \
19.  
    module_param_cb(name, ¶m_ops_##type, &value, perm); \
20.  
    __MODULE_PARM_TYPE(name, #type)
21.  
     
22.  
    #define module_param_cb(name, ops, arg, perm) \
23.  
    __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1）

以driver/usb/gadget/serial.c中的use_acm為例，如下：

1.  
   static bool use_acm = true;
2.  
   module_param(use_acm, bool, 0);

Module_param展開到__module_param_call，如下：

1.  
   Static bool use_acm = true;
2.  
   Param_check_bool(use_acm, &(use_acm));
3.  
   __module_param_call(MODULE_PARAM_PREFIX, use_acm, ¶m_ops_bool, &(use_acm, 0, -1));
4.  
   __MODULE_PARAM_TYPE(use_acm, bool);

將__module_param_call展開，可以看到是定義了結構體kernel_param，如下：

1.  
   Static struct kernel_param __moduleparam_const __param_use_acm
2.  
   __ used __attribute__ ((unused,__section__ ("__param"),aligned(sizeof(void *)))) = {
3.  
   .name = MODULE_PARAM_PREFIX#use_acm,
4.  
   .ops = ¶m_ops_bool,
5.  
   .Perm= 0,
6.  
   .level = -1.
7.  
   .arg = &use_acm
8.  
   }

很清楚，跟.init.setup段一樣，kernel鏈接時會根據鏈接順序將定義的kernel_param放在__param段中。

Kernel_param有3個成員變量需要注意：

（1）

ops=param_ops_bool，是kernel_param_ops結構體，定義如下：

 

1.  
   struct kernel_param_ops param_ops_bool = {
2.  
   . set = param_set_bool,
3.  
   .get = param_get_bool,
4.  
   };

 

這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中：

 

1.  
   * You can override this manually, but generally this should match the
2.  
   module name. */
3.  
   #ifdef MODULE
4.  
   #define MODULE_PARAM_PREFIX /* empty */
5.  
   #else
6.  
   #define MODULE_PARAM_PREFIX KBUILD_MODNAME "."
7.  
   #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，如下：

 

1.  
   g_serial-y := serial.o
2.  
   ....
3.  
   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(),如下：

1.  
   void __init parse_early_options(char *cmdline)
2.  
   {
3.  
   parse_args( "early options", cmdline, NULL, 0, 0, 0, do_early_param);
4.  
   }
5.  
    
6.  
   /* Arch code calls this early on, or if not, just before other parsing. */
7.  
   void __init parse_early_param(void)
8.  
   {
9.  
   static __initdata int done = 0;
10.  
    static __initdata char tmp_cmdline[COMMAND_LINE_SIZE];
11.  
     
12.  
    if (done)
13.  
    return;
14.  
     
15.  
    /* All fall through to do_early_param. */
16.  
    strlcpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE);
17.  
    parse_early_options(tmp_cmdline);
18.  
    done = 1;
19.  
    }
20.  
    Parse_early_param拷貝cmdline到tmp_cmdline中一份，最終調用parse_args，如下：
21.  
     
22.  
    /* Args looks like "foo=bar,bar2 baz=fuz wiz". */
23.  
    int parse_args(const char *name,
24.  
    char *args,
25.  
    const struct kernel_param *params,
26.  
    unsigned num,
27.  
    s16 min_level,
28.  
    s16 max_level,
29.  
    int (*unknown)(char *param, char *val))
30.  
    {
31.  
    char *param, *val;
32.  
     
33.  
    pr_debug( "Parsing ARGS: %s\n", args);
34.  
     
35.  
    /* Chew leading spaces */
36.  
    args = skip_spaces(args);
37.  
     
38.  
    while (*args) {
39.  
    int ret;
40.  
    int irq_was_disabled;
41.  
     
42.  
    args = next_arg(args, ¶m, &val);
43.  
    irq_was_disabled = irqs_disabled();
44.  
    ret = parse_one(param, val, params, num,
45.  
    min_level, max_level, unknown);
46.  
    if (irq_was_disabled && !irqs_disabled()) {
47.  
    printk(KERN_WARNING "parse_args(): option '%s' enabled "
48.  
    "irq's!\n", param);
49.  
    }
50.  
    switch (ret) {
51.  
    case -ENOENT:
52.  
    printk(KERN_ERR "%s: Unknown parameter `%s'\n",
53.  
    name, param);
54.  
    return ret;
55.  
    case -ENOSPC:
56.  
    printk(KERN_ERR
57.  
    "%s: `%s' too large for parameter `%s'\n",
58.  
    name, val ?: "", param);
59.  
    return ret;
60.  
    case 0:
61.  
    break;
62.  
    default:
63.  
    printk(KERN_ERR
64.  
    "%s: `%s' invalid for parameter `%s'\n",
65.  
    name, val ?: "", param);
66.  
    return ret;
67.  
    }
68.  
    }
69.  
     
70.  
    /* All parsed OK. */
71.  
    return 0;
72.  
    }
73.  
    .....
74.  
    void __init parse_early_options(char *cmdline)
75.  
    {
76.  
    parse_args( "early options", cmdline, NULL, 0, 0, 0, do_early_param);
77.  
    }

Parse_args遍歷cmdline，按照空格切割獲取參數，對所有參數調用next_arg獲取參數名param和參數值val。如console=ttyS0,115200，則param=console，val=ttyS0,115200。調用parse_one。如下：

1.  
   static int parse_one(char *param,
2.  
   char *val,
3.  
   const struct kernel_param *params,
4.  
   unsigned num_params,
5.  
   s16 min_level,
6.  
   s16 max_level,
7.  
   int (*handle_unknown)(char *param, char *val))
8.  
   {
9.  
   unsigned int i;
10.  
    int err;
11.  
     
12.  
    /* Find parameter */
13.  
    for (i = 0; i < num_params; i++) {
14.  
    if (parameq(param, params[i].name)) {
15.  
    if (params[i].level < min_level
16.  
    || params[i].level > max_level)
17.  
    return 0;
18.  
    /* No one handled NULL, so do it here. */
19.  
    if (!val && params[i].ops->set != param_set_bool
20.  
    && params[i].ops-> set != param_set_bint)
21.  
    return -EINVAL;
22.  
    pr_debug( "They are equal! Calling %p\n",
23.  
    params[i].ops-> set);
24.  
    mutex_lock(¶m_lock);
25.  
    err = params[i].ops-> set(val, ¶ms[i]);
26.  
    mutex_unlock(¶m_lock);
27.  
    return err;
28.  
    }
29.  
    }
30.  
     
31.  
    if (handle_unknown) {
32.  
    pr_debug( "Unknown argument: calling %p\n", handle_unknown);
33.  
    return handle_unknown(param, val);
34.  
    }
35.  
     
36.  
    pr_debug( "Unknown argument `%s'\n", param);
37.  
    return -ENOENT;
38.  
    }

由於從parse_early_options傳入的num_params=0，所以parse_one是直接走的最后handle_unknown函數。該函數是由parse-early_options傳入的do_early_param。如下：

1.  
   static int __init do_early_param(char *param, char *val)
2.  
   {
3.  
   const struct obs_kernel_param *p;
4.  
    
5.  
   for (p = __setup_start; p < __setup_end; p++) {
6.  
   if ((p->early && parameq(param, p->str)) ||
7.  
   ( strcmp(param, "console") == 0 &&
8.  
   strcmp(p->str, "earlycon") == 0)
9.  
   ) {
10.  
    if (p->setup_func(val) != 0)
11.  
    printk(KERN_WARNING
12.  
    "Malformed early option '%s'\n", param);
13.  
    }
14.  
    }
15.  
    /* We accept everything at this stage. */
16.  
    return 0;
17.  
    }

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自定義參數。接着往下看。代碼如下：

 

1.  
   setup_arch(&command_line);
2.  
   mm_init_owner(&init_mm, &init_task);
3.  
   mm_init_cpumask(&init_mm);
4.  
   setup_command_line(command_line);
5.  
   setup_nr_cpu_ids();
6.  
   setup_per_cpu_areas();
7.  
   smp_prepare_boot_cpu(); /* arch-specific boot-cpu hooks */
8.  
    
9.  
   build_all_zonelists( NULL);
10.  
    page_alloc_init();
11.  
     
12.  
    printk(KERN_NOTICE "Kernel command line: %s\n", boot_command_line);
13.  
    parse_early_param();
14.  
    parse_args( "Booting kernel", static_command_line, __start___param,
15.  
    __stop___param - __start___param,
16.  
    -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，代碼如下： 

 

1.  
   /*
2.  
   * Unknown boot options get handed to init, unless they look like
3.  
   * unused parameters (modprobe will find them in /proc/cmdline).
4.  
   */
5.  
   static int __init unknown_bootoption(char *param, char *val)
6.  
   {
7.  
   repair_env_string(param, val);
8.  
    
9.  
   /* Handle obsolete-style parameters */
10.  
    if (obsolete_checksetup(param))
11.  
    return 0;
12.  
     
13.  
    /* Unused module parameter. */
14.  
    if (strchr(param, '.') && (!val || strchr(param, '.') < val))
15.  
    return 0;
16.  
     
17.  
    if (panic_later)
18.  
    return 0;
19.  
     
20.  
    if (val) {
21.  
    /* Environment option */
22.  
    unsigned int i;
23.  
    for (i = 0; envp_init[i]; i++) {
24.  
    if (i == MAX_INIT_ENVS) {
25.  
    panic_later = "Too many boot env vars at `%s'";
26.  
    panic_param = param;
27.  
    }
28.  
    if (!strncmp(param, envp_init[i], val - param))
29.  
    break;
30.  
    }
31.  
    envp_init[i] = param;
32.  
    } else {</span>

1.  
   <span style= "font-size:14px;"> /* Command line option */
2.  
   unsigned int i;
3.  
   for (i = 0; argv_init[i]; i++) {
4.  
   if (i == MAX_INIT_ARGS) {
5.  
   panic_later = "Too many boot init vars at `%s'";
6.  
   panic_param = param;
7.  
   }
8.  
   }
9.  
   argv_init[i] = param;
10.  
    }
11.  
    return 0;
12.  
    }

 

首先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私有結構體的回調處理函數也有這個思想哇！