Hur du uppdaterar din Android Kernel till den senaste Linux-stabiliteten

Vi har täckt guider för Android-kärnor, till exempel "Hur man bygger en anpassad kärna" och "Bästa anpassade kärnor för Android", men idag ska vi visa dig hur du strömmar upp din kärna mot den senaste Linux-stallen.

Vänligen veta att det här är avancerade grejer - om du aldrig har sammanställt en kärna tidigare, bör du följa guiden "Hur man bygger en anpassad kärna" länkad ovan, och den här guiden kommer att involvera körsbärsplockning och sammanslagningsåtaganden från den senaste Linux- stabil kärna med din Android-kärna innan du sammanställer den.

Att uppgradera din Android-kärna till den senaste Linux-stallen har många positiva fördelar, som att vara uppdaterad med de senaste säkerhetsåtgärderna och bugfixes - vi förklarar några av för- och nackdelarna senare i den här guiden.

Vad är Linux-stabil kärna?

Linux-stabil som namnet antyder är Linux-kärnans stabila arm. Den andra armen kallas ”mainline”, som är mästarkontoret . All Linux-kärnutveckling sker i huvudlinjen och följer i allmänhet denna process:

  1. Linus Torvalds tar en massa lappar från sina underhållare i två veckor.
  2. Efter dessa två veckor släpper han en rc1 (t.ex. 4.14-rc1) kärna.
  3. För varje vecka under de kommande 6-8 veckorna kommer han att släppa ytterligare en RC-kärna (t.ex. 4.14-rc2, 4.14-rc3, etc), som innehåller ENDAST bug och regression fixes.
  4. När den anses stabil kommer den att släppas som en tarball för nedladdning på org (t.ex. 4.14).

Vad är LTS-kärnor?

Varje år plockar Greg en kärna och underhåller den antingen två år (LTS) eller sex år (utökad LTS). Dessa är utformade för att ha produkter som behöver stabilitet (som Android-telefoner eller andra IOT-enheter). Processen är exakt samma som ovan, det händer bara under längre tid. Det finns för närvarande sex LTS-kärnor (som alltid kan ses på kernel.org-utgåssidan):

  • 4.14 (LTS), upprätthålls av Greg Kroah-Hartman
  • 4, 9 (LTS), upprätthålls av Greg Kroah-Hartman
  • 4.4 (eLTS), upprätthålls av Greg Kroah-Hartman
  • 4.1 (LTS), underhållen av Sasha Levin
  • 3, 16 (LTS), underhållen av Ben Hutchings
  • 3, 2 (LTS), underhållen av Ben Hutchings

Vilka är fördelarna med att uppströma min Android-kärna till Linux Stable?

När viktiga sårbarheter avslöjas / fixas är de stabila kärnorna de första som får dem. Således kommer din Android-kärna att vara mycket säkrare mot attacker, säkerhetsbrister och bara buggar i allmänhet.

Linux-stallen innehåller korrigeringar för många drivrutiner som min Android-enhet inte använder, är det inte mest nödvändigt?

Ja och nej, beroende på hur du definierar "mestadels". Linux-kärnan kan innehålla en hel del kod som går oanvända i Android-systemet, men det garanterar inte att det inte kommer att finnas några konflikter från dessa filer när man slår ihop nya versioner! Förstå att praktiskt taget ingen bygger varje enskild del av kärnan, inte ens de vanligaste Linux-distrosna som Ubuntu eller Mint. Det betyder inte att du inte bör ta dessa korrigeringar eftersom det finns FÖRSLAG för drivrutiner du KÖR . Ta till exempel arm / arm64 och ext4, som är den vanligaste Android-arkitekturen respektive filsystemet. I 4.4, från 4.4.78 (version av den senaste Oreo CAF-taggen) till 4.4.121 (senaste uppströmstaggen), är dessa följande nummer för åtaganden för dessa system:

 ~ / kernels / linux-stable (master) $ git log - format =% h v4.4.78..v4.4.121 | wc -l2285 postskyddad ~ / kernels / linux-stable (master) $ git log - format =% h v4.4.78..v4.4.121 arch / arm | wc -l58 postskyddad ~ / kernels / linux-stable (master) $ git log - format =% h v4.4.78..v4.4.121 arch / arm64 | wc -l22 postskyddad ~ / 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 uppväxten; när du väl är uppdaterad tar det ingen tid att slå sig samman i 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 smälter Linux Stable Kernel till en Android Kernel

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ör kärnversion 

Det kommer att returnera versionen du är på. 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 alla 4.4-kärnor) och det sista numret kommer att användas för att avgöra vilken version du behöver för att börja med att slå samman (t.ex. om du är på 4.4 .21, du kommer att slå samman 4.4.22 nästa).

Ta tag i den senaste källkällan från kernel.org

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

 git remote lägg till linux-stable //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit hämta linux-stable 

Bestäm om du vill slå samman hela kärnan eller plocka körsbär

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

OBS: Om din kärnkälla är i form av en tarball, kommer du troligtvis att behöva cherry-pick, annars kommer du att få tusentals filkonflikter eftersom git fyller historien baserat på uppströms, inte vad OEM eller CAF har ändrats. 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 omplacera eftersom varje begå är på egen hand.
  • 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

Sammanfoga

Fördelar :

  • Det är snabbare eftersom du inte behöver vänta på att alla rena fläckar smälter samman.
  • Det är lättare att se när ett engagemang är från uppströms eftersom du inte kommer att vara pendlare, uppströmsunderhållaren kommer att vara.

Nackdelar:

  • Att lösa konflikter kan vara lite svårare eftersom du kommer att behöva leta upp vilka åtaganden som orsakar konflikten med git-logg / git-skuld, det kommer inte direkt att berätta för dig.
  • Återföra är svårt eftersom du inte kan omfasera en sammanslagning, det kommer att erbjuda att körsbär plocka alla åtaganden individuellt. Du bör emellertid inte återföra ofta, istället använda git revert och git fusion där det är möjligt.

Jag skulle rekommendera att du gör en körsbärsplockning för att ta reda på eventuella problemkonflikter initialt, göra en sammanslagning, och sedan återgå till problemet begås efteråt så att uppdateringen är enklare (eftersom sammanslagning är snabbare efter att ha varit uppdaterad).

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

Den viktigaste delen av denna process är versionen i taget. Det kan finnas problem i din uppströms serie, vilket kan orsaka problem med att starta upp eller bryta något som ljud eller laddning (förklaras i avsnittet tips och tricks). Att göra stegvisa versionändringar är viktigt av detta skäl, det är lättare att hitta ett problem i 50 åtaganden än uppåt 2000 åtaganden för vissa versioner. Jag skulle bara rekommendera att göra en fullständig sammanslagning när du vet att alla problem begår och konfliktlösningar.

Körsbärsplockning

Formatera:

 git cherry-pick .. 

Exempel:

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

Sammanfoga

Formatera:

 git fusionera 

Exempel:

git merge v3.10.74

Jag rekommenderar att du håller reda på konflikterna i sammanslagningsåtgärder genom att ta bort markeringarna #.

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 innebär god kunskap om C-språk, men här är några tips.

Om du går samman, räkna ut vad som begår som orsakar konflikten. Du kan göra detta på två sätt:

  1. git log -pv $ (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 åtagande så att du kan se.
  2. Kör lite skylt på filen för att få hasherna för varje begå i området. Du kan sedan köra git show –format = fullare för att se om pendlaren 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 den smutsiga COW-fixen, och deras backportar kan komma i konflikt med uppströms. Du kan köra git log –grep = ”” och se om det returnerar något. Om det gör det, kan du hoppa över engagemanget (om körsbärsplockning med git reset –hard && git cherry-pick – fortsätt) eller ignorera konflikterna (ta bort <<<<< >>>>>).
  • Ta reda på om det har funnits en backport som raderar upplösningen. Google och CAF vill återrapportera vissa korrigeringar som stabil inte skulle göra. Stabil kommer ofta att behöva anpassa upplösningen av huvudlinjen förpliktar sig till frånvaron av vissa korrigeringar som Google väljer att backport. Du kan titta på mainline-åtagandet genom att köra git-show (mainline-hash kommer att finnas tillgängligt i engagemangsmeddelandet för den stabila commit). Om det finns en backport som krossar det, kan du antingen kasta ändringarna eller så kan du använda mainline-versionen (vilket du vanligtvis behöver göra).
  • Läs vad åtagaren försöker göra och se om problemet redan är fixat. 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 kassera 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-lagret på GitHub, vilket kan vara enklare för att leta upp engagemangslistor och skiljer sig åt konfliktlösning. Jag rekommenderar att du går till åtagandelistan först och lokaliserar problemet åtagande för att se originaldiffen för att jämföra den med din.

Exempel URL: //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 ALLTID ska göra är att se till att din slutliga diff 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 -lv $ (make kernelversion | cut -d. -f 1, 2) * | head -n1) 

Aktivera omrapportering

Git har en funktion som heter rerere (står för återanvänd inspelad upplösning), vilket innebär att när den upptäcker en konflikt, kommer den att spela in hur du löst det så att du kan återanvända det senare. Detta är särskilt användbart för både kroniska rebaser 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öms uppströms eftersom konflikten kommer att lösas hur du tidigare löst det.

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

 git config rerere.enabled sant 

Hur man git halverar när man stöter på en kompilator eller körtidsfel

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

Vad git bisect kommer att göra är att ta en rad åtaganden, från var frågan är närvarande till där den inte var närvarande, och sedan börja halvera engagemangsintervallet, 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 spottar åtagandet som orsakar problemet. Vid den tidpunkten kan du antingen fixa den eller återställa den.

  1. Börja halva: git bisect start
  2. Märk den aktuella revisionen som dålig: git bisect bad
  3. Märk en revision som bra: git bisect good
  4. Bygg med den nya revisionen
  5. Baserat på resultatet (om problemet är närvarande eller inte), berätta för git: git bisect good ELLER git bisect bad
  6. Skölj och upprepa steg 4-5 tills problemet begås!
  7. Återställ eller fixa problemet begå.

OBS: Fusioner kommer att behöva tillfälligt köra git rebase -i för att tillämpa alla korrigeringsfiler på din gren för korrekt skärning, eftersom halvering med sammanslagningarna på plats ofta kommer att kassa på uppströmsåtgärderna, vilket betyder att du inte har någon av de specifika Android-åtagandena. Jag kan gå mer in på detta på begäran men lita på mig, det behövs. När du har identifierat problemet begå kan du återställa eller ombasera det till sammanslagningen.

Squash INTE uppströms uppdateringar

Många nya utvecklare frestas att göra detta eftersom det är "renare" och "lättare" att hantera. Detta är fruktansvärt av några skäl:

  • Författarskap går förlorat. Det är orättvist för andra utvecklare att få sin kredit för deras arbete.
  • Det är omöjligt att halva sig. Om du squashar en serie av åtaganden och något är ett problem i den serien, är det omöjligt att säga vilken begåvning som orsakat ett problem i en squash.
  • Framtida körsbärsplockningar är svårare. Om du behöver avfasas med en klämd serie är det svårt / omöjligt att säga var en konflikt härrör.

Prenumerera på Linux Kernel-adresslistan för snabba uppdateringar

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

Intressanta Artiklar