Android init源代码分析(2)init.rc解析

本文描述init.rc脚本解析以及执行过程,读完本章后,读者应能
(1) 了解init.rc解析过程
(2) 定制init.rc

init.rc介绍
init.rc是一个文本文件,可认为它是Android系统启动脚本。init.rc文件中定义了环境变量配置、系统进程启动,分区挂载,属性配置等诸多内容。init.rc具有特殊的语法。init源码目录下的readme.txt中详细的描述了init启动脚本的语法规则,是试图定制init.rc的开发者的必读资料。
Android启动脚本包括一组文件,包括
init.rc
init.usb.rc
init.trace.rc
init.{hardware}.rc
init.environ.rc
init.zygote32.rc
这些文件可能分布于如下目录中
  1. system/core/rootdir
  2. device/{vendor}/{hardware}/
除init.rc外,其他文件都由init.rc中以import语句导入,一般来说init.rc文件存放通用配置,而其他特定模块以及特定硬件的配置则放置在独立的文件中,这样设计可以使init.rc脚本简洁,方便系统维护和升级。

一个简单的init.rc语法如下。(基于system/core/rootdir/init.rc裁剪)
# Copyright (C) 2012 The Android Open Source Project
#
# IMPORTANT: Do not create world writable files or directories.
# This is a common source of Android security bugs.
#

import /init.environ.rc
import /init.usb.rc
import /init.${ro.hardware}.rc
import /init.${ro.zygote}.rc
import /init.trace.rc
on early-init
    start ueventd

on init
    sysclktz 0
    loglevel 3
    mkdir /system
    mkdir /data 0771 system system
    write /proc/sys/kernel/panic_on_oops 1
# Load properties from /system/ + /factory after fs mount.
on load_all_props_action
    load_all_props
on post-fs
    # once everything is setup, no need to modify /
    mount rootfs rootfs / ro remount
on boot
    # basic network init
    ifup lo
    class_start core
    class_start main
on property:vold.decrypt=trigger_reset_main
    class_reset main
service ueventd /sbin/ueventd
    class core
    critical
on property:ro.debuggable=1
    start console
service debuggerd /system/bin/debuggerd
    class main
service bootanim /system/bin/bootanimation
    class main
    user graphics
    group graphics
    disabled
    oneshot

为了行文方便,下文提及init.rc,通常泛指Android启动脚本。

init.rc可以定义两类结构:Actions与Services。
Actions
Actions是一组命令的集合,定义一个Actions如下,每个Actions都可以定义一个触发器(trigger),Actions格式如下:
on <trigger>
   <command>
   <command>
   <command>
其中<command>类似于shell命令,command对应一个函数,通常执行一条动作,例如创建一个文件夹等。

触发器(Triggers)
触发器只是一段字符串罢了
PS:在android/system/core/rootdir/下执行
grep -h "^on" --include="*.rc" -r .
可以当前init启动脚本所含有的trigger,如下。
on early-init
on init
on property:sys.boot_from_charger_mode=1
on load_all_props_action
on firmware_mounts_complete
on late-init
on post-fs
on post-fs-data
on boot
on nonencrypted
on property:sys.init_log_level=*
on charger
on property:vold.decrypt=trigger_reset_main
on property:vold.decrypt=trigger_load_persist_props
on property:vold.decrypt=trigger_post_fs_data
on property:vold.decrypt=trigger_restart_min_framework
on property:vold.decrypt=trigger_restart_framework
on property:vold.decrypt=trigger_shutdown_framework
on property:sys.powerctl=*
on property:sys.sysctl.extra_free_kbytes=*
on property:sys.sysctl.tcp_def_init_rwnd=*
on property:ro.debuggable=1
on property:ro.kernel.qemu=1
on boot
on post-fs-data
on property:sys.usb.config=none
on property:sys.usb.config=adb
on property:sys.usb.config=accessory
on property:sys.usb.config=accessory,adb
on property:sys.usb.config=audio_source
on property:sys.usb.config=audio_source,adb
on property:sys.usb.config=accessory,audio_source
on property:sys.usb.config=accessory,audio_source,adb
on property:persist.sys.usb.config=*
根据trigger的不同,可以将Actions大致分为两类:
(1) 普通型
这类trigger的的作用仅仅是用于给一个Actions命名,方便查找和引用。如 early-init、init、late-init、early-fs、fs、post-fs、post-fs-data、early-boot、boot、charger等
一般来说,这类Actions将在Android启动时执行,其trigger暗示了执行对应Actions执行的时机。具体的执行流程将在本文最后介绍。

此外,根据readme.txt描述,还有其他几种trigger,但在init.rc以及init源代码中却没有找到相关代码,如下所示,
device-added-<path>
device-removed-<path>
    设备节点被添加或移除时调用,。
service-exited-<name>
   这类trigger将在某service退出时执行。关于什么是service稍后介绍。

(2) 属性型
其trigger为property:<name>=<value>
其trigger不仅唯一标识了这个Actions,同时也设定了这类Actons执行的条件,当property <name>的值为<value>时才会被执行。

Commands

command的格式如下
command-name <parament1> [parament2...]
<>表示必须存在的参数,[]表示可选参数

说明:readme.txt中虽然有大部分commands的介绍,但并不完整。init.rc中所有commands都在keywords.h中定义,可使用如下命令提取。
sed -n "s/KEYWORD(\([^,]\+\),[ \t]\+COMMAND.*/\1/p" keywords.h

目前Android4.4支持的Commands如下:
    chdir <direcotory> 改变工作目录
    chroot <directory> 改变当前进程的root目录
    class_start <serviceclass> 如果serviceclass内所有services尚未启动,则启动它
    class_stop  <serviceclass> 停止serviceclass内所有services
    class_reset <serviceclass> 重启serviceclass内所有services
    domainname <name>  设置domain名称
    enable  <servicename>
    exec <path> [ <argument> ]*  fork后执行path所执行的程序,该语句会阻塞直到path指定的程序执行完毕。
    export <name> <value> 设置全局环境变量,将会被该命令后所启动的进程继承。
    hostname <name> 设置主机名
    ifup  <interface> 启动interface所指定的网络接口
    insmod <path> 安装path所指定的内核模块
    mkdir <path> [mode] [owner] [group] 创建path制定的目录,并根据可选的mode、owner、group设定参数。如果未指定可选参数,则创建的文件夹权限将会设置为0755,而owner与group都为root
    mount_all
    mount  <type> <device> <dir> [ <mountoption] *
    powerctl
    restart <service>
    restorecon
    restorecon_recursive
    rm <path> 删除path指定的文件
    rmdir <path> 删除path指定的目录(目录为空才能删除)
    setcon
    setenforce
    setkey
    setprop
    setrlimit
    setsebool
    start <service>
    stop <service>
    swapon_all
    trigger
    symlink
    sysclktz
    wait
    write
    copy
    chown
    chmod
    loglevel
    load_persist_props
    load_all_props

Service
这里的service仅仅是init.rc中的概念,与通常意义上的“服务”概念无关。一个Service对应一个可执行程序,并且可以设定该程序的一些执行性质,如仅仅执行一次、或退出时自动重启。当service所代表的可执行程序在退出时自动重启时,该service通常意味着这是一个守护进程。

service字段由如下格式定义
service <name> <pathname> [ <argument> ]*
   <option>
   <option>
   ...
<name>字段为service的名字,<pathname>为该service对应的二进制程序的路径,随后是该程序的参数列表。
<option>是该service的属性(笔者注:也许用attribute更合适),目前Android4.4中所支持的option如下所示(ps,由 sed -n "s/KEYWORD(\([^,]\+\),[ \t]\+OPTION.*/\1/p" keywords.h 命令生成)
    capability
    class <name> 设定service的class
    console
    critical
    disabled
    group <groupname> [<groupname>]* 设定进程
    keycodes
    oneshot  service只执行一次
    onrestart 当service终止时自动重启
    seclabeli
    setenv
    socket
    user <username>    
    ioprio

为了方便管理多个service,可为service设定class属性,具有同样class的多个service构成一个组,可以在Actions中通过class_start、class_stop、class_reset等命令启动、停止、重启动。

此外init.rc中还有其他规则
  • 以#号开头的行为注释行
  • import语句导入其他init脚本文件,
  • \可用于转义换行符
  • 空格与Tab字符都可用作空白字符
前面介绍了init.rc的语法,假如要自己实现一个程序读取init.rc并解析其内容,该如何实现呢?读者不妨思考下。
Android中的实现非常的简洁。解析设计思路如下:
  • 引入section的概念。一个Actions、Service、import是一个section,分别实现不同的section解析代码。
  • 基于行解析,行解析函数与当前所在的section有关,使用函数指针实现。
  • 利用空白字符(一个或多个空行)实现分词,当检测到新的一行时,识别关键词为on、service、import,若是则认为一个section开始了,同时也意味着上一个section终结了。import使用递归实现
  • 每个Actions创建一个struct action数据结构,每个command创建一个struct command数据结构,action中有一个command的链表;每个service创建一个struct service数据结构。
  • 创建全局Actions链表,将识别到Actions都加入全局链表中,创建全局Service链表,将识别到的Service加入到全局链表中
执行思路如下:
创建一个额外的链表充当Actions执行队列action-queue。将一些Actions链表加入到执行队列中。
然后一次从队列中取出一个Actions,依次执行其中每一条command,当该Actions执行完毕后则从actions-queue取出下一个Actions继续执行。

init.rc main函数<part3>代码如下
    INFO("reading config file\n");
    init_parse_config_file("/init.rc")
init_parse_config_file("/init.rc")
在这个函数中将会加载Android系统/init.rc文件。

这个函数将init.rc读入内存,解析其内容(遇到import关键字,则加载对应的文件),
1)Actions
针对Actions,创建struct action数据结构。为Actions的每个command创建一个struct comand数据结构,struct actions存储struct command的链表。

相关数据结构代码如下
init_parser.c
static list_declare(service_list);
static list_declare(action_list);
static list_declare(action_queue);
service_list是全局service链表,解析启动脚本过程中,service对应数据结构struct service将会挂载到这里。
action_list是全局Actions链表,Actions对应数据结构struct action将会挂载到这里。
至于action_queue在解析完毕之后,实际执行Actions时才会用到。

init.h
struct command
{
        /* list of commands in an action */
    struct listnode clist;

    int (*func)(int nargs, char **args);

    int line;
    const char *filename;

    int nargs;
    char *args[1];
};

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;
    struct command *current;
};

struct command各字段含义如下:
clist是“挂载”于链表的钩子
line变量存放对应的command语句在init脚本文件(可能是init.rc、init.usb.rc等)行号。
filename存放所在init脚本文件的名字
nargs存放command语句所表示的命令对应的函数的参数个数,
args是struct command的最后一个变量,看起来是一个单元素的数组,但是在init.rc解析过程中,确定nargs后,使用malloc申请内存时,args所表示的数组长度将是 n+1个。(与0长度数组的实现类似)。
func字段存放command语句所对应的函数指针。

struct actions各字段含义如下:
alist变量是action_list链表钩子
qlist是action_queue链表钩子
类似, tlist的也是一个特殊链表的钩子
hash在目前init实现中未使用
name存放Actions的名字(也就是Actions的trigger)
commands存放该Actions所有struct command链表
current在Actions执行时,存储当前正在被执行的struct command指针。

actions_list是一个双向链表,其每一个节点都是struct action结构的alist对象,当init.rc解析完毕之后,二者效果如下所示。为了简单,链表只绘制了两个节点。



init_parse_config_file执行完毕后,解析出启动脚本中所有的Actions,并构造出上图所示的数据结构。可见利用action_list,可以遍历启动脚本中所有Actions,并能遍历出单个Actions中的所有command。

2)service
init在解析init启动脚本,为每个service字段创建一个struct service数据结构
struct service {
        /* list of all services */
    struct listnode slist; //用于挂载于service_list的钩子
    const char *name; //存放service的名称
    const char *classname; //用于存放该service所隶属的class的名称
    unsigned flags; //位图变量,其各个位代表不同的servcie的属性(对应service中的option字段)
    pid_t pid; //当service对应的程序执行时,存放其进程号
    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; //该servcie对应进程的uid
    gid_t gid; //该service对应进程的gidinit_parse_config_file("/init.rc");
    gid_t supp_gids[NR_SVC_SUPP_GIDS];//该service对应进程的附加群组id
    size_t nr_supp_gids; //该service所隶属的附件组的数目
    char *seclabel; //存放selinux所需要的security context
    struct socketinfo *sockets;    struct svcenvinfo *envvars;

    struct action onrestart;  /* Actions to execute on restart. */
    
    /* keycodes for triggering this service via /dev/keychord */
    int *keycodes;"queue_property_triggers"
    int nkeycodes;
    int keychord_id;

    int ioprio_class;
    int ioprio_pri;
    int nargs; //对应service语句传入的参数数目
    /* "MUST BE AT THE END OF THE STRUCT" */
    char *args[1]; //存放service语句实际传入的参数,其长度将会被修正为nargs+1
}; /*     ^-------'args' MUST be at the end of this struct! */

解析完毕后,构造出如下所示的数据结构(示意图仅画链表仅绘制两个节点)"queue_property_triggers"



一个比较奇怪的地方在于,为什么在struct service中为什么出现了struct action?这与service的onrestart属性有关,该属性比较特殊,在init.rc存在如下service:
service servicemanager /system/bin/servicemanager
    class core
    user system
    group system
    critical
    onrestart restart healthd
    onrestart restart zygote
    onrestart restart media
    onrestart restart surfaceflinger
    onrestart restart drm
onrestart属性后必须跟restart关键字,随后必须再跟一个service名称。
这段含义是定义一个名为servicemanager的service,对应的可执行程序为/system/bin/servicemanager,其多个option则设定servicemanager进程退出时,重启healthd、zygote、media、surfaceflinger、drm等service。
每个service均对应一个可执行程序,类似与一个Actions中的command,多条onrestart语句即多个command,可以认为一个service似乎隐含一个Actions,因此在struct service中包含了一个struct action,从而代码复用。

每个属性(option)由struct service中flags的一位表示,flags各个位含义如下(由于英文比较直观,不具体翻译了)
//init.h
#define SVC_DISABLED    0x01  /* do not autostart with class */
#define SVC_ONESHOT     0x02  /* do not restart on exit */
#define SVC_RUNNING     0x04  /* currently active */
#define SVC_RESTARTING  0x08  /* waiting to restart */
#define SVC_CONSOLE     0x10  /* requires console */
#define SVC_CRITICAL    0x20  /* will reboot into recovery if keeps crashing */
#define SVC_RESET       0x40  /* Use when stopping a process, but not disabling
                                 so it can be restarted with its class */
#define SVC_RC_DISABLED 0x80  /* Remember if the disabled flag was set in the rc script */
#define SVC_RESTART     0x100 /* Use to safely restart (stop, wait, start) a service */
#define SVC_DISABLED_START 0x200 /* a start was requested but it was disabled at the time */

至此函数init_parse_config_file("/init.rc")核心功能介绍完毕,其具体代码就不赘述了。感兴趣的代码可以深入分析init.rc解析引擎的实现,非常有意思。
再强调一下,该函数执行在解析init启动脚本后,只是针对Actions和service创建数据结构,并分别添加到全局链表action_list与service_list中,仅此而已,并没有执行任何一条Actions command,或是启动任何一个service进程。此时action_queue还未添加任何有效节点。

继续分析代码init.c随后的代码。
init.c main函数代码
    action_for_each_trigger("early-init", action_add_queue_tail);

    queue_builtin_action(wait_for_coldboot_done_action, "wait_for_coldboot_done");
    queue_builtin_action(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_lin一部分在ux_rng");
    queue_builtin_action(keychord_init_action, "keychord_init");
    queue_builtin_action(console_init_action, "console_init");

    /* execute all the boot actions to get us started */
    action_for_each_trigger("init", action_add_queue_tail);

    /* skip mounting filesystems in charger mode */
    if (!is_charger) {
        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");

    if (is_charger) {
        action_for_each_trigger("charger", 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
    queue_builtin_action(bootchart_init_action, "bootchart_init");
#endif

void action_for_each_trigger(const char *trigger, void (*func)(struct action *act))
该函数利用字符串trigger从从action_list中查找特定Actions,为每个符合条件的Actions执行action_add_queue_tail函数,也就是说将action_list中所有触发器为trigger的Actions添加到action_queue中。

void queue_builtin_action(int (*func)(int nargs, char **args), char *name)
该函数完成两个操作:
1)构造一个触发器为name的struct action结构体,并创建一个struct command,对应函数为行参func
2)将struct action添加到action_queue链表末尾。

从名字上来看action_queue就是Actions队列,而队列具有FIFO特性。事实也是如此,action_queue可以用于控制Actions执行的顺序。

上述代码结束后,action_queue链表最终具有如下形式,每个链表都是struct action数据结构,各节点通过struct action中的qlist变量彼此连接。

白色节点来自init启动脚本,橘红色节点则有函数queue_builtin_action创建。

现在万事具备,只欠东风。接下来就是如何执行这些Actions了。
init.c main
    for(;;) {
        execute_one_command();
        ...
    }

execute_one_command函数分析
概括的说,这个函数每次从action_queue开头取出一个Actions,同时移除对应节点,依次执行每个command。由与main函数中for循环语句的存在,最终所有的action_queue中所有Actions都会被执行。大致执行流程如此。

简要总结下:init进程的逻辑时,任何一个Actions想要被执行,只要把自己放到action_queue中,然后在init进程的for循环中就会在之后的某个时间被执行。

细心的读者已经发现,为什么action_queue中的Actions如此之少(请参考本文前面介绍Actions时),至少“post-fs”、“post-fs-data”、“boot”,以及"property:<name>=<value>”等Actions怎么没有?

这是因为init进程耍了花招,它把这部分Actions的触发放到了init.rc里,由Actions的一条特殊command: "trigger"触发。请注意,该trigger与Actions的名字(也称为trigger)不同。
见init.rc
on late-init
    trigger early-fs
    trigger fs
    trigger post-fs
    trigger post-fs-data

    # Load properties from /system/ + /factory after fs mount. Place
    # this in another action so that the load will be scheduled after the prior
    # issued fs triggers have completed.
    trigger load_all_props_action

    # Remove a file to wake up anything waiting for firmware.
    trigger firmware_mounts_complete

    trigger early-boot
    trigger boot

看到这里,先大胆猜测当init进程执行到“late-init” Actions时,对于每条trigger语句,取出后面所跟的字符串,从action_list(“妈蛋,终于想起我来了”)中找出该Actions对应的struct action结构,添加到action_queue中。快去看看代码确定一下是否如此。怎么找到command对应代码?前面提到init启动脚本所有关键字都keyword.h中,
//keyword.h
//-------------
    KEYWORD(trigger,     COMMAND, 1, do_trigger)
//builtins.c
//-------------
int do_trigger(int nargs, char **args)
{
    action_for_each_trigger(args[1], action_add_queue_tail);
    return 0;
}

bingo!原来trigger命令对应的函数do_trigger中再次调用了action_for_each_trigger,可见之前的猜测正确!

至于"property:<name>=<value>”类型的Actions由于需要在属性条件满足时被执行,在android4.4的init的实现中对这类Actions的处理比较特殊,有两种方式:
(1) 通过action_queue,配合execute_one_command处理
参考上面action_queue链表图,在main函数中使用queue_builtin_action创建了一个特殊的Actions:"queue_property_triggers",该Actions内只有一个command,对应函数为queue_property_triggers_action,代码如下:
static int queue_property_triggers_action(int nargs, char **args)
{
    queue_all_property_triggers();
    /* enable property triggers */
    property_triggers_enabled = 1;
    return 0;
}
void queue_all_property_triggers()
{
    struct listnode *node;
    struct action *act;
    list_for_each(node, &action_list) {
        act = node_to_item(node, struct action, alist);
        if (!strncmp(act->name, "property:", strlen("property:"))) {
            /* parse property name and value
               syntax is property:<name>=<value> */
            const char* name = act->name + strlen("property:");
            const char* equals = strchr(name, '=');
            if (equals) {
                char prop_name[PROP_NAME_MAX + 1];
                char value[PROP_VALUE_MAX];新浪微博
                int length = equals - name;
                if (length > PROP_NAME_MAX) {
                    ERROR("property name too long in trigger %s", act->name);
                } else {
                    int ret;
                    memcpy(prop_name, name, length);
                    prop_name[length] = 0;

                    /* does the property exist, and match the trigger value? */
                    ret = property_get(prop_name, value);
                    if (ret > 0 && (!strcmp(equals + 1, value) ||
                                    !strcmp(equals + 1, "*"))) {
                        action_add_queue_tail(act);
                    }
                }
            }
        }
    }
}
可见queue_all_property_triggers函数中会检查从action_list中查找所有property型的Actions,并判断其属性条件是否满足,若满足则使用action_add_queue_tail(act)将其添加到action_queue中。

仔细考虑一下,这种方式并不能保证所有property型的Actions都能在属性满足后被触发执行,参考action_queue链表图,这种方式仅仅能保证在"queue_property_triggers"之前的Actions执行中所设置的属性。设想这种情况,在init.rc添加某个Actions,希望可以在Android命令行终端中设置属性(android的set_property命令可以设置android属性),从而触发某个动作。仅仅通过action_queue配合execute_one_command是难以优雅实现的,所以init进程使用了第二种方式。
思考:非优雅的实现最简单方式,只要在for循环中定时轮询属性,但是延时间隔多少合适?若是间隔太短,则将会相当浪费CPU,若是间隔太长,则会导致设置某个属性到执行其对应Actions的时间过长。优雅的方式可以利用进程见通信机制避免CPU被浪费,并能保证响应的及时性。

(2) 借助进程间通信方式实现
首先细化init.c main函数中for循环代码,大致如下:
int main(int argc, char* argv[])
{
    ....
    for(;;) {
        execute_one_command();
        ....
        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();
                ...
            }
        }
    }
}

当某个程序(进程)调用property_set(libcutils库)来自设置属性,就会给init进程发送一个消息(通过Unix domain socket),最终init接收到整个消息后,会调用
handle_property_set_fd() -> property_set(来自init/property_service.c)->  property_changed() -> queue_property_triggers()->action_add_queue_tail
在queue_property_triggers函数中从全局action_list中匹配 property:<name>=<value>类型的Actions,如果属性数值满足,则将该Actions加入到action-queue中,这样该Actions中的command将会在之后的execute_one_command()被调用。

在本文中涉及很多Android属性的操作,笔者将在文章《Android init源代码分析(3)属性系统》进一步分析Android的属性系统。
此外还有些问题需要解决:
(1). service将如何执行,并且service存在多种属性,当包含restart属性时,init进程是如何重启的?
(2). for循环中execute_one_command之后的大量代码的含义?

第一个问题将在文章《Android init源代码分析(4)service的处理》中具体分析。至于for循环中其他代码,将分散在init源代码分析(3)与(4)这两篇文章中。

本文由prife原创,转载请注明出处。博客地址: blog.csdn.net/prife ,豆瓣 prife,weibo prife

你可能感兴趣的:(Android init源代码分析(2)init.rc解析)