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

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

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

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

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

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

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

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

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

वेंडर के ramdisk cpio में कॉपी किए जाने वाले कर्नेल मॉड्यूल तय करने के लिए, BOARD_VENDOR_RAMDISK_KERNEL_MODULES में उनकी सूची बनाएं. बिल्ड इन मॉड्यूल पर depmod चलाया जाता है और इससे मिलने वाली modprobe कॉन्फ़िगरेशन फ़ाइलों को वेंडर रैमडिस्क 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) का इस्तेमाल कर सकता है. ध्यान दें कि इंटिग्रेट किए गए कर्नेल बिल्ड के मामले में वाइल्डकार्ड काम नहीं करता. ऐसा इसलिए होता है, क्योंकि जब make को कॉल किया जाता है और makefile में मैक्रो को बड़ा किया जाता है, तो कर्नेल मॉड्यूल बिल्ट नहीं होते. इसलिए, मैक्रो खाली होते हैं.

इस समस्या को हल करने के लिए, वेंडर अपने कर्नेल बिल्ड में एक ज़िप संग्रह बना सकता है. इसमें, हर पार्टीशन पर कॉपी किए जाने वाले कर्नेल मॉड्यूल शामिल होते हैं. उस ज़िप संग्रह का पाथ 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 में उस सबसेट के कॉन्टेंट की जानकारी दें.

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