kuidas

Kuidas värskendada Androidi tuuma uusimale Linuxi stabiilsele versioonile

Oleme hõlmanud Androidi tuumade juhendeid, näiteks „Kuidas kohandatud kernelit luua” ja „Androidi parimad kohandatud tuumad”, kuid täna näitame teile, kuidas kerneli uusimale Linuxi stabiilsele versioonile vastu võtta.

Pange tähele, et see on edasijõudnud kraam - kui te pole kunagi tuuma koostanud, peaksite järgima ülaltoodud juhendit „Kuidas kohandatud tuuma üles ehitada” ja see juhend hõlmab kirsside kogumist ja uusimate Linuxi versioonide sidumist stabiilse kerneli oma Androidi tuumaga enne selle kompileerimist.

Teie Androidi tuuma ülekandmisel uusimale Linuxi stabiilsele versioonile on palju positiivseid eeliseid, näiteks uusimate turvakomiteede ja veaparandustega kursis hoidmine - mõned eelised ja miinused selgitame selles juhendis hiljem.

Mis on Linuxi stabiilne kernel?

Nagu nimigi viitab, on stabiilne Linuxi kerneli stabiilne osa. Teist haru tuntakse kui mainline, mis on peamine haru . Kõik Linuxi kerneli arendused toimuvad põhiliinides ja järgivad seda protsessi üldiselt:

Linus Torvalds võtab kahe nädala jooksul oma hooldajatelt hunniku plaastreid.
Pärast seda kahte nädalat vabastab ta rc1 (nt 4.14-rc1) tuuma.
Järgmise 6-8 nädala jooksul iga nädala jaoks vabastab ta uue RC (nt 4.14-rc2, 4.14-rc3 jne) tuuma, mis sisaldab AINULT vea- ja regressiooniparandusi.
Kui seda stabiilseks loetakse, vabastatakse see orgonis allalaadimiseks tarbona (nt 4.14).

Mis on LTS-i tuumad?

Igal aastal valib Greg ühe tuuma ja hooldab seda kas kaks aastat (LTS) või kuus aastat (pikendatud LTS). Need on mõeldud stabiilsust vajavate toodete jaoks (näiteks Androidi telefonid või muud IOT-seadmed). Protsess on täpselt sama nagu ülalpool, see toimub lihtsalt pikema aja jooksul. Praegu on kuus LTS-tuuma (mida saab alati vaadata kernel.org releases lehel):

4.14 (LTS), haldaja Greg Kroah-Hartman
4, 9 (LTS), haldaja Greg Kroah-Hartman
4.4 (eLTS), haldaja Greg Kroah-Hartman
4.1 (LTS), hooldaja Sasha Levin
3.16 (LTS), hooldaja Ben Hutchings
3.2 (LTS), hooldaja Ben Hutchings

Mis kasu on minu Androidi kerneli versioonile Linux Stable ülekandmisest?

Oluliste haavatavuste avalikustamisel / parandamisel on stabiilsed tuumad esimesed, mis neid saadavad. Seega on teie Androidi tuum rünnakute, turvavigade ja lihtsalt vigade vastu palju turvalisem.

Linuxi stabiilne sisaldab parandusi paljudele draiveritele, mida mu Android-seade ei kasuta, kas see pole enamasti tarbetu?

Jah ja ei, sõltuvalt sellest, kuidas määratlete „enamasti“. Linuxi kernel võib sisaldada palju koodi, mis jääb Androidi süsteemis kasutamata, kuid see ei taga, et uute versioonide liitmisel nendest failidest konflikte ei teki! Saage aru, et tegelikult ei ehita keegi tuuma iga osa, isegi mitte kõige tavalisemad Linuxi distrod nagu Ubuntu või Mint. See ei tähenda, et te ei peaks neid parandusi kasutama, kuna draiveritel, mida juhite, on olemas parandusi. Võtke näiteks arm / arm64 ja ext4, mis on vastavalt tavalisemad Androidi arhitektuur ja failisüsteem. Punktis 4.4, alates 4.4.78 (uusima Oreo CAF sildi versioon) kuni 4.4.121 (uusim ülesvoolu silt), on need süsteemide toime pandud järgmised numbrid:

 ~ / tuumad / linux-püsiv (ülem) $ git log --vorming =% h v4.4.78..v4.4.121 | wc -l2285 ~ / tuumad / linux-püsiv (ülem) $ git log - vorming =% h v4.4.78..v4.4.121 arch / arm | wc -l58 ~ / tuumad / linux-püsiv (ülem) $ git log - vorming =% h v4.4.78..v4.4.121 arch / arm64 | wc -l22 ~ / tuumad / linux-stabiilne (master) $ git log - vorming =% h v4.4.78..v4.4.121 fs / ext4 | wc-l18

Kõige aeganõudvam osa on esialgne ülespanek; Kui olete kogu aeg kursis, ei võta üldse aega uue väljaande liitmine, mis sisaldab tavaliselt kuni 100 kohustust. Selle eelised (suurem stabiilsus ja parem turvalisus teie kasutajatele) peaksid seda protsessi siiski tingima.

Kuidas liita Linuxi stabiilne kernel Androidi tuuma

Kõigepealt peate välja mõtlema, millise kerneli versiooni teie Android-seade töötab.

Nii triviaalne kui see ka ei tundu, on vaja teada, kust peate alustama. Käivitage oma kerneli puus järgmine käsk:

 teha kernelversioon

See tagastab teie kasutatava versiooni. Kahte esimest numbrit kasutatakse vajaliku haru väljaarvutamiseks (nt linux-4.4.y mis tahes 4.4 tuuma jaoks) ja viimast numbrit kasutatakse selle määramiseks, millist versiooni peate liitmisega alustama (nt kui olete 4.4 .21, ühendate järgmiseks 4.4.22).

Haarake uusim kerneli allikas saidilt kernel.org

kernel.org sisaldab uusimat kerneli allikat Linuxi-stabiilses hoidlas. Selle lehe allosas on kolm toomise linki. Minu kogemuse kohaselt kipub Google'i peegel olema kiireim, kuid teie tulemused võivad erineda. Käivitage järgmised käsud:

 git remote lisada linux-stabiilne //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit tõmmake linux-stabiilne

Otsustage, kas soovite kogu kerneli ühendada või valida kirsse

Järgmisena peate valima, kas soovite ühendada komisjonid või valida kirsipuu. Siin on plussid ja miinused iga ja millal võiksite neid teha.

MÄRKUS. Kui teie kerneli allikas on tarbali kujul, peate tõenäoliselt valima, vastasel juhul saate tuhandeid failikonflikte, kuna git kasutab ajalugu ainult ülesvoolu, mitte aga seda, mida originaalartiklil või CAF-il on muutunud. Lihtsalt liikuge 4. sammu juurde.

Kirsside korjamine:

Plussid:

Konflikte on lihtsam lahendada, kuna teate täpselt, mis konflikti probleemi põhjustab.
Lihtsam on uuesti märata, kuna iga kohustus on omaette.
Lihtsam poolitada, kui teil tekib probleeme

Miinused:

See võtab kauem aega, kuna iga kohustus tuleb eraldi valida.
Pisut keerulisem öelda, kas pühendumus on esmapilgul suunatud ülesvoolu

Ühenda

Plussid :

See on kiirem, kuna te ei pea ootama kõigi puhaste plaastrite ühinemist.
Lihtsam on aru saada, kui kohustus on pärit ülesvoolu, kuna te ei ole toimepanija, vaid ülesvoolu hooldaja.

Miinused:

Konfliktide lahendamine võib olla natuke keerulisem, kuna peate git log / git süüd kasutades otsima, kes toime paneb konflikti, see ei ütle teile otse.
Rebasseerimine on keeruline, kuna te ei saa ühinemist uuesti korraldada, see pakub võimalust kõik kohustused eraldi valida. Kuid te ei tohiks sageli rebaste teha, selle asemel kasutage võimaluse korral git revert ja git merge.

Ma soovitaksin teha kõikvõimalike probleemide konfliktide välja selgitamiseks liitmise, seejärel ühendada ja seejärel probleemi lahendada. Nii on värskendamine lihtsam (kuna liitmine toimub kiiremini pärast ajakohastamist).

Lisage kohustused oma allikale, üks versioon korraga

Selle protsessi kõige olulisem osa on üks versioon korraga. Teie ülesvoolu seerias VÕIB olla probleemiparandus, mis võib põhjustada käivitamisel probleeme või rikkuda midagi, näiteks heli või laadimist (selgitatud näpunäidete jaotistes). Järkjärguliste versioonimuudatuste tegemine on sel põhjusel oluline, 50 siduva ülesande korral on lihtsam probleemi leida, kui mõne versiooni puhul ületab 2000 siduvat siduvat versiooni. Ma soovitaksin täieliku ühendamise teha alles siis, kui olete teadlik kõikidest probleemidest ja konfliktide lahendamistest.

Kirsside korjamine

Vorming:

 mine kirsiks-vali ..

Näide:

git kirsipasta v3.10.73..v3.10.74

Ühenda

Vorming:

 ühendada

Näide:

git merge v3.10.74

Soovitan konfliktide jälgimiseks liitmiskomisjonides eemaldada # markerid.

Kuidas lahendada konflikte

Me ei saa anda üksikasjalikku juhendit iga üksiku konflikti lahendamiseks, kuna see eeldab head C-keele oskust, kuid siin on mõned näpunäited.

Kui liitute, siis mõelge välja, mis toime paneb konflikti. Saate seda teha kahel viisil:

git log -pv $ (make kernelversion) .., et saada muudatused oma praeguse versiooni ja uuema versiooni vahel ülesvoolu. Lipp -p annab teile muudatused, mille on teinud iga pühendunud isik, nii et näete.
Käivitage failis süü, et saada kõigi piirkonnas toime pandud räsi. Seejärel saate käivitada rakenduse git show –format = täielikumaks, et näha, kas toimepanija oli mainline / stabiilne, Google või CodeAurora.

Selgitage välja, kas teil on juba kohustus. Mõned teenusepakkujad, näiteks Google või CAF, püüavad otsida üles kriitilisi vigu, näiteks Dirty COW-i parandus, ja nende tagamaad võivad olla vastuolus eelnevatega. Võite käivitada git log –grep = ”” ja vaadata, kas see tagastab midagi. Kui see juhtub, võite kohustuse vahele jätta (kui kirssikorjamine toimub git reset abil - raske && git cherry-pick - jätkata) või ignoreerida konflikte (eemaldage <<<<< >>>>>).
Selgitage välja, kas on olnud tagapaneeli, mis segab resolutsiooni. Google ja CAF soovivad teatud plaastreid tagasi saata, mis stabiilselt ei toimi. Stabiilne peab sageli kohandama põhijoone eraldusvõimet, jättes teatavad plaastrid tegemata, mida Google valib tagasi. Põhiliinile lubamiseks saate vaadata git show-d (põhiliinirütm on saadaval stabiilse pühendumissõnumi korral). Kui mõni backport seda segab, võite muudatused tühistada või võite kasutada põhiliini versiooni (mida peate tavaliselt tegema).
Lugege, mida pühenduda üritab, ja vaadake, kas probleem on juba lahendatud. Mõnikord võib CAF parandada tõrke ülesvoolust sõltumatult, see tähendab, et võite kas ülesvoolu paranduse üle kirjutada või sellest loobuda, nagu ülalpool.

Vastasel juhul võib see olla lihtsalt CAF / Google / OEM lisamise tulemus ja sel juhul peate lihtsalt mõnda asja ümber segama.

Siin on GitHubi linux-stabiilse kernel.org-hoidla peegel, mida saab hõlpsamalt otsida loenditest ja erinevustest konfliktide lahendamisel. Soovitan kõigepealt minna kohustuste loendi kuvale ja leida probleem, et näha algne erinevus, et seda teie omaga võrrelda.

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

Saate seda teha ka käsurealt:

 git log .. git show

Otsuste lahendamine on seotud kontekstiga. Mida peaksite ALATI tegema, on veenduda, et teie lõplik erinevus vastab ülesvoolu, käivitades kahes eraldi aknas järgmised käsud:

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

Luba uuesti sisenemine

Gitil on funktsioon nimega rerere (tähistab uuesti salvestatud resolutsiooni taaskasutamist), mis tähendab, et kui ta tuvastab konflikti, registreerib see, kuidas te selle lahendasite, et saaksite seda hiljem uuesti kasutada. See on eriti kasulik mõlemale kroonilisele taaskasutajale nii liitmise kui ka kirssikorjamisega, kuna peate lihtsalt git add käivitama. && git - jätkake eelneval toomise uuesti tegemisel, kuna konflikt lahendatakse nii, nagu te varem selle lahendasite.

Seda saab lubada, käivitades kerneli repos järgmise käsu:

 git config rerere.enabled true

Kuidas kompilaatori või käitusvea korral joosta poolitada?

Arvestades, et lisate suure hulga tellimusi, on teil väga võimalik tutvustada kompilaatori või käitusviga. Ainult loobumise asemel saate probleemi algpõhjuse väljaselgitamiseks kasutada giti sisseehitatud poolitusriista! Ideaalis ehitate ja vilgate iga kerneli versiooni, kui lisate selle, nii et poolitamine võtab vajaduse korral vähem aega, kuid saate bisect 5000 korraldada ilma probleemideta.

See, mida te teete, teeb vaid mitme kohustuse võtmise, alates teema hetkest kuni selle puudumiseni, ja siis alustage kohustuste vahemiku vähendamist poole võrra, lubades teil ehitada ja katsetada ning anda teada, kas see on hea või mitte. . Seda jätkatakse seni, kuni see sülitab välja teie probleemi põhjustanud kohustuse. Sel ajal saate selle parandada või tagasi pöörata.

Alusta poolitamist: alusta pooleldi alustamist
Märkige praegune versioon kui halb: jätke pool halvaks
Pange versioon heaks kui hea: poolita hea
Ehitage uue versiooniga
Tulemuse põhjal (kui probleem on olemas või mitte) öelge git: git bisect good VÕi git bisect halb
Loputage ja korrake samme 4-5, kuni probleem on leitud!
Taastage või lahendage probleemi lahendamine.

MÄRKUS. Ühinemised peavad ajutiselt käivitama git rebase -i, et rakendada kõik plaastrid teie harule korralikuks poolitamiseks, kuna poolitatud ühinemiste korral poolitamine toimub sageli korrektselt ülesvoolu, st teil pole ühtegi Androidi konkreetset kohustust. Ma võin selle soovi korral põhjalikumalt uurida, kuid usaldage mind, seda on vaja. Kui olete probleemi kindlaks teinud, saate selle uuesti ühendamiseks ennistada või uuesti luua.

ÄRGE ajage värskendusi üles

Paljudel uutel arendajatel on kiusatus seda teha, kuna seda on “puhtam” ja “kergem” hallata. See on kohutav mitmel põhjusel:

Autoriõigus on kadunud. Teiste arendajate suhtes on ebaõiglane, kui nende töö eest nõutakse krediiti.
Poolitamine on võimatu. Kui pritsite välja mitu siduvat sarja ja miski on selle seeria teema, pole võimatu öelda, mis sunnib prügi välja andma.
Tulevased kirsipurgad on raskemad. Kui teil on vaja uuesti kokku kiskuda sarjaga, on keeruline / võimatu öelda, kust konflikt tuleneb.

Telli õigeaegsete värskenduste saamiseks Linuxi kerneli meililisti

Uuendusvärskenduse olemasolul teate saamiseks tellige linux-kernel-kuulutuste loend. See võimaldab teil saada iga kerneli vabastamise korral e-kirja, nii et saate värskendada ja lükata nii kiiresti kui võimalik.