Existen dos tipos de módulos del kernel: los módulos del GKI, que son independientes del hardware, y los módulos del proveedor, que son específicos del hardware. En esta página, se proporciona una descripción general de ambos tipos de módulos.
Módulos de GKI
Los módulos de la imagen genérica del kernel (GKI) se usan para proporcionar capacidades del kernel que no se requieren para el arranque, separadas del kernel genérico principal. Con los módulos del GKI, puedes elegir 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 en el tiempo de ejecución. La reducción de tamaño hace que el GKI sea adecuado para dispositivos Android Go y otros factores de forma con recursos limitados.
Los módulos del GKI también proporcionan un mecanismo para que los proveedores incorporen nuevas funciones upstream después del hito de congelación de la KMI. El código integrado no se puede reemplazar sin compilar otra imagen, mientras que el código que se entrega como un módulo se puede reemplazar por otro módulo.
Los módulos de GKI usan la infraestructura de firma en tiempo de compilación del kernel para diferenciar entre GKI y otros módulos en el tiempo de ejecución. Se permite cargar módulos sin firmar siempre y cuando solo usen símbolos que aparezcan 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 no protegido.
Módulo de GKI protegido
Google entrega un módulo de GKI protegido, no está restringido de ninguna manera y se comporta como si se hubiera compilado 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 de KMI y que no están disponibles para los módulos del proveedor ni para los módulos de GKI no protegidos.
- Los módulos del GKI protegido pueden exportar símbolos que se convierten en parte de la superficie de la KMI, siempre y cuando esos símbolos se citen en una lista de símbolos.
- Los módulos de GKI protegidos no pueden ser anulados por los módulos del proveedor.
Un módulo de GKI protegido es la clase predeterminada de módulos de GKI. Todos los módulos del GKI se consideran protegidos en el momento de la congelación del KMI.
Módulo de GKI no protegido
Un módulo de GKI no protegido puede anularse con un módulo del proveedor. Después de la congelación de la KMI, es posible que un módulo de GKI protegido se reclasifique como no protegido si el equipo de GKI decide que los proveedores deben anular la implementación predeterminada con una versión que incluya funciones nuevas del kernel de Linux upstream. En la próxima versión de GKI, los módulos no protegidos se reclasifican como protegidos después de que el código upstream se incluya en un kernel común de Android (ACK). Los módulos de GKI no protegidos tienen las siguientes características:
- Los módulos de GKI no protegidos tienen el mismo acceso a los símbolos exportados que los módulos del proveedor.
- Los módulos de GKI no protegidos no pueden exportar símbolos exportados por módulos de GKI protegidos.
- Los módulos de GKI no protegidos deben conservar cualquier interfaz de KMI como si fuera parte del kernel principal.
- Los módulos de GKI no protegidos pueden ser anulados por módulos del proveedor.
Módulos de proveedores
Los socios entregan un módulo del proveedor para implementar capacidades específicas del SoC y del dispositivo. Cualquier módulo del kernel existente que no se entregue como parte del kernel de la GKI se puede entregar como un módulo del proveedor.
Dado que uno de los objetivos principales del proyecto de GKI es minimizar el código específico del hardware en el kernel principal, los proveedores pueden esperar que el kernel de GKI no incluya módulos que administren claramente su propio hardware. Por ejemplo, el proveedor ABC Inc. puede esperar que las configuraciones como CONFIG_ABC_SOC_SUPPORT tampoco se habiliten como módulos de GKI integrados o cargables sin su asistencia.
Si existe un controlador o framework del 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 del proveedor. No se recomienda realizar este tipo de modificaciones en los módulos que no son específicos del proveedor, ya que es posible que las mismas capacidades se entreguen con el kernel de GKI en una versión futura. Cuando el kernel de GKI contiene capacidades proporcionadas por un módulo del proveedor, este no se cargará. Por ejemplo, CONFIG_GREYBUS no se establece 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 esté habilitado como módulo o integrado en GKI en Android 12, en cuyo caso no se cargarán los módulos del proveedor de Greybus. Se recomienda usar la versión upstream de los controladores no específicos del proveedor si se entregan como módulos del proveedor.
Puedes entregar módulos del proveedor en la imagen vendor o vendor_boot. Los módulos que se requieren en las primeras etapas 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.