Cara Memperbarui Kernel Android Anda ke Linux Stable Terbaru

Kami telah membahas panduan tentang kernel Android, seperti "Cara Membangun Kernel Kustom" dan "Kernel Kustom Terbaik untuk Android", tetapi hari ini kami akan menunjukkan kepada Anda bagaimana untuk meng-upstream kernel Anda terhadap stabil Linux terbaru.

Ketahuilah bahwa ini adalah hal-hal lanjutan - jika Anda belum pernah mengkompilasi kernel sebelumnya, Anda harus mengikuti panduan "Cara Membangun Kernel Kustom" yang ditautkan di atas, dan panduan ini akan melibatkan komit pengambilan dan penggabungan ceri dari Linux terbaru kernel stabil dengan kernel Android Anda sebelum Anda mengkompilasinya.

Melakukan upstream kernel Android Anda ke Linux stable terbaru memiliki banyak manfaat positif, seperti memperbarui dengan komitmen keamanan terbaru dan perbaikan bug - kami akan menjelaskan beberapa pro dan kontra nanti dalam panduan ini.

Apa itu kernel Linux-Stable?

Linux-stable sesuai namanya adalah lengan stabil dari kernel Linux. Lengan lainnya dikenal sebagai "arus utama", yang merupakan cabang utama . Semua pengembangan kernel Linux terjadi di jalur utama, dan umumnya mengikuti proses ini:

1. Linus Torvalds akan mengambil banyak tambalan dari pengurusnya selama dua minggu.
2. Setelah dua minggu ini, ia merilis kernel rc1 (mis. 4.14-rc1).
3. Untuk setiap minggu selama 6-8 minggu ke depan, ia akan merilis kernel RC lain (mis. 4.14-rc2, 4.14-rc3, dll), yang berisi HANYA perbaikan bug dan regresi.
4. Setelah dianggap stabil, itu akan dirilis sebagai tarball untuk diunduh di org (mis. 4.14).

Apa itu kernel LTS?

Setiap tahun, Greg akan memilih satu kernel dan memeliharanya selama dua tahun (LTS) atau enam tahun (extended LTS). Ini dirancang untuk memiliki produk yang membutuhkan stabilitas (seperti ponsel Android atau perangkat IOT lainnya). Prosesnya sama persis seperti di atas, itu hanya terjadi untuk waktu yang lebih lama. Saat ini ada enam kernel LTS (yang selalu dapat dilihat di halaman rilis kernel.org):

• 4.14 (LTS), dikelola oleh Greg Kroah-Hartman
• 4.9 (LTS), dikelola oleh Greg Kroah-Hartman
• 4.4 (eLTS), dikelola oleh Greg Kroah-Hartman
• 4.1 (LTS), dikelola oleh Sasha Levin
• 3.16 (LTS), dikelola oleh Ben Hutchings
• 3.2 (LTS), dikelola oleh Ben Hutchings

Apa manfaat dari upstreaming kernel Android saya ke Linux Stable?

Ketika kerentanan penting diungkapkan / diperbaiki, kernel stabil adalah yang pertama mendapatkannya. Dengan demikian, kernel Android Anda akan jauh lebih aman terhadap serangan, kelemahan keamanan, dan bug pada umumnya.

Stabil Linux menyertakan perbaikan untuk banyak driver yang tidak digunakan perangkat Android saya, bukankah ini sebagian besar tidak perlu?

Ya dan tidak, tergantung pada bagaimana Anda mendefinisikan "sebagian besar". Kernel Linux dapat menyertakan banyak kode yang tidak digunakan dalam sistem Android, tetapi itu tidak menjamin tidak akan ada konflik dari file-file tersebut ketika menggabungkan versi baru! Memahami bahwa hampir tidak ada yang membangun setiap bagian dari kernel, bahkan distro Linux yang paling umum seperti Ubuntu atau Mint. Ini tidak berarti Anda tidak boleh mengambil perbaikan ini karena ADA perbaikan untuk driver yang Anda jalankan. Ambil contoh arm / arm64 dan ext4, yang merupakan arsitektur Android dan sistem file yang paling umum. Di 4.4, dari 4.4.78 (versi tag Oreo CAF terbaru) hingga 4.4.121 (tag upstream terbaru), ini adalah angka-angka berikut untuk komitmen sistem-sistem tersebut:

 ~ / kernel / linux-stable (master) $ git log --format =% h v4.4.78..v4.4.121 | wc -l2285 ~ / kernel / linux-stable (master) $ git log --format =% h v4.4.78..v4.4.121 arch / arm | wc -l58 ~ / kernel / linux-stable (master) $ git log --format =% h v4.4.78..v4.4.121 arch / arm64 | wc -l22 ~ / kernel / linux-stable (master) $ git log --format =% h v4.4.78..v4.4.121 fs / ext4 | wc -l18 

Bagian yang paling memakan waktu adalah tampilan awal; setelah Anda benar-benar mutakhir, tidak butuh waktu sama sekali untuk bergabung dalam rilis baru, yang biasanya berisi tidak lebih dari 100 komitmen. Manfaat yang dihasilkannya (stabilitas dan keamanan yang lebih baik bagi pengguna Anda) harus memerlukan proses ini.

Cara Menggabungkan Linux Stable Kernel menjadi Android Kernel

Pertama, Anda perlu mencari tahu versi kernel apa yang dijalankan perangkat Android Anda.

Sepele seperti ini tampaknya, perlu untuk mengetahui di mana Anda harus memulai. Jalankan perintah berikut di pohon kernel Anda:

 buat versi kernel 

Ini akan mengembalikan versi yang Anda gunakan. Dua angka pertama akan digunakan untuk mencari tahu cabang yang Anda butuhkan (mis. Linux-4.4.y untuk kernel 4.4) dan angka terakhir akan digunakan untuk menentukan versi apa yang Anda perlukan untuk memulai dengan penggabungan (mis. Jika Anda menggunakan 4.4 .21, Anda akan menggabungkan 4.4.22 selanjutnya).

Raih sumber kernel terbaru dari kernel.org

kernel.org menampung sumber kernel terbaru di repositori linux-stable. Di bagian bawah halaman itu, akan ada tiga tautan ambil. Dalam pengalaman saya, mirror Google cenderung menjadi yang tercepat tetapi hasil Anda dapat bervariasi. Jalankan perintah berikut:

 git remote menambahkan linux-stable //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit ambil linux-stable 

Putuskan apakah Anda ingin menggabungkan seluruh kernel atau memilih ceri komit

Selanjutnya, Anda harus memilih jika ingin menggabungkan komit atau memilih-ceri. Inilah pro dan kontra dari masing-masing dan kapan Anda ingin melakukannya.

CATATAN: Jika sumber kernel Anda adalah dalam bentuk tarball, kemungkinan besar Anda perlu memilih-ceri, jika tidak, Anda akan mendapatkan ribuan konflik file karena git mengisi sejarah berdasarkan murni di hulu, bukan apa yang dimiliki OEM atau CAF berubah. Langsung saja ke langkah 4.

Memetik ceri:

Pro:

• Lebih mudah menyelesaikan konflik karena Anda tahu persis konflik apa yang menyebabkan masalah.
• Lebih mudah untuk rebase karena setiap komit adalah sendiri.
• Lebih mudah membagi dua jika mengalami masalah

Cons:

• Dibutuhkan lebih lama karena setiap komit harus dipilih secara individual.
• Sedikit lebih sulit untuk mengetahui apakah komit berasal dari hulu pada pandangan pertama

Menggabungkan

Pro :

• Ini lebih cepat karena Anda tidak harus menunggu semua patch bersih untuk bergabung.
• Lebih mudah untuk melihat ketika komit berasal dari hulu karena Anda tidak akan menjadi pengemis, pengelola hulu akan menjadi.

Cons:

• Menyelesaikan konflik bisa menjadi sedikit lebih sulit karena Anda perlu mencari komit yang menyebabkan konflik menggunakan git log / git menyalahkan, itu tidak akan langsung memberi tahu Anda.
• Rebasing itu sulit karena Anda tidak bisa membuat ulang gabungan, itu akan menawarkan untuk memilih semua komit secara individual. Namun, Anda seharusnya tidak sering rebasing, sebaliknya menggunakan git revert dan git merge jika memungkinkan.

Saya akan merekomendasikan melakukan cherry-pick untuk mencari tahu konflik masalah pada awalnya, melakukan penggabungan, kemudian mengembalikan masalah yang dilakukan setelah itu sehingga memperbarui lebih mudah (karena penggabungan lebih cepat setelah diperbarui).

Tambahkan komit ke sumber Anda, satu versi setiap kali

Bagian terpenting dari proses ini adalah versi satu per satu. Mungkin ada patch masalah di seri hulu Anda, yang dapat menyebabkan masalah dengan boot atau merusak sesuatu seperti suara atau pengisian daya (dijelaskan di bagian tips dan trik). Melakukan perubahan versi tambahan adalah penting karena alasan ini, lebih mudah untuk menemukan masalah dalam 50 commit daripada 2000 commit untuk beberapa versi. Saya hanya akan merekomendasikan melakukan penggabungan penuh setelah Anda mengetahui semua masalah yang terjadi dan resolusi konflik.

Memetik ceri

Format:

 git cherry-pick .. 

Contoh:

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

Menggabungkan

Format:

 git bergabung 

Contoh:

git merge v3.10.74

Saya merekomendasikan untuk melacak konflik dalam gabungan komit dengan menghapus tanda #.

Cara Mengatasi Konflik

Kami tidak dapat memberikan panduan langkah demi langkah untuk menyelesaikan setiap konflik tunggal, karena melibatkan pengetahuan yang baik tentang bahasa C, tapi di sini ada beberapa petunjuk.

Jika Anda bergabung, cari tahu komit apa yang menyebabkan konflik. Anda dapat melakukan ini dengan dua cara:

1. git log -pv $ (make kernelversion) .. untuk mendapatkan perubahan antara versi Anda saat ini dan yang terbaru dari hulu. Bendera -p akan memberi Anda perubahan yang dilakukan oleh setiap komit sehingga Anda dapat melihat.
2. Jalankan menyalahkan git pada file untuk mendapatkan hash dari setiap commit di area tersebut. Anda kemudian dapat menjalankan git show –format = lebih lengkap untuk melihat apakah committer berasal dari mainline / stable, Google, atau CodeAurora.

• Cari tahu apakah Anda sudah memiliki komit. Beberapa vendor seperti Google atau CAF akan berusaha mencari upstream untuk bug penting, seperti perbaikan COW Kotor, dan backport mereka dapat bertentangan dengan upstream. Anda dapat menjalankan git log –grep = ”” dan melihat apakah itu mengembalikan sesuatu. Jika ya, Anda dapat melewati komit (jika memetik ceri menggunakan git reset –hard && git ceri-pick - lanjutkan) atau abaikan konflik (hapus <<<<< >>>>>).
• Cari tahu apakah ada backport yang mengacaukan resolusi. Google dan CAF ingin mencadangkan tambalan tertentu yang tidak stabil. Stabil akan sering perlu untuk mengadaptasi resolusi dari garis utama yang berkomitmen pada absennya tambalan tertentu yang Google pilih untuk di-backport. Anda dapat melihat komit garis utama dengan menjalankan git show (hash garis utama akan tersedia dalam pesan komit dari komit stabil). Jika ada backport yang mengacaukannya, Anda bisa membuang perubahan atau menggunakan versi garis utama (yang biasanya perlu Anda lakukan).
• Baca apa yang coba dilakukan komit dan lihat apakah masalahnya sudah diperbaiki. Terkadang CAF dapat memperbaiki bug yang terlepas dari upstream, artinya Anda dapat menimpa perbaikannya untuk upstream atau membuangnya, seperti di atas.

Kalau tidak, itu mungkin hanya hasil dari penambahan CAF / Google / OEM, dalam hal ini Anda hanya perlu mengacak beberapa hal di sekitar.

Berikut ini adalah mirror dari repositori kernel.org linux-stable di GitHub, yang dapat lebih mudah untuk mencari daftar commit dan berbeda untuk resolusi konflik. Saya sarankan pergi ke tampilan daftar komit terlebih dahulu dan mencari masalah komit untuk melihat diff asli untuk membandingkannya dengan Anda.

URL contoh: //github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

Anda juga dapat melakukannya melalui baris perintah:

 log git .. pertunjukan git 

Memecahkan resolusi adalah tentang konteks. Apa yang harus Anda SELALU lakukan adalah memastikan perbedaan final Anda cocok dengan upstream dengan menjalankan perintah berikut di dua jendela terpisah:

 git diff HEAD git diff v $ (make kernelversion) .. $ (tag git --sort = -taggerdate -lv $ (make kernelversion | cut -d. -f 1, 2) * | head -n1) 

Aktifkan rerere

Git memiliki fitur yang disebut rerere (kependekan dari Reuse Recorded Resolution), artinya ketika mendeteksi konflik, ia akan merekam bagaimana Anda menyelesaikannya sehingga Anda dapat menggunakannya kembali nanti. Ini sangat membantu untuk kedua rebasers kronis dengan penggabungan dan pengambilan ceri karena Anda hanya perlu menjalankan git add. && git –lanjutkan saat mengulang kembali upstream karena konflik akan diselesaikan seperti sebelumnya.

Ini dapat diaktifkan dengan menjalankan perintah berikut di repo kernel Anda:

 git config rerere.enabled benar 

Bagaimana cara membagi dua saat menjalankan ke compiler atau runtime error

Karena Anda akan menambahkan jumlah komit yang cukup besar, sangat mungkin bagi Anda untuk memperkenalkan kesalahan kompilator atau runtime. Alih-alih menyerah, Anda dapat menggunakan alat bisect bawaan git untuk mengetahui akar penyebab masalah! Idealnya, Anda akan membangun dan mem-flash setiap versi kernel tunggal saat Anda menambahkannya sehingga membagi dua akan memakan waktu lebih sedikit jika diperlukan tetapi Anda dapat membagi dua 5.000 komit tanpa masalah.

Apa yang akan dilakukan git bisect adalah mengambil serangkaian komitmen, mulai dari di mana masalah hadir hingga tidak ada, dan kemudian mulai mengurangi separuh kisaran komit, memungkinkan Anda untuk membangun dan menguji dan membiarkannya tahu apakah itu baik atau tidak . Ini akan melanjutkan ini sampai meludahkan komit yang menyebabkan masalah Anda. Pada titik itu, Anda dapat memperbaikinya atau mengembalikannya.

1. Mulai membagi dua: mulai git membagi dua
2. Beri label revisi saat ini sebagai buruk: git bisect buruk
3. Beri label revisi sebagai baik: git bisect good
4. Bangun dengan revisi baru
5. Berdasarkan hasil (jika masalah ada atau tidak), beri tahu git: git bisect baik ATAU git bisect buruk
6. Bilas dan ulangi langkah 4-5 hingga masalah komit ditemukan!
7. Kembalikan atau perbaiki komit masalah.

CATATAN: Merger perlu menjalankan sementara git rebase -i untuk menerapkan semua tambalan ke cabang Anda untuk membagi dua secara tepat, karena membagi dua dengan penggabungan di tempat akan sering kali checkout ke komit upstream, artinya Anda tidak memiliki komitmen spesifik Android. Saya bisa lebih mendalam tentang ini berdasarkan permintaan tetapi percayalah, itu diperlukan. Setelah Anda mengidentifikasi masalah yang dikomit, Anda bisa mengembalikan atau mengubahnya kembali ke dalam gabungan.

JANGAN remas pembaruan hulu

Banyak pengembang baru tergoda untuk melakukan ini karena ini “bersih” dan “lebih mudah” untuk dikelola. Ini mengerikan karena beberapa alasan:

• Karangan hilang. Tidak adil bagi pengembang lain untuk menghentikan kredit mereka atas pekerjaan mereka.
• Membelah dua tidak mungkin. Jika Anda menekan serangkaian komit dan ada sesuatu yang menjadi masalah dalam seri itu, tidak mungkin untuk mengetahui komit apa yang menyebabkan masalah dalam squash.
• Pilihan ceri masa depan lebih sulit. Jika Anda perlu melakukan rebase dengan seri yang tergencet, sulit / tidak mungkin untuk mengetahui dari mana konflik berasal.

Berlangganan mailing list Kernel Linux untuk pembaruan tepat waktu

Untuk mendapat pemberitahuan kapan pun ada pembaruan di hulu, berlangganan ke daftar linux-kernel-announce. Ini memungkinkan Anda untuk mendapatkan email setiap kali kernel baru dirilis sehingga Anda dapat memperbarui dan mendorong secepat mungkin.