Kako ažurirati Android kernel na najnoviji Linux stabilni

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

Dio koji najviše oduzima vremenu je početni odgoj; nakon što ste potpuno ažurni, uopće ne treba vremena za spajanje u novom izdanju, koje obično sadrži ne više od 100 obveza. Blagodati koje ovo donosi (veća stabilnost i bolja sigurnost za vaše korisnike) trebale bi zahtijevati ovaj postupak.

Kako spojiti Linux stabilnu jezgru u Android kernel

Prvo morate shvatiti koju verziju jezgre ima vaš Android uređaj.

Koliko god se ovo čini trivijalnim, nužno je znati odakle trebate započeti. Pokrenite sljedeću naredbu u svom stablu jezgre:

napraviti kernelversion

Vratit će se verzija na kojoj ste. Prva dva broja upotrijebit će se za utvrđivanje grane koja vam je potrebna (npr. Linux-4.4.y za bilo koje 4.4 jezgre), a zadnji broj upotrijebit će se za utvrđivanje koju verziju trebate započeti spajanjem (npr. Ako ste na 4.4 .21, sljedeći ćete spojiti 4.4.22).

Preuzmite najnoviji izvor jezgre s kernel.org

kernel.org sadrži najnoviji izvor jezgre u linux-stabilno spremište . Na dnu te stranice nalazit će se tri veze za dohvaćanje. Prema mom iskustvu, Googleovo zrcalo obično je najbrže, ali vaši se rezultati mogu razlikovati. Izvedite sljedeće naredbe:

git remote dodaj linux-stable https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit dohvati linux-stable

Odlučite želite li spojiti cjelokupnu jezgru ili odabrati trešnje za odabir

Dalje, morat ćete odabrati želite li spojiti obveze ili cherry-pick. Evo prednosti i nedostataka svake i kada biste ih možda željeli učiniti.

BILJEŠKA: Ako je vaš izvor jezgre u obliku tarball-a, najvjerojatnije ćete trebati izabrati, inače ćete dobiti tisuće sukoba datoteka jer git popunjava povijest koja se temelji isključivo na uzvodnom toku, a ne na onome što su promijenili OEM ili CAF. Samo prijeđite na 4. korak.

Branje trešanja:

Pros:

• Lakše je riješiti sukobe jer točno znate koji sukob uzrokuje problem.
• Jednostavnije je izvršiti bazu podataka jer je svaki predavanje vlastiti.
• Lakše se podijeliti ako naiđete na probleme

Protiv:

• Potrebno je više vremena jer se svaki odabir mora pojedinačno odabrati.
• Malo je teže reći je li predavanje na prvi pogled uzvodno

Ići

Pros :

• Brže je jer ne morate čekati da se sve čiste zakrpe spoje.
• Lakše je vidjeti kada je urezivanje od uzvodno, jer ti nećeš biti počinitelj, a bit će održavatelj uzvodno.

Protiv:

• Rješavanje sukoba može biti malo teže jer ćete trebati potražiti koji je počinitelj uzrok sukoba pomoću git log / git krivnje, neće vam to izravno reći.
• Predefiniranje je teško jer ne možete rebazirati spajanje, ponudit će trešnje-odabir svih urezivanja pojedinačno. Međutim, ne biste trebali često podrezivati ​​podatke, već koristite git revert i git merge kad god je to moguće.

Preporučio bih da izvršite trešnje kako biste u početku otkrili bilo kakve sukobe problema, izvršili spajanje, a zatim vratili počinjene probleme kako bi ažuriranje bilo lakše (jer je spajanje brže nakon što je ažurirano).

Dodajte obveze u izvor, jednu po jednu verziju

Najvažniji dio ovog postupka je pojedinačna verzija. MOŽE postojati zakrpa problema u vašoj uzvodnoj seriji, koja bi mogla stvoriti problem s dizanjem ili slomiti nešto poput zvuka ili punjenja (objašnjeno u odjeljku savjeta i trikova). Iz tog razloga važno je raditi inkrementalne izmjene verzije, jer je lakše pronaći problem u 50 obveza, nego više od 2000 obveza za neke verzije. Potpuno spajanje preporučio bih tek kad saznate za sve počinjene probleme i rješenja sukoba.

Branje trešanja

Format:

git cherry-pick ..

Primjer:

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

Ići

Format:

idi spajanje

Primjer:

git spajanje v3.10.74

Preporučujem praćenje sukoba u spajanju predavanja uklanjanjem # markera.

Kako riješiti sukobe

Ne možemo dati detaljni vodič za rješavanje svakog pojedinog sukoba, jer uključuje dobro znanje jezika C, ali evo nekoliko savjeta.

Ako se spajate, shvatite što počinjenje uzrokuje sukob. To možete učiniti na dva načina:

1. git log -p v $ (make kernelversion) .. da biste dobili promjene između vaše trenutne verzije i najnovije iz uzvodne verzije. Oznaka -p dat će vam promjene izvršene svakim urezivanjem kako biste mogli vidjeti.
2. Pokrenite git krivnju na datoteci da biste dobili hashove svakog urezivanja na tom području. Zatim možete pokrenuti git show –format = fuller da vidite je li predavač iz mainline / stable, Googlea ili CodeAurore.

• Otkrijte imate li već urezivanje. Neki dobavljači poput Googlea ili CAF-a pokušat će potražiti kritične programske pogreške, poput popravka Prljave krave, uzlazno, a njihove bi se pozadinske pozadine mogle sukobiti s uzvodnim. Možete pokrenuti git log –grep = ”” i provjeriti vraća li nešto. Ako se dogodi, možete preskočiti urezivanje (ako se branje trešnje koristi git reset –hard && git cherry-pick –nastavi) ili zanemariti sukobe (uklonite<<<<<>>>>>).
• Otkrijte je li postojao backport koji je poremetio rezoluciju. Google i CAF vole podržavati određene zakrpe koje stabilno ne bi. Stabilni će često trebati prilagoditi rezoluciju glavne obveze apscesiji određenih zakrpa koje Google odlučuje za backport. Glavno urezivanje možete pogledati pokretanjem git show (glavno raspršivanje bit će dostupno u poruci urezivanja stabilnog urezivanja). Ako postoji backport koji ga zabrlja, možete odbaciti promjene ili možete upotrijebiti glavnu verziju (što ćete obično trebati učiniti).
• Pročitajte što predavanje pokušava učiniti i pogledajte je li problem već riješen. Ponekad CAF može ispraviti pogrešku neovisnu o uzvodnoj verziji, što znači da možete ili prepisati njihov popravak za uzvodnu verziju ili je odbaciti, kao gore.

Inače, to je možda rezultat dodavanja CAF-a / Google-a / OEM-a, u tom slučaju trebate samo promiješati neke stvari oko sebe.

Ovdje je zrcalo linux-stabilnog spremišta kernel.org na GitHub-u, što može biti lakše za pretraživanje popisa obveza i razlike za rješavanje sukoba. Preporučujem da prvo odete na prikaz popisa urezivanja i locirate prijavu problema da biste vidjeli izvornu razliku kako biste je usporedili s vašom.

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

To možete učiniti i putem naredbenog retka:

git log .. git show

Rješavanje rezolucija sve je u kontekstu. Ono što biste UVIJEK trebali učiniti je osigurati da se vaša konačna razlika poklapa uzvodno tako što ćete izvesti sljedeće naredbe u dva odvojena prozora:

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

Omogući ponovno vraćanje

Git ima značajku koja se zove rerere (skraćenica od Reuse Recorded Resolution), što znači da će, kad otkrije sukob, zabilježiti kako ste ga riješili kako biste ga kasnije mogli ponovno koristiti. To je posebno korisno za kronične rebazere koji spajaju i beru trešnje jer ćete samo trebati pokrenuti git add. && git –nastavite pri ponovnom uspostavljanju nadogradnje jer će sukob biti riješen na način na koji ste ga prethodno riješili.

To se može omogućiti pokretanjem sljedeće naredbe u vašem repo-u jezgre:

git config rerere.enabled true

Kako git bisect kada naiđe na pogrešku prevoditelja ili runtime

S obzirom na to da ćete dodati znatan broj predavanja, vrlo je moguće da unesete pogrešku prevoditelja ili runtime. Umjesto da samo odustanete, možete upotrijebiti gitov ugrađeni bisekt alat da biste otkrili osnovni uzrok problema! Idealno bi bilo da ćete svaku dodatnu verziju jezgre graditi i bljeskati dok je dodajete, tako da će dijeljenje dijeliti po potrebi manje vremena, ali možete podijeliti 5000 izvršavanja bez ikakvih problema.

Ono što će git bisect učiniti je uzeti niz predavanja, od mjesta gdje je problem prisutan do mjesta gdje nije bio prisutan, a zatim početi prepoloviti raspon urezivanja, omogućujući vam izgradnju i testiranje te mu dati do znanja je li to dobro ili nije . Nastavit će tako sve dok ne ispljune urezivanje koje je uzrokovalo vaš problem. U tom trenutku možete to popraviti ili vratiti.

1. Počnite dijeliti: git bisect start
2. Označite trenutnu reviziju kao lošu: git bisect bad
3. Označite reviziju kao dobru: git bisect good
4. Izradite s novom revizijom
5. Na temelju rezultata (ako je problem prisutan ili ne), recite git: git bisect dobro ILI git bisect bad
6. Isperite i ponavljajte korake 4-5 dok se ne pronađe urezivanje problema!
7. Vratite ili popravite urezivanje problema.

BILJEŠKA: Spajanja će trebati privremeno pokrenuti git rebase -i da bi se sve zakrpe primijenile na vašu granu radi pravilnog dijeljenja, jer će dijeljenje s spajanjem na mjestu često puta odjaviti uz nadolazeće komitove, što znači da nemate nijedan od Android specifičnih obveza. Na zahtjev mogu to detaljnije proučiti, ali vjerujte mi, to je potrebno. Nakon što prepoznate urezivanje problema, možete ga vratiti ili prebazirati u spajanje.

NEMOJTE gnječiti nadogradnje

Mnogi su novi programeri u iskušenju da to učine jer je 'čišći' i 'lakši' za upravljanje. Ovo je strašno iz nekoliko razloga:

• Autorstvo je izgubljeno. Nepravedno je prema drugim programerima ako im se umanjuje kredit za njihov rad.
• Dijeljenje je nemoguće. Ako zgužvate niz obveza i nešto je problem u toj seriji, nemoguće je reći koji je pogodak izazvao problem u tikvici.
• Buduće branje trešanja teže je. Ako trebate izvršiti bazu podataka sa zgnječenom serijom, teško je / nemoguće reći odakle dolazi do sukoba.

Pretplatite se na mailing listu Linux Kernela za pravovremena ažuriranja

Pretplatite se da biste primali obavijesti kad god postoji nadogradnja popis Linux-kernel-najave . To će vam omogućiti da dobijete e-poštu svaki put kad se izda nova jezgra, tako da možete što brže ažurirati i pritisnuti.