Slik oppdaterer du Android-kjernen til nyeste Linux-stabil

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

Den mest tidkrevende delen er den første oppveksten; Når du er helt oppdatert, tar det ikke tid å slå seg sammen i en ny utgivelse, som vanligvis ikke inneholder mer enn 100 forpliktelser. Fordelene som dette gir (mer stabilitet og bedre sikkerhet for brukerne dine) bør imidlertid kreve denne prosessen.

Slik slår du sammen Linux Stable Kernel til en Android Kernel

Først må du finne ut hvilken kjerneversjon Android-enheten din kjører.

Så trivielt som dette virker, er det nødvendig å vite hvor du trenger å begynne. Kjør følgende kommando i kjernetreet ditt:

lage kjerneversjon

Den returnerer versjonen du er på. De to første tallene vil bli brukt til å finne ut grenen du trenger (f.eks. Linux-4.4.y for en hvilken som helst 4.4-kjerne), og det siste tallet vil bli brukt til å bestemme hvilken versjon du trenger for å starte med sammenslåing (f.eks. Hvis du er på 4.4 .21, vil du slå sammen 4.4.22 neste).

Ta tak i den siste kjernekilden fra kernel.org

kernel.org huser den siste kjernekilden i det linux-stabile depotet . Nederst på den siden vil det være tre hentelinker. Etter min erfaring har Googles speil en tendens til å være den raskeste, men resultatene kan variere. Kjør følgende kommandoer:

git ekstern legge til linux-stabil https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit hente linux-stabil

Bestem om du vil slå sammen hele kjernen eller kirsebærplukke forpliktelsene

Deretter må du velge om du vil slå sammen forpliktelsene eller kirsebærplukkingen. Her er fordelene og ulempene med hver og en gang du kanskje vil gjøre det.

MERK: Hvis kjernekilden din er i form av en tarball, vil du mest sannsynlig trenge å kirsebærplukke, ellers vil du få tusenvis av filkonflikter fordi git fyller historien utelukkende basert på oppstrøms, ikke hva OEM eller CAF har endret. Bare hopp til trinn 4.

Kirsebærplukking:

Fordeler:

• Enklere å løse konflikter da du vet nøyaktig hvilken konflikt som forårsaker et problem.
• Enklere å omsette ettersom hver forpliktelse er alene.
• Enklere å halvere hvis du får problemer

Ulemper:

• Det tar lengre tid siden hver forpliktelse må velges individuelt.
• Litt vanskeligere å se om forpliktelse er fra oppstrøms ved første øyekast

Gå

Fordeler :

• Det er raskere siden du ikke trenger å vente på at alle de rene lappene skal smelte sammen.
• Det er lettere å se når en forpliktelse er fra oppstrøms, da du ikke vil være forpliktende, oppstrøms vedlikeholder vil være.

Ulemper:

• Å løse konflikter kan være litt vanskeligere ettersom du må slå opp hvilken forpliktelse som forårsaker konflikten ved å bruke git log / git-skyld, det vil ikke fortelle deg det.
• Det er vanskelig å rebase ettersom du ikke kan omsette en sammenslåing, den vil tilby å kirsebærplukke alle forpliktelsene individuelt. Du bør imidlertid ikke basere deg ofte, i stedet for å bruke git revert og git flette der det er mulig.

Jeg vil anbefale å gjøre en kirsebærplukk for å finne ut eventuelle problemkonflikter i utgangspunktet, gjøre en sammenslåing, og deretter tilbakestille problemet forplikter seg etterpå, slik at oppdatering er enklere (ettersom sammenslåing er raskere etter å ha vært oppdatert).

Legg til forpliktelsene til kilden din, en versjon om gangen

Den viktigste delen av denne prosessen er den ene versjonen av gangen. Det KAN være en problemoppdatering i oppstrømserien din, som kan forårsake et problem med oppstart eller ødelegge noe som lyd eller lading (forklart i delen tips og triks). Det er viktig å gjøre trinnvise versjonsendringer av denne grunn. Det er lettere å finne et problem i 50 forpliktelser enn oppover 2000 forpliktelser for noen versjoner. Jeg vil bare anbefale å gjøre en full sammenslåing når du vet at alle problemene er forpliktet og konfliktløsninger.

Kirsebærplukking

Format:

git cherry-pick ..

Eksempel:

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

Gå

Format:

gå flette

Eksempel:

git merge v3.10.74

Jeg anbefaler å holde oversikt over konfliktene i fusjonsforpliktelser ved å fjerne # markørene.

Hvordan løse konflikter

Vi kan ikke gi en trinnvis veiledning for å løse hver eneste konflikt, da det innebærer god kunnskap om C-språk, men her er noen tips.

Hvis du smelter sammen, kan du finne ut hva som er årsaken til konflikten. Du kan gjøre dette på to måter:

1. git log -p v $ (make kernelversion) .. for å få endringene mellom din nåværende versjon og den siste fra oppstrøms. Flagget -p vil gi deg endringene som gjøres av hver kommisjon, slik at du kan se.
2. Kjør git-skyld på filen for å få hashene for hver forpliktelse i området. Deretter kan du kjøre git show –format = fullere for å se om kommitøren var fra hovedlinje / stabil, Google eller CodeAurora.

• Finn ut om du allerede har forpliktelsen. Noen leverandører som Google eller CAF vil prøve å se oppstrøms etter kritiske feil, som Dirty COW-løsningen, og bakportene deres kan komme i konflikt med oppstrøms. Du kan kjøre git log –grep = ”” og se om den returnerer noe. Hvis den gjør det, kan du hoppe over forpliktelsen (hvis kirsebærplukking med git reset –hard && git kirsebærplukk – fortsett) eller ignorere konfliktene (fjern<<<<<>>>>>).
• Finn ut om det har vært en backport som ødelegger oppløsningen. Google og CAF baksporterer visse oppdateringer som ikke er stabile. Stabil vil ofte trenge å tilpasse oppløsningen til hovedlinjen forplikte seg til å fjerne visse oppdateringer som Google velger å støtte. Du kan se på hovedlinjeforpliktelsen ved å kjøre git show (hovedlinjens hash vil være tilgjengelig i kommisjonsmeldingen til den stabile forpliktelsen). Hvis det er en backport som ødelegger den, kan du enten forkaste endringene, eller du kan bruke hovedversjonen (som du vanligvis trenger å gjøre).
• Les hva forpliktelsen prøver å gjøre, og se om problemet allerede er løst. Noen ganger kan CAF fikse en feil uavhengig av oppstrøms, noe som betyr at du enten kan overskrive løsningen for oppstrøms eller forkaste den, som ovenfor.

Ellers kan det bare være et resultat av et CAF / Google / OEM-tillegg, i så fall trenger du bare å blande noen ting rundt.

Her er et speil av det linux-stabile kernel.org-depotet på GitHub, som kan være lettere for å slå opp forpliktelseslister og forskjeller for konfliktløsning. Jeg anbefaler å gå til listen over kommisjonslisten først og finne problemet forplikte deg for å se den opprinnelige forskjellen for å sammenligne den med din.

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

Du kan også gjøre det via kommandolinjen:

git log .. git show

Å løse oppløsninger handler om kontekst. Det du ALLTID bør gjøre er å sørge for at den endelige forskjellen samsvarer med oppstrøms ved å kjøre følgende kommandoer i to separate vinduer:

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

Aktiver viderekobling

Git har en funksjon kalt rerere (står for Reuse Recorded Resolution), noe som betyr at når den oppdager en konflikt, vil den registrere hvordan du løste den slik at du kan bruke den senere. Dette er spesielt nyttig for begge kroniske rebasere med både sammenslåing og kirsebærplukking, da du bare trenger å kjøre git add. && git - fortsett når du gjør om oppstrømsopphentingen ettersom konflikten blir løst slik du tidligere løste den.

Det kan aktiveres ved å kjøre følgende kommando i kjerneposten:

git config rerere.enabled true

Hvordan git bisect når du får en kompilator eller kjøretidsfeil

Gitt at du vil legge til et betydelig antall forpliktelser, er det veldig mulig for deg å introdusere en kompilator- eller kjøretidsfeil. I stedet for bare å gi opp, kan du bruke gits innebygde halveringsverktøy for å finne ut av årsaken til problemet! Ideelt sett vil du bygge og blinke hver eneste kjerneversjon når du legger den til, slik at halvering vil ta kortere tid om nødvendig, men du kan halvere 5000 forpliktelser uten problemer.

Hva git bisect vil gjøre er å ta en rekke forpliktelser, fra der problemet er til der det ikke var tilstede, og deretter begynne å halvere forpliktelsesområdet, slik at du kan bygge og teste og gi beskjed om det er bra eller ikke . Det vil fortsette dette til det spytter ut forpliktelsen som forårsaker problemet ditt. På det tidspunktet kan du enten fikse det eller tilbakestille det.

1. Start halvering: Git halvering
2. Merk den nåværende revisjonen som dårlig: git bisect bad
3. Merk en revisjon som god: git bisect good
4. Bygg med den nye revisjonen
5. Basert på resultatet (hvis problemet er tilstede eller ikke), fortell git: git bisect bra ELLER git bisect dårlig
6. Skyll og gjenta trinn 4-5 til problemet er funnet!
7. Tilbakestill eller fikse problemet.

MERK: Fusjoner må midlertidig kjøre git rebase -i for å bruke alle oppdateringene på grenen din for riktig halvering, ettersom halvering med sammenslåingene på plass ofte vil betale til oppstrømsforpliktelser, noe som betyr at du ikke har noen av de Android-spesifikke forpliktelsene. Jeg kan gå nærmere inn på dette på forespørsel, men stol på meg, det er nødvendig. Når du har identifisert problemforpliktelsen, kan du tilbakestille eller omsette det til sammenslåingen.

IKKE squash oppstrømsoppdateringer

Mange nye utviklere er fristet til å gjøre dette da det er 'renere' og 'lettere' å administrere. Dette er forferdelig av noen få grunner:

• Forfatterskap er tapt. Det er urettferdig overfor andre utviklere å få æren for arbeidet sitt.
• Halvering er umulig. Hvis du klemmer en serie forpliktelser og noe er et problem i den serien, er det umulig å fortelle hva som har forårsaket et problem i en squash.
• Fremtidige kirsebærvalg er vanskeligere. Hvis du trenger å basere på nytt med en squashed serie, er det vanskelig / umulig å fortelle hvor en konflikt skyldes.

Abonner på Linux Kernel-adresselisten for oppdateringer

For å bli varslet når det er en oppdatering oppstrøms, abonner på Linux-kernel-kunngjør listen . Dette vil tillate deg å motta en e-post hver gang en ny kjerne slippes, slik at du kan oppdatere og presse så raskt som mulig.