前回の Linux Plumbers 2019 カンファレンスで、Google 開発について Linux カーネルで開発された変更をメイン Linux カーネルに転送する場合 Android プラットフォーム用。 最終的な目標は、Android 固有のブランチに基づいてデバイスごとに個別のビルドを準備するのではなく、Android で XNUMX つの共通カーネルを使用できるようにすることです。 。 この目標はすでに部分的に達成されており、通常の無修正の Linux カーネルに基づくファームウェアを搭載した Xiaomi Poco F1 Android スマートフォンがカンファレンスでデモンストレーションされました。
プロジェクトの準備が完了すると、ベンダーはメインの Linux カーネルに基づいたベース カーネルを提供するよう求められます。 ハードウェア サポート用のコンポーネントは、カーネルにパッチを適用せずに、追加のカーネル モジュールの形式でのみサプライヤーによって提供されます。 モジュールは、カーネル シンボル名前空間レベルでメイン カーネルと互換性がある必要があります。 メインコアに影響を与えるすべての変更はアップストリームにプロモートされます。 LTS ブランチ内の独自モジュールとの互換性を維持するために、カーネル API と ABI を安定した形式で維持することが提案されています。これにより、各共通カーネル ブランチの更新によるモジュールの互換性が維持されます。
各種リソース（CPU、メモリ、I/O）の取得待ち時間情報を解析するPSI（Pressure Stall Information）サブシステムや、プロセス間通信用擬似ファイルシステムBinderFSなどの機能を2年間で実現Android カーネル版からメイン Linux カーネルに移行されたメカニズム、バインダーおよびエネルギー効率の高いタスク スケジューラ EAS (Energy Aware Scheduling)。 将来的には、Android は、特定の SchedTune スケジューラから、cgroupsXNUMX および標準カーネル メカニズムに基づいて、ARM で開発された新しい UtilClamp サブシステムに移行される予定です。
これまで、Android プラットフォームのカーネルはいくつかの準備段階を経てきたことを思い出してください。
- メインの LTS カーネル (3.18、4.4、4.9、および 4.14) に基づいて、「Android Common Kernel」のブランチが作成され、そこに Android 固有のパッチが転送されました (以前は変更のサイズが数百万行に達していましたが、最近では変更は数千行のコードに削減されました)。
- 「Android Common Kernel」に基づいて、Qualcomm などのチップメーカーは、ハードウェアをサポートするためのアドオンを含む「SoC カーネル」を形成しました。
- SoC カーネルに基づいて、デバイス メーカーは、追加の機器、スクリーン、カメラ、サウンド システムなどのサポートに関連する変更を含むデバイス カーネルを作成しました。
本質的に、各デバイスには独自のカーネルがあり、他のデバイスでは使用できませんでした。 このようなスキームは、脆弱性を排除するためのアップデートの実装と新しいカーネル ブランチへの移行を大幅に複雑にします。 たとえば、4 月にリリースされた最新の Pixel 4.14 スマートフォンには、XNUMX 年前にリリースされた Linux カーネル XNUMX が搭載されています。 部分的には、Google はシステムを推進することでメンテナンスを簡素化しようとしました これにより、メーカーは、使用されている特定の Android バージョンや Linux カーネル リリースに縛られないユニバーサル ハードウェア サポート コンポーネントを作成できるようになります。 Treble を使用すると、Google の既製のアップデートをベースとして使用し、特定のデバイスに固有のコンポーネントを統合することができます。
出所： オープンネット.ru