Sie können ABI-Monitoringtools (Application Binary Interface) verwenden, die in
Android 11 und höher, um den Kernel zu stabilisieren
ABI von Android-Kerneln. Mit dem Tool werden ABI-Darstellungen erfasst und verglichen.
aus vorhandenen Kernel-Binärdateien (vmlinux
+ GKI-Module). Diese ABI
Darstellungen sind die .stg
-Dateien und die Symbollisten. Die Benutzeroberfläche auf
die durch die Darstellung eine Ansicht liefert, wird als Kernel Module Interface bezeichnet.
(KMI). Sie können die Tools verwenden, um Änderungen an der KMI zu verfolgen und zu mindern.
Die Tools zur ABI-Überwachung
entwickelt in AOSP
und verwendet
STG (oder
libabigail
in
Android 13 und niedriger), um Daten zu generieren und zu vergleichen
Darstellungen.
Auf dieser Seite werden die Tools, der Prozess zum Erfassen und Analysieren von ABI, beschrieben. Darstellungen sowie die Verwendung dieser Darstellungen, um die Stabilität der das ABI im Kernel. Auf dieser Seite finden Sie auch Informationen dazu, wie Sie Änderungen beisteuern können. zu den Android-Kerneln.
Prozess
Die Analyse des ABI des Kernels umfasst mehrere Schritte, von denen die meisten automatisiert werden können:
- Erstellen Sie den Kernel und seine ABI-Darstellung.
- Analysiere die ABI-Unterschiede zwischen dem Build und einer Referenz.
- Aktualisieren Sie die ABI-Darstellung (falls erforderlich).
- Mit Symbollisten arbeiten
Die folgende Anleitung gilt für alle
Kernel, den Sie mit einem
unterstützte Toolchain (z. B. die vordefinierte Clang-Toolchain). repo manifests
sind für alle gängigen Kernel-Zweige von Android und für mehrere
gerätespezifischen Kernels eine korrekte Toolchain verwendet, wenn Sie
eine Kernel-Distribution für die Analyse erstellen.
Symbollisten
Die KMI enthält nicht alle Symbole im Kernel oder nicht alle der über 30.000 exportierten Symbolen. Stattdessen können die Anbietermodule die folgenden Symbole verwenden: explizit in einer Reihe von Symbollistendateien aufgeführt sind, die öffentlich im Stammverzeichnis verwaltet werden. des Kernel-Baums. Die Gesamtheit aller Symbole in allen Symbollistendateien definiert die Gruppe von KMI-Symbolen, die als stabil gehalten werden. Beispiel für eine Symbollistendatei ist abi_gki_aarch64_db845c in der die für das Ereignis DragonBoard 845c.
Nur die in einer Symbolliste aufgeführten Symbole und ihre zugehörigen Strukturen und Definitionen werden als Teil der KMI angesehen. Sie können Änderungen hochladen in Ihrem wenn die benötigten Symbole nicht vorhanden sind. Wenn neue Benutzeroberflächen verfügbar sind und Teil der KMI-Beschreibung sind, bleiben sie stabil, und dürfen nicht aus der Symbolliste entfernt oder nach der Erstellung des Zweigs geändert werden. eingefroren.
Jeder KMI-Kernel-Zweig von Android Common Kernel (ACK) hat einen eigenen Satz von Symbolen
Listen. Es wird nicht versucht, ABI-Stabilität zwischen verschiedenen KMI-Kernels zu ermöglichen
Zweige. Die KMI für android12-5.10
ist beispielsweise völlig unabhängig von
die KMI für android13-5.10
.
ABI-Tools verwenden KMI-Symbollisten, um einzuschränken, welche Schnittstellen überwacht werden müssen
Stabilität. Die
Liste der Hauptsymbole
enthält die Symbole, die für die GKI-Kernelmodule erforderlich sind. Zulieferunternehmen
zusätzliche Symbollisten einreichen und aktualisieren, um sicherzustellen,
Sie benötigen die ABI-Kompatibilität
der Schnittstellen, auf die sie angewiesen sind. Um beispielsweise eine Liste mit
der Symbollisten für android13-5.15
, siehe
https://android.googlesource.com/kernel/common/+/refs/heads/android13-5.15/android
Eine Symbolliste enthält die Symbole, die für den jeweiligen Anbieter oder Gerät. Die von den Tools verwendete Liste umfasst alle KMI-Symbollistendateien. ABI-Tools bestimmen die Details jedes Symbols, einschließlich Funktionssignatur und verschachtelte Datenstrukturen.
Wenn die KMI eingefroren ist, sind keine Änderungen an den vorhandenen KMI-Schnittstellen zulässig. sie sind stabil. Anbieter dürfen der KMI jedoch jederzeit Symbole hinzufügen. solange Ergänzungen die Stabilität des bestehenden ABI nicht beeinträchtigen. Neu hinzugefügt -Symbole werden so stabil gehalten, dass sie in einer KMI-Symbolliste zitiert werden. Symbole sollten nur dann aus einer Liste für einen Kernel entfernt werden, wenn dies bestätigt werden kann. dass noch nie ein Gerät mit einer Abhängigkeit von diesem Symbol geliefert wurde.
Sie können eine KMI-Symbolliste für ein Gerät erstellen. Folgen Sie dazu der Anleitung unter Informationen zur Verwendung von Symbollisten Viele Partner reichen eine Symbolliste pro Bestätigung ein. Dies ist jedoch keine zwingende Anforderung. Wenn dies bei der Wartung hilft, kannst du mehrere Symbollisten einreichen.
KMI verlängern
Während KMI-Symbole und verwandte Strukturen stabil bleiben (d. h. Änderungen, die stabile Schnittstellen in einem Kernel mit einer eingefrorenen KMI zerstören, können nicht akzeptiert) Der GKI-Kernel bleibt für Erweiterungen offen, sodass die Geräte nicht alle Abhängigkeiten definieren müssen, bevor die KMI eingefroren. Um die KMI zu erweitern, können Sie neue Symbole für neue oder vorhandene exportierte Kernel-Funktionen nutzen, auch wenn die KMI eingefroren ist. Neuer Kernel Patches werden möglicherweise auch akzeptiert, wenn sie die KMI nicht unterbrechen.
Informationen zu KMI-Fehlern
Ein Kernel hat Quellen und Binärdateien werden aus diesen Quellen erstellt.
ABI-überwachte Kernel-Zweige enthalten eine ABI-Darstellung der aktuellen GKI
ABI (in Form einer .stg
-Datei). Nach den Binärdateien (vmlinux
, Image
und
GKI-Modulen erstellt werden, kann eine ABI-Darstellung aus dem
Binärdateien. Jede Änderung, die an einer Kernel-Quelldatei vorgenommen wird, kann sich auf die Binärdateien und in
wirken sich auch auf die extrahierten .stg
aus. Das AbiAnalyzer
-Analysetool vergleicht die Messwerte
hat mit der aus Build-Artefakten extrahierten Datei .stg
einen Commit durchgeführt und ein
Lint-1-Label für die Änderung in Gerrit, wenn ein semanischer Unterschied festgestellt wird.
Mit ABI-Problemen umgehen
Der folgende Patch führt beispielsweise zu einem sehr offensichtlichen ABI-Fehler:
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 42786e6364ef..e15f1d0f137b 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -657,6 +657,7 @@ struct mm_struct {
ANDROID_KABI_RESERVE(1);
} __randomize_layout;
+ int tickle_count;
/*
* The mm_cpumask needs to be at the end of mm_struct, because it
* is dynamically sized based on nr_cpu_ids.
Wenn Sie den Build ABI mit diesem Patch ausführen, wird das Tool mit Fehlercode ungleich null und meldet einen ABI-Unterschied wie diesen:
function symbol 'struct block_device* I_BDEV(struct inode*)' changed
CRC changed from 0x8d400dbd to 0xabfc92ad
function symbol 'void* PDE_DATA(const struct inode*)' changed
CRC changed from 0xc3c38b5c to 0x7ad96c0d
function symbol 'void __ClearPageMovable(struct page*)' changed
CRC changed from 0xf489e5e8 to 0x92bd005e
... 4492 omitted; 4495 symbols have only CRC changes
type 'struct mm_struct' changed
byte size changed from 992 to 1000
member 'int tickle_count' was added
member 'unsigned long cpu_bitmap[0]' changed
offset changed by 64
Beim Build-Zeitpunkt erkannte ABI-Unterschiede
Der häufigste Grund für Fehler ist, wenn ein Fahrer ein neues Symbol aus der der nicht in einer der Symbollisten enthalten ist.
Wenn das Symbol nicht in der Symbolliste (android/abi_gki_aarch64
) enthalten ist,
müssen Sie zunächst überprüfen, ob der Export
EXPORT_SYMBOL_GPL(symbol_name)
und aktualisieren Sie dann den
ABI-XML-Darstellung und Symbolliste. Die folgenden Änderungen fügen beispielsweise
das neue Feature „Inkrementeller FS“ zum Zweig android-12-5.10
,
die Aktualisierung der Symbolliste und der ABI-XML-Darstellung umfasst.
- Das Beispiel für eine Funktionsänderung ist in aosp/1345659
- Beispiel für Symbolliste: aosp/1346742
- Das Beispiel für eine ABI-XML-Änderung befindet sich in aosp/1349377
Wenn das Symbol exportiert wurde (entweder von Ihnen oder zuvor), aber nicht verwendet wird, erhalten Sie möglicherweise einen Build-Fehler wie den folgenden.
Comparing the KMI and the symbol lists:
+ build/abi/compare_to_symbol_list out/$BRANCH/common/Module.symvers out/$BRANCH/common/abi_symbollist.raw
ERROR: Differences between ksymtab and symbol list detected!
Symbols missing from ksymtab:
Symbols missing from symbol list:
- simple_strtoull
Um dieses Problem zu beheben, aktualisieren Sie die KMI-Symbolliste in Ihrem Kernel und in der ACK (siehe Aktualisieren Sie die ABI-Darstellung. Beispiel der ABI-XML und der Symbolliste in der ACK erhalten Sie unter aosp/1367601
Kernel-ABI-Ausfälle beheben
Sie können Kernel-ABI-Ausfälle beheben, indem Sie den Code so refaktorieren, dass der ABI oder die ABI-Darstellung aktualisieren Verwenden Sie Folgendes: Diagramm, um den besten Ansatz für Ihre Situation zu ermitteln.
Abbildung 1: Fehlerbehebung bei Problemen mit ABI
Code refaktorieren, um ABI-Änderungen zu vermeiden
Ergreife alles daran, das bestehende ABI nicht zu modifizieren. In vielen Fällen können Sie Ihren Code refaktorieren, um Änderungen zu entfernen, die sich auf das ABI auswirken.
Änderungen des Strukturfelds refaktorieren: Wenn eine Änderung das ABI für eine Fehlerbehebung ändert fügen Sie einen
#ifdef
um die Felder (in den Strukturen und der Quelle) Referenzen) und achten Sie darauf, dass die für#ifdef
verwendeteCONFIG
für Production defconfig undgki_defconfig
Ein Beispiel für eine Fehlerbehebung Konfiguration kann einer Struktur hinzugefügt werden, ohne das ABI zu unterbrechen. Weitere Informationen patchsetRefaktorierung von Funktionen, damit der Kern-Kernel nicht geändert wird. Wenn neue Funktionen das ACK zur Unterstützung der Partnermodule hinzugefügt werden soll, versuche, das ABI zu refaktorieren ein Teil der Änderung ist, um die Kernel-ABI nicht zu modifizieren. Ein Beispiel für die Verwendung von dem vorhandenen Kernel-ABI, um zusätzliche Funktionen hinzuzufügen, ohne den Kernel ABI beziehen sich auf aosp/1312213.
Defektes ABI auf Android Gerrit reparieren
Wenn Sie den Kernel-ABI nicht absichtlich durchbrochen haben, müssen Sie ihn untersuchen, anhand der Vorgaben der ABI-Monitoringtools. Am häufigsten Ursachen für Brüche sind geänderte Datenstrukturen und das zugehörige Symbol CRC. oder aufgrund von Änderungen an den Konfigurationsoptionen, die zu einem der oben genannten Punkte führen. Beheben Sie zuerst die vom Tool gefundenen Probleme.
Sie können die ABI-Ergebnisse lokal reproduzieren, Erstellen Sie den Kernel und seine ABI-Darstellung.
Informationen zu Lint-1-Labels
Wenn Sie Änderungen an einem Zweig hochladen, der eine eingefrorene oder abgeschlossene KMI enthält,
Änderungen müssen den AbiAnalyzer
übergeben, damit sie sich nicht auf die stabile Version auswirken
ABI nicht kompatibel ist. Während dieses Vorgangs sucht AbiAnalyzer
nach dem
ABI-Bericht, der während des Build-Prozesses erstellt wird (ein erweiterter Build, der den
normalen Build und dann einige ABI-Extraktions- und Vergleichsschritte.
Wenn AbiAnalyzer
einen nicht leeren Bericht findet, werden das Lint-1-Label und die
Die Änderung kann erst eingereicht werden, wenn sie behoben ist. bis das Patch-Set eine
Lint+1-Label.
Kernel-ABI aktualisieren
Wenn eine Änderung des ABI unvermeidbar ist, müssen Sie Ihre Codeänderungen anwenden, die ABI-Darstellung und die Symbolliste an das ACK. Damit Lint Entfernen Sie „-1“, ohne die GKI-Kompatibilität zu beeinträchtigen, und gehen Sie so vor:
Warten Sie, bis Sie eine Code-Review +2 für das Patchset erhalten.
Führen Sie Ihre Codeänderungen und die ABI-Aktualisierungsänderung zusammen.
Änderungen am ABI-Code in die Bestätigung hochladen
Die Aktualisierung der ACK ABI hängt von der Art der vorgenommenen Änderung ab.
Wenn eine ABI-Änderung mit einer Funktion zusammenhängt, die sich auf CTS- oder VTS-Tests auswirkt, Änderung kann in der Regel selektiv zum Bestätigen bestätigt werden. Hier einige Beispiele:
- aosp/1289677 ist erforderlich, damit Audio funktioniert.
- aosp/1295945 ist erforderlich, damit USB funktioniert.
Wenn eine ABI-Änderung für eine Funktion gilt, die mit dem ACK geteilt werden kann, können Sie die Änderung unverändert übernehmen. Durch die folgenden Änderungen sind für CTS- oder VTS-Tests nicht erforderlich, können aber an ACK weitergegeben werden:
- aosp/1250412 ist die Veränderung der Wärmefunktion.
- aosp/1288857
ist eine
EXPORT_SYMBOL_GPL
-Änderung.
Wenn durch eine ABI-Änderung eine neue Funktion eingeführt wird, die nicht in die ACK haben, können Sie die ACK-Symbole mithilfe eines Stubs einführen, wie in im folgenden Abschnitt an.
Stubs für ACK verwenden
Stubs dürfen nur für Core-Kernel-Änderungen erforderlich sein, von denen der ACK, wie z. B. Leistungs- und Energieänderungen. Die folgende Liste enthält Beispiele und teilweise Kirschpickel in ACK für GKI.
Funktions-Stub zur Kernisolierung (aosp/1284493) Die Funktionen in ACK sind nicht erforderlich, aber die Symbole müssen vorhanden sein. in ACK, damit Ihre Module diese Symbole verwenden.
Platzhaltersymbol für Anbietermodul (aosp/1288860)
Nur für ABI verfügbare
mm
-Ereignis-Tracking-Funktion pro Prozess (aosp/1288454) Das ursprüngliche Patch wurde sorgfältig ausgewählt und dann so zugeschnitten, dass es nur die notwendigen Änderungen, um den ABI-Differenz fürtask_struct
undmm_event_count
. Dieser Patch aktualisiert auch die Aufzählungmm_event_type
so, dass sie Folgendes enthält: den Endmitgliedern gerecht zu werden.Teilweise charakteristische Änderungen an der Thermostruktur-ABI, für die mehr als nur eine Änderung erforderlich war und die neuen ABI-Felder.
Pflaster aosp/1255544 ABI-Unterschiede zwischen dem Partner-Kernel und ACK behoben.
Pflaster aosp/1291018 Wir haben die Funktionsprobleme behoben, die bei den GKI-Tests des vorherigen Patches festgestellt wurden. Zur Problembehebung wurde die zu registrierende Sensorparameterstruktur initialisiert mit einem Sensor verbinden.
CONFIG_NL80211_TESTMODE
ABI-Änderungen (aosp/1344321) Dieser Patch fügte die notwendigen Strukturänderungen für ABI hinzu und stellte sicher, dass der zusätzliche Felder keine Funktionsunterschiede, sodass PartnerCONFIG_NL80211_TESTMODE
in ihre Produktions-Kernel aufzunehmen und trotzdem GKI-Compliance aufrechterhalten
KMI während der Laufzeit erzwingen
Die GKI-Kernels verwenden die Konfigurationsoptionen TRIM_UNUSED_KSYMS=y
und UNUSED_KSYMS_WHITELIST=<union
of all symbol lists>
, die die exportierten Symbole begrenzen
(z. B. mit EXPORT_SYMBOL_GPL()
exportierte Symbole) und die in einem
Symbolliste. Alle anderen Symbole werden nicht exportiert und für das Laden eines Moduls ist ein
nicht exportiertes Symbol abgelehnt wird. Diese Einschränkung wird zum Build-Zeitpunkt erzwungen und
fehlende Einträge werden gekennzeichnet.
Für Entwicklungszwecke können Sie einen GKI-Kernel-Build verwenden, der keine
das heißt, dass alle sonst exportierten Symbole verwendet werden können. Um zu finden,
suchen Sie nach den kernel_debug_aarch64
-Builds auf
ci.android.com auf.
KMI durch Modulversionsverwaltung erzwingen
Die GKI-Kernel (Generic Kernel Image) verwenden die Modulversionsverwaltung.
(CONFIG_MODVERSIONS
) als zusätzliche Maßnahme zur Durchsetzung der KMI-Compliance unter
Laufzeit. Modulversionsverwaltung kann zu einer Abweichung bei der zyklischen Redundanzprüfung (Cyclic Redundant Check, CRC) führen
Fehler beim Laden des Moduls, wenn die erwartete KMI eines Moduls nicht mit dem
vmlinux
KMI. Folgendes Beispiel zeigt einen typischen Fehler, der bei
Ladezeit des Moduls aufgrund einer CRC-Abweichung für das Symbol module_layout()
:
init: Loading module /lib/modules/kernel/.../XXX.ko with args ""
XXX: disagrees about version of symbol module_layout
init: Failed to insmod '/lib/modules/kernel/.../XXX.ko' with args ''
Vorteile der Modulversionsverwaltung
Die Modulversionsverwaltung ist aus folgenden Gründen nützlich:
Mit der Modulversionsverwaltung werden Änderungen an der Sichtbarkeit der Datenstruktur erfasst. Wenn-Module undurchsichtige Datenstrukturen zu ändern, also Datenstrukturen, KMI sind nach zukünftigen Änderungen an der Struktur kaputt.
Ein Beispiel ist die
fwnode
. Feld instruct device
. Dieses Feld MUSS für Module undurchsichtig sein, damit keine Änderungen vorgenommen werden können.device->fw_node
-Feldern oder Annahmen über die Größe treffen.Wenn ein Modul jedoch
<linux/fwnode.h>
enthält (direkt oder indirekt), dann ist das Feldfwnode
instruct device
nicht mehr undurchsichtig. Die kann dann Änderungen andevice->fwnode->dev
vornehmen oderdevice->fwnode->ops
. Dieses Szenario ist aus mehreren Gründen problematisch, wie folgt angegeben:Sie kann Annahmen des zentralen Kernel-Codes bezüglich seiner internen Datenstrukturen.
Wenn ein zukünftiges Kernel-Update den
struct fwnode_handle
(die Daten Typfwnode
), funktioniert das Modul nicht mehr mit dem neuen Kernel. Außerdem werden instgdiff
keine Unterschiede angezeigt, da das Modul nicht funktioniert. durch direkte Manipulation interner Datenstrukturen, nur durch Überprüfung der Binärdarstellung erfasst werden.
Ein aktuelles Modul gilt als KMI-inkompatibel, wenn es zu einem späteren Zeitpunkt geladen wird weil der Kernel nicht kompatibel ist. Durch die Modulversionsverwaltung wird Vermeiden Sie es, versehentlich ein Modul zu laden, das nicht mit dem Kernel kompatibel ist. Diese Prüfung verhindert schwer zu behebende Laufzeitprobleme und Kernel-Abstürze, die das Ergebnis einer nicht erkannten Inkompatibilität im KMI.
Durch die Aktivierung der Modulversionsverwaltung können all diese Probleme vermieden werden.
Nach CRC-Abweichungen suchen, ohne das Gerät zu starten
stgdiff
vergleicht und meldet CRC-Abweichungen zwischen Kerneln und anderen
ABI-Unterschiede.
Darüber hinaus generiert ein vollständiger Kernel-Build mit aktiviertem CONFIG_MODVERSIONS
ein
Module.symvers
als Teil des normalen Build-Prozesses. Diese Datei enthält eine
für jedes Symbol, das vom Kernel (vmlinux
) und den Modulen exportiert wurde. Jedes
besteht aus dem CRC-Wert, dem Symbolnamen, dem Symbol-Namespace, dem vmlinux
- oder
Modulname, in dem das Symbol exportiert wird, und der Exporttyp (z. B.
EXPORT_SYMBOL
gegen EXPORT_SYMBOL_GPL
).
Sie können die Module.symvers
-Dateien des GKI-Builds mit Ihrem Build vergleichen.
um nach CRC-Unterschieden in den von vmlinux
exportierten Symbolen zu suchen. Wenn es
ist eine CRC-Wertdifferenz zwischen allen von vmlinux
exportierten Symbolen und, die
-Symbol von einem der Module verwendet wird, die Sie in Ihr Gerät laden, wird das Modul nicht
laden.
Wenn Sie nicht alle Build-Artefakte haben, aber die vmlinux
-Dateien
GKI-Kernel und Ihren Kernel haben, können Sie die CRC-Werte für einen bestimmten
indem Sie den folgenden Befehl für beide Kernel ausführen und die Werte
Ausgabe:
nm <path to vmlinux>/vmlinux | grep __crc_<symbol name>
Mit dem folgenden Befehl wird beispielsweise der CRC-Wert für module_layout
geprüft.
Symbol:
nm vmlinux | grep __crc_module_layout
0000000008663742 A __crc_module_layout
CRC-Abweichungen beheben
Führen Sie die folgenden Schritte aus, um eine CRC-Abweichung beim Laden eines Moduls zu beheben:
GKI-Kernel und Gerätekernel mit der
--kbuild_symtypes
erstellen wie im folgenden Befehl gezeigt:tools/bazel run --kbuild_symtypes //common:kernel_aarch64_dist
Mit diesem Befehl wird für jede
.o
-Datei eine.symtypes
-Datei generiert. Weitere Informationen finden Sie unterKBUILD_SYMTYPES
in Kleaf .Erstellen Sie für Android 13 und niedriger den GKI-Kernel. und Ihren Geräte-Kernel, indem Sie
KBUILD_SYMTYPES=1
dem Befehl verwenden, um den Kernel zu erstellen, wie im folgenden Befehl gezeigt:KBUILD_SYMTYPES=1 BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
Bei Verwendung von
build_abi.sh,
wird das FlagKBUILD_SYMTYPES=1
implizit festgelegt bereits.Suchen Sie die Datei
.c
, in die das Symbol mit nicht übereinstimmender CRC-Datei exportiert wird, mithilfe von folgenden Befehl:cd common && git grep EXPORT_SYMBOL.*module_layout kernel/module.c:EXPORT_SYMBOL(module_layout);
Die Datei
.c
hat eine entsprechende.symtypes
-Datei in der GKI und Ihr Build-Artefakte des Geräte-Kernels. Suchen Sie die Datei.c
mit folgendem Befehl: Befehle:cd out/$BRANCH/common && ls -1 kernel/module.* kernel/module.o kernel/module.o.symversions kernel/module.symtypes
Die Datei
.c
hat folgende Merkmale:Die Datei
.c
hat das Format einer (möglicherweise sehr langen) Zeile pro Symbol.[s|u|e|etc]#
am Anfang der Zeile bedeutet, dass das Symbol den Datentyp hat[struct|union|enum|etc]
. Beispiel:t#bool typedef _Bool bool
Ein fehlendes Präfix
#
am Anfang der Zeile weist darauf hin, dass das Symbol ist eine Funktion. Beispiel:find_module s#module * find_module ( const char * )
Vergleichen Sie die beiden Dateien und beheben Sie alle Unterschiede.
Fall 1: Unterschiede aufgrund der Sichtbarkeit des Datentyps
Wenn ein Kernel ein Symbol oder einen Datentyp für die Module undurchsichtig und der andere
nicht, tritt der Unterschied zwischen den .symtypes
-Dateien auf
der beiden Kernel an. Die Datei .symtypes
von einem der Kernel enthält UNKNOWN
.
für ein Symbol und die Datei .symtypes
aus dem anderen Kernel hat eine erweiterte Ansicht
des Symbols oder Datentyps.
Fügen Sie beispielsweise die folgende Zeile zum
Die Datei include/linux/device.h
in Ihrem Kernel verursacht CRC-Abweichungen. Unter anderem
ist für module_layout()
:
#include <linux/fwnode.h>
Wenn Sie das module.symtypes
für dieses Symbol vergleichen, sehen Sie Folgendes:
Unterschiede:
$ diff -u <GKI>/kernel/module.symtypes <your kernel>/kernel/module.symtypes
--- <GKI>/kernel/module.symtypes
+++ <your kernel>/kernel/module.symtypes
@@ -334,12 +334,15 @@
...
-s#fwnode_handle struct fwnode_handle { UNKNOWN }
+s#fwnode_reference_args struct fwnode_reference_args { s#fwnode_handle * fwnode ; unsigned int nargs ; t#u64 args [ 8 ] ; }
...
Wenn Ihr Kernel den Wert UNKNOWN
und der GKI-Kernel die erweiterte Ansicht hat
des Symbols (sehr unwahrscheinlich) ein und führen Sie dann den neuesten Android Common Kernel in
Ihren Kernel, sodass Sie die neueste GKI-Kernel-Basis verwenden.
In den meisten Fällen hat der GKI-Kernel den Wert UNKNOWN
, während Ihr Kernel den
interne Details des Symbols aufgrund von Änderungen an Ihrem Kernel. Dies ist
da eine der Dateien in Ihrem Kernel ein #include
hinzugefügt hat, das in
des GKI-Kernels.
Häufig wird das Problem dadurch behoben, dass der neue #include
vor genksyms
ausgeblendet wird.
#ifndef __GENKSYMS__
#include <linux/fwnode.h>
#endif
Andernfalls können Sie die #include
, die den Unterschied verursachen, folgendermaßen ermitteln:
Schritte:
Öffnen Sie die Headerdatei, in der das Symbol oder der Datentyp definiert ist, Unterschied. Bearbeiten Sie z. B.
include/linux/fwnode.h
für diestruct fwnode_handle
.Fügen Sie oben in der Headerdatei den folgenden Code ein:
#ifdef CRC_CATCH #error "Included from here" #endif
Fügen Sie in der Datei
.c
des Moduls mit einer CRC-Abweichung den Parameter gefolgt als erste Zeile vor einer der#include
-Zeilen.#define CRC_CATCH 1
Kompilieren Sie Ihr Modul. Der resultierende Build-Zeit-Fehler zeigt die Kette von Headerdatei
#include
, die zu dieser CRC-Abweichung geführt hat. Beispiel:In file included from .../drivers/clk/XXX.c:16:` In file included from .../include/linux/of_device.h:5: In file included from .../include/linux/cpu.h:17: In file included from .../include/linux/node.h:18: .../include/linux/device.h:16:2: error: "Included from here" #error "Included from here"
Eines der Glieder in dieser Kette von
#include
ist auf eine Änderung an Ihrem das im GKI-Kernel fehlt.Identifizieren Sie die Änderung, machen Sie sie im Kernel rückgängig oder laden Sie es in ACK hoch und führen Sie es zusammen.
Fall 2: Unterschiede aufgrund von Datentypänderungen
Wenn die CRC-Abweichung für ein Symbol oder einen Datentyp nicht auf einen Unterschied in dann liegt das an tatsächlichen Änderungen (Ergänzungen, Löschungen oder Änderungen) den Datentyp selbst.
Die folgende Änderung in Ihrem Kernel verursacht beispielsweise mehrere CRC-Fehler. stimmt nicht überein, da von dieser Art von Änderung indirekt viele Symbole betroffen sind:
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -259,7 +259,7 @@ struct iommu_ops {
void (*iotlb_sync)(struct iommu_domain *domain);
phys_addr_t (*iova_to_phys)(struct iommu_domain *domain, dma_addr_t iova);
phys_addr_t (*iova_to_phys_hard)(struct iommu_domain *domain,
- dma_addr_t iova);
+ dma_addr_t iova, unsigned long trans_flag);
int (*add_device)(struct device *dev);
void (*remove_device)(struct device *dev);
struct iommu_group *(*device_group)(struct device *dev);
Eine CRC-Abweichung gilt für devm_of_platform_populate()
.
Wenn Sie die .symtypes
-Dateien für dieses Symbol vergleichen, könnte das so aussehen:
$ diff -u <GKI>/drivers/of/platform.symtypes <your kernel>/drivers/of/platform.symtypes
--- <GKI>/drivers/of/platform.symtypes
+++ <your kernel>/drivers/of/platform.symtypes
@@ -399,7 +399,7 @@
...
-s#iommu_ops struct iommu_ops { ... ; t#phy
s_addr_t ( * iova_to_phys_hard ) ( s#iommu_domain * , t#dma_addr_t ) ; int
( * add_device ) ( s#device * ) ; ...
+s#iommu_ops struct iommu_ops { ... ; t#phy
s_addr_t ( * iova_to_phys_hard ) ( s#iommu_domain * , t#dma_addr_t , unsigned long ) ; int ( * add_device ) ( s#device * ) ; ...
So ermitteln Sie den geänderten Typ:
Die Definition des Symbols findest du im Quellcode (normalerweise in
.h
-Dateien).- Für Symbolunterschiede zwischen Ihrem Kernel und dem GKI-Kernel: Ermitteln Sie den Commit mit folgendem Befehl:
git blame
- Für gelöschte Symbole (wenn ein Symbol in einem Baum gelöscht wird und Sie auch im anderen Baum löschen möchten), müssen Sie die Änderung finden, hat die Zeile gelöscht. Führen Sie den folgenden Befehl in der Baumstruktur aus, in der sich die Zeile wurde gelöscht:
git log -S "copy paste of deleted line/word" -- <file where it was deleted>
Überprüfen Sie die zurückgegebene Liste der Commits, um die Änderung oder Löschung zu finden. Die ist wahrscheinlich derjenige, nach dem Sie suchen. Ist dies nicht der Fall, bis Sie das Commit gefunden haben.
Nachdem Sie die Änderung identifiziert haben, machen Sie sie entweder im Kernel rückgängig oder in ACK hochladen und abrufen zusammengeführt wurden.