Android-ytimen päivittäminen viimeisimmäksi Linux-vakaaksi

Neuvovat: Klikkaa Korjata Windows Virheitä Ja Optimoida Järjestelmän Suorituskykyä

Olemme käsittäneet Android-ytimien oppaat, kuten ”Kuinka rakentaa mukautettu ydin” ja “Parhaat mukautetut ytimet Androidille”, mutta tänään aiomme näyttää, kuinka ytimeesi voidaan upottaa viimeisintä Linux-vakautta vastaan.

Huomaa, että tämä on edistyksellisiä juttuja - jos et ole koskaan koonnut ydintä aiemmin, sinun tulee noudattaa yllä linkitettyä opasta ”Kuinka rakentaa mukautettu ydin”, ja tähän oppaaseen sisältyy kirsikkakeräily ja sitoutumisten yhdistäminen uusimmasta Linux- vakaa ydin Android-ytimen kanssa, ennen kuin käännät sen.

Android-ytimen päivittämisellä uusimpaan Linux-vakaaseen on paljon myönteisiä etuja, kuten päivitys viimeisimpiin tietoturvakomiteoihin ja virhekorjauksiin - selitämme joitain eduista ja haitoista myöhemmin tässä oppaassa.

Mikä on Linux-vakaa ydin?

Linux-vakaa, kuten nimestä käy ilmi, on Linux-ytimen vakaa käsivarsi. Toinen varsi tunnetaan nimellä "mainline", joka on päähaara . Kaikki Linux-ytimen kehitys tapahtuu päälinjassa, ja se noudattaa yleensä tätä prosessia:

  1. Linus Torvalds ottaa joukon korjaustiedostoja ylläpitäjiltään kahden viikon ajan.
  2. Tämän kahden viikon kuluttua hän vapauttaa rc1 (esim. 4.14-rc1) ytimen.
  3. Jokaisesta seuraavan 6-8 viikon viikosta hän vapauttaa toisen RC (esim. 4.14-rc2, 4.14-rc3 jne.) -Ydin, joka sisältää VAIN virhe- ja regressiokorjauksia.
  4. Kun sen katsotaan olevan vakaa, se julkaistaan ​​tarballina ladattavaksi organisaatiossa (esim. 4.14).

Mitä LTS-ytimet ovat?

Joka vuosi Greg valitsee yhden ytimen ja ylläpitää sitä joko kaksi vuotta (LTS) tai kuusi vuotta (laajennettu LTS). Ne on suunniteltu käyttämään tuotteita, jotka tarvitsevat vakautta (kuten Android-puhelimet tai muut IOT-laitteet). Prosessi on täsmälleen sama kuin yllä, se tapahtuu vain pidempään aikaan. Tällä hetkellä on kuusi LTS-ydintä (joita voi aina katsella kernel.org-julkaisusivulla):

  • 4, 14 (LTS), ylläpitää Greg Kroah-Hartman
  • 4, 9 (LTS), ylläpitää Greg Kroah-Hartman
  • 4.4 (eLTS), ylläpitäjä Greg Kroah-Hartman
  • 4, 1 (LTS), ylläpitäjä Sasha Levin
  • 3, 16 (LTS), ylläpitää Ben Hutchings
  • 3.2 (LTS), ylläpitää Ben Hutchings

Mitä hyötyä on Android-ytimen päivittämisestä Linux Stable -sovellukseen?

Kun tärkeät haavoittuvuudet paljastetaan / korjataan, vakaat ytimet saavat ne ensin. Siten Android-ytimesi on paljon turvallisempi hyökkäyksiä, tietoturvavirheitä ja vain virheitä vastaan.

Linux-vakaa sisältää korjauksia monille ohjaimille, joita Android-laite ei käytä. Eikö tämä ole enimmäkseen turhaa?

Kyllä ja ei, riippuen siitä, kuinka määrittelet ”enimmäkseen”. Linux-ytimessä voi olla paljon koodia, jota ei käytetä Android-järjestelmässä, mutta se ei takaa, että näistä tiedostoista ei tule ristiriitoja uusien versioiden yhdistämisen yhteydessä! Ymmärrä, että käytännössä kukaan ei rakenna ytimen jokaista osaa, edes edes yleisimmät Linux-distrossa kuten Ubuntu tai Mint. Tämä ei tarkoita, että sinun ei pitäisi ottaa näitä korjauksia, koska TEillä on korjauksia ohjaimille, joita käytät. Otetaan esimerkiksi arm / arm64 ja ext4, jotka ovat yleisin Android-arkkitehtuuri ja vastaavasti tiedostojärjestelmä. Kohdassa 4.4, luvusta 4.4.78 (viimeisimmän Oreo CAF -tagin versio) - 4.4.121 (viimeisin ylävirran tunniste), nämä ovat seuraavat numerot näiden järjestelmien toimeksiannoille:

 ~ / ytimet / linux-stabiili (master) $ git log --muoto =% h v4.4.78..v4.4.121 | wc -l2285 ~ / ytimet / linux-stabiili (master) $ git log --muoto =% h v4.4.78..v4.4.121 arch / arm | wc -l58 ~ / ytimet / linux-stabiili (master) $ git log --muoto =% h v4.4.78..v4.4.121 arch / arm64 | wc -l22 ~ / ytimet / linux-stabiili (master) $ git log --muoto =% h v4.4.78..v4.4.121 fs / ext4 | wc-l18 

Kaikkein aikaa vievämpi osa on ensimmäinen kasvatus; Kun olet aina ajan tasalla, ei vie ollenkaan aikaa yhdistää uutta julkaisua, joka sisältää yleensä enintään 100 toimeksiantoa. Tämän hyödyn (lisää vakautta ja parempaa turvallisuutta käyttäjillesi) pitäisi kuitenkin tarvita tämä prosessi.

Kuinka yhdistää Linuxin vakaa ydin Android-ytimeen

Ensin on selvitettävä, mikä ytimen versio Android-laitteesi on käynnissä.

Niin triviaalia kuin tämä näyttää, on välttämätöntä tietää, mistä aloitat. Suorita seuraava komento ytimen puussa:

 tee ydinversio 

Se palauttaa käyttämäsi version. Kahta ensimmäistä numeroa käytetään selvittämään tarvitsemasi haara (esim. Linux-4.4.y mille tahansa 4.4-ytimelle) ja viimeistä numeroa käytetään määrittämään, minkä version haluat aloittaa yhdistämällä (esim. Jos olet 4.4 .21, yhdistät seuraavan 4.4.22).

Tartu uusimpaan ytimen lähteeseen kernel.org

kernel.org sisältää uusimman ytimen lähteen linuxvakaassa arkistossa. Sivun alareunassa on kolme hakulinkkiä. Kokemukseni mukaan Googlen peili on yleensä nopein, mutta tuloksesi voivat vaihdella. Suorita seuraavat komennot:

 git remote add linux-vakaa //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit nouta linux-vakaa 

Päätä, haluatko yhdistää koko ytimen vai valitako kirsikka-valintaruudut

Seuraavaksi sinun on valittava, haluatko yhdistää sitoumukset vai kirsikka-poiminnan. Tässä on edut ja haitat jokaiselle ja milloin haluat ehkä tehdä ne.

HUOMAUTUS: Jos ytimen lähde on tarball-muodossa, joudut todennäköisesti kirsikka-poimintaan, muuten saat tuhansia tiedostokonflikteja, koska git käyttää historiaa puhtaasti ylävirtaan, ei siihen, mitä OEM: llä tai CAF: lla on muuttunut. Hyppää vain vaiheeseen 4.

Kirsikoiden poiminta:

Plussat:

  • Ristiriitojen ratkaiseminen on helpompaa, koska tiedät tarkalleen, mikä konflikti aiheuttaa ongelman.
  • Helpointa uudistaa, koska jokainen sitoumus on oma.
  • Helppo puolittaa, jos törmää ongelmiin

Haittoja:

  • Kestää kauemmin, koska jokainen sitoumus on valittava erikseen.
  • Hieman vaikeampi sanoa, onko sitoutuminen ensimmäisellä silmäyksellä ylävirtaan

Yhdistää

Plussaa :

  • Se on nopeampaa, koska sinun ei tarvitse odottaa kaikkien puhtaanjen laastarien sulautumista.
  • On helpompi nähdä, kun sitoutuminen tapahtuu ylävirtaan, koska et ole toimeenpanija, ylävirran ylläpitäjä on.

Haittoja:

  • Ristiriitojen ratkaiseminen voi olla hiukan vaikeampaa, koska joudut etsimään, mikä sitoutuminen aiheuttaa konfliktin käyttämällä git log / git syytä, se ei kerro sinulle suoraan.
  • Rebassointi on vaikeaa, koska et voi yhdistää yhdistelmää uudelleen, se tarjoaa valita kaikki sitoutuneet erikseen. Sinun ei pitäisi kuitenkaan rentoutua usein, vaan käyttää git revert ja git merge jos mahdollista.

Suosittelen, että valitset kirsikkavalinnan selvittääksesi mahdolliset konfliktit aluksi, tekemällä yhdistämisen, palauttaaksesi ongelman sitkeästi myöhemmin, joten päivittäminen on helpompaa (koska yhdistäminen on nopeampaa päivityksen jälkeen).

Lisää sitoumukset lähdeisiisi, yksi versio kerrallaan

Tärkein osa tätä prosessia on yksi versio kerrallaan. Upstream-sarjassasi voi olla ongelmakorjaus, joka voi aiheuttaa ongelmia käynnistyksessä tai katkaista esimerkiksi ääni tai lataus (selostettu vinkit-osiossa). Vaiheittaisten versionmuutosten tekeminen on tärkeää tästä syystä, on helpompaa löytää ongelma 50 toimeksiannossa kuin ylöspäin 2000: n toimeksiannosta joillekin versioille. Suosittelen täydellistä yhdistämistä vasta, kun tiedät kaikki ongelman sitoumukset ja konfliktin ratkaisut.

Kirsikoiden poiminta

Muoto:

 git kirsikka-poiminta .. 

Esimerkki:

git kirsikkavalinta v3.10.73..v3.10.74

Yhdistää

Muoto:

 git sulautua 

Esimerkki:

git merge v3.10.74

Suosittelen seuraamaan konflikteja sulautumissitoumuksissa poistamalla # -merkit.

Kuinka ratkaista konfliktit

Emme voi antaa vaiheittaisia ​​ohjeita jokaisen konfliktin ratkaisemiseksi, koska siihen liittyy hyvä C-kielen tuntemus, mutta tässä on muutamia vinkkejä.

Jos yhdistät, selvitä mikä sitoutuminen aiheuttaa konfliktin. Voit tehdä tämän kahdella tavalla:

  1. git log -pv $ (tee kernelversion) .. saadaksesi muutokset nykyisen version ja viimeisimmän välillä ylävirtaan. P-lippu antaa sinulle muutokset, jotka jokainen sitoutuu tekemään, jotta voit nähdä.
  2. Suorita git blame tiedostossa saadaksesi kunkin alueen sitoutumisen tiivistelmät. Voit sitten suorittaa git show –format = fulller nähdäksesi oliko toimeksiantaja päälinja / vakaa, Google tai CodeAurora.
  • Selvitä, onko sinulla jo sitoutunut. Jotkut myyjät, kuten Google tai CAF, yrittävät etsiä kriittisiä virheitä, kuten Dirty COW -korjausta, ja heidän takakannat voivat olla ristiriidassa tuotantoketjun loppupään kanssa. Voit suorittaa git log –grep = ”” ja nähdä, palauttaako se mitään. Jos näin käy, voit ohittaa sitoumuksen (jos kirsikan poiminta käyttämällä git reset –hard && git kirsikan valitsinta - jatkaa) tai jättää konfliktit huomiotta (poista <<<<< >>>>>).
  • Selvitä, onko jokin taustaportti sekoittanut päätöslauselman. Google ja CAF haluavat tukea tiettyjä korjauksia, jotka eivät vakaa. Vakaan on usein mukautettava päälinjan päätöslauselma tiettyjen korjausten poissaolosta, jotka Google päättää tukea. Voit katsoa päälinjan sitoutumista suorittamalla git show (pääradan tiiviste on saatavana vakaan sitoutumisen viestissä). Jos siellä on backport, joka sekoittaa sen, voit joko hylätä muutokset tai käyttää päälinjaversiota (mikä sinun on yleensä tehtävä).
  • Lue mitä sitoutuminen yrittää tehdä ja katso jos ongelma on jo korjattu. Joskus CAF voi korjata virheen, joka on riippumaton ylävirtaan, mikä tarkoittaa, että voit joko korvata niiden korjauksen ylävirtaan tai hylätä se, kuten yllä.

Muuten se voi johtua vain CAF / Google / OEM-lisäyksestä, jolloin sinun on vain sekoitettava joitain asioita.

Tässä on GitHubin Linux-vakaan kernel.org-arkiston peili, josta voi olla helpompaa etsiä sitoutumisluetteloita ja hajautuksia konfliktien ratkaisemiseksi. Suosittelen menemään ensin sitoutumisluettelonäkymään ja etsimällä ongelma sitoutumaan, jotta näet alkuperäisen eron vertaillaksesi omaasi.

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

Voit tehdä sen myös komentorivin kautta:

 git log .. git show 

Päätöslauselmien ratkaiseminen liittyy kontekstiin. Sinun tulisi aina varmistaa, että lopullinen ero vastaa ylävirtaan suorittamalla seuraavat komennot kahdessa erillisessä ikkunassa:

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

Ota uudelleenrekisteröinti käyttöön

Gitillä on ominaisuus nimeltään rerere (tarkoittaa uudelleen tallennettua resoluutiota), mikä tarkoittaa, että kun se havaitsee ristiriidan, se tallentaa kuinka ratkaisit sen, jotta voit käyttää sitä myöhemmin uudelleen. Tämä on erityisen hyödyllistä molemmille kroonisille rebasereille sekä sulautumisen että kirsikan poiminnan yhteydessä, koska sinun täytyy vain suorittaa git add. && git - jatka, kun uudelleentarkastelet ylävirtaan tulevaa tilausta, koska konflikti ratkaistaan ​​tavalla, jolla olet aiemmin ratkaissut sen.

Se voidaan ottaa käyttöön suorittamalla seuraava komento ytimen repo-ohjelmassa:

 git config rerere.enabled true 

Kuinka puolittaa, kun törmäät kääntäjään tai suoritusaikavirheeseen

Koska lisäät suuren määrän toimeksiantoja, on erittäin mahdollista ottaa käyttöön kääntäjä- tai suoritusaikavirhe. Sen sijaan, että vain luovut, voit käyttää gitin sisäänrakennettua puolityökalua selvittääksesi ongelman perimmäisen syyn! Ihannetapauksessa rakennat ja vilkutat jokaista ytimen versiota lisättäessäsi, joten puolittaminen vie vähemmän aikaa tarvittaessa, mutta voit puolittaa 5000-komennot ilman mitään ongelmia.

Ainoa puolue, joka tehdään, on ryhtyä joukkoon sitoumuksia, mistä lähtien asia on läsnä, minne sitä ei ollut, ja sitten aloittaa puolittaminen sitoumusalueella, jolloin voit rakentaa ja testata ja antaa sen tietää, onko se hyvä vai ei. . Se jatkaa tätä, kunnes se sylkee ongelman aiheuttaneen sitoumuksen. Tässä vaiheessa voit joko korjata sen tai palauttaa sen.

  1. Aloita puolittaminen: aloita puolittaminen
  2. Merkitse nykyinen versio huonoksi: gise bisect bad
  3. Merkitse versio hyväksi: tee puoliksi hyvä
  4. Luo uusi versio
  5. Kerro git: git bisect good TAI git bisect bad tuloksen perusteella (jos ongelma on olemassa tai ei)
  6. Huuhtele ja toista vaiheet 4-5, kunnes ongelma on löydetty!
  7. Palauta tai korjaa ongelma.

HUOMAUTUS: Sulautumisten on suoritettava väliaikaisesti git rebase -i, jotta kaikki korjaustiedostot lisätään haaraasi oikean puolittamisen vuoksi, koska puolittaminen sulautumalla paikallaan suorittaa usein tarkistuksia ylävirran sitoumuksiin, mikä tarkoittaa, että sinulla ei ole mitään Android-erityisiä sitoumuksia. Voin syventää tätä asiaa pyynnöstä, mutta luota minuun, sitä tarvitaan. Kun olet tunnistanut ongelman sitoutumisen, voit palauttaa sen tai yhdistää sen uudelleen yhdistämiseen.

ÄLÄ squash upstream-päivityksiä

Monilla uusilla kehittäjillä on houkutus tehdä tämä, koska se on ”puhtaampaa” ja “helpompaa” hallita. Tämä on kauheaa muutamasta syystä:

  • Kirjallisuus on menetetty. On epäreilua muiden kehittäjien suhteen, jos heidän luotonsa vaaditaan heidän työstään.
  • Halkaisu on mahdotonta. Jos puristat sarjan sitoumuksia ja jotain on kyseisen sarjan aihe, on mahdotonta sanoa, mikä sitoumus aiheutti aiheen squashissa.
  • Tulevat kirsikkavinkit ovat vaikeampia. Jos tarvitset uudelleen base-up sarjan kanssa, on vaikea / mahdotonta kertoa mistä konflikti johtuu.

Tilaa Linux-ytimen postitusluettelo päivittääksesi ne ajoissa

Tilaa linux-ydin-ilmoitusta -luettelo saadaksesi ilmoituksen aina, kun päivitystä on saatavilla. Tämän avulla voit saada sähköpostin joka kerta, kun uusi ydin julkaistaan, jotta voit päivittää ja työntää mahdollisimman nopeasti.

Mielenkiintoisia Artikkeleita