カーネルモジュールのサポート

汎用カーネルイメージ（GKI）には、デバイスでパーティションをマウントするために必要なドライバサポートが含まれていない場合があります。デバイスがパーティションをマウントして起動を継続できるように、第 1 ステージの init が改良されて、RAM ディスクに存在するカーネルモジュールを読み込むようになりました。RAM ディスクは、汎用の RAM ディスクと、ベンダー RAM ディスクに分割されています。ベンダーカーネルモジュールは、ベンダー RAM ディスクに格納されます。カーネルモジュールを読み込む順序は設定可能です。

モジュールの場所

RAM ディスクは、第 1 ステージの init, と、A/B デバイスおよび仮想 A/B デバイスのリカバリイメージまたは fastbootd イメージ用のファイルシステムです。これは、ブートローダーによって連結される 2 つの cpio アーカイブからなる initramfs です。ベンダーブートパーティションにベンダー RAM ディスクとして格納される最初の cpio アーカイブには、次のコンポーネントが含まれています。

/lib/modules/ にある第 1 ステージの init ベンダーカーネルモジュール。
/lib/modules/ にある modprobe 構成ファイル modules.dep、modules.softdep、modules.alias、modules.options。
第 1 ステージの init で読み込むモジュールとその順序を示す modules.load ファイル（/lib/modules/ 内）。
A/B デバイスと仮想 A/B デバイスのベンダーリカバリカーネルモジュール（/lib/modules/ 内）。
A/B デバイスと仮想 A/B デバイス用に読み込むモジュールとその順序を示す modules.load.recovery（/lib/modules 内）。

2 番目の cpio アーカイブは、boot.img の RAM ディスクとして GKI で提供され、最初のアーカイブの先頭に適用されます。first_stage_init と、依存するライブラリが含まれます。

第 1 ステージの init でのモジュールの読み込み

第 1 ステージの init は、RAM ディスク上の /lib/modules/ から modprobe 構成ファイルを読み込むことから始まります。次に、/lib/modules/modules.load（リカバリの場合は /lib/modules/modules.load.recovery）で指定されたモジュールのリストを読み取り、前に読み込んだファイルで指定された構成に従って各モジュールを順に読み込もうとします。ハード依存関係またはソフト依存関係を満たすために、リクエストされた順序どおりにはならないことがあります。

ビルドサポート、第 1 ステージの init

ベンダー RAM ディスク cpio にコピーするカーネルモジュールを指定するには、BOARD_VENDOR_RAMDISK_KERNEL_MODULES にリストします。ビルドはこれらのモジュールに対して depmod を実行し、結果の modprobe 構成ファイルをベンダー RAM ディスク cpio に配置します。

また、ビルドによって modules.load ファイルも作成され、ベンダー RAM ディスク cpio に保存されます。デフォルトでは、BOARD_VENDOR_RAMDISK_KERNEL_MODULES にリストされているすべてのモジュールが含まれています。ファイルの内容をオーバーライドするには、次の例のように BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD を使用します。

BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD := \
    device/vendor/mydevice-kernel/first.ko \
    device/vendor/mydevice-kernel/second.ko \
    device/vendor/mydevice-kernel/third.ko

ビルドサポート、フル Android

Android 10 以前のリリースと同様に、BOARD_VENDOR_KERNEL_MODULES にリストされているカーネルモジュールは、Android プラットフォームビルドによって /vendor/lib/modules のベンダーパーティションにコピーされます。プラットフォームビルドは、これらのモジュールに対して depmod を実行し、depmod 出力ファイルを同じ場所にあるベンダーパーティションにコピーします。/vendor からカーネルモジュールを読み込むメカニズムは、以前の Android リリースの場合と同様です。モジュールを読み込む方法とタイミングは自由に決められますが、通常は init.rc スクリプトを使用します。

ワイルドカードと統合カーネルビルド

デバイスカーネルビルドと Android プラットフォームビルドを組み合わせるベンダーは、上記の BOARD マクロを使用してデバイスにコピーするカーネルモジュールを指定すると、問題が発生することがあります。デバイスのプラットフォームビルドファイルにカーネルモジュールをリストしない場合、ベンダーはワイルドカード（$(wildcard device/vendor/mydevice/*.ko）を使用できます。なお、統合カーネルビルドの場合、ワイルドカードは機能しません。これは、make が呼び出され、マクロが makefile で展開されると、カーネルモジュールがビルドされず、マクロが空になるためです。

この問題を回避するために、ベンダーはカーネルビルドで、各パーティションにコピーされるカーネルモジュールを含む zip アーカイブを作成していることがあります。BOARD_*_KERNEL_MODULES_ARCHIVE で zip アーカイブのパスを設定します。ここで * は、パーティションの名前です（例: BOARD_VENDOR_KERNEL_MODULES_ARCHIVE）。Android プラットフォームビルドは、この zip アーカイブを適切な場所に解凍し、モジュールに対して depmod を実行します。

カーネルモジュールの zip アーカイブには、必要に応じてプラットフォームビルドがアーカイブを生成できるようにする make ルールが必要です。

リカバリ

以前の Android リリースでは、リカバリに必要なカーネルモジュールが BOARD_RECOVERY_KERNEL_MODULES で指定されていました。Android 11 でも、このマクロを使用してリカバリに必要なカーネルモジュールを指定します。ただし、リカバリカーネルモジュールは、汎用の RAM ディスク cpio ではなく、ベンダー RAM ディスク cpio にコピーされます。デフォルトでは、BOARD_RECOVERY_KERNEL_MODULES にリストされているすべてのカーネルモジュールは、第 1 ステージの init で読み込まれます。これらのモジュールのサブセットのみを読み込む場合は、BOARD_RECOVERY_KERNEL_MODULES_LOAD でサブセットの内容を指定します。

ベンダーブートパーティション（このページで述べたベンダー RAM ディスクを含む）の作成方法については、ブートパーティションをご覧ください。

カーネル モジュールのサポート