Wielu producentów OEM systemu Android modyfikuje sterownik jądra ION z różnych powodów, takich jak dodanie stert dostawców i dostosowanie zarządzania pamięcią podręczną (szczegółowe informacje na temat tych modyfikacji można znaleźć w części Integracja modułu alokacji pamięci ION ). Aby umożliwić producentom OEM zachowanie takich modyfikacji podczas korzystania z Generic Kernel Image (GKI) , Android Common Kernel v5.4 wprowadza platformę do modularyzacji specyficznych dla dostawcy stert ION, zachowując jednocześnie wbudowany podstawowy sterownik ION. Poniższy rysunek przedstawia układ obrazu jądra .
Rysunek 1. Modularny sterownik jądra ION
Modułowe kopce ION mają następujące zalety.
- Podstawowy sterownik ION może być częścią obrazu GKI, umożliwiając niezależne od urządzenia optymalizacje wydajności i poprawki błędów, aby dotrzeć do wszystkich urządzeń.
- Podstawowy sterownik ION we wspólnym jądrze może obsługiwać rejestrację sterty i zarządzać interfejsem do przestrzeni użytkownika i klientów jądra. Moduły sterty dostawcy są wymagane tylko do implementowania niestandardowych operacji na stercie.
- Podstawowy sterownik ION (jako część GKI) może zawierać elementy ułatwiające śledzenie wykorzystania pamięci, co nie było możliwe, gdy każdy producent OEM miał własną wersję sterownika ION.
- Modułowe sterty ION dostawcy powinny ułatwić przyszłe przejścia na sterty
dmabuf.
Realizowanie
Moduły sterty ION mogą rejestrować własne operacje dmabuf , aby zastąpić te zarejestrowane przez podstawowy sterownik ION. Operacja dmabuf (taka jak get_flags() ), która nie jest obsługiwana przez podstawowy sterownik ION, zwraca -EOPNOTSUPP jeśli w implementacji sterty brakuje niezbędnych przesłonięć.
Aby poprawić wydajność, sterownik dmabuf może przeprowadzić częściową konserwację pamięci podręcznej (zobacz listę zmian ). Klienci jądra mogą używać funkcji dma_buf_begin_cpu_access_partial i dma_buf_end_cpu_access_partial do wykonywania częściowej konserwacji pamięci podręcznej.
Wspólne jądro systemu Android zawiera modułowe implementacje systemu i sterty alokatora pamięci ciągłej (CMA), które można wykorzystać jako punkt odniesienia przy modularyzacji sterty.
Zmiany w nagłówku ION UAPI
Nagłówek API przestrzeni użytkownika ION (UAPI) zawiera wyliczenie ion_heap_id do wykorzystania przy definiowaniu zakresu identyfikatorów stert do wykorzystania przez sterty dostawców.
/**
* 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),
};
Ponadto nowy IOCTL ( ION_IOC_ABI_VERSION ) może pomóc klientom przestrzeni użytkownika określić, czy używane są sterty modułowe.
Zastępowanie ogólnej sterty systemowej
Kopiec systemu ION jest wbudowany i stanowi część obrazu GKI, aby zapewnić, że każda funkcja wymagająca dostępu do sterty ogólnej/niezależnej od urządzenia może zależeć od jej istnienia. W związku z tym nie można zastąpić identyfikatora sterty ION_HEAP_SYSTEM . Aby utworzyć dostosowaną stertę systemową, użyj identyfikatora sterty z niestandardowego zakresu ( ION_HEAP_CUSTOM_START do ION_HEAP_CUSTOM_END ), aby przeprowadzić alokację.