A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.

Questa pagina è stata tradotta dall'API Cloud Translation.

Monitoraggio dell'ABI del kernel di Android
Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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. Lo strumento raccoglie e confronta le rappresentazioni ABI dai binari del kernel esistenti (vmlinux+ moduli GKI). Queste ABI sono i file .stg e gli elenchi di simboli. L'interfaccia su cui la rappresentazione fornisce una visualizzazione è chiamata Kernel Module Interface (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 richiede più passaggi, la maggior parte dei quali può essere automatizzata:

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 del kernel o anche tutti i più di 30.000 simboli esportati. I simboli che possono essere utilizzati dai moduli del fornitore sono invece elencati esplicitamente in un insieme di file di elenchi di simboli gestiti pubblicamente nella radice dell'albero del kernel. L'unione di tutti i simboli in tutti i file dell'elenco di simboli definisce l'insieme di simboli KMI mantenuti stabili. Un file di elenco di simboli di esempio è 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 e definizioni sono considerati 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 di Android Common Kernel (ACK) ha il proprio insieme di elenchi di simboli. Non viene effettuato alcun tentativo di fornire stabilità ABI tra diversi kernel KMI rami. Ad esempio, il KMI per android12-5.10 è completamente indipendente dal KMI per android13-5.10.

Gli strumenti ABI utilizzano gli elenchi di simboli KMI per limitare le interfacce da monitorare la stabilità. L'elenco di 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 su cui fanno affidamento mantengono 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 segnalati come necessari per il particolare 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 della funzione 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. I simboli appena aggiunti vengono mantenuti stabili non appena vengono citati da 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 seguendo le istruzioni riportate in Come utilizzare gli elenchi di simboli. Molti partner inviano un elenco di simboli per ogni ACK, ma questo non è un requisito difficile. Se ti è utile per la manutenzione, puoi inviare più elenchi di simboli.

Espandere 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 funzioni di kernel esportate nuove o 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 origini e i binari vengono compilati a partire da queste origini. I rami del kernel monitorati dall'ABI includono una rappresentazione ABI dell'ABI GKI corrente (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 del kernel può influire sui file binari e, a loro volta, anche sul .stg estratto. L'analizzatore AbiAnalyzer confronta il file .stg sottoposto a commit con quello estratto dagli elementi di build e imposta un'etichetta Lint-1 sulla modifica in Gerrit se rileva una differenza semantica.

Gestire i malfunzionamenti dell'ABI

Ad esempio, la patch seguente introduce un'interruzione ABI molto evidente:

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

La causa più comune degli errori si verifica quando un driver utilizza un nuovo simbolo del kernel che non è presente 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 di simboli e della rappresentazione XML ABI.

L'esempio di modifica della funzionalità è in aosp/1345659.
L'esempio di elenco di simboli si trova in aosp/1346742.
L'esempio di modifica XML dell'ABI è in aosp/1349377.

Se il simbolo è esportato (da te o è stato esportato in precedenza) ma nessun altro driver lo utilizza, potresti ricevere un errore di compilazione 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 problemi 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.

Diagramma di flusso per l'interruzione dell'ABI

Figura 1. Risoluzione di malfunzionamento dell'ABI

Esegui il refactoring del codice per evitare modifiche all'ABI

Fai del tuo meglio 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 una configurazione di debug può essere aggiunta a una struct senza violare l'ABI, consulta questo patchset.
Funzionalità di refactoring per non modificare il kernel di base. 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 violato intenzionalmente l'ABI del kernel, devi effettuare accertamenti utilizzando le indicazioni fornite dagli strumenti di monitoraggio dell'ABI. Le cause più comuni di interruzioni sono le modifiche alle strutture di dati e le modifiche al CRC del simbolo associato oppure le modifiche alle opzioni di configurazione che portano a una delle cause sopra indicate. Inizia affrontando i problemi rilevati dallo strumento.

Puoi riprodurre i risultati dell'ABI localmente, consulta Compilare il kernel e la relativa 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 il report ABI creato durante la compilazione (una compilazione estesa che esegue la compilazione normale e poi alcuni passaggi di estrazione e confronto dell'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.

Aggiornare 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 nell'ACK.
Attendi di ricevere un feedback di revisione del codice +2 per il set di patch.
Aggiorna la rappresentazione ABI di riferimento.
Unisci le modifiche al codice e la modifica dell'aggiornamento dell'ABI.

Carica le modifiche al codice ABI nell'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 è necessario per il funzionamento dell'audio.
- aosp/1295945 è necessario per il funzionamento della porta USB.
Se una modifica dell'ABI riguarda una funzionalità che può essere condivisa con l'ACK, la modifica può essere selezionata per l'ACK così com'è. Ad esempio, le seguenti modifiche non sono necessarie per il test CTS o VTS, ma possono essere condivise con l'ACK:
- aosp/1250412 è una modifica della funzionalità termica.
- aosp/1288857 è una modifica EXPORT_SYMBOL_GPL.
Se una modifica dell'ABI introduce una nuova funzionalità che non deve essere inclusa nell'ACK, puoi introdurre i simboli nell'ACK utilizzando uno stub come descritto nella sezione seguente.

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 del nucleo (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).
Scelta accurata della funzionalità di monitoraggio degli eventi mm per processo solo per ABI (aosp/1288454). La patch originale è stata selezionata per ACK e poi tagliata in modo da includere solo le modifiche necessarie per risolvere la differenza ABI per task_struct e mm_event_count. Questa patch aggiorna anche l'enum mm_event_type per contenere i membri finali.
Scelta parziale delle modifiche all'ABI della struttura termica che richiedevano più dell'aggiunta dei 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 ha incluso l'inizializzazione della struttura del parametro del sensore per registrare più zone termiche su 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.

Applicare 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 i simboli esportati utilizzando EXPORT_SYMBOL_GPL()) a quelli elencati in un elenco di simboli. Tutti gli altri simboli non sono esportati e il caricamento di un modulo che richiede un simbolo non esportato viene 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.

Applicare il KMI utilizzando il controllo delle versioni dei moduli

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 errore tipico che si verifica al caricamento del modulo a causa di una mancata corrispondenza del 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:

La gestione delle versioni dei moduli rileva le modifiche alla 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 il campo fwnode in struct device. Questo campo DEVE essere opaco per i moduli in modo che non possano apportare modifiche ai campi di device->fw_node o fare supposizioni sulle relative dimensioni.

Tuttavia, se un modulo include <linux/fwnode.h> (direttamente o indirettamente), il campo fwnode in struct device non è più opaco. Il modulo può quindi apportare modifiche a device->fwnode->dev o device->fwnode->ops. Questo scenario è problematico per diversi motivi, indicato come segue:
- Può interrompere i presupposti 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 attuale è 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 evita problemi di runtime difficili da eseguire il debug e arresti anomali del kernel che potrebbero essere causati da 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 compilazione completa del kernel con CONFIG_MODVERSIONS abilitato genera un Module.symvers file nell'ambito della normale procedura di compilazione. Questo file contiene una riga 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 esiste una differenza di valore CRC in un simbolo esportato da vmlinux e quel simbolo viene utilizzato da uno dei moduli caricati nel dispositivo, il modulo non viene caricato.

Se non disponi di tutti gli elementi di compilazione, ma hai i file vmlinux del kernel GKI e del tuo kernel, puoi confrontare i valori CRC per un simbolo specifico eseguendo il seguente comando su entrambi i kernel e confrontando l'output:

nm <path to vmlinux>/vmlinux | grep __crc_<symbol name>

Ad esempio, il seguente comando controlla il valore CRC per il simbolo module_layout:

nm vmlinux | grep __crc_module_layout
0000000008663742 A __crc_module_layout

Risolvere le mancate corrispondenze dei CRC

Per risolvere una mancata corrispondenza del CRC durante il caricamento di un modulo:

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. Per maggiori dettagli, consulta KBUILD_SYMTYPES in Kleaf.

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 è già impostato implicitamente.
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 i seguenti comandi:
```
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 riga indica che il simbolo è di tipo di 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 contiene UNKNOWN per un simbolo e il file .symtypes dell'altro kernel contiene una vista espansa del simbolo o del tipo di dati.

Ad esempio, l'aggiunta della riga seguente al include/linux/device.h file nel kernel causa mancate corrispondenze CRC, una delle quali è per module_layout():

 #include <linux/fwnode.h>

Il confronto del module.symtypes per quel simbolo mette in evidenza le seguenti 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 accade perché uno dei file del kernel ha aggiunto un #include non presente nel kernel GKI.

Spesso, la soluzione è semplicemente 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 questa 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 con una mancata corrispondenza CRC, aggiungi quanto 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 link di questa catena di #include è dovuto a una modifica apportata al kernel che non è presente nel kernel GKI.

Identifica la modifica, ripristinala nel kernel caricarla su ACK e farla unire.

Caso 2: differenze dovute a modifiche del tipo di dati

Se la mancata corrispondenza CRC per un simbolo o un tipo di dati non è dovuta a una differenza di visibilità, è dovuta a modifiche effettive (aggiunte, rimozioni o modifiche) nel 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 nei simboli tra il kernel e il kernel GKI, trovate il commit eseguendo il seguente 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>
```
Nota: non copiare e incollare le schede.
Esamina l'elenco di commit restituito per individuare la modifica o l'eliminazione. Il primo commit è probabilmente quello che stai cercando. In caso contrario, scorri l'elenco fino a trovare il commit.
Dopo aver identificato la modifica, ripristinala nel kernel caricarlo su ACK e riceverlo uniti.