शिपिंग कर्नेल 4.14 और उसके बाद के वर्शन वाले डिवाइसों पर, ION कर्नेल मॉड्यूल की अहम रीफ़ैक्टरिंग का असर पड़ा है. इसे कई वेंडर ग्राफ़िक मेमोरी ऐलोकेटर (gralloc) हार्डवेयर ऐब्स्ट्रक्शन लेयर (HAL) लागू करने की वजह से शेयर किया जाता है, ताकि शेयर किए गए मेमोरी बफ़र का बंटवारा किया जा सके. इस पेज पर, लेगसी वेंडर कोड को ION के नए वर्शन पर माइग्रेट करने के बारे में दिशा-निर्देश दिए गए हैं. साथ ही, आने वाले समय में ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) के संभावित ब्रेक के बारे में बताया गया है.
ION के बारे में जानकारी
ION, अपस्ट्रीम कर्नेल के अभी काम चल रहे स्टैजिंग ट्री का हिस्सा है. स्टैजिंग के दौरान, ION के यूज़रस्पेस-टू-कर्नल एबीआई में, कलेर्नल के मेजर वर्शन के बीच गड़बड़ी हो सकती है. ION ABI के बीच के अंतर का असर, आम तौर पर इस्तेमाल होने वाले ऐप्लिकेशन या पहले से लॉन्च किए गए डिवाइसों पर सीधे तौर पर नहीं पड़ता. हालांकि, नए मुख्य कर्नेल वर्शन पर माइग्रेट करने वाले वेंडर को ऐसे बदलाव दिख सकते हैं जिनका असर, ION में वेंडर कोड को कॉल करने पर पड़ता है. इसके अलावा, आने वाले समय में एबीआई के लिए ब्रेक भी आ सकते हैं, क्योंकि Android सिस्टम की टीम, ION को स्टेजिंग ट्री से बाहर ले जाने के लिए अपस्ट्रीम के साथ काम करती है.
android-4.14 में हुए बदलाव
Kernel 4.12 में ION kernel कोड को काफ़ी बदलाव किया गया है. इसमें ION के उन हिस्सों को हटाया गया है जो दूसरे kernel फ़्रेमवर्क के साथ ओवरलैप होते हैं. साथ ही, ION को बेहतर बनाने के लिए उसमें मौजूद गड़बड़ियों को ठीक किया गया है. इस वजह से, कई लेगसी ION ioctl अब काम के नहीं हैं और उन्हें हटा दिया गया है.
ION क्लाइंट और हैंडल हटाना
कर्नेल 4.12 से पहले, /dev/ion खोलने पर एक ION क्लाइंट असाइन किया जाता था. ION_IOC_ALLOC ioctl ने एक नया बफ़र तय किया है और उसे ION हैंडल के तौर पर यूज़रस्पेस में वापस भेज दिया है.
यह एक ओपेक पूर्णांक है, जिसका मतलब सिर्फ़ उस ION क्लाइंट के लिए होता है जिसने इसे असाइन किया है.
बफ़र को उपयोगकर्ता स्पेस में मैप करने या उन्हें अन्य प्रोसेस के साथ शेयर करने के लिए, ION_IOC_SHARE ioctl का इस्तेमाल करके ION
हैंडल को डीएमए-बफ़ फ़्ड के तौर पर फिर से एक्सपोर्ट किया गया.
kernel 4.12 में, ION_IOC_ALLOC ioctl सीधे
dma-buf fds को आउटपुट करता है. ION हैंडल की इंटरमीडियरी स्टेट हटा दी गई है. साथ ही, ION हैंडल का इस्तेमाल करने या जनरेट करने वाले सभी ioctls भी हटा दिए गए हैं. dma-buf fds, किसी खास ION क्लाइंट से नहीं जुड़े होते हैं. इसलिए, ION_IOC_SHARE
ioctl की अब ज़रूरत नहीं है और ION क्लाइंट का पूरा इन्फ़्रास्ट्रक्चर हटा दिया गया है.
कैश-कोहरेन्सी ioctls जोड़ना
कर्नेल 4.12 से पहले, ION ने फ़ाइल डिस्क्रिप्टर को मेमोरी के साथ सिंक करने के लिए, ION_IOC_SYNC ioctl दिया था. इस ioctl के बारे में कम जानकारी दी गई थी और इसे इस्तेमाल करना मुश्किल था. इस वजह से, कई वेंडर ने कैश मेमोरी को मैनेज करने के लिए, कस्टम
ioctls लागू किए.
कर्नेल 4.12 ने ION_IOC_SYNC को
linux/dma-buf.h में बताए गए
DMA_BUF_IOCTL_SYNC ioctl से बदल दिया है.
हर सीपीयू ऐक्सेस की शुरुआत और आखिर में DMA_BUF_IOCTL_SYNC को कॉल करें. साथ ही, फ़्लैग का इस्तेमाल करके बताएं कि ये ऐक्सेस, पढ़ने और/या लिखने के लिए हैं. हालांकि, DMA_BUF_IOCTL_SYNC
ION_IOC_SYNC से ज़्यादा शब्दों में है, लेकिन इससे उपयोगकर्ता को कैश मेमोरी के रखरखाव से जुड़े ऑपरेशन पर ज़्यादा कंट्रोल मिलता है.
DMA_BUF_IOCTL_SYNC, कर्नेल के स्थिर एबीआई का हिस्सा है. साथ ही, इसे सभी dma-buf fds के साथ इस्तेमाल किया जा सकता है. भले ही, उन्हें ION ने एलोकेट किया हो या नहीं.
वेंडर कोड को android-4.12+ पर माइग्रेट करना
Android सिस्टम टीम, userspace क्लाइंट के लिए, ioctl() कॉल को ओपन-कोड करने के बजाय, libion का इस्तेमाल करने का सुझाव देती है. Android 9 के बाद से, libion अपने-आप ही रनटाइम पर ION ABI का पता लगा लेता है और कर्नेल के बीच के किसी भी अंतर को छिपाने की कोशिश करता है.
हालांकि, ion_user_handle_t हैंडल जनरेट करने या इस्तेमाल करने वाले सभी libion फ़ंक्शन, कर्नेल 4.12 के बाद काम नहीं करते. इन फ़ंक्शन की जगह पर, dma-buf fds पर इससे मिलती-जुलती कार्रवाइयां की जा सकती हैं. ये कार्रवाइयां, कर्नेल के अब तक के सभी वर्शन पर काम करती हैं.
| लेगसी ion_user_handle_t कॉल | dma-buf fd कॉल के बराबर |
|---|---|
ion_alloc(ion_fd, …, &buf_handle) |
ion_alloc_fd(ion_fd, ..., &buf_fd) |
ion_share(ion_fd, buf_handle, &buf_fd) |
लागू नहीं (dma-buf fds के साथ इस कॉल की ज़रूरत नहीं है) |
ion_map(ion_fd, buf_handle, ...) |
mmap(buf_fd, ...) |
ion_free(ion_fd, buf_handle) |
close(buf_fd) |
ion_import(ion_fd, buf_fd, &buf_handle) |
लागू नहीं (dma-buf fds के साथ इस कॉल की ज़रूरत नहीं है) |
ion_sync_fd(ion_fd, buf_fd) |
If (ion_is_legacy(ion_fd))
ion_sync_fd(ion_fd, buf_fd);
else
ioctl(buf_fd, DMA_BUF_IOCTL_SYNC, ...); |
इन-कर्नल क्लाइंट के लिए, ION अब किसी भी कर्नेल-फ़ेसिंग एपीआई को एक्सपोर्ट नहीं करता. इसलिए, जिन ड्राइवरों ने पहले ion_import_dma_buf_fd() के साथ इन-कर्नल ION कर्नेल एपीआई का इस्तेमाल किया था उन्हें dma_buf_get() के साथ इन-कर्नल dma-buf एपीआई का इस्तेमाल करने के लिए बदलना होगा.
आने वाले समय में ION एबीआई के लिए ब्रेक
ION को स्टेजिंग ट्री से बाहर ले जाने से पहले, आने वाले समय में की जा सकने वाली रिलीज़ को ION ABI को फिर से तोड़ना पड़ सकता है. Android सिस्टम टीम को नहीं लगता कि इन बदलावों से, अगले Android वर्शन के साथ लॉन्च होने वाले डिवाइसों पर असर पड़ेगा. हालांकि, इन बदलावों से Android के बाद के वर्शन के साथ लॉन्च होने वाले डिवाइसों पर असर पड़ सकता है.
उदाहरण के लिए, अपस्ट्रीम कम्यूनिटी ने एक /dev/ion नोड को हर-हीप नोड (उदाहरण के लिए, /dev/ion/heap0) में बांटने का सुझाव दिया है, ताकि डिवाइस हर हीप पर अलग-अलग SELinux नीतियां लागू कर सकें. अगर यह बदलाव, आने वाले समय में रिलीज़ होने वाले कर्नेल में लागू किया जाता है, तो इससे ION ABI काम नहीं करेगा.