nasıl

Android Çekirdeğinizi En Son Linux Kararlı Olarak Güncelleme

“Özel Bir Çekirdeğin Nasıl Yapılacağı” ve “Android için En İyi Özel Çekirdekler” gibi Android çekirdeğindeki kılavuzları ele aldık, ancak bugün size en son Linux kararlıına karşı çekirdeğinizi nasıl yukarı çekeceğinizi göstereceğiz.

Lütfen bunun gelişmiş bir şey olduğunu unutmayın - daha önce hiç bir çekirdeği derlemediyseniz, yukarıda bağlanmış olan “Özel Bir Çekirdeğin Nasıl Yapılacağı” kılavuzunu izlemelisiniz ve bu rehber en son Linux’tan kiraz toplama ve birleştirme işlemlerini içerecektir. Derlemeden önce Android çekirdeğinizle sabit çekirdek.

Android çekirdeğinizi en son Linux kararlılarına yükseltmek, en son güvenlik görevlileri ve hata düzeltmeleri konusunda güncel olmak gibi birçok olumlu avantaj sağlar - bu kılavuzun ilerleyen kısımlarında bazı artıları ve eksileri açıklayacağız.

Linux-Stabil çekirdek nedir?

Adından da anlaşılacağı gibi Linux kararlı, Linux çekirdeğinin kararlı kolu. Diğer kol ana dal olan “ana hat” olarak bilinir. Tüm Linux çekirdeği gelişimi ana hatta gerçekleşir ve genellikle bu süreci takip eder:

Linus Torvalds, iki hafta boyunca bakıcılarından bir sürü yama alacak.
Bu iki haftadan sonra, bir rc1 (örneğin 4.14-rc1) çekirdeği serbest bırakır.
Önümüzdeki 6-8 hafta boyunca her hafta, SADECE hata ve regresyon düzeltmeleri içeren başka bir RC (örneğin 4.14-rc2, 4.14-rc3, vb.) Çekirdeği serbest bırakacak.
Kararlı olarak kabul edildikten sonra, org'da indirilmek üzere tarball olarak yayınlanacaktır (ör. 4.14).

LTS çekirdekleri nedir?

Her yıl Greg bir çekirdeği seçip iki yıl (LTS) veya altı yıl (uzatılmış LTS) olarak koruyacak. Bunlar kararlılık gerektiren ürünlere sahip olacak şekilde tasarlanmıştır (Android telefonlar veya diğer IOT cihazları gibi). İşlem yukarıdaki ile aynıdır, sadece daha uzun bir süre gerçekleşir. Halen altı LTS çekirdeği vardır (bunlar her zaman kernel.org sürümleri sayfasında görülebilir):

4.14 (LTS), Greg Kroah-Hartman tarafından sürdürüldü
4.9 (LTS), Greg Kroah-Hartman tarafından sağlanmıştır
4.4 (eLTS), Greg Kroah-Hartman tarafından sağlanmıştır
4.1 (LTS), Sasha Levin tarafından sağlanmıştır
3.16 (LTS), Ben Hutchings tarafından sağlanmıştır.
3.2 (LTS), Ben Hutchings tarafından sağlanmıştır

Android çekirdeğimi Linux Stable'a aktarmanın faydaları nelerdir?

Önemli güvenlik açıkları açıklandığı / düzeltildiği zaman, kararlı çekirdekler onları ilk alanlardandır. Böylece, Android çekirdeğiniz saldırılara, güvenlik kusurlarına ve genel olarak sadece böceklere karşı çok daha güvenli olacaktır.

Linux kararlı, Android cihazımın kullanmadığı birçok sürücü için düzeltmeler içeriyor, bu çoğunlukla gereksiz değil mi?

Evet ve hayır, “çoğunlukla” nasıl tanımladığınıza bağlı olarak. Linux çekirdeği, Android sisteminde kullanılmayan birçok kod içerebilir, ancak bu, yeni sürümleri birleştirirken bu dosyalardan hiçbir çelişki olmayacağını garanti etmez! Neredeyse hiç kimsenin Ubuntu veya Mint gibi en yaygın Linux dağıtımlarını bile değil, çekirdeğin her bir bölümünü oluşturmadığını anlayın. Bu, bu düzeltmeleri yapmamanız gerektiği anlamına gelmez, çünkü çalıştırdığınız sürücüler için ARE düzeltmeleri vardır. Örneğin, sırasıyla en yaygın Android mimarisi ve dosya sistemi olan arm / arm64 ve ext4 kodlarını kullanın. 4.4'te 4.4.78'den (en son Oreo CAF etiketinin sürümü) 4.4.121'e (en son giriş etiketi) kadar), bunlar, bu sistemlerin taahhütleri için aşağıdaki sayılardır:

 ~ / çekirdek / linux-kararlı (ana) $ git log --format =% h v4.4.78..v4.4.121 | wc -2285 ~ / çekirdek / linux-kararlı (ana) $ git günlüğü - biçim =% h v4.4.78..v4.4.121 kemer / kol | wc -l58 ~ / çekirdek / linux-kararlı (ana) $ git log --format =% h v4.4.78..v4.4.121 kemer / arm64 | wc -l22 ~ / çekirdek / linux-kararlı (ana) $ git log --format =% h v4.4.78..v4.4.121 fs / ext4 | wc -l18

En fazla zaman alan kısım ilk başlangıçtır; Tamamen güncel olduğunuzda, genellikle 100'den fazla taahhüt içermeyen yeni bir sürümde bir araya gelmek hiç zaman almaz. Bunun getirdiği faydalar (kullanıcılarınız için daha fazla istikrar ve daha iyi güvenlik) bu süreci zorunlu kılmalıdır.

Linux Kararlı Çekirdeğini Android Çekirdeğinde Birleştirme

Öncelikle Android cihazınızın hangi çekirdek versiyonunun çalıştığını bulmanız gerekiyor.

Bu kadar önemsiz göründüğü gibi, nereden başlamanız gerektiğini bilmek gerekir. Çekirdek ağacınızda aşağıdaki komutu çalıştırın:

 çekirdeği yapmak

Bulunduğunuz sürümü geri döndürür. İhtiyacınız olan dalı bulmak için ilk iki sayı (örneğin, herhangi bir 4.4 çekirdeği için linux-4.4.y) ve birleştirmeye başlamak için hangi sürüme ihtiyacınız olduğunu belirlemek için son sayı kullanılacaktır (ör. 4.4. .21, sonra 4.4.22 birleştireceksiniz).

Kernel.org sitesinden en son çekirdek kaynağını alın.

kernel.org, linux-istikrarlı havuzdaki en son çekirdek kaynağını barındırmaktadır. Bu sayfanın altında, üç getirme bağlantısı olacaktır. Tecrübelerime göre, Google'ın aynası en hızlı olma eğilimindedir, ancak sonuçlarınız farklılık gösterebilir. Aşağıdaki komutları çalıştırın:

 git uzak linux-kararlı eklemek //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit

Çekirdeğin tamamını birleştirmek mi yoksa kiralamayı seçmek mi istediğinize karar verin.

Daha sonra, komisyonları birleştirmek ya da kiraz toplama yapmak isteyip istemediğinizi seçmeniz gerekir. İşte her birinin avantajları ve dezavantajları ve ne zaman yapmak isteyebilirsiniz.

NOT: Çekirdek kaynağınız bir tarball biçimindeyse, büyük olasılıkla kiraz toplama işlemi yapmanız gerekecek, aksi takdirde git, yalnızca OEM veya CAF’nın ne yaptığı değil, tam tersine dayalı olarak doldurduğu için binlerce dosya çakışması alırsınız. değişti. Sadece 4. adıma atlayın.

Kiraz toplama:

Artıları:

Hangi sorunun hangi soruna yol açtığını bildiğiniz gibi anlaşmazlıkları çözmek daha kolaydır.
Her bir taahhüt kendi başına olduğu için yeniden kazanılması daha kolaydır.
Sorunla karşılaşırsanız parçalanması daha kolaydır

Eksileri:

Her bir işin bireysel olarak seçilmesi gerektiğinden daha uzun sürer.
İlk bakışta taahhüdün yukarı yönde olup olmadığını söylemek biraz daha zor

birleşmek

Artıları :

Tüm temiz yamaların birleşmesini beklemeniz gerekmediğinden daha hızlıdır.
Bir taahhüdün ne zaman üstlenimden geldiğini görmek daha kolay olacaktır, çünkü siz bir girişimci olmayacaksınız;

Eksileri:

Çatışmaları çözmek biraz daha zor olabilir, çünkü hangi işlemin git log / git suçunu kullanarak çakışmaya neden olduğuna bakmak gerekir, doğrudan size söylemez.
Yeniden birleştirme, yeniden birleştirme yapamayacağınız için zordur, tüm taahhütleri ayrı ayrı seçmeyi teklif eder. Ancak, sık sık yeniden doğramamanız gerekir, bunun yerine mümkün olduğunda git geri alma ve git birleştirme kullanılır.

Başlangıçta herhangi bir sorunla çakışmak için bir seçim yapmayı, bir birleştirme yapmayı, sonra sorunu geri almayı öneririm, böylece güncelleme daha kolaylaşır (birleşme, güncel olduktan sonra daha hızlı olduğu için).

Her seferinde bir sürüm olmak üzere kaynağınıza taahhütleri ekleyin.

Bu sürecin en önemli kısmı, bir zaman dilimindeki tek versiyondur. Giriş dizinizde, önyükleme veya ses veya şarj etme gibi bir şeyi önyükleme veya bozulma ile sonuçlanabilecek bir sorun olabilir (ipuçları ve püf noktaları bölümünde açıklanmıştır). Artımlı sürüm değişiklikleri yapmak bu nedenle önemlidir, 50 sürümde bir sayı bulmak, bazı sürümler için 2000'den fazla olan verilere göre daha kolaydır. Tüm sorunun birleştiğini ve kararların çözüldüğünü öğrendikten sonra tam bir birleştirme yapmanızı tavsiye ederim.

Kiraz toplama

Biçim:

 git cherry-pick ..

Örnek:

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

birleşmek

Biçim:

 git birleştirme

Örnek:

git birleştirme v3.10.74

# İşaretleyicilerini kaldırarak birleştirme işlemlerinde çakışmaları takip etmenizi öneririz.

Çatışmalar Nasıl Çözülür?

Her bir anlaşmazlığın çözümü için adım adım rehber veremeyiz, çünkü C dilini iyi bir şekilde biliyordur, ancak işte birkaç ipucu.

Birleşiyorsanız, çatışmaya hangi bağlılığın yol açtığını anlayın. Bunu iki yoldan biriyle yapabilirsiniz:

git log -pv $ (kernelversion yapın) .. geçerli sürümünüz ile yukarı akıştan en son sürüm arasındaki değişiklikleri almak için. -P bayrağı size görebilmeniz için her bir taahhütte yapılan değişiklikleri verecektir.
Alandaki her işlenişin karmasını almak için dosyadaki git suçunu çalıştırın. Ardından, alıcının ana hat / kararlı, Google veya CodeAurora'dan olup olmadığını görmek için git show –format = fuller komutunu çalıştırabilirsiniz.

Zaten bir taahhüdünüz olup olmadığını anlayın. Google veya CAF gibi bazı satıcılar, Dirty COW düzeltmesi gibi kritik hatalar için yukarı doğru bakmaya çalışacak ve destekleri yukarı akış ile çelişebilir. Git log –grep = ”” komutunu çalıştırabilir ve bir şey döndürüp döndürmediğini görebilirsiniz. Eğer öyleyse, taahhüdü atlayabilirsiniz (eğer git reset -hard && git cherry-pick-continue kullanarak kiraz toplama) veya çakışmaları görmezden gelebilirsiniz (<<<<< >>>>> 'yi kaldırın).
Çözünürlüğü bozan bir destek olup olmadığını anlayın. Google ve CAF, istikrarlı olmayan bazı yamaları desteklemeyi sever. Kararlı, genellikle Google’ın desteklemeyi seçtiği bazı yamaların eksikliğine bağlı olan ana hattın çözünürlüğünü uyarlamak zorunda kalacaktır. Git şovu çalıştırarak ana çizgi taahhüdüne bakabilirsiniz (ana çizgi karmaşanın kararlılık mesajında mevcut olacaktır). Bunu bozan bir destek varsa, değişiklikleri kaldırabilir veya ana hat sürümünü kullanabilirsiniz (bu genellikle yapmanız gerekenler).
Taahhüdün ne yapmaya çalıştığını okuyun ve sorunun çözülüp çözülmediğini görün. Bazen CAF, yukarı akıştan bağımsız bir hatayı düzeltebilir, bu da yukarı akış için düzeltmelerinin üzerine yazabilir veya yukarıdaki gibi atabilirsiniz.

Aksi halde, yalnızca CAF / Google / OEM eklemesinin bir sonucu olabilir, bu durumda bazı şeyleri karıştırmanız yeterlidir.

İşte, kararlı listelerde arama yapmak için daha kolay olabilen ve uyuşmazlıkların çözümü için farklı olabilecek GitHub'daki linux-kararlı kernel.org deposunun bir aynası. Öncelikle değerlendirme listesi görünümüne gitmenizi ve orijinal farkı sizinkiyle karşılaştırmak için orijinal farkı görmeyi taahhüt etmeyi öneriyorum.

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

Ayrıca komut satırı üzerinden de yapabilirsiniz:

 git günlüğü .. git göster

Kararları çözmek tamamen bağlamla ilgilidir. HER ZAMAN yapmanız gereken, aşağıdaki komutları iki ayrı pencerede çalıştırarak son farkınızın yukarı akış ile eşleştiğinden emin olmaktır:

 git diff HEAD git diff v $ (çekirdeği değiştir) .. $ (git etiketi --sort = -taggerdate -lv $ (çekirdeği değiştir | cut -d. -f 1, 2) * | head -n1)

Tekrar etkinleştir

Git, rerere (Yeniden Kayıtlı Çözünürlük Yeniden Kullanımı) anlamına gelen bir özelliğe sahiptir, yani bir çakışma algıladığında, nasıl çözdüğünüzü kaydeder, böylece daha sonra yeniden kullanabilirsiniz. Bu, özellikle sadece git add komutunu çalıştırmanız gerekeceğinden, birleştirme ve kiraz toplama işlemleriyle hem kronik yeniden donatıcılar için faydalıdır. && git –çevaşki olayın yeniden yapılması sırasında devam etmekte, çünkü çatışma daha önce çözdüğünüz şekilde çözülecektir.

Çekirdek deponuzda aşağıdaki komutu çalıştırarak etkinleştirilebilir:

 git config rerere.enabled true

Bir derleyici veya çalışma zamanı hatasıyla çalışırken git bisect nasıl yapılır

Oldukça fazla sayıda taahhüt ekleyeceğiniz göz önüne alındığında, bir derleyici veya çalışma zamanı hatası vermeniz çok olasıdır. Sadece vazgeçmek yerine, sorunun nedenini bulmak için git'in yerleşik ikiye ayırma aracını kullanabilirsiniz! İdeal olarak, her bir çekirdek sürümünü oluşturacak ve yanıp söneceksin, eklediğiniz için ikiye böldüğünüzde, gerektiğinde daha az zaman alacaktır, ancak 5000 adet ürün için herhangi bir sorun olmadan ikiye katlayabilirsiniz.

Git bisect'in yapacağı şey, sorunun mevcut olmadığı yerden mevcut olduğu yerden bir dizi taahhüt almak ve sonra iyi olup olmadığını anlamak ve test etmek ve test etmek için izin vermek için işlem aralığını yarıya indirmek . Soruna neden olan taahhüdü tükenene kadar bu devam edecek. Bu noktada, düzeltebilir veya geri alabilirsiniz.

İkiye ayırmaya başla: git bisect start
Mevcut düzeltmeyi kötü olarak etiketleyin: git bisect bad
Bir düzeltmeyi iyi olarak etiketleyin: git bisect good
Yeni revizyon ile inşa et
Sonuca göre (eğer sorun mevcutsa veya olmasın) git söyle: git bisect iyi VEYA git bisect kötü
Durulayın ve sorun çözme işlemi bulunana kadar 4-5 arasındaki adımları tekrarlayın!
Geri al ya da sorunu çöz.

NOT: Birleşmelerin, tüm yamaları uygun ikiye ayırma için şubenize uygulamak için git rebase -i'yi geçici olarak çalıştırmaları gerekecektir, zira yerinde birleştirme ile yapılan ikiye ayırma işlemi genellikle Android'in taahhüt ettiği hiçbir işlemin olmadığı anlamına gelir. Talep üzerine bu konuda daha derinlemesine gidebilirim ama güven bana, gerekli. Sorunun çözüldüğünü belirledikten sonra, geri döndürebilir veya yeniden birleştirebilirsiniz.

Yukarı akış güncellemelerini ezmeyin

Pek çok yeni geliştirici bunu “temizleyici” ve “kolay” olduğu için yapmaya özendirdi. Bu birkaç nedenden dolayı korkunç:

Yazarlık kayboldu. Diğer geliştiricilerin çalışmaları için kredilerini almaları haksızlıktır.
İkiye bölmek imkansızdır. Eğer bir dizi taahhüdü eziyorsanız ve bir şey bu serideki bir sorundur, bir kararmanın bir squashta bir soruna neden olduğunu söylemek imkansızdır.
Gelecek kiraz-seçtikleri daha zordur. Eğer ezilmiş bir seriyle yeniden derlemek gerekirse, bir çatışmanın nereden çıktığını söylemek zor / imkansızdır.

Zamanında güncellemeler için Linux Çekirdeği posta listesine abone olun

Bir güncelleme olduğunda ne zaman haberdar olun, linux-çekirdek-anons listesine abone olun. Bu, yeni bir çekirdek piyasaya sürüldüğünde bir e-posta almanıza olanak tanır; böylece olabildiğince hızlı bir şekilde güncelleme ve gönderme yapabilirsiniz.