diff --git a/en/device-dev/subsystems/Readme-EN.md b/en/device-dev/subsystems/Readme-EN.md index 7acc0662535adc30158ecaa188051c0a49645354..a124e6470632802f156c8be1138dcc34ba19510d 100644 --- a/en/device-dev/subsystems/Readme-EN.md +++ b/en/device-dev/subsystems/Readme-EN.md @@ -82,6 +82,8 @@ - [Parameter Management](subsys-boot-init-sysparam.md) - [Sandbox Management](subsys-boot-init-sandbox.md) - [Plug-in Management](subsys-boot-init-plugin.md) + - [Component-based Startup](subsys-boot-init-sub-unit.md) + - [init Run Log Standardization](subsys-boot-init-log.md) - [appspawn Module](subsys-boot-appspawn.md) - [bootstrap Module](subsys-boot-bootstrap.md) - [FAQs](subsys-boot-faqs.md) diff --git a/en/device-dev/subsystems/subsys-boot-init-log.md b/en/device-dev/subsystems/subsys-boot-init-log.md new file mode 100644 index 0000000000000000000000000000000000000000..db7500c6d0442d054fecac560fececac1bb11598 --- /dev/null +++ b/en/device-dev/subsystems/subsys-boot-init-log.md @@ -0,0 +1,75 @@ +# init Run Log Standardization +## Overview +### Introduction +Basic functions of a log include recording key nodes and troubleshooting faults during the init startup process. +- Logs help troubleshoot faults, check the startup duration of each subsystem, command execution duration, and more. + +- Log tags (including **param**, **uevent**, and **module**) for different modules can be viewed. + +- Logs can be printed for key phases, for example, the startup of the first phase, a required partition and its device node, **uevent** creation, service startup, and more. + +- Logs can be printed according to the specified log level. Currently, the following log levels are available: **INIT_DEBUG**, **INIT_INFO**, **INIT_WARN**, **INIT_ERROR**, and **INIT_FATAL**. + +### Basic Concepts + +The implementation of init logs varies according to the OpenHarmony version. +- OpenHarmony standard: The init log is implemented via **dmesg log** of the Linux kernel. +- OpenHarmony LiteOS L1: The init log is implemented via **hilog**. +- OpenHarmony LiteOS L0: The init log is implemented via **printf**. + +### Constraints +None + +## How to Develop +### Use Cases +init logs are mainly used to start modules (like **param**, **ueventd**, and **module**) during init startup, and are used in the open API **begetutils**. + +### Available APIs + +**Table 1** Log APIs +| API | Format and Example | Description | +| ----------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | +| INIT_LOGV | INIT_LOGV("Add %s to job %s", service->name, jobName); | Prints the log of the DEBUG level. | +| INIT_LOGI | INIT_LOGI("Start init first stage."); | Prints the log of the INFO level. | +| INIT_LOGW | INIT_LOGW("initialize signal handler failed"); | Prints the log of the WARN level. | +| INIT_LOGE | INIT_LOGE("Failed to format other opt"); | Prints the log of the ERROR level. | +| INIT_LOGF | INIT_LOGF("Failed to init system"); | Prints the log of the FATAL level. | +| INIT_ERROR_CHECK | INIT_ERROR_CHECK(ctx != NULL, return NULL, "Failed to get cmd args "); | Prints a log and executes **return NULL** when **ctx != NULL** is not true.| +| INIT_INFO_CHECK | INIT_INFO_CHECK(sockopt != NULL, return SERVICE_FAILURE, "Failed to malloc for service %s", service->name); | Prints a log and executes **return SERVICE_FAILURE** when **sockopt != NULL** is not true.| +| INIT_WARNING_CHECK | INIT_WARNING_CHECK(argsCount <= SPACES_CNT_IN_CMD_MAX, argsCount = SPACES_CNT_IN_CMD_MAX, "Too much arguments for command, max number is %d", SPACES_CNT_IN_CMD_MAX); | Prints a log and executes **argsCount = SPACES_CNT_IN_CMD_MAX** when **argsCount <= SPACES_CNT_IN_CMD_MAX** is not true.| +| INIT_CHECK | INIT_CHECK(arg != NULL, return NULL); | Executes **return NULL** when **arg != NULL** is not true. | +| INIT_CHECK_RETURN_VALUE | INIT_CHECK_RETURN_VALUE(errno == 0, -1); | Executes **return -1** when **errno == 0** is not true. | +| INIT_CHECK_ONLY_RETURN | INIT_CHECK_ONLY_RETURN(cmd != NULL); | Executes **return** when **cmd != NULL** is not true. | +| INIT_CHECK_ONLY_ELOG | INIT_CHECK_ONLY_ELOG(execv(argv[0], argv) == 0, "execv %s failed! err %d.", argv[0], errno); | Prints only **log "execv %s failed! err %d."** when **execv(argv[0], argv) == 0** is not true.| + +### Development Example + + 1. Call an API to print the log. + + For example, call **INIT_LOGI("Start init first stage.")** in **//base/startup/init/services/init/standard/init.c** to print the log. + ```c + void SystemPrepare(void) + { + MountBasicFs(); + CreateDeviceNode(); + LogInit(); + // Make sure init logs are always printed to /dev/kmsg. + EnableDevKmsg(); + INIT_LOGI("Start init first stage."); + // Only the OpenHarmony standard system supports + // two stages of init. + // In updater mode, only one stage of init is supported. + if (InUpdaterMode() == 0) { + StartInitSecondStage(); + } + } + ``` + Run **dmesg** to check the printed log **Start init first stage.** + + 2. Set the log level by using the begetctl command. + + The command is **begetctl setloglevel level**, where **level** indicates one of the following log levels: **0** (**INIT_DEBUG**), **1** (**INIT_INFO**), **2** (**INIT_WARN**), **3** (**INIT_ERROR**), and **4** (**INIT_FATAL**). + + After the setting is complete, the level set via **g_logLevel** of init takes effect immediately, and log APIs can print logs only when their log levels are higher than or equal to this level. For example, **begetctl setloglevel 3** sets the log level to **INIT_ERROR**. In this case, only **INIT_LOGE** and **INIT_LOGF** will print logs. + + After the system is restarted, the configured log level will take effect after the **load_persist_params** command in the **init.cfg** file is executed. diff --git a/en/device-dev/subsystems/subsys-boot-init-sub-unit.md b/en/device-dev/subsystems/subsys-boot-init-sub-unit.md new file mode 100644 index 0000000000000000000000000000000000000000..2e1407b9fd8dc6a29e74b91b4c1bc414a7eaae73 --- /dev/null +++ b/en/device-dev/subsystems/subsys-boot-init-sub-unit.md @@ -0,0 +1,121 @@ +# 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.