Viele Android-OEMs modifizieren den ION-Kerneltreiber aus verschiedenen Gründen, z. B. das Hinzufügen von Anbieter-Heaps und die Anpassung der Cache-Verwaltung (Details zu diesen Änderungen vornehmen, siehe ION-Speicher integrieren Allocator). Damit OEMs diese Änderungen bei Verwendung des generischen Kernel-Images (GKI), Android Common Kernel v5.4 bietet ein Framework zur Modularisierung anbieterspezifischer IONs. während der Core ION-Treiber integriert ist. Die folgende Abbildung zeigt die Kernel-Image-Layout.
Abbildung 1: Modularisierter ION-Kernel-Treiber
Modulare ION-Heaps haben die folgenden Vorteile.
- Der ION-Kerntreiber kann Teil des GKI-Image sein und ermöglicht geräteunabhängige Leistungsoptimierungen und Fehlerkorrekturen, um alle Geräte.
- Der ION-Kerntreiber im Common Kernel kann die Heap-Registrierung und die Schnittstelle zum Userspace und zu Kernel-Clients verwalten. Die Heap-Module des Anbieters nur zum Implementieren der benutzerdefinierten Heap-Vorgänge erforderlich sind.
- Der ION-Kerntreiber (als Teil der GKI) kann Hooks für ein einfacheres Gedächtnis enthalten was nicht möglich war, wenn jeder OEM eine eigene den ION-Treiber.
- Modulare ION-Heap-Anbieter von Anbietern sollten bei künftigen Umstellungen auf
dmabuf-Heaps umgestellt werden. einfacher zu machen.
Implementierung
ION-Heap-Module können ihre eigenen dmabuf-Vorgänge registrieren, um die Vorgänge zu überschreiben
die vom zentralen ION-Treiber registriert wurden. Ein dmabuf-Vorgang (z. B. get_flags())
wird vom Core-ION-Treiber nicht unterstützt,
gibt -EOPNOTSUPP zurück, wenn der Heap
bei der Implementierung die
notwendigen Überschreibungen fehlen.
Zur Verbesserung der Leistung kann der Treiber dmabuf einen partiellen Cache ausführen
Wartung (siehe
Änderungsliste).
Kernel-Clients können die dma_buf_begin_cpu_access_partial und
dma_buf_end_cpu_access_partial-Funktionen zur Durchführung einer teilweisen Cache-Wartung.
Der Android Common Kernel enthält modulare Implementierungen des Systems und CMA-Heaps (Contiguous Memory Allocator) zur Verwendung als Referenz für Heaps Modularisierung.
Änderungen am ION UAPI-Header
Der UAPI-Header (ION User Space API) enthält eine ion_heap_id-Enum zur Verwendung in
Sie definieren einen Bereich 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 ein neues IOCTL (ION_IOC_ABI_VERSION) den Userspace-Kunden helfen
ob modulare Heaps verwendet werden.
Generischen System-Heap überschreiben
Der ION-System-Heap ist integriert und Teil des GKI-Image, damit alle
die Zugriff auf einen generischen/geräteunabhängigen Heap benötigt,
Existenz. Daher kann die Heap-ID von ION_HEAP_SYSTEM nicht überschrieben werden. Bis
benutzerdefinierten System-Heap erstellen, Heap-ID im benutzerdefinierten Bereich verwenden
(ION_HEAP_CUSTOM_START bis ION_HEAP_CUSTOM_END), um Zuweisungen vorzunehmen.