Il existe deux types de modules de noyau: ceux qui sont indépendants du matériel Modules GKI et composants matériels modules pour les fournisseurs. Cette page présente ces deux types de modules.
Modules GKI
Les modules d'image de noyau générique (GKI) sont utilisés pour fournir un noyau non amorçable distincte du noyau 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é pour Appareils Android Go et autres facteurs de forme dont les ressources sont limitées
Les modules GKI offrent également un mécanisme permettant aux fournisseurs d'incorporer de nouvelles des fonctionnalités en amont après le gel de KMI. Code intégré ne peut pas être remplacé sans créer une autre image, alors que le code livré sous forme peut être remplacé par un autre module.
Les modules GKI utilisent l'infrastructure de signature du temps de compilation du noyau pour différencier entre GKI et d'autres modules au moment de l'exécution. Les modules non signés sont autorisés à charger à condition 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: Protect GKI module et un module GKI non protégé.
Module GKI protégé
Un module GKI protégé est fourni par Google, n'est soumis à aucune restriction se comporte comme s'il était construit avec le noyau après le chargement. En outre, 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 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 GKI modules sont considérés comme protégés au moment du gel de KMI.
Module GKI non protégé
Un module GKI non protégé peut être remplacé par un module de fournisseur. Après le blocage du 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. Le suivant GKI, les modules non protégés sont reclassés comme protégés après le code en amont atterrit dans un noyau commun Android (ACK). 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 le fournisseur modules.
- Les modules GKI non protégés ne peuvent pas exporter les symboles exportés par une GKI protégée modules.
- Les modules GKI non protégés doivent conserver toutes les interfaces KMI comme si noyau.
- Les modules GKI non protégés peuvent être remplacés par les modules de fournisseurs.
Modules du fournisseur
Un module fournisseur est fourni par les partenaires pour implémenter un SoC et un module spécifique à l'appareil des fonctionnalités. Tout module de noyau existant qui n'est pas distribué Le noyau GKI peut être livré en tant que module de fournisseur.
Puisque l'un des principaux objectifs du projet GKI est de réduire
code spécifique au matériel dans le noyau principal, les fournisseurs peuvent s'attendre à ce que le GKI
le noyau n’inclura pas de modules qui gèrent
clairement leur propre matériel. Pour
exemple, le fournisseur ABC Inc. peut s'attendre à ce que les configurations telles que
CONFIG_ABC_SOC_SUPPORT ne sera pas activé comme intégré ni chargeable
modules GKI sans leur prise en charge.
Si un pilote ou un framework de noyau existe dans l’ACK, mais qu’il n’est pas livré dans le cadre
le noyau GKI, les fournisseurs peuvent
modifier le pilote et le fournir en tant que
de ce module. De telles modifications sont déconseillées pour les modules non spécifiques au fournisseur.
car les mêmes capacités peuvent être
fournies avec le noyau GKI dans un
version ultérieure. Lorsque le noyau GKI contient des fonctionnalités fournies par un fournisseur
, le module du 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 fournisseur Greybus. Toutefois, CONFIG_GREYBUS peut être
en tant que module ou module GKI intégré dans Android 12,
Dans ce cas, les modules de
fournisseurs Greybus ne seront pas chargés. Une bonne pratique consiste à utiliser
la version en amont des pilotes non propres au fournisseur s'ils sont fournis
modules fournisseurs.
Vous pouvez distribuer des modules de fournisseur dans le vendor ou le
vendor_boot
l'image. Les modules requis au début du processus de démarrage doivent se trouver dans vendor_boot.
Un coût de démarrage est associé au chargement de modules depuis vendor_boot.