Existen dos tipos de módulos de kernel: independientes del hardware. Módulos de GKI y módulos de módulos para proveedores. En esta página, se proporciona una descripción general de ambos tipos de módulos.
Módulos de GKI
Los módulos de imagen genérica del kernel (GKI) se usan para entregar el kernel que no requiere inicio. capacidades independientes del kernel principal genérico. Con los módulos de GKI, puedes elegir las capacidades específicas del kernel para usar, lo que a menudo reduce el tamaño de la imagen del kernel. y el consumo de memoria del entorno de ejecución. La reducción de tamaño hace que GKI sea ideal para Dispositivos Android Go y otros factores de forma con recursos restringidos
Los módulos de GKI también ofrecen un mecanismo para permitir que los proveedores incorporen atributos ascendentes después del hito de suspensión de KMI; Código integrado no se puede reemplazar sin crear otra imagen, mientras que el código publicado como puede reemplazarse por otro.
Los módulos de GKI usan la infraestructura de firma del tiempo de compilación del kernel para diferenciar entre GKI y otros módulos en el tiempo de ejecución. Los módulos sin firmar pueden cargarse siempre y cuando solo usen símbolos que aparecen en la lista de entidades permitidas o que proporcionen otros módulos sin firmar.
Existen dos tipos lógicos de módulos de GKI: módulo de GKI protegido y módulo de GKI desprotegido.
Módulo de GKI protegido
Google proporciona un módulo de GKI protegido, sin restricciones. se comporta como si se compilara con el kernel después de la carga. Además: Los módulos de GKI protegidos tienen las siguientes características:
- Los módulos de GKI protegidos tienen acceso a símbolos del kernel que no son KMI y que no son que estén disponibles para módulos de proveedores o módulos de GKI desprotegidos.
- Los módulos de GKI protegidos pueden exportar símbolos que forman parte de la plataforma de KMI. siempre que esos símbolos estén citados en una lista de símbolos.
- Los módulos del proveedor no pueden anular los módulos de GKI protegidos.
Un módulo de GKI protegido es la clase predeterminada de los módulos de GKI. Todo el GKI Los módulos se consideran protegidos cuando se suspende KMI.
Módulo de GKI desprotegido
Un módulo de proveedor puede anular un módulo de GKI desprotegido. Después de que se suspenda el KMI, un módulo de GKI protegido podría volver a clasificarse como no protegido si el equipo de GKI decide que los proveedores deben anular la implementación predeterminada con una versión que incluye funciones nuevas de Linux upstream. El próximo versión de GKI, los módulos desprotegidos se vuelven a clasificar como protegidos después de el código upstream llega a un kernel común de Android (ACK). Módulos de GKI desprotegidos tienen las siguientes características:
- Los módulos de GKI desprotegidos tienen el mismo acceso a los símbolos exportados que el proveedor. módulos.
- Los módulos de GKI desprotegidos no pueden exportar símbolos exportados por un GKI protegido. módulos.
- Los módulos de GKI desprotegidos deben conservar todas las interfaces KMI como parte del kernel principal.
- Los módulos del proveedor pueden anular los módulos de GKI desprotegidos.
Módulos de proveedores
Los socios ofrecen un módulo de proveedores para implementar el SoC y las apps capacidades de integración. Cualquier módulo de kernel existente que no se entregue como parte del El kernel de GKI se puede entregar como un módulo de proveedor.
Ya que uno de los objetivos principales del proyecto GKI es minimizar
específico de hardware específico en el kernel principal, los proveedores pueden esperar que el GKI
no incluirá módulos que administran claramente su propio hardware. Para
Por ejemplo, el proveedor ABC Inc. puede esperar que las configuraciones como
CONFIG_ABC_SOC_SUPPORT no se habilitará como integrado ni se podrá cargar
módulos de GKI sin su asistencia.
Si un controlador de kernel o framework existe en ACK, pero no se entrega como parte de
el kernel de GKI, los proveedores pueden modificar el controlador y entregarlo como proveedor
módulo. No se recomienda realizar estas modificaciones para módulos que no sean específicos del proveedor
porque las mismas capacidades se pueden entregar con el kernel de GKI en un
en una versión futura. Cuando el kernel de GKI contiene capacidades proporcionadas por un proveedor
proveedor, no se cargará. Por ejemplo:
CONFIG_GREYBUS no está configurado para GKI en Android 11, por lo que
los proveedores pueden entregar módulos de proveedores de greybus. Sin embargo, es posible que CONFIG_GREYBUS
habilitado como módulo o GKI integrado en Android 12, en
en el que no se cargarán los módulos de proveedores de Greybus. Una práctica recomendada es usar
la versión ascendente de los controladores no específicos del proveedor si se entregan como
módulos de proveedores.
Puedes publicar módulos de proveedores en vendor o en la
vendor_boot
imagen. Los módulos necesarios al principio del proceso de inicio deben estar en vendor_boot.
Hay un costo de inicio asociado con la carga de módulos de vendor_boot.