Wielu producentów OEM Androida modyfikuje sterownik jądra ION z różnych powodów, np. dodając stosy dostawcy i dostosowując zarządzanie pamięcią podręcznej (szczegółowe informacje o tych modyfikacjach znajdziesz w artykule Integracja z alokatorem pamięci ION). Aby umożliwić producentom OEM zachowanie takich zmian podczas korzystania z ogólnego obrazu jądra (GKI), Android Common Kernel w wersji 5.4 wprowadza platformę do modularyzacji stosów ION dla konkretnego dostawcy przy zachowaniu wbudowanego głównego sterownika ION. Poniższy rysunek pokazuje układ obrazu jądra.
Rysunek 1. Modułowy sterownik jądra ION
Modułowe stosy ION mają te zalety:
- Sterownik rdzenia ION może być częścią obrazu GKI, co umożliwia stosowanie optymalizacji wydajności i poprawek błędów niezależnych od urządzenia na wszystkich urządzeniach.
- Sterownik rdzenia ION w ramach wspólnego jądra może obsługiwać rejestrację stosu i zarządzać interfejsem dla przestrzeni użytkownika i klientów jądra. Moduł dostawcy stosu jest wymagany tylko do implementowania operacji niestandardowego stosu.
- Sterownik rdzenia ION (będący częścią GKI) może zawierać elementy umożliwiające łatwiejsze śledzenie wykorzystania pamięci, co nie było możliwe, gdy każdy producent OEM miał własną wersję sterownika ION.
- Modułowa pamięć ION dostawcy powinna ułatwić przyszłe przejścia na pamięć
dmabuf.
Implementacja
Moduły pamięci ION mogą rejestrować własne operacje dmabuf, aby zastąpić te zarejestrowane przez podstawowy sterownik ION. Operacja dmabuf (np. get_flags()), która nie jest obsługiwana przez podstawowy sterownik ION, zwraca -EOPNOTSUPP, jeśli implementacja stosu nie zawiera wymaganych zastąpień.
Aby zwiększyć wydajność, sterownik dmabuf może przeprowadzić częściową konserwację pamięci podręcznej (patrz lista zmian).
Klienty 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ólny rdzeń Androida zawiera modułowe implementacje stosów systemowych i ciągłych alokacji pamięci (CMA) do użycia jako odniesienia do modułowej implementacji stosu.
Zmiany w nagłówku ION UAPI
Nagłówek interfejsu ION user space API (UAPI) zawiera typ wyliczeniowy ion_heap_id, który służy do definiowania zakresu identyfikatorów stosu do użycia przez stosy 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 nowa zmienna IOCTL (ION_IOC_ABI_VERSION) może pomóc klientom przestrzeni użytkownika określić, czy są używane stosy modułowe.
Zastępowanie ogólnego stosu systemu
Systemowy stos ION jest wbudowany i jest częścią obrazu GKI, aby zapewnić, że każda funkcja, która potrzebuje dostępu do ogólnego stosu niezależnego od urządzenia, może polegać na jego istnieniu. W związku z tym nie można zastąpić identyfikatora stosu ION_HEAP_SYSTEM. Aby utworzyć niestandardową stertę systemu, użyj identyfikatora sterty z zakresu niestandardowego (ION_HEAP_CUSTOM_START–ION_HEAP_CUSTOM_END) do wykonywania alokacji.