Android Init进程命令的执行和服务的启动

  这里开始分析init进程中配置文件的解析,在配置文件中的命令的执行和服务的启动。
  首先init是一个可执行文件,它的对应的Makfile是init/Android.mk。 Android.mk定义了init
程序在编译的时候,使用了哪些源码,以及生成方式。当init程序生成之后,最终会放到/init,
即根目录的init文件。通常所说的init进程就是执行这个init程序。

  执行这个init程序的代码是在KERNEL/init/main.c文件中的kernel_init()函数里,当kernel
把一些基本的工作,比如CPU初始化,内存初始化,输入输出初始化等等完成之后,就会找到
根目录下的init程序,然后执行这个程序。

  在Android系统中,init程序对应的代码在ANDROID/system/core/init/下,用Android.mk,文件
管理编译的。这个程序的入口函数是init.c的main函数。在Android下init进程的主要功能和其它
发行版的Linux的系统差不多,都是通过解析配置文件,完成Linux系统的基本的操作,比如
用户级别,权限的设定,一些安全策略的启动,如selinux的启动,基本的文件(/dev, /sys等)创建,
然后就是其它基本的进程。 init的进程的id永远为1,在系统中最基本的进程之一。

今天我们主要目的目标如下:
  1) init进程是如何解析配置文件的
  2) init进程是如何启动其它基本的进程的

1 init进程是如何解析配置文件


  1.1 了解init.rc文件的语法(见init.rc语法)
  

1.2 init.rc对应的数据结构

  parse_state这个结构体是用来跟踪整个init.rc文件解析过程的。这个在阅读代码时,把这个结构体理解为一个篮子,

这个篮子中放的都是各种各样的rc文件内容即可。

1         struct parse_state
2         struct command{
3             struct listnode clist;//命令数列
4 
5             int (*func)(int nargs, char **args);//当前命令对应的函数,比如write命令,对应do_write(xxx)
6             int nargs; //参数个数
7             char *args[1]; //参数数组
8         };

  action就是on xxx对应的部分,action主要是由command组成。Android系统在开机执行的顺序,
是按照这个action顺序执行的。也就是说系统触发不同的trigger,就顺序执行这个trigger对应的action
下的所有命令,这个执行过程是顺序执行的,没有并行进行。而且系统在启动过程中,都是按照action去
执行的。记住,是在开机过程中才是这么执行的。

        struct action {
            struct listnode alist;//系统中所有的action的队列
            struct listnode qlist;//等待触发trigger的队列
            struct listnode tlist;//这个队列的意义不明,好在也没人用到这个队列

            unsigned hash;
            const char *name;//这个名字就是triggeer的名字

            struct listnode commands;//在当前这个action下所有的comman的队列
            struct command *current;//当前要执行的命令
        };

  service也是系统的一个SECTION,这样的SECTION仅有service, import, on xxxx这三种。对这三种
不同的SECTION解析的函数是不同的。记住on xxxx就是一个action。这个数据结构就是对应一个service,在
系统中service是不能直接执行的,它仅仅是一个service的属性信息的集合,为service的启动提供全面的信息,
但是它不是一个命令,所以不能直接执行。前面这些command可能仅仅就是在init进程中执行,但是service不同。
service启动是在一个新的进程中进行的。也就是说init进程会先fork一个进程,然后通过exec家族函数去启动
这个service。所以service是运行在一个新的进程中的。

struct service

  1.3  init.rc文件的解析

  对于init.rc文件的解析主要是通过以下代码实现的[init.c文件中]:

1 init_parse_config_file("/init.rc");

这句代码是解析所有init.rc文件的入口,其他的*.rc文件都是通过init.rc中通过import一级一级地导入的;
所以从这句代码入手是最合适的地方。 init_parse_config_file函数读取init.rc文件,并调用parse_config函数,
这个函数才是真正解析init.rc文件的地方。先看看这个函数的主要部分,如下[init_parce.c文件中]:

 1         static void parse_config(const char *fn, char *s)
 2         {
 3             //第一部分
 4             struct parse_state state;
 5             struct listnode import_list;
 6             struct listnode *node;
 7             char *args[INIT_PARSER_MAXARGS];
 8             int nargs;
 9 
10             nargs = 0;
11             state.filename = fn;
12             state.line = 0;
13             state.ptr = s;
14             state.nexttoken = 0;
15             state.parse_line = parse_line_no_op;
16 
17             list_init(&import_list);
18             state.priv = &import_list;
19             //第二部分
20             for (;;) {
21                 switch (next_token(&state)) {
22                 case T_EOF:
23                     state.parse_line(&state, 0, 0);
24                     goto parser_done;
25                 case T_NEWLINE:
26                     state.line++;
27                     if (nargs) {
28                         int kw = lookup_keyword(args[0]);
29                         if (kw_is(kw, SECTION)) {
30                             state.parse_line(&state, 0, 0);
31                             parse_new_section(&state, kw, nargs, args);
32                         } else {
33                             state.parse_line(&state, nargs, args);
34                         }
35                         nargs = 0;
36                     }
37                     break;
38                 case T_TEXT:
39                     if (nargs < INIT_PARSER_MAXARGS) {
40                         args[nargs++] = state.text;
41                     }
42                     break;
43                 }
44             }
45         //第三部分
46         parser_done:
47             list_for_each(node, &import_list) {
48                  struct import *import = node_to_item(node, struct import, list);
49                  int ret;
50 
51                  INFO("importing '%s'", import->filename);
52                  ret = init_parse_config_file(import->filename);
53                  if (ret)
54                      ERROR("could not import file '%s' from '%s'\n",
55                            import->filename, fn);
56             }
57         }

把这个函数分成三部分理解会更方便,首先第一部分只是在解析过程中一些变量的初始化,主要是就是parse_state结构体
的初始化。真正解析rc文件的是在第二部分;在当前rc文件解析完成后,会处理当前文件import的其它rc文件,这些是在
第三部分做的。如果有import其它的rc文件,在第三部分中会调用init_parse_config_file函数,接着解析导入的rc文件;
从整体上看,像是一个递归函数。我们把重点放在第二部分上。

在第二部分中next_token函数相当于一个简单的词法分析器,这个函数对应的状态机如下图:

 

这个图画的不是很标准,我再大概注释下吧:对于rc文件内容逐个字母输入这个状态机,如果是字符的话就继续输入下一个字符,直到输入的是空格或\r或者\t,

那么就进入TEXT状态,并把这个token返回给parse_config函数去处理;同样,要是遇到换行,或者文件结束,都要返回给parse_config去处理。

从第二部分可以看出,rc文件的解析是以行为单位进行的,在每一行中检查到一个TEXT,就会把这个单词放入args数组中;
这样,当一行结束时,这个args数组和nargs变量就初始化完成;然后开始换行;在换行时,需要在如下代码(第二部分代码中)中进行:

 1                 case T_NEWLINE:
 2                     state.line++;
 3                     //nargs非0,说明这行中有命令需要解析
 4                     if (nargs) {
 5                         //先看看在本行中第一个词是不是关键词,
 6                         //关键词列表在keywords.h文件中
 7                         int kw = lookup_keyword(args[0]);
 8                         //如果第一参数是关键词,那么就会返回关键词的index
 9                         //然后判断这个关键词是不是SECTION,只有import,on,service
10                         //才是SECTION
11                         if (kw_is(kw, SECTION)) {
12                             state.parse_line(&state, 0, 0);
13                             //在parse_new_section中,会解析这个section,
14                             //在解析过程中,最重要的是给parse_line赋值;
15                             //因为parse_line是个函数指针
16                             parse_new_section(&state, kw, nargs, args);
17                         } else {
18                             //在一个SECTION中,parse_line会保持不变的,
19                             //直到遇到下个SECTION之前,这个parse_line函数
20                             //会保持不变的
21                             state.parse_line(&state, nargs, args);
22                         }
23                         nargs = 0;
24                     }
25                     break;

给parse_line赋值是在parse_new_section中进行的,能够赋值给parse_line的函数有parse_line_service,parse_line_action,
对这个两个函数的理解,有助于对init.rc文件解析的理解。对于这两个函数没必要逐行分析,这里不作介绍;
在lookup_keyword函数中,有个地方说明下;可能是我的基础知识不是很牢固,在看这个函数的时候,有些地方卡了一下;
在init_parse.c文件中有如下宏定义

1                 #define KEYWORD(symbol, flags, nargs, func, uev_func) \
2                     [ K_##symbol ] = { #symbol, func, uev_func, nargs + 1, flags, },

而在keywords.h文件中,还有个宏定义如下:

                #define KEYWORD(symbol, flags, nargs, func, uev_func) K_##symbol,

这两个宏是一样的。 C语言中宏的作用范围只是在单文件中。宏是在编译过程中进行的替换,这个过程发生在链接之前,所以
宏的作用范围只能是在当前文件中。这样的话,在init_parse.c文件中的宏定义没人用到,因此哪个宏也是无意义的。

2 init进程是如何启动其它基本的进程的
  2.1 init进程中命令和服务启动顺序
    在正式开始介绍init进程是如何启动其它服务之前,还有一些内容要介绍,就是系统如何确定开机执行顺序的。在init.c文件中有如下代码:

 1                 action_for_each_trigger("early-init", action_add_queue_tail);
 2                 queue_builtin_action(wait_for_coldboot_done_action, "wait_for_coldboot_done");
 3                 queue_builtin_action(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_linux_rng");
 4                 queue_builtin_action(keychord_init_action, "keychord_init");
 5                 queue_builtin_action(console_init_action, "console_init");
 6                 action_for_each_trigger("init", action_add_queue_tail);
 7                 if (!is_special) {
 8                     action_for_each_trigger("early-fs", action_add_queue_tail);
 9                     action_for_each_trigger("fs", action_add_queue_tail);
10                     action_for_each_trigger("post-fs", action_add_queue_tail);
11                     action_for_each_trigger("post-fs-data", action_add_queue_tail);
12                 }
13                     /* Repeat mix_hwrng_into_linux_rng in case /dev/hw_random or /dev/random
14                      * wasn't ready immediately after wait_for_coldboot_done
15                      */
16                 queue_builtin_action(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_linux_rng");
17                 queue_builtin_action(property_service_init_action, "property_service_init");
18                 queue_builtin_action(signal_init_action, "signal_init");
19                 queue_builtin_action(check_startup_action, "check_startup");
20                 if (is_special) {
21                     action_for_each_trigger(bootmode, action_add_queue_tail);
22                 } else {
23                     action_for_each_trigger("early-boot", action_add_queue_tail);
24                     action_for_each_trigger("boot", action_add_queue_tail);
25                 }
26                 queue_builtin_action(queue_property_triggers_action, "queue_property_triggers");

  这段代码中主要的函数就两个,分别是action_for_each_trigger,queue_builtin_action,这两个函数操作同意队列,
这个队列就是action_queue。init进程启动顺序就是action在action_queue这个队列中的顺序。action_for_each_trigger
函数就是把*.rc文件中, 对应trigger的action放入action_queue队列。 而queue_builtin_action函数是临时需要在action_queue中
新增加一个action,只不过这个action仅仅有一个command,这个command就是queue_builtin_action函数第一个参数对应的函数。

  因此从这段代码中,我们可以看出,init执行顺序是:
    early-init,    wait_for_coldboot_done,   mix_hwrng_into_linux_rng,  keychord_init,console_init,   init,
    early-fs,   fs,   post-fs,   post-fs-data,   mix_hwrng_into_linux_rng,  property_service_init,signal_init,
    check_startup,  early-boot,   boot,   queue_property_triggers.
  上面这些代码仅仅是把action_queue队列配置完成,安排好每个action的顺序。 但是现在并没有开始按照这个队列去执行各个
命令或者启动各个服务。

  2.2 在init进程中执行命令和服务

  这里就开始介绍init进程是如何执行命令和启动服务的。这个过程是在如下代码开始执行的:

 1             for(;;) {
 2                 int nr, i, timeout = -1;
 3                 //第一部分
 4                 //execute_one_command是开始执行命令的地方
 5                 execute_one_command();
 6                 //如果有些进程需要重启的话在这里进行
 7                 restart_processes();
 8                 //第二部分
 9                 //接下来是四个socket,使用Linux的poll机制去监听
10                 //这四个文件的状态,与其它进程通信;比如:
11                 //当我们通过命令调用 setprop时候,就会和get_property_set_fd
12                 //指向的socket通信
13                 if (!property_set_fd_init && get_property_set_fd() > 0) {
14                     ufds[fd_count].fd = get_property_set_fd();
15                     ufds[fd_count].events = POLLIN;
16                     ufds[fd_count].revents = 0;
17                     fd_count++;
18                     property_set_fd_init = 1;
19                 }
20                 if (!signal_fd_init && get_signal_fd() > 0) {
21                     ufds[fd_count].fd = get_signal_fd();
22                     ufds[fd_count].events = POLLIN;
23                     ufds[fd_count].revents = 0;
24                     fd_count++;
25                     signal_fd_init = 1;
26                 }
27                 if (!keychord_fd_init && get_keychord_fd() > 0) {
28                     ufds[fd_count].fd = get_keychord_fd();
29                     ufds[fd_count].events = POLLIN;
30                     ufds[fd_count].revents = 0;
31                     fd_count++;
32                     keychord_fd_init = 1;
33                 }
34 
35                 if (process_needs_restart) {
36                     timeout = (process_needs_restart - gettime()) * 1000;
37                     if (timeout < 0)
38                         timeout = 0;
39                 }
40 
41                 if (!action_queue_empty() || cur_action)
42                     timeout = 0;
43                 //这里就是poll机制的利用,
44                 //接收到socket通信后,对于这些事件的分配
45                 nr = poll(ufds, fd_count, timeout);
46                 if (nr <= 0)
47                     continue;
48 
49                 for (i = 0; i < fd_count; i++) {
50                     if (ufds[i].revents == POLLIN) {
51                         if (ufds[i].fd == get_property_set_fd())
52                             handle_property_set_fd();
53                         else if (ufds[i].fd == get_keychord_fd())
54                             handle_keychord();
55                         else if (ufds[i].fd == get_signal_fd())
56                             handle_signal();
57                     }
58                 }
59             }

便于理解,把上述代码分为两个部分。这两个部分都是重点。
不过第一部分更切合我们这一小节的主题:命令的执行和服务的启动。
execute_one_command函数是命令执行和服务启动主要函数,这个函数的代码如下:

 1             void execute_one_command(void)
 2             {
 3                 int ret;
 4 
 5                 if (!cur_action || !cur_command || is_last_command(cur_action, cur_command)) {
 6                     //从action_queue中取出第一个action
 7                     cur_action = action_remove_queue_head();
 8                     cur_command = NULL;
 9                     if (!cur_action)
10                         return;
11                     INFO("processing action %p (%s)\n", cur_action, cur_action->name);
12                     //从当前action中取出第一个command
13                     cur_command = get_first_command(cur_action);
14                 } else {
15                     cur_command = get_next_command(cur_action, cur_command);
16                 }
17 
18                 if (!cur_command)
19                     return;
20                 //执行这个command
21                 ret = cur_command->func(cur_command->nargs, cur_command->args);
22                 INFO("command '%s' r=%d\n", cur_command->args[0], ret);
23             }

上面这个过程就是命令执行的过程.这些命令对应的函数,可以从kerwords.h中看到。如果前面的rc文件解析中,仔细分析
了整个流程的话,就很容易回忆起前面的这些内容。对于这个func也不会陌生,这些函数的实现都是在builtins.c文件中实现的。
在rc文件中出现的命令,绝大部分都是很常见的,不多做介绍。不过,下面还是会以其中一个命令说明下整个过程,这个命令就是
class_start--这个命令是专门用来启动service的,在其他Linux系统中也是没有的。
对于这个命令,首先到keywords.h中找到其对应的函数,如下:

1             KEYWORD(class_start, COMMAND, 1, do_class_start, 0)

所以class_start命令对应的函数实际上就是do_class_start。前文已经说过,这些函数都是在builtins.c文件中实现的,那么这个
函数实现如下:

 1             int do_class_start(int nargs, char **args){
 2                         /* Starting a class does not start services
 3                          * which are explicitly disabled.  They must
 4                          * be started individually.
 5                          * */
 6                     service_for_each_class(args[1], service_start_if_not_disabled);
 7                         return 0;
 8             }
 9 service_for_each_class函数的实现实在init_parser.c文件中,如下
10             void service_for_each_class(const char *classname, void (*func)(struct service *svc)){
11                 struct listnode *node;
12                 struct service *svc;
13                 list_for_each(node, &service_list) {
14                     svc = node_to_item(node, struct service, slist);
15                     if (!strcmp(svc->classname, classname)) {
16                         func(svc);
17                     }
18                 }
19             }

到这里,基本已经可以看出这个命令和service之间的关系来。通过这两个函数,实际上就是通过service_start_if_not_disabled
函数启动所有className与给出的classname相同的service。 这些classname指的就是在定义每一个service的时候,定义在class
之后的部分,比如下面这个service:

 1             service servicemanager /system/bin/servicemanager
 2                 class core
 3                 user system
 4                 group system
 5                 critical
 6                 onrestart restart healthd
 7                 onrestart restart zygote
 8                 onrestart restart media
 9                 onrestart restart surfaceflinger
10                 onrestart restart drm

servicemanager服务的classname就是 core. 那么调用class_start命令的地方在哪里呢?
调用class_start命令的地方在init.rc中,当执行boot action的时候,顺序执行就能执行到这个命令,首先启动的core一级别的服务,
然后启动才是main级别的服务

1             on boot
2                 ...
3                 class_start core
4                 class_start main

既然已经找到了命令开始的地方了,那么我们可以继续看看service到底是如何执行的。这就要看service_start_if_not_disabled函数了,
这个函数的代码如下,在builtins.c文件中:

1             static void service_start_if_not_disabled(struct service *svc){
2                     if (!(svc->flags & SVC_DISABLED)) {
3                                 service_start(svc, NULL);
4                     }
5             }

这里会检查flags中没有disabled选项的启动。在service_start函数是真正启动一个服务的地方。service_start函数在init.c文件中实现的。
当你在这个函数中看到fork()函数时候,你就明白这个服务启动了。而逐个启动每个服务,这个循环过程实在service_for_each_class中的
list_for_each中的,可以回头再看看。

到这里就是介绍完成来通过rc文件启动一个服务的过程。能读到这里,说明你真的很有耐心啊,给自己一个表扬吧。不过这时候,你也许会有
一个疑问,如果一个service中flags中有disabled项时,这样的服务是怎样启动的呢?

下面就以下面这个含有disabled项服务的启动为例,介绍下这类服务的启动过程,这个服务如下:

1             service bootanim /system/bin/bootanimation
2                 class main
3                 user graphics
4                 group graphics
5                 disabled
6                 oneshot

这个服务是开机动画,如果使用的是模拟器的话,就是开机闪烁android的那个动画。这个服务中含有disabled, 通过上面的解析,我们知道这个服务
肯定不是通过class_start命令启动的。但是在开机过程中,我们的确看到来开机动画,那么这个服务是在何时由谁启动的呢?

启动开机动画是在SurfaceFlinger初始化完成时,由SurfaceFlinger间接启动这个服务的。在SurfceFlinger初始化完成时,调用来函数startBootAnim(),
这个函数通过设置一个系统属性,然后开机动画就开始来。设置这个属性的代码如下:

1             void SurfaceFlinger::startBootAnim() {
2                 // 首先是先退出开机动画。如果开机动画在进行中,那么就退出这个开机动画;
3                 // 如果开机动画没有运行,那么这个属性设置上也是没有影响的
4                 property_set("service.bootanim.exit", "0");
5                 //然后,开始播放动画。init进程会检查这个属性,然后开始动画播放
6                 property_set("ctl.start", "bootanim");
7             }

property_set的函数,在实现的时候,实际上是通过写socket和init进程通信。在前面也说到过,init进程在启动后,会监视四个文件的状态,这四个
文件都是socket文件,其中一直就是属性socket文件的描述符get_property_set_fd(). 通过Linux的poll机制,当有有系统属性设置进来的时候,就会
有触发调用下面的函数:
handle_property_set_fd()
这函数是在init.c文件中被调用,它的实现实在property_service.c文件中。这个函数从socket中读取出传递过来的信息。传递过来的信息都是按照键值对
封装好的。如果键值对中的name中前4个字母是"crtl.",那么就会调用handle_control_message()函数。关于函数handle_property_set_fd()的代码在property_service.c
文件中,这里就不再拿出来单独看了.
在调用到handle_control_message函数,这个函数如下:

 1             void handle_control_message(const char *msg, const char *arg)
 2             {
 3                 if (!strcmp(msg,"start")) {
 4                     msg_start(arg);
 5                 } else if (!strcmp(msg,"stop")) {
 6                     msg_stop(arg);
 7                 } else if (!strcmp(msg,"restart")) {
 8                     msg_restart(arg);
 9                 } else {
10                     ERROR("unknown control msg '%s'\n", msg);
11                 }
12             }
13             static void msg_start(const char *name)
14             {
15                 ...
16                 svc = service_find_by_name(name);
17                 ...
18                 service_start(svc, args);
19                 ...
20             }

如果命令中的start的话,这里把msg_start函数彻底简写了,仅仅保留这两个最核心的代码。根据service的名字找到这个service,
然后启动service。当你看到service_start()函数的时候,想必你已经明白来整个过程来。service_start()函数在前面有过简略
地介绍,这里也不多说来。

就是类似与这样,init进程在设备启动后,还在忙碌地参与这系统的运行。

posted @ 2014-12-25 14:43  Balancor  阅读(3052)  评论(0编辑  收藏  举报