Es ist wichtig, einen stabilen KMI für Anbietermodule aufrechtzuerhalten. Der GKI-Kernel wird in binärer Form erstellt und ausgeliefert, und vom Anbieter ladbare Module werden in einem separaten Baum erstellt. Der resultierende GKI-Kernel und die Herstellermodule müssen so funktionieren, als wären sie zusammen erstellt worden.
Im Allgemeinen missbilligt die Linux-Community die Vorstellung einer Kernel-ABI-Stabilität für den Hauptkernel. Angesichts unterschiedlicher Toolchains, Konfigurationen und eines sich ständig weiterentwickelnden Linux-Mainline-Kernels ist es nicht möglich, einen stabilen KMI in der Mainline aufrechtzuerhalten. Mit den folgenden Einschränkungen ist es jedoch möglich, einen stabilen 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.10oderandroid13-5.15.- Für
android-mainlinewird keine KMI-Stabilität aufrechterhalten.
- Für
Zum Erstellen von Kernel und Modulen wird nur die spezifische Clang- Toolchain verwendet, die in AOSP bereitgestellt und für den entsprechenden Zweig definiert wird.
Nur Symbole, von denen bekannt ist, dass sie von in einer Symbolliste angegebenen Modulen verwendet werden, werden auf Stabilität überwacht und als KMI-Symbole betrachtet.
- Die Konsequenz daraus ist, dass Anbietermodule 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 ist, sind Änderungen zulässig, können den KMI jedoch nicht beschädigen. Diese Änderungen umfassen Folgendes:
- Konfigurationsänderungen
- Änderungen am Kernel-Code
- Toolchain-Änderungen (einschließlich Updates)
Nutzen Sie den hermetischen Build-Prozess und die LLVM-Toolchain
Der hermetische Build-Prozess gewährleistet ein stabiles KMI, indem repo Manifeste im kernel/manifest die Build-Umgebung vollständig beschreiben. Das Manifest für android13-5.15 enthält beispielsweise die Toolchain, Build-Skripte und alles andere, was zum Erstellen des Generic Kernel Image (GKI)-Kernels erforderlich ist. Die entsprechenden build.config Konfigurationsdateien, beispielsweise 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 außerdem sicher, dass die ABI-Beschreibung für den Baum 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 Baum generiert wurde, der die Anbietermodule enthält. Die Tools zum Erstellen und Vergleichen der Die ABI-Beschreibung für das Kernel Module Interface (KMI) wird auch als Teil des im Manifest beschriebenen Repos bereitgestellt.
Die zum Erstellen des GKI-Kernels verwendete Toolchain muss vollständig kompatibel mit der Toolchain 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, denselben 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 diese Kompatibilitätsgarantien bieten.
Was kommt als nächstes?
Anweisungen zum Erstellen des Kernels mithilfe des hermetischen Build-Prozesses und der LLVM-Toolchain finden Sie unter „Kernel erstellen“ .
Anweisungen zum Überwachen des ABI und zum Beheben von Problemen finden Sie unter Android Kernel ABI Monitoring