làm thế nào để

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

Chúng tôi đã giới thiệu các hướng dẫn về các nhân Android, chẳng hạn như Cách xây dựng hạt nhân tùy chỉnh và hạt nhân tùy chỉnh tốt nhất cho Android, nhưng hôm nay chúng tôi sẽ hướng dẫn bạn cách cập nhật kernel của bạn chống lại Linux ổn định mới nhất.

Vui lòng biết rằng đây là công cụ nâng cao - nếu bạn chưa bao giờ biên dịch kernel trước đó, bạn nên làm theo hướng dẫn về Cách xây dựng hạt nhân tùy chỉnh được liên kết ở trên và hướng dẫn này sẽ bao gồm các cam kết chọn và hợp nhất cherry từ Linux mới nhất- kernel ổn định với kernel Android của bạn trước khi bạn biên dịch nó.

Việc đưa dòng nhân Android của bạn lên bộ ổn định Linux mới nhất có rất nhiều lợi ích tích cực, chẳng hạn như được cập nhật các cam kết bảo mật và lỗi mới nhất - chúng tôi sẽ giải thích một số ưu và nhược điểm sau trong hướng dẫn này.

Nhân ổn định Linux là gì?

Ổn định Linux như tên gọi của nó là nhánh ổn định của nhân Linux. Cánh tay còn lại được biết đến với tên gọi là dòng chính của dòng Cameron, là nhánh chính . Tất cả sự phát triển nhân Linux đều diễn ra trong dòng chính và thường tuân theo quy trình này:

Linus Torvalds sẽ lấy một loạt các bản vá từ những người bảo trì của anh ta trong hai tuần.
Sau hai tuần, anh ta phát hành hạt nhân RC1 (ví dụ 4.14-rc1).
Trong mỗi tuần trong 6-8 tuần tiếp theo, anh ta sẽ phát hành một hạt nhân RC khác (ví dụ: 4.14-rc2, 4.14-rc3, v.v.), chứa CHỈ sửa lỗi và hồi quy.
Khi nó được coi là ổn định, nó sẽ được phát hành dưới dạng tarball để tải xuống trên org (ví dụ 4.14).

Hạt nhân LTS là gì?

Mỗi năm, Greg sẽ chọn một hạt nhân và duy trì nó trong hai năm (LTS) hoặc sáu năm (LTS mở rộng). Chúng được thiết kế để có các sản phẩm cần sự ổn định (như điện thoại Android hoặc các thiết bị IOT khác). Quá trình này giống hệt như trên, nó chỉ xảy ra trong một thời gian dài hơn. Hiện tại có sáu hạt nhân LTS (luôn có thể được xem trên trang phát hành kernel.org):

4, 14 (LTS), được duy trì bởi Greg Kroah-Hartman
4.9 (LTS), được duy trì bởi Greg Kroah-Hartman
4.4 (eLTS), được duy trì bởi Greg Kroah-Hartman
4.1 (LTS), được duy trì bởi Sasha Levin
3.16 (LTS), được duy trì bởi Ben Hutchings
3.2 (LTS), được duy trì bởi Ben Hutchings

Những lợi ích của việc cập nhật kernel Android của tôi vào Linux Stable là gì?

Khi các lỗ hổng quan trọng được tiết lộ / sửa chữa, các hạt nhân ổn định là những cái đầu tiên để có được chúng. Do đó, nhân Android của bạn sẽ an toàn hơn rất nhiều trước các cuộc tấn công, lỗi bảo mật và chỉ là các lỗi nói chung.

Ổn định Linux bao gồm các bản sửa lỗi cho nhiều trình điều khiển mà thiết bị Android của tôi không sử dụng, điều này hầu như không cần thiết?

Có và không, tùy thuộc vào cách bạn xác định chủ yếu là 341. Nhân Linux có thể bao gồm rất nhiều mã không được sử dụng trong hệ thống Android, nhưng điều đó không đảm bảo sẽ không có xung đột từ các tệp đó khi hợp nhất các phiên bản mới! Hiểu rằng hầu như không ai xây dựng từng phần của kernel, thậm chí không phải là các bản phân phối Linux phổ biến nhất như Ubuntu hay Mint. Điều này không có nghĩa là bạn không nên thực hiện các bản sửa lỗi này vì có bản sửa lỗi cho trình điều khiển bạn chạy. Lấy arm / arm64 và ext4 làm ví dụ, đây là hệ thống tệp và kiến trúc phổ biến nhất của Android. Trong 4.4, từ 4.4.78 (phiên bản của thẻ Oreo CAF mới nhất) đến 4.4.121 (thẻ ngược dòng mới nhất), đây là những con số sau đây cho các cam kết của các hệ thống đó:

 ~ / kernels / linux-ổn định (chính) $ git log --format =% h v4.4.78..v4.4.121 | wc -l2285 ~ / hạt nhân / linux-ổn định (chính) $ git log --format =% h v4.4.78..v4.4.121 arch / arm | wc -l58 ~ / kernels / linux-ổn định (chính) $ git log --format =% h v4.4.78..v4.4.121 arch / arm64 | wc -l22 ~ / kernels / linux-ổn định (chính) $ git log --format =% h v4.4.78..v4.4.121 fs / ext4 | wc -l18

Phần tốn thời gian nhất là phần khởi đầu; một khi bạn hoàn toàn cập nhật, sẽ không mất chút thời gian nào để hợp nhất trong một bản phát hành mới, thường không chứa hơn 100 lần xác nhậ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 hạt nhân ổn định Linux vào hạt nhân Android

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

Như tầm thường như thế này, cần phải biết bạn 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 bật. 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ỳ kernel 4.4 nào) và số cuối cùng sẽ được sử dụng để xác định phiên bản nào bạn cần bắt đầu với việc hợp nhất (ví dụ: nếu bạn ở trên 4.4 .21, bạn sẽ hợp nhất 4.4.22 tiếp theo).

Lấy nguồn kernel mới nhất từ kernel.org

kernel.org chứa nguồn kernel mới nhất trong kho lưu trữ ổn định linux. Ở dưới cùng của 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ể thay đổi. Chạy các lệnh sau:

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

Quyết định xem bạn có muốn hợp nhất toàn bộ kernel hoặc chọn cherry không

Tiếp theo, bạn sẽ cần chọn nếu bạn muốn hợp nhất các cam kết hoặc chọn cherry. Đây là ưu và nhược điểm của mỗi và khi bạn có thể muốn làm chúng.

LƯU Ý: Nếu nguồn kernel của bạn ở dạng tarball, rất có thể bạn sẽ cần chọn cherry, nếu không, bạn sẽ nhận được hàng ngàn xung đột tệp vì git đang điền vào lịch sử hoàn toàn dựa trên thượng nguồn, không phải là OEM hay CAF có đã thay đổi Chỉ cần bỏ qua bước 4.

Chọn anh đào:

Ưu điểm:

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

Nhược điểm:

Phải mất nhiều thời gian hơn vì mỗi cam kết phải được chọn riêng.
Khó khăn hơn để nói nếu cam kết là từ thượng nguồn trong cái nhìn đầu tiên

Hợp nhất

Ưu điểm :

Sẽ nhanh hơn vì bạn không phải đợi tất cả các bản vá sạch sẽ hợp nhất.
Sẽ dễ dàng hơn để xem khi một cam kết là từ thượng nguồn vì bạn sẽ không phải là người đi lại, người duy trì ngược dòng sẽ là.

Nhược điểm:

Giải quyết xung đột có thể khó khăn hơn một chút vì bạn sẽ cần tìm kiếm cam kết nào gây ra xung đột bằng cách sử dụng git log / git đổ lỗi, nó sẽ không trực tiếp cho bạn biết.
Rebasing rất khó vì bạn không thể rebase một hợp nhất, nó sẽ cung cấp cho cherry-pick tất cả các cam kết riêng lẻ. Tuy nhiên, bạn không nên nổi loạn thường xuyên, thay vào đó 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 lựa chọn anh đào để 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 các vấn đề được cam kết sau đó để cập nhật dễ dàng hơn (vì việc hợp nhất sẽ nhanh hơn sau khi cập nhật).

Thêm các cam kết vào nguồn của bạn, mỗi phiên bản một

Phần quan trọng nhất của quá trình này là một phiên bản tại một phần thời gian. Có thể có một bản vá vấn đề trong loạt ngược dòng của bạn, điều này có thể gây ra sự cố khi khởi động hoặc phá vỡ thứ gì đó như âm thanh hoặc sạc (được giải thích trong phần mẹo và thủ thuật). Thực hiện các thay đổi phiên bản gia tăng rất quan trọng vì lý do này, việc tìm kiếm một vấn đề trong 50 lần cam kết trở nên dễ dàng hơn so với 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.

Chọn anh đào

Định dạng:

 git cherry-pick ..

Thí dụ:

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

Hợp nhất

Định dạng:

 hợp nhất git

Thí dụ:

hợp nhất git 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 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 đây là một vài gợi ý.

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

git log -pv $ (tạo kernelversion) .. để có được những 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ừ thượng nguồn. Cờ -p sẽ cung cấp cho bạn các thay đổi được thực hiện bởi mỗi cam kết để bạn có thể thấy.
Chạy git đổ lỗi cho tập tin để có được băm của từng cam kết trong khu vực. Sau đó, bạn có thể chạy git showTHERformat = fuller để xem liệu người giao dịch đến từ tuyến chính / ổn định, Google hoặc CodeAurora.

Chỉ ra nếu bạn đã có cam kết. 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, như sửa lỗi Dirty COW và các bản sao lưu của họ có thể xung đột với thượng nguồn. Bạn có thể chạy git logTHERgrep = 341, và xem nó có trả lại gì không. Nếu đúng như vậy, bạn có thể bỏ qua cam kết (nếu chọn anh đào bằng cách sử dụng git reset HPhard && git cherry-pick Nhậncontinue) hoặc bỏ qua các xung đột (xóa <<<<< >>>>>).
Tìm hiểu xem đã có một backport làm rối độ phân giải. Google và CAF muốn backport một số bản vá nhất định sẽ ổn định. Ổn định thường sẽ cần điều chỉnh độ phân giải của đường chính cam kết với sự bỏ qua của một số bản vá nhất định mà Google áp dụng cho backport. Bạn có thể xem cam kết chính bằng cách chạy chương trình git (hàm băm 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 rối tung nó, bạn có thể loại bỏ các thay đổi hoặc bạn có thể sử dụng phiên bản chính (đó là những gì bạn thường sẽ cần phải làm).
Đọc những gì mà 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 độc lập với ngược dòng, nghĩa là bạn có thể ghi đè lên bản sửa lỗi của chúng để ngược dòng hoặc loại bỏ nó, như trên.

Mặt khác, 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.

Dưới đâ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 trong việc tìm kiếm danh sách cam kết và 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à định vị cam kết vấn đề để xem khác biệt ban đầu để so sánh nó với bạn.

URL ví dụ: //github.com/nathanchance/linux-urdy/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:

 đăng nhập git .. hiển thị git

Giải quyết các nghị quyết là tất cả về bối cảnh. Những gì bạn nên LUÔN làm là đảm bảo khác biệt cuối cùng của bạn khớp với 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 -lv $ (tạo kernelversion | cut -d. -f 1, 2) * | head -n1)

Kích hoạt lại

Git có một tính năng gọi là rerere (viết tắt của Reuse Recorded Nghị quyết), nghĩa là khi phát hiện xung đột, nó sẽ ghi lại cách bạn giải quyết nó để bạn có thể sử dụng lại sau. Điều này đặc biệt hữu ích cho cả những người nổi loạn kinh niên với cả việc hợp nhất và chọn anh đào vì bạn sẽ chỉ cần chạy git add. && gitTHERcontinue khi làm lại việc đưa lên 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 repo kernel của bạn:

 git config rerere.en bật đúng

Cách git bisect khi chạy vào trình biên dịch hoặc lỗi thời gian chạy

Cho rằng bạn sẽ thêm một số lượng lớn các cam kết, bạn có thể giới thiệu một trình biên dịch hoặc lỗi thời gian chạy. Thay vì chỉ từ bỏ, bạn có thể sử dụng công cụ chia đôi tích hợp 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à flash mọi phiên bản kernel đơn lẻ khi bạn thêm nó để việc chia đôi sẽ mất ít thời gian hơn nếu cần nhưng bạn có thể chia đôi 5000 lần xác nhận mà không gặp 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 xảy ra sự cố đến nơi nó 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 nó 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ó phun ra cam kết gây ra vấn đề của bạn. Tại thời điểm đó, bạn có thể sửa nó hoặc hoàn nguyên nó.

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

LƯU Ý: Sáp nhập sẽ cần 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 để chia đôi chính xác, vì việc chia đôi với các sự hợp nhất tại chỗ sẽ thường xuyên 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 tin tưởng tôi, nó là cần thiết. Khi bạn đã xác định được cam kết vấn đề, bạn có thể hoàn nguyên hoặc khởi động lại nó thành hợp nhất.

KHÔNG đè bẹp các cập nhật ngược dòng

Rất nhiều nhà phát triển mới bị cám dỗ để làm điều này vì nó là chương trình dọn dẹp sạch hơn và dễ dàng hơn để quản lý. Đ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ọ được quy định cho công việc của họ.
Sai sót là không thể. Nếu bạn đè bẹp một loạt các cam kết và một cái gì đó là một vấn đề trong chuỗi đó, thì không thể biết được cam kết nào gây ra vấn đề trong một quả bí.
Tương lai anh đào khó hơn. Nếu bạn cần phải nổi loạn với một loạt bị đè bẹp, rất khó / không thể biết được kết quả của một cuộc xung đột từ đâu.

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

Để nhận được 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ý vào danh sách thông báo kernel-kernel. Điều này sẽ cho phép bạn nhận được email mỗi khi kernel mới được phát hành để bạn có thể cập nhật và đẩy nhanh nhất có thể.