linux kernel的cmdline參數解析原理分析【轉】
Kernel啓動時會解析cmdline，而後根據這些參數如console root來進行配置運行。linux
Cmdline是由bootloader傳給kernel，如uboot，將須要傳給kernel的參數作成一個tags鏈表放在ram中，將首地址傳給kernel，kernel解析tags來獲取cmdline等信息。less
Uboot傳參給kernel以及kernel如何解析tags能夠看個人另外一篇博文，連接以下：ide
今天要分析的是kernel在獲取到cmdline以後如何對cmdline進行解析。函數
依據個人思路（時間順序，如何開始，如何結束），首先看kernel下2種參數的註冊。
第一種是kernel通用參數，如console=ttyS0,115200 root=/rdinit/init等。這裏以console爲例。
第二種是kernel下各個driver中須要的參數，在寫driver中，若是須要一些啓動時可變參數。能夠在driver最後加入module_param（）來註冊一個參數，kernel啓動時由cmdline指定該參數的值。ui
這裏以drivers/usb/gadget/serial.c中的use_acm參數爲例（這個例子有點偏。。由於最近在調試usb虛擬串口）this
一 kernel通用參數
對於這類通用參數，kernel留出單獨一塊data段，叫.ini.setup段。在arch/arm/kernel/vmlinux.lds中：spa
.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。debug
.init.setup段中存放的就是kernel通用參數和對應處理函數的映射表。在include/linux/init.h中指針
能夠看出宏定義__setup以及early_param定義了obs_kernel_param結構體，該結構體存放參數和對應處理函數，存放在.init.setup段中。調試
能夠想象，若是多個文件中調用該宏定義，在連接時就會根據連接順序將定義的obs_kernel_param放到.init.setup段中。
以console爲例，在/kernel/printk.c中，以下：
static int __init console_setup(char *str)
{
.......
}
__setup("console=", console_setup);
__setup宏定義展開，以下：
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中，以下：
__param : AT(ADDR(__param) - 0) { __start___param = .; *(__param) __stop___param = .; }
該段放在.rodata段中。
那該段中存放的是什麼樣的數據呢？
Driver中使用module_param來註冊參數，跟蹤這個宏定義，最終就會找到對__param段的操做函數以下：
/* This is the fundamental function for registering boot/module
parameters. */
#define __module_param_call(prefix, name, ops, arg, perm, level) \
/* Default value instead of permissions? */ \
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爲例，以下：
static bool use_acm = true; module_param(use_acm, bool, 0); Module_param展開到__module_param_call，以下： 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，以下：
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結構體，定義以下：
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中：
* You can override this manually, but generally this should match the module name. */ #ifdef MODULE #define MODULE_PARAM_PREFIX /* empty */ #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，以下：
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(),以下：
void __init parse_early_options(char *cmdline)
{
parse_args("early options", cmdline, NULL, 0, 0, 0, do_early_param);
}
/* Arch code calls this early on, or if not, just before other parsing. */
void __init parse_early_param(void)
{
static __initdata int done = 0;
static __initdata char tmp_cmdline[COMMAND_LINE_SIZE];
if (done)
return;
/* All fall through to do_early_param. */
strlcpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE);
parse_early_options(tmp_cmdline);
done = 1;
}
Parse_early_param拷貝cmdline到tmp_cmdline中一份，最終調用parse_args，以下：
/* Args looks like "foo=bar,bar2 baz=fuz wiz". */
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);
/* Chew leading spaces */
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;
}
}
/* All parsed OK. */
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。以下：
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;
/* Find parameter */
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;
/* No one handled NULL, so do it here. */
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。以下：
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);
}
}
/* We accept everything at this stage. */
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自定義參數。接着往下看。代碼以下：
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(); /* arch-specific boot-cpu hooks */
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，代碼以下：
/*
* Unknown boot options get handed to init, unless they look like
* unused parameters (modprobe will find them in /proc/cmdline).
*/
static int __init unknown_bootoption(char *param, char *val)
{
repair_env_string(param, val);
/* Handle obsolete-style parameters */
if (obsolete_checksetup(param))
return 0;
/* Unused module parameter. */
if (strchr(param, '.') && (!val || strchr(param, '.') < val))
return 0;
if (panic_later)
return 0;
if (val) {
/* Environment option */
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 {</span>
<span style="font-size:14px;"> /* Command line option */
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私有結構體的回調處理函數也有這個思想哇！
- 1. module_param_call宏的做用解析 cmdline解析分析
- 2. [Linux]如何讀取Kernel cmdline
- 3. linux kernel 進程切換原理分析
- 4. mybatis原理分析(五)---參數處理
- 5. 機器學習中核函數(Kernel)的理解與Kernel-SVM原理解析
- 6. HandlerAdapter解析參數過程之HandlerMethodArgumentResolver RequestMappingHandlerAdapter和RequestParam原理分析
- 7. Request 接收參數亂碼原理解析三：實例分析
- 8. Linux Kernel Netfilter Helper 分析
- 9. Linux Kernel Oops異常分析
- 10. 卡在Starting kernel...的原因分析
- 更多相關文章...
- • XML DOM 解析器 - XML DOM 教程
- • TCP報文格式解析 - TCP/IP教程
- • 互聯網組織的未來：剖析GitHub員工的任性之源
- • 常用的分佈式事務解決方案
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. module_param_call宏的做用解析 cmdline解析分析
- 2. [Linux]如何讀取Kernel cmdline
- 3. linux kernel 進程切換原理分析
- 4. mybatis原理分析(五)---參數處理
- 5. 機器學習中核函數(Kernel)的理解與Kernel-SVM原理解析
- 6. HandlerAdapter解析參數過程之HandlerMethodArgumentResolver RequestMappingHandlerAdapter和RequestParam原理分析
- 7. Request 接收參數亂碼原理解析三：實例分析
- 8. Linux Kernel Netfilter Helper 分析
- 9. Linux Kernel Oops異常分析
- 10. 卡在Starting kernel...的原因分析