जीकेआई के लिए कर्नेल कोड डेवलप करना

जेनेरिक कर्नेल इमेज (जीकेआई) अपस्ट्रीम Linux कर्नेल के साथ अलाइन करके कर्नेल फ़्रैगमेंटेशन को कम करती है. हालांकि, कुछ पैच को अपस्ट्रीम में स्वीकार न किए जाने की मान्य वजहें हैं. साथ ही, प्रॉडक्ट के शेड्यूल को पूरा करना ज़रूरी है. इसलिए, कुछ पैच को Android Common Kernel (ACK) के सोर्स में बनाए रखा जाता है, जिनसे GKI बनाया जाता है.

डेवलपर को पहले विकल्प के तौर पर, Linux Kernel Mailing List (LKML) का इस्तेमाल करके कोड में बदलाव करने का अनुरोध सबमिट करना होगा. साथ ही, ACK android-mainline ब्रांच में सिर्फ़ तब सबमिट करना होगा, जब अपस्ट्रीम काम न करने की कोई ठोस वजह हो. मान्य वजहों के उदाहरण और उन्हें मैनेज करने का तरीका यहां दिया गया है.

  • पैच को LKML को सबमिट किया गया था, लेकिन प्रॉडक्ट रिलीज़ करने के लिए, उसे समय पर स्वीकार नहीं किया गया. इस पैच को मैनेज करने के लिए:

    • इस बात का सबूत दें कि पैच को LKML में सबमिट किया गया था और पैच के लिए टिप्पणियां मिली थीं या उस समय का अनुमान दें जब पैच को अपस्ट्रीम में सबमिट किया गया था.
    • ACK में पैच को शामिल करने के लिए, कार्रवाई का तरीका तय करें. साथ ही, अपस्ट्रीम से इसकी मंज़ूरी पाएं. इसके बाद, अपस्ट्रीम का फ़ाइनल वर्शन ACK में मर्ज होने पर, पैच को ACK से हटा दें.

  • पैच में, वेंडर मॉड्यूल के लिए EXPORT_SYMBOLS_GPL() तय किया गया है. हालांकि, इसे अपस्ट्रीम सबमिट नहीं किया जा सका, क्योंकि ट्री में ऐसे कोई मॉड्यूल नहीं है जो उस सिंबल का इस्तेमाल करता हो. इस पैच को मैनेज करने के लिए, इस बारे में जानकारी दें कि आपके मॉड्यूल को अपस्ट्रीम सबमिट क्यों नहीं किया जा सकता. साथ ही, यह भी बताएं कि इस अनुरोध को करने से पहले, आपने कौनसे विकल्पों पर विचार किया था.

  • पैच, अपस्ट्रीम के लिए ज़रूरत के मुताबिक नहीं है. साथ ही, प्रॉडक्ट रिलीज़ होने से पहले, इसे फिर से बनाने का समय नहीं है. इस पैच को मैनेज करने के लिए, वह अनुमानित समय बताएं जिसमें रीफ़ैक्टर किए गए पैच को अपस्ट्रीम सबमिट किया जाएगा. समीक्षा के लिए, रीफ़ैक्टर किए गए पैच अपस्ट्रीम को समीक्षा के लिए सबमिट करने के प्लान के बिना, पैच को ACK में स्वीकार नहीं किया जाएगा.

  • अपस्ट्रीम, पैच को स्वीकार नहीं कर सकता, क्योंकि... <insert reason here>. इस पैच को मैनेज करने के लिए, Android kernel टीम से संपर्क करें और पैच को फिर से लिखने के विकल्पों पर हमारे साथ काम करें, ताकि इसे समीक्षा के लिए सबमिट किया जा सके और अपस्ट्रीम में स्वीकार किया जा सके.

इसके अलावा, कई और वजहें हो सकती हैं. गड़बड़ी या पैच सबमिट करते समय, सही वजह बताएं. साथ ही, कुछ बदलाव और चर्चा की उम्मीद करें. हम जानते हैं कि ACK में कुछ पैच होते हैं. खास तौर पर, GKI के शुरुआती चरणों में, जब सभी लोग अपस्ट्रीम करने का तरीका सीख रहे होते हैं. हालांकि, ऐसा करने के लिए प्रॉडक्ट के शेड्यूल में बदलाव नहीं किया जा सकता. अपस्ट्रीम करने से जुड़ी ज़रूरी शर्तें, समय के साथ ज़्यादा सख्त हो सकती हैं.

पैच से जुड़ी ज़रूरी शर्तें

पैच, Linux सोर्स ट्री में बताए गए Linux kernel कोडिंग स्टैंडर्ड के मुताबिक होने चाहिए. भले ही, उन्हें अपस्ट्रीम या ACK में सबमिट किया गया हो. scripts/checkpatch.pl स्क्रिप्ट, Gerrit प्री-सबमिट टेस्टिंग के हिस्से के तौर पर चलती है, इसलिए इसे पहले से चलाकर पक्का करें कि यह पास हो जाए. सबमिट करने से पहले की जाने वाली जांच के उसी कॉन्फ़िगरेशन के साथ checkpatch स्क्रिप्ट को चलाने के लिए, //build/kernel/static_analysis:checkpatch_presubmit का इस्तेमाल करें. ज़्यादा जानकारी के लिए, build/kernel/kleaf/docs/checkpatch.md देखें.

ACK पैच

ACK को सबमिट किए गए पैच, Linux kernel कोडिंग स्टैंडर्ड और योगदान से जुड़े दिशा-निर्देशों के मुताबिक होने चाहिए. आपको कमिट मैसेज में Change-Id टैग शामिल करना होगा. अगर पैच को एक से ज़्यादा शाखाओं (उदाहरण के लिए, android-mainline और android12-5.4) में सबमिट किया जाता है, तो आपको पैच के सभी इंस्टेंस के लिए एक ही Change-Id का इस्तेमाल करना होगा.

अपस्ट्रीम समीक्षा के लिए, पहले LKML को पैच सबमिट करें. अगर पैच यह है:

  • अपस्ट्रीम में स्वीकार होने के बाद, यह android-mainline में अपने-आप मर्ज हो जाता है.
  • अपस्ट्रीम में स्वीकार नहीं किया गया. इसे android-mainline पर सबमिट करें. साथ ही, अपस्ट्रीम सबमिशन का रेफ़रंस दें या यह बताएं कि इसे LKML पर क्यों सबमिट नहीं किया गया.

पैच को अपस्ट्रीम या android-mainline में स्वीकार किए जाने के बाद, उसे सही एलटीएस-आधारित ACK पर बैकपोर्ट किया जा सकता है. जैसे, Android के खास कोड को ठीक करने वाले पैच के लिए android12-5.4 और android11-5.4. android-mainline पर सबमिट करने से, अपस्ट्रीम रिलीज़ के नए उम्मीदवारों के साथ टेस्टिंग की सुविधा मिलती है. साथ ही, यह भी पक्का होता है कि पैच, LTS पर आधारित अगले ACK में शामिल है. अपवाद में वे मामले शामिल हैं जब किसी अपस्ट्रीम पैच को android12-5.4 में बैकपोर्ट किया जाता है (क्योंकि पैच पहले से ही android-mainline में मौजूद होने की संभावना है).

अपस्ट्रीम पैच

योगदान के दिशा-निर्देशों में बताए गए मुताबिक, ACK कर्नेल के लिए अपस्ट्रीम पैच, इन ग्रुप में आते हैं. ये ग्रुप, स्वीकार किए जाने की संभावना के हिसाब से लगाए गए हैं.

  • UPSTREAM: - अगर 'android-mainline` से चुने गए पैच का इस्तेमाल सही तरीके से किया जा सकता है, तो हो सकता है कि उन्हें ACK में शामिल किया जाए.
  • BACKPORT: - अपस्ट्रीम से मिलने वाले ऐसे पैच भी स्वीकार किए जा सकते हैं जिनमें सही तरीके से चुनिंदा बदलाव नहीं किए गए हैं और जिनमें बदलाव करने की ज़रूरत है. हालांकि, इसके लिए ज़रूरी है कि उनका इस्तेमाल सही तरीके से किया जा रहा हो.
  • FROMGIT: - अगर Linux के मुख्य वर्शन में सबमिट करने के लिए, रखरखाव करने वाले की शाखा से चुने गए पैच की समयसीमा आ रही है, तो उन्हें स्वीकार किया जा सकता है. ये वजहें, कॉन्टेंट और शेड्यूल, दोनों के लिए सही होनी चाहिए.
  • FROMLIST: - LKML को सबमिट किए गए पैच, अगर अब तक मैनेजर की शाखा में स्वीकार नहीं किए गए हैं, तो उन्हें स्वीकार किए जाने की संभावना कम है. हालांकि, अगर पैच को अपस्ट्रीम Linux में शामिल किया जाता है, तो उसे स्वीकार किया जाएगा. हालांकि, हमारा मानना है कि ऐसा नहीं होगा. Android kernel टीम के साथ चर्चा करने के लिए, FROMLIST पैच से जुड़ी कोई समस्या होनी चाहिए.

Android के लिए खास पैच

अगर आपको अपस्ट्रीम में ज़रूरी बदलाव नहीं मिल पा रहे हैं, तो सीधे ACK में आउट-ऑफ़-ट्री पैच सबमिट किए जा सकते हैं. ट्री से बाहर के पैच सबमिट करने के लिए, आपको आईटी में एक समस्या बनानी होगी. इसमें पैच के बारे में जानकारी दी जानी चाहिए. साथ ही, यह भी बताया जाना चाहिए कि पैच को अपस्ट्रीम क्यों सबमिट नहीं किया जा सकता. उदाहरण के लिए, पिछली सूची देखें. हालांकि, कुछ मामलों में कोड को अपस्ट्रीम सबमिट नहीं किया जा सकता. इन मामलों को यहां बताया गया है. साथ ही, Android के लिए बने पैच के लिए, योगदान से जुड़े दिशा-निर्देशों का पालन करना होगा. साथ ही, विषय में ANDROID: प्रीफ़िक्स के साथ टैग करना होगा.

gki_defconfig में बदलाव

gki_defconfig में किए गए सभी CONFIG बदलावों को arm64 और x86, दोनों वर्शन पर लागू करना ज़रूरी है. ऐसा तब तक करना होगा, जब तक कि CONFIG किसी खास आर्किटेक्चर के लिए न हो. CONFIG सेटिंग में बदलाव का अनुरोध करने के लिए, बदलाव के बारे में चर्चा करने के लिए आईटी में कोई समस्या बनाएं. CONFIG ऐसा कोई भी बदलाव अस्वीकार कर दिया जाता है जिससे फ़्रीज़ होने के बाद, Kernel Module Interface (KMI) पर असर पड़ता है. अगर पार्टनर किसी एक कॉन्फ़िगरेशन के लिए, एक-दूसरे से मेल न खाने वाली सेटिंग का अनुरोध करते हैं, तो हम उनसे जुड़ी गड़बड़ियों पर चर्चा करके, विवादों को सुलझाते हैं.

ऐसा कोड जो अपस्ट्रीम में मौजूद नहीं है

पहले से ही Android के लिए बने कोड में किए गए बदलावों को अपस्ट्रीम नहीं भेजा जा सकता. उदाहरण के लिए, भले ही बाइंडर ड्राइवर को अपस्ट्रीम में मैनेज किया जाता है, लेकिन बाइंडर ड्राइवर की प्राथमिकता इनहेरिटेंस सुविधाओं में बदलाव, अपस्ट्रीम में नहीं भेजे जा सकते, क्योंकि ये Android के हिसाब से होती हैं. अपनी गड़बड़ी के बारे में साफ़ तौर पर बताएं और इस बारे में बताएं कि कोड को अपस्ट्रीम क्यों नहीं भेजा जा सकता. अगर हो सके, तो पैच को ऐसे हिस्सों में बांटें जिन्हें अपस्ट्रीम सबमिट किया जा सकता है और Android के हिसाब से ऐसे हिस्सों में बांटें जिन्हें अपस्ट्रीम सबमिट नहीं किया जा सकता. इससे ACK में, ट्री से बाहर के कोड की संख्या कम हो जाएगी.

इस कैटगरी में अन्य बदलावों में, केएमआई रेप्रज़ेंटेशन फ़ाइलों, केएमआई के सिंबल की सूचियों, gki_defconfig, बिल्ड स्क्रिप्ट या कॉन्फ़िगरेशन या ऐसी अन्य स्क्रिप्ट के अपडेट शामिल हैं जो अपस्ट्रीम में मौजूद नहीं हैं.

ट्री से बाहर के मॉड्यूल

अपस्ट्रीम Linux, 'पेड़ के बाहर वाले मॉड्यूल' बनाने की सुविधा का समर्थन नहीं करता. यह एक सही फ़ैसला है, क्योंकि Linux के रखरखाव करने वाले लोग, इन-कर्नल सोर्स या बाइनरी के साथ काम करने की गारंटी नहीं देते. साथ ही, वे ऐसे कोड के साथ काम नहीं करना चाहते जो ट्री में मौजूद नहीं है. हालांकि, GKI, वेंडर मॉड्यूल के लिए एबीआई की गारंटी देता है. इससे यह पक्का होता है कि किसी कर्नेल के काम करने के दौरान, केएमआई इंटरफ़ेस स्थिर रहते हैं. इसलिए, वेंडर के ऐसे मॉड्यूल के साथ काम करने के लिए, बदलावों की एक कैटगरी बनाई गई है जो ACK के लिए स्वीकार किए जाते हैं, लेकिन अपस्ट्रीम के लिए स्वीकार नहीं किए जाते.

उदाहरण के लिए, ऐसे पैच पर विचार करें जो EXPORT_SYMBOL_GPL() मैक्रो जोड़ता है, जहां एक्सपोर्ट का इस्तेमाल करने वाले मॉड्यूल सोर्स ट्री में नहीं होते. EXPORT_SYMBOL_GPL() अपस्ट्रीम के लिए अनुरोध करें और एक्सपोर्ट किए गए नए सिंबल का इस्तेमाल करने वाला मॉड्यूल उपलब्ध कराएं. हालांकि, अगर अपस्ट्रीम मॉड्यूल को सबमिट न किए जाने की कोई मान्य वजह है, तो पैच को ACK में सबमिट किया जा सकता है. आपको यह बताना होगा कि इशू में मॉड्यूल को अपस्ट्रीम क्यों नहीं किया जा सकता. (GPL के तहत न आने वाले वैरिएंट, EXPORT_SYMBOL() का अनुरोध न करें.)

छिपे हुए कॉन्फ़िगरेशन

कुछ इन-ट्री मॉड्यूल, छिपे हुए ऐसे कॉन्फ़िगरेशन को अपने-आप चुनते हैं जिन्हें gki_defconfig में तय नहीं किया जा सकता. उदाहरण के लिए, CONFIG_SND_SOC_SOF=y कॉन्फ़िगर होने पर, CONFIG_SND_SOC_TOPOLOGY अपने-आप चुना जाता है. ट्री के बाहर के मॉड्यूल को बनाने के लिए, GKI में छिपे हुए कॉन्फ़िगरेशन को चालू करने का एक तरीका शामिल है.

छिपे हुए कॉन्फ़िगरेशन को चालू करने के लिए, init/Kconfig.gki में select स्टेटमेंट जोड़ें, ताकि यह gki_defconfig में चालू किए गए CONFIG_GKI_HACKS_TO_FIX कर्नेल कॉन्फ़िगरेशन के आधार पर अपने-आप चुना जाए. इस तरीके का इस्तेमाल सिर्फ़ छिपे हुए कॉन्फ़िगरेशन के लिए करें. अगर कॉन्फ़िगरेशन छिपा नहीं है, तो उसे gki_defconfig में साफ़ तौर पर या डिपेंडेंसी के तौर पर बताना होगा.

लोड किए जा सकने वाले गवर्नर

cpufreq जैसे ऐसे कर्नेल फ़्रेमवर्क के लिए जो लोड किए जा सकने वाले गवर्नर के साथ काम करते हैं, डिफ़ॉल्ट गवर्नर (जैसे, cpufreq का schedutil गवर्नर) को बदला जा सकता है. ऐसे फ़्रेमवर्क (जैसे कि थर्मल फ़्रेमवर्क) के लिए जो लोड किए जा सकने वाले गवर्नर या ड्राइवर की सुविधा नहीं देते, लेकिन वेंडर के हिसाब से लागू करने की ज़रूरत होती है, तो आईटी में समस्या दर्ज करें और Android कर्नेल टीम से सलाह लें.

हम आपके और अपस्ट्रीम मैनेज करने वालों के साथ मिलकर, ज़रूरी मदद उपलब्ध कराएंगे.

वेंडर हुक

पिछली रिलीज़ में, सीधे कोर कर्नेल में वेंडर के हिसाब से बदलाव किए जा सकते थे. GKI 2.0 के साथ ऐसा नहीं किया जा सकता, क्योंकि प्रॉडक्ट के हिसाब से कोड को मॉड्यूल में लागू करना ज़रूरी है. इसे अपस्ट्रीम कोर कर्नेल या ACK में स्वीकार नहीं किया जाएगा. वैल्यू-ऐडेड सुविधाएं चालू करने के लिए पार्टनर, कोर कर्नेल कोड पर कम से कम असर डालते हैं. इसके लिए, जीकेआई वेंडर हुक स्वीकार करता है. इससे मॉड्यूल को कोर कर्नेल कोड से शुरू करने में मदद मिलती है. इसके अलावा, मुख्य डेटा स्ट्रक्चर को वेंडर डेटा फ़ील्ड के साथ जोड़ा जा सकता है. ये फ़ील्ड, इन सुविधाओं को लागू करने के लिए वेंडर के खास डेटा को स्टोर करने के लिए उपलब्ध होते हैं.

वेंडर हुक दो वैरिएंट (सामान्य और पाबंदी वाले) में आते हैं. ये ट्रैसपॉइंट (ट्रैस इवेंट नहीं) पर आधारित होते हैं. वेंडर मॉड्यूल, इनसे अटैच हो सकते हैं. उदाहरण के लिए, टास्क के पूरा होने पर हिसाब-किताब करने के लिए, नया sched_exit() फ़ंक्शन जोड़ने के बजाय, वेंडर do_exit() में एक हुक जोड़ सकते हैं. प्रोसेसिंग के लिए, वेंडर मॉड्यूल उस हुक से जुड़ सकता है. लागू करने के उदाहरण में, वेंडर हुक शामिल हैं.

  • सामान्य वेंडर हुक trace_name नाम वाला ट्रेसपॉइंट फ़ंक्शन बनाने के लिए, DECLARE_HOOK() का इस्तेमाल करते हैं. यहां name ट्रेस का यूनीक आइडेंटिफ़ायर होता है. नियम के मुताबिक, वेंडर हुक के सामान्य नाम android_vh से शुरू होते हैं. इसलिए, sched_exit() हुक का नाम android_vh_sched_exit होगा.
  • शेड्यूलर हुक जैसे मामलों में, पाबंदी वाले वेंडर हुक की ज़रूरत होती है. इन मामलों में, सीपीयू के ऑफ़लाइन होने या nonatomic कॉन्टेक्स्ट की ज़रूरत होने पर भी, अटैच किए गए फ़ंक्शन को कॉल किया जाना चाहिए. पाबंदी वाले वेंडर हुक को अलग नहीं किया जा सकता. इसलिए, पाबंदी वाले हुक से जुड़े मॉड्यूल कभी भी अनलोड नहीं हो सकते. पाबंदी वाले वेंडर हुक के नाम android_rvh से शुरू होते हैं.

वेंडर हुक जोड़ने के लिए, आईटी में समस्या दर्ज करें और पैच सबमिट करें (जैसा कि Android के लिए बने सभी पैच में होता है, उसमें कोई समस्या होनी चाहिए और आपको सही वजह बतानी होगी). वेंडर हुक की सुविधा सिर्फ़ ACK में उपलब्ध है. इसलिए, इन पैच को अपस्ट्रीम Linux में न भेजें.

स्ट्रक्चर में वेंडर फ़ील्ड जोड़ना

ANDROID_VENDOR_DATA() मैक्रो का इस्तेमाल करके android_vendor_data फ़ील्ड जोड़कर, वेंडर डेटा को मुख्य डेटा स्ट्रक्चर से जोड़ा जा सकता है. उदाहरण के लिए, वैल्यू-ऐडेड सुविधाओं के साथ काम करने के लिए, नीचे दिए गए कोड सैंपल में दिखाए गए तरीके के मुताबिक, स्ट्रक्चर में फ़ील्ड जोड़ें.

वेंडर के लिए ज़रूरी फ़ील्ड और OEM के लिए ज़रूरी फ़ील्ड के बीच संभावित विरोध से बचने के लिए, OEM को कभी भी ANDROID_VENDOR_DATA() मैक्रो का इस्तेमाल करके एलान किए गए फ़ील्ड का इस्तेमाल नहीं करना चाहिए. इसके बजाय, OEM को android_oem_data फ़ील्ड का एलान करने के लिए, ANDROID_OEM_DATA() का इस्तेमाल करना होगा.

#include <linux/android_vendor.h>
...
struct important_kernel_data {
  [all the standard fields];
  /* Create vendor data for use by hook implementations. The
   * size of vendor data is based on vendor input. Vendor data
   * can be defined as single u64 fields like the following that
   * declares a single u64 field named "android_vendor_data1" :
   */
  ANDROID_VENDOR_DATA(1);

  /*
   * ...or an array can be declared. The following is equivalent to
   * u64 android_vendor_data2[20]:
   */
  ANDROID_VENDOR_DATA_ARRAY(2, 20);

  /*
   * SoC vendors must not use fields declared for OEMs and
   * OEMs must not use fields declared for SoC vendors.
   */
  ANDROID_OEM_DATA(1);

  /* no further fields */
}

वेंडर हुक तय करना

वेंडर हुक को ट्रेसपॉइंट के तौर पर, कर्नेल कोड में जोड़ें. ऐसा करने के लिए, DECLARE_HOOK() या DECLARE_RESTRICTED_HOOK() का इस्तेमाल करके उनका एलान करें. इसके बाद, उन्हें ट्रेसपॉइंट के तौर पर कोड में जोड़ें. उदाहरण के लिए, मौजूदा do_exit() के कर्नेल फ़ंक्शन में trace_android_vh_sched_exit() जोड़ने के लिए:

#include <trace/hooks/exit.h>
void do_exit(long code)
{
    struct task_struct *tsk = current;
    ...
    trace_android_vh_sched_exit(tsk);
    ...
}

trace_android_vh_sched_exit() फ़ंक्शन शुरू में सिर्फ़ यह जांचता है कि कोई फ़ाइल अटैच है या नहीं. हालांकि, अगर कोई वेंडर मॉड्यूल, register_trace_android_vh_sched_exit() का इस्तेमाल करके हैंडलर रजिस्टर करता है, तो रजिस्टर किए गए फ़ंक्शन को कॉल किया जाता है. हैंडलर को लॉक, आरसीएस की स्थिति, और अन्य चीज़ों के कॉन्टेक्स्ट की जानकारी होनी चाहिए. हुक को include/trace/hooks डायरेक्ट्री में मौजूद हेडर फ़ाइल में तय किया जाना चाहिए.

उदाहरण के लिए, नीचे दिया गया कोड, include/trace/hooks/exit.h फ़ाइल में trace_android_vh_sched_exit() के लिए एक संभावित एलान देता है.

/* SPDX-License-Identifier: GPL-2.0 */
#undef TRACE_SYSTEM
#define TRACE_SYSTEM sched
#define TRACE_INCLUDE_PATH trace/hooks

#if !defined(_TRACE_HOOK_SCHED_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TRACE_HOOK_SCHED_H
#include <trace/hooks/vendor_hooks.h>
/*
 * Following tracepoints are not exported in tracefs and provide a
 * mechanism for vendor modules to hook and extend functionality
 */

struct task_struct;

DECLARE_HOOK(android_vh_sched_exit,
             TP_PROTO(struct task_struct *p),
             TP_ARGS(p));

#endif /* _TRACE_HOOK_SCHED_H */

/* This part must be outside protection */
#include <trace/define_trace.h>

वेंडर हुक के लिए ज़रूरी इंटरफ़ेस को इंस्टैंशिएट करने के लिए, drivers/android/vendor_hooks.c में हुक की जानकारी वाली हेडर फ़ाइल जोड़ें और सिंबल एक्सपोर्ट करें. उदाहरण के लिए, यहां दिया गया कोड, android_vh_sched_exit() हुक का एलान पूरा करता है.

#ifndef __GENKSYMS__
/* struct task_struct */
#include <linux/sched.h>
#endif

#define CREATE_TRACE_POINTS
#include <trace/hooks/vendor_hooks.h>
#include <trace/hooks/exit.h>
/*
 * Export tracepoints that act as a bare tracehook (i.e. have no trace
 * event associated with them) to allow external modules to probe
 * them.
 */
EXPORT_TRACEPOINT_SYMBOL_GPL(android_vh_sched_exit);

ध्यान दें: एबीआई के स्थिर रहने की गारंटी देने के लिए, हुक एलान में इस्तेमाल किए गए डेटा स्ट्रक्चर की पूरी जानकारी देना ज़रूरी है. ऐसा न करने पर, ऑपैक पॉइंटर का रेफ़रंस हटाना या साइज़ वाले कॉन्टेक्स्ट में स्ट्रक्चर का इस्तेमाल करना असुरक्षित है. ऐसे डेटा स्ट्रक्चर की पूरी जानकारी देने वाले include को drivers/android/vendor_hooks.c के #ifndef __GENKSYMS__ सेक्शन में शामिल किया जाना चाहिए. include/trace/hooks में मौजूद हेडर फ़ाइलों में, टाइप की परिभाषाओं के साथ कर्नेल हेडर फ़ाइल शामिल नहीं होनी चाहिए. इससे सीआरसी में होने वाले ऐसे बदलावों से बचा जा सकता है जो केएमआई को तोड़ देते हैं. इसके बजाय, टाइप के बारे में जानकारी दें.

वेंडर हुक से अटैच करना

वेंडर हुक का इस्तेमाल करने के लिए, वेंडर मॉड्यूल को हुक के लिए एक हैंडलर रजिस्टर करना होगा. आम तौर पर, ऐसा मॉड्यूल शुरू करने के दौरान किया जाता है. उदाहरण के लिए, यहां दिया गया कोड, trace_android_vh_sched_exit() के लिए मॉड्यूल foo.ko हैंडलर दिखाता है.

#include <trace/hooks/sched.h>
...
static void foo_sched_exit_handler(void *data, struct task_struct *p)
{
    foo_do_exit_accounting(p);
}
...
static int foo_probe(..)
{
    ...
    rc = register_trace_android_vh_sched_exit(foo_sched_exit_handler, NULL);
    ...
}

हेडर फ़ाइलों से वेंडर हुक का इस्तेमाल करना

हेडर फ़ाइलों से वेंडर हुक का इस्तेमाल करने के लिए, आपको वेंडर हुक हेडर फ़ाइल को अपडेट करना पड़ सकता है, ताकि TRACE_INCLUDE_PATH को अनडिफ़ाइन किया जा सके. इससे, ट्रैक पॉइंट हेडर फ़ाइल न मिलने की जानकारी देने वाली बिल्ड गड़बड़ियों से बचा जा सकता है. उदाहरण के लिए,

In file included from .../common/init/main.c:111:
In file included from .../common/include/trace/events/initcall.h:74:
.../common/include/trace/define_trace.h:95:10: fatal error: 'trace/hooks/initcall.h' file not found
   95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../common/include/trace/define_trace.h:90:32: note: expanded from macro 'TRACE_INCLUDE'
   90 | # define TRACE_INCLUDE(system) __TRACE_INCLUDE(system)
      |                                ^~~~~~~~~~~~~~~~~~~~~~~
.../common/include/trace/define_trace.h:87:34: note: expanded from macro '__TRACE_INCLUDE'
   87 | # define __TRACE_INCLUDE(system) __stringify(TRACE_INCLUDE_PATH/system.h)
      |                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../common/include/linux/stringify.h:10:27: note: expanded from macro '__stringify'
   10 | #define __stringify(x...)       __stringify_1(x)
      |                                 ^~~~~~~~~~~~~~~~
.../common/include/linux/stringify.h:9:29: note: expanded from macro '__stringify_1'
    9 | #define __stringify_1(x...)     #x
      |                                 ^~
<scratch space>:14:1: note: expanded from here
   14 | "trace/hooks/initcall.h"
      | ^~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

इस तरह की बिल्ड गड़बड़ी को ठीक करने के लिए, शामिल की जा रही वेंडर हुक हेडर फ़ाइल में, ठीक करने का यही तरीका अपनाएं. ज़्यादा जानकारी के लिए, https://r.android.com/3066703 पर जाएं.

diff --git a/include/trace/hooks/mm.h b/include/trace/hooks/mm.h
index bc6de7e53d66..039926f7701d 100644
--- a/include/trace/hooks/mm.h
+++ b/include/trace/hooks/mm.h
@@ -2,7 +2,10 @@
 #undef TRACE_SYSTEM
 #define TRACE_SYSTEM mm

+#ifdef CREATE_TRACE_POINTS
 #define TRACE_INCLUDE_PATH trace/hooks
+#define UNDEF_TRACE_INCLUDE_PATH
+#endif

UNDEF_TRACE_INCLUDE_PATH तय करने पर, include/trace/define_trace.h को ट्रेस पॉइंट बनाने के बाद, TRACE_INCLUDE_PATH को अनफ़ाइन करने के लिए कहा जाता है.

कर्नेल के लिए मुख्य सुविधाएं

अगर ऊपर बताई गई कोई भी तकनीक, किसी मॉड्यूल की सुविधा को लागू करने में आपकी मदद नहीं करती है, तो आपको मुख्य कोर में Android के हिसाब से बदलाव के तौर पर सुविधा जोड़नी होगी. बातचीत शुरू करने के लिए, समस्या ट्रैकर (आईटी) में कोई समस्या बनाएं.

यूज़र ऐप्लिकेशन प्रोग्रामिंग इंटरफ़ेस (यूएपीआई)

  • UAPI हेडर फ़ाइलें. UAPI हेडर फ़ाइलों में बदलाव, अपस्ट्रीम में होने चाहिए. ऐसा तब तक करना होगा, जब तक कि बदलाव Android के इंटरफ़ेस के लिए न हों. वेंडर मॉड्यूल और वेंडर यूज़रस्पेस कोड के बीच इंटरफ़ेस तय करने के लिए, वेंडर के हिसाब से हेडर फ़ाइलों का इस्तेमाल करें.
  • sysfs नोड. GKI कर्नेल में नए sysfs नोड न जोड़ें. ये सिर्फ़ वेंडर मॉड्यूल में जोड़े जा सकते हैं. SoC और डिवाइस के हिसाब से काम न करने वाली लाइब्रेरी और Android फ़्रेमवर्क में शामिल Java कोड में इस्तेमाल किए जाने वाले sysfs नोड को सिर्फ़ काम करने वाले तरीकों से बदला जा सकता है. अगर ये Android के हिसाब से काम करने वाले sysfs नोड नहीं हैं, तो उन्हें अपस्ट्रीम में बदलना होगा. आपके पास, वेंडर के हिसाब से sysfs नोड बनाने का विकल्प होता है. इनका इस्तेमाल, वेंडर के यूज़रस्पेस में किया जाता है. डिफ़ॉल्ट रूप से, SELinux का इस्तेमाल करके, userspace से sysfs नोड को ऐक्सेस करने की अनुमति नहीं दी जाती. यह वेंडर पर निर्भर करता है कि वह SELinux लेबल कैसे जोड़ेगा, ताकि अनुमति वाले वेंडर सॉफ़्टवेयर को ऐक्सेस दिया जा सके.
  • DebugFS नोड. वेंडर मॉड्यूल, सिर्फ़ डीबग करने के लिए debugfs में नोड तय कर सकते हैं. ऐसा इसलिए, क्योंकि डिवाइस के सामान्य कामकाज के दौरान debugfs माउंट नहीं होता.