init.rc文件解析过程
Android init 语法解析 http://www.cnblogs.com/shed/p/3718548.html
Android init.rc 文件解析 http://www.cnblogs.com/shed/p/3722947.html
我们已经知道init.rc的结构,应该可以想到解析init.rc的过程就是识别一个个section的过程,将各个section的信息保存下来,然后在init.c的main()中去执行一个个命令。
android采用双向链表(关于双向链表详解见本文第三部分)来存储section的信息,解析完成之后,会得到三个双向链表action_list、service_list、import_list来分别存储三种section的信息上。
1. init.c中调用init_parse_config_file(“/init.rc”), 代码如下:
int init_parse_config_file(const char *fn)
{
char *data;
data = read_file(fn, 0); //read_file()调用openlseek ead 将init.rc读出来
if (!data) return -1;
parse_config(fn, data); //调用parse_config开始解析
DUMP();
return 0;
}
2. parse_config()代码如下:
static void parse_config(const char *fn, char *s)
{
struct parse_state state;
struct listnode import_list;
struct listnode *node;
char *args[INIT_PARSER_MAXARGS];
int nargs;
nargs = 0;
state.filename = fn;
state.line = 0;
state.ptr = s;
state.nexttoken = 0;
state.parse_line = parse_line_no_op;
list_init(&import_list);
state.priv = &import_list;
for (;;) {
switch (next_token(&state)) { //next_token()根据从state.ptr开始遍历
case T_EOF: //遍历到文件结尾,然后goto解析import的.rc文件
state.parse_line(&state, 0, 0);
goto parser_done;
case T_NEWLINE: //到了新的一行
state.line++;
if (nargs) {
int kw = lookup_keyword(args[0]); //找到这一行的关键字
if (kw_is(kw, SECTION)) { //查看关键字是否为Section,只有Service 和 on 满足
state.parse_line(&state, 0, 0);
parse_new_section(&state, kw, nargs, args); //解析on 或service
} else { //如果这不是一个Section的第一行,那就是service 或on 下面的内容
state.parse_line(&state, nargs, args);
}
nargs = 0;
}
break;
case T_TEXT: //遇到普通字符
if (nargs < INIT_PARSER_MAXARGS) {
args[nargs++] = state.text;
}
break;
}/*switch*/
}/*for(;;)*/
parser_done:
list_for_each(node, &import_list) {
struct import *import = node_to_item(node, struct import, list);
int ret;
INFO("importing '%s'", import->filename);
ret = init_parse_config_file(import->filename);
if (ret)
ERROR("could not import file '%s' from '%s' ", import->filename, fn);
}
}/*parse_config*/
next_token() 解析完init.rc中一行之后,会返回T_NEWLINE,这时调用lookup_keyword函数来找出这一行的关键字, lookup_keyword返回的是一个整型值,对应keyword_info[]数组的下标,keyword_info[]存放的是keyword_info结构体类型的数据,
struct {
const char *name; //关键字的名称
int (*func)(int nargs, char **args); //对应的处理函数
unsigned char nargs; //参数个数
unsigned char flags; //flag标识关键字的类型,包括COMMAND、OPTION、SECTION
} keyword_info
因此keyword_info[]中存放的是所有关键字的信息,每一项对应一个关键字。
keyword_info 结构体定义在: system/core/init/init_parser.c
keyword_info[] 定义在: system/core/init/keywords.h
根据每一项的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。
3、parse_new_section 代码如下:
void parse_new_section(struct parse_state *state, int kw, int nargs, char **args)
{
printf("[ %s %s ] ", args[0], nargs > 1 ? args[1] : "");
switch(kw) {
case K_service: \解析service类型的section
state->context = parse_service(state, nargs, args);
if (state->context) {
state->parse_line = parse_line_service;
return;
}
break;
case K_on: \解析on类型的section
state->context = parse_action(state, nargs, args);
if (state->context) {
state->parse_line = parse_line_action;
return;
}
break;
case K_import: \解析import类型的section
parse_import(state, nargs, args);
break;
}
state->parse_line = parse_line_no_op;
}
4、parse_service()和parse_line_service()
parse_service()代码如下:
static void *parse_service(struct parse_state *state, int nargs, char **args)
{
struct service *svc;
if (nargs < 3) {
parse_error(state, "services must have a name and a program ");
return 0;
}
if (!valid_name(args[1])) {
parse_error(state, "invalid service name '%s' ", args[1]);
return 0;
}
svc = service_find_by_name(args[1]); //在链表中查找当前行对应的service
if (svc) {
parse_error(state, "ignored duplicate definition of service '%s' ", args[1]);
return 0;
}
//如果当前行对应的service还没有加入service_list链表,则新建一个
nargs -= 2;
svc = calloc(1, sizeof(*svc) + sizeof(char*) * nargs);
if (!svc) {
parse_error(state, "out of memory ");
return 0;
}
svc->name = args[1]; // service 的名字
svc->classname = "default"; //svc 的类名默认为default
memcpy(svc->args, args + 2, sizeof(char*) * nargs); //首个参数放的是可执行文件
svc->args[nargs] = 0;
svc->nargs = nargs; //参数的个数
svc->onrestart.name = "onrestart";
list_init(&svc->onrestart.commands);
list_add_tail(&service_list, &svc->slist); //将这个service加入到service_list
//注意此时svc对象基本上是一个空壳,因为相关的options还没有解析
return svc;
}
parse_line_service()解析service对应的options行,主要是填充parse_service()中创建的service对象。
5、parse_action()和parse_line_action()
parse_action()函数主要是根据当前行的信息创建一个action结构体类型的对象,加入到action_list双向链表中, 代码比较简单,有兴趣可自行研究。
parse_line_action()解析对应的命令行, 代码如下:
static void parse_line_action(struct parse_state* state, int nargs, char **args)
{
struct command *cmd;
struct action *act = state->context;
int (*func)(int nargs, char **args);
int kw, n;
if (nargs == 0) {
return;
}
kw = lookup_keyword(args[0]);
if (!kw_is(kw, COMMAND)) {
parse_error(state, "invalid command '%s' ", args[0]);
return;
}
n = kw_nargs(kw);
if (nargs < n) {
parse_error(state, "%s requires %d %s ", args[0], n - 1, n > 2 ? "arguments" : "argument");
return;
}
cmd = malloc(sizeof(*cmd) + sizeof(char*) * nargs); //生成一个command类型的对象
cmd->func = kw_func(kw);
cmd->nargs = nargs;
memcpy(cmd->args, args, sizeof(char*) * nargs);
list_add_tail(&act->commands, &cmd->clist); //将这个command对象加入actions->commands
}
一个on类型的section对应一个action, action类型定义如下:
struct action {
/* node in list of all actions */
struct listnode alist;
/* node in the queue of pending actions */
struct listnode qlist;
/* node in list of actions for a trigger */
struct listnode tlist;
unsigned hash;
const char *name;
struct listnode commands; //command的双向链表
struct command *current;
};
因此,每个on类型section的第二行开始每一行都解析了一个command, 所有command组成一个双向链表指向该action的commands字段中。
三、相关结构体
1、listnode
listnode 结构体用于建立双向链表,这种结构广泛用于kernel代码中, android源代码中定义了listnode结构体以及相关操作双向链表的方法,与kernel中的定义类似。
listnode 定义在:system/core/include/cutils/list.h
system/core/libcutils/list.c
这个实现的核心思想是:在用户自定义的结构体xx中定义一个listnode类型的成员,
这个listnode类型成员的作用就是能将xx类型的变量组成一个双向链表。下面我们来看一下是listnode是怎么做到的。
//listnode 类型里面只有两个指针prev,next
struct listnode
{
struct listnode *next;
struct listnode *prev;
};
//将链表中的一个node转换成自定义结构体中的一个对象
#define node_to_item(node, container, member)
(container *) (((char*) (node)) - offsetof(container, member))
//初始化一个链表
void list_init(struct listnode *node)
{
node->next = node;
node->prev = node;
}
//将一个节点到链表
void list_add_tail(struct listnode *head, struct listnode *item)
{
item->next = head;
item->prev = head->prev;
head->prev->next = item;
head->prev = item;
}
//删除一个节点
void list_remove(struct listnode *item)
{
item->next->prev = item->prev;
item->prev->next = item->next;
}
理解node_to_item宏是理解listnode用法的关键,这个宏的作用是将一个listnode指针转换成了一个指定类型(自定义)的指针,这个宏先使用offsetof函数获取到指定结构体中指定成员变量的地址偏移量,然后通过指针运算获得listnode指针变量所在结构体变量的指针。
这种实现与我们课堂上所学的链表实现方法不太一样,教科书上的实现是在listnode中存储了自定义的数据,而这个实现是在自定义的数据当中存储listnode指针。
2、action结构体
前面已经讲过on类型的section解析之后会生成一个双向链表action_list, 这个action_list每个node表示就是action结构体的对象,也就是说一个on类型的section都会生成一个action结构体的对象。
action,command,service defined by: system/core/init/init.h
action结构体定义如下:
struct action {
/* node in list of all actions */
struct listnode alist;
/* node in the queue of pending actions */
struct listnode qlist;
/* node in list of actions for a trigger */
struct listnode tlist;
unsigned hash;
const char *name;
struct listnode commands; //节点为command结构体的双向链表
struct command *current;
};
action结构体除了用在on类型的section, 也用在service类型的section,下面介绍service结构体时会说明。
3、command结构体
Command结构体定义如下:
struct command
{
/* list of commands in an action */
struct listnode clist;
int (*func)(int nargs, char **args);
int nargs;
char *args[1];
};
command结构体比较简单, 用于标识一个命令,包含双向链表指针、对应的执行函数、参数个数以及命令关键字。
4、service结构体
struct service {
/* list of all services */
struct listnode slist; //将结构体链接成service_list用
const char *name;
const char *classname;
unsigned flags;
pid_t pid;
time_t time_started; /* time of last start */
time_t time_crashed; /* first crash within inspection window */
int nr_crashed; /* number of times crashed within window */
uid_t uid;
gid_t gid;
gid_t supp_gids[NR_SVC_SUPP_GIDS];
size_t nr_supp_gids;
#ifdef HAVE_SELINUX
char *seclabel;
#endif
struct socketinfo *sockets;
struct svcenvinfo *envvars;
struct action onrestart; /* Actions to execute on restart. */
/* keycodes for triggering this service via /dev/keychord */
int *keycodes;
int nkeycodes;
int keychord_id;
int ioprio_class;
int ioprio_pri;
int nargs;
/* "MUST BE AT THE END OF THE STRUCT" */
char *args[1];
};
service结构体存储了service的相关信息, 包括进程号、启动时间、名字等, 字段onrestart
就用到了action结构体, onrestart这个option后面通常跟着一个命令,所以也用action结构体来表示。
此处贴上init.c: main
int main(int argc, char **argv) { int fd_count = 0; struct pollfd ufds[4]; char *tmpdev; char* debuggable; char tmp[32]; int property_set_fd_init = 0; int signal_fd_init = 0; int keychord_fd_init = 0; bool is_special = false; #ifdef MANUALENABLE /* enable bootchart if asked by user */ if (getenv("bootchart")) enablechart = 1; #endif /* If we are called as 'modprobe' command, we run as a * standalone executable and reuse ueventd's logic to do the job. */ if (!strcmp(basename(argv[0]), "ueventd") || !strcmp(basename(argv[0]), "modprobe")) return ueventd_main(argc, argv); if (!strcmp(basename(argv[0]), "watchdogd")) return watchdogd_main(argc, argv); /* clear the umask */ umask(0); /* Get the basic filesystem setup we need put * together in the initramdisk on / and then we'll * let the rc file figure out the rest. */ //为rootfs建立必要的文件夹,并挂载适当的分区
mkdir("/dev", 0755); mkdir("/proc", 0755); mkdir("/sys", 0755); mount("tmpfs", "/dev", "tmpfs", MS_NOSUID, "mode=0755"); mkdir("/dev/pts", 0755); mkdir("/dev/socket", 0755); mount("devpts", "/dev/pts", "devpts", 0, NULL); mount("proc", "/proc", "proc", 0, NULL); mount("sysfs", "/sys", "sysfs", 0, NULL); /* indicate that booting is in progress to background fw loaders, etc */ close(open("/dev/.booting", O_WRONLY | O_CREAT, 0000)); /* We must have some place other than / to create the * device nodes for kmsg and null, otherwise we won't * be able to remount / read-only later on. * Now that tmpfs is mounted on /dev, we can actually * talk to the outside world. */ //创建/dev/null节点,需要在后面的程序中看到打印信息的话, 需要屏蔽这个函数
open_devnull_stdio(); klog_init(); // log 系统初始化 INFO("system/core/init.c--main() "); property_init(); INFO("reading property config file "); init_parse_config_file("/props.rc"); get_hardware_name(hardware, &revision); process_kernel_cmdline(); union selinux_callback cb; cb.func_log = klog_write; selinux_set_callback(SELINUX_CB_LOG, cb); cb.func_audit = audit_callback; selinux_set_callback(SELINUX_CB_AUDIT, cb); selinux_initialize(); /* These directories were necessarily created before initial policy load * and therefore need their security context restored to the proper value. * This must happen before /dev is populated by ueventd. */ restorecon("/dev"); restorecon("/dev/socket"); restorecon("/dev/__properties__"); restorecon_recursive("/sys"); is_special = is_special_bootmode(bootmode); INFO("property init "); if (!is_special) property_load_boot_defaults(); /* Clear the init.props action list. All the properties * derivation is now done. No need to overload further action_list * processing */ clear_action_list(); INFO("reading config file "); //解析/init.rc,将所有服务和操作信息加入链表
init_parse_config_file("/init.rc"); //触发init.rc 中 “early-init” 的命令。 action_for_each_trigger("early-init", action_add_queue_tail);
//queue_builtin_action来向init进程中的一个待执行action队列增加了一个名称等于“console_init”的action。这个action对应的执行函数为console_init_action,它就是用来显示第二个开机画面的 queue_builtin_action(wait_for_coldboot_done_action, "wait_for_coldboot_done"); queue_builtin_action(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_linux_rng"); queue_builtin_action(keychord_init_action, "keychord_init"); queue_builtin_action(console_init_action, "console_init"); INFO("action_for_each_trigger--init "); /* execute all the boot actions to get us started */ action_for_each_trigger("init", action_add_queue_tail); INFO("action_for_each_trigger--early-fs--fs--post-fs--post-fs-data "); /* skip mounting filesystems in special mode */ if (!is_special) { action_for_each_trigger("early-fs", action_add_queue_tail); action_for_each_trigger("fs", action_add_queue_tail); action_for_each_trigger("post-fs", action_add_queue_tail); action_for_each_trigger("post-fs-data", action_add_queue_tail); } /* Repeat mix_hwrng_into_linux_rng in case /dev/hw_random or /dev/random * wasn't ready immediately after wait_for_coldboot_done */ queue_builtin_action(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_linux_rng"); queue_builtin_action(property_service_init_action, "property_service_init"); queue_builtin_action(signal_init_action, "signal_init"); queue_builtin_action(check_startup_action, "check_startup"); INFO("action_for_each_trigger--early-boot--boot "); if (is_special) { action_for_each_trigger(bootmode, action_add_queue_tail); } else { action_for_each_trigger("early-boot", action_add_queue_tail); action_for_each_trigger("boot", action_add_queue_tail); } /* run all property triggers based on current state of the properties */ queue_builtin_action(queue_property_triggers_action, "queue_property_triggers"); #if BOOTCHART #ifdef MANUALENABLE if (enablechart) #endif queue_builtin_action(bootchart_init_action, "bootchart_init"); #endif for(;;) { int nr, i, timeout = -1; execute_one_command(); restart_processes(); if (!property_set_fd_init && get_property_set_fd() > 0) { ufds[fd_count].fd = get_property_set_fd(); ufds[fd_count].events = POLLIN; ufds[fd_count].revents = 0; fd_count++; property_set_fd_init = 1; } if (!signal_fd_init && get_signal_fd() > 0) { ufds[fd_count].fd = get_signal_fd(); ufds[fd_count].events = POLLIN; ufds[fd_count].revents = 0; fd_count++; signal_fd_init = 1; } if (!keychord_fd_init && get_keychord_fd() > 0) { ufds[fd_count].fd = get_keychord_fd(); ufds[fd_count].events = POLLIN; ufds[fd_count].revents = 0; fd_count++; keychord_fd_init = 1; } if (process_needs_restart) { timeout = (process_needs_restart - gettime()) * 1000; if (timeout < 0) timeout = 0; } if (!action_queue_empty() || cur_action) timeout = 0; #if BOOTCHART #ifdef MANUALENABLE if (enablechart) #endif if (bootchart_count > 0) { if (timeout < 0 || timeout > BOOTCHART_POLLING_MS) timeout = BOOTCHART_POLLING_MS; if (bootchart_step() < 0 || --bootchart_count == 0) { bootchart_finish(); bootchart_count = 0; } } #endif nr = poll(ufds, fd_count, timeout); if (nr <= 0) continue; for (i = 0; i < fd_count; i++) { if (ufds[i].revents == POLLIN) { if (ufds[i].fd == get_property_set_fd()) handle_property_set_fd(); else if (ufds[i].fd == get_keychord_fd()) handle_keychord(); else if (ufds[i].fd == get_signal_fd()) handle_signal(); } } } return 0; }
回到init进程的入口函数main中,最后init进程会进入到一个无限循环中去。在这个无限循环中,init进程会做以下五个事情:
A. 调用函数execute_one_command来检查action_queue列表是否为空。如果不为空的话,那么init进程就会将保存在列表头中的action移除,并且执行这个被移除的action。由于前面我们将一个名称为“console_init”的action添加到了action_queue列表中,因此,在这个无限循环中,这个action就会被执行,即函数console_init_action会被调用。
B. 调用函数restart_processes来检查系统中是否有进程需要重启。在启动脚本/init.rc中,我们可以指定一个进程在退出之后会自动重新启动。在这种情况下,函数restart_processes就会检查是否存在需要重新启动的进程,如果存在的话,那么就会将它重新启动起来。
C. 处理系统属性变化事件。当我们调用函数property_set来改变一个系统属性值时,系统就会通过一个socket(通过调用函数get_property_set_fd可以获得它的文件描述符)来向init进程发送一个属性值改变事件通知。init进程接收到这个属性值改变事件之后,就会调用函数handle_property_set_fd来进行相应的处理。后面在分析第三个开机画面的显示过程时,我们就会看到,SurfaceFlinger服务就是通过修改“ctl.start”和“ctl.stop”属性值来启动和停止第三个开机画面的。
D. 处理一种称为“chorded keyboard”的键盘输入事件。这种类型为chorded keyboard”的键盘设备通过不同的铵键组合来描述不同的命令或者操作,它对应的设备文件为/dev/keychord。我们可以通过调用函数get_keychord_fd来获得这个设备的文件描述符,以便可以监控它的输入事件,并且调用函数handle_keychord来对这些输入事件进行处理。
E. 回收僵尸进程。我们知道,在Linux内核中,如果父进程不等待子进程结束就退出,那么当子进程结束的时候,就会变成一个僵尸进程,从而占用系统的资源。为了回收这些僵尸进程,init进程会安装一个SIGCHLD信号接收器。当那些父进程已经退出了的子进程退出的时候,内核就会发出一个SIGCHLD信号给init进程。init进程可以通过一个socket(通过调用函数get_signal_fd可以获得它的文件描述符)来将接收到的SIGCHLD信号读取回来,并且调用函数handle_signal来对接收到的SIGCHLD信号进行处理,即回收那些已经变成了僵尸的子进程。
注意,由于后面三个事件都是可以通过文件描述符来描述的,因此,init进程的入口函数main使用poll机制来同时轮询它们,以便可以提高效率。
other---
queue_builtin_action(int (*func)(int nargs,char **args), char *name)是以name形成action,挂在action_list上;以func和name组成command,挂在action的commands上。然后加入到action_queue的队尾。
进入无限循环中for(;;)
9.1 execute_one_command():[system/core/init/init.c]
1) 从action_queue取下structaction *act赋给cur_action;
2) 从cur_action获得struct command *赋给cur_command;
3) 执行cur_command->func(cur_command->nargs, cur_command->args)
注1:以上是第一次执行时,如果action中还有command,就不需要1,而2中就是直接再在action上取下一条command即可。
注2:这里才是真正地命令的执行,前面的action_for_each_trigger()和queue_builtin_action()只是加入到action_queue队列中,而这里是从队列中顺序取出,并执行。
所以,加入队列action_queue的顺序也就决定了执行的顺序。Init???.rc中action所在的section决定了它们执行的先后次序:early-init -> init -> early-fs -> fs -> post-fs ->early-boot -> boot。
9.2 restart_processes():system/core/init/init.c
对有SVC_RESTARTING标志的service,执行restart_service_if_needed()
9.3 用poll等待几个事件:property事件/子进程结束的signal事件/keychord
9.4 处理等到的事件
对property_set事件,调用handle_property_set_fd()处理;
对keychord事件,调用handle_keychord()处理;
对signal事件,调用handle_signal()处理;
Ref:
http://www.docin.com/p-623861334.html
http://blog.csdn.net/persuit/article/details/7693479