HongmengOSオープンソースコードの本質的な解釈-init

著者紹介：

Zhongke Chuangda OpenHarmony Research Group

説明：

Zhongke ChuangdaのOpenHarmonyの研究グループは、オープンソースコードにコードの調査と研究を詳細に行った上https://codechina.csdn.net/openharmonyのために初めて。この目的のために、私たちは一連の中規模および洗練されたソースコード分析記事を作成して、すべての人がHongmengOSにさらに参入できるようにする予定です。コードを理解することで、開発者の大多数がコードに参加する意欲と自信も高まります。これは、HongmengOSオープンソースの意味でもあります。

この記事の要約：

この記事では、OpenHarmonyのipcamera_hi3518ev300をコンパイルターゲットとして使用し、initプロセスの関連コードを紹介します。

前に書かれた言葉

OpenHarmonyコードで簡単で大まかな統計を実行しました。すべてのサードパーティコード（つまり、OpenHarmonyで使用されるサードパーティのオープンソースライブラリ）を除き、残りのコードの中でも、統計エントリとして.cファイルと.hファイルを使用し、有効なコード行の総数（コメント、空白行などを除く）を使用します。 tSourceCounter）は325627行です。その中で、アトリビューションカーネルディレクトリ内の有効なコード行の総数は74,150行です。OpenHarmony全体で、カーネル部分は約22.8％を占め、コードの主要部分は、フレームワークと呼ばれるカーネルの上の部分です。Androidシステムでの長年の調査と経験によると、FrameworkはまさにAndroidOSの本質です。したがって、OpenHarmonyの現在のフレームワークコードボリュームがわずか200,000行を超えることに基づいて、関心のある開発者が共同構築に参加し、この分野でアイデアを提供する絶好の機会があります。

1.OpenHarmony ソースコードをダウンロードしてコンパイルします

まず、コードのダウンロードとコンパイルを紹介します。私たちの研究グループは、ubuntu19.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番目の方法「取得方法4：コードウェアハウスから取得」を使用します。このセクションのいくつかのコマンドを実行して、ソースコードリポジトリ全体を取得します。

1.2 ソースコードをコンパイルする

選択したコンパイルターゲットは「Hi3518solution」で、コンパイルされた出力ディレクトリの名前はipcamera_hi3518ev300です。ipcamera_hi3518ev300は、HiSiliconをベースにした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の場合、開発者は上記のリンクの「ビルド環境」に従ってダウンロードして構成する必要があります。

すべての準備ができたら、ソースルートディレクトリでpythonbuild.pyを実行します。パラメータがない場合は、コンパイル対象を指定するように求められます。スクリーンショットは次のとおりです。

図1パラメータなしのpythonbuild.pyの実行結果

今回は、python build.pyipcamera_hi3518ev300を使用して「Hi3518Solution」をコンパイルできます。コンパイルには10分かかります。

コンパイルプロセス中に<valgrind / valgrind.h>が見つからないというエラーが発生する可能性があることに注意してください。これは、valgrindヘッダーファイルが現在ダウンロードされているコードに含まれていないためです。開発者は、/ usr / include / valgrindディレクトリをprebuilts / lite / sysroot / usr / includeに手動でコピーできます（Ubuntuプラットフォームの場合のみ、valgrindツールを事前にインストールする必要があります）。

1.3OpenHarmonyコンパイルの概要関連知識

OpenHarmonyソースコードコンパイルシステムは、Googleが開発したgnツールとninjiaを使用します。この2つの組み合わせは、従来のmakefileコンパイルシステムよりも効率的であり、大規模システムの並列コンパイルに特に適しています。開発者にとって、OpenHarmonyの開発に参加したい場合は、gnの構文を理解する必要があります。この記事では、いくつかの基本的な紹介のみを行います。

開発者は、gnツールを使用して、コンパイルルールをBUILD.gnという名前のファイルに書き込みます。Makefileと同様に、gnファイルには独自の文法規則があり、ドメイン固有言語（DSL）に属しています。gnの文法は難しくありませんが、コンパイルルール自体に多くのコンテンツがあるため、一度にすべてを習得するのは簡単ではありません。
gnは、.gniという名前のファイルに配置できるカスタムテンプレート関数をサポートしています。OpenHarmonyで最も一般的なgnテンプレートファイルは./build/lite/config/component/lite_component.gniです。Gniテンプレートファイルは、.gnファイルにインポートすることでインポートできます。OpenHarmonyは、lite_componentやlite_libraryなどのテンプレート関数を定義します。
gnでは、実行可能ファイルのコンパイル関数エントリは実行可能（ "ファイル名"）であり、共有ライブラリのコンパイルルール関数はshared_library（ "ファイル名"）です。したがって、ファイルに対応するコンパイルルールを検索する場合は、最初にすべてのBUILD.gnファイルを検索してから、grep実行可能ファイルを検索できます。以下は、grepのすべての実行可能な結果のスクリーンショットです。

図2は、grepBUILD.gnで実行可能な結果を示しています。

このようにして、たとえば、initに対応するコードをすばやく見つけることができます。

最後に、OpenHarmonyコンパイルシステムの基盤となるOSに関連する条件付きコンパイル制御変数ohos_kernel_typeを簡単に紹介します。現在、この変数には「liteos_a」、「liteos_m」、「liteos_riscv」、「linux」の4つの値があります。

「liteos_a」と「linux」は、グループとして判断されることがよくあります。liteos_aは、実際には比較的高性能でLinuxシステムで実行できるCortex-Aシリーズに対応しています。
「liteos_m」と「liteos_riscv」は多くの場合グループです。liteos_mはCortex-Mシリーズに対応し、liteos_riscvはRiscvチップを表しています。どちらも、平均的なパフォーマンスと低消費電力のデバイス向けです。

ohos_kernel_typeの値は、build / lite / product / solutionname.jsonファイルのproductフィールドによって決定されます。たとえば、選択したipcamera_hi3518ev300の構成ファイルの内容のスクリーンショットは次のとおりであり、そのカーネルフィールド値は「liteos_a」です。

図3構成ファイルbuild / lite / product /ipcamera_hi3518ev300.jsonの概略図

コンパイルが完了すると、コンパイルされたすべての製品がout / ipcamera_hi3518ev300ディレクトリにあります。

2init ソースコードの本質的な分析

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 /として見つけることができます。その内容を次の図に示します。

図5init_liteソースファイルの概略図

main.cは、init全体への入り口です。以下に示すように、そのコードを簡単に見てみましょう。

図6init_lite / main.c

initの主な機能は非常に簡潔で、軽量でシンプルなスタイルの「ライト」と非常に一致しています。もちろん、initコードが将来ますます複雑になることを排除するものではありません。AOSPで観察された状況は一例です-AOSPの現在の初期化コードは非常に複雑です）。

InitReadCfgにもっと関心があります。この関数は、/ etc /init.cfgファイルを内部的に読み取ります。このファイルは、図4に記載されているrootfs.tarにあります。次の図はその内容を示しています。

図7rootfs.tar / etc / init.cfg

init.cfgは、基本的にjson形式のファイルです。これには、「jobs」という名前の配列と「services」という名前の配列が含まれています。

「ジョブ」の場合：「pre-init」、「init」、「post-init」の3つの要素が含まれます。上のスクリーンショットからわかるように、これらの3つの要素は、一部のデバイスのセットアップとマウント、パスのセットアップ、およびサービスの開始に対応しています。
「サービス」の場合：一連のサービスの定義が含まれます。いわゆるサービスは、システムの重要なプロセスです。initは、サービス構成に従って対応するサービスプログラムを開始し、そのuid、gid、プロセスの優先度、アクセス許可などを設定すると推測できます。

開発者がAndroidシステムについてある程度理解している場合、OpenHarmonyとAOSPはinitワークフローで同様の設計アイデアを持っていることがわかります。ただし、OpenHarmonyターゲットデバイスの場合、json形式の使用は間違いなく比較的簡単で便利です。

最後に、init-serviceプロセスステータス監視のもう1つの重要な機能を見てみましょう。init.cfg内のこれらのサービスは、システムの重要なプロセスに属しています。それらが異常であり、操作中にプロセスが終了する場合は、ビジネスの継続性を確保するためにそれらを再起動する方法が必要です。

この機能の実現は、LinuxシステムのSIGCHILD信号を使用することです。Initは、SignalInitModule内の信号を監視し、対応する信号処理関数であるSigHandlerを設定します。SigHandler関数の特定の処理は、ここで説明されているものよりも少し複雑です。現在、コンテンツのこの部分は、読者が自分で探索できるように残されています。！