Übersicht über Kernelmodule

Es gibt zwei Arten von Kernelmodulen: hardwareunabhängige GKI-Module und hardwarespezifische Herstellermodule . Auf dieser Seite finden Sie einen Überblick über beide Modultypen.

GKI-Module

Generic Kernel Image (GKI)-Module werden verwendet, um nicht für den Start erforderliche Kernel-Funktionalität getrennt vom generischen Kernel bereitzustellen. Mit GKI-Modulen können Sie bestimmte Kernel-Funktionen zur Verwendung auswählen und so häufig die Größe des Kernel-Images und den Laufzeitspeicherverbrauch reduzieren. Aufgrund der Größenreduzierung eignet sich GKI gut für Android Go-Geräte und andere ressourcenbeschränkte Formfaktoren.

GKI-Module bieten außerdem einen Mechanismus, der es Anbietern ermöglicht, nach dem Meilenstein des KMI-Einfrierens neue Upstream-Funktionen zu integrieren. Eingebauter Code kann nicht ersetzt werden, ohne ein weiteres Image zu erstellen, wohingegen als Modul gelieferter Code durch ein anderes Modul ersetzt werden kann.

GKI-Module nutzen die Build-Time-Signatur-Infrastruktur des Kernels, um zur Laufzeit zwischen GKI und anderen Modulen zu unterscheiden. Nicht signierte Module dürfen geladen werden, solange sie nur Symbole verwenden, die auf der Zulassungsliste stehen oder von anderen nicht signierten Modulen bereitgestellt werden.

Es gibt zwei logische Arten von GKI-Modulen: geschützte GKI-Module und ungeschützte GKI-Module .

Geschütztes GKI-Modul

Ein geschütztes GKI-Modul wird von Google bereitgestellt, unterliegt keinerlei Einschränkungen und verhält sich nach dem Laden so, als wäre es mit dem Kernel erstellt worden. Darüber hinaus weisen geschützte GKI-Module die folgenden Eigenschaften auf:

  • Geschützte GKI-Module haben Zugriff auf Nicht-KMI-Kernelsymbole, die für Herstellermodule oder ungeschützte GKI-Module nicht verfügbar sind.
  • Geschützte GKI-Module können Symbole exportieren, die Teil der KMI-Oberfläche werden, sofern diese Symbole in einer Symbolliste aufgeführt sind.
  • Geschützte GKI-Module können nicht durch Anbietermodule überschrieben werden.

Ein geschütztes GKI-Modul ist die Standardklasse von GKI-Modulen. Alle GKI-Module gelten zum Zeitpunkt des KMI-Einfrierens als geschützt.

Ungeschütztes GKI-Modul

Ein ungeschütztes GKI-Modul kann durch ein Herstellermodul überschrieben werden. Nach dem Einfrieren von KMI kann ein geschütztes GKI-Modul als ungeschützt eingestuft werden, wenn das GKI-Team entscheidet, dass Anbieter die Standardimplementierung mit einer Version überschreiben müssen, die neue Funktionen von Upstream-Linux enthält. Bei der nächsten GKI-Version werden ungeschützte Module als geschützt neu klassifiziert, nachdem Upstream-Code in einem Android Common Kernel (ACK) landet. Ungeschützte GKI-Module weisen die folgenden Eigenschaften auf:

  • Ungeschützte GKI-Module haben denselben Zugriff auf exportierte Symbole wie Anbietermodule.
  • Ungeschützte GKI-Module können keine Symbole exportieren, die von geschützten GKI-Modulen exportiert wurden.
  • Ungeschützte GKI-Module müssen alle KMI-Schnittstellen beibehalten, als wären sie Teil des Kernels.
  • Ungeschützte GKI-Module können durch Herstellermodule überschrieben werden.

Anbietermodule

Zur Implementierung von SoC- und gerätespezifischen Funktionen wird von Partnern ein Anbietermodul bereitgestellt. Jedes vorhandene Kernelmodul, das nicht als Teil des GKI-Kernels bereitgestellt wird, kann als Anbietermodul bereitgestellt werden.

Da eines der Hauptziele des GKI-Projekts darin besteht, hardwarespezifischen Code im Kernel zu minimieren, können Anbieter davon ausgehen, dass der GKI-Kernel keine Module enthält, die eindeutig ihre eigene Hardware verwalten. Beispielsweise kann der Anbieter ABC Inc. davon ausgehen, dass Konfigurationen wie CONFIG_ABC_SOC_SUPPORT ohne deren Unterstützung weder als integrierte noch als ladbare GKI-Module aktiviert werden.

Wenn ein Kernel-Treiber oder ein Kernel-Framework in ACK vorhanden ist, aber nicht als Teil des GKI-Kernels bereitgestellt wird, können Anbieter den Treiber ändern und ihn als Anbietermodul bereitstellen. Von solchen Änderungen wird bei nicht herstellerspezifischen Modulen abgeraten, da die gleiche Funktionalität möglicherweise in einer zukünftigen Version mit dem GKI-Kernel bereitgestellt wird. Wenn der GKI-Kernel Funktionen enthält, die von einem Anbietermodul bereitgestellt werden, wird das Anbietermodul nicht geladen. Beispielsweise ist CONFIG_GREYBUS in Android 11 nicht für GKI festgelegt, sodass Anbieter möglicherweise Greybus-Anbietermodule bereitstellen. Allerdings ist CONFIG_GREYBUS möglicherweise als GKI-Integration oder -Modul in Android 12 aktiviert. In diesem Fall werden Greybus-Anbietermodule nicht geladen. Eine bewährte Vorgehensweise besteht darin, die Upstream-Version von nicht herstellerspezifischen Treibern zu verwenden, wenn diese als Herstellermodule geliefert werden.

Sie können Anbietermodule im vendor oder vendor_boot Image bereitstellen. Module, die zu Beginn des Startvorgangs benötigt werden, müssen sich in vendor_boot befinden. Mit dem Laden von Modulen von vendor_boot fallen Bootzeitkosten an.