Existen dos tipos de módulos de kernel: módulos de GKI independientes del hardware y módulos de proveedor 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 imagen genérica del kernel (GKI) se usan para proporcionar capacidades de kernel que no requieren inicio, separadas del kernel principal genérico. Con los módulos de GKI, puedes elegir funciones específicas del kernel para usar, lo que suele reducir 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 adecuada para dispositivos Android Go y otros factores de forma con recursos limitados.
Los módulos de GKI también proporcionan un mecanismo para permitir que los proveedores incorporen funciones upstream nuevas después del evento de inmovilización de KMI. El código integrado no se puede reemplazar sin compilar otra imagen, mientras que el código que se entrega como módulo se puede reemplazar 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 que 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, que no está restringido de ninguna manera y 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 de kernel que no son de KMI que no están disponibles para los módulos de proveedores ni para los módulos de GKI no protegidos.
- Los módulos de GKI protegidos pueden exportar símbolos que se convierten en parte de la plataforma de KMI, siempre que esos símbolos se citen en una lista de símbolos.
- Los módulos de GKI protegidos no se pueden anular con los módulos del proveedor.
Un módulo de GKI protegido es la clase predeterminada de los módulos de GKI. Todos los módulos de GKI se consideran protegidos en el momento de la suspensión de KMI.
Módulo de GKI desprotegido
Un módulo de proveedor puede anular un módulo de GKI desprotegido. Después de la inmovilización de KMI, un módulo de GKI protegido puede 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 incluya funciones nuevas de Linux upstream. En la próxima versión de GKI, los módulos no protegidos se vuelven a clasificar como protegidos después de que el código upstream llegue a un kernel común de Android (ACK). Los módulos de GKI no protegidos tienen las siguientes características:
- Los módulos de GKI desprotegidos tienen el mismo acceso a los símbolos exportados que los módulos de proveedores.
- Los módulos de GKI no protegidos no pueden exportar símbolos que exportan los módulos de GKI protegidos.
- Los módulos de GKI no protegidos deben conservar todas las interfaces de KMI como si fueran parte del kernel principal.
- Los módulos de proveedores pueden anular los módulos de GKI no protegidos.
Módulos de proveedores
Los socios proporcionan un módulo de proveedor para implementar capacidades específicas del SoC y del dispositivo. Cualquier módulo de 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 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 configuraciones como CONFIG_ABC_SOC_SUPPORT no se habiliten como módulos de GKI integrados o cargables sin su compatibilidad.
Si existe un controlador o framework 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. No se recomienda realizar este tipo de modificaciones en módulos que no sean específicos del proveedor, ya que las mismas funciones podrían entregarse con el kernel de GKI en una versión futura. Cuando el kernel de GKI contiene capacidades proporcionadas por un módulo de proveedor, el módulo de proveedor no se carga. 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 se habilite como un módulo integrado o GKI en Android 12, en cuyo caso 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 de proveedores si se entregan como módulos de proveedores.
Puedes entregar módulos de proveedores en la imagen vendor o vendor_boot. Los módulos necesarios al principio del proceso de inicio deben estar en vendor_boot.
Hay un costo de tiempo de inicio asociado con la carga de módulos desde vendor_boot.