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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

रैमडिस्क, पहले चरण के init, और A/B और वर्चुअल A/B डिवाइसों पर रिकवरी/fastbootd इमेज के लिए फ़ाइल सिस्टम है. यह एक ऐसा 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) में बताए गए मॉड्यूल की सूची को पढ़ता है और उन सभी मॉड्यूल को क्रम से लोड करने की कोशिश करता है. यह कोशिश, पहले लोड की गई फ़ाइलों में बताए गए कॉन्फ़िगरेशन के हिसाब से की जाती है. हार्ड या सॉफ़्ट डिपेंडेंसी को पूरा करने के लिए, अनुरोध किए गए ऑर्डर में बदलाव किया जा सकता है.

Build support, first-stage init

वेंडर के 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 में उस zip संग्रह का पाथ सेट करें, जहां *, partition का नाम है (जैसे, BOARD_VENDOR_KERNEL_MODULES_ARCHIVE). Android प्लैटफ़ॉर्म का बिल्ड, इस zip संग्रह को सही जगह पर निकालता है और मॉड्यूल पर depmod को चलाता है.

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

रिकवरी

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

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

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