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

鴻蒙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。若是不帶參數的話，它會提醒你指定編譯目標，截圖以下：

此次，咱們經過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的結果截圖。
   

經過這種方式，咱們能很快定位到好比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"。

編譯完成後，全部編譯生成物都在out/ipcamera_hi3518ev300目錄下。

2 init源碼精要解析

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

在上面提到的out/ipcamera_hi3518ev300目錄下，有一個rootfs.tar文件。這個文件裏就是設備上根文件系統的內容。打開其中的/rootfs/bin目錄，能夠看到這次編譯的可執行程序以下截圖所示：

藉助圖2裏提到的辦法，咱們能夠定位到init對應的代碼路徑爲base/startup/services/init_lite/。其內容以下圖所示：

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

init main函數很是精簡，很是符合"lite"輕量簡便的風格。固然，也不排除將來init的代碼會愈來愈複雜。咱們在AOSP上觀察到的狀況就是一個例子——AOSP裏如今的init的相關代碼很是複雜）。

咱們對InitReadCfg比較感興趣，這個函數內部將讀取/etc/init.cfg文件。這個文件在圖4中提到的rootfs.tar中能夠找到，下圖是其內容的示意：

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函數的具體處理過程則比此處說得要更復雜一點。如今，這部份內容就留給讀者們自行探索了！！

---

原文連接：https://developer.huawei.com/consumer/cn/forum/topicview?tid=0202366642839450045&fid=0101303901040230869做者：innost