hvordan

Slik oppdaterer du din Android Kernel til den siste Linux-stallen

Vi har dekket guider på Android-kjerner, for eksempel “Hvordan bygge en tilpasset kjerne” og “Beste tilpassede kerner for Android”, men i dag skal vi vise deg hvordan du oppstrømmer kjernen din mot den nyeste Linux-stallen.

Vær oppmerksom på at dette er avanserte ting - hvis du aldri har satt sammen en kjerne før, bør du følge guiden "Hvordan bygge en tilpasset kjerne" som er koblet over, og denne guiden vil innebære kirsebærplukking og sammenslåingsforpliktelser fra den nyeste Linux- stabil kjerne med Android-kjernen før du kompilerer den.

Å oppstrømme Android-kjernen til den nyeste Linux-stallen har mange positive fordeler, for eksempel å være oppdatert med de siste sikkerhetsforpliktelsene og feilrettelsene - vi forklarer noen av fordeler og ulemper senere i denne guiden.

Hva er Linux-stabil kjerne?

Linux-stabil som navnet tilsier er den stabile armen til Linux-kjernen. Den andre armen er kjent som "hovedlinje", som er mestergrenen . All Linux-kjerneutviklingen skjer i hovedlinjen, og følger vanligvis denne prosessen:

Linus Torvalds vil ta en haug med lapper fra vedlikeholderne sine i to uker.
Etter disse to ukene slipper han en rc1 (f.eks. 4.14-rc1) -kjerne.
For hver uke i løpet av de neste 6-8 ukene vil han slippe en annen RC (f.eks. 4.14-rc2, 4.14-rc3, etc), som inneholder KUN feil og regresjonsrettelser.
Når den anses som stabil, vil den bli utgitt som en tarball for nedlasting på org (f.eks. 4.14).

Hva er LTS-kjerner?

Hvert år plukker Greg ut en kjerne og opprettholder den i to år (LTS) eller seks år (utvidet LTS). Disse er designet for å ha produkter som trenger stabilitet (som Android-telefoner eller andre IOT-enheter). Prosessen er nøyaktig den samme som ovenfor, den skjer bare over lengre tid. Det er for tiden seks LTS-kjerner (som alltid kan vises på kernel.org-utgivelsessiden):

4.14 (LTS), vedlikeholdt av Greg Kroah-Hartman
4, 9 (LTS), vedlikeholdt av Greg Kroah-Hartman
4.4 (eLTS), vedlikeholdt av Greg Kroah-Hartman
4.1 (LTS), vedlikeholdt av Sasha Levin
3, 16 (LTS), vedlikeholdt av Ben Hutchings
3.2 (LTS), vedlikeholdt av Ben Hutchings

Hva er fordelene med å oppstrømme Android-kjernen til Linux Stable?

Når viktige sårbarheter blir avslørt / fikset, er de stabile kjernene de første som får dem. Dermed vil Android-kjernen din være mye tryggere mot angrep, sikkerhetsfeil og bare feil generelt.

Linux-stallen inkluderer rettelser for mange drivere som Android-enheten min ikke bruker, er det ikke mest unødvendig?

Ja og nei, avhengig av hvordan du definerer “det meste”. Linux-kjernen kan inneholde mye kode som blir ubrukt i Android-systemet, men som ikke garanterer at det ikke vil være konflikter fra disse filene når du slår sammen nye versjoner! Forstå at praktisk talt ingen bygger hver eneste del av kjernen, ikke engang de vanligste Linux-distrosene som Ubuntu eller Mint. Dette betyr ikke at du ikke bør ta disse rettelsene, fordi det ER Fikser for drivere du kjører. Ta for eksempel arm / arm64 og ext4, som er henholdsvis den vanligste Android-arkitekturen og filsystemet. I 4.4, fra 4.4.78 (versjon av den nyeste Oreo CAF-koden) til 4.4.121 (siste oppstrømskode), er dette følgende tall for forpliktelsene til disse systemene:

 ~ / kernels / linux-stable (master) $ git log - format =% h v4.4.78..v4.4.121 | wc -l2285 postbeskyttet ~ / kernels / linux-stable (master) $ git log - format =% h v4.4.78..v4.4.121 arch / arm | wc -l58 postbeskyttet ~ / kernels / linux-stable (master) $ git log - format =% h v4.4.78..v4.4.121 arch / arm64 | wc -l22 postbeskyttet ~ / 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 oppstarten; når du først er oppdatert, tar det ingen tid å slå seg sammen i en ny utgivelse, som vanligvis ikke inneholder mer enn 100 forpliktelser. Fordelene som dette medfører (mer stabilitet og bedre sikkerhet for brukerne dine) bør imidlertid nødvendiggjøre denne prosessen.

Hvordan slå sammen Linux Stable Kernel til en Android Kernel

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

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

 lage kernelversion

Den vil returnere versjonen du er på. De to første numrene vil bli brukt til å finne ut hvilken gren 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 kilden fra kernel.org

kernel.org inneholder den siste kilden i kilden i Linux-stabilen. Nederst på siden vil det være tre hentekoblinger. Etter min erfaring har Googles speil en tendens til å være raskest, men resultatene kan variere. Kjør følgende kommandoer:

 git remote legge til linux-stable //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit hente linux-stable

Bestem om du vil slå sammen hele kjernen eller kirsebær-velg forpliktelsene

Deretter må du velge om du vil slå sammen forpliktelsene eller kirsebærplukk. Her er fordeler og ulemper med hver og en gang du kanskje vil gjøre dem.

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

Kirsebærplukking:

Pros:

Enklere å løse konflikter da du vet nøyaktig hvilken konflikt som forårsaker et problem.
Enklere å rebase fordi hver begå er på egen hånd.
Enklere å halvere hvis du får problemer

Ulemper:

Det tar lengre tid ettersom hver forpliktelse må velges individuelt.
Litt vanskeligere å si om engasjementet er fra oppstrøms ved første øyekast

Slå sammen

Fordeler :

Det er raskere, siden du ikke trenger å vente til alle de rene lappene smelter sammen.
Det er lettere å se når en forpliktelse er fra oppstrøms, ettersom du ikke vil være pendler, vil oppstrømse vedlikeholder være.

Ulemper:

Å løse konflikter kan være litt vanskeligere, da du vil måtte slå opp hvilke forpliktelser som forårsaker konflikten ved å bruke git-logg / git-skyld, det vil ikke direkte fortelle deg.
Å omjustere er vanskelig, siden du ikke kan omfusjonere en sammenslåing, det vil tilby å kirsebærplukke alle forpliktelsene individuelt. Imidlertid bør du ikke rebase ofte, i stedet bruke git revert og git fusjonere der det er mulig.

Jeg vil anbefale å gjøre et kirsebærvalg for å finne ut av eventuelle problemkonflikter til å begynne med, gjøre en sammenslåing, og deretter tilbakestille problemet forplikter seg etterpå, så oppdateringen er enklere (da sammenslåing er raskere etter å ha blitt oppdatert).

Legg til forpliktelsene til kilden, en versjon av gangen

Den viktigste delen av denne prosessen er den versjonen av gangen. Det kan være en problemoppdatering i oppstrøms-serien din, som kan forårsake problemer med å starte opp eller ødelegge noe som lyd eller lading (forklart i tips og triks-delen). Å gjøre trinnvise versjonsendringer er viktig 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 forplikter og konfliktløsninger.

Kirsebærplukking

Format:

 git cherry-pick ..

Eksempel:

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

Slå sammen

Format:

 git fusjonere

Eksempel:

git merge v3.10.74

Jeg anbefaler å følge med på konfliktene i fletteforpliktelser ved å fjerne # -merkene.

Slik løser du konflikter

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

Hvis du slår seg sammen, finn ut hva som begår konflikten. Du kan gjøre dette på to måter:

git log -pv $ (lag kernelversion) .. for å få endringene mellom din nåværende versjon og den siste fra oppstrøms. Flagget -p gir deg endringene som er gjort av hver forpliktelse, slik at du kan se.
Kjør git-skyld på filen for å få hasjene til hver begår i området. Du kan deretter kjøre git show –format = fyldigere for å se om pendleren var fra hovedlinje / stall, Google eller CodeAurora.

Finn ut om du allerede har forpliktelsen. Noen leverandører som Google eller CAF vil forsøke å se oppstrøms for kritiske feil, for eksempel Dirty COW-fixen, og backportene deres kan komme i konflikt med oppstrøms. Du kan kjøre git log –grep = ”” og se om det returnerer noe. Hvis det gjør det, kan du hoppe over engasjementet (hvis du plukker med kirsebær ved hjelp av git reset –hard && git cherry-pick – fortsett) eller ignorerer konfliktene (fjern <<<<< >>>>>).
Finn ut om det har vært en backport som roter opp oppløsningen. Google og CAF liker å tilbakeføre visse oppdateringer som stabile ikke ville gjort. Stabil vil ofte trenge å tilpasse oppløsningen av hovedlinjen forpliktende til fraværet av visse oppdateringer som Google velger å haport. Du kan se på mainline-engasjementet ved å kjøre git-show (hovedlinjen-hasj vil være tilgjengelig i forpliktelsesmeldingen til den stabile commit). Hvis det er en backport som kutter det, kan du enten forkaste endringene, eller du kan bruke hovedlinjeversjonen (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 hvilket tilfelle du bare trenger å stokke noen ting rundt.

Her er et speil av det linuxstabile kernel.org-depotet på GitHub, som kan være enklere for å slå opp engasjementslister og forskjeller for konfliktløsning. Jeg anbefaler at du først går til engasjementslistevisningen og finner problemet forpliktet for å se den opprinnelige diffen for å sammenligne den med din.

Eksempel URL: //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 resolusjoner handler om kontekst. Det du ALLTID bør gjøre er å sørge for at den endelige diffen din samsvarer med oppstrøms ved å kjøre følgende kommandoer i to separate vinduer:

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

Aktiver rerere

Git har en funksjon som heter rerere (står for Reuse Recorded Resolution), 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 både 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øms oppbrudd, da konflikten vil bli løst hvordan du tidligere løste den.

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

 git config rerere.enabled sant

Hvordan gis halveres når du løper inn i en kompilator eller runtime-feil

Med tanke på at du vil legge til et betydelig antall forpliktelser, er det veldig mulig for deg å introdusere en kompilator eller runtime-feil. I stedet for bare å gi opp, kan du bruke gits innebygde halvverktøy for å finne ut årsaken til problemet! Ideelt sett vil du bygge og blinke hver eneste kjerneversjon når du legger til den, så det kan ta kortere tid om det å halvere seg, men du kan halvere 5000 forpliktelser uten problemer.

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

Start halvering: git bisect start
Merk den gjeldende revisjonen som dårlig: Git bisect bad
Merk en revisjon som god: git bisect good
Bygg med den nye revisjonen
Basert på resultatet (hvis problemet er til stede eller ikke), fortell git: git bisect good ELLER git bisect bad
Skyll og gjenta trinn 4-5 til problemet er begått!
Gå tilbake eller fikse problemet.

MERKNAD: Sammenslåing må midlertidig kjøre git rebase -i for å bruke alle lappene på grenen din for å få riktig deling, ettersom det å halvere seg med sammenslåingene på plass ofte vil kassa til oppstrøms forpliktelser, 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 problemet begår, kan du tilbakeføre eller omgjøre det til sammenslåingen.

IKKE squash oppstrøms oppdateringer

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

Forfatterskap er tapt. Det er urettferdig overfor andre utviklere å få kreditten sin stukket for arbeidet sitt.
Binding er umulig. Hvis du squash en serie forpliktelser, og noe er et problem i den serien, er det umulig å si hva forpliktelser som forårsaket et problem i en squash.
Fremtidige kirsebærplukk er vanskeligere. Hvis du trenger å ta opp på nytt med en klemt serie, er det vanskelig / umulig å si hvor en konflikt resulterer fra.

Abonner på Linux Kernel-adresselisten for rettidige oppdateringer

For å bli varslet når det er en oppstrøms oppdatering, kan du abonnere på linux-kernel-kunngjøringslisten. Dette lar deg få en e-post hver gang en ny kjerne slippes, slik at du kan oppdatere og presse så raskt som mulig.