Startup

• Limitations and Constraints

The startup subsystem provides the functions of starting key system processes after the kernel is started and before applications are started, and restoring the system to factory settings. The subsystem consists of the following modules:

• init module

  This module corresponds to the init process, which is the first user-space process started after the kernel is initialized. Upon startup, the init process reads and parses the configuration file init.cfg. Based on the parsing result, the init module executes the commands listed in Table 2 in init Module and starts the key system service processes in sequence with corresponding permissions granted.

• appspawn module

  This module spawns application processes upon receiving commands from the application framework, configures permissions for new processes, and calls the entry function of the application framework.

• bootstrap module

  This module provides entry identifiers for starting services and features. When the Samgr is started, the entry function identified by boostrap is called and system services are started.

• syspara module

  This module provides APIs for obtaining device information, such as the product name, brand name, and manufacturer name, based on the OpenHarmony Product Compatibility Specifications (PCS). It also provides APIs for setting and obtaining system parameters.

Limitations and Constraints

The directories of startup subsystem are applicable to different platforms.

Table 1 Directories and applicable platforms of the startup subsystem

• init module

  • After being burnt to the development board, the configuration file init.cfg changes to read-only. If you want to modify the file, you must repack and burn the rootfs image again.
  • The configuration file init.cfg must be in JSON format.

• bootstrap module: The zInit code needs to be configured in the link script.

• syspara module: The SetParameter and GetParameter APIs can only be called by applications whose UID is greater than 1000.