Så här uppdaterar du din Android-kärna till senaste Linux-stabila

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 tidskrävande delen är den första uppfostringen; när du väl är helt uppdaterad tar det ingen tid alls att slå samman en ny version, som vanligtvis inte innehåller mer än 100 åtaganden. Fördelarna med detta (mer stabilitet och bättre säkerhet för dina användare) bör dock kräva denna process.

Hur man slår samman Linux-stabil kärna till en Android-kärna

Först måste du ta reda på vilken kärnversion din Android-enhet kör.

Så trivialt som detta verkar är det nödvändigt att veta var du behöver börja. Kör följande kommando i ditt kärnträd:

göra kärnversion

Den returnerar den version du använder. De två första siffrorna kommer att användas för att räkna ut den gren du behöver (t.ex. linux-4.4.y för vilken 4.4-kärna som helst) och det sista numret kommer att användas för att avgöra vilken version du behöver för att börja slå samman (t.ex. om du är på 4.4 .21 kommer du att slå samman 4.4.22 nästa).

Ta den senaste kärnkällan från kernel.org

kernel.org innehåller den senaste kärnkällan i det Linux-stabila förvaret . Längst ner på den sidan kommer det att finnas tre hämtningslänkar. Enligt min erfarenhet tenderar Googles spegel att vara snabbast men dina resultat kan variera. Kör följande kommandon:

git fjärrkontroll lägg till linux-stabil https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit hämta linux-stabil

Bestäm om du vill slå samman hela kärnan eller körplocka åtagandena

Därefter måste du välja om du vill slå samman åtaganden eller körsbärsplockning. Här är fördelarna och nackdelarna med var och en när du kanske vill göra dem.

NOTERA: Om din kärnkälla är i form av en tarball, kommer du troligen att behöva körsbärsplocka, annars kommer du att få tusentals filkonflikter eftersom git fyller historien uteslutande baserat på uppströms, inte vad OEM eller CAF har förändrat. Hoppa bara till steg 4.

Körsbärsplockning:

Fördelar:

• Lättare att lösa konflikter eftersom du vet exakt vilken konflikt som orsakar ett problem.
• Lättare att återfå eftersom varje åtagande är ensam.
• Lättare att halvera om du stöter på problem

Nackdelar:

• Det tar längre tid eftersom varje åtagande måste väljas individuellt.
• Lite svårare att säga om engagemang är från uppströms vid första anblicken

Gå

Fördelar :

• Det går snabbare eftersom du inte behöver vänta tills alla rena fläckar slås samman.
• Det är lättare att se när ett engagemang kommer från uppströms eftersom du inte kommer att göra det, utan upprätthållaren kommer att vara.

Nackdelar:

• Att lösa konflikter kan vara lite svårare eftersom du kommer att behöva leta upp vilket åtagande som orsakar konflikten med git log / git-skuld, det kommer inte att berätta för dig direkt.
• Omgraderingen är svår eftersom du inte kan ompröva en sammanslagning, den kommer att erbjuda dig att plocka upp alla åtaganden individuellt. Du bör emellertid inte basa om ofta utan istället använda git revert och git merge där det är möjligt.

Jag rekommenderar att du gör en körsbärsplockning för att ta reda på eventuella problemkonflikter från början, göra en sammanslagning och sedan återställa problemet som görs efteråt så att uppdateringen blir enklare (eftersom sammanslagningen går snabbare efter att ha varit uppdaterad).

Lägg till åtagandena till din källa, en version i taget

Den viktigaste delen av denna process är den ena versionen i taget. Det KAN finnas en problemkorrigering i din uppströmsserie, som kan orsaka problem med att starta eller bryta något som ljud eller laddning (förklaras i avsnittet tips och tricks). Att göra inkrementella versionändringar är viktigt av den anledningen, det är lättare att hitta ett problem i 50 åtaganden än upp till 2000 åtaganden för vissa versioner. Jag skulle bara rekommendera att göra en fullständig sammanslagning när du förstår alla problem och konfliktlösningar.

Körsbärsplockning

Formatera:

git cherry pick ...

Exempel:

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

Gå

Formatera:

gå samman

Exempel:

git merge v3.10.74

Jag rekommenderar att du håller koll på konflikterna i sammanslagningsförpliktelser genom att ta bort # -markörerna.

Hur man löser konflikter

Vi kan inte ge en steg-för-steg-guide för att lösa varje enskild konflikt, eftersom det handlar om goda kunskaper i C-språket, men här är några tips.

Om du går ihop, ta reda på vad som gör orsaken till konflikten. Du kan göra detta på två sätt:

1. git log -p v $ (gör kernelversion) .. för att få ändringarna mellan din nuvarande version och den senaste från uppströms. Flaggan -p ger dig de ändringar som gjorts av varje engagemang så att du kan se.
2. Kör git-skuld på filen för att få hasharna för varje åtagande i området. Du kan sedan köra git show –format = fullare för att se om kommitören var från mainline / stable, Google eller CodeAurora.

• Ta reda på om du redan har åtagandet. Vissa leverantörer som Google eller CAF kommer att försöka leta uppströms efter kritiska buggar, som Dirty COW-korrigeringen, och deras bakportar kan komma i konflikt med uppströms. Du kan köra git log –grep = ”” och se om den returnerar något. Om den gör det kan du hoppa över engagemanget (om körsbärsplockning med git reset –hard && git körsbärsplockning - fortsätt) eller ignorera konflikterna (ta bort<<<<<>>>>>).
• Ta reda på om det har funnits en backport som förstör upplösningen. Google och CAF gillar att backportera vissa korrigeringar som inte fungerar. Stabilt kommer ofta att behöva anpassa upplösningen från huvudlinjen för att avlägsna vissa korrigeringar som Google väljer att backport. Du kan titta på mainline commit genom att köra git show (mainline hash kommer att finnas tillgängligt i commit-meddelandet för det stabila commitet). Om det finns en backport som förstör det kan du antingen kasta bort ändringarna eller så kan du använda huvudversionen (vilket är vad du vanligtvis behöver göra).
• Läs vad engagemanget försöker göra och se om problemet redan är löst. Ibland kan CAF fixa ett fel oberoende av uppströms, vilket innebär att du antingen kan skriva över deras fix för uppströms eller kasta det, som ovan.

Annars kan det bara vara ett resultat av ett CAF / Google / OEM-tillägg, i vilket fall du bara behöver blanda några saker runt.

Här är en spegel av det linux-stabila kernel.org-förvaret på GitHub, vilket kan vara lättare att leta upp engagemangslistor och skiljer sig åt för konfliktlösning. Jag rekommenderar att du går till listan över kommit först och lokaliserar problemförpliktelsen för att se den ursprungliga skillnaden för att jämföra den med din.

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

Du kan också göra det via kommandoraden:

git log .. git show

Att lösa resolutioner handlar om sammanhang. Vad du bör göra är ALLTID att se till att din sista skillnad matchar uppströms genom att köra följande kommandon i två separata fönster:

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

Aktivera omdirigering

Git har en funktion som heter rerere (står för Reuse Recorded Resolution), vilket innebär att när den upptäcker en konflikt kommer den att registrera hur du löste den så att du kan återanvända den senare. Detta är särskilt användbart för både kroniska rebasers med både sammanslagning och körsbärsplockning eftersom du bara behöver köra git add. && git - fortsätt när du gör om uppströmsuppdraget eftersom konflikten kommer att lösas hur du tidigare löste den.

Det kan aktiveras genom att köra följande kommando i din kärnrepa:

git config rerere.enabled true

Hur man git bisect när man stöter på en kompilator eller runtime-fel

Med tanke på att du kommer att lägga till ett betydande antal åtaganden är det mycket möjligt för dig att införa ett kompilator- eller runtime-fel. Istället för att bara ge upp kan du använda gits inbyggda halvaverktyg för att ta reda på orsaken till problemet! Helst kommer du att bygga och blinka varje enskild kärnaversion när du lägger till den så att halvering tar mindre tid om det behövs men du kan halvera 5000 åtaganden utan några problem.

Vad git bisect kommer att göra är att ta en rad åtaganden, varifrån problemet är närvarande till var det inte var närvarande, och sedan börja halvera engagemangsområdet, så att du kan bygga och testa och låta det veta om det är bra eller inte . Det kommer att fortsätta tills det spitar ut det åtagande som orsakar ditt problem. Vid den tiden kan du antingen fixa det eller återställa det.

1. Börja halvera: git halva igång
2. Märk den aktuella versionen som dålig: git bisect dålig
3. Märk en revision som bra: git bisect bra
4. Bygg med den nya versionen
5. Baserat på resultatet (om problemet är närvarande eller inte), berätta för git: git bisect bra ELLER git bisect dåligt
6. Skölj och upprepa steg 4-5 tills problemet har hittats!
7. Återställ eller åtgärda problemet.

NOTERA: Fusioner måste tillfälligt köra git rebase -i för att tillämpa alla korrigeringsfiler på din filial för korrekt genomskärning, eftersom genomskärning med sammanslagningarna på plats ofta kommer att checka ut på uppströmsförpliktelser, vilket innebär att du inte har någon av Android-specifika åtaganden. Jag kan gå djupare in på detta på begäran men lita på mig, det behövs. När du har identifierat problemåtgärden kan du återställa eller omformulera det till sammanslagningen.

Squash INTE uppdateringar uppströms

Många nya utvecklare är frestade att göra detta eftersom det är 'renare' och 'lättare' att hantera. Det är hemskt av några anledningar:

• Författarskapet är förlorat. Det är orättvist för andra utvecklare att få sin kredit för sitt arbete.
• Halvering är omöjligt. Om du squashar en serie av åtaganden och något är ett problem i den serien är det omöjligt att berätta vad begår orsakade ett problem i en squash.
• Framtida körsbärsplockningar är svårare. Om du behöver starta om med en squashed-serie är det svårt / omöjligt att säga var en konflikt härrör från.

Prenumerera på e-postlistan för Linux Kernel för uppdateringar i rätt tid

För att få ett meddelande när det finns en uppdatering uppströms, prenumerera på listan linux-kernel-announce . Detta gör att du kan få ett e-postmeddelande varje gång en ny kärna släpps så att du kan uppdatera och trycka så snabbt som möjligt.