วิธีอัปเดตเคอร์เนล Android เป็น Linux ล่าสุดที่เสถียร

เราได้ครอบคลุมแนวทางเกี่ยวกับเคอร์เนลของ Android เช่น "วิธีสร้างเคอร์เนลที่กำหนดเอง" และ "เคอร์เนลที่กำหนดเองที่ดีที่สุดสำหรับ Android" แต่วันนี้เราจะแสดงวิธีอัปสตรีมเคอร์เนลของคุณกับ Linux เสถียรล่าสุด

โปรดทราบว่านี่คือสิ่ง ขั้นสูง - หากคุณไม่เคยรวบรวมเคอร์เนลมาก่อนคุณควรทำตามคำแนะนำ "วิธีสร้างเคอร์เนลที่กำหนดเอง" ที่ลิงก์ด้านบนและคู่มือนี้จะเกี่ยวข้องกับการรวบรวมเชอร์รี่และคอมมิชชันจาก Linux ล่าสุด - เคอร์เนลที่เสถียรกับเคอร์เนล Android ของคุณก่อนที่คุณจะรวบรวม

การอัปเกรดเคอร์เนล Android ของคุณไปยัง Linux ล่าสุดจะมีประโยชน์มากมายเช่นการอัพเดทความปลอดภัยและข้อผิดพลาดล่าสุด - เราจะอธิบายข้อดีและข้อเสียบางอย่างในคู่มือนี้

เคอร์เนล Linux-Stable คืออะไร

Linux-stable ตามชื่อหมายถึงเป็นแขนที่มั่นคงของเคอร์เนล Linux แขนอีกข้างเรียกว่า "ฉีด" ซึ่งเป็น แขนงหลัก การพัฒนาเคอร์เนล Linux ทั้งหมดเกิดขึ้นในการฉีดและโดยทั่วไปจะทำตามกระบวนการนี้:

1. Linus Torvalds จะหยิบของปะจากผู้ดูแลของเขาเป็นเวลาสองสัปดาห์
2. หลังจากสองสัปดาห์นี้เขาจะปล่อยเคอร์เนล rc1 (เช่น 4.14-rc1)
3. สำหรับแต่ละสัปดาห์สำหรับ 6-8 สัปดาห์ถัดไปเขาจะปล่อยเคอร์เนล RC (เช่น 4.14-rc2, 4.14-rc3 และอื่น ๆ ) ซึ่งมีเฉพาะการแก้ไขข้อบกพร่องและการถดถอยเท่านั้น
4. เมื่อถือว่ามีเสถียรภาพแล้วจะมีการเปิดตัวเป็น tarball สำหรับดาวน์โหลดในองค์กร (เช่น 4.14)

เมล็ด LTS คืออะไร?

ทุกปี Greg จะเลือกเคอร์เนลหนึ่งตัวและเก็บรักษาไว้เป็นเวลาสองปี (LTS) หรือหกปี (Extended LTS) สิ่งเหล่านี้ได้รับการออกแบบให้มีผลิตภัณฑ์ที่ต้องการความเสถียร (เช่นโทรศัพท์ Android หรืออุปกรณ์ IOT อื่น ๆ ) กระบวนการนี้เป็นแบบเดียวกันกับที่กล่าวไว้ข้างต้นมันเพิ่งเกิดขึ้นเป็นเวลานาน ปัจจุบันมีเมล็ด LTS หกเมล็ด (ซึ่งสามารถดูได้ในหน้าเผยแพร่ kernel.org):

• 4.14 (LTS) ดูแลโดย Greg Kroah-Hartman
• 4.9 (LTS), ดูแลโดย Greg Kroah-Hartman
• 4.4 (eLTS) ดูแลโดย Greg Kroah-Hartman
• 4.1 (LTS) ดูแลโดย Sasha Levin
• 3.16 (LTS) ดูแลโดย Ben Hutchings
• 3.2 (LTS) ดูแลโดย Ben Hutchings

การอัปเกรดเคอร์เนล Android ของฉันไปยัง Linux Stable มีประโยชน์อย่างไร

เมื่อมีการเปิดเผย / แก้ไขช่องโหว่ที่สำคัญเมล็ดที่เสถียรจะเป็นช่องโหว่แรกที่ได้รับ ดังนั้นเคอร์เนล Android ของคุณจะปลอดภัยมากขึ้นจากการโจมตีข้อบกพร่องด้านความปลอดภัยและข้อบกพร่องโดยทั่วไป

Linux เสถียรรวมถึงการแก้ไขสำหรับไดรเวอร์จำนวนมากที่อุปกรณ์ Android ของฉันไม่ได้ใช้มันไม่จำเป็นเลยใช่มั้ย

ใช่และไม่ขึ้นอยู่กับว่าคุณให้นิยาม“ ส่วนใหญ่” เคอร์เนล Linux อาจมีรหัสจำนวนมากที่ไม่ได้ใช้ในระบบ Android แต่ไม่รับประกันว่าจะไม่มีความขัดแย้งจากไฟล์เหล่านั้นเมื่อทำการผสานเวอร์ชันใหม่! เข้าใจว่าแทบ ไม่มีใคร สร้างส่วนของเคอร์เนลได้แม้แต่แม้แต่ลินุกซ์ distros ทั่วไปเช่น Ubuntu หรือ Mint นี่ไม่ได้หมายความว่าคุณไม่ควรทำการแก้ไขเหล่านี้เพราะมีการแก้ไขสำหรับไดรเวอร์ที่คุณรัน ยกตัวอย่างเช่น arm / arm64 และ ext4 ซึ่งเป็นสถาปัตยกรรม Android ที่พบมากที่สุดและระบบไฟล์ตามลำดับ ใน 4.4 จาก 4.4.78 (เวอร์ชันของแท็ก Oreo CAF ล่าสุด) ถึง 4.4.121 (แท็กอัปสตรีมล่าสุด) นี่คือตัวเลขต่อไปนี้สำหรับการกระทำของระบบเหล่านั้น:

 ~ / kernels / linux-stable (master) บันทึก $ git - รูปแบบ =% h v4.4.78..v4.4.121 | wc -l2285 ~ / kernels / linux-stable (master) บันทึก $ git - รูปแบบ =% h v4.4.78..v4.4.121 arch / arm | wc -l58 ~ / kernels / linux-stable (master) บันทึก $ git - รูปแบบ =% h v4.4.78..v4.4.121 arch / arm64 | wc -l22 ~ / kernels / linux-stable (หลัก) บันทึก $ git - รูปแบบ =% h v4.4.78..v4.4.121 fs / ext4 | ห้องสุขา -l18 

ส่วนที่ใช้เวลามากที่สุดคือการเริ่มต้นทำงาน เมื่อคุณได้รับข้อมูลล่าสุดแล้วก็ไม่ต้องใช้เวลาในการรวมเข้ากับรีลีสใหม่ซึ่งมักจะมีการคอมมิทไม่เกิน 100 คอมมิท ประโยชน์ที่จะได้รับ (เสถียรภาพมากขึ้นและความปลอดภัยที่ดีขึ้นสำหรับผู้ใช้ของคุณ) ควรทำให้กระบวนการนี้มีความจำเป็น

วิธีผสานเคอร์เนล Linux เสถียรเข้ากับเคอร์เนล Android

ก่อนอื่นคุณต้องหาว่ารุ่นใดที่เคอร์เนลอุปกรณ์ Android ของคุณใช้งานอยู่

เป็นเรื่องเล็กน้อยอย่างที่เห็นมันเป็นสิ่งจำเป็นที่จะต้องรู้ว่าคุณต้องเริ่มจากตรงไหน รันคำสั่งต่อไปนี้ในแผนผังเคอร์เนลของคุณ:

 ทำ kernelversion 

มันจะส่งคืนเวอร์ชันที่คุณใช้อยู่ ตัวเลขสองตัวแรกจะถูกนำมาใช้เพื่อหาสาขาที่คุณต้องการ (เช่น linux-4.4.y สำหรับเคอร์เนล 4.4) และหมายเลขสุดท้ายจะถูกใช้เพื่อกำหนดเวอร์ชันที่คุณต้องการเริ่มต้นด้วยการผสาน (เช่นถ้าคุณใช้ 4.4 .21 คุณจะรวม 4.4.22 ต่อไป)

คว้าแหล่งเคอร์เนลล่าสุดจาก kernel.org

kernel.org เป็นแหล่งของเคอร์เนลล่าสุดในที่เก็บ linux-stable ที่ด้านล่างของหน้านั้นจะมีลิงค์ดึงข้อมูลอยู่สามลิงก์ จากประสบการณ์ของฉันกระจกของ Google มีแนวโน้มที่จะเร็วที่สุด แต่ผลลัพธ์ของคุณอาจแตกต่างกันไป รันคำสั่งต่อไปนี้:

 git remote เพิ่ม linux-stable //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit ดึง linux-stable 

ตัดสินใจว่าคุณต้องการรวมเคอร์เนลทั้งหมดหรือเลือกเชอร์รี่

ถัดไปคุณจะต้องเลือกถ้าคุณต้องการรวมการกระทำหรือเชอร์รี่เลือก นี่คือข้อดีข้อเสียของแต่ละคนและเมื่อคุณอาจต้องการที่จะทำ

หมายเหตุ: หากแหล่งเคอร์เนลของคุณอยู่ในรูปแบบของ tarball ส่วนใหญ่คุณจะต้องเลือกรับไม่เช่นนั้นคุณจะได้รับความขัดแย้งหลายพันไฟล์เนื่องจาก git กำลังเติมประวัติตามทางต้นน้ำไม่ใช่ OEM หรือ CAF การเปลี่ยนแปลง เพียงข้ามไปขั้นตอนที่ 4

เชอร์รี่แคะ:

ข้อดี:

• ง่ายขึ้นในการแก้ไขข้อขัดแย้งตามที่คุณทราบแน่ชัดว่าความขัดแย้งใดที่ทำให้เกิดปัญหา
• ง่ายต่อการรีบูตเนื่องจากการส่งแต่ละครั้งจะดำเนินการด้วยตนเอง
• ง่ายต่อการแบ่งออกเป็นสองส่วนหากพบปัญหา

จุดด้อย:

• ใช้เวลานานกว่าที่แต่ละการส่งมอบจะต้องเลือกทีละรายการ
• ยากขึ้นอีกเล็กน้อยที่จะบอกได้ว่าการกระทำนั้นมาจากต้นน้ำเมื่อมองแวบแรก

ผสาน

ข้อดี :

• มันเร็วกว่าที่คุณไม่ต้องรอให้แผ่นสะอาดทั้งหมดรวมเข้าด้วยกัน
• มันง่ายกว่าที่จะเห็นว่าการกระทำนั้นมาจากต้นน้ำเพราะคุณจะไม่ใช่ผู้มุ่งมั่นผู้ดูแลต้นน้ำจะเป็น

จุดด้อย:

• การแก้ไขข้อขัดแย้งอาจเป็นเรื่องยากขึ้นเล็กน้อยเนื่องจากคุณจะต้องค้นหาว่าการกระทำใดก่อให้เกิดความขัดแย้งโดยใช้การตำหนิ git log / git มันจะไม่บอกคุณโดยตรง
• การรีบูทเป็นเรื่องยากเนื่องจากคุณไม่สามารถรีบูตการผสานได้มันจะเสนอให้เลือกการกระทำทั้งหมดเป็นรายบุคคล อย่างไรก็ตามคุณไม่ควรทำการรีบูตบ่อยครั้งแทนที่จะใช้ git revert และ git merge เมื่อเป็นไปได้

ฉันขอแนะนำให้ทำ Cherry-pick เพื่อหาข้อขัดแย้งของปัญหาใด ๆ ในตอนแรกทำการผสานจากนั้นจึงย้อนกลับปัญหาที่เกิดขึ้นหลังจากนั้นเพื่อให้การอัปเดตนั้นง่ายขึ้น (การผสานนั้นเร็วขึ้นหลังจากอัปเดตเป็นปัจจุบัน)

เพิ่มคอมมิชชันลงในแหล่งที่มาของคุณทีละหนึ่งเวอร์ชัน

ส่วนที่สำคัญที่สุดของกระบวนการนี้คือรุ่นหนึ่งในเวลาส่วนหนึ่ง อาจมีปัญหาในซีรีย์อัปสตรีมของคุณซึ่งอาจทำให้เกิดปัญหากับการบูทหรือทำลายบางอย่างเช่นเสียงหรือการชาร์จ (อธิบายไว้ในส่วนเคล็ดลับและลูกเล่น) การทำการเปลี่ยนแปลงรุ่นเพิ่มเติมนั้นมีความสำคัญสำหรับเหตุผลนี้ทำให้ง่ายต่อการค้นหาปัญหาใน 50 คอมมิทมากกว่าการคอมมิทรุ่นขึ้นไป 2000 ครั้งสำหรับบางเวอร์ชั่น ฉันอยากจะแนะนำให้ทำการผสานอย่างสมบูรณ์เมื่อคุณรู้ว่าปัญหาทั้งหมดกระทำและการแก้ไขข้อขัดแย้ง

เชอร์รี่แคะ

รูปแบบ:

 คอมไพล์เชอร์รี่เลือก .. 

ตัวอย่าง:

git cherry-pick v3.10.73..v3.10.74

ผสาน

รูปแบบ:

 คอมไพล์ผสาน 

ตัวอย่าง:

git merge v3.10.74

ฉันขอแนะนำให้ติดตามความขัดแย้งในการรวมการกระทำโดยการลบเครื่องหมาย # ออก

วิธีแก้ไขความขัดแย้ง

เราไม่สามารถให้คำแนะนำทีละขั้นตอนเพื่อแก้ไขความขัดแย้งทุกอย่างเนื่องจากเกี่ยวข้องกับความรู้ภาษา C ที่ดี แต่นี่เป็นคำแนะนำเล็กน้อย

หากคุณกำลังรวมกันให้คิดว่าการกระทำใดก่อให้เกิดความขัดแย้ง คุณสามารถทำหนึ่งในสองวิธีนี้:

1. git log -pv $ (สร้างเคอร์เนล) เพื่อรับการเปลี่ยนแปลงระหว่างเวอร์ชันปัจจุบันของคุณกับเวอร์ชันล่าสุดจาก upstream แฟล็ก -p จะให้การเปลี่ยนแปลงที่คุณทำโดยแต่ละคอมมิทเพื่อที่คุณจะได้เห็น
2. เรียกใช้การคอมไพล์ตำหนิในไฟล์เพื่อรับการแฮชของการคอมมิทแต่ละครั้งในพื้นที่ จากนั้นคุณสามารถเรียกใช้ git show –format = fuller เพื่อดูว่าคอมมิชชันนั้นมาจากการฉีด / เสถียร, Google หรือ CodeAurora

• คิดออกว่าคุณมีความมุ่งมั่นแล้ว ผู้ค้าบางรายเช่น Google หรือ CAF จะพยายามค้นหาข้อบกพร่องที่สำคัญเช่นการแก้ไข Dirty COW และ backport ของพวกเขาอาจขัดแย้งกับของ upstream คุณสามารถเรียกใช้ git log –grep =”” และดูว่ามันส่งคืนอะไรหรือไม่ ถ้าเป็นเช่นนั้นคุณสามารถข้ามการกระทำ (ถ้าการหยิบเชอร์รี่โดยใช้การรีเซ็ต git - ฮาร์ด && git การเลือกเชอร์รี่ - ต่อเนื่อง) หรือละเว้นข้อขัดแย้ง (ลบ <<<<< >>>>>)
• คิดออกว่ามี backport ที่ messing up ความละเอียด Google และ CAF ต้องการ backport แพทช์บางอย่างที่ไม่น่าเชื่อถือ เสถียรมักจะต้องปรับความละเอียดของการฉีดเพื่อให้ได้มาซึ่งความไม่แน่นอนของ patch ที่ Google เลือกที่จะ backport คุณสามารถดูการกระทำการฉีดได้โดยการรันการแสดง git (แฮชการฉีดจะพร้อมใช้งานในข้อความการส่งข้อความของการส่งข้อมูลที่มีเสถียรภาพ) หากมี backport messing มันขึ้นคุณสามารถยกเลิกการเปลี่ยนแปลงหรือคุณสามารถใช้รุ่น mainline (ซึ่งเป็นสิ่งที่คุณมักจะต้องทำ)
• อ่านสิ่งที่ผู้มอบอำนาจพยายามทำและดูว่าปัญหาได้รับการแก้ไขแล้วหรือไม่ บางครั้ง CAF อาจแก้ไขข้อผิดพลาดที่เป็นอิสระจาก upstream ซึ่งหมายความว่าคุณสามารถเขียนทับการแก้ไขของพวกเขาสำหรับ upstream's หรือละทิ้งมันเช่นด้านบน

ไม่เช่นนั้นอาจเป็นผลมาจากการเพิ่ม CAF / Google / OEM ซึ่งในกรณีนี้คุณต้องสลับบางสิ่งรอบ ๆ

นี่เป็นภาพสะท้อนของพื้นที่เก็บข้อมูล kernel.org ที่มีเสถียรภาพของ linux บน GitHub ซึ่งสามารถค้นหารายการคอมมิตและการแก้ไขข้อขัดแย้งได้ง่ายขึ้น ฉันขอแนะนำให้ไปที่มุมมองรายการยอมรับก่อนและค้นหาปัญหาที่กระทำเพื่อดู diff ต้นฉบับเพื่อเปรียบเทียบกับของคุณ

ตัวอย่าง URL: //github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

คุณยังสามารถทำได้ผ่านบรรทัดคำสั่ง:

 git log .. git show 

การแก้ปัญหาคือทั้งหมดที่เกี่ยวกับบริบท สิ่งที่คุณควรทำเสมอคือทำให้แน่ใจว่า diff สุดท้ายของคุณตรงกับ upstream โดยเรียกใช้คำสั่งต่อไปนี้ในหน้าต่างแยกสองหน้าต่าง:

 git diff HEAD git diff v $ (ทำเคอร์เนลรุ่น) .. $ (แท็ก git --sort = -taggerdate -lv $ (ทำ kernelversion | cut -d. -f 1, 2) * | head -n1) 

เปิดใช้งานการทำซ้ำ

Git มีคุณสมบัติที่เรียกว่า rerere (ย่อมาจาก Reuse Recorded Resolution) ซึ่งหมายความว่าเมื่อตรวจพบข้อขัดแย้งมันจะบันทึกวิธีที่คุณแก้ไขมันเพื่อให้คุณสามารถนำกลับมาใช้ใหม่ได้ในภายหลัง สิ่งนี้มีประโยชน์อย่างยิ่งสำหรับทั้งผู้รีบาวด์เรื้อรังที่มีทั้งการรวมและการเลือกเชอร์รี่เนื่องจากคุณจะต้องเพิ่มคอมไพล์ && git - หยุดเมื่อทำการ redupup ของอัปสตรีมเนื่องจากความขัดแย้งจะได้รับการแก้ไขวิธีที่คุณแก้ไขก่อนหน้านี้

มันสามารถเปิดใช้งานโดยการเรียกใช้คำสั่งต่อไปนี้ใน repo เคอร์เนลของคุณ:

 git config rerere.enabled จริง 

วิธีการคอมไพล์ทวิตเมื่อทำงานเป็นคอมไพเลอร์หรือข้อผิดพลาดรันไทม์

เนื่องจากคุณจะเพิ่มจำนวนการคอมมิทที่มากพอคุณสามารถแนะนำคอมไพเลอร์หรือข้อผิดพลาดรันไทม์ได้ แทนที่จะยอมแพ้คุณสามารถใช้เครื่องมือ bisect ในตัวเพื่อหาสาเหตุของปัญหาได้! เป็นการดีที่คุณจะสร้างและกระพริบทุกเคอร์เนลเวอร์ชันเดียวตามที่คุณเพิ่มมันการตัดจะใช้เวลาน้อยลงหากจำเป็น แต่คุณสามารถแบ่งออกได้ 5, 000 commits โดยไม่มีปัญหาใด ๆ

สิ่งที่ gis bisect จะทำคือใช้ช่วงของการคอมมิชชันจากที่มีปัญหาไปยังที่ที่ไม่ได้อยู่จากนั้นเริ่มครึ่งช่วงคอมมิชชันที่อนุญาตให้คุณสร้างและทดสอบและแจ้งให้ทราบว่าดีหรือไม่ . มันจะดำเนินการต่อไปจนกว่าจะแยกการกระทำที่ทำให้เกิดปัญหาของคุณ ณ จุดนี้คุณสามารถแก้ไขได้หรือย้อนกลับ

1. เริ่มต้นแบ่งครึ่ง: เริ่มต้นแบ่งครึ่ง
2. ติดป้ายการแก้ไขปัจจุบันว่าไม่ดี: คอมไพล์ไม่ดี
3. ติดป้ายการแก้ไขว่าดี: คอมไพล์ดี
4. สร้างด้วยการแก้ไขใหม่
5. ขึ้นอยู่กับผลลัพธ์ (หากมีปัญหาหรือไม่) บอก git: git bisect ดีหรือ git bisect ไม่ดี
6. ล้างและทำซ้ำขั้นตอนที่ 4-5 จนกระทั่งพบปัญหาการส่ง!
7. ย้อนกลับหรือแก้ไขปัญหาการมอบหมาย

หมายเหตุ: การควบรวมกิจการจะต้องเรียกใช้ git rebase -i ชั่วคราวเพื่อนำ patch ทั้งหมดไปใช้กับสาขาของคุณเพื่อทำการตัดที่เหมาะสมเนื่องจากการตัดกับการรวมในสถานที่นั้นมักจะมีการชำระเงินครั้งเดียวกับคอมมิชชัน upstream ซึ่งหมายความว่า ฉันสามารถพูดคุยเกี่ยวกับเรื่องนี้ได้ลึกกว่านี้ตามที่ขอ แต่เชื่อฉันเป็นสิ่งจำเป็น เมื่อคุณระบุปัญหาที่กระทำแล้วคุณสามารถย้อนกลับหรือทำการรีบูตเป็นการผสานได้

อย่าสควอชอัปเดตอัปสตรีม

นักพัฒนาใหม่จำนวนมากถูกล่อลวงให้ทำเช่นนี้เพราะ "สะอาด" และ "ง่ายขึ้น" ในการจัดการ นี่คือเหตุผลที่น่ากลัวด้วยเหตุผลบางประการ:

• การประพันธ์สูญหายไป มันไม่ยุติธรรมกับผู้พัฒนารายอื่นที่จะให้เครดิตกับงานของพวกเขา
• การตัดแบ่งเป็นไปไม่ได้ หากคุณสควอชชุดของการกระทำและสิ่งที่เป็นปัญหาในซีรีส์นั้นมันเป็นไปไม่ได้ที่จะบอกได้ว่าการกระทำที่ก่อให้เกิดปัญหาในสควอช
• การเลือกเชอร์รี่ในอนาคตนั้นยากกว่า หากคุณต้องการรีบูตด้วยซีรี่ส์ที่ถูกแบนมันเป็นเรื่องยาก / เป็นไปไม่ได้ที่จะบอกได้ว่าความขัดแย้งนั้นมาจากไหน

สมัครสมาชิกลิสต์การส่งเมลเคอร์เนลเพื่อรับการอัพเดททันเวลา

เพื่อรับการแจ้งเตือนเมื่อใดก็ตามที่มีการอัปเดตอัปสตรีมให้สมัครสมาชิกรายการ linux-kernel-ประกาศ วิธีนี้จะช่วยให้คุณได้รับอีเมลทุกครั้งที่เคอร์เนลใหม่ถูกปล่อยออกมาเพื่อให้คุณสามารถอัปเดตและพุชได้อย่างรวดเร็วที่สุด