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

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

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

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

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

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

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

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

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

पैच की ज़रूरी शर्तें

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

ACK पैच

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

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

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

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

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

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

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

Android के लिए खास तौर पर बनाए गए पैच

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

gki_defconfig में बदलाव

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

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

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

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

पेड़-पौधों से उगने वाले मॉड्यूल

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

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

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

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

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

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

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

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

वेंडर हुक

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

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

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

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

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

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

वेंडर और फ़ील्ड के लिए ज़रूरी फ़ील्ड के बीच संभावित टकराव से बचने के लिए OEM को ज़रूरत हो, तो 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(). इसके बाद, उन्हें इस खाते से कोड में जोड़ें: ट्रेसपॉइंट बदल जाता है. उदाहरण के लिए, trace_android_vh_sched_exit() को मौजूदा do_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);

ध्यान दें: हुक डिक्लेरेशन में इस्तेमाल किए जाने वाले डेटा स्ट्रक्चर को पूरी तरह से परिभाषित किया गया है, ताकि एबीआई की स्थिरता की गारंटी दी जा सके. अगर ऐसा नहीं किया जाता है, तो ओपेक पॉइंटर को रेफ़रंस न करें या साइज़ वाले कॉन्टेक्स्ट में स्ट्रक्चर का इस्तेमाल करें. शामिल करें ऐसे डेटा स्ट्रक्चर की पूरी परिभाषा बताता है जो 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 नोड. जीकेआई कर्नेल में नए sysfs नोड न जोड़ें (इस तरह के जोड़ सिर्फ़ वेंडर मॉड्यूल में मान्य हैं). SoC- और डिवाइस-एग्नोस्टिक लाइब्रेरी और Java कोड, जिनमें Android फ़्रेमवर्क शामिल होता है को सिर्फ़ साथ काम करने वाले तरीकों से बदला जा सकता है. साथ ही, अपस्ट्रीम को भी बदलना होगा, अगर ये Android के लिए खास तौर पर कॉन्फ़िगर किए गए sysfs नोड नहीं हैं. आप बना सकते हैं वेंडर यूज़रस्पेस से इस्तेमाल किए जाने वाले वेंडर के लिए खास sysfs नोड. डिफ़ॉल्ट रूप से, SELinux का इस्तेमाल करके यूज़रस्पेस से sysfs नोड तक ऐक्सेस की अनुमति नहीं है. यह तय करना कि वेंडर को सही SELinux लेबल जोड़ने की अनुमति देनी होगी, ताकि वेंडर सॉफ़्टवेयर.
• डीबगएफ़एस नोड. वेंडर मॉड्यूल, debugfs में नोड को तय कर सकते हैं सिर्फ़ डीबग करने का तरीका (क्योंकि debugfs को डिवाइस).