Maintenir une interface de module de noyau (KMI) stable

Il est essentiel de maintenir une KMI stable pour les modules des fournisseurs. Le noyau GKI est construit et livré sous forme binaire et les modules chargeables par le fournisseur sont construits dans une arborescence distincte. Le noyau GKI et les modules du fournisseur doivent fonctionner comme s'ils avaient été construits ensemble.

En général, la communauté Linux a désapprouvé la notion de stabilité ABI dans le noyau pour le noyau principal. Face aux différentes chaînes d'outils, configurations et à un noyau principal Linux en constante évolution, il n'est pas possible de maintenir une KMI stable dans la ligne principale. Cependant, il est possible de maintenir une KMI stable dans l'environnement GKI hautement contraint avec ces contraintes :

  • Une seule configuration, gki_defconfig , peut être utilisée pour construire le noyau.

  • Le KMI n'est stable qu'au sein de la même version LTS et Android d'un noyau, comme android13-5.10 , android12-5.10 ou android13-5.15 .

    • Aucune stabilité KMI n'est maintenue pour android-mainline .
  • Seule la chaîne d'outils Clang spécifique fournie dans AOSP et définie pour la branche correspondante est utilisée pour construire le noyau et les modules.

  • Seuls les symboles connus pour être utilisés par les modules comme spécifié dans une liste de symboles sont surveillés pour leur stabilité et sont considérés comme des symboles KMI.

    • Le corollaire est que les modules du fournisseur doivent utiliser uniquement des symboles KMI. Cette contrainte est appliquée par l'échec du chargement du module si des symboles non KMI sont requis.
  • Une fois la branche KMI gelée, les modifications sont autorisées mais ne peuvent pas interrompre le KMI. Ces changements incluent les éléments suivants :

    • Modifications de la configuration
    • Modifications du code du noyau
    • Modifications de la chaîne d'outils (y compris les mises à jour)

Utilisez le processus de construction hermétique et la chaîne d'outils LLVM

Le processus de construction hermétique garantit une KMI stable en faisant en sorte que les manifestes repo dans kernel/manifest décrivent complètement l'environnement de construction. Par exemple, le manifeste pour android13-5.15 inclut la chaîne d'outils, les scripts de construction et tout le reste requis pour créer le noyau Generic Kernel Image (GKI). Les fichiers de configuration build.config respectifs, tels que la configuration de build GKI build.config.gki.aarch64 , garantissent que les outils inclus sont utilisés correctement pour générer des résultats de build cohérents.

L'utilisation d'un processus de construction hermétique garantit également que la description ABI de l'arborescence est cohérente, qu'elle soit générée par Google (par exemple, abi_gki_aarch64.xml pour android13-5.15 ou générée dans une arborescence locale incluant les modules du fournisseur. Les outils permettant de créer et de comparer les La description ABI de l'interface du module noyau (KMI) est également fournie dans le cadre du dépôt décrit par le manifeste.

La chaîne d'outils utilisée pour créer le noyau GKI doit être entièrement compatible avec la chaîne d'outils utilisée pour créer les modules du fournisseur. Depuis Android 10, tous les noyaux Android doivent être construits avec une chaîne d'outils LLVM. Avec GKI, la chaîne d'outils LLVM utilisée pour créer les noyaux de produits et les modules fournisseurs doit générer le même ABI que la chaîne d'outils LLVM d'AOSP et les partenaires doivent garantir que le KMI est compatible avec le noyau GKI. L'utilisation des outils de construction fournis est fortement encouragée car ils offrent des garanties de compatibilité.

Et après?

  • Pour obtenir des instructions sur la construction du noyau à l'aide du processus de construction hermétique et de la chaîne d'outils LLVM, reportez-vous à Build kernels .

  • Pour obtenir des instructions sur la façon de surveiller l'ABI et de résoudre les problèmes, reportez-vous à Surveillance de l'ABI du noyau Android.