Es ist wichtig, eine stabile Kernel-Modulschnittstelle (KMI) für den Anbieter aufrechtzuerhalten Module. Der GKI-Kernel ist werden in binärer Form erstellt und ausgeliefert. separater Baum. Die resultierenden GKI-Kernel- und Anbietermodule müssen obwohl sie zusammen entwickelt wurden.
Im Allgemeinen hat die Linux-Community sein skeptisch gegenüber dem Konzept des In-Kernel-ABI Stabilität für den Mainline-Kernel. Bei unterschiedlichen Toolchains, Konfigurationen, und einem sich ständig weiterentwickelnden Linux-Mainline-Kernel ist es nicht machbar, KMI in Mainline stabil. Es ist jedoch möglich, der stark eingeschränkten GKI-Umgebung mit diesen Einschränkungen:
Nur eine Konfiguration (
gki_defconfig) kann zum Erstellen des Kernel.Die KMI ist nur innerhalb derselben Version von Langzeitsupport und Android-Version eines Kernels stabil, z. B.
android13-5.10,android12-5.10oderandroid13-5.15.- Für
android-mainlinewird keine KMI-Stabilität beibehalten.
- Für
Nur die spezifische Clang-Toolchain, die in AOSP bereitgestellt und für den der entsprechende Zweig für die Erstellung des Kernels und der Module verwendet wird.
Nur Symbole, die von Modulen aus einer Symbolliste verwendet werden können, sind werden auf Stabilität überwacht und als KMI-Symbole betrachtet.
- Folglich dürfen in den Anbietermodulen nur KMI-Symbole verwendet werden. Dieses wird erzwungen, wenn das Laden von Modulen fehlschlägt, wenn Nicht-KMI-Symbole erforderlich.
Nachdem der KMI-Zweig eingefroren ist, sind Änderungen zulässig, die KMI kann jedoch nicht unterbrochen werden. Zu diesen Änderungen gehören:
- Konfigurationsänderungen
- Änderungen am Kernel-Code
- Änderungen an der Toolchain (einschließlich Aktualisierungen)
Hermetischen Build-Prozess und LLVM-Toolchain verwenden
Der hermetische Build-Prozess sorgt mit repo-Manifesten in
kernel/manifest beschreibt die Build-Umgebung umfassend. Beispiel: Der Parameter
Manifest für android13-5.15
enthält die Toolchain, Build-Skripts und alles andere, was zum Erstellen der
Generischer Kernel-Image-Kernel (GKI). Die entsprechende build.config-Konfiguration
z. B. die GKI-Build-Konfiguration build.config.gki.aarch64,
Sie stellen sicher, dass die enthaltenen Tools korrekt verwendet werden, um konsistente Builds zu generieren.
Ergebnisse.
Die Verwendung eines hermetischen Build-Prozesses stellt außerdem sicher, dass die ABI-Beschreibung für die
ist einheitlich, ob von Google generiert (z. B.
abi_gki_aarch64.xml
für android13-5.15) oder in einer lokalen Baumstruktur generiert, die den Anbieter enthält
Module. Die
Tools zum Erstellen und Vergleichen der ABI-Beschreibung
für das Kernel Module Interface (KMI) werden ebenfalls als Teil des Repositorys bereitgestellt.
die im Manifest beschrieben sind.
Die zum Erstellen des GKI-Kernels verwendete Toolchain muss vollständig kompatibel sein mit Die Toolchain, die zum Erstellen von Anbietermodulen verwendet wird. Ab Android 10, alle Android-Kernel müssen erstellt werden mit einer LLVM-Toolchain. Mit GKI, der LLVM-Toolchain, die zum Erstellen des Produkts verwendet wird Kernel und Anbietermodule müssen dasselbe ABI generieren wie die LLVM-Toolchain aus AOSP und Partner müssen sicherstellen, dass die KMI mit dem GKI-Kernel kompatibel ist. Es wird dringend empfohlen, die bereitgestellten Build-Tools zu verwenden, da diese beste Kompatibilität.
Wie geht es weiter?
Anleitungen zum Erstellen des Kernels mithilfe des hermetischen Build-Prozesses und LLVM-Toolchain, siehe Verweis auf Build-Kernel
Anweisungen zum Überwachen des ABI und zum Beheben von Problemen findest du unter ABI-Monitoring unter Android-Kernel