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

nathan @ flashbox ~ / kernels / linux-stabil (master) $ git log --format =٪ h v4.4.78..v4.4.121 | wc -l2285 nathan @ flashbox ~ / kernels / linux-stabil (master) $ git log --format =٪ h v4.4.78..v4.4.121 قوس / ذراع | wc -l58 nathan @ flashbox ~ / kernels / linux-stabil (master) $ git log --format =٪ h v4.4.78..v4.4.121 قوس / arm64 | wc -l22 nathan @ flashbox ~ / kernels / linux-stabil (master) $ git log --format =٪ h v4.4.78..v4.4.121 fs / ext4 | مرحاض -l18

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

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

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

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

جعل kernelversion

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

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

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

git remote add linux-stabil https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit جلب مستقر لينكس

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

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

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

قطف الكرز:

الايجابيات:

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

سلبيات:

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

اذهب

الايجابيات :

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

سلبيات:

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

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

أضف الالتزامات إلى مصدرك ، نسخة واحدة في كل مرة

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

قطف الكرز

شكل:

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

مثال:

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

اذهب

شكل:

اذهب للدمج

مثال:

بوابة دمج v3.10.74

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

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

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

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

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

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

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

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

مثال URL: https://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 -l v $ (make kernelversion | cut -d. -f 1،2) * | head -n1)

تفعيل rerere

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

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

git config rerere.enabled صحيحًا

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

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

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

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

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

لا تقم بسحق تحديثات المنبع

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

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

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

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