diff --git a/en/device-dev/subsystems/subsys-boot-init.md b/en/device-dev/subsystems/subsys-boot-init.md
index 486534234a0ee565d510c42943cb8cfe9232b98b..403fe4bc793e4aca2832481c19cb0277f9dc5b4e 100644
--- a/en/device-dev/subsystems/subsys-boot-init.md
+++ b/en/device-dev/subsystems/subsys-boot-init.md
@@ -1,24 +1,28 @@
# init Module
-The init module starts key service processes during system startup. If you would like to add a system service that automatically starts upon system startup, you can add the service to the **init.cfg** file.
+- [Configuration File](#section56901555917)
+- [Development Guidelines](#section15371931131117)
+- [Development Example](#section173413113565)
-## Configuration File
+The init module starts key service processes during system startup. If you would like to add a system service that automatically starts upon system startup, you can add the service to the **init.cfg** file.
-The configuration file **init.cfg** of the init module contains service names, executable file paths, permissions, and other information of all key system services that need to be started by the init process. The file is stored in the code repository **vendor/huawei/camera/init\_configs/**, and can be found in **/etc/** after burning is complete. The file is in JSON format, and its size cannot exceed 100 KB.
+## Configuration File of the init Module
-After the init process starts, it reads the **/etc/init.cfg** file, parses the content in JSON format, and loads system services in sequence based on the parsing result.
+The configuration file **init.cfg** of the init module contains service names, executable file paths, permissions, and other information of all key system services that need to be started by the init process. The file is stored in the code repository **vendor/huawei/camera/init\_configs/**, and can be found in **/etc/** after burning is complete. The file is in JSON format, and its size cannot exceed 100 KB.
-## How to Develop
+After the init process starts, it reads the **/etc/init.cfg** file, parses the content in JSON format, and loads system services in sequence based on the parsing result.
-1. Configure the **jobs** array.
+## Development Guidelines
+
+1. Configure the **jobs** array.
The init module completes the system startup in 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.
+ - **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.
- Each of the preceding phases is represented by a job, which corresponds to a command set. The init module initializes the system by executing the commands in each job in sequence. pre-init job is executed first, then init job, and finally post-init job.
+ Each of the preceding phases is represented by a job, which corresponds to a command set. The init module initializes the system by executing the commands in each job in sequence. The **pre-init** job is executed first, then the **init** job, and finally the **post-init** job.
```
"jobs" : [{
@@ -43,10 +47,10 @@ After the init process starts, it reads the **/etc/init.cfg** file, parses the
],
```
- **Table 1** Job execution
+ **Table 1** Job description
-
Job Name
+ Job
|
Description
|
@@ -54,7 +58,7 @@ After the init process starts, it reads the **/etc/init.cfg** file, parses the
pre-init
|
- Job that is executed first. Operations (for example, creating a folder) required before the process startup are executed in this job.
+ | Job that is executed first. Operations (for example, creating a folder) required before the process startup are executed in the pre-init job.
|
init
@@ -70,9 +74,9 @@ After the init process starts, it reads the **/etc/init.cfg** file, parses the
|
- A single job can hold a maximum of 30 commands \(only **start/mkdir/chmod/chown/mount/loadcfg** supported currently\). The command name and parameters \(128 bytes or less\) must be separated by only one space.
+ 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
+ **Table 2** Commands supported by a job
Command
@@ -85,60 +89,60 @@ After the init process starts, it reads the **/etc/init.cfg** file, parses the
|
mkdir
|
- mkdir target folder
+ | mkdir target folder
Example: mkdir /storage/myDirectory
|
- Creates a folder. mkdir and the target folder must be separated by only one space.
+ | 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 permission target
+ Example: 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.
+ | 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
+ | 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.
+ | Modifies the owner group. chown, uid, gid, and target must be separated by only one space.
|
mount
|
- mount fileSystemType src dst flags data
+ | 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.
+ | 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
+ | start serviceName
Example: start foundation
start shell
|
- Starts services. serviceName must be contained in the services array.
+ | Starts services. serviceName must be contained in the services array.
|
loadcfg
|
- loadcfg filePath
+ | 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.
+ | 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.
|
-2. Configure the **services** array, which holds all system services \(a maximum of 100\) that need to be started by the init process.
+2. Configure the services array, which holds all system services (a maximum of 100) that need to be started by the init process.
```
"services" : [{
@@ -161,10 +165,10 @@ After the init process starts, it reads the **/etc/init.cfg** file, parses the
]
```
- **Table 3** Elements in the **services** array
+ **Table 3** Fields in the services array
- Element
+ Field
|
Description
|
@@ -193,16 +197,16 @@ After the init process starts, it reads the **/etc/init.cfg** file, parses the
---|
once
|
Whether the current service process is a one-off process.
- 1: The current service 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.
+ 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.
+ 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
@@ -214,7 +218,7 @@ After the init process starts, it reads the **/etc/init.cfg** file, parses the
|
-## How to Use
+## Development Example
The following uses the MySystemApp service as an example to illustrate how to use the init process to start a system service.
@@ -252,7 +256,6 @@ The following uses the MySystemApp service as an example to illustrate how to us
After the configuration is complete, compile the package to burn the board.
-1. Run the **task -a** command for liteos-a or **ps** for Linux to check whether the MySystemApp service process is started.
-2. Run the **kill** command to kill the MySystemApp process, and then verify that the process will be restarted.
-3. Run the **kill** command to kill the MySystemApp process, and then verify that the development board will not be restarted.
-
+1. Run the **task -a** command for liteos-a or **ps** for Linux to check whether the MySystemApp service process is started.
+2. Run the **kill** command to kill the MySystemApp process, and then verify that the process will be restarted.
+3. Run the **kill** command to kill the MySystemApp process, and then verify that the development board will not be restarted.
|
---|
|
---|