cum să

Cum să actualizați kernel-ul dvs. Android la cea mai recentă unitate de Linux

Am acoperit ghiduri pentru nuclee Android, cum ar fi „Cum să construiți un nucleu personalizat” și „Cele mai bune kerneluri personalizate pentru Android”, dar astăzi vă vom arăta cum să vă conectați kernel-ul împotriva celui mai recent stabil Linux.

Vă rugăm să știți că acestea sunt lucruri avansate - dacă nu ați compilat niciodată un nucleu înainte, ar trebui să urmați ghidul „Cum se construiește un nucleu personalizat” legat mai sus, iar acest ghid va implica comisioane de culegere de cireșe și comasare de la cele mai recente Linux- kernel stabil cu nucleul tău Android înainte de al compila.

Îmbunătățirea nucleului Android la cel mai recent stabil Linux are o mulțime de beneficii pozitive, cum ar fi să fiți la curent cu cele mai recente comitete de securitate și bug-uri - vom explica unele dintre avantajele și contra în continuare în acest ghid.

Ce este nucleul stabil Linux?

Linux-stabil, după cum sugerează și numele este brațul stabil al nucleului Linux. Celălalt braț este cunoscut sub numele de „mainline”, care este ramura principală . Toată dezvoltarea nucleului Linux se întâmplă în linia principală și, în general, urmează acest proces:

Linus Torvalds va lua o grămadă de patch-uri de la agenții săi de întreținere timp de două săptămâni.
După aceste două săptămâni, el eliberează un nucleu rc1 (de exemplu, 4.14-rc1).
Pentru fiecare săptămână pentru următoarele 6-8 săptămâni, el va elibera un alt nucleu RC (de exemplu, 4.14-rc2, 4.14-rc3, etc), care conține NUMAI remedieri de erori și de regresie.
Odată ce este considerat stabil, acesta va fi lansat ca tarball pentru descărcare pe org (de exemplu 4.14).

Ce sunt sâmburele LTS?

În fiecare an, Greg va alege un nucleu și îl va întreține fie pentru doi ani (LTS), fie pentru șase ani (LTS extins). Acestea sunt concepute pentru a avea produse care au nevoie de stabilitate (cum ar fi telefoanele Android sau alte dispozitive IOT). Procesul este exact ca mai sus, se întâmplă doar pentru o perioadă mai lungă de timp. În prezent, există șase nuclee LTS (care pot fi vizualizate întotdeauna pe pagina de lansare a kernel.org):

4.14 (LTS), menținut de Greg Kroah-Hartman
4.9 (LTS), menținută de Greg Kroah-Hartman
4.4 (eLTS), menținut de Greg Kroah-Hartman
4.1 (LTS), menținută de Sasha Levin
3.16 (LTS), menținută de Ben Hutchings
3.2 (LTS), menținut de Ben Hutchings

Care sunt avantajele extinderii kernelului meu Android în Linux Stable?

Când sunt dezvăluite / fixate vulnerabilități importante, nucleele stabile sunt primele care le obțin. Astfel, nucleul tău Android va fi mult mai sigur împotriva atacurilor, a defectelor de securitate și doar a erorilor în general.

Stabilul Linux include corecții pentru o mulțime de drivere pe care dispozitivul meu Android nu le folosește, nu este in general inutil?

Da și nu, în funcție de cum definiți „mai ales”. Nucleul Linux poate include o mulțime de coduri care nu sunt utilizate în sistemul Android, dar acest lucru nu garantează că nu vor exista conflicte din aceste fișiere atunci când fuzionează versiuni noi! Înțelegeți că practic nimeni nu construiește fiecare parte a kernelului, nici măcar cele mai frecvente distros Linux precum Ubuntu sau Mint. Acest lucru nu înseamnă că nu ar trebui să luați aceste corecții, deoarece există corecții pentru driverele pe care le executați. Luăm arm / arm64 și ext4, de exemplu, care sunt arhitectura Android și respectiv sistemul de fișiere Android. În 4.4, de la 4.4.78 (versiunea cea mai recentă etichetă Oreo CAF) până la 4.4.121 (ultima etichetă în amonte), acestea sunt următoarele numere pentru comiterile acestor sisteme:

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

Cea mai mare parte a timpului este aducerea inițială; odată ce sunteți la curent, nu mai este nevoie deloc de timp să vă îmbinați într-o nouă versiune, care de obicei nu conține mai mult de 100 de angajamente. Cu toate acestea, beneficiile pe care acestea le aduc (mai multă stabilitate și o mai bună securitate pentru utilizatorii dvs.) ar trebui să necesite acest proces.

Cum să îmbinați Kernel stabil în Linux într-un nucleu Android

În primul rând, trebuie să vă dați seama ce versiune de kernel rulează dispozitivul dvs. Android.

Oricât de banal pare acest lucru, este necesar să știți de unde trebuie să începeți. Executați următoarea comandă în arborele de nucleu:

 faceți nucleu

Va reveni versiunea pe care o activați. Primele două numere vor fi folosite pentru a descoperi ramura de care aveți nevoie (de exemplu linux-4.4.y pentru orice nucleu 4.4), iar ultimul număr va fi utilizat pentru a determina ce versiune trebuie să începeți cu fuziunea (de exemplu, dacă sunteți pe 4.4 .21, veți îmbina 4.4.22 în continuare).

Prinde cea mai recentă sursă de kernel de pe kernel.org

kernel.org găzduiește cea mai recentă sursă de kernel din depozitul linux-stabil. În partea de jos a acestei pagini, vor exista trei link-uri de preluare. În experiența mea, oglinda Google are tendința de a fi cea mai rapidă, dar rezultatele tale pot varia. Executați următoarele comenzi:

 git remote adăugați linux-stable //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit fetch linux-stable

Decideți dacă doriți să îmbinați întregul sâmbure sau cireșe-alegeți angajamentele

În continuare, va trebui să alegeți dacă doriți să îmbinați comitele sau cireșele. Iată argumentele pro și contra fiecăruia și când poate doriți să le faceți.

NOTĂ: Dacă sursa dvs. de sâmbure este sub formă de tarball, cel mai probabil va trebui să alegeți cherry-pick, altfel veți primi mii de conflicte de fișiere, deoarece git populează istoria bazată pur pe amonte, nu pe ceea ce OEM sau CAF are. schimbat. Treci la pasul 4.

Cherry-picking:

Pro:

Mai ușor de rezolvat conflictele, deoarece știi exact ce conflict provoacă o problemă.
Mai ușor de rambursat, deoarece fiecare angajament este pe cont propriu.
Mai ușor de bifat dacă aveți probleme

Contra:

Durează mai mult, deoarece fiecare angajament trebuie ales individual.
Puțin mai greu de spus dacă angajamentul este din amonte la prima vedere

contopi

Pro :

Este mai rapid, deoarece nu trebuie să aștepți ca toate patch-urile curate să se contopească.
Este mai ușor să vedeți când un angajament este din amonte, deoarece nu veți fi emițătorul, întreținerea din amonte va fi.

Contra:

Rezolvarea conflictelor poate fi ceva mai dificilă, întrucât va trebui să căutați care angajează cauzează conflictul folosind git log / git blame, nu vă va spune direct.
Răsturnarea este dificilă, deoarece nu puteți rambursa o contopire, aceasta va oferi pentru a culege toate cerințele în mod individual. Cu toate acestea, nu ar trebui să revanșezi des, în schimb, folosind git revert și git merge, unde este posibil.

V-aș recomanda să faceți o cireșă pentru a descoperi inițial conflictele cu probleme, să faceți o fuziune, apoi să reveniți la comiterea problemelor după aceea, actualizarea este mai ușoară (deoarece fuzionarea este mai rapidă după actualizare).

Adăugați angajamentele la sursa dvs., o versiune simultan

Cea mai importantă parte a acestui proces este versiunea unică. Poate exista un patch-ul problemelor din seria dvs. din amonte, care ar putea cauza o problemă cu pornirea sau ruperea ceva ca sunetul sau încărcarea (explicate în secțiunea Sfaturi și trucuri). Efectuarea unor modificări de versiune incrementală este importantă din acest motiv, este mai ușor să găsiți o problemă în 50 de comiteri decât peste 2000 de comisioane pentru unele versiuni. Aș recomanda să faceți o fuziune completă numai după ce cunoașteți toate problemele comise și soluționarea conflictelor.

Cherry-cules

Format:

 git cherry-pick ..

Exemplu:

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

contopi

Format:

 git merge

Exemplu:

git merge v3.10.74

Recomand să urmăriți conflictele în comisioanele de îmbinare prin eliminarea marcajelor #.

Cum să rezolvi conflictele

Nu putem oferi un ghid pas cu pas pentru soluționarea fiecărui conflict, deoarece implică o bună cunoaștere a limbajului C, dar iată câteva indicii.

Dacă fuzionați, aflați ce comisie provoacă conflictul. Puteți face acest lucru din două moduri:

git log -pv $ (faceți kernelversion) .. pentru a obține modificările dintre versiunea curentă și cea mai recentă din amonte. Steagul -p vă va oferi modificările făcute de fiecare angajament, astfel încât să puteți vedea.
Rulați vina git pe fișier pentru a obține hashes-ul fiecărui angajament din zonă. Puteți rula apoi git show –format = fuller pentru a vedea dacă emitatorul a fost de la mainline / stabil, Google sau CodeAurora.

Dă-ți seama dacă ai deja angajamentul. Unii furnizori precum Google sau CAF vor încerca să caute în amonte bug-uri critice, cum ar fi soluția Dirty COW, iar suporturile lor ar putea intra în conflict cu cele din amonte. Puteți rula git log –grep = ”” și vedeți dacă returnează ceva. În acest caz, puteți săriți comiterea (dacă alegeți cireșe folosind resetarea git –hard && git cherry-pick –continue) sau să ignorați conflictele (eliminați <<<<< >>>>>).
Dă-ți seama dacă a existat un backport care rezolvă problema. Google și CAF doresc să sprijine anumite patch-uri care să nu fie stabile. Stabil va trebui adesea să adapteze rezoluția angajamentului principal la absența anumitor patch-uri pe care Google optează pentru backport. Puteți să vă uitați la angajarea mainline executând git show (hash-ul principal va fi disponibil în mesajul de comitere a comisului stabil). Dacă există un backport care îl încurcă, puteți fie să eliminați modificările, fie puteți utiliza versiunea principală (ceea ce va trebui de obicei să faceți).
Citiți ce încearcă să facă angajamentul și vedeți dacă problema este deja rezolvată. Uneori, CAF poate rezolva o eroare independentă de amonte, ceea ce înseamnă că puteți suprascrie corectarea lor pentru amonte sau o puteți elimina, ca mai sus.

În caz contrar, poate fi doar rezultatul unei adăugări CAF / Google / OEM, caz în care trebuie doar să schimbați anumite lucruri.

Aici este o oglindă a depozitului kernel.org linux-stabil pe GitHub, care poate fi mai ușor pentru căutarea listelor de angajare și diferit pentru rezolvarea conflictelor. Vă recomand să mergeți mai întâi la vizualizarea listei de comitere și să localizați problema de la angajare pentru a vedea diferența originală pentru a o compara cu a ta.

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

Puteți face, de asemenea, prin linia de comandă:

 git log .. git show

Rezolvarea rezoluțiilor se referă la context. Ceea ce ar trebui să faceți SEMPRE este să vă asigurați că dif dvs. final se potrivește în amonte, executând următoarele comenzi în două ferestre separate:

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

Activați rerere

Git are o caracteristică numită rerere (înseamnă Reutilizare Rezoluție înregistrată), ceea ce înseamnă că atunci când detectează un conflict, va înregistra modul în care l-ați rezolvat, astfel încât să îl puteți refolosi ulterior. Acest lucru este util în special pentru ambele rebasere cronice, atât pentru fuziune, cât și pentru cules, deoarece va trebui doar să rulați git add. && git - va continua atunci când refaceți amintirea din amonte, deoarece conflictul va fi rezolvat cum l-ați rezolvat anterior.

Poate fi activată rulând următoarea comandă din repo-ul kernel-ului:

 git config rerere.enabled true

Cum să git bisect când se execută un compilator sau o eroare de rulare

Având în vedere că veți adăuga un număr considerabil de comitete, este foarte posibil să introduceți un compilator sau o eroare de rulare. În loc să renunți doar, poți folosi instrumentul bisect încorporat pentru git pentru a descoperi cauza principală a problemei! În mod ideal, veți construi și clipește fiecare versiune de nucleu pe măsură ce o adăugați, astfel încât bisectarea va dura mai puțin timp dacă este necesar, dar puteți bisecta 5000 de comiteri fără probleme.

Ce va face git bisect este să luați o serie de comiteri, de unde este prezentă problema până unde nu a fost prezent și apoi să începeți să reducă la jumătate intervalul de compromisuri, permițându-vă să construiți și să testați și anunțați-l dacă este bine sau nu . Va continua acest lucru până când va elimina angajamentul care a cauzat problema dvs. În acel moment, îl puteți repara sau inversa.

Start bisecting: git bisect start
Etichetați revizuirea curentă ca fiind proastă: git bisect bad
Etichetați o revizuire la fel de bună: git bisect good
Construiți cu noua revizuire
Pe baza rezultatului (dacă problema este prezentă sau nu), spuneți lui git: git bisect good OR git bisect bad
Clătiți și repetați pașii 4-5 până la găsirea problemei!
Reveniți sau reparați comiterea problemei.

NOTĂ: Fuziunile vor trebui să execute temporar git rebase -i pentru a aplica toate patch-urile pe sucursala dvs. pentru o bisectare corespunzătoare, întrucât bisectarea cu fuziunile în loc va face de multe ori checkout-ul pe comitele din amonte, ceea ce înseamnă că nu aveți niciuna dintre comitele specifice Android. Pot să aprofundez acest lucru la cerere, dar aveți încredere în mine, este nevoie. După ce ați identificat comiterea problemei, puteți să o reveniți sau să o refaceți în fuziune.

NU aruncați actualizări în amonte

O mulțime de noi dezvoltatori sunt tentați să facă acest lucru, deoarece este mai curat și mai ușor de gestionat. Acest lucru este îngrozitor din câteva motive:

Autorul este pierdut. Este nedrept pentru alți dezvoltatori să-și pună creditul pentru munca lor.
Bisectarea este imposibilă. Dacă încercați o serie de comiteri și ceva este o problemă din seria respectivă, este imposibil să spuneți ce comisie a provocat o problemă într-o squash.
Viitoarele cireșe sunt mai grele. Dacă aveți nevoie să vă retrăiți cu o serie ghemuită, este dificil / imposibil să spuneți de unde rezultă un conflict.

Abonați-vă la lista de corespondență Linux Kernel pentru actualizări în timp util

Pentru a vă anunța ori de câte ori există o actualizare în amonte, abonați-vă la lista linux-kernel-anunț. Acest lucru vă va permite să primiți un e-mail de fiecare dată când este lansat un nucleu nou, astfel încât să puteți actualiza și apăsa cât mai repede posibil.