Hay dos tipos de módulos de kernel: módulos GKI independientes del hardware y módulos de proveedores específicos de hardware. Esta página proporciona una descripción general de ambos tipos de módulos.
módulos GKI
Los módulos de imagen de kernel genérico (GKI) se utilizan para ofrecer una funcionalidad de kernel que no requiere arranque separada del kernel central genérico. Con los módulos GKI, puede elegir la funcionalidad específica del kernel que desea utilizar, lo que a menudo reduce el tamaño de la imagen del kernel y el consumo de memoria en tiempo de ejecución. La reducción de tamaño hace que GKI sea muy adecuado para dispositivos Android Go y otros factores de forma con recursos restringidos.
Los módulos GKI también proporcionan un mecanismo que permite a los proveedores incorporar nuevas funciones ascendentes después del hito de congelación de KMI. El código incorporado no se puede reemplazar sin crear otra imagen, mientras que el código entregado como módulo se puede reemplazar por otro módulo.
Los módulos GKI utilizan la infraestructura de firma en tiempo de compilación del kernel para diferenciar entre GKI y otros módulos en tiempo de ejecución. Los módulos sin firmar pueden cargarse siempre que solo utilicen símbolos que aparecen en la lista de permitidos o proporcionados por otros módulos sin firmar.
Hay dos tipos lógicos de módulos GKI: módulo GKI protegido y módulo GKI desprotegido .
Módulo GKI protegido
Google entrega un módulo GKI protegido, no está restringido de ninguna manera y se comporta como si estuviera construido con el kernel después de la carga. Además, los módulos GKI protegidos tienen las siguientes características:
- Los módulos GKI protegidos tienen acceso a símbolos del kernel que no son KMI que no están disponibles para los módulos del proveedor o para los módulos GKI desprotegidos.
- Los módulos GKI protegidos pueden exportar símbolos que pasan a formar parte de la superficie KMI siempre que esos símbolos estén citados en una lista de símbolos.
- Los módulos de GKI protegidos no pueden ser anulados por módulos de proveedores.
Un módulo GKI protegido es la clase predeterminada de módulos GKI. Todos los módulos GKI se consideran protegidos en el momento de la congelación de KMI.
Módulo GKI desprotegido
Un módulo de proveedor puede anular un módulo GKI desprotegido. Después de la congelación de KMI, un módulo GKI protegido podría reclasificarse como no protegido si el equipo de GKI decide que los proveedores deben anular la implementación predeterminada con una versión que incluya nuevas características de Linux. En la próxima versión de GKI, los módulos desprotegidos se reclasifican como protegidos después de que el código ascendente llegue a un kernel común de Android (ACK). Los módulos GKI desprotegidos tienen las siguientes características:
- Los módulos GKI desprotegidos tienen el mismo acceso a los símbolos exportados que los módulos de proveedores.
- Los módulos GKI desprotegidos no pueden exportar símbolos exportados por módulos GKI protegidos.
- Los módulos GKI desprotegidos deben preservar cualquier interfaz KMI como si fuera parte del núcleo central.
- Los módulos de GKI desprotegidos pueden ser anulados por módulos de proveedor.
Módulos de proveedores
Los socios entregan un módulo de proveedor para implementar SoC y funcionalidades específicas del dispositivo. Cualquier módulo del kernel existente que no se entregue como parte del kernel de GKI se puede entregar como módulo de proveedor.
Dado que uno de los objetivos principales del proyecto GKI es minimizar el código específico del hardware en el núcleo central, los proveedores pueden esperar que el núcleo GKI no incluya módulos que administren claramente su propio hardware. Por ejemplo, el proveedor ABC Inc puede esperar que configuraciones como CONFIG_ABC_SOC_SUPPORT no se habiliten como módulos GKI integrados o cargables sin su soporte.
Si existe un controlador o marco de kernel en ACK, pero no se entrega como parte del kernel de GKI, los proveedores pueden modificar el controlador y entregarlo como un módulo de proveedor. Se desaconsejan tales modificaciones para módulos que no son específicos del proveedor porque la misma funcionalidad podría entregarse con el kernel GKI en una versión futura. Cuando el kernel de GKI contiene funcionalidad proporcionada por un módulo de proveedor, el módulo de 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 proveedor de greybus. Sin embargo, CONFIG_GREYBUS puede estar habilitado como módulo o GKI integrado en Android 12, en cuyo caso los módulos del proveedor de Greybus no se cargarán. Una práctica recomendada es utilizar la versión ascendente de controladores no específicos del proveedor si se entregan como módulos del proveedor.
Puede entregar módulos de proveedor en la imagen vendor o de vendor_boot . Los módulos necesarios al principio del proceso de arranque deben estar en vendor_boot . Hay un costo de tiempo de arranque asociado con la carga de módulos desde vendor_boot .