कर्नेल मॉड्यूल से जुड़ी सहायता

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

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

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

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

दूसरा cpio संग्रह, GKI के साथ boot.img के ramdisk के तौर पर दिया जाता है. इसे पहले cpio संग्रह के ऊपर लागू किया जाता है. इसमें first_stage_init और वे लाइब्रेरी शामिल होती हैं जिन पर यह निर्भर करता है.

मॉड्यूल, पहले चरण के शुरू होने पर लोड हो रहा है

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

सहायता उपलब्ध है, पहले चरण की शुरुआत

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

बिल्ड, 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 के साथ पूरी तरह से काम करता है

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

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

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

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

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

रिकवरी

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

इससे जुड़ा दस्तावेज़

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