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

nathan @ flashbox ~ / kernels / linux-stable (มาสเตอร์) $ git log --format =% h v4.4.78..v4.4.121 | wc -l2285 nathan @ flashbox ~ / kernels / linux-stable (master) $ git log --format =% h v4.4.78..v4.4.121 arch / arm | wc -l58 nathan @ flashbox ~ / kernels / linux-stable (master) $ git log --format =% h v4.4.78..v4.4.121 arch / arm64 | wc -l22 nathan @ flashbox ~ / kernels / linux-stable (master) $ git log --format =% h v4.4.78..v4.4.121 fs / ext4 | wc -l18

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

วิธีผสาน Linux Stable Kernel เข้ากับ Android Kernel

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

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

ทำเคอร์เนล

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

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

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

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

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

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

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

การเก็บเชอร์รี่:

ข้อดี:

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

จุดด้อย:

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

ไป

ข้อดี :

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

จุดด้อย:

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

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

เพิ่มคอมมิตลงในซอร์สของคุณทีละเวอร์ชัน

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

การเก็บเชอร์รี่

รูปแบบ:

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

ตัวอย่าง:

git เชอร์รี่เลือก v3.10.73..v3.10.74

ไป

รูปแบบ:

ไปรวม

ตัวอย่าง:

git ผสาน v3.10.74

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

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

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

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

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

• ดูว่าคุณมีคอมมิตอยู่แล้วหรือไม่ ผู้ให้บริการบางรายเช่น Google หรือ CAF จะพยายามค้นหาจุดบกพร่องที่สำคัญในขั้นต้นเช่นการแก้ไข Dirty COW และแบ็คพอร์ตอาจขัดแย้งกับต้นน้ำ คุณสามารถเรียกใช้ git log –grep =”” และดูว่าส่งคืนค่าอะไรหรือไม่ หากเป็นเช่นนั้นคุณสามารถข้ามการคอมมิต (หากเลือกเชอร์รี่โดยใช้ git reset –hard && git cherry-pick --continue) หรือเพิกเฉยต่อความขัดแย้ง (ลบ<<<<<>>>>>)
• ดูว่ามีแบ็คพอร์ตที่ทำให้ความละเอียดยุ่งเหยิงหรือไม่ Google และ CAF ต้องการแบ็คพอร์ตแพตช์บางอย่างที่ไม่เสถียร Stable มักจะต้องปรับความละเอียดของเมนไลน์ที่กระทำกับการไม่ใช้แพตช์บางอย่างที่ Google เลือกที่จะย้อนกลับ คุณสามารถดูการคอมมิตเมนไลน์ได้โดยเรียกใช้ 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 log .. git show

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

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

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

git config rerere.enabled true

วิธีคอมไพเลอร์แบ่งครึ่งเมื่อทำงานในคอมไพเลอร์หรือข้อผิดพลาดรันไทม์

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

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

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

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

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

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

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

สมัครรับรายชื่อส่งเมลของเคอร์เนล Linux เพื่อรับการอัปเดตตามเวลา

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