कर्नेल मॉड्यूल समर्थन

एक सामान्य कर्नेल छवि (GKI) में विभाजन को माउंट करने के लिए डिवाइस को सक्षम करने के लिए आवश्यक ड्राइवर समर्थन नहीं हो सकता है। विभाजन को माउंट करने और बूटिंग जारी रखने के लिए एक उपकरण को सक्षम करने के लिए, प्रथम-चरण init को रैमडिस्क पर मौजूद कर्नेल मॉड्यूल को लोड करने के लिए बढ़ाया जाता है। रैमडिस्क को जेनेरिक और वेंडर रैमडिस्क में विभाजित किया गया है। विक्रेता कर्नेल मॉड्यूल विक्रेता रैमडिस्क में संग्रहीत होते हैं। जिस क्रम में कर्नेल मॉड्यूल लोड होते हैं वह विन्यास योग्य होता है।

मॉड्यूल स्थान

रैमडिस्क प्रथम-चरण init, और ए/बी और वर्चुअल ए/बी डिवाइस पर रिकवरी/फास्टबूट छवि के लिए है। यह दो cpio अभिलेखागार से बना एक initramfs है जो बूटलोडर द्वारा संयोजित हो जाता है। पहले cpio संग्रह, जो विक्रेता-बूट विभाजन में विक्रेता रैमडिस्क के रूप में संग्रहीत है, में ये घटक शामिल हैं:

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

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

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

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

समर्थन बनाएँ, प्रथम चरण init

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

बिल्ड एक modules.load फ़ाइल भी बनाता है और इसे विक्रेता रैमडिस्क सीपीओ में संग्रहीत करता है। डिफ़ॉल्ट रूप से इसमें 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

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

वाइल्डकार्ड और एकीकृत कर्नेल बनाता है

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

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

कर्नेल मॉड्यूल ज़िप संग्रह में एक मेक नियम होना चाहिए जो सुनिश्चित करता है कि प्लेटफ़ॉर्म बिल्ड आवश्यकता पड़ने पर संग्रह उत्पन्न कर सकता है।

वसूली

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

संबंधित दस्तावेज

विक्रेता बूट विभाजन बनाने के बारे में जानने के लिए (जिसमें इस पृष्ठ पर उल्लिखित विक्रेता रैमडिस्क शामिल है), बूट विभाजन देखें।