Cách cập nhật nhân Android của bạn lên Linux ổn định mới nhất

nathan @ flashbox ~ / kernels / linux-stable (master) $ 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

Phần tốn nhiều thời gian nhất là khởi tạo ban đầu; khi bạn đã cập nhật tất cả, hoàn toàn không mất thời gian để hợp nhất trong một bản phát hành mới, thường chứa không quá 100 cam kết. Tuy nhiên, những lợi ích mà điều này mang lại (ổn định hơn và bảo mật tốt hơn cho người dùng của bạn) nên cần quá trình này.

Cách hợp nhất Nhân ổn định của Linux vào Nhân Android

Trước tiên, bạn cần phải tìm ra phiên bản hạt nhân mà thiết bị Android của bạn đang chạy.

Điều này có vẻ tầm thường, nhưng bạn cần phải biết mình cần bắt đầu từ đâu. Chạy lệnh sau trong cây nhân của bạn:

tạo kernelversion

Nó sẽ trả lại phiên bản bạn đang sử dụng. Hai số đầu tiên sẽ được sử dụng để tìm ra nhánh bạn cần (ví dụ: linux-4.4.y cho bất kỳ hạt nhân 4.4 nào) và số cuối cùng sẽ được sử dụng để xác định phiên bản bạn cần để bắt đầu hợp nhất (ví dụ: nếu bạn đang sử dụng 4.4 .21, bạn sẽ hợp nhất 4.4.22 tiếp theo).

Lấy nguồn hạt nhân mới nhất từ ​​kernel.org

kernel.org chứa nguồn hạt nhân mới nhất trong kho lưu trữ ổn định linux . Ở cuối trang đó, sẽ có ba liên kết tìm nạp. Theo kinh nghiệm của tôi, gương của Google có xu hướng nhanh nhất nhưng kết quả của bạn có thể khác nhau. Chạy các lệnh sau:

git từ xa thêm linux-ổn định https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit tìm nạp linux-ổn định

Quyết định xem bạn muốn hợp nhất toàn bộ hạt nhân hay chọn sơ ri các cam kết

Tiếp theo, bạn sẽ cần phải chọn nếu bạn muốn hợp nhất các cam kết hoặc chọn anh đào. Dưới đây là ưu và nhược điểm của từng loại và khi nào bạn có thể muốn thực hiện chúng.

GHI CHÚ: Nếu nguồn hạt nhân của bạn ở dạng tarball, rất có thể bạn sẽ cần phải sơ chế, nếu không, bạn sẽ nhận được hàng nghìn xung đột tệp vì git đang điền lịch sử hoàn toàn dựa trên ngược dòng chứ không phải những gì OEM hoặc CAF đã thay đổi. Chỉ cần chuyển sang bước 4.

Hái anh đào:

Ưu điểm:

• Giải quyết xung đột dễ dàng hơn khi bạn biết chính xác xung đột đang gây ra vấn đề gì.
• Dễ dàng rebase hơn vì mỗi cam kết là riêng của nó.
• Dễ dàng phân chia hơn nếu gặp sự cố

Nhược điểm:

• Sẽ mất nhiều thời gian hơn vì mỗi cam kết phải được chọn riêng lẻ.
• Khó khăn hơn một chút để biết liệu cam kết có phải là từ thượng nguồn ngay từ cái nhìn đầu tiên hay không

Đi

Ưu điểm :

• Nhanh hơn vì bạn không phải đợi tất cả các bản vá lỗi hợp nhất.
• Dễ dàng nhận thấy khi nào một cam kết từ thượng nguồn vì bạn sẽ không phải là người cam kết mà sẽ là người bảo trì ngược dòng.

Nhược điểm:

• Việc giải quyết xung đột có thể khó hơn một chút vì bạn sẽ cần phải tra cứu bản cam kết nào đang gây ra xung đột bằng cách sử dụng git log / git blu, nó sẽ không trực tiếp cho bạn biết.
• Việc hoàn nguyên rất khó vì bạn không thể căn cứ lại một hợp nhất, nó sẽ cung cấp cho bạn chọn tất cả các cam kết riêng lẻ. Tuy nhiên, bạn không nên khôi phục thường xuyên, thay vào đó hãy sử dụng git revert và git merge nếu có thể.

Tôi khuyên bạn nên thực hiện một thao tác chọn sơ ri để tìm ra bất kỳ xung đột vấn đề nào ban đầu, thực hiện hợp nhất, sau đó hoàn nguyên cam kết vấn đề sau đó để cập nhật dễ dàng hơn (vì hợp nhất nhanh hơn sau khi được cập nhật).

Thêm cam kết vào nguồn của bạn, một phiên bản tại một thời điểm

Phần quan trọng nhất của quá trình này là từng phiên bản một. CÓ THỂ có một bản vá sự cố trong loạt video ngược dòng của bạn, có thể gây ra sự cố khởi động hoặc hỏng một thứ gì đó như âm thanh hoặc sạc (được giải thích trong phần mẹo và thủ thuật). Vì lý do này, việc thực hiện các thay đổi phiên bản gia tăng là rất quan trọng, dễ dàng tìm thấy sự cố trong 50 lần cam kết hơn là 2000 lần cam kết đối với một số phiên bản. Tôi chỉ khuyên bạn nên thực hiện hợp nhất đầy đủ khi bạn biết tất cả các cam kết và giải quyết xung đột của vấn đề.

Hái anh đào

Định dạng:

git cherry-pick ..

Thí dụ:

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

Đi

Định dạng:

đi hợp nhất

Thí dụ:

git merge v3.10.74

Tôi khuyên bạn nên theo dõi các xung đột trong các cam kết hợp nhất bằng cách xóa các điểm đánh dấu #.

Cách giải quyết xung đột

Chúng tôi không thể đưa ra hướng dẫn từng bước để giải quyết mọi xung đột vì nó liên quan đến kiến ​​thức tốt về ngôn ngữ C, nhưng sau đây là một vài gợi ý.

Nếu bạn đang hợp nhất, hãy tìm ra cam kết nào gây ra xung đột. Bạn có thể làm điều này theo một trong hai cách:

1. git log -p v $ (tạo kernelversion) .. để nhận các thay đổi giữa phiên bản hiện tại của bạn và phiên bản mới nhất từ ​​ngược dòng. Cờ -p sẽ cung cấp cho bạn những thay đổi được thực hiện bởi mỗi lần cam kết để bạn có thể thấy.
2. Chạy git blu trên tệp để nhận các băm của từng cam kết trong khu vực. Sau đó, bạn có thể chạy git show –format = fuller để xem trình cam kết đến từ mainline / stable, Google hay CodeAurora.

• Tìm hiểu xem bạn đã có cam kết chưa. Một số nhà cung cấp như Google hoặc CAF sẽ cố gắng tìm kiếm các lỗi nghiêm trọng, chẳng hạn như bản sửa lỗi BÒ Bẩn và cổng ngược của họ có thể xung đột với các lỗi ngược dòng. Bạn có thể chạy git log –grep = ”” và xem nó có trả về bất kỳ thứ gì không. Nếu đúng như vậy, bạn có thể bỏ qua cam kết (nếu chọn cherry bằng git reset –hard && git cherry-pick –continue) hoặc bỏ qua các xung đột (xóa<<<<<>>>>>).
• Tìm hiểu xem có một backport nào đang làm rối loạn độ phân giải hay không. Google và CAF muốn phản hồi một số bản vá lỗi ổn định thì không. Ổn định thường sẽ cần phải điều chỉnh độ phân giải của cam kết đường chính đối với sự vắng mặt của một số bản vá lỗi mà Google chọn để hỗ trợ. Bạn có thể xem cam kết dòng chính bằng cách chạy git show (băm dòng chính sẽ có sẵn trong thông báo cam kết của cam kết ổn định). Nếu có một backport làm xáo trộn nó, bạn có thể hủy các thay đổi hoặc bạn có thể sử dụng phiên bản dòng chính (đó là những gì bạn thường sẽ cần làm).
• Đọc những gì cam kết đang cố gắng thực hiện và xem sự cố đã được khắc phục chưa. Đôi khi CAF có thể sửa một lỗi không phụ thuộc vào quá trình ngược dòng, nghĩa là bạn có thể ghi đè bản sửa lỗi của họ cho phần ngược dòng hoặc loại bỏ nó, như ở trên.

Nếu không, nó có thể chỉ là kết quả của việc bổ sung CAF / Google / OEM, trong trường hợp đó, bạn chỉ cần xáo trộn một số thứ xung quanh.

Đây là một bản sao của kho lưu trữ kernel.org ổn định linux trên GitHub, có thể dễ dàng hơn để tra cứu danh sách cam kết và các khác biệt để giải quyết xung đột. Tôi khuyên bạn nên đi đến chế độ xem danh sách cam kết trước và xác định sự cố cam kết để xem sự khác biệt ban đầu để so sánh nó với của bạn.

URL mẫu: https://github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

Bạn cũng có thể làm điều đó thông qua dòng lệnh:

git log .. git show

Giải quyết các độ phân giải là tất cả về ngữ cảnh. Điều bạn LUÔN LUÔN nên làm là đảm bảo điểm khác biệt cuối cùng của bạn khớp với phần ngược dòng bằng cách chạy các lệnh sau trong hai cửa sổ riêng biệt:

git diff HEAD git diff v $ (tạo kernelversion) .. $ (thẻ git --sort = -taggerdate -l v $ (tạo kernelversion | cut -d. -f 1,2) * | head -n1)

Bật rerere

Git có một tính năng gọi là rerere (viết tắt của Reuse Recorded Resolution), nghĩa là khi phát hiện ra xung đột, nó sẽ ghi lại cách bạn đã giải quyết để bạn có thể sử dụng lại sau này. Điều này đặc biệt hữu ích cho cả những người làm lại lâu năm với cả việc hợp nhất và hái anh đào vì bạn sẽ chỉ cần chạy git add. && git – tiếp tục khi thực hiện lại quy trình ngược dòng vì xung đột sẽ được giải quyết theo cách bạn đã giải quyết trước đó.

Nó có thể được kích hoạt bằng cách chạy lệnh sau trong kho hạt nhân của bạn:

git config rerere.enabled true

Làm thế nào để git bisect khi chạy vào trình biên dịch hoặc lỗi thời gian chạy

Do bạn sẽ thêm một số lượng lớn các cam kết, bạn rất có thể gặp lỗi trình biên dịch hoặc thời gian chạy. Thay vì chỉ từ bỏ, bạn có thể sử dụng công cụ bisect tích hợp sẵn của git để tìm ra nguyên nhân gốc rễ của vấn đề! Lý tưởng nhất là bạn sẽ xây dựng và nhấp nháy từng phiên bản hạt nhân khi bạn thêm nó, do đó việc chia nhỏ sẽ mất ít thời gian hơn nếu cần nhưng bạn có thể chia nhỏ 5000 lần cam kết mà không gặp bất kỳ vấn đề gì.

Những gì git bisect sẽ làm là thực hiện một loạt các cam kết, từ nơi có vấn đề đến nơi không xuất hiện và sau đó bắt đầu giảm một nửa phạm vi cam kết, cho phép bạn xây dựng và kiểm tra và cho biết liệu nó có tốt hay không . Nó sẽ tiếp tục điều này cho đến khi nó tạo ra cam kết gây ra sự cố của bạn. Tại thời điểm đó, bạn có thể sửa hoặc hoàn nguyên.

1. Bắt đầu chia đôi: git bisect start
2. Gắn nhãn bản sửa đổi hiện tại là xấu: git bisect bad
3. Gắn nhãn một bản sửa đổi là tốt: git bisect good
4. Xây dựng với bản sửa đổi mới
5. Dựa trên kết quả (nếu sự cố có hay không), hãy cho git biết: git bisect tốt HOẶC git bisect xấu
6. Rửa sạch và lặp lại các bước 4-5 cho đến khi tìm thấy lỗi!
7. Hoàn nguyên hoặc sửa lỗi cam kết.

GHI CHÚ: Các hợp nhất sẽ cần phải tạm thời chạy git rebase -i để áp dụng tất cả các bản vá cho chi nhánh của bạn để phân chia phù hợp, vì việc chia nhỏ với các hợp nhất tại chỗ thường sẽ kiểm tra các cam kết ngược dòng, nghĩa là bạn không có cam kết cụ thể nào của Android. Tôi có thể đi sâu hơn về vấn đề này theo yêu cầu nhưng hãy tin tôi, nó là cần thiết. Khi bạn đã xác định cam kết vấn đề, bạn có thể hoàn nguyên hoặc căn cứ lại nó vào hợp nhất.

KHÔNG xóa các bản cập nhật ngược dòng

Rất nhiều nhà phát triển mới muốn làm điều này vì nó “sạch sẽ hơn” và “dễ quản lý” hơn. Điều này thật tồi tệ vì một vài lý do:

• Quyền tác giả bị mất. Thật không công bằng cho các nhà phát triển khác khi tín dụng của họ bị hạn chế cho công việc của họ.
• Bẻ đôi là không thể. Nếu bạn bỏ qua một loạt cam kết và có vấn đề gì đó trong chuỗi đó, thì không thể biết được cam kết nào đã gây ra sự cố trong một loạt cam kết.
• Việc hái anh đào trong tương lai khó hơn. Nếu bạn cần phải căn cứ lại với một chuỗi bị bóp méo, rất khó / không thể biết xung đột bắt nguồn từ đâu.

Đăng ký danh sách gửi thư Nhân Linux để cập nhật kịp thời

Để nhận thông báo bất cứ khi nào có bản cập nhật ngược dòng, hãy đăng ký danh sách thông báo-kernel-linux . Điều này sẽ cho phép bạn nhận email mỗi khi hạt nhân mới được phát hành để bạn có thể cập nhật và đẩy nhanh nhất có thể.