Viele Android-OEMs ändern den ION-Kerneltreiber aus verschiedenen Gründen, z. B. durch das Hinzufügen von Hersteller-Heaps und das Anpassen der Cache-Verwaltung (Einzelheiten zu diesen Änderungen finden Sie unter „Integration des ION-Speicherzuweisers “). Damit OEMs solche Änderungen beibehalten können, wenn sie das Generic Kernel Image (GKI) verwenden, führt Android Common Kernel v5.4 ein Framework zur Modularisierung herstellerspezifischer ION-Heaps ein, während der Kern-ION-Treiber integriert bleibt. Die folgende Abbildung zeigt das Kernel-Image-Layout .
Abbildung 1. Modularisierter ION-Kernel-Treiber
Modulare ION-Heaps bieten die folgenden Vorteile.
- Der ION-Kerntreiber kann Teil des GKI-Images sein, sodass alle geräteunabhängigen Leistungsoptimierungen und Fehlerbehebungen alle Geräte erreichen können.
- Der ION-Kerntreiber im gemeinsamen Kernel kann die Heap-Registrierung übernehmen und die Schnittstelle zu Userspace- und Kernel-Clients verwalten. Die Heap-Module des Anbieters sind nur zum Implementieren der benutzerdefinierten Heap-Vorgänge erforderlich.
- Der ION-Kerntreiber (als Teil des GKI) kann Hooks für eine einfachere Verfolgung der Speichernutzung enthalten, was nicht möglich war, als jeder OEM seine eigene Version des ION-Treibers hatte.
- Modulare ION-Heaps von Anbietern sollten künftige Umstellungen auf
dmabuf
Heaps erleichtern.
Umsetzung
ION-Heap-Module können ihre eigenen dmabuf
Vorgänge registrieren, um die vom ION-Kerntreiber registrierten Vorgänge zu überschreiben. Eine dmabuf
Operation (z. B. get_flags()
), die vom ION-Kerntreiber nicht unterstützt wird, gibt -EOPNOTSUPP
zurück, wenn der Heap-Implementierung die erforderlichen Überschreibungen fehlen.
Um die Leistung zu verbessern, kann der dmabuf
Treiber eine teilweise Cache-Wartung durchführen (siehe Änderungsliste ). Kernel-Clients können die Funktionen dma_buf_begin_cpu_access_partial
und dma_buf_end_cpu_access_partial
verwenden, um eine teilweise Cache-Wartung durchzuführen.
Der Android Common Kernel enthält modulare Implementierungen des Systems und CMA-Heaps (Contiguous Memory Allocator) zur Verwendung als Referenz für die Heap-Modularisierung.
Änderungen am ION UAPI-Header
Der ION User Space API (UAPI)-Header enthält eine ion_heap_id
Enumeration zur Verwendung beim Definieren eines Bereichs von Heap-IDs zur Verwendung durch Anbieter-Heaps.
/**
* 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),
};
Darüber hinaus kann eine neue IOCTL
( ION_IOC_ABI_VERSION
) User-Space-Clients dabei helfen, festzustellen, ob modulare Heaps verwendet werden.
Überschreiben des generischen Systemheaps
Der ION-System-Heap ist integriert und Teil des GKI-Images, um sicherzustellen, dass jede Funktion, die Zugriff auf einen generischen/geräteunabhängigen Heap benötigt, von dessen Existenz abhängig sein kann. Daher können Sie die Heap-ID von ION_HEAP_SYSTEM
nicht überschreiben. Um einen benutzerdefinierten System-Heap zu erstellen, verwenden Sie eine Heap-ID im benutzerdefinierten Bereich ( ION_HEAP_CUSTOM_START
bis ION_HEAP_CUSTOM_END
), um Zuweisungen durchzuführen.