Eine stabile Kernelmodul-Benutzeroberfläche aufrechterhalten

Es ist wichtig, eine stabile Kernel-Modul-Schnittstelle (Kernel Module Interface, KMI) für Anbietermodule zu pflegen. Der GKI-Kernel wird in Binärform erstellt und bereitgestellt. Von Anbietern ladbare Module werden in einem separaten Verzeichnis erstellt. Der daraus resultierende GKI-Kernel und die Anbietermodule müssen so funktionieren, als wären sie zusammen erstellt worden.

Im Allgemeinen hat die Linux-Community Bedenken hinsichtlich der Stabilität des In-Kernel-ABI für den Mainline-Kernel geäußert. Angesichts der verschiedenen Toolchains, Konfigurationen und des sich ständig weiterentwickelnden Linux-Mainline-Kernels ist es nicht möglich, eine stabile KMI im Mainline zu pflegen. Es ist jedoch möglich, unter Einhaltung der folgenden Einschränkungen eine stabile KMI in der stark eingeschränkten GKI-Umgebung aufrechtzuerhalten:

  • Zum Erstellen des Kernels kann nur eine einzige Konfiguration, gki_defconfig, verwendet werden.

  • Der KMI ist nur innerhalb derselben LTS- und Android-Version eines Kernels stabil, z. B. android13-5.10, android12-5.10 oder android13-5.15.

    • Für android-mainline wird keine KMI-Stabilität aufrechterhalten.

  • Für das Erstellen des Kernels und der Module wird nur die spezifische Clang-Toolchain verwendet, die in AOSP bereitgestellt und für den entsprechenden Branch definiert ist.

  • Nur Symbole, die bekanntermaßen von Modulen verwendet werden, wie in einer Symbolliste angegeben, werden auf Stabilität überwacht und als KMI-Symbole betrachtet.

    • Das bedeutet, dass Anbietermodule nur KMI-Symbole verwenden dürfen. Diese Einschränkung wird durch fehlgeschlagene Modulladungen erzwungen, wenn keine KMI-Symbole erforderlich sind.

  • Nachdem der KMI-Zweig eingefroren wurde, sind Änderungen zulässig, dürfen aber die KMI nicht beeinträchtigen. Zu diesen Änderungen gehören:

    • Konfigurationsänderungen
    • Änderungen am Kernelcode
    • Änderungen an der Toolchain (einschließlich Updates)

Hermetischen Buildprozess und LLVM-Toolchain verwenden

Der hermetische Build-Prozess sorgt für eine stabile KMI, da die Build-Umgebung vollständig in repo-Manifesten in kernel/manifest beschrieben wird. Das Manifest für android13-5.15 enthält beispielsweise die Toolchain, Build-Scripts und alles andere, was zum Erstellen des GKI-Kernels (Generic Kernel Image) erforderlich ist. Die entsprechenden build.config-Konfigurationsdateien, z. B. die GKI-Build-Konfiguration build.config.gki.aarch64, sorgen dafür, dass die enthaltenen Tools korrekt verwendet werden, um konsistente Buildergebnisse zu generieren.

Durch einen hermetischen Buildprozess wird außerdem sichergestellt, dass die ABI-Beschreibung für den Verzeichnisbaum konsistent ist, unabhängig davon, ob sie von Google generiert wurde (z. B. abi_gki_aarch64.xml für android13-5.15) oder in einem lokalen Verzeichnisbaum, der die Anbietermodule enthält. Die Tools zum Erstellen und Vergleichen der ABI-Beschreibung für die Kernel-Modul-Schnittstelle (KMI) sind ebenfalls Teil des vom Manifest beschriebenen Repos.

Die Toolchain, die zum Erstellen des GKI-Kernels verwendet wird, muss vollständig mit der Toolchain kompatibel sein, die zum Erstellen von Anbietermodulen verwendet wird. Ab Android 10 müssen alle Android-Kernel mit einer LLVM-Toolchain erstellt werden. Bei GKI muss die LLVM-Toolchain, die zum Erstellen von Produktkernen und Anbietermodulen verwendet wird, dasselbe ABI generieren wie die LLVM-Toolchain von AOSP. Außerdem müssen Partner dafür sorgen, dass das KMI mit dem GKI-Kernel kompatibel ist. Wir empfehlen dringend, die bereitgestellten Build-Tools zu verwenden, da sie die beste Kompatibilität bieten.

Wie geht es weiter?

  • Eine Anleitung zum Erstellen des Kernels mit dem hermetischen Build-Prozess und der LLVM-Toolchain finden Sie unter Kernel erstellen.

  • Eine Anleitung zum Überwachen des ABI und zum Beheben von Problemen finden Sie unter Android Kernel ABI Monitoring.