Viele Android-OEMs ändern den ION-Kernel-Treiber aus verschiedenen Gründen, z. B. um Anbieter-Heaps hinzuzufügen und die Cache-Verwaltung anzupassen (Details zu diesen Änderungen finden Sie unter ION-Arbeitsspeicherzuweisung einbinden). Damit OEMs solche Änderungen bei Verwendung des Generic Kernel Image (GKI) beibehalten können, wurde mit Android Common Kernel v5.4 ein Framework zur Modularisierung anbieterspezifischer ION-Heaps eingeführt, während der ION-Kerntreiber integriert bleibt. Die folgende Abbildung zeigt das Layout des Kernel-Images.
Abbildung 1. Modularisierter ION-Kerneltreiber
Modulare ION-Haufen bieten folgende Vorteile:
- Der ION-Kerntreiber kann Teil des GKI-Abbilds sein, sodass alle geräteunabhängigen Leistungsoptimierungen und Fehlerkorrekturen alle Geräte erreichen.
- Der ION-Kerntreiber im gemeinsamen Kernel kann die Heap-Registrierung verarbeiten und die Schnittstelle zu Nutzerbereichs- und Kernel-Clients verwalten. Die Anbieter-Heap-Module sind nur zum Implementieren der benutzerdefinierten Heap-Vorgänge erforderlich.
- Der ION-Kerntreiber (als Teil der GKI) kann Hooks zur einfacheren Verfolgung der Speichernutzung enthalten. Dies war nicht möglich, wenn jeder OEM über eine eigene Version des ION-Treibers verfügte.
- Modulare ION-Stapel von Anbietern sollten zukünftige Umstellungen auf
dmabuf-Stapel erleichtern.
Implementierung
ION-Heap-Module können ihre eigenen dmabuf-Vorgänge registrieren, um die vom ION-Kerntreiber registrierten zu überschreiben. Bei einem dmabuf-Vorgang (z. B. get_flags()), der vom ION-Kerntreiber nicht unterstützt wird, wird -EOPNOTSUPP zurückgegeben, wenn die Heap-Implementierung die erforderlichen Overrides nicht enthält.
Um die Leistung zu verbessern, kann der dmabuf-Treiber eine teilweise Cache-Wartung ausführen (siehe changelist).
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 der System- und CMA-Heaps (Contiguous Memory Allocator), die als Referenz für die Heap-Modularisierung verwendet werden können.
Änderungen am ION-UAPI-Header
Der ION User Space API-Header (UAPI) enthält ein ion_heap_id-Enum, mit dem ein Bereich von Heap-IDs für die Verwendung durch Anbieter-Heaps definiert werden kann.
/**
* 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),
};
Außerdem kann eine neue IOCTL (ION_IOC_ABI_VERSION) Nutzern im Userspace helfen zu ermitteln, ob modulare Heaps verwendet werden.
Generischen System-Heap überschreiben
Der ION-System-Heap ist in das GKI-Image eingebunden, damit alle Funktionen, die Zugriff auf einen generischen/geräteunabhängigen Heap benötigen, davon abhängig sein können. Daher können Sie die Heap-ID von ION_HEAP_SYSTEM nicht überschreiben. Verwenden Sie zum Erstellen eines benutzerdefinierten System-Heaps eine Heap-ID im benutzerdefinierten Bereich (ION_HEAP_CUSTOM_START bis ION_HEAP_CUSTOM_END), um Zuweisungen vorzunehmen.