Kako posodobiti jedro Android na najnovejšo stabilno 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

Najbolj zamuden del je začetna vzgoja; ko ste povsem na tekočem, ne traja nič časa, da se združite v novi izdaji, ki običajno vsebuje največ 100 prevzema. Prednosti, ki jih to prinaša (več stabilnosti in boljša varnost za vaše uporabnike), bi morale vseeno zahtevati ta postopek.

Kako združiti stabilno jedro Linuxa v jedro Android

Najprej morate ugotoviti, katero različico jedra ima vaša naprava Android.

Kolikor se to zdi nepomembno, je treba vedeti, kje morate začeti. V drevesu jedra zaženite naslednji ukaz:

narediti kernelversion

Vrnila se bo različica, v kateri ste. Prvi dve številki bosta uporabljeni za določitev veje, ki jo potrebujete (npr. Linux-4.4.y za katero koli 4.4 jedro), zadnja številka pa za določitev, katero različico morate začeti z združevanjem (npr. Če uporabljate 4.4 .21, naslednji boste združili 4.4.22).

Zgrabite najnovejši vir jedra s strani kernel.org

kernel.org hrani najnovejši vir jedra v linux-stabilno skladišče . Na dnu te strani bodo tri povezave za prenos. Po mojih izkušnjah je Googlovo ogledalo ponavadi najhitrejše, vendar se lahko vaši rezultati razlikujejo. Zaženite naslednje ukaze:

git remote add linux-stable https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit fetch linux-stable

Odločite se, ali želite združiti celotno jedro ali češnjevo nabrati zaveze

Nato boste morali izbrati, ali želite združiti zaveze ali cherry-pick. Tu so prednosti in slabosti vsakega in kdaj jih boste morda želeli izvesti.

OPOMBA: Če je vaš izvor jedra v obliki tarball, boste najverjetneje morali izbrati češnje, sicer boste dobili na tisoče konfliktov datotek, ker git zapolnjuje zgodovino, ki temelji zgolj na zgornjem toku, ne pa na tem, kaj sta OEM ali CAF spremenila. Samo preskočite na 4. korak.

Nabiranje češenj:

Prednosti:

• Lažje je razrešiti konflikte, saj natančno veste, kateri konflikt povzroča težavo.
• Preprostejše prenavljanje, saj je vsak prevzem sam zase.
• Preprostejše razdeljevanje, če naletite na težave

Slabosti:

• Traja dlje, saj je treba vsako prevzem posamično izbrati.
• Malo težje je ugotoviti, ali je prevzem na prvi pogled od zgoraj

Pojdi

Prednosti :

• Hitreje je, saj vam ni treba čakati, da se vsi čisti obliži združijo.
• Lažje je videti, kdaj je prevzem iz zgornje verige, saj vi ne boste zavezanec, bo vzdrževalec v zgornjem toku.

Slabosti:

• Reševanje konfliktov je lahko nekoliko težje, saj boste morali poiskati, katera zaveza povzroča konflikt, s pomočjo git log / git krivde, ne bo vam neposredno povedal.
• Ponovna podlaga je težavna, saj združitve ne morete znova zgraditi, saj bo ponujal, da izberete vsak prevzem posebej. Vendar pa ne bi smeli pogosto prerazporejati, namesto tega uporabite git revert in git merge, kjer je to mogoče.

Priporočam, da na začetku izvedete izbiro češenj, da najprej ugotovite morebitne konflikte, naredite spajanje, nato pa pozneje povrnete težave, ki jih je treba prevzeti, tako da je posodabljanje lažje (ker je spajanje hitrejše, ko je posodobljeno).

Obveze dodajte v svoj vir, vsako različico naenkrat

Najpomembnejši del tega postopka je posamezna različica. V seriji navzgor lahko nastane obliž za težave, ki bi lahko povzročil težave z zagonom ali pokvaril nekaj podobnega zvoku ali polnjenju (razloženo v razdelku z nasveti in triki). Iz tega razloga je pomembno postopno spreminjanje različice, zato je težavo lažje najti v 50 zavezah kot pri 2000 različicah več kot 2000. Priporočam popolno združitev šele, ko poznate vse težave in rešitve sporov.

Nabiranje češenj

Oblika:

git cherry-pick ..

Primer:

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

Pojdi

Oblika:

pojdi združiti

Primer:

git merge v3.10.74

Priporočam, da spremljate navzkrižja v zavezah združevanja tako, da odstranite oznake #.

Kako odpraviti konflikte

Ne moremo podati podrobnih navodil za reševanje vsakega posameznega konflikta, saj gre za dobro znanje jezika C, a tu je nekaj namigov.

Če se združujete, ugotovite, kakšna zaveza povzroča konflikt. To lahko storite na dva načina:

1. git log -p v $ (make kernelversion) .., da dobite spremembe med vašo trenutno in najnovejšo različico v zgornjem toku. Oznaka -p vam bo dala spremembe, ki jih je naredil vsak prevzem, tako da boste lahko videli.
2. Zaženite git krivdo v datoteki, da dobite razpršitve vsake objave na območju. Nato lahko zaženete git show –format = fuller, da preverite, ali je bil prevzemnik iz mainline / stable, Google ali CodeAurora.

• Ugotovite, ali že imate prevzeto. Nekateri prodajalci, kot sta Google ali CAF, bodo poskušali poiskati kritične napake, na primer popravek Dirty COW, in njihove podlage bi lahko bile v nasprotju s predhodnimi. Lahko zaženete git log –grep = ”” in preverite, ali vrne kaj. Če se to zgodi, lahko preskočite objavo (če nabiranje češenj s pomočjo git reset –hard && git cherry-pick –nastavi) ali prezrete konflikte (odstranite<<<<<>>>>>).
• Ugotovite, ali je obstajal backport, ki je zmedel ločljivost. Google in CAF rada podpirata nekatere popravke, ki jih stabilno ne bi. Stable bo pogosto moral prilagoditi resolucijo glavne proge odsotnosti nekaterih popravkov, ki jih Google izbere za nazaj. Ojavo glavne črte si lahko ogledate tako, da zaženete git show (razpršitev glavne črte bo na voljo v sporočilu za odobritev stabilnega sprejema). Če je backport pokvarjen, lahko spremembe zavržete ali pa uporabite glavno različico (kar boste običajno morali storiti).
• Preberite, kaj poskuša storiti predaja, in preverite, ali je težava že odpravljena. CAF lahko včasih odpravi napako, neodvisno od gorvodne verige, kar pomeni, da jo lahko popravite za zgornjo točko ali jo zavržete, kot zgoraj.

V nasprotnem primeru je to lahko le posledica dodatka CAF / Google / OEM, v tem primeru morate le premešati nekaj stvari.

Tukaj je zrcalo linux-stabilnega repozitorija kernel.org na GitHub, kar je lahko lažje za iskanje seznamov zavez in razlike za reševanje konfliktov. Priporočam, da najprej odprete pogled seznama odobritev in poiščete težavo, da se prikaže prvotna različica, da jo primerjate s svojo.

Primer URL-ja: https://github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

To lahko storite tudi prek ukazne vrstice:

git log .. git show

Reševanje ločljivosti je vse v kontekstu. Vedno morate poskrbeti, da se bo vaš zadnji razlik ujemal z zgornjim tokom, tako da v dveh ločenih oknih zaženete naslednje ukaze:

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

Omogoči ponovni vnos

Git ima funkcijo rerere (pomeni Reuse Recorded Resolution), kar pomeni, da bo, ko zazna konflikt, zapisal, kako ste ga razrešili, da ga boste lahko pozneje ponovno uporabili. To je še posebej koristno za oba kronična rebaseerja z združevanjem in nabiranjem češenj, saj boste morali zagnati git add. && git - nadaljujte s ponovitvijo prevzema navzgor, saj bo konflikt rešen tako, kot ste ga prej rešili.

To lahko omogočite tako, da v repou jedra zaženete naslednji ukaz:

git config rerere.enabled true

Kako git bisect pri zagonu napake prevajalnika ali runtime

Glede na to, da boste dodali precejšnje število prevzemov, boste zelo verjetno lahko vnesli napako prevajalnika ali runtime. Namesto da bi se samo odpovedali, lahko z vgrajenim orodjem za bisekt gita ugotovite vzrok težave! V idealnem primeru boste pri dodajanju vsake različice jedra sestavili in utripali, tako da bo razdeljevanje po potrebi trajalo manj časa, lahko pa 5000 vprašanj razdvojite brez kakršnih koli težav.

Kaj bo naredil git bisect, bo naredil vrsto predavanj, od mesta, kjer je težava prisotna, do mesta, kjer ni bilo, in nato začeti prepoloviti obseg predavanja, kar vam omogoča, da zgradite in preizkusite ter sporočite, ali je to dobro ali ne . Tako bo nadaljeval, dokler ne izpusti objave, ki je povzročila vašo težavo. Takrat lahko to popravite ali razveljavite.

1. Začni bisecting: git bisect start
2. Označi trenutno revizijo kot slabo: git bisect bad
3. Označite revizijo kot dobro: git razpolovi dobro
4. Zgradite z novo revizijo
5. Na podlagi rezultata (če je težava prisotna ali ne) povejte git: git bisect dobro ALI git bisect bad
6. Sperite in ponavljajte korake 4-5, dokler ne najdete prevzema težave!
7. Razveljavite ali odpravite težavo.

OPOMBA: Združitve bodo morale začasno zagnati git rebase -i, da bodo za vašo podružnico veljale vse popravke za pravilno razdeljevanje, saj bo razdeljevanje z združitvami na mestu pogostokrat plačilo nad prevzemnimi prevzemi, kar pomeni, da nimate nobenega od zavez za Android. Na zahtevo se lahko poglobim v to, a verjemite mi, da je to potrebno. Ko prepoznate težavo, jo lahko razveljavite ali znova nastavite v združitev.

NE zmečkajte posodobitev v smeri toka

Veliko novih razvijalcev je v skušnjavi, da bi to storili, saj je 'čistejše' in 'lažje' za upravljanje. To je grozno iz nekaj razlogov:

• Avtorstvo je izgubljeno. Nepošteno je do drugih razvijalcev, če jim odrekajo zasluge za njihovo delo.
• Razdeljevanje je nemogoče. Če zmečkate vrsto opravkov in je v tej seriji nekaj težav, je nemogoče ugotoviti, kakšna zaveza je povzročila težavo v skvošu.
• Prihodnje češnje so težje. Če morate znova narediti zmečkano serijo, je težko / nemogoče ugotoviti, od kod izhaja konflikt.

Za pravočasne posodobitve se naročite na poštni seznam jedra Linux

Če želite biti obveščeni o vsaki posodobitvi, se naročite na seznam Linux-kernel-napovedi . To vam bo omogočilo, da dobite e-poštno sporočilo vsakič, ko izide novo jedro, tako da ga boste lahko posodobili in potisnili čim hitreje.