Maintenir une interface de module de noyau stable

Il est essentiel de maintenir une interface de module de noyau (KMI) stable pour les modules du fournisseur. Le noyau GKI est compilé et distribué au format binaire, et les modules pouvant être chargés par le fournisseur sont compilés dans une arborescence distincte. Le kernel GKI et les modules du fournisseur qui en résultent doivent fonctionner comme s'ils avaient été créés ensemble.

En général, la communauté Linux a défavorisé la notion de stabilité de l'ABI dans le noyau pour le noyau principal. Face aux différentes chaînes d'outils, configurations et noyaux principaux Linux en constante évolution, il n'est pas possible de maintenir un KMI stable dans le noyau principal. Toutefois, il est possible de maintenir un KMI stable dans l'environnement GKI hautement contraint avec les contraintes suivantes:

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

  • Le KMI n'est stable que dans la même version LTS et Android d'un noyau, comme android14-6.1, android15-6.6 ou android16-6.12.

    • 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 compiler le noyau et les modules.

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

    • Par conséquent, les modules du fournisseur ne doivent utiliser que des symboles KMI. Cette contrainte est appliquée par des chargements de modules défaillants si des symboles autres que des symboles KMI sont requis.

  • Une fois la branche KMI congelée, les modifications sont autorisées, mais ne peuvent pas endommager le KMI. Voici quelques-unes de ces modifications:

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

Utiliser le processus de compilation hermétique et la chaîne d'outils LLVM

Le processus de compilation hermétique garantit une KMI stable en faisant en sorte que les fichiers manifestes repo dans kernel/manifest décrivent complètement l'environnement de compilation. Par exemple, le fichier manifeste pour android16-6.12 inclut la chaîne d'outils, le système de compilation et tout le reste nécessaire pour créer le kernel GKI (Generic Kernel Image). La configuration de compilation, principalement BUILD.bazel, garantit que les outils inclus sont utilisés correctement pour générer des résultats de compilation cohérents.

L'utilisation d'un processus de compilation hermétique garantit également que la description de l'ABI de l'arborescence est cohérente, qu'elle soit générée par Google (par exemple, gki/aarch64/abi.stg pour android16-6.12) ou générée dans une arborescence locale qui inclut les modules du fournisseur. Les outils permettant de créer et de comparer la description de l'ABI pour l'interface de module de kernel (KMI) sont également fournis dans le dépôt décrit par le fichier manifeste.

La chaîne d'outils utilisée pour compiler le kernel GKI doit être entièrement compatible avec la chaîne d'outils utilisée pour compiler les modules du fournisseur. À partir d'Android 10, tous les noyaux Android doivent être compilés 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 du fournisseur doit générer la même ABI que la chaîne d'outils LLVM d'AOSP, et les partenaires doivent s'assurer que le KMI est compatible avec le noyau GKI. Nous vous recommandons vivement d'utiliser les outils de compilation fournis, car ils offrent la meilleure compatibilité.

Et maintenant ?