kaip

Kaip atnaujinti "Android" branduolį į naujausią "Linux" stabilųjį

Mes apėmėme „Android“ branduolių vadovus, tokius kaip „Kaip sukurti pasirinktinį branduolį“ ir „Geriausi pritaikyti branduoliai„ Android “, tačiau šiandien parodysime, kaip pakelti branduolį prieš naujausią„ Linux “stabilumą.

Atminkite, kad tai sudėtingesni dalykai - jei niekada anksčiau nesudarėte branduolio, turėtumėte vadovautis aukščiau pateiktu vadovu „Kaip sukurti pasirinktinį branduolį“, o šiame vadove bus pateikiamos vyšnių rinkimo ir įsipareigojimų sujungimo iš naujausios „Linux“ versijos versijos. stabilus branduolys su „Android“ branduoliu prieš jį kompiliant.

„Android“ branduolio atnaujinimas į naujausią „Linux“ stabilųjį įrenginį turi daug teigiamų pranašumų, pavyzdžiui, tai, kad esate atnaujintas su naujausiais saugumo įsipareigojimais ir pataisomis - kai kuriuos privalumus ir trūkumus paaiškinsime vėliau šiame vadove.

Kas yra „Linux“ stabilus branduolys?

Stabilus „Linux“, kaip rodo pavadinimas, yra stabili „Linux“ branduolio ranka. Kita ranka yra vadinama „mainline“, kuri yra pagrindinė šaka . Visas „Linux“ branduolio vystymas vyksta pagrindinėje linijoje ir paprastai vyksta pagal šį procesą:

Linus Torvalds dvi savaites iš savo prižiūrėtojų paims krūvą pleistrų.
Po šių dviejų savaičių jis paleidžia rc1 (pvz., 4.14-rc1) branduolį.
Kiekvienai savaitei ateinančias 6-8 savaites jis išleis kitą RC (pvz., 4.14-rc2, 4.14-rc3 ir tt) branduolį, kuriame yra TIK klaidų ir regresijos pataisymai.
Kai jis bus laikomas stabiliu, jis bus paleistas kaip „Tarball“, kurį galima atsisiųsti „org“ (pvz., 4.14).

Kas yra LTS branduoliai?

Kiekvienais metais Gregas pasirinks vieną branduolį ir prižiūrės jį dvejus metus (LTS) arba šešerius metus (pratęstas LTS). Jie skirti turėti stabilumo reikalaujančius produktus (pvz., „Android“ telefonus ar kitus IOT įrenginius). Procesas yra visiškai tas pats, kaip aukščiau, jis tiesiog vyksta ilgesnį laiką. Šiuo metu yra šeši LTS branduoliai (kuriuos visada galima peržiūrėti kernel.org leidimų puslapyje):

4.14 (LTS), prižiūri Gregas Kroahas-Hartmanas
4, 9 (LTS), prižiūri Gregas Kroahas-Hartmanas
4.4 (eLTS), prižiūrimas Grego Kroaho-Hartmano
4.1 (LTS), prižiūri Sasha Levin
3.16 (LTS), prižiūri Benas Hutchingsas
3.2 (LTS), prižiūrimas Beno Hutchingso

Kokie yra mano „Android“ branduolio atnaujinimo į „Linux Stable“ pranašumai?

Kai atskleidžiami / ištaisomi svarbūs pažeidžiamumai, stabilūs branduoliai yra pirmieji, kurie juos gauna. Taigi, jūsų „Android“ branduolys bus daug saugesnis nuo atakų, saugumo trūkumų ir tiesiog nuo klaidų apskritai.

Į „Linux“ stabilumą įtraukta daugybės tvarkyklių, kurių mano „Android“ įrenginys nenaudoja, pataisymai, ar tai dažniausiai nereikalinga?

Taip ir ne, atsižvelgiant į tai, kaip apibrėžiate „dažniausiai“. „Linux“ branduolyje gali būti daug kodo, kuris nenaudojamas „Android“ sistemoje, tačiau tai negarantuoja, kad sujungiant naujas versijas nebus tų failų konfliktų! Supraskite, kad beveik niekas nestato kiekvienos branduolio dalies, net ne patys įprasti „Linux“ diskotekos, tokios kaip „Ubuntu“ ar „Mint“. Tai nereiškia, kad neturėtumėte naudoti šių pataisų, nes ten yra tvarkyklių, kurias vykdote, taisymai. Pavyzdžiui, paimkite „arm / arm64“ ir „ext4“, kurie yra labiausiai paplitusi „Android“ architektūra ir failų sistema. 4.4 punkte nuo 4.4.78 (naujausios „Oreo CAF“ etiketės versija) iki 4.4.121 (naujausia „upstream tag“) yra šie tų sistemų įvykių skaičiai:

 ~ / branduoliai / linux-stabilus (pagrindinis) $ git log --format =% h v4.4.78..v4.4.121 | wc -l2285 ~ / branduoliai / linux-stabilus (pagrindinis) $ git log --format =% h v4.4.78..v4.4.121 arch / arm | wc -l58 ~ / branduoliai / linux-stabilus (pagrindinis) $ git log --format =% h v4.4.78..v4.4.121 arch / arm64 | wc -l22 ~ / branduoliai / linux-stabilus (pagrindinis) $ git log --format =% h v4.4.78..v4.4.121 fs / ext4 | wc -l18

Daugiausia laiko reikalaujanti dalis yra pradinis auklėjimas; Kai esate visą laiką atnaujintas, nereikia daug laiko sujungti į naują laidą, kurioje paprastai yra ne daugiau kaip 100 įsipareigojimų. Vis dėlto šis procesas turėtų reikalauti naudos, kurią tai suteikia (didesnis stabilumas ir didesnis jūsų vartotojų saugumas).

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

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

Kad ir kaip trivialu tai atrodo, būtina žinoti, kur reikia pradėti. Savo branduolio medyje paleiskite šią komandą:

 atlikti branduolio perversmą

Tai grąžins jūsų naudojamą versiją. Pirmieji du skaičiai bus naudojami norint išsiaiškinti jums reikalingą šaką (pvz., „Linux-4.4.y“ bet kokiam 4.4 branduoliui), o paskutinis skaičius bus naudojamas norint nustatyti, kurią versiją reikia pradėti sujungiant (pvz., Jei esate 4.4 versijoje). .21, kitą kartą sujungsite 4.4.22).

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

kernel.org talpina naujausią branduolio šaltinį linux stabilioje saugykloje. Puslapio apačioje bus trys pateikiamos nuorodos. Mano patirtis rodo, kad „Google“ veidrodis yra greičiausias, tačiau jūsų rezultatai gali skirtis. Vykdykite šias komandas:

 „git“ nuotoliniu būdu pridėti „Linux“ stabilų //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit iškelti linux stabilų

Nuspręskite, ar norite sujungti visą branduolį, ar pasirinkti vyšnių rinkinį

Tada turėsite pasirinkti, ar norite sujungti įpareigojimus, ar pasirinkti vyšnių rinkinį. Čia yra kiekvieno privalumai ir trūkumai, kada jūs galite juos padaryti.

PASTABA: Jei jūsų branduolio šaltinis yra „tarball“ forma, greičiausiai jums reikės pasirinkti „vyšnią“, kitaip gausite tūkstančius failų konfliktų, nes „Git“ istorija remiasi vien tik „upstream“, o ne tuo, ką turi „OEM“ ar „CAF“. pasikeitė. Tiesiog pereikite prie 4 veiksmo.

Vyšnių rinkimas:

Argumentai už:

Lengviau išspręsti konfliktus, nes tiksliai žinote, koks konfliktas sukelia problemą.
Lengviau pakartoti, nes kiekvienas įsipareigojimas yra savarankiškas.
Lengviau skaidyti, jei kyla problemų

Minusai:

Tai užtrunka ilgiau, nes kiekvienas įsipareigojimas turi būti pasirenkamas atskirai.
Šiek tiek sunkiau pasakyti, ar įsipareigojimas iš pirmo žvilgsnio kyla iš aukščiau

Sujungti

Argumentai už :

Tai greičiau, nes nereikia laukti, kol visi švarūs pleistrai susijungs.
Lengviau pastebėti, kai įsipareigojimas vykdomas iš aukščiau esančios įmonės, nes nebūsite įsipareigotojas, o aukščiau esančio subjekto išlaikytojas bus.

Minusai:

Išspręsti konfliktus gali būti šiek tiek sunkiau, nes jums reikės išsiaiškinti, kuris įsipareigojimas sukelia konfliktą, naudojant git log / git kaltę, tai jums to tiesiogiai nepasakys.
Atnaujinti sunku, nes negalite pakartotinai sujungti, tai pasiūlysite pasirinkti visus įsipareigojimus atskirai. Tačiau nereikėtų dažnai rebasuoti, vietoj to, kur įmanoma, naudoti „git revert“ ir „git merge“.

Aš rekomenduočiau pasirinkti pavyzdį, jei norite išsiaiškinti bet kokius problemų konfliktus, atlikdami sujungimą, po to grąžindami problemą, todėl vėliau atnaujinti yra lengviau (nes susijungimas yra greitesnis, jei atnaujinate).

Pridėkite įsipareigojimus prie savo šaltinio, vieną versiją vienu metu

Svarbiausia šio proceso dalis yra viena versija. Jūsų tiekėjų serijoje Gali būti problemų pataisymas, kuris gali sukelti paleidimo problemą arba sugadinti kažką panašaus į garsą ar įkrovimą (paaiškinta patarimų ir gudrybių skyriuje). Dėl šios priežasties svarbu atlikti laipsniškus versijos pakeitimus, lengviau rasti problemą 50-yje įsipareigojimų, nei kai kuriose versijose - daugiau nei 2000-yje. Aš rekomenduočiau visiškai sujungti tik tada, kai žinosite apie visus įsipareigojimus ir konfliktų sprendimus.

Vyšnių rinkimas

Formatas:

 git vyšnių skinti ..

Pavyzdys:

git vyšnių rinkimas v3.10.73..v3.10.74

Sujungti

Formatas:

 git sujungti

Pavyzdys:

git merge v3.10.74

Aš rekomenduoju sekti konfliktus sujungiant įsipareigojimus pašalinant # žymenis.

Kaip išspręsti konfliktus

Negalime pateikti nuoseklaus vadovo, kaip išspręsti kiekvieną konfliktą, nes tai reiškia geras C kalbos žinias, tačiau čia yra keletas patarimų.

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

git log -pv $ (make kernelversion) .. Norėdami gauti pakeitimus tarp dabartinės versijos ir naujausios versijos. -P vėliava suteiks jums kiekvieno įsipareigojimo atliktus pakeitimus, kad galėtumėte pamatyti.
Vykdykite pagrindinę bylą, kad gautumėte kiekvieno įsipareigojimo judesius šioje srityje. Tada galite paleisti „git show –format = full“, kad sužinotumėte, ar nusikaltimo dalyvis buvo iš pagrindinės / stabilios, „Google“ ar „CodeAurora“.

Išsiaiškink, ar jau įsipareigoji. Kai kurie pardavėjai, tokie kaip „Google“ ar CAF, bandys ieškoti kritinių klaidų, pvz., „Dirty COW“ pataisų, ir jų atgalinis turinys gali prieštarauti aukščiau esančioms įmonėms. Galite paleisti „git log –grep =“ “ir pažiūrėti, ar jis ką nors grąžina. Jei tai atsitiks, galite praleisti įsipareigojimą (jei vyšnių rinkimas atliekamas naudojant „git reset“ - sunku ir & git vyšnių rinkimas - tęsti) arba ignoruoti konfliktus (pašalinti <<<<< >>>>>).
Išsiaiškinkite, ar nebuvo užnugario, kuris trikdo skiriamąją gebą. „Google“ ir CAF mėgsta kurti tam tikras pataisas, kurios stabilios nebus. Stabiliam dažnai reikės pritaikyti pagrindinio įsipareigojimo skiriamąją gebą atsižvelgiant į tam tikrų pataisų, kurias „Google“ pasirenka remti, atsisakymą. Galite pažvelgti į pagrindinį įsipareigojimą vykdydami „Git Show“ (pagrindinė maiša bus prieinama stabiliojo įsipareigojimo pranešime). Jei egzistuoja tai, kas jį sujaukia, galite atmesti pakeitimus arba galite naudoti pagrindinės linijos versiją (kurią dažniausiai turėsite padaryti).
Perskaitykite, ką įsipareigoja daryti, ir patikrinkite, ar problema jau išspręsta. Kartais CAF gali ištaisyti klaidą, nepriklausomai nuo aukščiau esančio vartotojo, tai reiškia, kad galite arba perrašyti aukščiau esančio vartotojo pataisymą, arba atsisakyti, kaip aprašyta aukščiau.

Priešingu atveju tai gali būti tiesiog CAF / „Google“ / OEM papildymo rezultatas. Tokiu atveju jums tiesiog reikia pamaišyti kai kuriuos dalykus.

Čia yra „Linux“ stabilios „kernel.org“ saugyklos „GitHub“ veidrodis, kuriame gali būti lengviau ieškoti įsipareigojimų sąrašų ir išspręsti konfliktus. Aš rekomenduoju pirmiausia patekti į įsipareigojimų sąrašo rodinį ir rasti problemą, kad pamatytumėte originalų skirtumą, kad palygintumėte jį su jūsų.

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

Tai taip pat galite padaryti naudodami komandinę eilutę:

 Git Log .. Git Rodyti

Sprendimų sprendimas susijęs su kontekstu. Viskas, ką visada turėtumėte padaryti, tai įsitikinkite, kad galutinis diferencialas sutampa su pasroviui, vykdydami šias komandas dviejuose atskiruose languose:

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

Įgalinti perregistravimą

„Git“ turi funkciją, vadinamą „rerere“ (reiškia pakartotinai įrašytą rezoliuciją), tai reiškia, kad aptikus konfliktą, ji užfiksuos, kaip jūs ją išsprendėte, kad galėtumėte vėliau ją pakartotinai naudoti. Tai ypač naudinga tiek lėtiniams atgimimo atvejams, tiek sujungiant, tiek imant vyšnias, nes jums tereikės paleisti „git add“. &&git - tęskite, kai pakartotinai pateikiate aukcioną, nes konfliktas bus išspręstas taip, kaip jūs anksčiau jį išsprendėte.

Tai gali būti įgalinta, paleidžiant šią komandą savo branduolio atpirkime:

 git config rerere.enabled true

Kaip pritraukti kompiliatorių ar vykdymo laiko klaidą

Atsižvelgiant į tai, kad pridėsite nemažą skaičių pavedimų, labai įmanoma, kad įvesite kompiliatorių ar vykdymo laiko klaidą. Užuot tiesiog atsisakius, naudodamiesi įmontuotu „git bisect“ įrankiu išsiaiškinkite pagrindinę problemos priežastį! Idealiu atveju jūs sukursite ir mirksės kiekviena branduolio versija, kai ją pridėsite, taigi skilimas prireiks mažiau laiko, bet jei norite, galite atskirti 5000 įsakymų be jokių problemų.

Tai, ką padarysite, bus prisiimti įvairius įsipareigojimus, pradedant nuo problemos aktualumo, 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 neišnaikins įsipareigojimo, dėl kurio kilo jūsų problema. Tada galite ją ištaisyti arba grąžinti.

Pradėkite dalijimąsi: pradėkite dvi dalis
Pažymėkite dabartinę versiją kaip blogą: blogai padarykite blogą
Pažymėkite recenziją kaip gerą: duokite gerą
Kurkite su nauja versija
Remdamiesi rezultatu (jei problema yra ar nėra), pasakykite git: git bisect good ARBA git bisect blogas
Nuplaukite ir pakartokite 4-5 veiksmus, kol bus rastas problemos sprendimas!
Grąžinkite arba ištaisykite problemą.

PASTABA: Susiliejimams reikės laikinai paleisti „git rebase -i“, kad būtų galima pritaikyti visus pleistrus jūsų šakai, kad jie būtų tinkamai perpjaunami, nes dalijimasis su atliktais sujungimais dažnai kartojasi į aukščiau esančius įsipareigojimus, tai reiškia, kad jūs neturite nė vieno iš „Android“ konkrečių įsipareigojimų. Pateikęs prašymą galiu gilintis į tai, bet pasitikėk manimi, jis reikalingas. Kai išsiaiškinsite problemą, galite ją sugrąžinti arba pakartotinai sujungti.

NEMOKITE srautinių naujinimų

Daugybė naujų kūrėjų nori tai padaryti, nes tai yra „švaresnis“ ir „lengvesnis“ valdymas. Tai yra siaubinga dėl kelių priežasčių:

Autorystė prarasta. Nesąžininga kitų kūrėjų atžvilgiu, jei jų darbui yra suteikiamos paskolos.
Dvipusiai neįmanoma. Jei jūs supjaustote kelis įpareigojimus ir kažkas yra tos serijos problema, neįmanoma pasakyti, koks įsipareigojimas sukėlė moliūgo problemą.
Ateities vyšnių skynės yra kietesnės. Jei jums reikia atsinaujinti pritrūkusia serija, sunku / neįmanoma pasakyti, iš kur kyla konfliktas.

Norėdami laiku atnaujinti prenumeruokite „Linux Kernel“ adresų sąrašą

Norėdami gauti pranešimus apie atnaujinimus prieš vartotoją, užsiprenumeruokite „Linux“ branduolio-pranešimų sąrašą. Tai leis jums gauti el. Laišką kaskart išleidžiant naują branduolį, kad galėtumėte atnaujinti ir stumti kuo greičiau.