Cum să vă actualizați kernel-ul Android la cel mai recent stabil Linux

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

Partea care consumă mai mult timp este prezentarea inițială; odată ce sunteți la curent, nu este nevoie de timp pentru a fuziona într-o nouă versiune, care de obicei nu conține mai mult de 100 de confirmări. Avantajele pe care le aduce acest lucru (mai multă stabilitate și o securitate mai bună pentru utilizatorii dvs.) ar trebui să necesite acest proces.

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

Mai întâi trebuie să vă dați seama ce versiune de nucleu rulează dispozitivul dvs. Android.

Oricât de banal pare acest lucru, este necesar să știm de unde trebuie să începi. Rulați următoarea comandă în arborele nucleului:

face kernelversion

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

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

kernel.org găzduiește cea mai recentă sursă de nucleu din depozitul Linux-stable . În partea de jos a paginii respective, vor exista trei linkuri de preluare. Din experiența mea, oglinda Google tinde să fie cea mai rapidă, dar rezultatele dvs. pot varia. Rulați următoarele comenzi:

git remote add linux-stable https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit fetch linux-stable

Decideți dacă doriți să îmbinați întregul nucleu sau să alegeți comitetele

Apoi, va trebui să alegeți dacă doriți să îmbinați comitetele sau cherry-pick. Iată avantajele și dezavantajele fiecăruia și când doriți să le faceți.

NOTĂ: Dacă sursa dvs. de nucleu este sub forma unui tarball, cel mai probabil va trebui să alegeți cherry, altfel veți obține mii de conflicte de fișiere, deoarece git populează istoricul bazat doar pe amonte, nu pe ceea ce OEM sau CAF a schimbat. Treceți la pasul 4.

Culegerea cireșelor:

Pro:

• Este mai ușor să rezolvați conflictele, deoarece știți exact ce conflict cauzează o problemă.
• Mai ușor de reexaminat, deoarece fiecare comitere este singură.
• Mai ușor de divizat dacă întâmpinați probleme

Contra:

• Durează mai mult, deoarece fiecare comitere trebuie selectată individual.
• Puțin mai dificil de spus dacă comiterea este din amonte la prima vedere

Merge

Pro :

• Este mai rapid, deoarece nu trebuie să așteptați ca toate patch-urile curate să se îmbine.
• Este mai ușor să vedeți când o comitere este din amonte, deoarece nu veți fi comitatorul, va fi și întreținătorul din amonte.

Contra:

• Rezolvarea conflictelor poate fi puțin mai dificilă, deoarece va trebui să căutați care comitere cauzează conflictul folosind git log / git blame, nu vă va spune direct.
• Rebasarea este dificilă, deoarece nu puteți reface o îmbinare, aceasta va oferi să alegeți toate comitetele individual. Cu toate acestea, nu trebuie să refaceți frecvent, folosind git revert și git merge acolo unde este posibil.

Aș recomanda să faceți o selecție cherry pentru a afla orice conflict de problemă inițial, să faceți o fuzionare, apoi să reveniți la comiterea problemei ulterior, astfel încât actualizarea să fie mai ușoară (deoarece fuzionarea este mai rapidă după ce ați fost actualizată).

Adăugați confirmările la sursa dvs., o versiune la un moment dat

Cea mai importantă parte a acestui proces este versiunea unică la un moment dat. S-ar putea să existe un patch cu probleme în seria dvs. din amonte, care ar putea provoca o problemă la pornire sau să rupă ceva de genul sunetului sau încărcării (explicat în secțiunea sfaturi și trucuri). Efectuarea modificărilor de versiune incrementală este importantă din acest motiv, este mai ușor să găsiți o problemă în 50 de confirmări decât peste 2000 de confirmări pentru unele versiuni. Aș recomanda să faceți o fuziune completă numai după ce cunoașteți toate problemele comise și rezolvarea conflictelor.

Cules de cireșe

Format:

git cherry-pick ..

Exemplu:

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

Merge

Format:

du-te fuzionează

Exemplu:

git merge v3.10.74

Vă recomand să țineți evidența conflictelor în comitetele de îmbinare, eliminând marcajele #.

Cum să rezolvați conflictele

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

Dacă fuzionați, aflați ce comitere cauzează conflictul. Puteți face acest lucru în două moduri:

1. git log -p v $ (make kernelversion) .. pentru a obține modificările dintre versiunea curentă și cea mai recentă din amonte. Semnalizatorul -p vă va oferi modificările făcute de fiecare commit, astfel încât să puteți vedea.
2. Rulați git blame pe fișier pentru a obține hashurile fiecărui commit din zonă. Apoi puteți rula git show –format = mai complet pentru a vedea dacă comitter-ul a fost de pe mainline / stable, Google sau CodeAurora.

• Aflați dacă aveți deja commit-ul. Unii furnizori precum Google sau CAF vor încerca să caute în amonte pentru erori critice, cum ar fi soluția Dirty COW, iar backporturile lor ar putea intra în conflict cu cele din amonte. Puteți rula git log –grep = ”” și puteți vedea dacă returnează ceva. Dacă da, puteți sări peste commit (dacă cherry-picking folosind git reset –hard && git cherry-pick –continue) sau să ignorați conflictele (eliminați<<<<<>>>>>).
• Aflați dacă a existat un backport care distruge rezoluția. Google și CAF doresc să retrogradeze anumite patch-uri care nu ar fi 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 privi comisia principală executând git show (hashul principal va fi disponibil în mesajul de comitere al comitetului stabil). Dacă există un backport care o încurcă, puteți fie să renunțați la modificări, fie să utilizați versiunea principală (ceea ce va trebui să faceți de obicei).
• Citiți ce încearcă să facă commit și vedeți dacă problema este deja remediată. Uneori, CAF poate remedia o eroare independentă de amonte, ceea ce înseamnă că puteți suprascrie remedierea lor pentru amonte sau o puteți arunca, ca mai sus.

În caz contrar, poate fi doar un rezultat al unei adăugări CAF / Google / OEM, caz în care trebuie doar să amestecați câteva lucruri în jur.

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

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

Puteți face acest lucru și prin linia de comandă:

git log .. git show

Rezolvarea rezoluțiilor se referă la context. Ceea ce ar trebui să faceți ÎNTOTDEAUNA este să vă asigurați că diferența 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 -l v $ (make kernelversion | cut -d. -f 1,2) * | head -n1)

Activați rerere

Git are o caracteristică numită rerere (înseamnă Reutilizarea înregistrării rezoluției), 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 atât pentru rebaserii cronici, atât cu fuzionarea, cât și cu cireșul, deoarece va trebui doar să rulați git add. && git - continuați atunci când refaceți reluarea în amonte, deoarece conflictul va fi rezolvat cum l-ați rezolvat anterior.

Poate fi activat executând următoarea comandă în repo kernel-ul dvs.:

git config rerere.enabled true

Cum se face git bisect atunci când se execută un compilator sau o eroare de execuție

Având în vedere că veți adăuga un număr considerabil de confirmări, este foarte posibil să introduceți o eroare de compilare sau de execuție. În loc să renunțați, puteți utiliza instrumentul de bisect încorporat al git pentru a afla cauza principală a problemei! În mod ideal, veți construi și clipi 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 împărți 5000 de comitere fără probleme.

Ce va face git bisect este să ia o serie de comitere, de la care problema este prezentă până la locul în care nu a fost prezentă, și apoi începeți să înjumătățiți intervalul de comitere, permițându-vă să construiți și să testați și să anunțați dacă este bine sau nu . Acesta va continua până când scuipă comiterea care cauzează problema. În acel moment, îl puteți repara sau reveni.

1. Începeți bisectarea: git bisect începe
2. Etichetați versiunea curentă ca fiind rea: git bisectează rău
3. Etichetați o revizuire ca fiind bună: git bisectează bine
4. Construiți cu noua versiune
5. Pe baza rezultatului (dacă problema este prezentă sau nu), spuneți git: git bisectează bine SAU git bisectează rău
6. Clătiți și repetați pașii 4-5 până când se constată comiterea problemei!
7. Reveniți sau remediați comiterea problemei.

NOTĂ: Fuziunile vor trebui să ruleze temporar git rebase -i pentru a aplica toate patch-urile la sucursala dvs. pentru o bisectare corectă, deoarece bisectarea cu fuziunile în loc va face de multe ori checkout-ul în comitetele din amonte, ceea ce înseamnă că nu aveți niciunul dintre comitetele specifice Android. Pot să aprofundez acest lucru la cerere, dar credeți-mă, este necesar. După ce ați identificat comiterea problemei, o puteți reveni sau restabili în fuziune.

NU ascundeți actualizările din amonte

Mulți dezvoltatori noi sunt tentați să facă acest lucru, deoarece este „mai curat” și „mai ușor” de gestionat. Acest lucru este teribil din câteva motive:

• Autoria este pierdută. Este nedrept pentru ceilalți dezvoltatori să li se limiteze creditul pentru munca lor.
• Bisectarea este imposibilă. Dacă spulberați o serie de confirmări și ceva este o problemă din seria respectivă, este imposibil să spuneți ce comitere a cauzat o problemă într-o squash.
• Viitoarele cireșe sunt mai grele. Dacă aveți nevoie să refaceți cu o serie zdrobită, este dificil / imposibil să spuneți de unde rezultă un conflict.

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

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