Présentation des modules du noyau

Il existe deux types de modules de noyau : les modules GKI indépendants du matériel et les modules de fournisseur spécifiques au matériel. Cette page donne un aperçu des deux types de modules.

Modules GKI

Les modules Generic Kernel Image (GKI) sont utilisés pour fournir des fonctionnalités de noyau non requises par le démarrage, distinctes du noyau générique. Avec les modules GKI, vous pouvez choisir des fonctionnalités spécifiques du noyau à utiliser, réduisant souvent la taille de l'image du noyau et la consommation de mémoire d'exécution. La réduction de la taille rend GKI bien adapté aux appareils Android Go et à d'autres facteurs de forme à ressources limitées.

Les modules GKI fournissent également un mécanisme permettant aux fournisseurs d'incorporer de nouvelles fonctionnalités en amont après le jalon du gel du KMI. Le code intégré ne peut pas être remplacé sans créer une autre image, alors que le code fourni sous forme de module peut être remplacé par un autre module.

Les modules GKI utilisent l'infrastructure de signature au moment de la construction du noyau pour différencier GKI des autres modules au moment de l'exécution. Les modules non signés sont autorisés à se charger à condition qu'ils utilisent uniquement les symboles apparaissant sur la liste verte ou fournis par d'autres modules non signés.

Il existe deux types logiques de modules GKI : le module GKI protégé et le module GKI non protégé .

Module GKI protégé

Un module GKI protégé est fourni par Google, n'est soumis à aucune restriction et se comporte comme s'il avait été construit avec le noyau après son chargement. De plus, les modules GKI protégés ont les caractéristiques suivantes :

  • Les modules GKI protégés ont accès aux symboles de noyau non KMI qui ne sont pas disponibles pour les modules du fournisseur ou les modules GKI non protégés.
  • Les modules GKI protégés peuvent exporter des symboles qui font partie de la surface KMI à condition que ces symboles soient cités dans une liste de symboles.
  • Les modules GKI protégés ne peuvent pas être remplacés par les modules du fournisseur.

Un module GKI protégé est la classe par défaut des modules GKI. Tous les modules GKI sont considérés comme protégés au moment du gel du KMI.

Module GKI non protégé

Un module GKI non protégé peut être remplacé par un module fournisseur. Après le gel de KMI, un module GKI protégé peut être reclassé comme non protégé si l'équipe GKI décide que les fournisseurs doivent remplacer l'implémentation par défaut par une version incluant de nouvelles fonctionnalités de Linux en amont. Dans la prochaine version de GKI, les modules non protégés sont reclassés comme protégés une fois que le code en amont arrive dans un noyau commun Android (ACK). Les modules GKI non protégés ont les caractéristiques suivantes :

  • Les modules GKI non protégés ont le même accès aux symboles exportés que les modules du fournisseur.
  • Les modules GKI non protégés ne peuvent pas exporter les symboles exportés par les modules GKI protégés.
  • Les modules GKI non protégés doivent conserver toutes les interfaces KMI comme si elles faisaient partie du noyau principal.
  • Les modules GKI non protégés peuvent être remplacés par les modules du fournisseur.

Modules fournisseurs

Un module fournisseur est fourni par les partenaires pour implémenter le SoC et les fonctionnalités spécifiques aux appareils. Tout module de noyau existant qui n'est pas fourni dans le cadre du noyau GKI peut être fourni en tant que module fournisseur.

Étant donné que l'un des principaux objectifs du projet GKI est de minimiser le code spécifique au matériel dans le noyau principal, les fournisseurs peuvent s'attendre à ce que le noyau GKI n'inclue pas de modules gérant clairement leur propre matériel. Par exemple, le fournisseur ABC Inc peut s'attendre à ce que des configurations telles que CONFIG_ABC_SOC_SUPPORT ne soient pas activées en tant que modules GKI intégrés ou chargeables sans leur prise en charge.

Si un pilote ou un framework de noyau existe dans ACK, mais n'est pas fourni dans le cadre du noyau GKI, les fournisseurs peuvent modifier le pilote et le fournir en tant que module fournisseur. De telles modifications sont déconseillées pour les modules non spécifiques au fournisseur, car la même fonctionnalité pourrait être fournie avec le noyau GKI dans une version ultérieure. Lorsque le noyau GKI contient des fonctionnalités fournies par un module fournisseur, le module fournisseur ne se chargera pas. Par exemple, CONFIG_GREYBUS n'est pas défini pour GKI dans Android 11, les fournisseurs peuvent donc fournir des modules fournisseur graybus. Cependant, CONFIG_GREYBUS peut être activé en tant que module ou module GKI intégré dans Android 12, auquel cas les modules du fournisseur graybus ne seront pas chargés. Une bonne pratique consiste à utiliser la version en amont des pilotes non spécifiques au fournisseur s'ils sont fournis en tant que modules du fournisseur.

Vous pouvez fournir des modules fournisseur dans l'image vendor ou vendor_boot . Les modules requis au début du processus de démarrage doivent se trouver dans vendor_boot . Il existe un coût de temps de démarrage associé au chargement des modules à partir de vendor_boot .