鴻蒙OS開源代碼精要解讀之——init

作者介紹：

中科創達OpenHarmony研究組

說明：

中科創達OpenHarmony研究組第一時間對https://codechina.csdn.net/openharmony上開源的代碼進行了詳盡的代碼研讀和學習，為此，我們打算撰寫一系列篇幅中等，內容精煉的原始碼分析文章來引領大家更進一步的走進鴻蒙OS，隨著對代碼的了解，廣大開發者想親自動手參與的意愿和信心也會隨之增強——這也是鴻蒙OS開源的意義所在，

本篇內容摘要：

本篇以OpenHarmony中ipcamera_hi3518ev300為編譯目標，介紹init行程的相關代碼，

寫在前面的話

我們對OpenHarmony的代碼進行了一個簡單粗略的統計，除去所有的third_party代碼（即OpenHarmony使用的第三方開源庫），其他剩余的代碼中，以.c、.h檔案為統計入口，總有效代碼行數（不含注釋、空行等，統計工具為tSourceCounter）為325627行，其中，歸屬kernel目錄下的總有效代碼行數為74150行，整個OpenHarmony中，kernel部分占比為22.8%左右，代碼量上占大頭的還在于kernel之上的、我們稱之為Framework的部分，根據我們在Android系統上多年的摸索和經驗，Framework恰恰是Android OS的精髓，所以，以OpenHarmony目前才20多萬行的Framework代碼量來看，感興趣的開發者在這塊參與共建、獻策獻力的機會非常大，

1. OpenHarmony原始碼的下載和編譯

先介紹代碼的下載和編譯，我們研究組用得是ubuntu 19.10的主機環境，

1.1 原始碼下載

按照codechina.csdn官網的原始碼下載指南：https://codechina.csdn.net/openharmony/docs/-/blob/master/get-code/%E6%BA%90%E7%A0%81%E8%8E%B7%E5%8F%96.md

我們使用的是第四種方式“獲取方式4：從代碼倉庫獲取”，執行這一節中的幾個命令，即可得到整個原始碼倉庫，

1.2 編譯原始碼

我們選擇的編譯目標是“Hi3518解決方案”,其編譯后的輸出目錄名為ipcamera_hi3518ev300，ipcamera_hi3518ev300是一個基于海思的ip攝像頭設備，相關的介紹檔案入口在https://codechina.csdn.net/openharmony/docs/-/blob/master/quick-start/%E6%90%AD%E5%BB%BA%E7%8E%AF%E5%A2%83-2.md，

注意，編譯不同的解決方案需要建立對應的編譯環境，對hi3518來說，開發者需要按照上述鏈接里的“搭建環境”來下載和配置，

一切就緒后，在原始碼根目錄下執行 python build.py，如果不帶引數的話，它會提醒你指定編譯目標，截圖如下：

圖1 python build.py不帶引數的執行結果

這次，我們通過python build.py ipcamera_hi3518ev300即可編譯“Hi3518解決方案”，編譯耗時10幾分鐘，

注意，編譯程序中可能出現找不到<valgrind/valgrind.h>的錯誤，這是因為目前我們下載的代碼中沒有包含valgrind的頭檔案，開發者可以手動將/usr/include/valgrind目錄拷貝到prebuilts/lite/sysroot/usr/include下即可（僅限Ubuntu平臺，需提前安裝好valgrind工具），

1.3 OpenHarmony編譯相關小知識介紹

OpenHarmony原始碼編譯系統使用了google開發的gn工具以及ninjia，這二者結合起來比傳統的makefile編譯系要高效，尤其適合大系統的并行編譯，對開發者而言，如果要參與OpenHarmony的開發，需要對gn的語法有些了解，本文僅做一些最基本的介紹：

1. 使用gn工具的話，開發者將編譯規則寫在名為BUILD.gn檔案中，和Makefile一樣，gn檔案有自己的語法規則，屬于領域語言（Domain Specific Language，DSL），gn語法不難，但編譯規則本身有很多內容，所以一下子要掌握全部內容也不容易，
2. gn支持自定義模板函式，可放在名為.gni的檔案中，OpenHarmony中最常見到的gn模板檔案為./build/lite/config/component/lite_component.gni，.gn檔案中通過import可匯入gni模板檔案，OpenHarmony定義了lite_component、lite_library等模板函式，
3. gn中，可執行檔案的編譯函式入口為exectuable("檔案名")，共享庫的編譯規則函式為shared_library("檔案名")，所以，如果要搜索某個檔案對應的編譯規則，可以先搜索所有的BUILD.gn檔案，然后grep executable，以下是我們grep所有的executable的結果截圖，

圖2 grep BUILD.gn中executable的結果示意

通過這種方式，我們能很快定位到比如init對應的代碼在什么地方，

最后，我們再簡單介紹下OpenHarmony編譯系統中和底層OS有關的一個條件編譯控制變數ohos_kernel_type，目前，該變數有四個取值，分別為"liteos_a"、"liteos_m"、"liteos_riscv"和"linux"：

1. "liteos_a"和"linux"經常做為一組進行判斷，liteos_a實際對應的是Cortex-A系列，其性能相對較高，可以跑Linux系統，
2. "liteos_m"和"liteos_riscv"往往是一組的，liteos_m對應的是Cortex-M系列，liteos_riscv是Riscv芯片的表示，二者可能都是針對性能一般，功耗較低的設備，

ohos_kernel_type的取值由build/lite/product/解決方案名.json檔案中的product欄位決定，例如，我們選擇的ipcamera_hi3518ev300的組態檔內容截圖如下，它的kernel欄位值為"liteos_a"，

圖3 build/lite/product/ ipcamera_hi3518ev300.json組態檔示意圖

編譯完成后，所有編譯生成物都在out/ipcamera_hi3518ev300目錄下，

2 init原始碼精要決議

init是Linux系統上的第一個應用行程，是其它行程的源頭，對ipcamera_hi3518ev300來說，它的編譯產物中也有一個init行程，

在上面提到的out/ipcamera_hi3518ev300目錄下，有一個rootfs.tar檔案，這個檔案里就是設備上根檔案系統的內容，打開其中的/rootfs/bin目錄，可以看到此次編譯的可執行程式如下截圖所示：

圖4 out/ipcamera_hi3518ev300/rootfs.tar/bin內容示意

借助圖2里提到的辦法，我們可以定位到init對應的代碼路徑為base/startup/services/init_lite/，其內容如下圖所示：

圖5 init_lite原始碼檔案示意圖

main.c是整個init的入口，我們簡單看一下它的代碼，如下所示，

圖6 init_lite/main.c

init main函式非常精簡，非常符合"lite"輕量簡便的風格，當然，也不排除未來init的代碼會越來越復雜，我們在AOSP上觀察到的情況就是一個例子——AOSP里現在的init的相關代碼非常復雜），

我們對InitReadCfg比較感興趣，這個函式內部將讀取/etc/init.cfg檔案，這個檔案在圖4中提到的rootfs.tar中可以找到，下圖是其內容的示意：

圖7 rootfs.tar/etc/init.cfg

init.cfg本質上是一個json格式的檔案，它包括一個名為"jobs"的陣列和一個名為"services"的陣列，

1. 對"jobs"來說：內部分別包含"pre-init"、"init"和"post-init"三個元素，從上面的截圖中可以看出，這三個元素對應的就是設定掛載一些設備、設定好路徑，啟動服務等作業，
2. 對"services"來說：它包含一組服務的定義，所謂的服務，就是系統里的關鍵行程，可以猜測到，init將根據service的配置來啟動對應的服務程式，并設定它的uid、gid、行程優先級和權限等，

如果開發者對Android系統有一定了解的話，會發現OpenHarmony和AOSP在init的作業流程上有著相似的設計思路，不過，對OpenHarmony目標設備來說，使用json格式無疑是比較簡單且方便的，

最后，我們再看一下init的另外一個重要職能——服務行程狀況監控，init.cfg中的那些服務屬于系統關鍵行程，運行程序中如果它們出現例外導致行程退出，需要有個辦法將它們重新啟動以保證業務連續性，

這個功能的實作就是利用Linux系統的SIGCHILD信號，init在SignalInitModule中監聽了該信號并設定了對應的信號處理函式——SigHandler，SigHandler函式的具體處理程序則比此處說得要更復雜一點，現在，這部分內容就留給讀者們自行探索了！！