Google は、黒人コミュニティに対する人種平等の促進に取り組んでいます。取り組みを見る
このページは Cloud Translation API によって翻訳されました。
Switch to English

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

汎用カーネルイメージ（GKI）には、デバイスがパーティションをマウントできるようにするために必要なドライバーサポートが含まれていない場合があります。デバイスがパーティションをマウントして起動を続行できるようにするために、第1段階のinitが拡張され、RAMディスクに存在するカーネルモジュールがロードされます。 ramdiskは、汎用ramdiskとベンダーramdiskに分割されます。ベンダーカーネルモジュールはベンダーRAMディスクに保存されます。カーネルモジュールがロードされる順序は構成可能です。

モジュールの場所

ramdiskは、第1段階のinit,およびA / Bおよび仮想A / Bデバイス上のリカバリ/ fastbootdイメージ用のファイルシステムです。これは、ブートローダーによって連結される2つのcpioアーカイブで構成されるinitramfsです。ベンダーのramdiskとしてvendor-bootパーティションに保存されている最初のcpioアーカイブには、次のコンポーネントが含まれています。

  • /lib/modules/ある第1段階のinitベンダーカーネルモジュール。
  • /lib/modules/にあるmodprobe設定ファイル： modules.dep 、 modules.softdep 、 modules.alias 、 modules.options 。
  • /lib/modules/にある、第1段階の初期化中にロードするモジュールとその順序を示すmodules.loadファイル。
  • /lib/modules/ A / Bおよび仮想A / Bデバイス用のベンダーリカバリカーネルモジュール
  • modules.load.recoveryは、 /lib/modules 、ロードするモジュールと、A / Bおよび仮想A / Bデバイスの順序を示し/lib/modules 。

2番目のcpioアーカイブは、boot.imgのramdiskとしてGKIで提供され、最初のアーカイブの上に適用され、 first_stage_initとそれが依存するライブラリを含みます。

第1段階の初期化でのモジュールのロード

第1段階のinitは、RAMディスクの/lib/modules/からmodprobe構成ファイルを読み取ることから始まります。次に、/ /lib/modules/modules.load / modules / /lib/modules/modules.load （またはリカバリの場合は/lib/modules/modules.load.recovery ）で指定されたモジュールのリストを読み取り、次の/lib/modules/modules.load.recoveryに従って、これらの各モジュールを順番にロードしようとします。以前にロードされたファイルで指定された構成。要求された順序は、ハードまたはソフトの依存関係を満たすために逸脱する場合があります。

ビルドサポート、第1段階の初期化

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

ビルドはmodules.loadファイルも作成し、ベンダーのramdiskcpioに保存します。デフォルトでは、 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リリースの場合と同様に、 BOARD_VENDOR_KERNEL_MODULESリストされているカーネルモジュールは、Androidプラットフォームビルドによって/vendor/lib/modulesベンダーパーティションにコピーされ/vendor/lib/modules 。プラットフォームビルドは、これらのモジュールでdepmodを実行し、 depmod出力ファイルを同じ場所のベンダーパーティションにコピーします。 /vendorからカーネルモジュールをロードするメカニズムは、Androidの以前のリリースの場合と同じです。これらのモジュールをロードする方法とタイミングはユーザーが決定しますが、通常、これはinit.rcスクリプトを使用して行われます。

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

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

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

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

回復

以前のAndroidリリースでは、リカバリに必要なカーネルモジュールはBOARD_RECOVERY_KERNEL_MODULES指定されていBOARD_RECOVERY_KERNEL_MODULES 。 Android 11では、リカバリに必要なカーネルモジュールは引き続きこのマクロを使用して指定されます。ただし、リカバリカーネルモジュールは、汎用のramdisk cpioではなく、ベンダーのramdiskcpioにコピーされます。デフォルトでは、 BOARD_RECOVERY_KERNEL_MODULESリストされているすべてのカーネルモジュールは、第1段階のinit中にロードされinit 。これらのモジュールのサブセットのみをロードする場合は、そのサブセットの内容をBOARD_RECOVERY_KERNEL_MODULES_LOADで指定します。

ベンダーのブートパーティション（このページに記載されているベンダーのRAMディスクを含む）の作成については、ブートパーティションを参照してください。