bagaimana untuk

Bagaimana Mengemas kini Kernel Android anda ke Stable Linux Terkini

Kami telah membimbing panduan mengenai kernel Android, seperti "Bagaimana Membina Kernel Tersuai" dan "Kernels Custom Terbaik untuk Android", tetapi hari ini kami akan menunjukkan kepada anda bagaimana untuk menaikkan kernel anda terhadap stabil Linux terkini.

Sila ketahui bahawa ini adalah perkara yang lebih maju - jika anda tidak pernah menyusun kernel sebelum ini, anda harus mengikuti panduan "Bagaimana Membina Kernel Tersuai" di pautan di atas, dan panduan ini akan melibatkan pengambil ceri dan penggabungan dari Linux- kernel stabil dengan kernel Android anda sebelum anda menyusunnya.

Memantulkan kernel Android anda ke stabil Linux terkini mempunyai banyak faedah positif, seperti yang terkini dengan komitmen keselamatan terkini dan pembaikan - kami akan menerangkan beberapa kebaikan dan keburukan kemudian dalam panduan ini.

Apakah kernel Linux-Stable?

Linux-stabil seperti namanya adalah lengan stabil kernel Linux. Lengan yang lain dikenali sebagai "mainline", yang merupakan cawangan utama . Semua perkembangan kernel Linux berlaku di baris utama, dan umumnya mengikuti proses ini:

Linus Torvalds akan mengambil banyak patch dari penyenggaranya selama dua minggu.
Selepas dua minggu ini, dia mengeluarkan kernel rc1 (contohnya 4.14-rc1).
Untuk setiap minggu untuk 6-8 minggu yang akan datang, dia akan membebaskan kernel lain RC (contohnya 4.14-rc2, 4.14-rc3, dll), yang mengandungi pembetulan bug dan regresi SAHAJA.
Sebaik sahaja ia dianggap stabil, ia akan dilepaskan sebagai tarball untuk muat turun pada org (mis. 4.14).

Apakah kernel LTS?

Setiap tahun, Greg akan memilih satu kernel dan mengekalkannya selama dua tahun (LTS) atau enam tahun (LTS diperpanjang). Ini direka untuk mempunyai produk yang memerlukan kestabilan (seperti telefon Android atau peranti IOT lain). Prosesnya adalah sama seperti di atas, ia hanya berlaku untuk masa yang lebih lama. Pada masa ini terdapat enam biji LTS (yang boleh dilihat pada halaman siaran kernel.org):

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

Apakah faedah pengumuman kernel Android saya ke Stable Linux?

Apabila kelemahan penting didedahkan / tetap, biji yang stabil adalah yang pertama untuk mendapatkannya. Oleh itu, kernel Android anda akan menjadi lebih selamat terhadap serangan, kecacatan keselamatan, dan hanya bug secara umum.

Stabil Linux termasuk pembaikan untuk banyak pemacu peranti Android saya tidak digunakan, bukannya kebanyakannya tidak perlu?

Ya dan tidak, bergantung pada cara anda menentukan "kebanyakannya". Kernel Linux mungkin termasuk banyak kod yang tidak digunakan dalam sistem Android, tetapi itu tidak menjamin tidak ada konflik dari fail tersebut ketika menggabungkan versi baru! Memahami bahawa hampir tiada siapa yang membina setiap bahagian kernel, bahkan tidak ada distro Linux yang paling biasa seperti Ubuntu atau Mint. Ini tidak bermakna anda tidak patut mengambil perbaikan ini kerana terdapat perbaikan untuk pemandu yang anda laksanakan. Ambil senjata / arm64 dan ext4 sebagai contoh, yang merupakan seni bina dan sistem fail Android yang paling biasa. Dalam 4.4, dari 4.4.78 (versi tag Oreo CAF terkini) kepada 4.4.121 (tag hulu terkini), ini adalah nombor berikut untuk para pembuat sistem tersebut:

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

Bahagian yang paling memakan masa adalah pembukaan awal; sebaik sahaja anda semua up to date, ia tidak mengambil masa untuk menggabungkan pelepasan baru, yang biasanya mengandungi tidak lebih daripada 100 komited. Faedah-faedah yang dibawa oleh ini (kestabilan dan keselamatan yang lebih baik untuk pengguna anda) semestinya memerlukan proses ini.

Bagaimana Menggabungkan Kernel Stabil Linux ke Kernel Android

Pertama, anda perlu memikirkan versi kernel yang mana peranti Android anda sedang berjalan.

Seperti yang sepele seperti ini, perlu diketahui di mana anda perlu bermula. Jalankan arahan berikut dalam pokok kernel anda:

 buat kernelversion

Ia akan kembali semula versi yang anda sedang aktif. Dua nombor pertama akan digunakan untuk mengetahui cawangan yang anda perlukan (cth. Linux-4.4.y untuk mana-mana kernel 4.4) dan nombor terakhir akan digunakan untuk menentukan versi yang perlu anda mulakan dengan penggabungan (contohnya jika anda berada pada 4.4 .21, anda akan menggabungkan 4.4.22 seterusnya).

Dapatkan sumber kernel terbaru dari kernel.org

kernel.org menempatkan sumber kernel terkini dalam repositori linux-stabil. Di bahagian bawah halaman itu, terdapat tiga pautan yang diambil. Dalam pengalaman saya, cermin Google cenderung menjadi yang terpantas tetapi keputusan anda mungkin berbeza-beza. Jalankan arahan berikut:

 remote git menambah linux-stabil //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit fetch linux-stable

Tentukan jika anda ingin menggabungkan keseluruhan kernel atau ceri-pilih komit tersebut

Seterusnya, anda perlu memilih jika anda mahu menggabungkan komit atau ceri. Inilah kebaikan dan keburukan masing-masing dan apabila anda mungkin mahu melakukannya.

NOTA: Sekiranya sumber kernel anda berupa tarball, anda mungkin perlu mengambil ceri, jika tidak, anda akan mendapat beribu-ribu konflik fail kerana git memunggah sejarah berasaskan semata-mata di hulu, bukan apa yang OEM atau CAF mempunyai berubah. Hanya langkau ke langkah 4.

Memetik ceri:

Kelebihan:

Lebih mudah menyelesaikan konflik seperti yang anda tahu dengan tepat apa konflik yang menyebabkan masalah.
Lebih mudah untuk menegur kerana setiap komit sendiri.
Lebih mudah untuk membantah jika menghadapi masalah

Keburukan:

Ia mengambil masa yang lebih lama kerana setiap komit terpaksa dipilih secara individu.
Sedikit lebih sukar untuk mengetahui jika komitmen dari hulu pada pandangan pertama

Gabung

Kelebihan :

Lebih cepat kerana anda tidak perlu menunggu semua patch bersih untuk bergabung.
Lebih mudah untuk melihat apabila komitmen adalah dari hulu kerana anda tidak akan menjadi penasihat, penyelenggara hulu akan.

Keburukan:

Menyelesaikan konflik boleh jadi lebih sukar kerana anda perlu mencari komit yang menyebabkan konflik menggunakan git log / git disalahkan, ia tidak akan memberitahu anda secara langsung.
Rebasing adalah sukar kerana anda tidak dapat menegaskan gabungan, ia akan menawarkan kepada cherry-pick semua komitmen secara individu. Walau bagaimanapun, anda tidak sepatutnya rebat, sebaliknya menggunakan git revert dan git bergabung sekiranya mungkin.

Saya akan mengesyorkan membuat ceri-ceri untuk mengetahui konflik masalah pada mulanya, melakukan penggabungan, kemudian mengembalikan masalah tersebut setelah itu supaya pengemaskinian adalah lebih mudah (sebagai penggabungan lebih cepat selepas dikemas kini).

Tambah komit ke sumber anda, satu versi pada satu masa

Bahagian yang paling penting dalam proses ini ialah satu versi pada satu masa. TIDAK ADA menjadi patch masalah dalam siri huluan anda, yang boleh menyebabkan masalah dengan boot atau memecahkan sesuatu seperti bunyi atau pengecasan (diterangkan dalam bahagian tips dan trik). Melakukan perubahan versi tambahan adalah penting untuk sebab ini, lebih mudah untuk mencari isu dalam 50 komit daripada 2000 ke atas untuk beberapa versi. Saya hanya akan mencadangkan melakukan penggabungan penuh sebaik sahaja anda mengetahui semua masalah yang berlaku dan resolusi konflik.

Memetik ceri

Format:

 git cherry-pick ..

Contoh:

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

Gabung

Format:

 gab bergabung

Contoh:

git bergabung v3.10.74

Saya cadangkan mengesan konflik dalam menggabungkan dengan menghapuskan penanda #.

Bagaimana Menyelesaikan Konflik

Kami tidak dapat memberikan panduan langkah demi langkah untuk menyelesaikan setiap konflik, kerana ia melibatkan pengetahuan yang baik tentang bahasa C, tetapi inilah beberapa petanda.

Sekiranya anda sedang menggabungkan, ketahui apa komit yang menyebabkan konflik itu. Anda boleh melakukan salah satu daripada dua cara ini:

git log -pv $ (buat kernelversion) .. untuk mendapatkan perubahan antara versi semasa anda dan terbaru dari hulu. Bendera -p akan memberi anda perubahan yang dilakukan oleh setiap komit supaya anda dapat melihatnya.
Jalankan menyalahkan fail pada fail untuk mendapatkan hash setiap komit di kawasan tersebut. Anda kemudian dapat menjalankan git show -format = fuller untuk melihat apakah pengirim itu dari mainline / stabil, Google, atau CodeAurora.

Perhatikan jika anda sudah mempunyai komit. Sesetengah vendor seperti Google atau CAF akan cuba mencari hulu untuk kritikal kritikal, seperti pembaikan Kotor Kotor, dan backport mereka boleh bertentangan dengan hulu. Anda boleh menjalankan git log -grep = "" dan lihat jika ia mengembalikan apa-apa. Sekiranya ia berlaku, anda boleh melangkau komit (jika memilih ceri menggunakan git reset -hard && git cherry-pick-continue) atau mengabaikan konflik (tanggalkan <<<<< >>>>>).
Perhatikan jika terdapat backport yang merosakkan resolusi. Google dan CAF suka menyokong beberapa patch tertentu yang tidak stabil. Stabil selalunya perlu menyesuaikan resolusi komik utama kepada ketidakcocokan patch tertentu yang Google memilih untuk backport. Anda boleh melihat komik utama dengan menjalankan pertunjukan git (hash baris utama akan tersedia dalam mesej komit komit stabil). Sekiranya terdapat backport yang mengaitkannya, anda boleh membuang perubahan atau anda boleh menggunakan versi utama (yang biasanya perlu dilakukan).
Bacalah apa yang sedang dilakukan oleh komit dan lihat jika masalah itu telah ditetapkan. Kadang-kadang CAF boleh menetapkan pepijat bebas dari hulu, bermakna anda boleh menulis ganti mereka untuk hulu atau membuangnya, seperti di atas.

Jika tidak, ini mungkin hasil dari tambahan CAF / Google / OEM, dalam hal ini anda hanya perlu mengosongkan beberapa perkara di sekitar.

Berikut adalah cermin dari repositori kernel.org linux-stabil di GitHub, yang boleh menjadi lebih mudah untuk mencari senarai komit dan diffs untuk resolusi konflik. Saya cadangkan pergi ke senarai senarai komit terlebih dahulu dan cari komit masalah untuk melihat diff asli untuk membandingkannya dengan anda.

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

Anda juga boleh melakukannya melalui baris arahan:

 git log .. git menunjukkan

Menyelesaikan resolusi adalah mengenai konteks. Apa yang anda SELALU lakukan adalah pastikan perbezaan akhir anda sepadan dengan hulu dengan menjalankan perintah berikut dalam dua tingkap berasingan:

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

Dayakan semula

Git mempunyai ciri yang dipanggil rerere (bermaksud Resolusi Direkodkan Semula), yang bermaksud bahawa apabila ia mengesan konflik, ia akan merakamkan cara anda menyelesaikannya supaya anda dapat menggunakannya semula kemudian. Ini amat berguna untuk penembakan kronik dengan penggabungan dan pengambilan ceri kerana anda hanya perlu menjalankan git add. && git-lanjutkan apabila merombak upup hulu apabila konflik akan diselesaikan bagaimana anda telah memutuskannya sebelumnya.

Ia boleh diaktifkan dengan menjalankan arahan berikut dalam repo kernel anda:

 git config rerere.enabled benar

Bagaimana untuk bisect apabila berjalan menjadi ralat pengompil atau runtime

Memandangkan anda akan menambah jumlah yang banyak komited, sangat mungkin bagi anda untuk memperkenalkan pengompilasi atau ralat runtime. Daripada melepaskan diri, anda boleh menggunakan alat bisect terbina dalam git untuk mengetahui sebab utama isu ini! Sebaik-baiknya, anda akan membina dan berkelip setiap versi kernel semasa anda menambahnya sehingga bisecting akan mengambil sedikit masa jika diperlukan tetapi anda boleh bisect 5000 commits tanpa sebarang masalah.

Apa yang akan dilakukan oleh git bisect adalah mengambil pelbagai komitmen, dari mana masalah itu hadir ke tempat ia tidak hadir, dan kemudian mula mengurangkan separuh komit, membolehkan anda membina dan menguji dan memaklumkannya jika ia bagus atau tidak . Ia akan meneruskannya sehingga ia meletupkan komit yang menyebabkan masalah anda. Pada ketika itu, anda boleh memperbaikinya atau mengembalikannya.

Mula bisecting: git bisect bermula
Label semakan semasa sebagai buruk: git bisect tidak baik
Label semakan sebagai baik: git bisect baik
Bina dengan semakan baru
Berdasarkan hasil (jika isu itu hadir atau tidak), beritahu git: git bisect baik ATAU git bisect buruk
Bilas dan ulang langkah 4-5 sehingga komit masalah ditemui!
Kembalikan atau tentukan masalah yang dilakukan.

NOTA: Penggabungan perlu untuk sementara menjalankan git rebase -i untuk memohon semua patch ke cawangan anda untuk bisecting yang betul, kerana bisecting dengan penggabungan di tempat akan sering kali checkout ke hulu commits, bermakna anda tidak mempunyai komitmen khusus Android. Saya boleh masuk lebih mendalam atas permintaan ini tetapi percaya kepada saya, ia diperlukan. Sebaik sahaja anda telah mengenal pasti komit masalah, anda boleh mengembalikan atau menyahsulitnya ke dalam penggabungan.

Jangan kemasukan hulu ke atas

Banyak pemaju baru tergoda untuk melakukan ini kerana ia "bersih" dan "lebih mudah" untuk diurus. Ini dahsyat kerana beberapa sebab:

Penulisan hilang. Tidak adil kepada pemaju lain untuk mendapatkan kredit mereka untuk kerja mereka.
Bisecting adalah mustahil. Sekiranya anda membuat beberapa siri komitmen dan sesuatu yang menjadi isu dalam siri itu, mustahil untuk memberitahu apa komit menyebabkan masalah dalam skuasy.
Masa ceri ceri lebih sukar. Sekiranya anda perlu menegaskan dengan siri yang tergendala, sukar / mustahil untuk memberitahu di mana konflik berlaku.

Langgan senarai mel Kernel Linux untuk kemas kini yang tepat pada masanya

Untuk mendapatkan pemberitahuan apabila terdapat kemas kini hulu, langganlah senarai linux-kernel-announce. Ini akan membolehkan anda mendapatkan e-mel setiap kali kernel baru dilepaskan supaya anda boleh mengemas kini dan menolak secepat mungkin.