内核启动组件式初始化(二)：流程与细节

内核启动后进入组件式初始化的过程如下图所示：

组件的初始化有以下三类：

1.来着bootloader传递的参数，使用do_early_param函数从__setup_start~__setup_end区间搜索完成。

2.中断和时钟的初始化

3.普通的初始化函数，这些主要是通过do_initcalls()函数完成的。

第一类初始化中，bootloader传递给kernel的参数格式为A=B，内核通过__setup和early_param标记来识别参数对应的函数。

相当于我们所说的绑定。

#define __setup(str,fn)           __setup_param(str,fn,fn,0)

#define early_param(str,fn)    __setup_param(str,fn,fn,1)

两者的差别就在最后一个参数,__setup_param内容如下：

#define __setup_param(str,unique_id,fn,early)

            static char __setup_str_##unique_id[]__initdata_aligned[1]=str;\

            static struct obs_kernel_param  __setup_##unique_id \ //实例名称

                                                              __used_section(.init.setup)\  //存放到.init.setup节

                                    __attribute__((aligned((sizeof(long)))) \  //对其要求

                             ={__setup_str_##unique_id, fn, early}           

可以看出查遍就在 obs_kernel_param数据结构的early成员是否置1。

再看一下obs_kernel_param的细节：

struct obs_kernel_param{

                    const char *str;

                    int (*setup_func)(char *);//slot用于绑定对应的函数

                    int early;//执行优先级的标记

}

可见被early_param修饰的函数要先于被__setup标记修饰的函数， 

以下是两种函数的调用过程：

对以early_param修饰的函数，是由do_early_param(...)

一般的函数若要在内核启动时背do_early_param调用，需使用early_param(...)"注册“

一个典型的例子是：

调试信息的的显示：

在linux_cmdline中如果加入了debug那么内核启动的信息将逐一打印出来，具体实现是这样的：

static int __init debug_kernel(char *str)

{

   console_loglevel = 10;

   return 0;

}

early_param("debug",debug_kernel);

于是，debug_kernel的入口地址在链接时被”挂“到了.init.setup节，供do_early_param调用。

对于__setup，使用__setup标记挂到.init.setup中的许多选项如今很少使用，除了__setup("init=",init_setup);