Sådan opdateres din Android-kerne til nyeste Linux-stabil

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

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

Sådan flettes Linux-stabil kerne til en Android-kerne

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

Den returnerer den version, du er på. De to første tal vil blive brugt til at finde ud af den 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 skal starte med at flette (f.eks. Hvis du er på 4.4 .21, vil du fusionere 4.4.22 næste).

Grib den nyeste kernekilde fra kernel.org

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

git remote tilføje linux-stabilt https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit hente linux-stabilt

Beslut om du vil flette hele kernen eller kirsebærpluk forpligter

Dernæst bliver du nødt til at vælge, om du vil flette forpligtelserne eller kirsebærpluk. Her er fordele og ulemper ved hver, og hvornår du måske vil gøre det.

BEMÆRK: Hvis din kernekilde er i form af en tarball, skal du sandsynligvis cherry-pick, ellers får du tusindvis af filkonflikter, fordi git udfylder historien udelukkende baseret på upstream, ikke hvad OEM eller CAF har ændret. Gå bare til trin 4.

Kirsebærplukning:

Fordele:

• Lettere at løse konflikter, da du ved nøjagtigt, hvilken konflikt der forårsager et problem.
• Lettere at rebase, da hver forpligtelse er alene.
• Lettere at skære, hvis der løber ind i problemer

Ulemper:

• Det tager længere tid, da hver forpligtelse skal vælges individuelt.
• Lidt sværere at vide, om forpligtelse er fra opstrøms ved første øjekast

Gå

Fordele :

• Det er hurtigere, da du ikke behøver at vente på, at alle de rene patches er slået sammen.
• Det er lettere at se, hvornår en forpligtelse er fra opstrøms, da du ikke vil være kommitter, den opstrøms vedligeholder vil være.

Ulemper:

• Det kan være lidt sværere at løse konflikter, da du bliver nødt til at slå op, hvilken forpligtelse der forårsager konflikten ved hjælp af git log / git-skyld, det fortæller dig ikke direkte.
• Ombasering er vanskelig, da du ikke kan omlægge en fletning, det vil tilbyde at kirsebærplukke alle forpligtelserne individuelt. Du bør dog ikke rebase ofte, i stedet for at bruge git revert og git merge, hvor det er muligt.

Jeg vil anbefale at udføre en cherry-pick for at finde ud af eventuelle problemkonflikter oprindeligt, foretage en fletning og derefter vende tilbage til problemet, der forpligter sig bagefter, så opdatering er lettere (da fletning 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 problem patch i din opstrøms serie, som kan forårsage et problem med opstart eller bryde noget som lyd eller opladning (forklaret i afsnittet tip og tricks). Det er vigtigt at foretage trinvise versionændringer af denne grund. Det er lettere at finde et problem i 50 commits end op til 2000 commits for nogle versioner. Jeg vil kun anbefale at foretage en fuld fusion, når du kender alle problemerne og konfliktløsningerne.

Cherry-picking

Format:

git cherry-pick ..

Eksempel:

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

Gå

Format:

gå flet

Eksempel:

git merge v3.10.74

Jeg anbefaler at holde styr på konflikterne i fusionsforpligtelser 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 er årsag til konflikten. Du kan gøre dette på to måder:

1. git log -p v $ (make kernelversion) .. for at få ændringerne mellem din nuværende version og den nyeste fra upstream. Flagget -p giver dig de ændringer, der er foretaget af hver forpligtelse, så du kan se.
2. Kør git-skyld på filen for at få hashes af hver begåelse i området. Du kan derefter køre git show –format = fyldigere for at se, om kommitteren var 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-rettelsen, og deres backports kan være i konflikt med upstreams. Du kan køre git log –grep = ”” og se om den returnerer noget. Hvis det gør det, kan du springe over forpligtelsen (hvis kirsebærplukning ved hjælp af git reset –hard && git kirsebærpluk – fortsæt) eller ignorerer konflikterne (fjern<<<<<>>>>>).
• Find ud af, om der har været en bagport, der ødelægger opløsningen. Google og CAF bakker gerne op om visse rettelser, der ikke er stabile. Stabil har ofte brug for at tilpasse opløsningen af ​​hovedlinjen forpligte sig til afbrydelsen af ​​visse programrettelser, som Google vælger at bakke. Du kan se på mainline-forpligtelsen ved at køre git show (mainline-hash'en vil være tilgængelig i commit-meddelelsen til den stabile commit). Hvis der er en backport, der ødelægger det, kan du enten kassere ændringerne, eller du kan bruge hovedlineversionen (hvilket er det, du normalt skal gøre).
• Læs, hvad forpligtelsen forsøger at gøre, og se om problemet allerede er løst. Nogle gange kan CAF rette en fejl uafhængig 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 af det linux-stabile kernel.org-lager på GitHub, hvilket kan være nemmere for at finde op på lister over forpligtelser og diffs for konfliktløsning. Jeg anbefaler, at du først går til listen over forpligtelseslister og finder problemet, for at se den oprindelige diff for at 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å gøre det via kommandolinjen:

git log .. git show

At løse opløsninger handler om kontekst. Hvad du ALTID skal gøre er at sørge for, at din sidste diff matcher upstream ved at kø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)

Aktivér omvendt

Git har en funktion kaldet rerere (står for Reuse Recorded Resolution), hvilket betyder, at når den opdager 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 fletning og kirsebærplukning, da du bare skal køre git add. && git - fortsæt, når du gentager upstream-bringingen, da konflikten løses, hvordan du tidligere løste den.

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

git config rerere.enabled sand

Sådan gits bisect, når du løber ind i en kompilator eller runtime-fejl

Da du tilføjer et betydeligt antal forpligtelser, er det meget muligt for dig at introducere en kompilator- eller runtime-fejl. I stedet for bare at give op, kan du bruge gits indbyggede bisect-værktøj til at finde ud af årsagen til problemet! Ideelt set vil du opbygge og blinke hver eneste kerneversion, når du tilføjer den, så halvering tager mindre tid, hvis det er nødvendigt, men du kan halvere 5000 forpligtelser uden problemer.

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

1. Start halvering: git halvering start
2. Mærk den aktuelle revision som dårlig: git bisect dårlig
3. Mærk en revision som god: git bisect god
4. Byg med den nye revision
5. Baseret på resultatet (hvis problemet er til stede eller ej), fortæl git: git bisect god ELLER git bisect dårlig
6. Skyl og gentag trin 4-5, indtil problemet er fundet!
7. Gendan eller rette problemforpligtelsen.

BEMÆRK: Fusioner bliver nødt til midlertidigt at køre git rebase -i for at anvende alle patches på din filial for korrekt gennemskæring, da deling med fusionerne på plads ofte vil betale til upstream-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 problemforpligtelsen, kan du tilbageføre eller omformulere det til fusionen.

Squash IKKE opstrømsopdateringer

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

• Forfatterskab er tabt. Det er uretfærdigt over for andre udviklere at få deres kredit afsat for deres arbejde.
• Halvering er umulig. Hvis du squasher en række forpligtelser, og noget er et problem i den serie, er det umuligt at fortælle, hvad begivenheden forårsagede et problem i en squash.
• Fremtidige kirsebærvalg er sværere. Hvis du har brug for at rebase med en squashed serie, er det svært / umuligt at fortælle, hvor en konflikt skyldes.

Abonner på Linux Kernel-postlisten for rettidige opdateringer

For at blive underrettet, når der er en upstream-opdatering, skal du abonnere på listen over Linux-kernel-announce . 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.