Kaip atnaujinti „Android“ branduolį į naujausią „Linux“ stabilų

nathan @ flashbox ~ / kernels / Linux-stabil (master) $ git log --formatas =% h v4.4.78..v4.4.121 | wc -l2285 nathan @ flashbox ~ / kernels / Linux-stabil (master) $ git log --format =% h v4.4.78..v4.4.121 arch / arm | wc -l58 nathan @ flashbox ~ / kernels / Linux-stabil (master) $ git log --format =% h v4.4.78..v4.4.121 arch / arm64 | wc -l22 nathan @ flashbox ~ / kernels / Linux-stabil (master) $ git log --format =% h v4.4.78..v4.4.121 fs / ext4 | wc -l18

Labiausiai laiko užimanti dalis yra pradinis auklėjimas; kai būsite visiškai atsinaujinęs, visiškai nereikia laiko susilieti su nauju leidimu, kuriame paprastai yra ne daugiau kaip 100 įsipareigojimų. Dėl šios naudos (daugiau stabilumo ir geresnio vartotojo saugumo) šis procesas turėtų būti reikalingas.

Kaip sujungti „Linux“ stabilų branduolį į „Android“ branduolį

Pirmiausia turite išsiaiškinti, kokia jūsų „Android“ įrenginio branduolio versija veikia.

Kad ir kaip trivialiai atrodo, būtina žinoti, nuo ko reikia pradėti. Branduolio medyje vykdykite šią komandą:

padaryti kernelversion

Tai grąžins jūsų naudojamą versiją. Pirmieji du skaičiai bus naudojami norint išsiaiškinti reikalingą šaką (pvz., „Linux-4.4.y“ bet kokiam 4.4 branduoliui), o paskutinis skaičius bus naudojamas nustatant, kurią versiją turite pradėti jungdami (pvz., Jei naudojate 4.4 versiją) .21, tada sujungsite 4.4.22.)

Paimkite naujausią branduolio šaltinį iš kernel.org

kernel.org yra naujausias branduolio šaltinis stabilią „Linux“ saugyklą . To puslapio apačioje bus pateiktos trys nuorodos. Mano patirtis rodo, kad „Google“ veidrodis dažniausiai būna greičiausias, tačiau jūsų rezultatai gali skirtis. Vykdykite šias komandas:

„git“ nuotolinis pridėjimas - stabilus „Linux“ https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit gauti linux-stabilus

Nuspręskite, ar norite sujungti visą branduolį, ar pasirinkti vyšnias

Tada turėsite pasirinkti, ar norite sujungti įsipareigojimus ar rinktis vyšnią. Štai kiekvieno iš jų privalumai ir trūkumai ir kada galbūt norėsite juos padaryti.

PASTABA: Jei jūsų branduolio šaltinis yra „tarball“ pavidalo, greičiausiai turėsite pasirinkti „cherry-pick“, kitaip gausite tūkstančius failų konfliktų, nes „git“ užpildo istoriją grynai priešais, o ne tai, ką pakeitė OEM ar CAF. Tiesiog pereikite prie 4 veiksmo.

Vyšnių rinkimas:

Argumentai už:

• Lengviau išspręsti konfliktus, nes tiksliai žinote, koks konfliktas sukelia problemą.
• Lengviau perkainoti, nes kiekvienas įsipareigojimas yra atskiras.
• Lengviau padalyti į dvi dalis, jei kyla problemų

Minusai:

• Tai užtrunka ilgiau, nes kiekvieną įsipareigojimą reikia pasirinkti atskirai.
• Šiek tiek sunkiau pasakyti, ar įsipareigoti iš pirmo žvilgsnio yra iš aukštupio

Eik

Argumentai 'už' :

• Tai greičiau, nes nereikia laukti, kol visi švarūs pleistrai susilies.
• Lengviau suvokti, kada įsipareigojimas yra iš aukštupio, nes jūs nebūsite įsipareigotojas, prieš tai bus išlaikytojas.

Minusai:

• Konfliktų sprendimas gali būti šiek tiek sunkesnis, nes turėsite sužinoti, kuris įsipareigojimas sukelia konfliktą, naudodamas „git log / git“ kaltę, tai jums tiesiogiai to nepasakys.
• Perkelti iš naujo sunku, nes negalite iš naujo sujungti sujungimo, todėl bus siūloma atskirai pasirinkti visus įsipareigojimus. Tačiau neturėtumėte dažnai perkurti iš naujo, užuot naudoję „git revert“ ir „git sulieti“, jei įmanoma.

Aš rekomenduočiau pasirinkti „cherry-pick“, kad iš pradžių išsiaiškintumėte bet kokius problemų konfliktus, atlikdami sujungimą, po to pakeiskite problemą, kad vėliau būtų lengviau atnaujinti (nes atnaujinimas yra greitesnis sujungimas).

Pridėkite įsipareigojimus prie savo šaltinio po vieną versiją

Svarbiausia šio proceso dalis yra viena versija. Gali būti, kad jūsų ankstesnėje serijoje yra probleminis pleistras, kuris gali sukelti problemų paleidžiant arba sugadinti kažką panašaus į garsą ar įkrovimą (paaiškinta patarimų ir gudrybių skyriuje). Dėl šios priežasties svarbu atlikti laipsniškus versijų pakeitimus, lengviau rasti problemą atlikus 50 įsipareigojimų, nei kai kurioms versijoms viršijus 2000 įsipareigojimų. Visą susijungimą rekomenduočiau atlikti tik tada, kai žinosite visus padarinius ir konfliktų sprendimus.

Vyšnių rinkimas

Formatas:

git cherry-pick ..

Pavyzdys:

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

Eik

Formatas:

eik susilieti

Pavyzdys:

git sulieti v3.10.74

Aš rekomenduoju sekti nesuderinamų įsipareigojimų konfliktus pašalinant # žymeklius.

Kaip išspręsti konfliktus

Negalime pateikti nuoseklaus vadovo kiekvienam konfliktui išspręsti, nes tai susiję su geromis C kalbos žiniomis, tačiau pateikiame keletą patarimų.

Jei jungiatės, išsiaiškinkite, koks įsipareigojimas sukelia konfliktą. Tai galite padaryti vienu iš dviejų būdų:

1. git log -p v $ (padaryti kernelversion) .. norėdami gauti pakeitimus tarp dabartinės versijos ir naujausios iš ankstesnės versijos. -P žymėjimas suteiks kiekvieno įsipareigojimo atliktus pakeitimus, kad galėtumėte pamatyti.
2. Vykdykite failą „git blame“, kad gautumėte kiekvieno įvykio maišos srityje. Tada galite paleisti „git show –format = fuller“, kad sužinotumėte, ar vykdytojas buvo iš pagrindinės linijos / stabilaus, „Google“ ar „CodeAurora“.

• Išsiaiškinkite, ar jau turite įsipareigojimą. Kai kurie pardavėjai, pvz., „Google“ ar CAF, bandys ieškoti svarbių klaidų, pvz., „Dirty COW“ pataisos, o jų užpakaliniai tinklai gali prieštarauti ankstesnėms. Galite paleisti „git log –grep =“ “ir sužinoti, ar jis ką nors grąžina. Jei taip, galite praleisti įsipareigojimą (jei vyšnių rinkimas naudojant „git reset“ - „hard && git cherry-pick“ - tęsti) arba nepaisyti konfliktų (pašalinti<<<<<>>>>>).
• Išsiaiškinkite, ar buvo užpakalinė dalis, kuri sujaukia skiriamąją gebą. „Google“ ir CAF mėgsta remti tam tikrus pataisymus, kurie stabiliai to nedarytų. Stabiliems dažnai reikės pritaikyti pagrindinės linijos skiriamąją gebą, kad nebūtų tam tikrų pataisų, kurias „Google“ pasirenka remti. Galite pažvelgti į pagrindinės linijos įsipareigojimą vykdydami „git show“ (pagrindinės linijos maišos bus pateikiamos stabilaus įsipareigojimo pranešime apie įsipareigojimą). Jei yra užpakalinis uostas, kuris jį sugadina, galite arba atmesti pakeitimus, arba galite naudoti pagrindinės programos versiją (būtent tai jums paprastai reikės padaryti).
• Perskaitykite, ką bando padaryti įsipareigojimas, ir sužinokite, ar problema jau išspręsta. Kartais CAF gali ištaisyti klaidą, nepriklausančią nuo tiekėjų, tai reiškia, kad galite arba perrašyti jų taisymą, ir pašalinti, kaip nurodyta aukščiau.

Priešingu atveju tai gali būti tik CAF / Google / OEM papildymo rezultatas, tokiu atveju jums tereikia sumaišyti kai kuriuos dalykus.

Čia yra „Linux-stabil“ kernel.org saugyklos veidrodis „GitHub“, kuris gali būti lengviau ieškant įsipareigojimų sąrašų ir diferentų konfliktams spręsti. Pirmiausia rekomenduoju eiti į įsipareigojimų sąrašo rodinį ir rasti problemą, kad pamatytumėte originalų skirtumą, kad palygintumėte jį su savo.

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

Tai galite padaryti ir per komandinę eilutę:

git log .. git šou

Sprendimų sprendimas yra susijęs su kontekstu. VISADA turėtumėte padaryti, kad įsitikintumėte, jog jūsų galutinis skirtumas atitinka prieš srovę, vykdydami šias komandas dviem atskirais langais:

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

Įgalinti perrašymą

„Git“ turi funkciją, vadinamą „rerere“ (reiškia Reuse Recorded Resolution pakartotinį naudojimą), tai reiškia, kad aptikęs konfliktą jis įrašys, kaip jūs jį išsprendėte, kad vėliau galėtumėte jį pakartotinai naudoti. Tai ypač naudinga abiem lėtiniams rebaseriams, tiek sujungiant, tiek renkant vyšnias, nes jums tereikia paleisti „git add“. && git - tęskite perduodami ankstesnio pristatymo langą, nes konfliktas bus išspręstas taip, kaip anksčiau jį išsprendėte.

Tai galima įgalinti vykdant šią komandą savo branduolio repo:

git config rerere.enabled tiesa

Kaip suskaidyti į dvi dalis paleidus kompiliatorių ar vykdymo metu

Atsižvelgdami į tai, kad pridėsite nemažai įsipareigojimų, labai įmanoma įvesti kompiliatoriaus ar vykdymo laiko klaidą. Užuot tiesiog atsisakę, galite naudoti „git“ įmontuotą dvikampio įrankį, kad išsiaiškintumėte pagrindinę problemos priežastį! Idealiu atveju jūs sukursite ir mirksėsite kiekvieną branduolio versiją, kai ją pridėsite, todėl dalijimasis prireiks mažiau laiko, tačiau galite padalyti 5000 įsipareigojimų be jokių problemų.

Tai, ką padarys „git bisect“, yra prisiimti įvairius įsipareigojimus, pradedant nuo to, kur problema yra, iki ten, kur jo nebuvo, tada pradėkite perpus sumažinti įsipareigojimų diapazoną, leisdami jums sukurti ir išbandyti bei pranešti, ar tai gerai, ar ne . Tai tęsis tol, kol išpjaus jūsų problemą sukeliantį įsipareigojimą. Tuo metu galite arba pataisyti, arba grąžinti.

1. Pradėkite dalinti du kartus: pradėkite dvipusį startą
2. Pažymėkite dabartinę pataisą kaip blogą: „git bisect blog“
3. Pažymėkite pataisą kaip gerą: git bisect good
4. Sukurkite su nauja redakcija
5. Remdamiesi rezultatu (jei problema yra ar ne), pasakykite „git“: „git bisect good“ arba „git bisect blog“
6. Skalaukite ir pakartokite 4-5 veiksmus, kol bus rasta problema!
7. Grąžinkite arba išspręskite problemą.

PASTABA: Susijungimai turės laikinai paleisti „git rebase -i“, kad visi pleistrai būtų pritaikyti jūsų filialui, kad būtų galima tinkamai padalyti, nes dalijimasis su susiliejančiais sujungimais dažnai nurodo, kad jūs atliksite įsipareigojimus prieš tiekėjus, o tai reiškia, kad jūs neturite jokių konkrečių „Android“ įsipareigojimų. Paprašius galiu išsamiau išsiaiškinti šį klausimą, bet patikėk manimi, jo reikia. Nustatę problemą, galite ją grąžinti arba iš naujo sujungti.

NEGALIMA sutvarkyti naujovių

Daugelis naujų kūrėjų gundo tai padaryti, nes tai yra „švariau“ ir „lengviau“ valdyti. Tai baisu dėl kelių priežasčių:

• Autoriacija prarasta. Nesąžininga kitų kūrėjų atžvilgiu, kai jų darbas yra įskaitytas.
• Dalinti per pusę neįmanoma. Jei sutrumpinsite įsipareigojimų seriją ir kažkas yra tos serijos problema, neįmanoma pasakyti, koks įsipareigojimas sukėlė problemą skvošo metu.
• Būsimos vyšnių kirtikliai yra sunkesni. Jei jums reikia iš naujo pagrįsti sutrauktą seriją, sunku / neįmanoma pasakyti, iš kur kyla konfliktas.

Norėdami laiku atnaujinti, užsiprenumeruokite „Linux“ branduolio adresų sąrašą

Norėdami gauti pranešimą, kai yra naujovinimas, užsisakykite „Linux-kernel-Announce“ sąrašą . Tai leis jums gauti el. Laišką kiekvieną kartą, kai išleidžiamas naujas branduolys, kad galėtumėte kuo greičiau atnaujinti ir perduoti.