加入CODE CHINA

· 不限速    · 不限空间    · 不限人数    · 私仓免费

免费加入
    README.md

    init_lite

    Introduction

    The init_lite module starts system service processes from the time the kernel loads the first user-space process to the time the first application is started. In addition to loading key system processes, the module needs to configure their permissions during the startup and keep the specified process alive after sub-processes are started. If a process exits abnormally, the module needs to restart it, and to perform system reset for a special process.

    Directory Structure

    base/startup/init_lite/             # init_lite module
    ├── LICENSE
    └── services
        ├── include                  # Header files for the init_lite module
        ├── src                      # Source files for the init_lite module
        └── test                     # Source files of the test cases for the init_lite module
            └── unittest
    vendor
    └──huawei
            └──camera
                    └──init_configs  # init_lite configuration files (in JSON format, and deployed in /etc/init.cfg after image burning)

    Constraints

    Currently, the init_lite module applies only to small-system devices (reference memory ≥ 1 MB), for example, Hi3516D V300 and Hi3518E V300.

    Usage

    init divides the system startup into three phases:

    pre-init: operations required before system services are started, for example, mounting a file system, creating a folder, and modifying permissions

    init: operations required for starting system services.

    post-init: operations required after system services are started.

    In the init.cfg file, each of the preceding phases is represented by a job, which corresponds to a command set. The init_lite module initializes the system by executing the commands in each job in sequence. Jobs are executed in the following sequence: pre-init > init > post-init. All jobs are stored in the jobs array in the init.cfg file.

    In addition to the jobs array, the init.cfg file also provides a services array, which is used to store the names, executable file paths, permissions, and other attribute information of the key system services that need to be started by the init process.

    The file is stored in /vendor/hisilicon/hispark_aries/init_configs/ under /etc/. It is in JSON format, and its size cannot exceed 100 KB.

    The format and content of the init.cfg file are as follows:

    {
        "jobs" : [{
                "name" : "pre-init",
                "cmds" : [
                    "mkdir /testdir",
                    "chmod 0700 /testdir",
                    "chown 99 99 /testdir",
                    "mkdir /testdir2",
                    "mount vfat /dev/mmcblk0p0 /testdir2 noexec nosuid"
                ]
            }, {
                "name" : "init",
                "cmds" : [
                    "start service1",
                    "start service2"
                 ]
            }, {
                 "name" : "post-init",
                 "cmds" : []
            }
        ],
        "services" : [{
                "name" : "service1",
                "path" : "/bin/process1",
                "uid" : 1,
                "gid" : 1,
                "once" : 0,
                "importance" : 1,
                "caps" : [0, 1, 2, 5]
        }, {
                "name" : "service2",
                "path" : "/bin/process2",
                "uid" : 2,
                "gid" : 2,
                "once" : 1,
                "importance" : 0,
                "caps" : []
            }
        ]
    }

    Table 1 Job description

    Job Name

    Description

    pre-init

    Job that is executed first. Operations (for example, creating a folder) required before the process startup are executed in this job.

    init

    Job that is executed in between. Operations (for example, service startup) are executed in this job.

    post-init

    Job that is finally executed. Operations (for example, mounting the device after the driver initialization) required after the process startup are executed in this job.

    A single job can hold a maximum of 30 commands (only start, mkdir, chmod, chown, mount, and loadcfg are supported currently). The command name and parameters (128 bytes or less) must be separated by only one space.

    Table 2 Commands supported by a job

    Command

    Format and Example

    Description

    mkdir

    mkdir target folder

    Example: mkdir /storage/myDirectory

    Creates a folder. mkdir and the target folder must be separated by only one space.

    chmod

    chmod permission target

    Examples: chmod 0600 /storage/myFile.txt

    chmod 0750 /storage/myDir

    Modifies the permission, which must be in the 0xxx format. chmod, permission, and target must be separated by only one space.

    chown

    chown uid gid target

    Example: chown 900 800 /storage/myDir

    chown 100 100 /storage/myFile.txt

    Modifies the owner group. chown, uid, gid, and target must be separated by only one space.

    mount

    mount fileSystemType src dst flags data

    Example: mount vfat /dev/mmcblk0 /sdc rw,umask=000

    mount jffs2 /dev/mtdblock3 /storage nosuid

    Mounts devices. Every two parameters must be separated by only one space. Currently, supported flags include nodev, noexec, nosuid, rdonly, and optionally data.

    start

    start serviceName

    Example: start foundation

    start shell

    Starts services. serviceName must be contained in the services array.

    loadcfg

    loadcfg filePath

    Example: loadcfg /patch/fstab.cfg

    Loads other .cfg files. The maximum size of the target file (only /patch/fstab.cfg supported currently) is 50 KB. Each line in the /patch/fstab.cfg file is a command. The command types and formats must comply with their respective requirements mentioned in this table. A maximum of 20 commands are allowed.

    Table 3 Elements in the services array

    Field

    Description

    name

    Name of the current service. The value cannot be empty and can contain a maximum of 32 bytes.

    path

    Full path (including parameters) of the executable file for the current service. This is an array. Ensure that the first element is the path of the executable file, the maximum number of elements is 20, and each element is a string that contains a maximum of 64 bytes.

    uid

    User ID (UID) of the current service process.

    gid

    Group ID (GID) of the current service process.

    once

    Whether the current service process is a one-off process.

    1: The current service process is a one-off process. If the process exits, the init process does not restart it.

    0: The current service process is not a one-off process. If the process exits, the init process restarts it upon receiving the SIGCHLD signal.

    Note: If a non-one-off process exits for five consecutive times within four minutes, the init process will no longer restart it at the fifth exit.

    importance

    Whether the current service process is a key system process.

    0: The current service process is not a key system process. If it exits, the init process does not reset or restart the system.

    1: The current service process is a key system process. If it exits, the init process resets and restarts the system.

    caps

    Capabilities required by the current service. They are evaluated based on the capabilities supported by the security subsystem and configured in accordance with the principle of least permission. Currently, a maximum of 100 values can be configured.

    Repositories Involved

    Startup subsystem

    startup_syspara_lite

    startup_appspawn_lite

    startup_bootstrap_lite

    startup_init_lite

    项目简介

    启动模块init进程

    发行版本

    当前项目没有发行版本

    贡献者 15

    全部贡献者

    开发语言

    • C 91.0 %
    • C++ 9.0 %