Jak aktualizovat jádro Android na nejnovější stabilní Linux

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

Časově nejnáročnější částí je počáteční vychování; jakmile jste úplně aktuální, sloučení v novém vydání, které obvykle neobsahuje více než 100 závazků, netrvá dlouho. Výhody, které to přináší (větší stabilita a lepší zabezpečení pro vaše uživatele), by však tento proces měly vyžadovat.

Jak sloučit stabilní jádro Linuxu do jádra Androidu

Nejprve musíte zjistit, jakou verzi jádra vaše zařízení Android běží.

Jakkoli se to zdá banální, je nutné vědět, kde musíte začít. Ve stromu jádra spusťte následující příkaz:

provést verzi jádra

Vrátí zpět verzi, kterou používáte. První dvě čísla se použijí k určení požadované větve (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 se slučováním (např. Pokud používáte 4.4 .21, sloučíte 4.4.22 další).

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

kernel.org obsahuje nejnovější zdroj jádra ve Windows linuxově stabilní úložiště . Ve spodní části této stránky budou tři odkazy načtení. Podle mých zkušeností 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 https://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 vybrat třešně

Dále si budete muset vybrat, zda chcete sloučit potvrzení nebo výběr třešní. Zde jsou výhody a nevýhody každého z nich a kdy je budete chtít udělat.

POZNÁMKA: Pokud je váš zdroj jádra ve formě tarballu, budete s největší pravděpodobností muset vybrat cherry, jinak získáte tisíce konfliktů souborů, protože git vyplňuje historii čistě na upstream, ne na tom, co se změnil OEM nebo CAF. Přeskočte na krok 4.

Sběr třešní:

Profesionálové:

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

Nevýhody:

• Trvá to déle, protože každý závazek musí být vybrán jednotlivě.
• Trochu obtížnější zjistit, zda je potvrzení na první pohled od horního toku

Jít

Profesionálové :

• Je to rychlejší, protože nemusíte čekat na sloučení všech čistých oprav.
• Je snazší zjistit, kdy je potvrzení od horního toku, protože nebudete Committer, nadřazený správce bude.

Nevýhody:

• Řešení konfliktů může být o něco obtížnější, protože budete muset pomocí git log / git viny zjistit, které potvrzení konflikt způsobuje, to vám přímo neřekne.
• Rebasing je obtížný, protože nemůžete rebase sloučit, nabídne vám výběr třešně jednotlivě. Neměli byste však často rebasovat, místo toho použijte git revert a git merge, kde je to možné.

Doporučil bych udělat cherry-pick, abyste nejprve zjistili konflikty problémů, provedli sloučení a poté se vrátili k problému, který se následně zaváže, takže aktualizace je jednodušší (protože sloučení je rychlejší po aktualizaci).

Přidejte závazky ke zdroji, jednu verzi po druhé

Nejdůležitější částí tohoto procesu je jedna verze po druhé. Ve vaší upstreamové sérii MŮŽE být problémová oprava, která by mohla způsobit problém se zaváděním nebo přerušením zvuku nebo nabíjení (vysvětleno v sekci tipy a triky). Z tohoto důvodu je důležité provádět přírůstkové změny verzí, u některých verzí je snazší najít problém u 50 revizí než u více než 2 000 revizí. Doporučil bych provést úplné sloučení, až budete znát všechny závazky k problému 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

Jít

Formát:

jít sloučit

Příklad:

git merge v3.10.74

Doporučuji sledovat konflikty v revizích sloučením odstraněním značek #.

Jak řešit konflikty

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

Pokud slučujete, zjistěte, jaké potvrzení konflikt způsobuje. Můžete to udělat dvěma způsoby:

1. git log -p v $ (make kernelversion) .. pro získání změn mezi vaší 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 soubor a získejte hashe každého potvrzení v této oblasti. Poté můžete spustit git show –format = fuller, abyste zjistili, zda je zadavatel z mainline / stable, Google nebo CodeAurora.

• Zjistěte, zda již máte potvrzení. Někteří prodejci, jako je Google nebo CAF, se pokusí vyhledat kritické chyby proti proudu, například opravu Dirty COW, a jejich backporty by mohly být v rozporu s upstream. Můžete spustit git log –grep = ”” a zjistit, zda něco vrací. Pokud ano, můžete přeskočit potvrzení (pokud je výběr cherry pomocí git reset –hard && git cherry-pick – pokračovat) nebo ignorovat konflikty (odstranit<<<<<>>>>>).
• Zjistěte, zda existuje backport, který zhoršuje rozlišení. Google a CAF rádi backportují určité opravy, které by stabilní nebyly. Stabilní bude často muset přizpůsobit rozlišení hlavní řady dopustit se na absenci určitých oprav, které se Google rozhodne pro backport. Na revizi hlavní řady se můžete podívat spuštěním git show (hash hlavní řady bude k dispozici ve zprávě o potvrzení stabilního potvrzení). Pokud to backport pokazil, můžete změny buď zahodit, nebo můžete použít verzi mainline (což je obvykle to, co musíte udělat).
• Přečtěte si, o co se potvrzení snaží, a zjistěte, zda je problém již vyřešen. Někdy může CAF opravit chybu nezávisle na upstream, což znamená, že můžete buď přepsat jejich opravu pro upstream, nebo ji zahodit, jako výše.

Jinak to může být jen důsledek přidání CAF / Google / OEM, v takovém případě stačí zamíchat některé věci.

Tady je zrcadlo úložiště linux-stable kernel.org na GitHubu, což může být jednodušší pro vyhledávání seznamů potvrzení a rozdílů pro řešení konfliktů. Doporučuji nejdříve přejít do zobrazení seznamu odevzdání a lokalizovat potvrzení problému, abyste viděli původní rozdíl, abyste jej mohli porovnat s vaším.

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

Můžete to udělat také z příkazového řádku:

git log .. git show

Řešení řešení je o kontextu. Co byste měli VŽDY udělat, je ujistit se, že váš finální rozdíl odpovídá upstream, 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 -l v $ (make kernelversion | cut -d. -f 1,2) * | head -n1)

Povolit opakování

Git má funkci nazvanou rerere (znamená opětovné použití zaznamenaného rozlišení), což znamená, že když zjistí konflikt, zaznamená, jak jste jej vyřešili, abyste jej mohli později znovu použít. To je obzvláště užitečné pro oba chronické rebasery jak se slučováním, tak s výběrem třešní, protože stačí spustit git add. && git –pokračujte v předávání upstream, protože konflikt bude vyřešen tak, 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 git bisect při spuštění do chyby kompilátoru nebo runtime

Vzhledem k tomu, že přidáváte značný počet revizí, je velmi možné zavést chybu kompilátoru nebo běhového modulu. Místo toho, abyste se vzdali, můžete použít vestavěný nástroj bisit git a zjistit hlavní příčinu problému! V ideálním případě budete stavět a blikat každou verzi jádra, jakmile ji přidáte, takže půlení bude v případě potřeby trvat méně času, ale můžete rozdělit 5000 závazků bez jakýchkoli problémů.

To, co git bisect udělá, je vzít řadu revizí, od místa, kde je problém, až po místo, kde nebyl, a pak začít snížit rozsah revizí na polovinu, což vám umožní sestavit a otestovat a dát vědět, jestli je to dobré nebo ne . Bude to pokračovat, dokud nevyplivne potvrzení způsobující váš problém. V tomto okamžiku to můžete buď opravit, nebo vrátit zpět.

1. Začněte půlit: start git bisect
2. Označte aktuální revizi jako špatnou: git bisect bad
3. Označte revizi jako dobrou: git bisect good
4. Budujte s novou revizí
5. Na základě výsledku (pokud je problém přítomen nebo ne) řekněte git: git bisect dobrý NEBO git bisect špatný
6. Opláchněte a opakujte kroky 4 až 5, dokud není nalezena chyba potvrzení!
7. Vrátit nebo opravit potvrzení problému.

POZNÁMKA: Fúze budou muset dočasně spustit git rebase -i, aby se všechny patche ve vaší pobočce aplikovaly na správné půlení, protože půlení se sloučením na místě bude často krát platba za provizemi proti proudu, což znamená, že nemáte žádný ze specifických závazků pro Android. Můžu se tím na žádost podrobněji zabývat, ale věřte mi, je to nutné. Jakmile zjistíte spáchání problému, můžete jej vrátit nebo rebasovat do sloučení.

NEPROVÁDĚJTE upstream aktualizace

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

• Autorství je ztraceno. Je nefér vůči ostatním vývojářům, když mají za svou práci omezený kredit.
• Oloupání je nemožné. Pokud zmáčknete řadu revizí a něco je problém v této sérii, je nemožné říci, co spáchání způsobilo problém ve squashu.
• Budoucí výběr třešní je těžší. Pokud potřebujete rebase se zmáčknutou sérií, je obtížné / nemožné určit, odkud konflikt vyplývá.

Přihlaste se k odběru e-mailového seznamu Linux Kernel a získejte včasné aktualizace

Chcete-li dostávat oznámení vždy, když dojde k aktualizaci upstream, přihlaste se k odběru seznam linux-kernel-oznámit . To vám umožní dostat e-mail pokaždé, když vyjde nové jádro, takže můžete aktualizovat a tlačit co nejrychleji.