Kako posodobiti Android Kernel na najnovejši Linux Stable

Pokrivali smo vodnike za jedra Android, kot so "Kako sestaviti jedro po meri" in "Najboljša jedra po meri za Android", danes pa vam bomo pokazali, kako nadgraditi svoje jedro proti najnovejši stabilni Linux.

Prosimo, vedite, da gre za napredne stvari - če še nikoli niste pripravili jedra, upoštevajte zgornji vodnik »Kako sestaviti jedro po meri« in ta priročnik bo vključeval nabiranje češenj in združevanje zavez iz najnovejšega Linux-a, stabilno jedro z vašim Androidnim jedrom, preden ga sestavite.

Posredovanje jedra Android na najnovejšo stabilnost Linuxa ima veliko pozitivnih prednosti, kot je na primer posodobitev najnovejših varnostnih zavez in popravkov - nekatere prednosti in slabosti bomo razložili v tem priročniku.

Kaj je Linux-stabilno jedro?

Linux-stabilen, kot pove že ime, je stabilna veja jedra Linuxa. Druga veja je znana kot "glavna linija", ki je glavna veja . Ves razvoj jedra Linuxa se dogaja v glavni liniji in na splošno sledi temu postopku:

  1. Linus Torvalds bo dva tedna od svojih vzdrževalcev vzel kup obližev.
  2. Po teh dveh tednih sprosti jedro rc1 (npr. 4.14-rc1).
  3. Vsak teden v naslednjih 6-8 tednih bo izdal še eno RC (npr. 4.14-rc2, 4.14-rc3 itd.) Jedro, ki vsebuje SAMO popravke napak in regresije.
  4. Ko se šteje za stabilno, bo objavljen kot tarča za prenos na org (npr. 4.14).

Kaj so LTS jedra?

Greg bo vsako leto izbral eno jedro in ga vzdrževal bodisi dve leti (LTS) bodisi šest let (podaljšani LTS). Zasnovani so tako, da imajo izdelke, ki potrebujejo stabilnost (kot so Android telefoni ali druge naprave IOT). Postopek je popolnoma enak kot zgoraj, zgodi se le dlje časa. Trenutno obstaja šest jeder LTS (ki si jih je vedno mogoče ogledati na strani z izdajami kernel.org):

  • 4.14 (LTS), ki ga vzdržuje Greg Kroah-Hartman
  • 4, 9 (LTS), ki ga vzdržuje Greg Kroah-Hartman
  • 4.4 (eLTS), ki ga vzdržuje Greg Kroah-Hartman
  • 4.1 (LTS), ki ga vzdržuje Saša Levin
  • 3.16 (LTS), ki ga vzdržuje Ben Hutchings
  • 3.2 (LTS), ki ga vzdržuje Ben Hutchings

Katere so prednosti mojega jedra Android v Linux Stable?

Ko so pomembne ranljivosti odkrite / popravljene, so stabilna jedra prva, ki jih dobijo. Tako bo vaše Androidno jedro veliko varnejše pred napadi, varnostnimi napakami in zgolj napakami na splošno.

Stabilnik Linux vključuje popravke za številne gonilnike, ki jih moja Android naprava ne uporablja, ali to večinoma ni nepotrebno?

Da in ne, odvisno od tega, kako definirate "večinoma". Linuxovo jedro lahko vsebuje veliko kode, ki se ne uporablja v sistemu Android, vendar to ne zagotavlja, da med združevanjem novih različic ne bo prišlo do konfliktov med temi datotekami! Razumejte, da skoraj nihče ne gradi vsakega dela jedra, niti najbolj običajnih Linuxov distros, kot sta Ubuntu ali Mint. To ne pomeni, da teh popravkov ne bi smeli uporabljati, ker obstajajo popravki za gonilnike, ki jih izvajate. Vzemimo za primer arm / arm64 in ext4, ki sta najpogostejša Androidova arhitektura in datotečni sistem. V 4.4, od 4.4.78 (različica najnovejše oznake Oreo CAF) do 4.4.121 (najnovejša oznaka navzgor), so naslednje številke za sisteme teh sistemov:

 ~ / jedra / stabilna za Linux (glavni) $ git log --format =% h v4.4.78..v4.4.121 | wc -l2285 ~ / kernel / linux-stable (master) $ git log --format =% h v4.4.78..v4.4.121 arch / arm | wc -l58 ~ / kernels / linux-stable (master) $ git log --format =% h v4.4.78..v4.4.121 arch / arm64 | wc -l22 ~ / kernel / linux-stable (master) $ git log --format =% h v4.4.78..v4.4.121 fs / ext4 | wc -18 

Najbolj zamuden del je začetni učinek; ko ste že na tekočem, ne potrebujete časa, da se združite v novo izdajo, ki običajno vsebuje največ 100 obrezov. Koristi, ki jih to prinaša (večja stabilnost in večja varnost za vaše uporabnike), bi morali zahtevati ta postopek.

Kako združiti stabilno jedro Linuxa v jedro Android

Najprej morate ugotoviti, v kateri različici jedra deluje vaša naprava Android.

Tako nepomembno, kot se zdi, je treba vedeti, kje morate začeti. V vašem drevesu jedra zaženite naslednji ukaz:

 narediti kernelverzijo 

Vrnil 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 katerokoli jedro 4.4), zadnja številka pa bo uporabljena za določitev, katero različico morate začeti s spajanjem (npr. Če ste na 4.4 .21, združiš 4.4.22 naprej).

Zberite najnovejši vir jedra s strani kernel.org

kernel.org hrani najnovejši vir jedra v shrambi, stabilnem za Linux. Na dnu te strani so tri povezave za prenos. Po mojih izkušnjah je Google ogledalo ponavadi najhitrejše, vendar se lahko vaši rezultati razlikujejo. Zaženite naslednje ukaze:

 git oddaljeno dodaj Linux-stabilno //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit donos linux-stable 

Odločite se, ali želite združiti celotno jedro ali prebrati češnje

Nato boste morali izbrati, ali želite združiti obveze ali češnjev nabor. Tukaj so prednosti in slabosti vsakega in kdaj jih boste morda želeli storiti.

OPOMBA: Če je vaš izvor jedra v obliki krogle, boste najverjetneje morali izbrati češnje, sicer boste dobili na tisoče konfliktov datotek, ker git napolnjuje zgodovino, ki temelji izključno na zgornjem delu, ne pa na OEM ali CAF spremenjena. Pojdite na korak 4.

Nabiranje češenj:

Prednosti:

  • Lažje rešite konflikte, saj natančno veste, kateri konflikt povzroča težavo.
  • Lažje obnoviti podatke, saj je vsak zagon sam.
  • Če imate težave, se lažje postavite na predelne stene

Slabosti:

  • Traja dlje, saj je treba vsako zavezo izbrati posebej.
  • Malo težje je ugotoviti, ali je počutje na prvi pogled od zgoraj navzgor

Spoji se

Pros :

  • Hitreje je, saj vam ni treba čakati, da se vsi čisti obliži združijo.
  • Lažje je razbrati, kdaj je zaveza od zgornjega toka, saj vi ne boste zavezanec, vzdrževalec zgornjega toka bo.

Slabosti:

  • Reševanje konfliktov je lahko nekoliko težje, saj boste morali poiskati, kateri storilec povzroča konflikt z uporabo git log / git krivde, ne bo vam neposredno povedal.
  • Ponovno izdajanje je težko, saj združitve ne morete ponovno postaviti, zato boste lahko vse zaveze sami izbrali. Vendar pa ne bi smeli večkrat objavljati različic, namesto tega uporabite gver revert in git merge, kjer je to mogoče.

Priporočam, da izberete češnjo, da najprej odkrijete morebitne težave v konfliktu, naredite združitev, nato pa težavo storite, nato pa se posodobi, tako da je posodabljanje enostavnejše (saj je spajanje hitrejše po posodobitvi).

Obveznosti dodajte v vir, in sicer po eno različico

Najpomembnejši del tega procesa je ena različica naenkrat. V vaši zgornji seriji je lahko napaka, ki bi lahko povzročila težave z zagonom ali zlomil nekaj podobnega zvoku ali polnjenju (razloženo v razdelku z nasveti in triki). Iz tega razloga je pomembno spreminjanje posameznih različic različic, zato je lažje najti težavo v 50 zapovedih kot pri nekaterih različicah več kot 2000 zapovedi. Celotno združitev bi vam priporočal šele, ko boste vedeli vse težave in rešitve konfliktov.

Nabiranje češenj

Oblika:

 git češnjev kramp .. 

Primer:

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

Spoji se

Oblika:

 git spajanje 

Primer:

git združitev v3.10.74

Priporočam, da sledite konfliktom v storitvah združevanja, tako da odstranite oznake #.

Kako razrešiti konflikte

Ne moremo dati navodila po korakih za razrešitev vsakega posameznega konflikta, saj vključuje dobro znanje jezika C, vendar je tu nekaj namigov.

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

  1. git log -pv $ (naredite kernelversion) .., da dobite spremembe med vašo trenutno in najnovejšo različico iz zgornjega toka. Z zastavico -p se prikažejo spremembe, ki jih opravi vsaka zaveza, tako da si jih lahko ogledate.
  2. Zaženite git krivdo na datoteki, da dobite razpršitve vsakega zapisa na tem območju. Nato lahko zaženete git show –format = fuller, da preverite, ali je izvajalec iz mainline / stable, Googla ali CodeAurora.
  • Ugotovite, ali že imate zaveze. Nekateri prodajalci, kot sta Google ali CAF, bodo poskušali poiskati kritične napake navzgor, kot je odpravljanje umazanih COW, in njihovi zaledji bi lahko bili v nasprotju z zgornjimi. Lahko zaženete git log –grep = ”” in vidite, ali vrne kaj. V tem primeru lahko preskočite zavezo (če je nabiranje češenj s pomočjo git reset –hard && git cherry-pick – nadaljevanje) ali prezrite konflikte (odstranite <<<<< >>>>>).
  • Ugotovite, ali je bilo povratno sporočilo, ki je zapletlo ločljivost. Google in CAF radi podpirajo določene popravke, ki jih stabilno ne bi. Stabilni bodo morali pogosto prilagoditi ločljivost glavne zaveze glede na absces nekaterih popravkov, za katere se Google odloči, da podpirajo. Glavni zagon si lahko ogledate tako, da zaženete git show (hash mainline bo na voljo v sporočilu o potrditvi stabilne zaveze). Če se vam bo zapornik zmešal, lahko spremembe zavržete ali pa uporabite različico glavne vrstice (kar boste običajno morali storiti).
  • Preberite si, kaj poskuša narediti in preverite, ali je težava že odpravljena. Včasih CAF lahko odpravi napako, neodvisno od zgornjega dela toka, kar pomeni, da lahko popravite njihov popravek za zgornji del ali pa ga zavržete, kot zgoraj.

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

Tukaj je zrcalo v Linux-stabilnem skladišču kernel.org na GitHub-u, ki je lažje iskati sezname potrditev in se razlikuje pri reševanju konfliktov. Priporočam, da najprej odprete pogled seznama potrditev in poiščete težavo, da si ogledate izvirno različico in jo primerjate z vašim.

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

To lahko storite tudi v ukazni vrstici:

 git dnevnik .. git show 

Reševanje ločljivosti se nanaša na kontekst. VEDNO morate storiti, da se končni različek ujema z zgornjim tokom tako, da v dveh ločenih oknih zaženete naslednje ukaze:

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

Omogoči ponovno uporabo

Git ima funkcijo, imenovano rerere (pomeni ponovno uporabo posnete ločljivosti), kar pomeni, da ko zazna konflikt, zabeleži, kako ste ga rešili, tako da ga lahko kasneje ponovno uporabite. To je še posebej koristno za kronične pripravljalnike, tako z združevanjem kot z nabiranjem češenj, saj boste morali zagnati git add. && git - nadaljujte pri ponovnem vnašanju zgornjega toka, ker bo konflikt rešen, kako ste ga prej rešili.

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

 git config rerere.enabled true 

Kako git bisect, ko teče v prevajalnik napake ali napake izvajanja

Glede na to, da boste dodali veliko število zavez, je zelo verjetno, da vnesete napako prevajalnika ali izvajalca. Namesto da se samo odpoveste, lahko z gitovim vgrajenim bisektnim orodjem ugotovite osnovni vzrok težave! V idealnem primeru boste zgradili in utripali vsako posamezno različico jedra, ko jo dodate, tako da bo sestavljanje seštevkov trajalo manj časa, če pa je potrebno, lahko brez kakršnih koli težav razdelite 5000 naprav.

Git bisect bo naredil vrsto dokumentov, od koder je težava prisotna do mesta, kjer je ni bilo, nato pa začnite razpoloviti obseg zavozov, kar vam omogoča, da sestavite in preizkusite in mu sporočite, ali je dober ali ne . To bo nadaljevalo, dokler ne izpusti zaveze, ki povzroča vašo težavo. V tem trenutku lahko popravite ali povrnete.

  1. Začnite razbijanje: začetek gise bisect
  2. Označite trenutno revizijo kot slabo: git bisect slab
  3. Revizijo označite kot dobro: git bisect good
  4. Gradite z novo revizijo
  5. Na podlagi rezultata (če je težava prisotna ali ne) povejte git: git bisect dober ALI git bisect slab
  6. Izperite in ponovite korake 4-5, dokler težave ne najdete!
  7. Povrnite ali odpravite težavo.

OPOMBA: Združitve bodo morale začasno zagnati git rebase -i, da bodo za pravilno razčlenjenje uporabile vse popravke na vaši podružnici, saj se bisekcije z združenimi meritvami pogosto odjavijo na naročila gorvodnega toka, kar pomeni, da nimate nobenega od posebnih zavez Android. Glede na to se lahko podrobneje ukvarjam s tem, vendar mi zaupajte, da je to potrebno. Ko ugotovite težavo, jo lahko vrnete ali ponovno postavite v združitev.

NE pospravljajte posodobitev navzgornjega toka

Veliko novih razvijalcev je v skušnjavi, da to storijo, saj je to bolj čisto in lažje za upravljanje. To je grozno iz nekaj razlogov:

  • Avtorstvo je izgubljeno. Do drugih razvijalcev ni krivično, da jim je kredit za delo onemogočen.
  • Sekanje je nemogoče. Če nanizujete serijo obdavčitev in je v tej seriji nekaj težav, je nemogoče povedati, kaj je pri storitvi povzročilo težavo.
  • Prihodnji nabiralniki češenj so težji. Če se morate ponovno sestaviti z zlomljeno serijo, je težko / nemogoče povedati, od kod izvira konflikt.

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

Če želite obvestiti vsakič, ko pride do posodobitve navzgornjega toka, se naročite na seznam linux-kernel-sporočite. Tako boste lahko prejeli e-poštno sporočilo vsakič, ko je novo jedro sproščeno, tako da ga lahko posodobite in pritisnete čim hitreje.

Zanimivi Članki