कर्नेल मॉड्यूल के लिए सहायता

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

मॉड्यूल की जगह

रैम डिस्क, पहले चरण के init, और A/B और वर्चुअल A/B डिवाइसों पर रिकवरी/फ़ास्टबूट इमेज. यह है initramfs दो cpio संग्रहों से मिलकर बना है जो इनके साथ जुड़े होते हैं बूटलोडर पर क्लिक करें. पहला cpio संग्रह, जिसे वेंडर ramdisk के तौर पर सेव किया गया है में ये कॉम्पोनेंट शामिल होते हैं:

• पहले स्टेज के init वेंडर कर्नेल मॉड्यूल में उपलब्ध है /lib/modules/.
• /lib/modules/ में मौजूद modprobe कॉन्फ़िगरेशन फ़ाइलें: modules.dep, modules.softdep, modules.alias, modules.options.
• modules.load फ़ाइल, जो बताती है कि कौनसे मॉड्यूल लोड होने हैं पहली स्टेज की शुरुआत में और किस क्रम में, /lib/modules/.
• A/B और वर्चुअल A/B डिवाइसों के लिए वेंडर रिकवरी-कर्नेल मॉड्यूल /lib/modules/ अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
• modules.load.recovery जो लोड होने वाले मॉड्यूल की जानकारी देता है और A/B और वर्चुअल A/B डिवाइसों के लिए, /lib/modules.

दूसरा cpio संग्रह, जिसकी आपूर्ति GKI के साथ की जाती है बूट.img की रैम डिस्क के रूप में किया जाता है और पहले, first_stage_init और उन लाइब्रेरी को शामिल करता है जिन पर यह निर्भर करता है.

पहले चरण में मॉड्यूल लोड हो रहा है

पहले स्टेज init की शुरुआत, मॉडप्रोब कॉन्फ़िगरेशन को पढ़ने से होती है रैम डिस्क पर /lib/modules/ से मिली फ़ाइलें. इसके बाद, यह सूची को पढ़ता है मॉड्यूल का मान /lib/modules/modules.load में बताया गया है (या अगर मामले में है, तो /lib/modules/modules.load.recovery) और बार-बार इनमें से हर मॉड्यूल को, नीचे दिए गए कॉन्फ़िगरेशन के हिसाब से लोड करते हैं पहले से लोड की गई फ़ाइलें. अनुरोध किया गया आदेश से बदलकर हो सकता है आपकी ज़रूरतें पूरी होती हैं.

बच्चों के लिए सहायता पाने की शुरुआत करें

वेंडर ramdisk cpio में कॉपी किए जाने वाले कर्नेल मॉड्यूल को तय करने के लिए, सूची बनाएं BOARD_VENDOR_RAMDISK_KERNEL_MODULES में उन्हें देखा. बिल्ड रन करता है depmod और नतीजे के तौर पर मिले मॉडप्रोब कॉन्फ़िगरेशन को दिखाता है फ़ाइलें वेंडर ramdisk cpio में हैं.

बिल्ड एक modules.load फ़ाइल भी बनाता है और उसे यहां सेव करता है वेंडर ramdisk cpio. डिफ़ॉल्ट रूप से इसमें BOARD_VENDOR_RAMDISK_KERNEL_MODULES. इनकी सामग्री को ओवरराइड करने के लिए वह फ़ाइल, BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD का इस्तेमाल करें, जैसा कि दिखाया गया है इस उदाहरण में:

BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD := \
    device/vendor/mydevice-kernel/first.ko \
    device/vendor/mydevice-kernel/second.ko \
    device/vendor/mydevice-kernel/third.ko

बिल्ड सपोर्ट, फ़ुल Android

Android 10 और उससे पहले के वर्शन वाली रिलीज़ की तरह ही, कर्नेल मॉड्यूल की सूची BOARD_VENDOR_KERNEL_MODULES को Android प्लैटफ़ॉर्म पर कॉपी किया जाता है /vendor/lib/modules पर बनाया गया. कॉन्टेंट बनाने प्लैटफ़ॉर्म बिल्ड इन मॉड्यूल पर depmod चलता है और depmod आउटपुट फ़ाइलों को वेंडर पार्टीशन में उसी रूप में रखा गया स्थान. /vendor से कर्नेल मॉड्यूल लोड करने का तरीका Android के पिछले रिलीज़ वाले मॉडल में भी वैसा ही बदलाव होगा. यह आपका फ़ैसला है ये मॉड्यूल कैसे और कब लोड करने हैं, हालांकि आम तौर पर इनका इस्तेमाल करके ऐसा किया जाता है init.rc स्क्रिप्ट.

वाइल्डकार्ड और इंटिग्रेट किए गए कर्नेल बिल्ड

अपने डिवाइस के कर्नेल बिल्ड को Android प्लैटफ़ॉर्म बिल्ड के साथ जोड़ने वाले वेंडर ऊपर दिए गए BOARD मैक्रो का उपयोग करने पर भी किसी समस्या का सामना करना पड़ सकता है डिवाइस पर कॉपी किए जाने वाले कर्नेल मॉड्यूल तय करें. अगर वेंडर पेमेंट से बचना चाहता है, तो डिवाइस के प्लैटफ़ॉर्म की बिल्ड फ़ाइलों में कर्नेल मॉड्यूल की सूची दिखाते हैं, तो वे वाइल्डकार्ड का इस्तेमाल कर सकते हैं ($(wildcard device/vendor/mydevice/*.ko). ध्यान दें कि वाइल्डकार्ड एक इंटिग्रेट किए गए कर्नेल बिल्ड के मामले में काम करते हैं, क्योंकि जबमेक शुरू होता है और मैक्रो को मेकफ़ाइल में बड़ा किया जाता है और कर्नेल मॉड्यूल नहीं बनाए जाते हैं. इसलिए, मैक्रो खाली हैं.

इस समस्या से बचने के लिए, वेंडर अपने कर्नेल बिल्ड के ज़रिए एक ZIP फ़ाइल बना सकता है संग्रह जिसमें कर्नेल मॉड्यूल मौजूद हैं और हर सेगमेंट में कॉपी किए जा सकते हैं. उस ज़िप संग्रह का पाथ BOARD_*_KERNEL_MODULES_ARCHIVE में सेट करें जहां * विभाजन का नाम है (जैसे कि BOARD_VENDOR_KERNEL_MODULES_ARCHIVE). Android प्लैटफ़ॉर्म का बिल्ड इस ज़िप संग्रह को सही जगह पर ले जाता है और depmod चलाता है देखें.

कर्नेल मॉड्यूल ज़िप संग्रह में एक बनाने का नियम होना चाहिए, जो प्लैटफ़ॉर्म को पक्का करता हो बिल्ड ज़रूरत पड़ने पर संग्रह जनरेट कर सकता है.

रिकवरी

पिछली Android रिलीज़ में, रिकवरी के लिए ज़रूरी कर्नेल मॉड्यूल ये थे BOARD_RECOVERY_KERNEL_MODULES में बताया गया है. Android 12 में, रिकवरी के लिए ज़रूरी कर्नेल मॉड्यूल अब भी हैं इस मैक्रो का उपयोग करके दर्ज किया गया है. हालांकि, रिकवरी कर्नेल मॉड्यूल की कॉपी विक्रेता ramdisk cpio के बजाय, सामान्य ramdisk cpio. डिफ़ॉल्ट रूप से सभी BOARD_RECOVERY_KERNEL_MODULES में दिए गए कर्नेल मॉड्यूल लोड हैं शुरुआती चरण init के दौरान. अगर आपको इनका सिर्फ़ एक सबसेट चाहिए, तो मॉड्यूल लोड होने के लिए, BOARD_RECOVERY_KERNEL_MODULES_LOAD.

इसी विषय से जुड़े अन्य दस्तावेज़

वेंडर बूट पार्टीशन (जिसमें वेंडर होता है) को बनाने के बारे में जानने के लिए इस पेज पर बताई गई ramdisk है), देखें बूट विभाजन.