Panoramica dei moduli del kernel

Esistono due tipi di moduli del kernel: moduli GKI indipendenti dall'hardware e moduli del fornitore specifici dell'hardware. Questa pagina fornisce una panoramica di entrambi i tipi di moduli.

Moduli GKI

I moduli Generic Kernel Image (GKI) vengono utilizzati per fornire funzionalità del kernel non richieste per l'avvio separate dal kernel core generico. Con i moduli GKI, puoi scegliere funzionalità specifiche del kernel da utilizzare, spesso riducendo le dimensioni dell'immagine del kernel e il consumo di memoria di runtime. La riduzione delle dimensioni rende GKI particolarmente adatto ai dispositivi Android Go e ad altri fattori di forma con limitazioni di risorse.

I moduli GKI forniscono anche un meccanismo che consente ai fornitori di incorporare nuove funzionalità upstream dopo il raggiungimento del traguardo del congelamento di 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. È consentito caricare moduli non firmati purché utilizzino solo simboli visualizzati 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 creato con il kernel dopo il caricamento. Inoltre, i moduli GKI protetti hanno le seguenti caratteristiche:

  • I moduli GKI protetti hanno accesso ai simboli del kernel non KMI che non sono disponibili per i moduli del fornitore o per i moduli GKI non protetti.
  • I moduli GKI protetti possono esportare simboli che diventano parte della superficie KMI purché tali simboli siano 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 del KMI.

Modulo GKI non protetto

Un modulo GKI non protetto può essere sovrascritto da un modulo del fornitore. Dopo il congelamento di KMI, un modulo GKI protetto potrebbe essere riclassificato come non protetto se il team GKI decide che i fornitori devono sovrascrivere l'implementazione predefinita con una versione che include nuove funzionalità da Linux upstream. Nella successiva versione GKI, i moduli non protetti verranno riclassificati come protetti dopo che il codice upstream arriva in un Android Common Kernel (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 simboli esportati da moduli GKI protetti.
  • I moduli GKI non protetti devono preservare qualsiasi interfaccia KMI come se fosse parte del kernel principale.
  • I moduli GKI non protetti possono essere sostituiti dai moduli del fornitore.

Moduli del venditore

Un modulo del fornitore viene fornito dai partner per implementare il SoC e le funzionalità specifiche del 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 principale, 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 verranno abilitate come moduli GKI integrati o caricabili senza il loro supporto.

Se un driver o un framework del kernel esiste in ACK, ma non viene fornito come parte del kernel GKI, i fornitori possono modificare il driver e fornirlo come modulo del fornitore. Tali modifiche sono scoraggiate per moduli non specifici del fornitore poiché la stessa funzionalità potrebbe essere fornita con il kernel GKI in una versione futura. Quando il kernel GKI contiene funzionalità fornite da un modulo del fornitore, il modulo del fornitore non verrà caricato. Ad esempio, CONFIG_GREYBUS non è impostato per GKI in Android 11, quindi i fornitori potrebbero fornire moduli del fornitore greybus. Tuttavia, CONFIG_GREYBUS potrebbe essere abilitato come modulo o modulo GKI integrato in Android 12, nel qual caso i moduli del fornitore greybus non verranno caricati. Una procedura consigliata consiste nell'utilizzare la versione upstream dei driver non specifici del fornitore se vengono forniti come moduli del fornitore.

È possibile fornire i moduli del fornitore nell'immagine vendor o nell'immagine vendor_boot . I moduli richiesti all'inizio del processo di avvio devono trovarsi in vendor_boot . È previsto un costo in fase di avvio associato al caricamento dei moduli da vendor_boot .