وحدات kernel قابلة للتحميل

كجزء من متطلبات النواة للوحدات التي تم تقديمها في الإصدار Android 8.0، تم إدخال جميع يجب أن تتوافق نواة النظام على الرقاقة (SoC) مع وحدات النواة القابلة للتحميل.

خيارات إعداد النواة

لدعم وحدات النواة القابلة للتحميل، android-base.config في جميع النواة الشائعة يشمل خيارات تهيئة kernel التالية (أو ما يعادلها من إصدار kernel):

CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y

يجب تفعيل هذه الخيارات على جميع نواة الجهاز. ينبغي أيضًا أن تحدد وحدات النواة دعم فك التحميل وإعادة التحميل كلما أمكن ذلك.

ملاحظة: إنّ "CONFIG_MODULE_SRCVERSION_ALL" اختياري ولم يتم اختباره. ضد.

توقيع الوحدة

لا تتوفّر إمكانية توقيع الوحدات لوحدات مورِّد GKI. على الأجهزة المطلوبة يدعم التشغيل المتحقَّق منه، يتطلب Android وجود وحدات kernel في الأقسام التي تم فيها تفعيل dm-verity. لن تحتاج بالتالي إلى توقيع الشخص وحدتها. طرَح نظام Android 13 مفهوم وحدات GKI. تستخدم وحدات GKI وقت إنشاء النواة. توقيع البنية الأساسية للتمييز بين GKI والوحدات الأخرى في وقت التشغيل. يُسمح بتحميل الوحدات غير الموقَّعة ما دامت تستخدم فقط الرموز التي تظهر في القائمة المسموح بها. أو يتم توفيرها من قبل وحدات أخرى غير موقعة. لتسهيل توقيع وحدات GKI أثناء إنشاء GKI باستخدام مفتاحَي وقت إنشاء kernel، تم تفعيل CONFIG_MODULE_SIG_ALL=y في إعدادات نواة GKI. لتجنُّب توقيع الوحدات التي لا تتبع GKI أثناء إصدارات نواة الجهاز، عليك إضافة # CONFIG_MODULE_SIG_ALL is not set كجزء من إعدادات النواة الأجزاء.

مواقع الملفات

لا يفرض الإصدار Android 7.x والإصدارات الأقدم أي متطلبات على وحدات النواة (وتتضمّن يتوافق مع insmod وrmmod) وAndroid 8.x ننصح بشدة باستخدام وحدات النواة (kernel) في المنظومة المتكاملة. ما يلي: الدعم الملحق المحتمل الخاص باللوحة المطلوب عبر ثلاث أوضاع تشغيل Android.

وضع التشغيل	مساحة التخزين	الشاشة	لوحة المفاتيح	البطارية	PMIC	الشاشة التي تعمل باللمس	NFC، Wi-Fi، البلوتوث	أجهزة الاستشعار	الكاميرا
استعادة الكرة
شاحن
Android

بالإضافة إلى توفر وضع التشغيل في Android، يمكن أيضًا تخزين وحدات النواة مصنفة حسب من يملكها (مورّد المنظومة على الرقاقة (SoC) أو ODM). إذا كانت وحدات النواة قيد الاستخدام، إلا أن متطلبات وضعها في نظام الملفات هي التالي:

• يجب أن يكون لدى جميع النواة دعم مدمج للتشغيل والتثبيت. الأقسام.
• يجب تحميل وحدات النواة من قسم للقراءة فقط.
• بالنسبة للأجهزة التي تتطلب التحقق من التمهيد (بدء تشغيل)، يجب إجراء وحدات النواة (النواة) تم تحميلها من الأقسام التي تم التحقق منها.
• يجب ألا تكون وحدات النواة موجودة في /system.
• يجب تحميل وحدات GKI المطلوبة للجهاز من: /system/lib/modules وهو رابط رمزي إلى /system_dlkm/lib/modules
• وحدات النواة (Kernel) من مورِّد المنظومة على الرقاقة (SoC) المطلوبة لنظام التشغيل Android أو يجب ضبط أوضاع الشاحن في /vendor/lib/modules.
• في حال توفُّر قسم ODM، تكون وحدات النواة من ODM المطلوبة. للوضعَين الكاملَين Android أو الشاحن في /odm/lib/modules وبخلاف ذلك، يجب أن تكون هذه الوحدات في /vendor/lib/modules
• وحدات النواة (Kernel) المطلوبة من أجل عملية الاسترداد من مورِّد المنظومة على الرقاقة (SoC) وبروتوكول ODM. يمكن أن يكون وضع التشغيل في ramfs الاسترداد على /lib/modules
• يلزم وجود وحدات النواة (النواة) في كل من وضع الاسترداد ونظام التشغيل Android الكامل أو يجب أن يكون وضعا الشاحن موجودًا في كل من rootfs واسترداد إما بالقسم /vendor أو /odm (على النحو الموصوف) أعلاه).
• يجب ألا تعتمد وحدات النواة المستخدَمة في وضع الاسترداد على الوحدات المتوفّرة فقط في /vendor أو /odm، حيث لا تكون هذه الأقسام في وضع الاسترداد.
• يجب ألا تعتمد وحدات النواة لمورِّد المنظومة على الإنترنت على وحدات النواة (ODM).

في الإصدار 7.x من نظام التشغيل Android والإصدارات الأقدم، /vendor و/odm لا يتم تثبيت الأقسام مبكرًا. في الإصدار 8.x من نظام التشغيل Android والإصدارات الأحدث، لتسهيل تحميل الوحدات من خلال هذه الأقسام، قد تم توفير شروط تم تصميمهما لتثبيت الأقسام في وقت مبكر لكليهما الأجهزة غير A/B وA/B: هذا أيضًا يضمن تثبيت الأقسام في وضعَي Android والشاحن.

دعم نظام إصدار Android

في BoardConfig.mk، يحدِّد إصدار Android متغيّر BOARD_VENDOR_KERNEL_MODULES يوفّر قائمة كاملة من وحدات النواة المخصصة لصورة البائع. الوحدات المدرجة في يتم نسخ هذا المتغير إلى صورة البائع على /lib/modules/، وبعد تثبيتها في Android، ستظهر في /vendor/lib/modules (وفقًا للمتطلبات أعلاه). مثال على ضبط وحدات النواة الخاصة بالمورّد:

vendor_lkm_dir := device/$(vendor)/lkm-4.x
BOARD_VENDOR_KERNEL_MODULES := \
  $(vendor_lkm_dir)/vendor_module_a.ko \
  $(vendor_lkm_dir)/vendor_module_b.ko \
  $(vendor_lkm_dir)/vendor_module_c.ko

في هذا المثال، يتم ربط مستودع تم إنشاؤه مسبقًا لوحدة نواة البائع في إصدار Android في الموقع المذكور أعلاه.

قد تحتوي صورة الاسترداد على مجموعة فرعية من وحدات المورد. نظام التشغيل Android الإصدار يحدد المتغير BOARD_RECOVERY_KERNEL_MODULES هذه الوحدات. مثال:

vendor_lkm_dir := device/$(vendor)/lkm-4.x
BOARD_RECOVERY_KERNEL_MODULES := \
  $(vendor_lkm_dir)/vendor_module_a.ko \
  $(vendor_lkm_dir)/vendor_module_b.ko

يركّز إصدار Android على تشغيل depmod لإنشاء الملفات المطلوبة modules.dep في /vendor/lib/modules و/lib/modules (recovery ramfs).

تحميل الوحدة وإصدار نُسخة منها

تحميل كل وحدات النواة في بطاقة واحدة من "init.rc*" من خلال الاستدعاء modprobe -a وهذا يتجنب عبء الإعداد المتكرر بيئة وقت التشغيل C لبرنامج ثنائي modprobe. تشير رسالة الأشكال البيانية يمكن تعديل حدث early-init لاستدعاء modprobe:

on early-init
    exec u:r:vendor_modprobe:s0 -- /vendor/bin/modprobe -a -d \
        /vendor/lib/modules module_a module_b module_c ...

عادة، يجب تجميع وحدة النواة باستخدام النواة التي تكون للاستخدام مع (وإلا ترفض النواة تحميل الوحدة). يوفّر CONFIG_MODVERSIONS حلاً بديلاً من خلال رصد الأعطال. في الواجهة الثنائية للتطبيق (ABI). تحسب هذه الميزة دورة فحص التكرار (CRC) للنموذج الأوّلي لكل رمز تم تصديره في kernel ويخزن القيم كجزء من النواة؛ للرموز التي يستخدمها بالنواة، يتم تخزين القيم أيضًا في وحدة الكيرنل (النواة). عندما تحميل الوحدة النمطية، تتم مقارنة قيم الرموز التي تستخدمها الوحدة مع تلك الموجودة في النواة. إذا تطابقت القيم، يتم تحميل الوحدة؛ وإلا فشل التحميل.

ملاحظة: للحصول على مساعدة في مقارنة تغييرات واجهة التطبيق الثنائية (ABI) النواة التي تؤثر في وتتبعها وتخفيفها التوافق مع وحدات النواة، يُرجى الرجوع إلى البرامج النصية والأدوات المساعدة في الأدوات المساعدة لمراقبة واجهة التطبيق الثنائية (ABI).

لتمكين تحديث صورة النواة بشكل منفصل عن صورة المورد، تفعيل CONFIG_MODVERSIONS. ويؤدي إجراء ذلك إلى السماح بإجراء تعديلات بسيطة على النواة (مثل إصلاح الأخطاء من قناة الدعم الطويل الأمد (LTS) مع الحفاظ على التوافق مع وحدات النواة (kernel) الحالية في صورة البائع. ومع ذلك، لا يعالج CONFIG_MODVERSIONS أعطال واجهة التطبيق الثنائية (ABI) بمفرده. إذا كانت النموذج الأولي لرمز تم تصديره في تغييرات النواة، إما بسبب تعديل المصدر أو بسبب تغير تكوين النواة، فإن هذا يقطع التوافق مع وحدات النواة التي تستخدم هذا الرمز. في مثل هذه الحالات، يجب إعادة تجميع وحدة النواة.

على سبيل المثال، إنّ بنية task_struct في النواة (النواة) هي include/linux/sched.h) يحتوي على العديد من الحقول بشكل مشروط. اعتمادًا على تهيئة النواة. sched_info ولا يتوفّر هذا الحقل إلا إذا تم تفعيل CONFIG_SCHED_INFO (والتي تحدث عند CONFIG_SCHEDSTATS أو تم تفعيل CONFIG_TASK_DELAY_ACCT). إذا تم ضبط حالة تغيُّر الخيارات، تنسيق بنية task_struct أي تغييرات وأي واجهات تم تصديرها من النواة kernel التي تستخدم تم تعديل task_struct (على سبيل المثال، set_cpus_allowed_ptr في kernel/sched/core.c). التوافق مع وحدات النواة التي تم تجميعها في وقت سابق والتي تستخدم هذه تتعطل الواجهات، مما يتطلب إعادة تصميم تلك الوحدات باستخدام النواة الجديدة التكوين.

لمزيد من التفاصيل حول CONFIG_MODVERSIONS، يُرجى الرجوع إلى التوثيق في شجرة النواة في Documentation/kbuild/modules.rst