Jak aktualizovat jádro systému Android na nejnovější verzi systému Linux

Pokryli jsme průvodci jádry Androidu, například „Jak vytvořit vlastní jádro“ a „Nejlepší vlastní jádra pro Android“, ale dnes vám ukážeme, jak upstream jádro proti nejnovějším stabilním Linuxu.

Vezměte prosím na vědomí, že se jedná o pokročilé věci - pokud jste ještě nikdy nezkompilovali jádro, měli byste se řídit výše uvedeným průvodcem „Jak vytvořit vlastní jádro“ a tento průvodce bude zahrnovat tísňové a slučovací závazky z nejnovějších Linux- stabilní jádro s jádrem Android před jeho kompilací.

Upgradování jádra Androidu na nejnovější linuxový systém má mnoho pozitivních výhod, jako je to, že máte nejnovější bezpečnostní závazky a opravy chyb - některé výhody a nevýhody vysvětlíme později v této příručce.

Co je jádro Linux-Stable?

Linux-stabilní, jak název napovídá, je stabilní rameno linuxového jádra. Druhá ruka je známá jako „hlavní linie“, což je hlavní větev . Celý vývoj jádra Linuxu se odehrává v hlavní linii a obecně se řídí tímto procesem:

  1. Linus Torvalds vezme spoustu oprav od svých správců na dva týdny.
  2. Po těchto dvou týdnech uvolní jádro rc1 (např. 4.14-rc1).
  3. Pro každý týden na dalších 6-8 týdnů uvolní další RC (např. 4.14-rc2, 4.14-rc3 atd.) Jádro, které obsahuje POUZE opravy chyb a regrese.
  4. Jakmile bude považován za stabilní, bude vydán jako tarball ke stažení na org (např. 4.14).

Co jsou jádra LTS?

Greg vybere každý rok jedno jádro a bude jej udržovat buď dva roky (LTS) nebo šest let (prodloužené LTS). Jsou navrženy tak, aby produkty, které vyžadují stabilitu (jako telefony Android nebo jiná zařízení IOT). Proces je přesně stejný jako výše, pouze se děje na delší dobu. V současné době existuje šest jader LTS (které lze vždy zobrazit na stránce vydání kernel.org):

  • 4, 14 (LTS), spravováno Gregem Kroah-Hartmanem
  • 4, 9 (LTS), spravováno Gregem Kroah-Hartmanem
  • 4, 4 (eLTS), udržovaný Gregem Kroah-Hartmanem
  • 4, 1 (LTS), spravovaná Sasha Levin
  • 3, 16 (LTS), spravováno Ben Hutchings
  • 3.2 (LTS), spravuje Ben Hutchings

Jaké jsou výhody upstreamingu mého Android jádra na Linux Stable?

Když jsou odhalena / opravena důležitá zranitelnost, stabilní jádra jsou první, kdo je získá. Vaše jádro Android tak bude mnohem bezpečnější proti útokům, bezpečnostním chybám a obecně pouze chybám.

Stabilní Linux zahrnuje opravy pro mnoho ovladačů, které moje zařízení Android nepoužívá, není to většinou zbytečné?

Ano a ne, podle toho, jak definujete „většinou“. Linuxové jádro může obsahovat spoustu kódu, který se v systému Android nevyužívá, ale to nezaručuje, že při sloučení nových verzí z těchto souborů nedojde ke konfliktům! Pochopte, že prakticky nikdo nestaví každou jednotlivou část jádra, ani nejběžnější linuxová distros, jako je Ubuntu nebo Mint. To neznamená, že byste neměli brát tyto opravy, protože existují ovladače pro ovladače, které spustíte. Vezměte například arm / arm64 a ext4, které jsou nejčastější architekturou Android a souborovým systémem. V 4.4, od 4.4.78 (verze nejnovější značky Oreo CAF) po 4.4.121 (nejnovější značka proti proudu), jsou tato čísla pro závazky těchto systémů:

 ~ / jádra / linux-stabilní (hlavní) $ git log --format =% h v4.4.78..v4.4.121 | wc -l2285 ~ / jádra / linux-stabilní (hlavní) $ git log --format =% h v4.4.78..v4.4.121 oblouk / rameno | wc -l58 ~ / jádra / linux-stabilní (hlavní) $ git log --format =% h v4.4.78..v4.4.121 arch / arm64 | wc -l22 ~ / jádra / linux-stabilní (hlavní) $ git log --format =% h v4.4.78..v4.4.121 fs / ext4 | wc -18 

Nejnáročnější částí je počáteční vychytávání; jakmile jste celou cestu až do dnešního dne, není vůbec nutné spojit se s novým vydáním, které obvykle neobsahuje více než 100 potvrzení. Výhody, které to přináší (větší stabilita a lepší zabezpečení vašich uživatelů), by však tento proces měly vyžadovat.

Jak sloučit linuxové stabilní jádro do jádra Android

Nejprve musíte zjistit, jakou verzi jádra vaše zařízení se systémem Android používá.

Jak to vypadá bezvýznamně, je nutné vědět, kde musíte začít. Ve stromu jádra spusťte následující příkaz:

 udělat jádro 

Vrátí zpět verzi, na které jste. První dvě čísla se použijí k určení pobočky, kterou potřebujete (např. Linux-4.4.y pro libovolné jádro 4.4) a poslední číslo se použije k určení verze, kterou musíte začít s fúzováním (např. Pokud používáte 4.4) .21, sloučíte další 4.4.22).

Získejte nejnovější zdroj jádra z kernel.org

kernel.org obsahuje nejnovější zdroj jádra v úložišti stabilním v Linuxu. Ve spodní části této stránky budou tři odkazy pro načtení. Podle mého názoru má zrcadlo Google tendenci být nejrychlejší, ale vaše výsledky se mohou lišit. Spusťte následující příkazy:

 git remote add linux-stable //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit načíst linux-stable 

Rozhodněte se, zda chcete sloučit celé jádro, nebo proveďte výběr

Dále si budete muset vybrat, zda chcete sloučit závazky nebo třešně. Zde jsou klady a zápory každého a kdy je budete chtít udělat.

POZNÁMKA: Pokud je váš zdroj jádra ve formě tarballu, budete pravděpodobně muset vybírat třešně, jinak dostanete tisíce konfliktů souborů, protože git naplňuje historii pouze na základě upstream, ne to, co má OEM nebo CAF změněno. Jednoduše přejděte ke kroku 4.

Sběr třešní:

Klady:

  • Snadnější řešení konfliktů, protože přesně víte, co konflikt způsobuje problém.
  • Snadnější rebase, protože každý závazek je sám o sobě.
  • Snadnější rozdělování, pokud narazíte na problémy

Nevýhody:

  • Trvá to déle, protože každé potvrzení musí být vybráno individuálně.
  • Těžko říct, zda je odhodlání na první pohled nahoře

Spojit

Výhody :

  • Je to rychlejší, protože nemusíte čekat na sloučení všech čistých záplat.
  • Je snazší zjistit, kdy je odevzdání provedeno z upstream, protože nebudete spáchatelem, bude správce upstream.

Nevýhody:

  • Řešení konfliktů může být o něco složitější, protože budete muset vyhledat, který závazek způsobuje konflikt pomocí git log / git viny, to vám přímo neřekne.
  • Rebasing je obtížný, protože nemůžete znovu sloučit sloučení, nabídne to, že vyberete všechny závazky individuálně. Neměli byste se však často rebasovat, místo toho použijte git zpět a sloučení git, pokud je to možné.

Doporučil bych provést třešňový výběr, abyste nejprve zjistili případné konflikty problému, provedli sloučení a poté problém vrátili a poté se vrátíme, takže aktualizace je snazší (protože sloučení je rychlejší poté, co byl aktuální).

Přidejte potvrzení ke zdroji, vždy po jedné verzi

Nejdůležitější součástí tohoto procesu je jedna verze najednou. Ve vaší předcházející sérii může být problémová záplata, která by mohla způsobit problém s bootováním nebo přerušit něco jako zvuk nebo nabíjení (vysvětleno v části Tipy a triky). Z tohoto důvodu je důležité provádět přírůstkové změny verzí, je snazší najít problém v 50 revizích, než u 2000 verzí. Doporučuji provést úplnou sloučení, pouze pokud víte, že všechny problémy se dopouštějí a řešení konfliktů.

Sběr třešní

Formát:

 git cherry-pick .. 

Příklad:

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

Spojit

Formát:

 spojit se 

Příklad:

git merge v3.10.74

Doporučuji sledovat konflikty v hromadných odevzdáních odstraněním značek #.

Jak vyřešit konflikty

Nemůžeme poskytnout průvodce krok za krokem pro řešení každého jednotlivého konfliktu, protože zahrnuje dobrou znalost jazyka C, ale zde je několik rad.

Pokud se slučujete, zjistěte, co je příčinou konfliktu. Můžete to udělat jedním ze dvou způsobů:

  1. git log -pv $ (make kernelversion) .. pro získání změn mezi aktuální verzí a nejnovější z upstream. Příznak -p vám poskytne změny provedené každým potvrzením, abyste viděli.
  2. Spusťte git vinu na souboru a získejte hashe každého odevzdání v oblasti. Poté můžete spustit git show –format = fuller, abyste zjistili, zda byl spoušť z mainline / stable, Google nebo CodeAurora.
  • Pokud již máte potvrzení, přijďte na to. Někteří prodejci, jako je Google nebo CAF, se pokusí vyhledat upstream pro kritické chyby, jako je oprava Dirty COW, a jejich backporty by mohly být v konfliktu s upstream. Můžete spustit git log –grep = "" a zjistit, jestli něco vrátí. Pokud ano, můžete přeskočit potvrzení (pokud vyberete třešně pomocí git reset –hard && git cherry-pick –continue) nebo konflikty ignorovat (odstranit <<<<< >>>>>).
  • Zjistit, jestli existuje backport, který je zmatek rozlišení. Google a CAF rádi podporují některé záplaty, které by stabilní nebyly. Stabilní bude často muset přizpůsobit řešení hlavního závazku abscesu některých záplat, které se Google rozhodne pro backport. Na hlavní potvrzení se můžete podívat spuštěním git show (hlavní hash bude k dispozici ve zprávě potvrzení stabilního potvrzení). Pokud je k dispozici backport, můžete změny zrušit nebo můžete použít hlavní verzi (což je obvykle to, co budete muset udělat).
  • Přečtěte si, co se revize snaží udělat, a zjistěte, zda je problém již vyřešen. Někdy může CAF opravit chybu nezávislou na upstream, což znamená, že můžete buď přepsat jejich opravu pro upstream, nebo ji zahodit, jako výše.

V opačném případě to může být výsledkem přidání modelu CAF / Google / OEM, v takovém případě stačí některé věci zamíchat.

Zde je zrcadlo linux-stabilního úložiště kernel.org na GitHubu, což může být snazší prohledávání seznamů odevzdání a liší se při řešení konfliktů. Doporučuji nejprve přejít do zobrazení seznamu odevzdání a lokalizovat problém odevzdání a podívat se na původní rozdíl a porovnat jej s vašimi.

Příklad adresy URL: //github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

Můžete to také provést pomocí příkazového řádku:

 git log .. git show 

Řešení řešení je především o kontextu. VŽDY byste se měli ujistit, že se váš konečný rozdíl shoduje s předními proudy spuštěním následujících příkazů ve dvou samostatných oknech:

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

Povolit opakování

Git má funkci nazvanou rerere (znamená Reuse Recorded Resolution), což znamená, že když detekuje konflikt, zaznamená to, jak jste jej vyřešili, abyste jej mohli znovu použít později. To je užitečné zejména pro chronické rebasery s slučováním i sbíráním třešní, protože stačí spustit git add. && git - pokračovat v opakování předvolby, protože konflikt bude vyřešen, jak jste jej dříve vyřešili.

Lze jej povolit spuštěním následujícího příkazu v repozitáři jádra:

 git config rerere.enabled true 

Jak se rozdělit, když běží do kompilátoru nebo za běhu

Vzhledem k tomu, že přidáváte značný počet potvrzení, je velmi pravděpodobné, že uvedete chybu kompilátoru nebo runtime. Místo toho, abyste se vzdali, můžete použít vestavěný nástroj bisit společnosti git, abyste zjistili hlavní příčinu problému! V ideálním případě budete stavět a blikat každou verzi jádra, jakmile jej přidáte, takže rozepření zabere v případě potřeby méně času, ale můžete rozdělit 5 000 odevzdání bez problémů.

Git bisect udělá to, že vezme řadu revizí, od místa, kde je problém k místu, kde nebyl přítomen, a pak začněte snižovat rozsah odevzdání na polovinu, což vám umožní sestavit a otestovat a dát mu vědět, zda je dobrý nebo ne . Bude to pokračovat, dokud nevyplní závazek způsobující váš problém. V tuto chvíli to můžete buď opravit, nebo vrátit.

  1. Start bisecting: git bisect start
  2. Označte aktuální revizi jako špatnou: git bisect bad
  3. Označte revizi jako dobrou: git bisect good
  4. Sestavte s novou revizí
  5. Na základě výsledku (pokud je problém přítomen nebo ne), řekněte git: git bisect good NEBO git bisect bad
  6. Opláchněte a opakujte kroky 4-5, dokud nebude nalezen problém potvrzení!
  7. Vrácení nebo oprava problému potvrzení.

POZNÁMKA: Fúze budou muset dočasně spustit git rebase -i, aby mohly být všechny záplaty aplikovány na vaši větev kvůli řádnému rozdělování, protože rozdělování se sloučením na místě bude často krát započítáno na předběžné závazky, což znamená, že nemáte žádné konkrétní závazky pro Android. Na požádání to mohu do hloubky rozšířit, ale věřte mi, je to nutné. Poté, co jste identifikovali odevzdání problému, můžete je vrátit nebo sloučit do sloučení.

NEVYTLAVUJTE upstream aktualizace

Mnoho nových vývojářů je v pokušení to udělat, protože je to „čistší“ a „snadnější“ řídit. To je hrozné z několika důvodů:

  • Autorství je ztraceno. Pro ostatní vývojáře je nespravedlivé, aby si za svou práci udělili kredit.
  • Rozštěpení je nemožné. Pokud rozmáčknete řadu odevzdání a něco je problémem v této sérii, je nemožné říci, co odevzdání způsobilo problém v squashi.
  • Budoucí třešně jsou těžší. Pokud potřebujete rebasovat s rozmačkanou řadou, je obtížné / nemožné zjistit, odkud konflikt vyplývá.

Přihlaste se k odběru poštovního seznamu linuxového jádra a získejte včasné aktualizace

Chcete-li dostávat oznámení, kdykoli dojde k upstream aktualizaci, přihlaste se k odběru seznamu linux-kernel-announce. To vám umožní získat e-mail pokaždé, když bude vydáno nové jádro, takže můžete aktualizovat a tlačit co nejrychleji.

Zajímavé Články