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 fourni au format binaire, et les modules pouvant être chargés par le fournisseur sont compilés dans un arbre distinct. Le noyau 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 désapprouve l'idée de stabilité de l'ABI dans le noyau pour le noyau principal. Compte tenu des différentes chaînes d'outils et configurations, ainsi que du noyau principal Linux en constante évolution, il n'est pas possible de maintenir une KMI stable dans le noyau principal. Toutefois, il est possible de maintenir un KMI stable dans l'environnement GKI très contraint avec les contraintes suivantes :

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

  • L'IKM 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é du 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, tels qu'ils sont spécifiés dans une liste de symboles, sont surveillés pour leur stabilité et considérés comme des symboles KMI.

    • Le corollaire est que les modules du fournisseur ne doivent utiliser que des symboles KMI. Cette contrainte est appliquée en cas d'échec du chargement des modules si des symboles non-KMI sont requis.

  • Une fois la branche KMI figée, les modifications sont autorisées, mais ne peuvent pas casser 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 interface 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 manifeste pour android16-6.12 inclut la chaîne d'outils, le système de compilation et tout ce qui est nécessaire pour compiler le noyau 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 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 dans une arborescence locale incluant les modules du fournisseur. Les outils permettant de créer et de comparer la description de l'ABI pour l'interface du module du noyau (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 noyau GKI doit être entièrement compatible avec celle utilisée pour compiler les modules du fournisseur. Depuis 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. Les partenaires doivent s'assurer que l'interface KMI est compatible avec le noyau GKI. Nous vous recommandons vivement d'utiliser les outils de compilation fournis, car ils offrent la meilleure compatibilité.

Étapes suivantes