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

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

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

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

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

दूसरा सीपीआईओ संग्रह, जिसे बूट.आईएमजी के रैमडिस्क के रूप में जीकेआई के साथ आपूर्ति की जाती है और पहले के शीर्ष पर लागू किया जाता है, इसमें first_stage_init और लाइब्रेरीज़ शामिल हैं जिन पर यह निर्भर करता है।

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

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

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

विक्रेता रैमडिस्क सीपीआईओ में कॉपी किए जाने वाले कर्नेल मॉड्यूल को निर्दिष्ट करने के लिए, उन्हें 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 से कर्नेल मॉड्यूल लोड करने का तंत्र वही रहता है जो एंड्रॉइड के पिछले रिलीज के लिए था। यह आपका निर्णय है कि इन मॉड्यूल को कैसे और कब लोड करना है, हालांकि आम तौर पर यह init.rc स्क्रिप्ट का उपयोग करके किया जाता है।

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

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

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

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

वसूली

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

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

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