Aufrechterhaltung einer stabilen Kernel Module Interface (KMI)

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Es ist wichtig, ein stabiles KMI für Anbietermodule aufrechtzuerhalten. Der GKI-Kernel wird in Binärform erstellt und ausgeliefert, und vom Hersteller ladbare Module werden in einem separaten Baum erstellt. Der resultierende GKI-Kernel und die Herstellermodule müssen so funktionieren, als wären sie zusammengebaut worden.

Im Allgemeinen missbilligt die Linux-Community den Begriff der Kernel-ABI-Stabilität für den Mainline-Kernel. Angesichts unterschiedlicher Toolchains, Konfigurationen und eines sich ständig weiterentwickelnden Linux-Mainline-Kernels ist es nicht möglich, ein stabiles KMI in der Mainline aufrechtzuerhalten. Es ist jedoch möglich, mit diesen Einschränkungen ein stabiles KMI in der stark eingeschränkten GKI-Umgebung aufrechtzuerhalten:

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

  • Das 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.

  • Nur die spezifische Clang -Toolchain, die in AOSP bereitgestellt und für den entsprechenden Zweig definiert wird, wird zum Erstellen von Kernel und Modulen verwendet.

  • Nur Symbole, von denen bekannt ist, dass sie von Modulen verwendet werden, wie in einer Symbolliste angegeben, werden auf Stabilität überwacht und als KMI-Symbole betrachtet.

    • Die logische Folge ist, dass Herstellermodule nur KMI-Symbole verwenden dürfen. Diese Einschränkung wird durch fehlgeschlagene Modulladevorgänge erzwungen, wenn Nicht-KMI-Symbole erforderlich sind.

  • Nachdem der KMI-Zweig eingefroren wurde, sind Änderungen erlaubt, können aber den KMI nicht unterbrechen. Diese Änderungen umfassen Folgendes:

    • Konfigurationsänderungen
    • Kernel-Code-Änderungen
    • Toolchain-Änderungen (einschließlich Updates)

Verwenden Sie den hermetischen Build-Prozess und die LLVM-Toolchain

Der hermetische Build-Prozess stellt ein stabiles KMI sicher, indem repo -Manifeste in kernel/manifest die Build-Umgebung vollständig beschreiben. Beispielsweise enthält das Manifest für android13-5.15 die Toolchain, Build-Skripte und alles andere, was zum Erstellen des Generic Kernel Image (GKI)-Kernels erforderlich ist. Die jeweiligen build.config Konfigurationsdateien, wie z. B. die GKI-Build-Konfiguration build.config.gki.aarch64 , stellen sicher, dass die enthaltenen Tools korrekt verwendet werden, um konsistente Build-Ergebnisse zu generieren.

Die Verwendung eines hermetischen Build-Prozesses stellt auch sicher, dass die ABI-Beschreibung für den Baum konsistent ist, unabhängig davon, ob sie von Google generiert wird (z. B. abi_gki_aarch64.xml für android13-5.15 oder in einem lokalen Baum generiert wird, der die Anbietermodule enthält. Die Tools zum Erstellen und Vergleichen der Die ABI-Beschreibung für das Kernel Module Interface (KMI) wird ebenfalls als Teil des durch das Manifest beschriebenen Repos bereitgestellt.

Die zum Erstellen des GKI-Kernels verwendete Toolchain 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 gebaut werden. Bei GKI muss die zum Erstellen von Produktkerneln und Anbietermodulen verwendete LLVM-Toolchain dieselbe ABI generieren wie die LLVM-Toolchain von AOSP, und Partner müssen sicherstellen, dass die KMI mit dem GKI-Kernel kompatibel ist. Die Verwendung der bereitgestellten Build-Tools wird dringend empfohlen, da sie die Kompatibilitätsgarantien bieten.

Was kommt als nächstes?

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

  • Anweisungen zur Überwachung der ABI und zur Behebung von Problemen finden Sie unter Android Kernel ABI Monitoring