كيف

كيفية تحديث Android Kernel إلى أحدث إصدارات Linux Linux

لقد غطينا أدلة على نواة أندرويد ، مثل "كيفية بناء نواة مخصصة" و "أفضل نوى مخصصة لأندرويد" ، لكننا اليوم سوف نعرض لك كيفية صعود نواةك ضد مستقر لينكس الأخير.

يرجى العلم أن هذه مواد متقدمة - إذا لم تقم مطلقًا بتجميع نواة من قبل ، فيجب عليك اتباع دليل "كيفية بناء نواة مخصصة" أعلاه ، وسيشمل هذا الدليل التزامات اختيار الكرز ودمجها من أحدث إصدارات Linux- نواة مستقرة مع نواة أندرويد قبل تجميعها.

إن رفع مستوى kernel على نظام Android إلى أحدث مستقر لنظام Linux له الكثير من الفوائد الإيجابية ، مثل تحديثه بأحدث التزامات الأمان والإصلاحات التي تحدث - سنشرح بعض إيجابيات وسلبيات لاحقًا في هذا الدليل.

ما هو نواة لينكس المستقرة؟

Linux-مستقرة كما يوحي الاسم هو الذراع المستقر لـ kernel Linux. يُعرف الذراع الآخر باسم "الخط الرئيسي" ، وهو الفرع الرئيسي . يحدث كل تطوير Linux kernel في الخط الرئيسي ، ويتبع هذه العملية عمومًا:

سيأخذ Linus Torvalds مجموعة من التصحيحات من المشرفين عليه لمدة أسبوعين.
بعد هذا الأسبوعين ، أطلق نواة RC1 (مثل 4.14-rc1).
لكل أسبوع لمدة 6-8 أسابيع ، سيصدر نواة أخرى لاتفاقية روتردام (مثل 4.14-rc2 ، 4.14-rc3 ، إلخ) ، تحتوي على إصلاحات الأخطاء والانحدار فقط.
بمجرد اعتبارها مستقرة ، سيتم إصدارها كقطعة قماشية للتحميل على org (على سبيل المثال 4.14).

ما هي حبات LTS؟

كل عام ، سيقوم Greg باختيار نواة واحدة والاحتفاظ بها لمدة عامين (LTS) أو ست سنوات (LTS ممتدة). تم تصميمها بحيث تحتوي على منتجات تحتاج إلى الاستقرار (مثل هواتف Android أو أجهزة IOT الأخرى). هذه العملية هي نفسها كما هو مذكور أعلاه ، إنها تحدث فقط لفترة أطول. يوجد حاليًا ستة نواة LTS (والتي يمكن عرضها دائمًا على صفحة إصدارات kernel.org):

4.14 (LTS) ، تحتفظ بها جريج كرواه هارتمان
4.9 (LTS) ، تحتفظ بها جريج كروا هارتمان
4.4 (eLTS) ، تحت إدارة جريج كرواه هارتمان
4.1 (LTS) ، تحتفظ بها ساشا ليفين
3.16 (LTS) ، تحت إدارة بن هتشينغز
3.2 (LTS) ، تحت إدارة بن هتشينغز

ما فوائد رفع مستوى kernel لنظام Android إلى Linux Stable؟

عندما يتم الكشف عن / إصلاح الثغرات المهمة ، فإن النوى المستقرة هي أول من يحصل عليها. وبالتالي ، ستكون نواة Android أكثر أمانًا ضد الهجمات والعيوب الأمنية والأخطاء بشكل عام.

يتضمن Linux Linux إصلاحات للعديد من برامج التشغيل التي لا يستخدمها جهازي Android ، أليس هذا غير ضروري في الغالب؟

نعم و لا ، اعتمادا على كيفية تعريفك "في الغالب". قد يشتمل Linux kernel على الكثير من التعليمات البرمجية غير المستخدمة في نظام Android ، لكن هذا لا يضمن عدم وجود تعارضات من هذه الملفات عند دمج الإصدارات الجديدة! افهم أن لا أحد يصنع كل جزء من النواة ، ولا حتى توزيعات Linux الأكثر شيوعًا مثل Ubuntu أو Mint. هذا لا يعني أنك لا يجب أن تأخذ هذه الإصلاحات لأن هناك إصلاحات لبرامج التشغيل التي تقوم بتشغيلها. خذ arm / arm64 و ext4 على سبيل المثال ، وهما أكثر أنظمة العمارة وملفات Android شيوعًا على التوالي. في 4.4 ، من 4.4.78 (إصدار أحدث علامة Oreo CAF) إلى 4.4.121 (أحدث علامة upstream) ، هذه هي الأرقام التالية لالتزامات تلك الأنظمة:

 ~ / kernels / linux-stable (master) $ git log --format =٪ h v4.4.78..v4.4.121 | wc -l2285 ~ / kernels / linux-stable (master) $ git log --format =٪ h v4.4.78..v4.4.121 arch / arm | wc -l58 ~ / kernels / linux-stable (master) $ git log --format =٪ h v4.4.78..v4.4.121 arch / arm64 | wc -l22 ~ / kernels / linux-stable (master) $ git log --format =٪ h v4.4.78..v4.4.121 fs / ext4 | مرحاض -18

الجزء الأكثر استهلاكا للوقت هو إحضار الأولي. بمجرد الانتهاء من التحديث ، لن يستغرق الأمر وقتًا على الإطلاق للدمج في إصدار جديد ، لا يحتوي عادة على أكثر من 100 عملية تنفيذ. يجب أن تستلزم هذه العملية الفوائد التي يحققها هذا (مزيد من الاستقرار وأمان أفضل لمستخدميك).

كيفية دمج Linux Stable Kernel في Android Kernel

تحتاج أولاً إلى معرفة إصدار kernel الذي يعمل عليه جهاز Android.

بقدر ما يبدو هذا تافهاً ، من الضروري أن تعرف من أين يجب أن تبدأ. قم بتشغيل الأمر التالي في شجرة kernel:

 جعل kernelversion

سيعود الإصدار الذي أنت عليه. سيتم استخدام الرقمين الأولين لمعرفة الفرع الذي تحتاج إليه (على سبيل المثال linux-4.4.y لأي 4.4 نواة) وسيتم استخدام الرقم الأخير لتحديد الإصدار الذي تحتاجه لبدء الدمج (على سبيل المثال ، إذا كنت تعمل على 4.4 .21 ، ستقوم بدمج 4.4.22 التالي).

الحصول على أحدث مصدر kernel من kernel.org

يضم kernel.org أحدث مصدر kernel في مستودع Linux الثابت. في أسفل تلك الصفحة ، سيكون هناك ثلاثة روابط جلب. في تجربتي ، تميل مرآة Google إلى أن تكون الأسرع ولكن نتائجك قد تختلف. قم بتشغيل الأوامر التالية:

 git remote add linux-stable //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit fetch linux-stable

حدد ما إذا كنت تريد دمج النواة بأكملها أو اختيار الكرز

بعد ذلك ، ستحتاج إلى اختيار ما إذا كنت تريد دمج التعيينات أو اختيار الكرز. وإليك إيجابيات وسلبيات كل وعندما تريد القيام بها.

ملاحظة: إذا كان مصدر kernel الخاص بك في شكل كرة قارية ، فستحتاج على الأرجح إلى اختيار الكرز ، وإلا فستحصل على الآلاف من تعارضات الملفات لأن git تملأ السجل استنادًا إلى بحتة وليس إلى ما لدى الشركة المصنّعة للمعدات الأصلية أو CAF تغير. فقط انتقل إلى الخطوة 4.

قطف الكرز:

الايجابيات:

أسهل لحل النزاعات كما تعلمون بالضبط ما الذي يسبب الصراع مشكلة.
أسهل في إعادة التوجيه حيث أن كل التزام من تلقاء نفسه.
أسهل في تشريح إذا واجهت القضايا

سلبيات:

يستغرق وقتًا أطول نظرًا لأن كل التزام يجب اختياره بشكل فردي.
من الصعب معرفة ما إذا كان الالتزام من المنبع للوهلة الأولى

دمج

الايجابيات :

إنه أسرع لأنه ليس عليك الانتظار حتى يتم دمج كافة التصحيحات النظيفة.
من الأسهل معرفة متى يكون الالتزام من المنبع لأنك لن تكون المرتكب ، فإن المشرف على المنبع سيكون كذلك.

سلبيات:

يمكن أن يكون حل النزاعات أكثر صعوبة بعض الشيء حيث ستحتاج إلى البحث عن الالتزام الذي يسبب الصراع باستخدام git log / git اللوم ، لن يخبرك مباشرةً.
يعد إعادة التثبيت أمرًا صعبًا لأنه لا يمكنك إعادة دمج عملية الدمج ، وسيوفر لك اختيار كل الالتزام بشكل فردي. ومع ذلك ، يجب أن لا تكون rebasing كثيرًا ، بدلاً من ذلك باستخدام git revert و git merge حيثما أمكن ذلك.

أوصي بالقيام باختيار الكرز لمعرفة أي تعارضات للمشاكل في البداية ، والقيام بدمج ، ثم التراجع عن المشكلة بعد ذلك حتى يصبح التحديث أسهل (حيث يكون الدمج أسرع بعد تحديثه).

أضف التعهدات إلى المصدر الخاص بك ، إصدار واحد في وقت واحد

الجزء الأكثر أهمية من هذه العملية هو إصدار واحد في وقت واحد. قد يكون هناك مشكلة في سلسلة upstream ، والتي يمكن أن تسبب مشكلة في التشغيل أو كسر شيء مثل الصوت أو الشحن (موضح في قسم النصائح والحيل). يعد إجراء تغييرات تدريجية على الإصدار أمرًا مهمًا لهذا السبب ، فمن الأسهل العثور على مشكلة في 50 دعوى مقارنة بـ 2000 مرة في بعض الإصدارات. أود أن أوصي فقط بالقيام بدمج كامل بمجرد أن تعرف كل مشكلة ارتكابها وحل النزاعات.

قطف الكرز

شكل:

 بوابة الكرز بيك ..

مثال:

بوابة الكرز بيك v3.10.73..v3.10.74

دمج

شكل:

 دمج بوابة

مثال:

بوابة دمج v3.10.74

أوصي بتتبع التعارضات في عمليات الدمج عن طريق إزالة علامات #.

كيفية حل النزاعات

لا يمكننا تقديم دليل خطوة بخطوة لحل كل صراع ، لأنه يتضمن معرفة جيدة باللغة C ، ولكن هناك بعض التلميحات.

إذا كنت تندمج ، فاكتشف ما هو الالتزام الذي يسبب الصراع. يمكنك القيام بذلك واحدة من طريقتين:

git log -pv $ (make kernelversion) .. للحصول على التغييرات بين الإصدار الحالي والأحدث من upstream. ستمنحك علامة -p التغييرات التي تم إجراؤها بواسطة كل التزام حتى يمكنك رؤيته.
تشغيل git اللوم على الملف للحصول على تجزئات كل التزام في المنطقة. يمكنك بعد ذلك تشغيل git show –format = fuller لمعرفة ما إذا كان المرسل من الخط الرئيسي / الثابت أو Google أو CodeAurora.

معرفة ما إذا كان لديك بالفعل الالتزام. سيحاول بعض البائعين ، مثل Google أو CAF ، البحث عن الخلل الحرجة ، مثل إصلاح Dirty COW ، وقد يتعارض دعمهم الخلفي مع عمليات التنقيب. يمكنك تشغيل git log –grep = "" ومعرفة ما إذا كان يُرجع أي شيء. إذا كان الأمر كذلك ، فيمكنك تخطي الالتزام (إذا كان اختيار الكرز باستخدام git reset –hard && git cherry-pick –continue) أو تجاهل التعارضات (قم بإزالة <<<<< >>>>>).
معرفة ما إذا كان هناك backport التي هي خراب القرار. ترغب Google و CAF في إعادة دعم بعض التصحيحات التي لن يستقر عليها هذا الإصدار. ستحتاج الإسطبل غالبًا إلى تكييف قرار الالتزام الرئيسي بوقف بعض التصحيحات التي تختار Google إعادة دعمها. يمكنك إلقاء نظرة على التزام الخط الرئيسي عن طريق تشغيل برنامج git show (ستكون علامة التجزئة الرئيسية متوفرة في رسالة الالتزام الخاصة بالالتزام المستقر). إذا كان هناك backport تعبث به ، يمكنك إما تجاهل التغييرات أو يمكنك استخدام الإصدار الرئيسي (وهو ما سوف تحتاج عادة إلى القيام به).
اقرأ ما يحاول الالتزام القيام به ومعرفة ما إذا كانت المشكلة قد تم حلها بالفعل أم لا. في بعض الأحيان ، قد يقوم CAF بإصلاح الخلل بشكل مستقل عن المنبع ، مما يعني أنه يمكنك إما الكتابة فوق الإصلاح الخاص بالتطبيق المنبع أو التخلص منه ، كما هو مذكور أعلاه.

خلاف ذلك ، قد يكون مجرد نتيجة لإضافة CAF / Google / OEM ، وفي هذه الحالة تحتاج فقط إلى خلط بعض الأشياء من حولك.

في ما يلي نسخة متطابقة من مستودع kernel.org المستقر على نظام Linux على GitHub ، والذي يمكن أن يكون أسهل في البحث عن قوائم الالتزام وفرق تسوية المنازعات. أوصي بالانتقال إلى طريقة عرض قائمة الالتزام أولاً وتحديد موقع مشكلة الالتزام لرؤية الفرق الأصلي لمقارنته بك.

مثال عنوان URL: //github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

يمكنك أيضًا القيام بذلك عبر سطر الأوامر:

 بوابة سجل .. بوابة المعرض

حل القرارات هو كل شيء عن السياق. ما يجب عليك فعله دائمًا هو التأكد من أن فرقتك النهائية تتطابق مع المنبع من خلال تشغيل الأوامر التالية في نافذتين منفصلتين:

 git diff HEAD git diff v $ (make kernelversion) .. $ (git tag --sort = -taggerdate -lv $ (make kernelversion | cut -d. -f 1،2) * | head -n1)

تمكين rerere

يحتوي Git على ميزة تسمى rerere (تعني إعادة استخدام الدقة المسجلة) ، وهذا يعني أنه عندما يكتشف تعارضًا ، فسوف يسجل كيفية حلها حتى تتمكن من إعادة استخدامها لاحقًا. هذا مفيد بشكل خاص لكلا rebasers المزمن مع كل من دمج واختيار الكرز كما ستحتاج فقط إلى تشغيل git add. && git - تابع عند إعادة إنشاء upup up up حيث سيتم حل التعارض كيف تم حلها مسبقًا.

يمكن تمكينه عن طريق تشغيل الأمر التالي في kernel repo:

 بوابة التكوين rerere.enabled صحيح

كيفية git bisect عند الوقوع في مترجم أو خطأ وقت التشغيل

نظرًا لأنك ستضيف عددًا كبيرًا من الإلتزامات ، فمن الممكن جدًا لك تقديم خطأ في التحويل البرمجي أو في وقت التشغيل. بدلاً من الاستسلام ، يمكنك استخدام أداة bitect المدمجة من git لمعرفة السبب الجذري للمشكلة! من الناحية المثالية ، ستقوم ببناء وميض كل إصدار من إصدارات kernel الفردية أثناء إضافته ، لذا فإن التنقيح يستغرق وقتًا أقل إذا لزم الأمر ولكن يمكنك تشريح 5000 التزام دون أي مشاكل.

ما ستفعله git bisect هو اتخاذ مجموعة من التعهدات ، من المكان الذي توجد فيه المشكلة إلى حيث لم تكن موجودة ، ثم البدء في خفض نطاق الالتزام إلى النصف ، مما يسمح لك بالبناء والاختبار وإعلامها إذا كانت جيدة أم لا . سيستمر هذا حتى يبصق الالتزام الذي تسبب في مشكلتك. في هذه المرحلة ، يمكنك إما إصلاحه أو إرجاعه.

بدء تشريح: بوابة بدء تشريح
وصف المراجعة الحالية بأنها سيئة: git bisect bad
وصف المراجعة بأنها جيدة: git bisect good
بناء مع المراجعة الجديدة
بناءً على النتيجة (إذا كانت المشكلة موجودة أم لا) ، أخبر git: git bisect good أو git bisect bad
شطف وكرر الخطوات 4-5 حتى يتم العثور على الالتزام المشكلة!
العودة أو إصلاح المشكلة الالتزام.

ملاحظة: ستحتاج عمليات الدمج إلى تشغيل git rebase مؤقتًا - i لتطبيق جميع التصحيحات على الفرع الخاص بك لإجراء عملية تشريح مناسبة ، حيث إن التشريح مع عمليات الدمج في المكان سوف يؤدي في كثير من الأحيان إلى تسجيل الخروج على التزامات المنبع ، مما يعني أنه ليس لديك أي من التزامات Android المحددة. يمكنني أن أتعمق أكثر في هذا عند الطلب ولكن ثق بي ، هناك حاجة لذلك. بمجرد تحديد الالتزام بالمشكلة ، يمكنك التراجع عنها أو إعادة دمجها في الدمج.

لا الاسكواش التحديثات المنبع

يميل الكثير من المطورين الجدد إلى القيام بذلك لأنه "أنظف" و "أسهل" في إدارته. هذا أمر فظيع لعدة أسباب:

فقدت التأليف. من غير المنصف للمطورين الآخرين أن يتم تسديد ائتمانهم بسبب عملهم.
تشريح أمر مستحيل. إذا قمت بسحق سلسلة من الإلتزامات وكان هناك شيء ما في هذه السلسلة ، فمن المستحيل معرفة ما تسبب في مشكلة في الإسكواش.
اختيارات الكرز المستقبلية أصعب. إذا كنت بحاجة إلى إعادة التشغيل باستخدام سلسلة مقلوبة ، فمن الصعب / المستحيل معرفة من أين ينشأ تعارض.

اشترك في قائمة Linux Kernel البريدية للحصول على التحديثات في الوقت المناسب

من أجل الحصول على إخطار كلما كان هناك تحديث upstream ، الاشتراك في قائمة إعلان linux-kernel. سيتيح لك ذلك الحصول على بريد إلكتروني في كل مرة يتم فيها إصدار نواة جديدة حتى تتمكن من التحديث والدفع بأسرع ما يمكن.