Ako aktualizovať svoje jadro Android na najnovšiu stabilnú verziu Linuxu

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

Časovo najnáročnejšou časťou je počiatočné vychovanie; akonáhle ste úplne v obraze, zlúčenie nového vydania, ktoré zvyčajne neobsahuje viac ako 100 záväzkov, netrvá vôbec dlho. Výhody, ktoré to prináša (väčšia stabilita a lepšie zabezpečenie vašich používateľov), by si však tento proces mali vyžadovať.

Ako zlúčiť stabilné jadro systému Linux do jadra systému Android

Najprv musíte zistiť, akú verziu jadra používa vaše zariadenie Android.

Akokoľvek sa to zdá byť malicherné, je potrebné vedieť, kde treba začať. V strome jadra spustite nasledujúci príkaz:

urobiť kernelverziu

Vráti sa späť verzia, ktorú používate. Prvé dve čísla sa použijú na zistenie požadovanej vetvy (napr. Linux-4.4.y pre akékoľvek jadro verzie 4.4) a posledné číslo sa použije na určenie verzie, ktorú musíte začať so zlúčením (napr. Ak používate verziu 4.4. .21, zlúčite 4.4.22 ďalšie).

Získajte najnovší zdroj jadra z kernel.org

kernel.org obsahuje najnovší zdroj jadra v systéme Windows linuxovo stabilné úložisko . V dolnej časti tejto stránky budú tri odkazy na načítanie. Podľa mojich skúseností zrkadlo spoločnosti Google býva najrýchlejšie, ale vaše výsledky sa môžu líšiť. Spustite nasledujúce príkazy:

git remote add linux-stable https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit načítať linux-stable

Rozhodnite sa, či chcete zlúčiť celé jadro, alebo vybrať čerešňu

Ďalej si budete musieť zvoliť, či chcete zlúčiť záväzky alebo vybrať čerešňu. Tu sú výhody a nevýhody každého z nich a vždy, keď ich možno budete chcieť urobiť.

POZNÁMKA: Ak je váš zdroj jadra vo forme tarballu, s najväčšou pravdepodobnosťou budete musieť vybrať čerešňu, inak sa vyskytnú tisíce konfliktov súborov, pretože git vypĺňa históriu založenú čisto na upstream, nie na tom, čo zmenil OEM alebo CAF. Preskočte na krok 4.

Zbieranie čerešní:

Klady:

• Ľahšie riešenie konfliktov, pretože presne viete, aký konflikt spôsobuje problém.
• Ľahšie rebázovať, pretože každý záväzok je samostatný.
• Ľahšie rozdeliteľné, ak narazíte na problémy

Zápory:

• Trvá to dlhšie, pretože každý potvrdenie musí byť vybraný individuálne.
• Trochu zložitejšie je zistiť, či je spáchanie na prvý pohľad od horného toku

Choď

Pros :

• Je to rýchlejšie, pretože nemusíte čakať na zlúčenie všetkých čistých opráv.
• Je ľahšie zistiť, kedy je potvrdenie od horného toku, pretože nebudete jeho odosielateľom, nadradený správca bude.

Zápory:

• Riešenie konfliktov môže byť o niečo zložitejšie, pretože budete musieť pomocou git log / git viny zistiť, ktoré spáchanie konfliktu spôsobuje, to vám priamo nepovie.
• Rebasovanie je ťažké, pretože nemôžete rebazovať zlúčenie, ponúkne vám individuálne vybratie všetkých záväzkov. Nemali by ste však rebasovať často, namiesto toho použite git revert a git merge, kde je to možné.

Odporučil by som čerešňovú voľbu, aby ste spočiatku zistili prípadné konflikty problémov, vykonali zlúčenie a potom vrátili problém späť, aby sa potom zaviazali, takže aktualizácia je ľahšia (pretože aktualizácia je po zlúčení rýchlejšia).

Pridajte záväzky k svojmu zdroju, jednu verziu po druhej

Najdôležitejšou súčasťou tohto procesu je jedna verzia po druhej. Vo vašej upstream sérii môže byť problémová oprava, ktorá by mohla spôsobiť problém so zavedením alebo pokazením zvuku alebo nabíjania (vysvetlené v sekcii tipy a triky). Z tohto dôvodu je dôležité robiť prírastkové zmeny verzií. Je ľahšie nájsť problém v 50 záväzkoch, ako v prípade niektorých verzií viac ako 2 000 záväzkov. Úplné zlúčenie by som odporučil, až keď poznáte všetky spáchané problémy a riešenia konfliktov.

Zbieranie čerešní

Formát:

git cherry-pick ..

Príklad:

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

Choď

Formát:

ísť zlúčiť

Príklad:

git merge v3.10.74

Odporúčam sledovať konflikty v záväzkoch zlúčenia odstránením značiek #.

Ako riešiť konflikty

Nemôžeme poskytnúť podrobného sprievodcu riešením každého konfliktu, pretože to vyžaduje dobrú znalosť jazyka C, ale tu je niekoľko rád.

Ak sa zlučujete, zistite, aký konflikt spôsobuje spáchanie. Môžete to urobiť jedným z dvoch spôsobov:

1. git log -p v $ (urobte verziu jadra) .. aby ste dostali zmeny medzi vašou aktuálnou verziou a najnovšou z nadradenej verzie. Príznak -p vám dá zmeny vykonané každým potvrdením, aby ste videli.
2. Spustite git vinu na súbor a získajte hašovanie každého potvrdenia v tejto oblasti. Potom môžete spustiť git show –format = fuller, aby ste zistili, či príkazca pochádza z mainline / stable, Google alebo CodeAurora.

• Zistite, či už máte potvrdenie. Niektorí dodávatelia, ako napríklad Google alebo CAF, sa pokúsia vyhľadať kritické chyby v protismere, ako je napríklad oprava Dirty COW, a ich backporty by mohli byť v rozpore s predchádzajúcimi. Môžete spustiť git log –grep = ”” a zistiť, či niečo vracia. Ak sa to stane, môžete preskočiť potvrdenie (ak vyberáte cherry pomocou git reset –hard && git cherry-pick – pokračovať) alebo ignorovať konflikty (odstrániť<<<<<>>>>>).
• Zistite, či existuje backport, ktorý zhoršuje rozlíšenie. Google a CAF radi backportujú určité opravy, ktoré by stabilné neboli. Stabilná verzia bude často musieť prispôsobiť rozlíšenie hlavnej línie zaviazanosti absencii určitých opráv, ktoré sa Google rozhodne pre backport. Môžete sa pozrieť na potvrdenie mainline spustením git show (hash mainline bude k dispozícii v správe potvrdenia stabilného potvrdenia). Ak to backport pokazí, môžete zmeny zahodiť alebo môžete použiť verziu mainline (čo musíte zvyčajne urobiť).
• Prečítajte si, o čo sa potvrdenie pokúša, a zistite, či je problém už vyriešený. CAF niekedy môže opraviť chybu nezávisle od predchádzajúcej verzie, čo znamená, že môžete buď prepísať jej opravu na predchádzajúcu, alebo ju zahodiť, ako je uvedené vyššie.

Inak to môže byť iba výsledok pridania CAF / Google / OEM. V takom prípade stačí zamiešať niektoré veci.

Tu je zrkadlo úložiska linux-stable kernel.org na GitHub, čo môže byť jednoduchšie na vyhľadanie zoznamov potvrdení a rozdielov na riešenie konfliktov. Odporúčam najskôr prejsť do zobrazenia zoznamu potvrdenia a vyhľadať potvrdenie problému, aby ste videli pôvodný rozdiel, ktorý ho porovná s vašim.

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

Môžete to urobiť aj pomocou príkazového riadku:

git log .. git show

Riešenie uznesení je predovšetkým o kontexte. Čo by ste mali VŽDY urobiť, je ubezpečiť sa, že váš konečný rozdiel sa zhoduje proti prúdu, a to spustením nasledujúcich príkazov v dvoch samostatných oknách:

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

Povoliť opätovné zaznamenanie

Git má funkciu nazvanú rerere (znamená opätovné použitie zaznamenaného rozlíšenia), čo znamená, že keď zistí konflikt, zaznamená, ako ste ho vyriešili, aby ste ho mohli neskôr znova použiť. To je obzvlášť užitočné pre oboch chronických rebaserov, ktoré sa spájajú aj vyberajú čerešne, pretože stačí spustiť git add. && git - pokračujte pri prerábaní upstream, pretože konflikt bude vyriešený tak, ako ste ho predtým vyriešili.

Môže sa to povoliť spustením nasledujúceho príkazu v repozitári jadra:

git config rerere.enabled pravda

Ako git bisect, keď narazíte na chybu kompilátora alebo runtime

Vzhľadom na to, že budete pridávať značný počet záväzkov, je veľmi možné, že predstavíte chybu kompilátora alebo runtime modulu. Namiesto toho, aby ste sa vzdali, môžete na zistenie hlavnej príčiny problému použiť vstavaný nástroj bisit na git! V ideálnom prípade budete zostavovať a blikať každú verziu jadra, ako ju pridáte, takže rozdelenie bude v prípade potreby trvať kratšie, ale môžete rozdeliť 5 000 záväzkov bez akýchkoľvek problémov.

To, čo git bisect urobí, je vziať celý rad záväzkov, od miesta, kde sa problém vyskytuje, až po miesto, kde nebol, a potom začať rozpínať rozsah záväzkov na polovicu, čo vám umožní vytvoriť a otestovať a dať mu vedieť, či je to dobré alebo nie . Bude to pokračovať dovtedy, kým nevypľuje záväzok spôsobujúci váš problém. V tom okamihu to môžete opraviť alebo vrátiť späť.

1. Začnite rozdeľovať: git bisect štart
2. Označte aktuálnu revíziu ako zlú: git bisect bad
3. Označte revíziu ako dobrú: git bisect good
4. Stavajte na novej revízii
5. Na základe výsledku (ak je problém prítomný alebo nie) povedzte git: git bisect dobrý ALEBO git bisect zlý
6. Opláchnite a opakujte kroky 4 až 5, kým sa nenájde potvrdenie problému!
7. Vrátiť alebo opraviť potvrdenie problému.

POZNÁMKA: Fúzie budú musieť dočasne spustiť git rebase -i, aby sa vo vašej pobočke použili všetky záplaty na správne rozpolenie, pretože rozpoltenie so zlúčenými zlúčeniami bude často čakať na zaplatenie za predchádzajúce potvrdenia, čo znamená, že nemáte žiadny z konkrétnych potvrdení pre Android. Na požiadanie sa tým môžem podrobnejšie zaoberať, ale verte mi, je to potrebné. Keď zistíte spáchanie problému, môžete ho vrátiť späť alebo rebázovať späť do zlúčenia.

NEPRACUJTE upstream aktualizácie

Mnoho nových vývojárov je v pokušení to urobiť, pretože je to „čistejšie“ a „ľahšie“ sa spravuje. To je hrozné z niekoľkých dôvodov:

• Autorstvo sa stratilo. Je nefér voči ostatným vývojárom, pokiaľ ide o to, že im bol za prácu poskytnutý kredit.
• Polícia je nemožná. Ak squashujete sériu záväzkov a niečo je problém v tejto sérii, nie je možné zistiť, čo spáchanie spôsobilo problém v squashi.
• Budúce výbery čerešní sú ťažšie. Ak potrebujete rebasovať so stlačenou sériou, je ťažké / nemožné povedať, odkiaľ konflikt vyplýva.

Prihláste sa na odber zoznamu adries Linux Kernel a získajte včasné aktualizácie

Prihláste sa na odber, aby ste dostali upozornenie vždy, keď dôjde k aktualizácii smerom nahor zoznam linux-kernel-oznámiť . Toto vám umožní dostať e-mail zakaždým, keď vyjde nové jadro, aby ste mohli aktualizovať a tlačiť čo najrýchlejšie.