hvordan

Sådan opdaterer du din Android Kernel til den nyeste Linux-stabil

Vi har dækket guider på Android-kerner, såsom "Sådan bygger du en brugerdefineret kerne" og "Bedste brugerdefinerede kerner til Android", men i dag vil vi vise dig, hvordan du opstrømmer din kerne mod den nyeste Linux-stal.

Vær opmærksom på, at dette er avancerede ting - hvis du aldrig har samlet en kerne før, skal du følge guiden "Sådan oprettes en brugerdefineret kerne", der er linket ovenfor, og denne vejledning vil omfatte cherry-picking og fusionering af forpligtelser fra den nyeste Linux- stabil kerne med din Android-kerne, før du kompilerer den.

Opstrømning af din Android-kerne til den nyeste Linux-stal har en masse positive fordele, såsom at være up-to-date med de seneste sikkerhedsforpligtelser og bugfixes - vi forklarer nogle af fordele og ulemper senere i denne vejledning.

Hvad er Linux-stabil kerne?

Linux-stabil, som navnet antyder, er den stabile arm i Linux-kernen. Den anden arm er kendt som ”hovedline”, som er mastergrenen . Al Linux-kerneudvikling sker i mainline og følger generelt denne proces:

Linus Torvalds tager et stykke plaster fra sine vedligeholdere i to uger.
Efter disse to uger frigiver han en rc1 (f.eks. 4.14-rc1) kerne.
For hver uge i de næste 6-8 uger frigiver han en anden RC (f.eks. 4.14-rc2, 4.14-rc3, osv.) Kerne, der KUN indeholder bug- og regressionsrettelser.
Når det anses for stabilt, frigives det som en tarball til download på org (f.eks. 4.14).

Hvad er LTS-kerner?

Hvert år vælger Greg en kerne og opretholder den i enten to år (LTS) eller seks år (forlænget LTS). Disse er designet til at have produkter, der har behov for stabilitet (som Android-telefoner eller andre IOT-enheder). Processen er nøjagtig den samme som ovenfor, den sker bare i længere tid. Der er i øjeblikket seks LTS-kerner (som altid kan ses på kernel.org-udgivelsessiden):

4.14 (LTS), vedligeholdt af Greg Kroah-Hartman
4, 9 (LTS), vedligeholdt af Greg Kroah-Hartman
4.4 (eLTS), vedligeholdt af Greg Kroah-Hartman
4.1 (LTS), vedligeholdt af Sasha Levin
3, 16 (LTS), vedligeholdt af Ben Hutchings
3, 2 (LTS), vedligeholdt af Ben Hutchings

Hvad er fordelene ved at opstrømme min Android-kerne til Linux Stable?

Når vigtige sårbarheder afsløres / rettes, er de stabile kerner de første, der får dem. Din Android-kerne vil således være meget sikrere mod angreb, sikkerhedsfejl og bare fejl generelt.

Linux-stalden indeholder rettelser til mange drivere, som min Android-enhed ikke bruger, er det for det meste ikke unødvendigt?

Ja og nej, afhængigt af hvordan du definerer "det meste". Linux-kernen kan indeholde en masse kode, der går ubrugt i Android-systemet, men det garanterer ikke, at der ikke vil være nogen konflikter fra disse filer, når nye versioner fusioneres! Forstå, at næsten ingen bygger hver eneste del af kernen, ikke engang de mest almindelige Linux-distros som Ubuntu eller Mint. Dette betyder ikke, at du ikke bør tage disse rettelser, fordi der ER RETNINGER til drivere, du Kører . Tag for eksempel arm / arm64 og ext4, som er henholdsvis den mest almindelige Android-arkitektur og filsystem. I 4.4 fra 4.4.78 (version af det nyeste Oreo CAF-tag) til 4.4.121 (seneste opstrøms-tag) er disse følgende numre for disse systemers forpligtelser:

 ~ / 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 / arm | wc -l58 ~ / kernels / linux-stable (master) $ git log - format =% h v4.4.78..v4.4.121 arch / arm64 | wc -l22 via ~ / kernels / linux-stable (master) $ git log - format =% h v4.4.78..v4.4.121 fs / ext4 | wc -l18

Den mest tidskrævende del er den første opstart; når du først er helt opdateret, tager det overhovedet ikke tid at fusionere i en ny udgave, der normalt ikke indeholder mere end 100 forpligtelser. Fordelene, som dette medfører (mere stabilitet og bedre sikkerhed for dine brugere), skal dog kræve denne proces.

Sådan flettes Linux Stable Kernel til en Android Kernel

Først skal du finde ud af, hvilken kerneversion din Android-enhed kører.

Så trivielt som dette ser ud, er det nødvendigt at vide, hvor du skal begynde. Kør følgende kommando i dit kernetræ:

 Lav kernelversion

Det returnerer den version, du er på. De to første numre bruges til at finde ud af, hvilken gren du har brug for (f.eks. Linux-4.4.y for en hvilken som helst 4.4-kerne), og det sidste nummer vil blive brugt til at bestemme, hvilken version du har brug for at starte med fusion (f.eks. Hvis du er på 4.4 .21, skal du flette 4.4.22 næste).

Grib den nyeste kernekilde fra kernel.org

kernel.org huser den nyeste kernekilde i det Linux-stabile arkiv. Nederst på siden er der tre hentningslinks. Efter min erfaring har Googles spejl en tendens til at være den hurtigste, men dine resultater kan variere. Kør følgende kommandoer:

 git remote tilføj linux-stable //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit hente linux-stable

Bestem, om du vil flette hele kernen eller kirsebær-vælg forpligtelserne

Derefter skal du vælge, om du vil flette forpligtelserne eller kirsebærplukket. Her er fordele og ulemper ved hver enkelt, og hvornår du måske ønsker at gøre dem.

BEMÆRK: Hvis din kerne-kilde er i form af en tarball, er du sandsynligvis nødt til at kirsebærplukke, ellers får du tusinder af filkonflikter, fordi git udfylder historien baseret på opstrøms, ikke hvad OEM eller CAF har ændret. Spring bare til trin 4.

Cherry-picking:

Fordele:

Nemmere at løse konflikter, da du ved nøjagtigt, hvilken konflikt der forårsager et problem.
Nemmere at rebase, da hver begå er på sin egen.
Nemmere at halvere, hvis der opstår problemer

Ulemper:

Det tager længere tid, da hver forpligtelse skal vælges individuelt.
Lidt vanskeligere at se, om engagement er fra opstrøms ved første øjekast

Fusionere

Fordele :

Det er hurtigere, da du ikke behøver at vente på, at alle de rene lapper smelter sammen.
Det er lettere at se, når en forpligtelse er fra opstrøms, da du ikke vil være pendleren, den opstrøms vedligeholder vil være.

Ulemper:

Det kan være lidt mere vanskeligt at løse konflikter, da du bliver nødt til at slå op, hvilke begåber, der forårsager konflikten ved hjælp af git-log / git-skyld, det vil ikke direkte fortælle dig.
Genfasning er vanskeligt, da du ikke kan omfatte en fusion, det vil tilbyde at kirsebær-plukke alle engagementer individuelt. Du bør dog ikke genfase ofte, men i stedet bruge git revert og git fusion, hvor det er muligt.

Jeg vil anbefale at udføre en kirsebærpluk for at finde ud af eventuelle problemkonflikter oprindeligt, foretage en fletning og derefter vende tilbage om problemet begår bagefter, så opdateringen er lettere (da sammenlægning er hurtigere efter at være opdateret).

Føj forpligtelserne til din kilde, en version ad gangen

Den vigtigste del af denne proces er den ene version ad gangen. Der kan muligvis være et problemopdatering i din opstrøms serie, som kan forårsage et problem med at starte eller ødelægge noget som lyd eller opladning (forklaret i afsnittet med tip og tricks). Det er vigtigt at udføre inkrementelle versionændringer af denne grund, det er lettere at finde et problem i 50 forpligtelser end op mod 2000 forpligtelser for nogle versioner. Jeg vil kun anbefale at udføre en fuld fusion, når du kender alle problemerne, der er begået og konfliktløsninger.

Cherry-picking

Format:

 git cherry-pick ..

Eksempel:

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

Fusionere

Format:

 git fusion

Eksempel:

git merge v3.10.74

Jeg anbefaler, at du holder styr på konflikterne i fletningsforpligtelser ved at fjerne #-markørerne.

Sådan løses konflikter

Vi kan ikke give en trinvis vejledning til løsning af hver enkelt konflikt, da det involverer et godt kendskab til C-sprog, men her er et par tip.

Hvis du fusionerer, skal du finde ud af, hvad der begår, der forårsager konflikten. Du kan gøre dette på en af to måder:

git log -pv $ (foretag kernelversion) .. for at få ændringerne mellem din nuværende version og den seneste fra opstrøms. Flagget -p giver dig de ændringer, der er foretaget af hver forpligtelse, så du kan se.
Kør git skyld på filen for at få hasherne for hver begå i området. Du kan derefter køre git show –format = fyldigere for at se, om pendleren stammer fra mainline / stable, Google eller CodeAurora.

Find ud af, om du allerede har forpligtelsen. Nogle leverandører som Google eller CAF vil forsøge at kigge opstrøms for kritiske fejl, som f.eks. Dirty COW-fixen, og deres backports kan komme i konflikt med upstream's. Du kan køre git-log –grep = ”” og se, om det returnerer noget. Hvis det gør det, kan du springe engagementet over (hvis cherry-picking vha. Git reset –hard && git cherry-pick –continue) eller ignorere konflikterne (fjern <<<<< >>>>>).
Find ud af, om der har været en backport, der messer opløsningen. Google og CAF vil gerne backportere visse patches, som stabil ikke ville have. Stabil vil ofte være nødt til at tilpasse opløsningen af mainline-forpligtelsen til fraværet af visse programrettelser, som Google vælger for backport. Du kan se på mainline-tilsagnet ved at køre git-show (mainline-hash vil være tilgængelig i engagement-meddelelsen om den stabile commit). Hvis der er en backport, der klipper det, kan du enten kassere ændringerne, eller du kan bruge mainline-versionen (hvilket er, hvad du normalt skal bruge).
Læs, hvad engagement forsøger at gøre, og se, om problemet allerede er løst. Nogle gange kan CAF løse en fejl uafhængigt af opstrøms, hvilket betyder, at du enten kan overskrive deres rettelse til opstrøms eller kassere den, som ovenfor.

Ellers kan det bare være et resultat af en CAF / Google / OEM-tilføjelse, i hvilket tilfælde du bare skal blande nogle ting rundt.

Her er et spejl på det Linux-stabile kernel.org-arkiv på GitHub, som kan være nemmere at finde frem til commit-lister og adskiller sig til konfliktløsning. Jeg anbefaler, at du først går til oversigtslistelisten og lokaliserer problemet forpligtig for at se den originale diff for at sammenligne den med din.

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

Du kan også gøre det via kommandolinjen:

 git log .. git show

At løse beslutninger handler om sammenhæng. Hvad du ALTID skal gøre, er at sikre dig, at din endelige diff stemmer overens med opstrøms ved at køre følgende kommandoer i to separate vinduer:

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

Aktivér rerere

Git har en funktion kaldet rerere (står for Genbrug optaget opløsning), hvilket betyder, at når den registrerer en konflikt, registrerer den, hvordan du løste den, så du kan genbruge den senere. Dette er især nyttigt for både kroniske rebasere med både fusion og kirsebærplukning, da du bare bliver nødt til at køre git add. && git - Fortsæt, når du gør om opstrøms opbremsning, da konflikten vil blive løst, hvordan du tidligere har løst den.

Det kan aktiveres ved at køre følgende kommando i din kerne repo:

 git config rerere.enabled sandt

Sådan får du halvering, når du løber ind i en compiler- eller runtime-fejl

I betragtning af at du tilføjer et betydeligt antal forpligtelser, er det meget muligt for dig at introducere en compiler- eller runtime-fejl. I stedet for bare at give op, kan du bruge Gits indbyggede halveringsværktøj til at finde ud af årsagen til problemet! Ideelt set bygger du og blinker hver enkelt kerneversion, mens du tilføjer den, så at halvering vil tage kortere tid om nødvendigt, men du kan halvere 5000 forpligtelser uden problemer.

Hvad git bisect vil gøre er at tage en række forpligtelser, fra hvor emnet er til stede til hvor det ikke var til stede, og derefter begynde at halvere engagementsområdet, så du kan bygge og teste og fortælle det, om det er godt eller ikke . Det fortsætter med dette, indtil det spytter ud den forpligtelse, der forårsager dit problem. På det tidspunkt kan du enten rette det eller vende det tilbage.

Start halvering: git bisect start
Mærk den aktuelle revision som dårlig: git bisect bad
Mærk en revision som god: git bisect good
Byg med den nye revision
Baseret på resultatet (hvis problemet er til stede eller ikke), fortæl git: git bisect good ELLER git bisect bad
Skyl og gentag trin 4-5, indtil problemet begås er fundet!
Tilbage eller rettelse af problemet begå.

BEMÆRK: Fusioner bliver nødt til midlertidigt at køre git-rebase -i for at anvende alle programrettelser på din gren for at få en korrekt halvering, da halvering med de fusioner, der er på plads, ofte tjekker ud på opstrøms forpligtelser, hvilket betyder, at du ikke har nogen af de Android-specifikke forpligtelser. Jeg kan gå nærmere ind på dette efter anmodning, men stol på mig, det er nødvendigt. Når du har identificeret problemet begår, kan du vende det tilbage eller omlægge det til fusionen.

Squash IKKE opstrømsopdateringer

Mange nye udviklere fristes til at gøre dette, da det er “renere” og “lettere” at styre. Dette er forfærdeligt af nogle få grunde:

Forfatterskab går tabt. Det er uretfærdigt over for andre udviklere at få deres kredit tilført deres arbejde.
At halde sig er umuligt. Hvis du sprænger en række forpligtelser, og noget er et problem i den serie, er det umuligt at fortælle, hvad engagement forårsager et problem i et squash.
Fremtidige kirsebærpluk er sværere. Hvis du er nødt til at omfatte med en klemt serie, er det vanskeligt / umuligt at se, hvor en konflikt er resultatet af.

Abonner på Linux Kernel-adresselisten for rettidige opdateringer

For at blive underrettet, når der er en opstrøms opdatering, kan du abonnere på linux-kernel-annoncere listen. Dette giver dig mulighed for at få en e-mail hver gang en ny kerne frigives, så du kan opdatere og skubbe så hurtigt som muligt.