Kuidas värskendada oma Android-tuuma uusimale stabiilsele Linuxile

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

Kõige aeganõudvam osa on esmane esiletoomine; kui olete kogu aeg kursis, ei võta uue versiooni ühendamine üldse aega, mis tavaliselt sisaldab kuni 100 toimingut. Eelised, mida see toob (rohkem stabiilsust ja paremat turvalisust teie kasutajatele), peaksid selle protsessi siiski tingima.

Kuidas ühendada Linuxi stabiilne tuum Android-tuumaks

Kõigepealt peate välja selgitama, millist tuuma versiooni teie Android-seade töötab.

Nii triviaalsena kui see tundub, on vaja teada, kust peate alustama. Käivitage oma tuumapuus järgmine käsk:

teha kernelversion

See tagastab teie versiooni. Kahte esimest numbrit kasutatakse vajaliku haru selgitamiseks (nt iga Linuxi tuuma puhul Linux-4.4.y) ja viimast numbrit kasutatakse selle määramiseks, millist versiooni peate liitmisega alustama (nt kui kasutate 4.4 .21, järgmisena ühendate 4.4.22).

Haara uusim kerneli allikas saidilt kernel.org

kernel.org majas on uusim tuumaallikas linux-stabiilne hoidla . Selle lehe allosas on kolm tõmbelinki. Minu kogemuste kohaselt kipub Google'i peegel olema kõige kiirem, kuid teie tulemused võivad erineda. Käivitage järgmised käsud:

giti kaugjuhtimispult lisage linux-stabiilne https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit tõmmake linux-stabiilne

Otsustage, kas soovite liita kogu kernel või valida toimingud kirssidega

Järgmisena peate valima, kas soovite ühendada toimingud või kirss. Siin on igaühe plussid ja miinused ning millal võiksite neid teha.

MÄRGE: Kui teie kerneli allikas on tarballi vormis, peate tõenäoliselt valima kirsside, vastasel juhul saate tuhandeid failikonflikte, kuna git täidab ajalugu puhtalt ülesvoolu, mitte selle järgi, mida OEM või CAF on muutnud. Lihtsalt minge 4. sammu juurde.

Kirsside korjamine:

Plussid:

• Konflikte on lihtsam lahendada, kuna teate täpselt, milline konflikt probleemi põhjustab.
• Lihtsam on uuesti teha, kuna iga pühendumine on omaette.
• Probleemide korral on lihtsam poolitada

Miinused:

• See võtab kauem aega, kuna iga kohustus tuleb valida eraldi.
• Veidi raskem on öelda, kas pühendumine on esmapilgul ülesvoolu

Mine

Plussid :

• See on kiirem, kuna te ei pea ootama kõigi puhaste plaastrite ühendamist.
• Lihtsam on näha, kui kohustus on pärit ülesvoolust, kuna te ei ole kohustuse täitja, seda on eelvoolu hooldaja.

Miinused:

• Konfliktide lahendamine võib olla veidi keerulisem, kuna peate git log / git süüdistuste abil üles otsima, milline toime põhjustab konflikti, see ei ütle teile otseselt.
• Uuesti alustamine on keeruline, kuna te ei saa ühendamist taaskäivitada, see pakub kõigi kohustuste individuaalset valimist. Kuid te ei tohiks sageli uuesti bassida, selle asemel kasutage git revert'i ja git sulamist, kui see on võimalik.

Soovitaksin kõigepealt leida probleemide konfliktide selgitamiseks kirsside valiku, teha liitmine ja seejärel probleem uuesti sooritada, nii et värskendamine on lihtsam (kuna ühendamine on pärast ajakohastamist kiirem).

Lisage toimingud allikale üks versioon korraga

Selle protsessi kõige olulisem osa on üks versioon korraga. Teie ülesvoolu seerias võib VÕI olla probleemipaik, mis võib põhjustada probleemi käivitamisel või rikkuda midagi sellist nagu heli või laadimine (selgitatud näpunäidete ja nõuannete osas). Versiooni järkjärguliste muudatuste tegemine on sel põhjusel oluline, mõne versiooni puhul on probleemi lihtsam leida 50 kulukohustuses kui 2000-st suuremast. Ma soovitaksin täieliku ühendamise teha alles siis, kui teate kõiki probleemi toiminguid ja konfliktide lahendamist.

Kirsside korjamine

Vorming:

git kirsipuu ..

Näide:

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

Mine

Vorming:

mine liituma

Näide:

git merge v3.10.74

Soovitan jälgida liitumiskohustuste konflikte, eemaldades # markerid.

Kuidas konflikte lahendada

Me ei saa anda samm-sammult juhiseid iga üksiku konflikti lahendamiseks, kuna see hõlmab head C-keele oskust, kuid siin on mõned näpunäited.

Kui liitute, siis mõelge välja, mis pühendumine konflikti põhjustab. Saate seda teha kahel viisil.

1. git log -p v $ (tee kernelversion) .. et saada muudatusi oma praeguse versiooni ja uusima vahel ülesvoolu. Lipp -p annab teile muudatused, mille iga pühendumine on teinud, nii et näete.
2. Käivitage failil git blame, et saada piirkonnas toimuvate iga räsimise räsimine. Seejärel saate käivitada git show –format = fuller, et näha, kas tellija oli põhiliinist / stabiilsest, Google'ist või CodeAurorast.

• Mõelge välja, kas teil on kohustus juba olemas. Mõned teenusepakkujad, nagu Google või CAF, üritavad otsida ülesvoolu kriitilisi vigu, näiteks Dirty COW-i parandus, ja nende backports võib olla vastuolus ülesvoolu. Võite käivitada git log –grep = ”” ja vaadata, kas see tagastab midagi. Kui see nii on, võite kohustuse vahele jätta (kui kirsside korjamine jätkab git reset –hard && git cherry-pick –jätkamist) või ignoreerib konflikte (eemaldage<<<<<>>>>>).
• Mõelge välja, kas on olnud taustapordi, mis segab eraldusvõimet. Google ja CAF soovivad toetada teatud plaastreid, mis stabiilselt mitte. Stabiilne peab sageli kohandama põhiliini eraldusvõimet teatud plaastrite puudumisele, mille Google valib tagasiühenduseks. Saate vaadata pealiini pühendumist, käivitades git show (pealiini räsi on saadaval stabiilse pühenduse pühendamise sõnumis). Kui mõni backport seda segamini ajab, võite muudatused kõrvale jätta või kasutada põhiliini versiooni (mida peate tavaliselt tegema).
• Loe, mida pühendunud üritab teha, ja vaata, kas probleem on juba lahendatud. Mõnikord võib CAF parandada vea, mis on ülesvoolust sõltumatu, see tähendab, et võite nende ülevoolu paranduse üle kirjutada või selle nagu eespool kirjeldatud, kõrvale jätta.

Vastasel juhul võib see olla lihtsalt CAF / Google / OEM lisamise tulemus, sellisel juhul peate lihtsalt mõned asjad ümber segama.

Siin on linux-stabiilse kernel.org hoidla peegel GitHubis, mis võib hõlbustada konfliktide lahendamiseks toimingute loendite ja diffide otsimist. Soovitan kõigepealt minna pühenduste loendi vaatesse ja leida ülesande probleem, et näha algset diffi, et seda teie omaga võrrelda.

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

Saate seda teha ka käsurea kaudu:

git log .. git show

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

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

Rerereerimise lubamine

Gitil on funktsioon nimega rerere (tähistab registreeritud eraldusvõime taaskasutust), mis tähendab, et kui ta tuvastab konflikti, salvestab see teie lahenduse, et saaksite seda hiljem uuesti kasutada. See on eriti kasulik nii krooniliste rebaserite jaoks nii ühendamise kui ka kirsikorjamisega, kuna peate lihtsalt käivitama git add. && git - jätkake eelvoolu esiletõstmise uuesti tegemisel, kuna konflikt lahendatakse nii, nagu te selle varem lahendasite.

Seda saab lubada, käivitades oma kernorepos järgmise käsu:

git config rerere.enabled tõene

Kuidas kompilaatorisse või runtime'i tõrke korral poolitada?

Arvestades, et lisate suures koguses toiminguid, on teil väga võimalik tutvustada kompilaatori või käituse viga. Alles loobumise asemel võite probleemi algpõhjuse väljaselgitamiseks kasutada giti sisseehitatud kahepoolse tööriista! Ideaalis ehitate ja vilgutate iga üksiku kerneli versiooni lisamise ajal, nii et poolitamine võtab vajadusel vähem aega, kuid saate 5000 toimingut poolitada probleemideta.

Mida git bisect teeb, on teha mitmeid kohustusi, alates probleemi esinemisest kuni kohani, kus seda ei olnud, ja seejärel hakata poolitama pühendamisvahemikku, võimaldades teil ehitada ja testida ning anda teada, kas see on hea või mitte . Ta jätkab seda seni, kuni sülitab teie probleemi põhjustanud kohustuse. Sel hetkel saate selle kas parandada või tagasi pöörduda.

1. Alustage poolitamist: alustage kahepoolset alustamist
2. Märgistage praegune redaktsioon halvaks: git bisect bad
3. Märgistage redaktsioon heaks: git bisect good
4. Ehitage uue redaktsiooniga
5. Tulemuse põhjal (kui probleem on olemas või mitte) öelge git: git bisect good OR git bisect bad
6. Loputage ja korrake samme 4-5, kuni probleem on leitud!
7. Probleemi ennistamine või lahendamine.

MÄRGE: Ühinemised peavad ajutiselt käivitama git rebase -i, et kõik plaastrid teie filiaalile õigeks poolitamiseks paigaldada, kuna poolitatud ühinemiste korral poolitamine kordab sageli sissemakseid ülesvoolu, mis tähendab, et teil pole ühtegi Androidi konkreetset kohustust. Soovi korral võin seda põhjalikumalt uurida, kuid usaldage mind, seda on vaja. Kui olete probleemi tuvastanud, saate selle uuesti ühendada või selle uuesti ühendada.

ÄRGE koondage ülesvoolu värskendusi

Paljudel uutel arendajatel on kiusatus seda teha, kuna seda on 'puhtam' ja 'lihtsam' hallata. See on kohutav mõnel põhjusel:

• Autorsus on kadunud. Teiste arendajate suhtes on ebaõiglane, kui nende töö eest krediiti vähendatakse.
• Poolitamine on võimatu. Kui teete kokku mitmete kohustuste seeria ja midagi on selles seerias probleemiks, siis on võimatu öelda, mis toime pani probleemi squashis.
• Tulevased kirsimarjad on raskemad. Kui teil on vaja uuesti kokku panna kokkutõmmatud seeriaga, on raske / võimatu öelda, kust konflikt tuleneb.

Telli õigeaegse värskenduse saamiseks Linuxi kerneli meililist

Kui soovite saada teateid alati, kui toimub varasem värskendus, tellige nimekiri linux-kernel-Announce . See võimaldab teil saada e-kiri iga kord, kui uus kernel vabastatakse, nii et saate värskendada ja edastada nii kiiresti kui võimalik.