Puoi utilizzare gli strumenti di monitoraggio Application BI (ABI), disponibili in
Android 11 e versioni successive per stabilizzare il kernel nel kernel.
ABI dei kernel Android. Questo strumento raccoglie e confronta le rappresentazioni ABI
da binari del kernel esistenti (vmlinux
+ moduli GKI). Queste ABI
sono i file .stg
e gli elenchi di simboli. L'interfaccia di
che la rappresentazione dà una vista è denominata interfaccia del modulo del kernel
(KMI). Puoi utilizzare gli strumenti per monitorare e mitigare le modifiche al KMI.
Gli strumenti di monitoraggio dell'ABI
sviluppato in AOSP
e utilizza
STG (o
libabigail
in
Android 13 e versioni precedenti) per generare e confrontare
rappresentazioni grafiche.
Questa pagina descrive gli strumenti, il processo di raccolta e analisi dell'ABI e il loro uso per fornire stabilità nell'ABI nel kernel. Questa pagina fornisce inoltre informazioni su come apportare le modifiche necessarie ai kernel Android.
Procedura
L'analisi dell'ABI del kernel prevede più passaggi, la maggior parte dei quali possono essere automatizzati:
- Crea il kernel e la sua rappresentazione ABI.
- Analizza le differenze ABI tra la build e un riferimento.
- Aggiorna la rappresentazione ABI (se richiesto).
- Utilizzare gli elenchi di simboli.
Le seguenti istruzioni sono valide per qualsiasi
kernel che puoi creare utilizzando un
più supportata (come la toolchain Clang predefinita). repo manifests
sono disponibili per tutti i rami del kernel comuni di Android e per diversi
specifici per dispositivo, assicurano che venga utilizzata la toolchain corretta quando si
e creare una distribuzione del kernel per l'analisi.
Elenchi di simboli
Il KMI non include tutti i simboli nel kernel e nemmeno tutti gli oltre 30.000 simboli esportati. Al contrario, i simboli che possono essere utilizzati dai moduli del fornitore sono esplicitamente elencati in un set di file di elenchi di simboli gestiti pubblicamente dell'albero del kernel. L'unione di tutti i simboli in tutti i file di elenco di simboli definisce l'insieme di simboli KMI mantenuti come stabili. Un file di elenco di simboli di esempio sono abi_gki_aarch64_db845c, che dichiara i simboli richiesti per DragonBoard 845c.
Solo i simboli elencati in un elenco di simboli e le relative strutture correlate e le definizioni sono considerate parte del KMI. Puoi caricare le modifiche se quelli necessari non sono presenti. Dopo l'attivazione delle nuove interfacce un elenco di simboli e fanno parte della descrizione KMI, vengono mantenuti e non deve essere rimosso dall'elenco dei simboli o modificato dopo che il ramo è bloccato.
Ogni ramo del kernel KMI del kernel Android Common Kernel (ACK) ha il proprio set di simboli
elenchi. Non viene effettuato alcun tentativo di fornire stabilità ABI tra diversi kernel KMI
rami. Ad esempio, il KMI per android12-5.10
è completamente indipendente
il KMI per android13-5.10
.
Gli strumenti ABI utilizzano gli elenchi di simboli KMI per limitare le interfacce da monitorare
la stabilità. La
elenco dei simboli principali
contiene i simboli richiesti dai moduli del kernel GKI. I fornitori sono
inviare e aggiornare ulteriori elenchi di simboli per garantire che
le interfacce a cui fanno affidamento mantengano la compatibilità ABI. Ad esempio, per vedere un elenco
degli elenchi di simboli per android13-5.15
, consulta
https://android.googlesource.com/kernel/common/+/refs/heads/android13-5.15/android
Un elenco di simboli contiene i simboli indicati come necessari per una determinata fornitore o dispositivo. L'elenco completo utilizzato dagli strumenti è l'unione di tutte le File di elenco dei simboli KMI. Gli strumenti ABI determinano i dettagli di ogni simbolo, tra cui: la firma delle funzioni e le strutture di dati nidificate.
Quando il KMI viene bloccato, non sono consentite modifiche alle interfacce KMI esistenti. sono stabili. Tuttavia, i fornitori sono liberi di aggiungere simboli al KMI in qualsiasi momento purché le aggiunte non influiscano sulla stabilità dell'ABI esistente. Appena aggiunta vengono mantenuti stabili non appena vengono citati in un elenco di simboli KMI. I simboli non devono essere rimossi dall'elenco di un kernel a meno che non sia possibile confermarli che nessun dispositivo è mai stato spedito con una dipendenza da quel simbolo.
Puoi generare un elenco di simboli KMI per un dispositivo utilizzando le istruzioni da Come utilizzare gli elenchi di simboli. Molti partner inviano un elenco di simboli per ogni ACK, ma questo non è un requisito difficile. Se aiuta con la manutenzione, puoi inviare più elenchi di simboli.
Estendi il KMI
Sebbene i simboli KMI e le strutture correlate siano mantenuti come stabili (ovvero modifiche che interrompono le interfacce stabili in un kernel con un KMI bloccato accettato) il kernel GKI rimane aperto alle estensioni in modo che i dispositivi più avanti nel corso dell'anno non dovranno definire tutte le dipendenze prima che bloccato. Per estendere il KMI, puoi aggiungere nuovi simboli per nuovi simboli le funzioni kernel esportate esistenti, anche se il KMI è bloccato. Nuovo kernel Le patch potrebbero essere accettate anche se non interrompono l'KMI.
Informazioni sui malfunzionamenti KMI
Un kernel ha sorgenti e i file binari sono creati da queste origini.
I rami di kernel monitorati da ABI includono una rappresentazione ABI dell'attuale GKI
ABI (sotto forma di file .stg
). Dopo i file binari (vmlinux
, Image
e
qualsiasi modulo GKI) vengono creati, una rappresentazione ABI può essere estratta
file binari. Qualsiasi modifica apportata a un file sorgente kernel può influenzare i file binari
influisce anche sul valore .stg
estratto. L'analizzatore AbiAnalyzer
confronta
ha eseguito il commit di .stg
con quello estratto dagli artefatti di build e imposta un valore
Etichetta Lint-1 sulla modifica in Gerrit se rileva una differenza semantica.
Gestire i malfunzionamenti dell'ABI
Ad esempio, la seguente patch introduce un evidente malfunzionamento dell'ABI:
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.
Quando esegui l'ABI della build con questa patch applicata, gli strumenti si escono con un codice di errore diverso da zero e segnala una differenza ABI simile a questa:
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
Differenze ABI rilevate al momento della creazione
Il motivo più comune di errori è quando un driver utilizza un nuovo simbolo dal che non è in nessuno degli elenchi di simboli.
Se il simbolo non è incluso nell'elenco dei simboli (android/abi_gki_aarch64
),
devi prima verificare che l'esportazione venga eseguita
EXPORT_SYMBOL_GPL(symbol_name)
e poi aggiorna
Rappresentazione XML ABI ed elenco di simboli. Ad esempio, le seguenti modifiche aggiungono
la nuova funzionalità FS incrementale al ramo android-12-5.10
, che
include l'aggiornamento dell'elenco dei simboli e della rappresentazione XML ABI.
- L'esempio di modifica delle funzionalità è disponibile aosp/1345659.
- L'esempio di elenco di simboli è in aosp/1346742.
- L'esempio di modifica XML dell'ABI è in aosp/1349377.
Se il simbolo viene esportato (da te o in precedenza), ma non se un altro driver lo sta utilizzando, potresti ricevere un errore di generazione simile al seguente.
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
Per risolvere il problema, aggiorna l'elenco dei simboli KMI sia nel kernel che nella chiave ACK (vedi Aggiorna la rappresentazione ABI). Ad esempio, per aggiornare l'elenco di simboli e il codice XML di ABI nell'ACK, fai riferimento aosp/1367601.
Risolvi i malfunzionamenti dell'ABI del kernel
Puoi gestire le interruzioni dell'ABI del kernel refactoring del codice per non modificare ABI o aggiornamento della rappresentazione ABI. Utilizza quanto segue per determinare l'approccio migliore per la tua situazione.
Figura 1. Risoluzione di malfunzionamento dell'ABI
Esegui il refactoring del codice per evitare modifiche all'ABI
Fai il possibile per evitare di modificare l'ABI esistente. In molti casi è possibile esegui il refactoring del codice per rimuovere le modifiche che interessano l'ABI.
Modifiche ai campi dello struct di refactoring. Se una modifica modifica l'ABI per un debug aggiungi un
#ifdef
intorno ai campi (negli struct e nelle origini riferimenti) e assicurati che il valoreCONFIG
utilizzato per#ifdef
sia disattivato per defconfig di produzione egki_defconfig
. Per un esempio di come un debug aggiungere una configurazione a uno struct senza danneggiare l'ABI. Fai riferimento a questo set di patch.È necessario eseguire il refactoring delle funzionalità per non modificare il kernel principale. Se le nuove funzionalità richiedono da aggiungere a ACK per supportare i moduli partner, prova a eseguire il refactoring dell'ABI parte della modifica per evitare di modificare l'ABI del kernel. Per un esempio di utilizzo all'ABI del kernel esistente per aggiungere ulteriori funzionalità senza modificare per ABI del kernel si intendono aosp/1312213
Correggere un'ABI non funzionante su Android Gerrit
Se non hai intenzionalmente interrotto l'ABI del kernel, devi indagare, utilizzando le linee guida fornite dagli strumenti di monitoraggio di ABI. Le più comuni le cause dei malfunzionamenti sono le strutture dei dati modificate e il simbolo associato CRC o a causa di modifiche alle opzioni di configurazione che portano a una delle suddette modifiche. Inizia affrontando i problemi rilevati dallo strumento.
Puoi riprodurre i risultati di ABI localmente, consulta Crea il kernel e la sua rappresentazione ABI.
Informazioni sulle etichette Lint-1
Se carichi le modifiche in un ramo contenente un KMI bloccato o finalizzato,
le modifiche devono superare AbiAnalyzer
per garantire che le modifiche non influiscano sulla stabilità
ABI non compatibile. Durante questa procedura, AbiAnalyzer
cerca
Report ABI creato durante la build (una build estesa che esegue
di una normale build e di alcuni passaggi di estrazione e confronto di ABI.
Se AbiAnalyzer
trova un report non vuoto, imposta l'etichetta Lint-1 e
l'invio della modifica viene bloccato fino alla risoluzione; finché il set di patch non riceve
Etichetta Lint + 1.
Aggiorna l'ABI del kernel
Se la modifica dell'ABI è inevitabile, devi applicare le modifiche al codice, la rappresentazione ABI e l'elenco di simboli all'ACK. Per fare in modo che Lint rimuovi -1 senza interrompere la compatibilità con GKI, procedi nel seguente modo:
Attendi di ricevere un Code-Review +2 per il set di patch.
Unisci le modifiche al codice e la modifica di aggiornamento dell'ABI.
Carica modifiche al codice ABI nel ACK
L'aggiornamento dell'ABI ACK dipende dal tipo di modifica apportata.
Se una modifica dell'ABI è correlata a una funzionalità che influisce sui test CTS o VTS, di solito una modifica può essere scelta in ACK così com'è. Ad esempio:
- aosp/1289677 per il corretto funzionamento dell'audio.
- aosp/1295945 per il funzionamento tramite USB.
Se una modifica all'ABI riguarda una caratteristica che può essere condivisa con l'ACK, una modifica può essere scelta in ACK così com'è. Ad esempio, le seguenti modifiche non sono necessari per il test CTS o VTS, ma possono essere condivisi con ACK:
- aosp/1250412 è una modifica delle caratteristiche termiche.
- aosp/1288857
è una modifica di
EXPORT_SYMBOL_GPL
.
Se una modifica all'ABI introduce una nuova funzionalità che non deve essere inclusa in l'ACK, è possibile introdurre i simboli in ACK utilizzando uno stub come descritto la sezione che segue.
Utilizzo di stub per ACK
Gli stb devono essere necessari solo per le modifiche del kernel che non apportano vantaggi al ACK, come le prestazioni e le variazioni di potenza. Di seguito sono riportati alcuni esempi di dettagli di stub e parziali di cherry-pick in ACK per GKI.
Stub della funzionalità di isolamento principale (aosp/1284493). Le funzionalità in ACK non sono necessarie, ma i simboli devono essere presenti in ACK per consentire ai moduli di utilizzare questi simboli.
Simbolo segnaposto per il modulo del fornitore (aosp/1288860).
Selezione della funzionalità di monitoraggio eventi
mm
per processo, solo per ABI (aosp/1288454). La patch originale è stata scelta per ACK e poi tagliata per includere le modifiche necessarie per risolvere le differenze ABI pertask_struct
emm_event_count
. Questa patch aggiorna anche l'enummm_event_type
per contenere i membri finali.Selezione parziale di cambiamenti dell'ABI dello struct termico che hanno richiesto più di una semplice aggiungendo i nuovi campi ABI.
Cerotto aosp/1255544 ha risolto le differenze ABI tra il kernel del partner e ACK.
Cerotto aosp/1291018 sono stati risolti i problemi funzionali rilevati durante il test GKI della patch precedente. La correzione includeva l'inizializzazione dello struct del parametro del sensore da registrare più zone termiche a un singolo sensore.
CONFIG_NL80211_TESTMODE
modifiche all'ABI (aosp/1344321). Questa patch ha aggiunto le modifiche necessarie allo struct per ABI e ha fatto in modo che campi aggiuntivi non hanno causato differenze funzionali, abilitando i partner includereCONFIG_NL80211_TESTMODE
nei loro kernel di produzione e comunque la conformità GKI.
Applica il KMI in fase di runtime
I kernel GKI utilizzano le opzioni di configurazione TRIM_UNUSED_KSYMS=y
e UNUSED_KSYMS_WHITELIST=<union
of all symbol lists>
, che limitano i simboli esportati
(ad esempio simboli esportati con EXPORT_SYMBOL_GPL()
) a quelli elencati in una
dell'elenco dei simboli. Tutti gli altri simboli non vengono esportati e viene caricato un modulo che richiede un
simbolo non esportato è negato. Questa limitazione viene applicata in fase di build
le voci mancanti vengono segnalate.
Ai fini dello sviluppo, puoi usare una build del kernel GKI che non include
tagliare i simboli (il che significa che possono essere utilizzati tutti i simboli solitamente esportati). Per individuare
queste build, cerca le build kernel_debug_aarch64
ci.android.com.
Applica il KMI utilizzando il controllo delle versioni del modulo
I kernel GKI (Generic Kernel Image) usano il controllo delle versioni del modulo
(CONFIG_MODVERSIONS
) come misura aggiuntiva per far rispettare la conformità KMI in
runtime. Il controllo delle versioni del modulo può causare una mancata corrispondenza del controllo di ridondanza ciclico (CRC)
errori al momento del caricamento del modulo se il KMI previsto di un modulo non corrisponde
vmlinux
KMI Ad esempio, di seguito è riportato un tipico errore che si verifica
tempo di caricamento del modulo a causa di una mancata corrispondenza CRC per il simbolo 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 ''
Utilizzi del controllo delle versioni dei moduli
Il controllo delle versioni dei moduli è utile per i seguenti motivi:
Il controllo delle versioni dei moduli rileva le modifiche nella visibilità della struttura dei dati. Se i moduli modificare le strutture di dati opache, ovvero le strutture di dati che non fanno parte KMI si interrompono dopo future modifiche alla struttura.
Ad esempio, considera la classe
fwnode
instruct device
. Questo campo DEVE essere opaco ai moduli in modo che non possano apportare modifiche campi didevice->fw_node
o fare ipotesi sulle sue dimensioni.Tuttavia, se un modulo include
<linux/fwnode.h>
(direttamente o indirettamente), il campofwnode
instruct device
non è più opaco. La modulo può quindi apportare modifiche adevice->fwnode->dev
odevice->fwnode->ops
. Questo scenario è problematico per diversi motivi, indicato come segue:Può interrompere le ipotesi che il codice del kernel core sta facendo in merito alla sua le strutture di dati.
Se un futuro aggiornamento del kernel cambia il
struct fwnode_handle
(i dati di tipofwnode
), il modulo non funziona più con il nuovo kernel. Inoltre,stgdiff
non mostrerà alcuna differenza perché il modulo viola il KMI manipolando direttamente le strutture di dati interni in modi che non semplicemente esaminando la rappresentazione binaria.
Un modulo corrente è considerato incompatibile con KMI quando viene caricato in un secondo momento da un nuovo kernel incompatibile. Il controllo delle versioni del modulo aggiunge un controllo di runtime evitare di caricare accidentalmente un modulo che non è compatibile con KMI con il kernel. Questo controllo impedisce i problemi di runtime e gli arresti anomali del kernel difficili da eseguire che potrebbero sono dovute a un'incompatibilità non rilevata nel KMI.
L'abilitazione del controllo delle versioni dei moduli evita tutti questi problemi.
Verifica la presenza di mancate corrispondenze CRC senza avviare il dispositivo
stgdiff
confronta e segnala le mancate corrispondenze CRC tra i kernel insieme ad altri
Differenze nelle ABI.
Inoltre, una build del kernel completa con CONFIG_MODVERSIONS
abilitato genera un
Module.symvers
nell'ambito del normale processo di compilazione. Questo file ha uno
per ogni simbolo esportato dal kernel (vmlinux
) e dai moduli. Ciascuna
è composta da valore CRC, nome simbolo, spazio dei nomi simbolo, vmlinux
il nome del modulo che esporta il simbolo e il tipo di esportazione (ad esempio,
EXPORT_SYMBOL
contro EXPORT_SYMBOL_GPL
).
Puoi confrontare i file Module.symvers
tra la build GKI e la tua build
per verificare la presenza di differenze CRC nei simboli esportati da vmlinux
. Se ci sono
è una differenza di valore CRC per qualsiasi simbolo esportato da vmlinux
e che
è utilizzato da uno dei moduli caricati sul dispositivo, il modulo non
caricamento.
Se non hai tutti gli artefatti della build, ma hai i file vmlinux
di
sia dal kernel GKI che dal kernel, puoi confrontare i valori CRC per una
eseguendo questo comando sia sui kernel sia confrontando
:
nm <path to vmlinux>/vmlinux | grep __crc_<symbol name>
Ad esempio, il seguente comando verifica il valore CRC per module_layout
simbolo:
nm vmlinux | grep __crc_module_layout
0000000008663742 A __crc_module_layout
Risolvere le mancate corrispondenze dei CRC
Per risolvere una mancata corrispondenza CRC durante il caricamento di un modulo, procedi nel seguente modo:
Crea il kernel GKI e il kernel del dispositivo utilizzando l'
--kbuild_symtypes
come mostrato nel seguente comando:tools/bazel run --kbuild_symtypes //common:kernel_aarch64_dist
Questo comando genera un file
.symtypes
per ogni file.o
. ConsultaKBUILD_SYMTYPES
in Kleaf per maggiori dettagli.Per Android 13 e versioni precedenti della build del kernel GKI e il kernel del dispositivo anteponendo
KBUILD_SYMTYPES=1
al comando per creare il kernel, come mostrato nel seguente comando:KBUILD_SYMTYPES=1 BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
Quando utilizzi
build_abi.sh,
, il flagKBUILD_SYMTYPES=1
è impostato in modo implicito .Trova il file
.c
in cui viene esportato il simbolo con mancata corrispondenza CRC utilizzando il seguente comando:cd common && git grep EXPORT_SYMBOL.*module_layout kernel/module.c:EXPORT_SYMBOL(module_layout);
Il file
.c
ha un file.symtypes
corrispondente nella GKI e il tuo artefatti delle build del kernel del dispositivo. Individua il file.c
utilizzando quanto segue :cd out/$BRANCH/common && ls -1 kernel/module.* kernel/module.o kernel/module.o.symversions kernel/module.symtypes
Di seguito sono riportate le caratteristiche del file
.c
:Il formato del file
.c
è una riga (potenzialmente molto lunga) per simbolo.[s|u|e|etc]#
all'inizio della linea significa che il simbolo è di tipo dati[struct|union|enum|etc]
. Ad esempio:t#bool typedef _Bool bool
Un prefisso
#
mancante all'inizio della riga indica che il simbolo è una funzione. Ad esempio:find_module s#module * find_module ( const char * )
Confronta i due file e correggi tutte le differenze.
Caso 1: differenze dovute alla visibilità del tipo di dati
Se un kernel mantiene un simbolo o un tipo di dati opaco rispetto ai moduli e l'altro
no, questa differenza si verifica tra i file .symtypes
dei due kernel. Il file .symtypes
di uno dei kernel ha UNKNOWN
per un simbolo e il file .symtypes
dell'altro kernel ha una vista espansa
del simbolo o del tipo di dati.
Ad esempio, se aggiungi la riga seguente alla
include/linux/device.h
file nel kernel causa errori di corrispondenza CRC, uno dei quali
è per module_layout()
:
#include <linux/fwnode.h>
Confrontando module.symtypes
per quel simbolo, si espone quanto segue
differenze:
$ 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 ] ; }
...
Se il kernel ha un valore pari a UNKNOWN
e il kernel GKI ha la vista espansa
del simbolo (molto improbabile), quindi unisci l'ultimo kernel comune di Android
del kernel in modo da usare la base kernel GKI più recente.
Nella maggior parte dei casi, il kernel GKI ha il valore UNKNOWN
, ma il kernel ha il
dettagli interni del simbolo a causa di modifiche apportate al kernel. Questo è
perché uno dei file del kernel ha aggiunto un #include
che non è presente
del kernel GKI.
Spesso, la soluzione consiste semplicemente nel nascondere il nuovo #include
da genksyms
.
#ifndef __GENKSYMS__
#include <linux/fwnode.h>
#endif
In caso contrario, per identificare il #include
che causa la differenza, segui questi
passaggi:
Apri il file di intestazione che definisce il simbolo o il tipo di dati con questo valore la differenza. Ad esempio, modifica
include/linux/fwnode.h
per il valorestruct fwnode_handle
.Aggiungi il seguente codice all'inizio del file di intestazione:
#ifdef CRC_CATCH #error "Included from here" #endif
Nel file
.c
del modulo che presenta una mancata corrispondenza CRC, aggiungi il parametro che segue come prima riga prima di qualsiasi riga#include
.#define CRC_CATCH 1
Compila il modulo. L'errore in fase di build risultante mostra la catena di file di intestazione
#include
che ha causato questa mancata corrispondenza del CRC. Ad esempio: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"
Uno dei maglie di questa catena di
#include
è dovuto a una modifica apportata alla tua che manca nel kernel GKI.Identifica la modifica, ripristinala nel kernel caricarla su ACK e farla unire.
Caso 2: differenze dovute alle modifiche dei tipi di dati
Se la mancata corrispondenza CRC per un simbolo o un tipo di dati non è dovuta a una differenza di visibilità, è dovuto a modifiche effettive (aggiunta, rimozioni o modifiche) il tipo di dati stesso.
Ad esempio, apportare la seguente modifica nel kernel provoca diversi CRC perché molti simboli sono indirettamente interessati da questo tipo di modifica:
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);
Una mancata corrispondenza CRC è relativa a devm_of_platform_populate()
.
Se confronti i file .symtypes
per il simbolo in questione, il codice potrebbe avere il seguente aspetto:
$ 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 * ) ; ...
Per identificare il tipo modificato:
Trova la definizione del simbolo nel codice sorgente (di solito nei file
.h
).- Per le differenze di simboli tra il kernel e il kernel GKI, per trovare il commit, esegui questo comando:
git blame
- Per i simboli eliminati (dove un simbolo viene eliminato in un albero e anche nell'altro albero), devi trovare la modifica ha eliminato la riga. Utilizza il seguente comando nell'albero in cui la riga è stata eliminata:
git log -S "copy paste of deleted line/word" -- <file where it was deleted>
Esamina l'elenco di commit restituito per individuare la modifica o l'eliminazione. La il primo commit è probabilmente quello che stai cercando. In caso contrario, vai nell'elenco finché non trovi il commit.
Dopo aver identificato la modifica, ripristinala nel kernel caricarlo su ACK e riceverlo uniti.