Questa pagina è stata tradotta dall'API Cloud Translation.

Monitoraggio dell'ABI con kernel Android

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:

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.

Grafico di flusso di interruzione ABI

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 valore CONFIG utilizzato per #ifdef sia disattivato per defconfig di produzione e gki_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:

Carica le modifiche al codice nel ACK.
Attendi di ricevere un Code-Review +2 per il set di patch.
Aggiorna la rappresentazione ABI di riferimento.
Unisci le modifiche al codice e la modifica di aggiornamento dell'ABI.

di Gemini Advanced.

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 per task_struct e mm_event_count. Questa patch aggiorna anche l'enum mm_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 includere CONFIG_NL80211_TESTMODE nei loro kernel di produzione e comunque la conformità GKI.

di Gemini Advanced.

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 in struct device. Questo campo DEVE essere opaco ai moduli in modo che non possano apportare modifiche campi di device->fw_node o fare ipotesi sulle sue dimensioni.

Tuttavia, se un modulo include <linux/fwnode.h> (direttamente o indirettamente), il campo fwnode in struct device non è più opaco. La modulo può quindi apportare modifiche a device->fwnode->dev o device->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 tipo fwnode), 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. Consulta KBUILD_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 flag KBUILD_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.

di Gemini Advanced.

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 valore struct 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:
di Gemini Advanced.
```
git log -S "copy paste of deleted line/word" -- <file where it was deleted>
```
Nota: non copiare e incollare le schede.
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.