Présentation des modules kernel

Il existe deux types de modules de kernel: les modules GKI indépendants du matériel et les modules du fournisseur spécifiques au matériel. Cette page présente les deux types de modules.

Modules GKI

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

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

Les modules GKI utilisent l'infrastructure de signature au moment de la compilation 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 n'utilisent que des symboles figurant dans la liste d'autorisation 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 en aucun cas limité et se comporte comme s'il était compilé avec le noyau après le chargement. De plus, les modules GKI protégés présentent les caractéristiques suivantes:

  • Les modules GKI protégés ont accès à des symboles de noyau non-KMI qui ne sont pas disponibles pour les modules de fournisseurs ni pour les modules GKI non protégés.
  • Les modules GKI protégés peuvent exporter des symboles qui font partie de la surface KMI tant que ces symboles sont cités dans une liste de symboles.
  • Les modules GKI protégés ne peuvent pas être ignoré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 blocage du KMI.

Module GKI non protégé

Un module GKI non protégé peut être remplacé par un module de fournisseur. Après le gel de KMI, un module GKI protégé peut être reclassifié 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 les nouvelles fonctionnalités de Linux en amont. Lors de la prochaine version du GKI, les modules non protégés sont reclassés comme protégés après l'arrivée du code en amont dans un kernel commun Android (ACK). Les modules GKI non protégés présentent 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 kernel principal.
  • Les modules GKI non protégés peuvent être remplacés par des modules du fournisseur.

Modules du fournisseur

Un module fournisseur est fourni par les partenaires pour implémenter les fonctionnalités spécifiques au SoC et à l'appareil. Tout module de kernel existant qui n'est pas fourni dans le kernel GKI peut être fourni en tant que module de fournisseur.

Étant donné que l'un des principaux objectifs du projet GKI est de réduire 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 qui gèrent clairement leur propre matériel. Par exemple, le fournisseur ABC Inc. peut s'attendre à ce que les 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 l'ACK, mais qu'il n'est pas fourni dans le cadre du noyau GKI, les fournisseurs peuvent modifier le pilote et le distribuer en tant que module fournisseur. Ces modifications sont déconseillées pour les modules non spécifiques au fournisseur, car les mêmes fonctionnalités pourraient être fournies avec le noyau GKI dans une prochaine version. Lorsque le noyau GKI contient des fonctionnalités fournies par un module fournisseur, le module fournisseur ne se charge pas. Par exemple, CONFIG_GREYBUS n'est pas défini pour GKI dans Android 11. Par conséquent, les fournisseurs peuvent fournir des modules de fournisseurs grisbus. Toutefois, CONFIG_GREYBUS peut être activé en tant que module ou module intégré GKI dans Android 12, auquel cas les modules du fournisseur greybus ne seront pas chargés. Il est recommandé d'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 de fournisseurs dans l'image vendor ou vendor_boot. Les modules requis au début du processus de démarrage doivent se trouver dans vendor_boot. Le chargement de modules à partir de vendor_boot entraîne un coût au démarrage.