Muchos OEM de Android modifican el controlador del kernel ION por diversos motivos, como agregar pilas de proveedores y personalizar la administración de caché (para obtener detalles sobre estas modificaciones, consulte Integración del asignador de memoria ION ). Para permitir que los OEM conserven dichas modificaciones cuando utilizan la imagen genérica del kernel (GKI) , Android Common Kernel v5.4 introduce un marco para modularizar los montones de ION específicos del proveedor mientras se mantiene el controlador ION central integrado. La siguiente figura muestra el diseño de la imagen del kernel .
Figura 1. Controlador del kernel ION modularizado
Los montones de ION modulares tienen las siguientes ventajas.
- El controlador central de ION puede ser parte de la imagen de GKI, lo que permite que todas las optimizaciones de rendimiento y correcciones de errores independientes del dispositivo lleguen a todos los dispositivos.
- El controlador central ION en el kernel común puede manejar el registro del montón y administrar la interfaz para el espacio de usuario y los clientes del kernel. Los módulos de montón del proveedor sólo son necesarios para implementar las operaciones de montón personalizadas.
- El controlador central ION (como parte de GKI) puede incluir enlaces para facilitar el seguimiento del uso de la memoria, lo que no era posible cuando cada OEM tenía su propia versión del controlador ION.
- Los montones ION de proveedores modulares deberían facilitar cualquier transición futura a montones
dmabuf.
Implementar
Los módulos de montón ION pueden registrar sus propias operaciones dmabuf para anular las registradas por el controlador ION principal. Una operación dmabuf (como get_flags() ) que no es compatible con el controlador ION principal devuelve -EOPNOTSUPP si la implementación del montón carece de las anulaciones necesarias.
Para mejorar el rendimiento, el controlador dmabuf puede realizar un mantenimiento parcial de la caché (consulte la lista de cambios ). Los clientes del kernel pueden utilizar las funciones dma_buf_begin_cpu_access_partial y dma_buf_end_cpu_access_partial para realizar el mantenimiento parcial de la caché.
El kernel común de Android contiene implementaciones modulares del sistema y montones de asignador de memoria contigua (CMA) para su uso como referencia para la modularización del montón.
Cambios en el encabezado ION UAPI
El encabezado de la API del espacio de usuario (UAPI) de ION contiene una enumeración ion_heap_id que se utiliza para definir un rango de ID de montón para uso de los montones de proveedores.
/**
* ion_heap_id - list of heap IDs that Android can use
*
* @ION_HEAP_SYSTEM ID for the ION_HEAP_TYPE_SYSTEM
* @ION_HEAP_DMA_START Start of reserved ID range for heaps of type ION_HEAP_TYPE_DMA
* @ION_HEAP_DMA_END End of reserved ID range for heaps of type ION_HEAP_TYPE_DMA
* @ION_HEAP_CUSTOM_START Start of reserved ID range for heaps of custom type
* @ION_HEAP_CUSTOM_END End of reserved ID range for heaps of custom type
*/
enum ion_heap_id {
ION_HEAP_SYSTEM = (1 << ION_HEAP_TYPE_SYSTEM),
ION_HEAP_DMA_START = (ION_HEAP_SYSTEM << 1),
ION_HEAP_DMA_END = (ION_HEAP_DMA_START << 7),
ION_HEAP_CUSTOM_START = (ION_HEAP_DMA_END << 1),
ION_HEAP_CUSTOM_END = (ION_HEAP_CUSTOM_START << 22),
};
Además, un nuevo IOCTL ( ION_IOC_ABI_VERSION ) puede ayudar a los clientes del espacio de usuario a determinar si se están utilizando montones modulares.
Anulación del montón del sistema genérico
El montón del sistema ION está integrado y es parte de la imagen de GKI para garantizar que cualquier característica que necesite acceso a un montón genérico/independiente del dispositivo pueda depender de su existencia. Como tal, no puedes anular el ID del montón de ION_HEAP_SYSTEM . Para crear un montón de sistema personalizado, utilice un ID de montón en el rango personalizado ( ION_HEAP_CUSTOM_START a ION_HEAP_CUSTOM_END ) para realizar asignaciones.