Es gibt zwei Arten von Kernelmodulen: hardwareunabhängige GKI-Module und hardwarespezifische Herstellermodule . Diese Seite gibt einen Überblick über beide Modularten.
GKI-Module
Generic Kernel Image (GKI)-Module werden verwendet, um Kernel-Funktionalität getrennt vom generischen Kernel bereitzustellen, die nicht vom Booten benötigt wird. Mit GKI-Modulen können Sie bestimmte zu verwendende Kernelfunktionen auswählen, wodurch häufig die Kernel-Image-Größe und der Speicherverbrauch zur Laufzeit reduziert werden. Aufgrund der geringeren Größe eignet sich GKI gut für Android Go-Geräte und andere ressourcenbeschränkte Formfaktoren.
GKI-Module bieten auch einen Mechanismus, mit dem Anbieter nach dem KMI-Einfrieren-Meilenstein neue Upstream-Funktionen integrieren können. Eingebauter Code kann nicht ersetzt werden, ohne ein weiteres Image zu erstellen, während Code, der als Modul geliefert wird, durch ein anderes Modul ersetzt werden kann.
GKI-Module verwenden die Build-Time-Signing-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 erscheinen oder von anderen nicht signierten Modulen bereitgestellt werden.
Es gibt zwei logische Typen von GKI-Modulen: geschütztes GKI-Modul und ungeschütztes GKI-Modul .
Geschütztes GKI-Modul
Ein geschütztes GKI-Modul wird von Google ausgeliefert, ist in keiner Weise eingeschränkt und verhält sich nach dem Laden so, als wäre es mit dem Kernel gebaut worden. Zusätzlich haben geschützte GKI-Module die folgenden Eigenschaften:
- Geschützte GKI-Module haben Zugriff auf Nicht-KMI-Kernelsymbole, die Anbietermodulen oder ungeschützten GKI-Modulen nicht zur Verfügung stehen.
- Geschützte GKI-Module können Symbole exportieren, die Teil der KMI-Oberfläche werden, solange diese Symbole in einer Symbolliste zitiert werden.
- Geschützte GKI-Module können nicht durch Herstellermodule überschrieben werden.
Ein geschütztes GKI-Modul ist die Standardklasse von GKI-Modulen. Alle GKI-Module gelten zum Zeitpunkt des Einfrierens von KMI als geschützt.
Ungeschütztes GKI-Modul
Ein ungeschütztes GKI-Modul kann von einem Anbietermodul überschrieben werden. Nach dem Einfrieren von KMI kann ein geschütztes GKI-Modul als ungeschützt neu klassifiziert werden, wenn das GKI-Team entscheidet, dass Anbieter die Standardimplementierung mit einer Version außer Kraft setzen müssen, die neue Funktionen von Upstream-Linux enthält. In 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 haben folgende Eigenschaften:
- Ungeschützte GKI-Module haben denselben Zugriff auf exportierte Symbole wie Herstellermodule.
- 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 als Teil des Kernels beibehalten.
- Ungeschützte GKI-Module können durch Herstellermodule überschrieben werden.
Anbietermodule
Ein Anbietermodul wird von Partnern bereitgestellt, um SoC- und gerätespezifische Funktionen zu implementieren. Jedes vorhandene Kernelmodul, das nicht als Teil des GKI-Kernels bereitgestellt wird, kann als Herstellermodul bereitgestellt werden.
Da eines der Hauptziele des GKI-Projekts darin besteht, hardwarespezifischen Code im Kernel zu minimieren, können Anbieter erwarten, dass der GKI-Kernel keine Module enthalten wird, die eindeutig ihre eigene Hardware verwalten. Beispielsweise kann der Anbieter ABC Inc erwarten, dass Konfigurationen wie CONFIG_ABC_SOC_SUPPORT ohne ihre Unterstützung weder als integrierte noch als ladbare GKI-Module aktiviert werden.
Wenn ein Kerneltreiber oder -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. Für nicht herstellerspezifische Module wird von solchen Modifikationen abgeraten, da die gleiche Funktionalität möglicherweise mit dem GKI-Kernel in einer zukünftigen Version 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 Greybus-Anbietermodule bereitstellen können. CONFIG_GREYBUS ist jedoch möglicherweise als GKI-integriert oder -Modul in Android 12 aktiviert, in diesem Fall werden keine Graybus-Anbietermodule geladen. Eine bewährte Methode besteht darin, die Upstream-Version von nicht herstellerspezifischen Treibern zu verwenden, wenn sie als Herstellermodule geliefert werden.
Sie können Vendor-Module im vendor oder vendor_boot -Image bereitstellen. Module, die zu Beginn des Startvorgangs erforderlich sind, müssen sich in vendor_boot . Mit dem Laden von Modulen aus vendor_boot sind Kosten für die Bootzeit verbunden.