Los dispositivos que envían el kernel 4.14 y superior se ven afectados por una importante refactorización del módulo del kernel de Ion , que muchas implementaciones de la capa de abstracción de hardware (HAL) del asignador de memoria gráfica (gralloc) de proveedores llaman para asignar búferes de memoria compartida. Este artículo brinda orientación sobre cómo migrar el código de proveedor heredado a la nueva versión de Ion y analiza posibles rupturas futuras de la interfaz binaria de la aplicación (ABI).
Acerca de iones
Ion es parte del árbol de etapas de trabajo en progreso del núcleo ascendente. Mientras está en preparación, la ABI de espacio de usuario a kernel de Ion puede romperse entre las versiones principales del kernel. Si bien las interrupciones de Ion ABI no afectan directamente a las aplicaciones ordinarias ni a los dispositivos ya lanzados , los proveedores que migren a nuevas versiones principales del kernel pueden encontrar cambios que afecten el código del proveedor que llama a Ion. Además, es posible que se produzcan futuras interrupciones de ABI a medida que el equipo de sistemas de Android trabaje en sentido ascendente para sacar a Ion del árbol de preparación.
Cambios en android-4.14
Kernel 4.12 refactorizó en gran medida el código del kernel de Ion, limpiando y eliminando partes de Ion que se superponían con otros marcos del kernel. Como resultado, muchos ioctls de Ion heredados ya no son relevantes y se han eliminado.
Eliminación de clientes y manijas de Ion
Antes del kernel 4.12, al abrir /dev/ion se asignaba un cliente Ion . El ioctl IOC_ION_ALLOC asignó un nuevo búfer y lo devolvió al espacio de usuario como un identificador de Ion (un entero opaco significativo solo para el cliente de Ion que lo asignó). Para mapear búferes en el espacio de usuario o compartirlos con otros procesos, los identificadores de Ion se volvieron a exportar como dma-buf fds utilizando el ioctl IOC_ION_SHARE .
En el kernel 4.12, el ioctl IOC_ION_ALLOC genera directamente dma-buf fds. Se eliminó el estado de mango de iones intermedio, junto con todos los ioctls que consumen o producen mangos de iones. Debido a que dma-buf fds no está vinculado a clientes Ion específicos, ya no se necesita el ioctl IOC_ION_SHARE y se eliminó toda la infraestructura del cliente Ion.
Adición de ioctls de coherencia de caché
Antes del kernel 4.12, Ion proporcionaba un ioctl ION_IOC_SYNC para sincronizar el descriptor de archivo con la memoria. Este ioctl estaba mal documentado y era inflexible. Como resultado, muchos proveedores implementaron ioctls personalizados para realizar el mantenimiento de la memoria caché.
Kernel 4.12 reemplazó ION_IOC_SYNC con DMA_BUF_IOCTL_SYNC ioctl definido en linux/dma-buf.h . Llame DMA_BUF_IOCTL_SYNC al principio y al final de cada acceso a la CPU, con indicadores que especifiquen si estos accesos son de lectura o escritura. Aunque DMA_BUF_IOCTL_SYNC es más detallado que ION_IOC_SYNC , le da al usuario más control sobre las operaciones de mantenimiento de caché subyacentes.
DMA_BUF_IOCTL_SYNC es parte de la ABI estable del kernel y se puede usar con todos los fds de dma-buf, ya sea que hayan sido asignados o no por Ion.
Migración del código del proveedor a Android-4.12+
Para los clientes del espacio de usuario , el equipo de sistemas de Android recomienda encarecidamente el uso de libion en lugar de llamadas ioctl() de codificación abierta. A partir de Android 9, libion detecta automáticamente el Ion ABI en tiempo de ejecución e intenta enmascarar las diferencias entre los kernels. Sin embargo, cualquier función de libion que haya producido o consumido identificadores ion_user_handle_t ya no funcionará después del kernel 4.12. Puede reemplazar estas funciones con las siguientes operaciones equivalentes en dma-buf fds, que funcionan en todas las versiones del kernel hasta la fecha.
| Llamada ion_user_handle_t heredada | Llamada dma-buf fd equivalente |
|---|---|
ion_alloc(ion_fd, …, &buf_handle) | ion_alloc_fd(ion_fd, ..., &buf_fd) |
ion_share(ion_fd, buf_handle, &buf_fd) | N/A (esta llamada no es necesaria con dma-buf fds) |
ion_map(ion_fd, buf_handle, ...) | mmap(buf_fd, ...) |
ion_free(ion_fd, buf_handle) | close(buf_fd) |
ion_import(ion_fd, buf_fd, &buf_handle) | N/A (esta llamada no es necesaria con dma-buf fds) |
ion_sync_fd(ion_fd, buf_fd) | If (ion_is_legacy(ion_fd)) |
Para clientes en el kernel , debido a que Ion ya no exporta ninguna API orientada al kernel, los controladores que anteriormente usaban la API del kernel de Ion en el kernel con ion_import_dma_buf_fd() deben convertirse para usar la API dma-buf en el kernel con dma_buf_get() .
Futuras roturas de ABI de iones
Antes de que Ion se pueda sacar del árbol de preparación, es posible que las futuras versiones del kernel deban romper la ABI de Ion nuevamente. El equipo de sistemas Android no espera que estos cambios afecten a los dispositivos que se inician con la próxima versión de Android, pero dichos cambios pueden afectar a los dispositivos que se inician con versiones posteriores de Android.
Por ejemplo, la comunidad ascendente ha propuesto dividir el único nodo /dev/ion en múltiples nodos por montón (p. ej., /dev/ion/heap0 ) para permitir que los dispositivos apliquen diferentes políticas de SELinux a cada montón. Si este cambio se implementa en una versión futura del kernel, rompería Ion ABI.
Los dispositivos que envían el kernel 4.14 y superior se ven afectados por una importante refactorización del módulo del kernel de Ion , que muchas implementaciones de la capa de abstracción de hardware (HAL) del asignador de memoria gráfica (gralloc) de proveedores llaman para asignar búferes de memoria compartida. Este artículo brinda orientación sobre cómo migrar el código de proveedor heredado a la nueva versión de Ion y analiza posibles rupturas futuras de la interfaz binaria de la aplicación (ABI).
Acerca de iones
Ion es parte del árbol de etapas de trabajo en progreso del núcleo ascendente. Mientras está en preparación, la ABI del espacio de usuario al kernel de Ion puede interrumpirse entre las versiones principales del kernel. Si bien las interrupciones de Ion ABI no afectan directamente a las aplicaciones ordinarias ni a los dispositivos ya lanzados , los proveedores que migren a nuevas versiones principales del kernel pueden encontrar cambios que afecten el código del proveedor que llama a Ion. Además, es posible que se produzcan futuras interrupciones de ABI a medida que el equipo de sistemas de Android trabaje en sentido ascendente para sacar a Ion del árbol de preparación.
Cambios en android-4.14
Kernel 4.12 refactorizó en gran medida el código del kernel de Ion, limpiando y eliminando partes de Ion que se superponían con otros marcos del kernel. Como resultado, muchos ioctls de Ion heredados ya no son relevantes y se han eliminado.
Eliminación de clientes y manijas de Ion
Antes del kernel 4.12, al abrir /dev/ion se asignaba un cliente Ion . El ioctl IOC_ION_ALLOC asignó un nuevo búfer y lo devolvió al espacio de usuario como un identificador de Ion (un entero opaco significativo solo para el cliente de Ion que lo asignó). Para mapear búferes en el espacio de usuario o compartirlos con otros procesos, los identificadores de Ion se volvieron a exportar como dma-buf fds utilizando el ioctl IOC_ION_SHARE .
En el kernel 4.12, el ioctl IOC_ION_ALLOC genera directamente dma-buf fds. Se eliminó el estado de mango de iones intermedio, junto con todos los ioctls que consumen o producen mangos de iones. Debido a que dma-buf fds no está vinculado a clientes Ion específicos, ya no se necesita el ioctl IOC_ION_SHARE y se eliminó toda la infraestructura del cliente Ion.
Adición de ioctls de coherencia de caché
Antes del kernel 4.12, Ion proporcionaba un ioctl ION_IOC_SYNC para sincronizar el descriptor de archivo con la memoria. Este ioctl estaba mal documentado y era inflexible. Como resultado, muchos proveedores implementaron ioctls personalizados para realizar el mantenimiento de la memoria caché.
Kernel 4.12 reemplazó ION_IOC_SYNC con DMA_BUF_IOCTL_SYNC ioctl definido en linux/dma-buf.h . Llame DMA_BUF_IOCTL_SYNC al principio y al final de cada acceso a la CPU, con indicadores que especifiquen si estos accesos son de lectura o escritura. Aunque DMA_BUF_IOCTL_SYNC es más detallado que ION_IOC_SYNC , le da al usuario más control sobre las operaciones de mantenimiento de caché subyacentes.
DMA_BUF_IOCTL_SYNC es parte de la ABI estable del kernel y se puede usar con todos los fds de dma-buf, ya sea que hayan sido asignados o no por Ion.
Migración del código del proveedor a Android-4.12+
Para los clientes del espacio de usuario , el equipo de sistemas de Android recomienda encarecidamente el uso de libion en lugar de llamadas ioctl() de codificación abierta. A partir de Android 9, libion detecta automáticamente el Ion ABI en tiempo de ejecución e intenta enmascarar las diferencias entre los kernels. Sin embargo, cualquier función de libion que haya producido o consumido identificadores ion_user_handle_t ya no funcionará después del kernel 4.12. Puede reemplazar estas funciones con las siguientes operaciones equivalentes en dma-buf fds, que funcionan en todas las versiones del kernel hasta la fecha.
| Llamada ion_user_handle_t heredada | Llamada dma-buf fd equivalente |
|---|---|
ion_alloc(ion_fd, …, &buf_handle) | ion_alloc_fd(ion_fd, ..., &buf_fd) |
ion_share(ion_fd, buf_handle, &buf_fd) | N/A (esta llamada no es necesaria con dma-buf fds) |
ion_map(ion_fd, buf_handle, ...) | mmap(buf_fd, ...) |
ion_free(ion_fd, buf_handle) | close(buf_fd) |
ion_import(ion_fd, buf_fd, &buf_handle) | N/A (esta llamada no es necesaria con dma-buf fds) |
ion_sync_fd(ion_fd, buf_fd) | If (ion_is_legacy(ion_fd)) |
Para clientes en el kernel , debido a que Ion ya no exporta ninguna API orientada al kernel, los controladores que anteriormente usaban la API del kernel de Ion en el kernel con ion_import_dma_buf_fd() deben convertirse para usar la API dma-buf en el kernel con dma_buf_get() .
Futuras roturas de ABI de iones
Antes de que Ion se pueda sacar del árbol de preparación, es posible que las futuras versiones del kernel deban romper la ABI de Ion nuevamente. El equipo de sistemas Android no espera que estos cambios afecten a los dispositivos que se inician con la próxima versión de Android, pero dichos cambios pueden afectar a los dispositivos que se inician con versiones posteriores de Android.
Por ejemplo, la comunidad ascendente ha propuesto dividir el único nodo /dev/ion en múltiples nodos por montón (p. ej., /dev/ion/heap0 ) para permitir que los dispositivos apliquen diferentes políticas de SELinux a cada montón. Si este cambio se implementa en una versión futura del kernel, rompería Ion ABI.