@@ -211,7 +211,7 @@ The HDF-based driver development involves driver implementation, write of the dr
>
> - If you need to set **uid** and **gid** to **system** or **root** due to service requirements, contact security experts for review.
>
> - The process UIDs are configured in **base/startup/init_lite/services/etc/passwd**, and the process GIDs are configured in **base/startup/init_lite/services/etc/group**. For details, see [Adding a System Service User Group]( https://gitee.com/openharmony/startup_init_lite/wikis).
> - The process UIDs are configured in **base/startup/init/services/etc/passwd**, and the process GIDs are configured in **base/startup/init/services/etc/group**. For details, see [Adding a System Service User Group]( https://gitee.com/openharmony/startup_init/wikis).
>
> - The **caps** value is in the caps = ["xxx"] format. To configure **CAP_DAC_OVERRIDE**, set this parameter to **caps = ["DAC_OVERRIDE"]**. Do not set it to **caps = ["CAP_DAC_OVERRIDE"]**.
2. For case 2, correctly configure **caps** by referring to the definition of the **capStrCapNum** data structure in **base/startup/init_lite/services/init/init_capability.c**.
2. For case 2, correctly configure **caps** by referring to the definition of the **capStrCapNum** data structure in **base/startup/init/services/init/init_capability.c**.
### Sandbox Not Enabled
...
...
@@ -175,7 +175,7 @@ None.
**Solution**
Set **const.sandbox** to **enable** in **base/startup/init_lite/services/etc/param/ohos.para**. For details, see [Sandbox Management](../subsystems/subsys-boot-init-sandbox.md).
Set **const.sandbox** to **enable** in **base/startup/init/services/etc/param/ohos.para**. For details, see [Sandbox Management](../subsystems/subsys-boot-init-sandbox.md).
@@ -69,7 +69,7 @@ Based on the preceding process, the recommended verification procedure is as fol
Create a root file system image **rootfs.img** by following instructions in [Building Procedures](../subsystems/subsys-build-all.md). As shown in the preceding figure, the startup process is closely related to the product configuration. You need to complete the following configuration when creating **rootfs.img**:
- Component configuration
In the product component configuration file ***vendor*/{*company*}/{*product*}/config.json**, configure the **init_lite** component of the startup subsystem and the **linux_4_1_9** component of the kernel subsystem.
In the product component configuration file ***vendor*/{*company*}/{*product*}/config.json**, configure the **init** component of the startup subsystem and the **linux_4_1_9** component of the kernel subsystem.
- System service configuration
Modify the system service configuration file ***vendor*/{*company*}/{*product*}/init_configs/init_xxx.cfg** to start the shell service.
@@ -443,7 +443,7 @@ To adapt `OpenHarmony` subsystems, you only need to add related subsystems and c
#### Startup Subsystem Adaptation
For the startup subsystem, adapt the `bootstrap_lite`, `syspara_lite`, `appspawn_lite`, and `init_lite` components. Add the corresponding configuration items to the `vendor/bearpi/bearpi_hm_micro/config.json` file, as shown below:
For the startup subsystem, adapt the `bootstrap_lite`, `syspara_lite`, `appspawn_lite`, and `init` components. Add the corresponding configuration items to the `vendor/bearpi/bearpi_hm_micro/config.json` file, as shown below:
```
{
...
...
@@ -452,7 +452,7 @@ For the startup subsystem, adapt the `bootstrap_lite`, `syspara_lite`, `appspawn
@@ -158,7 +158,7 @@ Now start build, and check whether the kernel image is generated as expected.
When porting a new chip platform, you need to add the **/vendor/etc/init/init.{hardware}.cfg** file that contains the platform-level initialization configuration. This file is used to implement platform-level initialization, for example, installing the ko driver and configuring information on the related **/proc** nodes.
The code of the init process is stored in the **//base/startup/init_lite** directory. This process is the first process in the system and does not depend on other processes.
The code of the init process is stored in the **//base/startup/init** directory. This process is the first process in the system and does not depend on other processes.
For details about how to develop the initialization configuration file, see [Startup](../subsystems/subsys-boot-overview.md).
Mounts devices. Every two parameters must be separated by only one space. <br>For details about <strong>flags</strong>, see the <strong>mountFlagMap[]</strong> array of the <strong>mountFlagMap</strong> function in <strong>base/startup/init_lite/services/init/init_common_cmds.c</strong>. The <strong>data</strong> field is optional.
Mounts devices. Every two parameters must be separated by only one space. <br>For details about <strong>flags</strong>, see the <strong>mountFlagMap[]</strong> array of the <strong>mountFlagMap</strong> function in <strong>base/startup/init/services/init/init_common_cmds.c</strong>. The <strong>data</strong> field is optional.
Sets resource usage restrictions. <br>For details, see the <strong>resource[]</strong> array of the <strong>DoSetrlimit</strong> function in <strong>base/startup/init_lite/services/init/init_common_cmds.c</strong>.
Sets resource usage restrictions. <br>For details, see the <strong>resource[]</strong> array of the <strong>DoSetrlimit</strong> function in <strong>base/startup/init/services/init/init_common_cmds.c</strong>.
@@ -247,16 +247,16 @@ You can set specific system parameters as needed to meet your service demand.
On a standard system, use the <strong>ohos_prebuilt_para</strong> template to install the configuration file to the <strong>/etc/param/</strong> directory. The following is an example of the GN script:
@@ -265,24 +265,24 @@ You can set specific system parameters as needed to meet your service demand.
On a small system, run the <strong>copy</strong> command to copy the corresponding system parameter definition file to the <strong>system/etc/param</strong> directory.
@@ -39,7 +39,7 @@ The startup subsystem is responsible for starting key system processes and servi
| base/startup/appspawn_lite | appspawn module of the Lite edition for spawning application processes. It receives Ability Manager Service (AMS) messages via IPC, parses the messages, starts application processes based on the parsing result, and grants permissions to them. | Platforms using the LiteOS Cortex-A kernel |
| base/startup/appspawn_standard | appspawn module of the Standard version for spawning application processes. It receives Ability Manager Service (AMS) messages via IPC, parses the messages, starts application processes based on the parsing result, and grants permissions to them. | Platforms using the Linux kernel |
| base/startup/bootstrap_lite | bootstrap module for starting all services except core system services. | Platforms using the LiteOS Cortex-M kernel |
| base/startup/init_lite | init_lite module for implementing the init process, which is the first user-space process loaded after the kernel is initialized. Upon startup, the process parses the configuration file in **/etc/init.cfg**. Based on the parsing result, the process then starts other key system processes and grants required permissions to them. | Platforms using the LiteOS Cortex-A or Linux kernel |
| base/startup/init | init module for implementing the init process, which is the first user-space process loaded after the kernel is initialized. Upon startup, the process parses the configuration file in **/etc/init.cfg**. Based on the parsing result, the process then starts other key system processes and grants required permissions to them. | Platforms using the LiteOS Cortex-A or Linux kernel |
| base/startup/syspara_lite | syspara module that provides APIs to obtain device information, including the product name, brand name, category name, and manufacturer name. | All platforms |
...
...
@@ -55,12 +55,12 @@ base/startup/
├── appspawn_lite # appspawn module for the mini system
