कई Android OEM, ION कर्नेल ड्राइवर में कई वजहों से बदलाव करते हैं. जैसे, वेंडर हेप जोड़ना और कैश मेमोरी मैनेजमेंट को पसंद के मुताबिक बनाना. इन बदलावों के बारे में ज़्यादा जानने के लिए, ION मेमोरी ऐलोकेटर को इंटिग्रेट करना लेख पढ़ें. OEM, Generic Kernel Image (GKI) का इस्तेमाल करते समय, ऐसे बदलावों को बनाए रख सकें, इसके लिए Android Common Kernel v5.4 में एक फ़्रेमवर्क जोड़ा गया है. इस फ़्रेमवर्क की मदद से, वेंडर के हिसाब से ION हेप को मॉड्यूलर किया जा सकता है. साथ ही, इसमें कोर ION ड्राइवर पहले से मौजूद रहता है. नीचे दिए गए इलस्ट्रेशन में, कोर इमेज का लेआउट दिखाया गया है.
पहली इमेज. मॉड्यूलराइज़्ड ION कर्नेल ड्राइवर
मॉड्यूलर ION हेप के ये फ़ायदे हैं.
- ION कोर ड्राइवर, GKI इमेज का हिस्सा हो सकता है. इससे सभी डिवाइसों पर परफ़ॉर्मेंस को ऑप्टिमाइज़ करने और गड़बड़ियों को ठीक करने की सुविधा मिलती है.
- सामान्य कर्नेल में ION कोर ड्राइवर हीप रजिस्ट्रेशन को मैनेज कर सकता है. साथ ही, यूज़रस्पेस और कर्नेल क्लाइंट के लिए इंटरफ़ेस को मैनेज कर सकता है. वेंडर हीप मॉड्यूल की ज़रूरत सिर्फ़ कस्टम हीप ऑपरेशन को लागू करने के लिए होती है.
- GKI के हिस्से के तौर पर, ION कोर ड्राइवर में आसानी से मेमोरी इस्तेमाल की ट्रैकिंग के लिए हुक शामिल किए जा सकते हैं. जब हर OEM के पास ION ड्राइवर का अपना वर्शन होता था, तब ऐसा नहीं किया जा सकता था.
- मॉड्यूलर वेंडर ION हेप की मदद से, आने वाले समय में
dmabufहेप पर ट्रांज़िशन करना आसान हो जाएगा.
लागू करना
ION हेप मॉड्यूल, अपने dmabuf ऑपरेशन रजिस्टर कर सकते हैं, ताकि कोर ION ड्राइवर से रजिस्टर किए गए ऑपरेशन को बदला जा सके. अगर ढेर के लागू होने में ज़रूरी बदलाव नहीं किए गए हैं, तो dmabuf कार्रवाई (जैसे कि get_flags()), जो मुख्य ION ड्राइवर के साथ काम नहीं करती है, तो -EOPNOTSUPP दिखाती है.
परफ़ॉर्मेंस को बेहतर बनाने के लिए, dmabuf ड्राइवर कुछ हद तक कैश मेमोरी का रखरखाव कर सकता है (चेंजलिस्ट देखें).
कैश मेमोरी का कुछ हिस्सा ठीक से काम करने के लिए, कर्नेल क्लाइंट dma_buf_begin_cpu_access_partial और dma_buf_end_cpu_access_partial फ़ंक्शन इस्तेमाल कर सकते हैं.
Android Common Kernel में, सिस्टम और एक साथ मेमोरी को ऐलोकेट करने वाले (सीएमए) ढेर को मॉड्यूलर तरीके से लागू किया गया है. इसका इस्तेमाल, ढेर को मॉड्यूलर बनाने के लिए रेफ़रंस के तौर पर किया जाता है.
ION UAPI हेडर में बदलाव
ION यूज़र स्पेस एपीआई (यूएपीआई) हेडर में एक ion_heap_id एनम शामिल होता है. इसका इस्तेमाल, वेंडर हेप के इस्तेमाल के लिए, हेप आईडी की रेंज तय करने में किया जाता है.
/**
* 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),
};
इसके अलावा, नए IOCTL (ION_IOC_ABI_VERSION) से उपयोगकर्ता स्पेस क्लाइंट को यह तय करने में मदद मिल सकती है कि मॉड्यूलर हेप का इस्तेमाल किया जा रहा है या नहीं.
सामान्य सिस्टम हीप को ओवरराइड किया जा रहा है
ION सिस्टम हेप, GKI इमेज का हिस्सा है और यह पहले से मौजूद होता है. इससे यह पक्का होता है कि किसी भी ऐसी सुविधा के लिए, जिसे सामान्य/डिवाइस पर निर्भर न करने वाली हेप का ऐक्सेस चाहिए, वह इस हेप के मौजूद होने पर ही काम कर सकती है. इसलिए, ION_HEAP_SYSTEM के हीप आईडी को बदला नहीं जा सकता. पसंद के मुताबिक सिस्टम हेप बनाने के लिए, कस्टम रेंज (ION_HEAP_CUSTOM_START से ION_HEAP_CUSTOM_END) में हेप आईडी का इस्तेमाल करके, एलोकेशन करें.