Descripción general de los módulos del kernel

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 Generic Kernel Image (GKI) se utilizan para ofrecer una funcionalidad del kernel que no requiere arranque, separada del kernel central genérico. Con los módulos GKI, puede elegir la funcionalidad específica del kernel para usar, 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 ideal para dispositivos Android Go y otros factores de forma con recursos restringidos.

Los módulos GKI también brindan 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 un módulo se puede reemplazar por otro módulo.

Los módulos GKI utilizan la infraestructura de firma de 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 y cuando solo usen los 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 no protegido .

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 de kernel que no son KMI que no están disponibles para módulos de proveedores o módulos GKI no protegidos.
  • Los módulos GKI protegidos pueden exportar símbolos que pasan a formar parte de la superficie KMI siempre que dichos símbolos se citen 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 GKI desprotegido puede ser anulado por un módulo de proveedor. Después de la congelación de KMI, un módulo GKI protegido puede reclasificarse como desprotegido si el equipo de GKI decide que los proveedores deben anular la implementación predeterminada con una versión que incluya nuevas funciones de Linux ascendente. En la próxima versión de GKI, los módulos desprotegidos se reclasifican como protegidos después de que el código ascendente llega a un kernel común de Android (ACK). Los módulos GKI sin protección tienen las siguientes características:

  • Los módulos GKI sin protección tienen el mismo acceso a los símbolos exportados que los módulos de proveedores.
  • Los módulos GKI sin protección 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 kernel central.
  • Los módulos GKI desprotegidos pueden ser anulados por módulos de proveedores.

Módulos de proveedores

Los socios entregan un módulo de proveedor para implementar el SoC y la funcionalidad específica del dispositivo. Cualquier módulo de kernel existente que no se entregue como parte del kernel de GKI se puede entregar como un 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 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 marco o controlador 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 dichas modificaciones para módulos no 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 ofrecer módulos de proveedores de greybus. Sin embargo, CONFIG_GREYBUS podría habilitarse como un módulo o GKI integrado en Android 12, en cuyo caso no se cargarán los módulos del proveedor de greybus. Una mejor práctica es usar la versión ascendente de los controladores no específicos del proveedor si se entregan como módulos del proveedor.

Puede entregar módulos de proveedor en la imagen de vendor o de vendor_boot . Los módulos requeridos 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 .