您的位置:首页 > 移动开发 > Android开发

Android init.rc文件解析过程详解(一)

2013-12-21 20:22 549 查看
init.c与init.rc在源码中的位置分别位于如下:

1
init.c
: /system/core/init
2
init.rc
: /system/core/rootdir
一、init.rc文件结构介绍

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
这样一个section包含了三个export命令,命令的执行是以section为单位的,所以这三个命令是一起执行的,不会单独执行,那什么时候执行呢? 这是由init.c的main()所决定的,main()里在某个时间会调用

1
action_for_each_trigger(
"init"
,
action_add_queue_tail);
这就把 ” on init “开始的这样一个section里的所有命令加入到一个执行队列,在未来的某个时候会顺序执行队列里的命令,所以调用

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
surfaceflinger作为一个名字标识了这个service,

1
/system/bin/surfaceflinger
表示可执行文件的位置, class、user、group、onrestart这些关键字所对应的行都被称为options,options是用来描述的service一些特点,不同的service有着不同的options。

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
所以可以看出android的启动过程主要就是on类型的section被执行的过程。

3、import类型的section表示引入另外一个.rc文件,例如:

1
import
init.
test
.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中调用

1
init_parse_config_file(“/init.rc”)
, 代码如下:

01
int
init_parse_config_file(
const
char
*fn)
02
{
03
char
*data;
04
data
= read_file(fn,0);
//read_file()调用open\lseek\read
将init.rc读出来
05
if
(!data)
return
-1;
06
07
parse_config(fn,
data);
//调用parse_config开始解析
08
DUMP();
09
return
0;
10
}
2、parse_config()代码如下:

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
= lookup_keyword(args[0]);
//找到这一行的关键字
28
if
(kw_is(kw,
SECTION)) {
//如果这是一个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
}
next_token() 解析完init.rc中一行之后,会返回 T_NEWLINE ,这时调用 lookup_keyword 函数来找出这一行的关键字,lookup_keyword 返回的是一个整型值,对应 keyword_info[] 数组的下标, keyword_info[] 存放的是 keyword_info 结构体类型的数据,

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
因此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"
,
MS_NOSUID,
"mode=0755"
);
14
mkdir(
"/dev/pts"
,
0755);
15
mkdir(
"/dev/socket"
,
0755);
16
mount(
"devpts"
,
"/dev/pts"
,
"devpts"
,
0,NULL);
17
mount(
"proc"
,
"/proc"
,
"proc"
,
0,NULL);
18
mount(
"sysfs"
,
"/sys"
,
"sysfs"
,
0,NULL);
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,
i,timeout = -1;
84
85
execute_one_command();
86
//
启动所有init脚本中声明的service
87
restart_processes();
88
...
...
89
//
多路监听设备管理,子进程运行状态,属性服务
90
nr
= poll(ufds,fd_count,timeout);
91
...
...
92
}
93
94
return
0;
95
}
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: