Maintenir une interface de module de noyau stable

Il est essentiel de maintenir une interface de module de noyau stable pour le fournisseur modules. Le noyau GKI est sont compilés et livrés sous forme binaire, et les modules que les fournisseurs peuvent charger sont intégrés dans un une arborescence distincte. Le noyau GKI résultant et les modules fournisseurs doivent fonctionner bien qu'ils aient été construits ensemble.

En général, la communauté Linux a a refusé la notion d'ABI dans le noyau stabilité pour le noyau principal. Face à différentes chaînes d'outils, et un noyau Linux principal en constante évolution, il n'est pas possible de maintenir un un KMI stable dans mainline. Cependant, 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 créer 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é de l'KMI n'est maintenue pour android-mainline.

  • Seule la chaîne d'outils Clang spécifique fournie dans AOSP et définie pour le la branche correspondante est utilisée pour construire le noyau et les modules.

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

    • Par conséquent, les modules du fournisseur ne doivent utiliser que des symboles KMI. Ce est appliquée en cas d'échec du chargement des modules si des symboles non-KMI sont obligatoire.

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

    • Modifications de la configuration
    • Modifications du code du noyau
    • Modifications de 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 un KMI stable grâce à l'ajout de fichiers manifestes repo. kernel/manifest décrivent complètement l'environnement de compilation. Par exemple, 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 Kernel Image (GKI) générique. La configuration build.config correspondante tels que la configuration de compilation GKI build.config.gki.aarch64, de s'assurer que les outils inclus sont utilisés correctement pour générer une compilation cohérente résultats.

L'utilisation d'un processus de compilation hermétique garantit également que la description de l'ABI pour le 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ées dans une arborescence locale incluant le fournisseur modules. La Outils pour créer et comparer la description de l'ABI pour l'interface KMI (Kernel Module Interface) sont également fournis dans le dépôt décrites 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 des fournisseurs. À partir d'Android 10, tous les noyaux Android doivent être compilés à une chaîne d'outils LLVM. Avec GKI, la chaîne d'outils LLVM utilisée pour créer Les noyaux et les modules fournisseurs doivent générer la même ABI que la chaîne d'outils LLVM à partir de L'AOSP et ses 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 fournissent la meilleure compatibilité.

Et maintenant ?