Esistono due tipi di moduli del kernel: moduli GKI indipendenti dall'hardware e moduli del fornitore specifici per l'hardware. Questa pagina fornisce una panoramica di entrambi i tipi di moduli.
Moduli GKI
I moduli di immagini kernel generiche (GKI) vengono utilizzati per fornire funzionalità del kernel non richieste per l'avvio separate dal kernel di base generico. Con i moduli GKI puoi scegliere funzionalità kernel specifiche da usare, spesso riducendo le dimensioni dell'immagine kernel e il consumo della memoria di runtime. Grazie alla riduzione delle dimensioni, GKI è particolarmente adatto a dispositivi Android Go e ad altri fattori di forma con limitazioni.
I moduli GKI forniscono inoltre un meccanismo per consentire ai fornitori di incorporare nuove funzionalità upstream dopo il traguardo del blocco KMI. Il codice integrato non può essere sostituito senza creare un'altra immagine, mentre il codice fornito come modulo può essere sostituito da un altro modulo.
I moduli GKI utilizzano l'infrastruttura di firma in fase di compilazione del kernel per distinguere tra GKI e altri moduli in fase di esecuzione. I moduli non firmati possono essere caricati purché utilizzino solo simboli presenti nella lista consentita o forniti da altri moduli non firmati.
Esistono due tipi logici di moduli GKI: modulo GKI protetto e modulo GKI non protetto.
Modulo GKI protetto
Un modulo GKI protetto viene fornito da Google, non è limitato in alcun modo e si comporta come se fosse compilato con il kernel dopo il caricamento. Inoltre, i moduli GKI protetti hanno le seguenti caratteristiche:
- I moduli GKI protetti hanno accesso a simboli del kernel non KMI non disponibili per i moduli del fornitore o per i moduli GKI non protetti.
- I moduli GKI protetti possono esportare simboli che diventano parte della piattaforma KMI se questi simboli sono citati in un elenco di simboli.
- I moduli GKI protetti non possono essere sostituiti dai moduli del fornitore.
Un modulo GKI protetto è la classe predefinita dei moduli GKI. Tutti i moduli GKI sono considerati protetti al momento del blocco KMI.
Modulo GKI non protetto
Un modulo GKI non protetto può essere sostituito da un modulo del fornitore. Dopo il blocco di KMI, un modulo GKI protetto potrebbe essere riclassificato come non protetto se il team GKI decide che i fornitori devono eseguire l'override dell'implementazione predefinita con una versione che include nuove funzionalità di Linux upstream. Nella successiva release GKI, i moduli non protetti vengono riclassificati come protetti dopo che il codice upstream viene inserito in un kernel Android Common (ACK). I moduli GKI non protetti hanno le seguenti caratteristiche:
- I moduli GKI non protetti hanno lo stesso accesso ai simboli esportati dei moduli del fornitore.
- I moduli GKI non protetti non possono esportare i simboli esportati dai moduli GKI protetti.
- I moduli GKI non protetti devono preservare le eventuali interfacce KMI come se facessero parte del kernel di base.
- I moduli GKI non protetti possono essere sostituiti dai moduli del fornitore.
Moduli dei fornitori
I partner forniscono un modulo del fornitore per implementare funzionalità specifiche per SoC e dispositivo. Qualsiasi modulo del kernel esistente che non viene fornito come parte del kernel GKI può essere fornito come modulo del fornitore.
Poiché uno degli obiettivi principali del progetto GKI è ridurre al minimo il codice specifico dell'hardware nel kernel di base, i fornitori possono aspettarsi che il kernel GKI non includa moduli che gestiscono chiaramente il proprio hardware. Ad esempio, il fornitore ABC Inc. può aspettarsi che configurazioni come CONFIG_ABC_SOC_SUPPORT non vengano abilitate come moduli GKI integrati o caricabili senza il loro supporto.
Se in ACK esiste un driver o un framework del kernel, ma non viene fornito come parte del kernel GKI, i fornitori possono modificarlo e fornirlo come modulo del fornitore. Queste modifiche sono sconsigliate per i moduli non specifici del fornitore
perché le stesse funzionalità potrebbero essere fornite con il kernel GKI in una
futura release. Quando il kernel GKI contiene funzionalità fornite da un modulo del fornitore, quest'ultimo non si carica. Ad esempio,CONFIG_GREYBUS non è impostato per GKI in Android 11, pertanto i fornitori potrebbero fornire moduli del fornitore di greybus. Tuttavia, CONFIG_GREYBUS potrebbe essere attivato come GKI integrato o come modulo in Android 12, nel qual caso i moduli del fornitore di greybus non verranno caricati. Una best practice è utilizzare la versione upstream dei driver non specifici del fornitore se vengono forniti come moduli del fornitore.
Puoi pubblicare i moduli del fornitore nell'immagine vendor o vendor_boot. I moduli richiesti all'inizio del processo di avvio devono trovarsi nel seguente paese: vendor_boot.
Il caricamento dei moduli da vendor_boot comporta un costo di avvio.