如何優雅地參與開源貢獻，向頂級開源項目提交PR（Pull Request），跟著大咖30分鐘成為OpenAtom OpenHarmony（簡稱“OpenHarmony”）Contributor。戰“碼”先鋒直播間第五期，邀請華為終端BG OpenHarmony基礎軟件SIG/技術專家Handy為大家分享《OpenHarmony設備啟動過程與模塊化開發實踐》。分享主要分為四個部分：OpenHarmony設備啟動的基本過程，基于qemu平臺的最小系統介紹，init進程的設計理念，以及如何基于qemu進行init的擴展模塊開發。

● 第一部分，是從宏觀上了解OpenHarmony在設備上的啟動引導過程，了解操作系統啟動引導的基本概念和相關術語。

● 第二部分，介紹基于qemu虛擬機平臺的最小系統，如何在不要開發板的情況下進行OpenHarmony標準系統基礎軟件的開發。

● 第三部分，介紹OpenHarmony第一個用戶態進程init的設計理念。

● 第四部分，介紹如何基于qemu虛擬機平臺進行init的模塊化開發。

1. 設備啟動過程

1.1 OS啟動引導技術概述

在介紹OpenHarmony操作系統啟動引導過程前，Handy老師先回顧了傳統PC行業操作系統的引導過程。上圖是傳統PC硬件和操作系統的大致結構，其中底層的是硬件主板，在主板上板載的firmware將完成主板的自啟；然后掃描存儲設備，包括硬盤、光盤、U盤等；再從存儲設備上識別已安裝的操作系統，最終從這些操作系統上啟動。

在PC環境下，firmware都遵循UEFI標準。UEFI是一個非常復雜的標準，由CPU廠商，PC主板廠商和OS廠商聯合開發，主要包括Win-Tel。該標準詳細定義了固件和操作系統之間的接口，適應了PC硬件的開放式架構，使得不同的操作系統都可以在各個不同廠商的CPU、主板、硬盤、內存上運行。UEFI標準的實現包括EDK2、coreboot、LinuxBoot等。

但在嵌入式系統中，這些標準則相對簡化。因為嵌入式設備不像早期PC一樣可以任意組裝。嵌入式設備就像一體機，SOC、RAM、EMMC、外設以及操作系統等都是在設備出廠時預制好，消費者開箱即用。因此，SOC板載的firmware一般相對簡化，只需要加載到bootloader，操作系統開發人員基本不關心SOC的firmware。

Bootloader是操作系統的直接上游，操作系統需要由Bootloader來加載并運行。在嵌入式系統中，一般都采用uboot。在uboot中可以指定操作系統鏡像在存儲器中的具體位置，這次主要基于u-boot介紹OpenHarmony標準系統的啟動引導過程。

另外還有兩個基本概念：分區表和OS鏡像。分區表是用來把存儲器的存儲區域進行劃分，不同區域存放不同的OS鏡像。

1.2 OpenHarmony啟動引導分區加載過程

上圖為我們指明了OpenHarmony相關的OS鏡像。u-boot首先加載boot.img和ramdisk.img。boot.img是內核鏡像，ramdisk.img是最早的用戶態進程鏡像，其中就包括init進程。通過這兩個OS鏡像，系統可以啟動到最基本的shell，這里還沒有啟動任何業務。

在ramdisk.img的init進程里，會主動掛載system.img和vendor.img，并掃描其中的啟動配置文件，拉起各個進程。system.img和vendor.img是OpenHarmony中各個子系統編譯后產物的集合。

從上圖右側文字我們可以看到，u-boot和OpenHarmony鏡像啟動時都需要知道分區表信息。分區表信息有多種方式傳遞，一般包括GPT分區表，bootargs分區表。圖中示意的是u-boot通過blkdevparts這個bootargs傳遞給內核。內核會根據這些信息創建對應的block設備。同時還有root這個節點，告知內核從哪里掛載根文件系統，從而啟動init。

ramdisk里的init最重要的幾個事件包括：創建并掛載根文件系統，包括tmpfs、dev節點、procfs等。同時，需要掛載system.img和vendor.img，這兩個是啟動過程的必選分區。當前Release版本里是通過ramdisk.img里的required.fstab文件來配置system、vendor分區的掛載參數；最新master版本還支持通過ohos.required_mount.xxx bootargs參數來提供這些掛載參數；具體參考文檔可以參考《啟動子系統概述》（https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/subsystems/subsys-boot-overview.md）。

ramdisk里的init完成system/vendor的掛載后，就開始進入system/vendor系統中，開始第二階段并發啟動的過程。此時，init會掃描/{system,vendor}/etc/init下的各個啟動配置文件，拉起各個子系統的服務，并最終拉起應用。在分區掛載方面，還有一個重要的配置文件/vendor/etc/fstab.{hardware}；這個可以定義更多需要掛載的分區，包括data分區，以及產品擴展的分區。

1.3 OpenHarmony系統進程啟動過程

隨后，Handy老師為我們介紹了進入OpenHarmony系統后，用戶態進程的啟動概況。從上圖中，我們可以把啟動的進程分為以下幾類：

● UHDF類系統進程UHDF類系統進程為系統提供HDI接口，這類進程為系統服務提供芯片無關的硬件訪問接口。這類進程都通過hdf_devmgr管理。

● SA類系統進程SA是OpenHarmony的基礎系統元能力，每個SA是一個獨立的so，根據配置一個或多個SA可以部署到同一個進程中，我們稱這類進程為SA類系統服務。每個SA類系統服務進程都是通過sa_main進程解析配置文件啟動，向sa_mgr服務注冊支持的SA；訪問SA服務時需要先根據SA的ID向sa_mgr獲取該SA的句柄。

● Linux原生系統服務OpenHarmony除了支持SA類和UHDF類系統進程外，也支持啟動Linux原生的系統進程。通過Linux原生系統服務可以快速使用Linux社區已有的成熟能力。

● 應用進程每個應用進程都是從appspawn孵化而來，appspawn預加載了應用運行時需要的資源，主要是ArkUI相關的依賴庫。

init拉起每個進程的方式都是通過配置文件來完成，其格式都是如下所示的JSON格式；每個進程的配置文件安裝到/system/etc/init或/vendor/etc/init目錄下，init會掃描這些配置，按照配置拉起對應的進程。下面我們將結合qemu最小系統來介紹下init的詳細設計。

{   "services" : [{           "name" : "watchdog_service",           "start-mode" : "condition",           "path" : ["/system/bin/watchdog_service", "10", "2"],           "disabled" : 1,           "sandbox" : 0,           "uid" : "watchdog",           "gid" : ["watchdog", "log", "readproc"],           "secon" : "uwatchdog_service:s0"      }  ]}

2. 基于qemu的最小系統

2.1 Why qemu

硬件設備開發人員在開發工作中，需要使用到各種各樣的開發板。每個開發板的連接線纜、接線方式、升級燒寫方式各不相同，且上手門檻高；開發時的便攜性和調試效率等都比較低。特別是init相關的開發調試，修改后還需要整機燒寫。為了能像應用開發者一樣，可以隨時隨地，相對高效且“體面”地開發底層系統服務。于是，構建了基于qemu的OpenHarmony最小系統，希望能讓硬件設備開發人員只需一臺筆記本就可以隨時開發調試底層系統服務。

2.2 關于qemu-arm-linux-min

OpenHarmony的qemu最小系統名稱是qemu-arm-linux-min。從名稱可以看出，它是用qemu模擬的ARM32位運行平臺，使用Linux內核運行的OpenHarmony最小系統部件集合。其部件集合的定義在vendor/ohemu/qemu_arm_linux_min/config.json里，包含約20個部件，主要是系統基礎的啟動、DFX、安全、samgr、軟總線相關的部件。

編譯命令只需要指定qemu-arm-linux-min產品名即可，運行也只需要一個qemu-run.sh命令。詳細的信息可以跳轉到文末的device/qemu/arm_virt虛擬平臺的文檔。

qemu-arm-linux-min的優勢：

● 代碼倉少，只需要96個倉代碼（-g ohos:chipset -m chipsets/qemu.xml），詳細說明參考https://gitee.com/openharmony/manifest。

● 編譯快：只需要編譯5000個文件（完整系統需3萬個）。

● 免燒寫：qemu-run.sh直接運行。

因此，開發者僅需一臺筆記本，就可以隨時隨地寫代碼，輕松為OpenHarmony做貢獻。

2.3 DEMO TIME

了解qemu-arm-linux-min介紹后，Handy老師為我們介紹了如何使用它。

arm_virt網頁上已經比較詳細地介紹了運行虛擬機的準備工作了。前面編譯環境準備以及下載代碼的都是通用的，編譯命令前面也說明了，只需要指定qemu-arm-linux-min即可。運行前，需要先安裝qemu，請下載5.2以上版本的qemu，并對源碼進行編譯。

qemu-run.sh運行腳本有兩個運行模式，普通模式直接啟動，虛擬機只有虛擬磁盤，沒有網絡。-n選項可以創建虛擬網橋，使得虛擬機和主機之間可以通過網絡通信，使用hdc等命令。下面我們演示如何使用qemu-arm-linux-min進行gdb調試。

調試環境如下圖所示：主機上通過qemu-run.sh創建了虛擬網橋，用于與虛擬機通信。同時，為了在虛擬機上訪問源碼進行gdb調試，在主機上啟動了smbd服務。虛擬機的內核默認開啟了cifs模塊，可以掛載主機上的smb共享目錄。

● 使能虛擬機的網絡接口：

# 使能虛擬機網絡接口ifconfig eth0 192.168.100.2# 測試與主機側的網絡連接ping192.168.100.1-t4

● 在虛擬機掛載主機的samba共享目錄：

# 創建掛載點mkdir /mnt/smb# 掛載cifs文件系統mount -t cifs -o username=xxx,password=xxx,vers=2.1      //192.168.100.1/handy /mnt/smb# 可選建立hdc連接hdc_stdtconn192.168.100.2:5555

● 使用gdb：

# gdb在主機samba服務器的tools目錄# 調試代碼在主機samba服務器的ohos目錄
# 運行調試程序/mnt/smb/tools/gdb /mnt/smb/ohos/out/qemu-arm-linux/exe.unstripped/startup/init/gdbtest
# 關聯源碼目錄directory /mnt/smb/ohos/out/qemu-arm-linux
#其它命令：r, bt

arm版的gdb可以從以下網站獲?。?/p>

https://github.com/therealsaumil/static-arm-bins/（需解決網絡問題）

https://gitee.com/stesen/ohos_cross_tools

3. init進程的設計理念

3.1 init進程的模塊劃分

通過前文的介紹，可以知道init進程是系統從內核態向用戶態引導的核心進程；該進程是所有用戶態進程的父進程。

init的模塊劃分如上圖所示，啟動過程大體分為第一階段和第二階段。第一階段用于創建基礎的根文件系統，包括procfs、sysfs、dev設備節點、tmpfs等。第二階段提供了系統參數服務，服務腳本解析能力；然后就進入了腳本配置啟動的過程。

具體配置參考《init啟動引導組件》（https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/subsystems/subsys-boot-init.md）。

這里很重要的部分是init里提供了模塊化引擎，提供了擴展模塊開發的對外API，可以在不改變init框架的基礎上擴展init各個模塊的功能。例如可以擴展腳本配置的命令，擴展服務管理功能，在腳本運行前擴展鉤子執行等。

3.2 init進程的啟動順序與擴展機制說明

上圖是init進程啟動的詳細過程，主要分為三個部分：

● 第一階段如前面描述，完成基礎根文件系統的構建。

● 第二大部分提供了系統參數服務，并且完成了配置腳本的掃描與解析。

● 第三大部分進入了腳本化運行的階段。

第一部分邏輯固定，不提供擴展；第二部分都是native代碼，可以通過開發擴展模塊向紅色擴展點注冊鉤子函數來擴展功能。第三部分通過配置腳本進行擴展，每個系統服務都可以編寫各自的配置文件在指定階段完成相應功能。

3.3 init腳本化啟動過程說明

腳本化啟動過程大體可以分為三個階段：

● pre-init完成腳本化早期工作，包括ueventd、data分區掛載等。

● init階段完成samgr和hdf_devmgr的啟動，這兩個進程是各個SA進程以及HDI服務進程的管理中心，公共依賴需提前啟動。

● post-init階段是各個子系統服務啟動的階段。為了保障整機開機啟動速度，這個階段各個服務都是并行啟動的，服務之間如果有依賴關系，需要進行運行時同步設計。init提供了系統參數服務，可以提供wait和watch機制，輔助各個服務進行同步。

4. init擴展模塊開發示例

init擴展模塊代碼都放在base/startup/init_lite/services/modules目錄下，代碼引用API頭文件定義及插件代碼入口：

#include "init_module_engine.h"
MODULE_CONSTRUCTOR(void){   // 加載插件代碼入口，dlopen此插件庫時自動執行}
MODULE_DESTRUCTOR(void){   // 卸載插件代碼入口，dlclose此插件庫時自動執行}

BUILD.gn編譯腳本依賴及插件安裝目錄：

ohos_shared_library("libinit_example_module") { ... external_deps = [ "init:libinit_module_engine" ] module_install_dir = "lib/init/" ...}

OpenHarmony期待你的加入，與Handy老師一起，深入理解OpenHarmony系統啟動，提PR，輕松踏上設備軟件開發之旅，成為貢獻達人，為OpenHarmony生態發展貢獻力量。

附錄：

啟動恢復子系統概述：

https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/subsystems/subsys-boot-overview.md

qemu ARM Virt 標準系統教程：

https://gitee.com/openharmony/device_qemu/tree/master/arm_virt/linux

qemu-arm-linux-min代碼倉說明：

https://gitee.com/openharmony/manifest

qemu ARM Virt 標準系統教程：

https://gitee.com/openharmony/device_qemu/tree/master/arm_virt/linux

Arm版的gdb可以從以下網站獲?。?/p>

https://github.com/therealsaumil/static-arm-bins/

https://gitee.com/stesen/ohos_cross_tools

init啟動引導組件：

https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/subsystems/subsys-boot-init.md

審核編輯 ：李倩