Maintenir une interface de module de noyau stable

Il est essentiel de maintenir une interface de module de noyau (KMI) stable pour les modules fournisseurs. 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 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 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 KMI sont requis.

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

    • Modifications de la 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 android13-5.15 inclut la chaîne d'outils, les scripts de compilation et tous les autres éléments requis pour compiler le noyau GKI (Generic Kernel Image). Les fichiers de configuration build.config respectifs, tels que la configuration de compilation GKI build.config.gki.aarch64, garantissent 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, abi_gki_aarch64.xml pour android13-5.15) 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 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. À 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 ?