Il existe deux types de modules de noyau : les modules GKI, qui sont indépendants du matériel, et les modules du fournisseur, qui sont 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 générique de base. Les modules GKI vous permettent de choisir les fonctionnalités spécifiques du noyau à utiliser, ce qui réduit 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'intégrer de nouvelles fonctionnalités en amont après l'étape de gel de l'interface 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 faire la différence entre les modules GKI et les autres modules au moment de l'exécution. Les modules non signés sont autorisés à se charger tant qu'ils n'utilisent que des symboles figurant sur 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 soumis à aucune restriction et se comporte comme s'il était intégré au 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 aux symboles du noyau non-KMI qui ne sont pas disponibles pour les modules du fournisseur 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 à 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 des modules de 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 KMI.
Module GKI non protégé
Un module GKI non protégé peut être remplacé par un module fournisseur. Après le gel du 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. Lors de la prochaine version de GKI, les modules non protégés seront reclassés comme protégés une fois que le code en amont sera intégré à un noyau 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 noyau principal.
- Les modules GKI non protégés peuvent être remplacés par des modules fournisseurs.
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 noyau existant qui n'est pas fourni avec le noyau GKI peut être fourni en tant que module fournisseur.
L'un des principaux objectifs du projet GKI étant 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 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 ACK, mais n'est pas fourni avec le noyau GKI, les fournisseurs peuvent modifier le pilote et le fournir en tant que module fournisseur. Ces modifications sont déconseillées pour les modules non spécifiques à un fournisseur, car les mêmes fonctionnalités peuvent être fournies avec le noyau GKI dans une version ultérieure. Lorsque le noyau GKI contient des fonctionnalités fournies par un module fournisseur, ce module ne se charge pas. Par exemple, CONFIG_GREYBUS n'est pas défini pour GKI dans Android 11. Les fournisseurs peuvent donc fournir des modules de fournisseur Greybus. Toutefois, CONFIG_GREYBUS peut être activé en tant que module ou intégré au noyau GKI dans Android 12. Dans ce cas, les modules fournisseur greybus 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 de 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.
Le chargement de modules à partir de vendor_boot entraîne un coût au moment du démarrage.