Android init.rc文件解析过程详解(一)
2013-12-21 20:22
549 查看
init.c与init.rc在源码中的位置分别位于如下:
一、init.rc文件结构介绍
init.rc文件基本组成单位是section,section分为三种类型,分别由三个关键字(所谓关键字即每一行的第一列)来区分,这三个关键字是 on、service、import。
1、on类型的section表示一系列命令的组合,例如:
这样一个section包含了三个export命令,命令的执行是以section为单位的,所以这三个命令是一起执行的,不会单独执行,那什么时候执行呢? 这是由init.c的main()所决定的,main()里在某个时间会调用
这就把 ” on init “开始的这样一个section里的所有命令加入到一个执行队列,在未来的某个时候会顺序执行队列里的命令,所以调用
的先后决定了命令执行的先后。
2、service类型的section表示一个可执行程序,例如:
surfaceflinger作为一个名字标识了这个service,
表示可执行文件的位置, class、user、group、onrestart这些关键字所对应的行都被称为options,options是用来描述的service一些特点,不同的service有着不同的options。
service类型的section标识了一个service(或者说可执行程序),那这个service什么时候被执行呢?是在
class_start 这个命令被执行的时候,这个命令行总是存在于某个on类型的section中,“class_start core”这样一条命令被执行,就会启动类型为core的所有service。如:
所以可以看出android的启动过程主要就是on类型的section被执行的过程。
3、import类型的section表示引入另外一个.rc文件,例如:
相当包含另外一些section,在解析完init.rc文件后继续会调用init_parse_config_file来解析引入的.rc文件。
二、init.rc文件解析过程
我们已经知道init.rc的结构,应该可以想到解析init.rc的过程就是识别一个个section的过程,将各个section的信息保存下来,然后在init.c的main()中去执行一个个命令。 android采用双向链表(关于双向链表详解见本文第三部分)来存储section的信息,解析完成之后,会得到三个双向链表action_list、service_list、import_list来分别存储三种section的信息上。
1、init.c中调用
, 代码如下:
2、parse_config()代码如下:
next_token() 解析完init.rc中一行之后,会返回 T_NEWLINE ,这时调用 lookup_keyword 函数来找出这一行的关键字,lookup_keyword 返回的是一个整型值,对应 keyword_info[] 数组的下标, keyword_info[] 存放的是 keyword_info 结构体类型的数据,
因此keyword_info[]中存放的是所有关键字的信息,每一项对应一个关键字。
根据每一项的flags就可以判断出关键字的类型,如新的一行是SECTION,就调用parse_new_section()来解析这一行,如新的一行不是一个SECTION的第一行,那么调用state.parseline()来解析(state.parseline所对应的函数会根据section类型的不同而不同),在parse_new_section()中进行动态设置。
三种类型的section: service、on、import,service对应的state.parseline为parse_line_service,
on对应的state.parseline为parse_line_action,import section中只有一行所以没有对应的state.parseline。
最后我们分析一下init.c中的main()函数
view
source
print?
1 | init.c : /system/core/init |
2 | init.rc : /system/core/rootdir |
init.rc文件基本组成单位是section,section分为三种类型,分别由三个关键字(所谓关键字即每一行的第一列)来区分,这三个关键字是 on、service、import。
1、on类型的section表示一系列命令的组合,例如:
1 | on init |
2 | export PATH /sbin:/system/sbin:/system/bin |
3 | export ANDROID_ROOT /system |
4 | export ANDROID_DATA /data |
1 | action_for_each_trigger( "init" , action_add_queue_tail); |
1 | action_for_each_trigger() |
2、service类型的section表示一个可执行程序,例如:
1 | service surfaceflinger /system/bin/surfaceflinger |
2 | class main |
3 | user system |
4 | group graphics drmrpc |
5 | onrestart restart zygote |
1 | /system/bin/surfaceflinger |
service类型的section标识了一个service(或者说可执行程序),那这个service什么时候被执行呢?是在
class_start 这个命令被执行的时候,这个命令行总是存在于某个on类型的section中,“class_start core”这样一条命令被执行,就会启动类型为core的所有service。如:
1 | on boot |
2 |
3 | 、、、、、、 |
4 |
5 | class_start core |
6 | class_start main |
3、import类型的section表示引入另外一个.rc文件,例如:
1 | import init. test .rc |
二、init.rc文件解析过程
我们已经知道init.rc的结构,应该可以想到解析init.rc的过程就是识别一个个section的过程,将各个section的信息保存下来,然后在init.c的main()中去执行一个个命令。 android采用双向链表(关于双向链表详解见本文第三部分)来存储section的信息,解析完成之后,会得到三个双向链表action_list、service_list、import_list来分别存储三种section的信息上。
1、init.c中调用
1 | init_parse_config_file(“/init.rc”) |
01 | int init_parse_config_file( const char *fn) |
02 | { |
03 | char *data; |
04 | data //read_file()调用open\lseek\read 将init.rc读出来 |
05 | if (!data) return -1; |
06 |
07 | parse_config(fn, //调用parse_config开始解析 |
08 | DUMP(); |
09 | return 0; |
10 | } |
01 | static void parse_config( const char *fn, char *s) |
02 | { |
03 | struct parse_state state; |
04 | struct listnode import_list; |
05 | struct listnode *node; |
06 | char *args[INIT_PARSER_MAXARGS]; |
07 | int nargs; |
08 |
09 | nargs = 0; |
10 | state.filename = fn; |
11 | state.line = 0; |
12 | state.ptr = s; |
13 | state.nexttoken = 0; |
14 | state.parse_line = parse_line_no_op; |
15 |
16 | list_init(&import_list); |
17 | state.priv = &import_list; |
18 |
19 | for (;;) { |
20 | switch (next_token(&state)) { //next_token()根据从state.ptr开始遍历 |
21 | case T_EOF: //遍历到文件结尾,然后goto解析import的.rc文件 |
22 | state.parse_line(&state, 0,0); |
23 | goto parser_done; |
24 | case T_NEWLINE: //到了一行结束 |
25 | state.line++; |
26 | if (nargs) { |
27 | int kw //找到这一行的关键字 |
28 | if (kw_is(kw, //如果这是一个section的第一行 |
29 | state.parse_line(&state, 0,0); |
30 | parse_new_section(&state, kw,nargs,args); |
31 | } else { //如果这不是一个section的第一行 |
32 | state.parse_line(&state, nargs,args); |
33 | } |
34 | nargs = 0; |
35 | } |
36 | break ; |
37 | case T_TEXT: //遇到普通字符 |
38 | if (nargs < INIT_PARSER_MAXARGS) { |
39 | args[nargs++] = state.text; |
40 | } |
41 | break ; |
42 | } |
43 | } |
44 | parser_done: |
45 | list_for_each(node, &import_list) { |
46 | struct import *import = node_to_item(node, struct import, list); |
47 | int ret; |
48 |
49 | INFO( "importing '%s'" , import->filename); |
50 | ret = init_parse_config_file(import->filename); |
51 | if (ret) |
52 | ERROR( "could not import file '%s' from '%s'\n" , |
53 | import->filename, fn); |
54 | } |
55 | } |
1 | struct { |
2 | const char *name; //关键字的名称 |
3 | int (*func)( int nargs, char **args); //对应的处理函数 |
4 | unsigned char nargs; //参数个数 |
5 | unsigned char flags; //flag标识关键字的类型,包括COMMAND、OPTION、SECTION |
6 | } keyword_info |
根据每一项的flags就可以判断出关键字的类型,如新的一行是SECTION,就调用parse_new_section()来解析这一行,如新的一行不是一个SECTION的第一行,那么调用state.parseline()来解析(state.parseline所对应的函数会根据section类型的不同而不同),在parse_new_section()中进行动态设置。
三种类型的section: service、on、import,service对应的state.parseline为parse_line_service,
on对应的state.parseline为parse_line_action,import section中只有一行所以没有对应的state.parseline。
最后我们分析一下init.c中的main()函数
view
source
print?
01 | int main( int argc, char **argv) |
02 | { |
03 | ... ... |
04 | /* Get the basic filesystem setup we need put |
05 | * together in the initramdisk on / and then we'll |
06 | * let the rc file figure out the rest. |
07 | */ |
08 | // 创建一些linux根文件系统中的目录 |
09 | mkdir( "/dev" , 0755); |
10 | mkdir( "/proc" , 0755); |
11 | mkdir( "/sys" , 0755); |
12 |
13 | mount( "tmpfs" , "/dev" , "tmpfs" , "mode=0755" ); |
14 | mkdir( "/dev/pts" , 0755); |
15 | mkdir( "/dev/socket" , 0755); |
16 | mount( "devpts" , "/dev/pts" , "devpts" , |
17 | mount( "proc" , "/proc" , "proc" , |
18 | mount( "sysfs" , "/sys" , "sysfs" , |
19 |
20 | //open_devnull_stdio(); |
21 | klog_init(); |
22 |
23 | ... ... |
24 |
25 | printf ( "Parsing init.rc ...\n" ); |
26 | // 读取并且解析init.rc文件 |
27 | init_parse_config_file( "/init.rc" ); |
28 |
29 | ... ... |
30 |
31 | // 取得硬件名 |
32 | get_hardware_name(); |
33 | snprintf(tmp, sizeof (tmp), "/init.%s.rc" , hardware); |
34 |
35 | // 读取并且解析硬件相关的init脚本文件 |
36 | parse_config_file(tmp); |
37 |
38 | ... ... |
39 |
40 | # 触发在init脚本文件中名字为early-init的action,并且执行其commands,其实是: on early-init |
41 | action_for_each_trigger( "early-init" , action_add_queue_tail); |
42 |
43 | queue_builtin_action(wait_for_coldboot_done_action, "wait_for_coldboot_done" ); |
44 | queue_builtin_action(property_init_action, "property_init" ); |
45 | queue_builtin_action(keychord_init_action, "keychord_init" ); |
46 | # 控制台相关初始化,在这里会加载启动动画,如果动画打开失败,则在屏幕上打印: A N D R O I D字样。 |
47 | queue_builtin_action(console_init_action, "console_init" ); |
48 | queue_builtin_action(set_init_properties_action, "set_init_properties" ); |
49 |
50 | /* execute all the boot actions to get us started */ |
51 | # 触发在init脚本文件中名字为init的action,并且执行其commands,其实是:on init |
52 | action_for_each_trigger( "init" , action_add_queue_tail); |
53 |
54 | /* skip mounting filesystems in charger mode */ |
55 | if ( strcmp (bootmode, "charger" ) != 0) { |
56 | action_for_each_trigger( "early-fs" , action_add_queue_tail); |
57 | action_for_each_trigger( "fs" , action_add_queue_tail); |
58 | action_for_each_trigger( "post-fs" , action_add_queue_tail); |
59 | action_for_each_trigger( "post-fs-data" , action_add_queue_tail); |
60 | } |
61 |
62 | // 启动系统属性服务: system property service |
63 | queue_builtin_action(property_service_init_action, "property_service_init" ); |
64 | queue_builtin_action(signal_init_action, "signal_init" ); |
65 | queue_builtin_action(check_startup_action, "check_startup" ); |
66 |
67 | queue_builtin_action(queue_early_property_triggers_action, "queue_early_propety_triggers" ); |
68 |
69 | if (! strcmp (bootmode, "charger" )) { |
70 | action_for_each_trigger( "charger" , action_add_queue_tail); |
71 | } else { |
72 | // 触发在init脚本文件中名字为early-boot和boot的action,并且执行其commands,其实是:on early-boot和on boot |
73 | action_for_each_trigger( "early-boot" , action_add_queue_tail); |
74 | action_for_each_trigger( "boot" , action_add_queue_tail); |
75 | } |
76 |
77 | /* run all property triggers based on current state of the properties */ |
78 | // 启动所有属性变化触发命令,其实是: on property:ro.xx.xx=xx |
79 | queue_builtin_action(queue_property_triggers_action, "queue_propety_triggers" ); |
80 |
81 | // 进入死循环 |
82 | for (;;) { |
83 | int nr, |
84 |
85 | execute_one_command(); |
86 | // 启动所有init脚本中声明的service |
87 | restart_processes(); |
88 | ... ... |
89 | // 多路监听设备管理,子进程运行状态,属性服务 |
90 | nr |
91 | ... ... |
92 | } |
93 |
94 | return 0; |
95 | } |
相关文章推荐
- Android init.rc文件解析过程详解(二)
- Android init.rc文件解析过程详解(三)
- Android init.rc文件解析过程详解(三)
- Android init.rc文件解析过程详解(一)
- Android init.rc文件解析过程详解(一)
- Android init.rc文件解析过程详解(一)
- Android init.rc文件解析过程详解(一)
- [原创]Android init.rc文件解析过程详解(二)
- Android init.rc文件解析过程分析
- Android中init.rc文件的解析&&Android init进程启动过程分析
- init.rc文件解析过程详解
- Android的init过程详解(二)初始化语言(init.rc)解析
- android启动过程详解(一)——解析init.rc
- Android中measure过程、WRAP_CONTENT详解以及xml布局文件解析流程浅析(下)
- Android读取init.rc配置文件parse_config函数解析
- android5.1 init对rc文件解析执行顺序
- Android中measure过程、WRAP_CONTENT详解以及 xml布局文件解析流程浅析
- Android中measure过程、WRAP_CONTENT详解以及xml布局文件解析流程浅析(下)
- android中init.rc文件的解析问题
- Android的init过程(二):初始化语言(init.rc)解析