subsys-boot-init-sub-unit.md

# Component-based Startup
## Overview
### Function Introduction
This subsystem provides the following functions:
- Builds four basic component images and provides component-based directories, including:
  - System component: **system**
  - Common product configuration component: **sys_prod**
  - Chipset component: **chipset**
  - Hardware configuration component: **chip_prod**
- Ensures that system parameters and startup scripts can be scanned and initialized by component priority.
- Independently compiles and builds the **system** component and **chipset** component.

### Basic Concepts
- Basic Components

   **system**: serves as the file system mount point, and functions as a platform service irrelevant to the chipset and hardware.
   **sys_prod**: extends and customizes capabilities of the **system** component, bears product-level differentiated capabilities, and stores product-related configuration files.
   **chipset**: serves as the file system mount point, and offers unified hardware abstraction services for the **system** component. Same chipset platforms can use the same **chipset** component.
   **chip_prod**: offers specific hardware capabilities of a peripheral board and product-level differentiated hardware configurations, as well as chipset-related configuration files.

- Component-based compilation and building

  Use **target_cpu** to specify the instruction set of the **system** component. Use **inherit** to inherit the common component set such as **base**, **headless**, and **rich**. Use **subsystems** to define more components for a specific product type.

- System parameters and startup scripts scanned and initialized by component priority

  System parameters and startup scripts include the CFG configuration file, PARAM file, sandbox JSON configuration file, and module plugin library file of a service. The following are related files that are in ascending order in terms of priority: **/system**, **/chipset**, **/sys_prod**, and **/chip_prod**. A file with a higher priority replaces and updates the configuration file with a lower priority.


### Constraints
Standard and small systems support component-based compilation and building. System parameters and startup scripts are scanned and initialized by component priority.

## How to Develop
### When to Use
Component-based startup enables vendors and hardware platforms to quickly develop products through modular combination. The following uses RK3568 as an example to illustrate component-based startup in detail.

### Building and Compiling RK3568 Based on Components
The **//vendor/hihope/rk3568/config.json** configuration file implements components required for building the product:

        {
          "product_name": "rk3568",
          "device_company": "rockchip",
          ...
          "target_cpu": "arm",
          ...
          "inherit": [ "productdefine/common/inherit/rich.json", "productdefine/common/inherit/chipset_common.json" ],
          "subsystems": [
            {
              "subsystem": "security",
              "components": [
                {
                  "component": "selinux",
                  "features": []
                }
              ]
            }
          ...
        }

The example above indicates the product name, chipset vendor, supported instruction set, and more. **inherit** indicates the dependent common components, and **subsystems** indicates other components.
The following illustrates the configuration of the **system** component in the **//productdefine/common/inherit/rich.json** file. The **system** component can also include **base.json** (list of minimal components that all products must contain) and **headless.json** (list of minimal components with which products having no UI allow for application installation and management).

    {
      "version": "3.0",
      "subsystems": [
      {
        "subsystem": "arkui",
        "components": [
          {
            "component": "ace_engine",
            "features": []
          },
          {
            "component": "napi",
            "features": []
          }
        ]
      },
      {
        "subsystem": "account",
        "components": [
          {
            "component": "os_account",
            "features": []
          }
        ]
      },
      ...
    }

### Scanning and Initializing System Parameters by Priority
The following are CFG files of a service, which are in ascending order in terms of priority: **/system/etc**, **/system/etc/init**, and **/chipset/etc**. A file with a higher priority replaces and updates the configuration file with a lower priority. The following uses **/system/etc/init/camera_service.cfg** as an example:

      {
        "services" : [{
            "name" : "camera_service",
            "path" : ["/system/bin/sa_main", "/system/profile/camera_service.xml"],
            "uid" : "cameraserver",
            "gid" : ["system", "shell"],
            "secon" : "u:r:camera_service:s0",
            "permission" : ["ohos.permission.GET_SENSITIVE_PERMISSIONS"],
            "permission_acls" : ["ohos.permission.GET_SENSITIVE_PERMISSIONS"]
        }]
      }  

**/chipset/etc/camera_B_service.cfg** exists at the same time.

       {
        "services" : [{
            "name" : "camera_service",
            "path" : ["/system/bin/sa_main", "/system/profile/camera_B_service.xml"],
            "uid" : "cameraserver",
            "gid" : ["system", "shell"],
            "secon" : "u:r:camera_service:s0",
            "permission" : ["ohos.permission.GET_SENSITIVE_PERMISSIONS"],
            "permission_acls" : ["ohos.permission.GET_SENSITIVE_PERMISSIONS"],
            "disabled" : 1
        }]
      }  

Based on the priority requirement, the **path** attribute of the **camera_service** service will be replaced by **["/system/bin/sa_main", "/system/profile/camera_B_service.xml"]** that has a higher priority, and the **disabled** attribute is added.