Mantenere un'interfaccia del modulo kernel stabile (KMI)

È fondamentale mantenere un KMI stabile per i moduli del fornitore. Il kernel GKI è costruito e distribuito in formato binario e i moduli caricabili dal fornitore sono costruiti in un albero separato. Il kernel GKI risultante e i moduli del fornitore devono funzionare come se fossero stati creati insieme.

In generale, la comunità Linux ha disapprovato il concetto di stabilità ABI in-kernel per il kernel principale. A fronte di diverse toolchain, configurazioni e un kernel Linux mainline in continua evoluzione, non è possibile mantenere un KMI stabile nella mainline. Tuttavia, è possibile mantenere un KMI stabile nell'ambiente GKI altamente vincolato con questi vincoli:

  • Per compilare il kernel è possibile utilizzare solo una singola configurazione, gki_defconfig .

  • Il KMI è stabile solo all'interno della stessa versione LTS e Android di un kernel, come android13-5.10 , android12-5.10 o android13-5.15 .

    • Non viene mantenuta la stabilità KMI per android-mainline .
  • Per creare kernel e moduli viene utilizzata solo la specifica toolchain Clang fornita in AOSP e definita per il ramo corrispondente.

  • Solo i simboli noti per essere utilizzati dai moduli come specificato in un elenco di simboli vengono monitorati per la stabilità e considerati simboli KMI.

    • Il corollario è che i moduli del fornitore devono utilizzare solo simboli KMI. Questo vincolo viene applicato in caso di mancato caricamento del modulo se sono richiesti simboli non KMI.
  • Dopo che il ramo KMI è stato congelato, le modifiche sono consentite ma non possono interrompere il KMI. Queste modifiche includono quanto segue:

    • Modifiche alla configurazione
    • Modifiche al codice kernel
    • Modifiche alla toolchain (compresi gli aggiornamenti)

Utilizza il processo di creazione ermetica e la toolchain LLVM

Il processo di compilazione ermetica garantisce un KMI stabile poiché i manifest repo nel kernel/manifest descrivono completamente l'ambiente di compilazione. Ad esempio, il manifest per android13-5.15 include la toolchain, gli script di compilazione e tutto il resto necessario per creare il kernel Generic Kernel Image (GKI). I rispettivi file di configurazione build.config , come GKI build config build.config.gki.aarch64 , garantiscono che gli strumenti inclusi vengano utilizzati correttamente per generare risultati di build coerenti.

L'utilizzo di un processo di creazione ermetica garantisce inoltre che la descrizione ABI per l'albero sia coerente sia che venga generata da Google (ad esempio, abi_gki_aarch64.xml per android13-5.15 o generata in un albero locale che include i moduli del fornitore. Gli strumenti per creare e confrontare l'albero Anche la descrizione ABI per l'interfaccia del modulo kernel (KMI) viene fornita come parte del repository descritto dal manifest.

La toolchain utilizzata per creare il kernel GKI deve essere completamente compatibile con la toolchain utilizzata per creare i moduli del fornitore. A partire da Android 10, tutti i kernel Android devono essere compilati con una toolchain LLVM. Con GKI, la toolchain LLVM utilizzata per creare kernel di prodotto e moduli del fornitore deve generare la stessa ABI della toolchain LLVM di AOSP e i partner devono garantire che il KMI sia compatibile con il kernel GKI. L'utilizzo degli strumenti di compilazione forniti è fortemente incoraggiato in quanto forniscono garanzie di compatibilità.

Qual è il prossimo?