Paano i-update ang iyong Android Kernel sa Pinakabagong Linux Stable

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

Ang pinaka-gumugol ng oras na bahagi ay ang paunang ilabas; sa sandaling napapanahon ka, hindi tumatagal ng anumang oras upang pagsamahin sa isang bagong paglabas, na karaniwang naglalaman ng hindi hihigit sa 100 mga komit. Ang mga benepisyo na dala nito (higit na katatagan at mas mahusay na seguridad para sa iyong mga gumagamit) ay dapat na kailanganin ang prosesong ito.

Paano pagsamahin ang Linux Stable Kernel sa isang Android Kernel

Una kailangan mong malaman kung anong bersyon ng kernel na tumatakbo ang iyong Android device.

Tulad ng walang gaanong hitsura nito, kinakailangang malaman kung saan mo kailangang magsimula. Patakbuhin ang sumusunod na utos sa iyong puno ng kernel:

gumawa ng kernelversion

Ibabalik nito ang bersyon kung nasaan ka. Ang unang dalawang numero ay gagamitin upang malaman ang sangay na kailangan mo (hal. Linux-4.4.y para sa anumang 4.4 kernel) at ang huling numero ay gagamitin upang matukoy kung anong bersyon ang kailangan mong simulan sa pagsasama (hal. Kung nasa 4.4 ka .21, pagsamahin mo ang 4.4.22 sa susunod).

Grab ang pinakabagong mapagkukunan ng kernel mula sa kernel.org

kernel.org bahay ang pinakabagong mapagkukunan ng kernel sa ang linux-stable na imbakan . Sa ilalim ng pahinang iyon, magkakaroon ng tatlong mga link na makuha. Sa aking karanasan, ang salamin ng Google ay may kaugaliang pinakamabilis ngunit ang iyong mga resulta ay maaaring magkakaiba. Patakbuhin ang mga sumusunod na utos:

git remote idagdag ang linux-stable https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit kunin ang linux-stable

Magpasya kung nais mong pagsamahin ang buong kernel o cherry-pick ang mga gumawa

Susunod, kakailanganin mong pumili kung nais mong pagsamahin ang mga commits o cherry-pick. Narito ang mga kalamangan at kahinaan ng bawat isa at kung kailan mo nais na gawin ang mga ito.

TANDAAN: Kung ang mapagkukunan ng iyong kernel ay nasa anyo ng isang tarball, malamang na kailangan mong pumili ng cherry, kung hindi man makakakuha ka ng libu-libong mga pagtatalo ng file dahil ang git ay pinupuno ang kasaysayan batay lamang sa upstream, hindi kung ano ang binago ng OEM o CAF. Laktawan lang sa hakbang 4.

Pagpipili ng cherry:

Mga kalamangan:

• Mas madaling malutas ang mga salungatan na alam mo nang eksakto kung ano ang salungatan na nagdudulot ng isang isyu.
• Mas madaling i-rebase ang bawat komit ay nasa sarili.
• Mas madaling bisect kung tumatakbo sa mga isyu

Kahinaan:

• Ito ay tumatagal ng mas matagal bilang bawat isa ay dapat na indibidwal na pumili.
• Medyo mas mahirap sabihin kung ang pagpayag ay mula sa upstream sa unang tingin

Punta ka na

Mga kalamangan :

• Mas mabilis ito dahil hindi mo kailangang maghintay para sa lahat ng malinis na mga patch na sumanib.
• Mas madaling makita kung ang isang nakatuon ay mula sa upstream dahil hindi ka magiging tagabawas, ang tagapanatili ng upstream ay magiging.

Kahinaan:

• Ang paglutas ng mga salungatan ay maaaring maging medyo mahirap dahil kakailanganin mong hanapin kung aling gumawa ang nagdudulot ng hidwaan sa paggamit ng git log / git sisihin, hindi ito direktang sasabihin sa iyo.
• Mahirap ang rebasing dahil hindi mo maaaring bawiin ang isang pagsasama, mag-aalok ito upang i-cherry-pick ang lahat ng pangako nang paisa-isa. Gayunpaman, hindi ka dapat muling nagre-rebuse ng madalas, sa halip ay gumagamit ng git revert at git merge kung posible.

Inirerekumenda ko ang paggawa ng isang cherry-pick upang malaman ang anumang mga salungatan sa problema sa una, paggawa ng isang pagsasama, pagkatapos ay ibalik ang problema ay gumawa pagkatapos pagkatapos ay mas madali ang pag-update (dahil ang pagsasama ay mas mabilis matapos na napapanahon).

Idagdag ang mga commits sa iyong mapagkukunan, isang bersyon nang paisa-isa

Ang pinakamahalagang bahagi ng prosesong ito ay ang isang bersyon nang paisa-isang bahagi. Maaaring MAY isang problema sa patch sa iyong upstream series, na maaaring maging sanhi ng isang problema sa pag-boot o masira ang isang bagay tulad ng tunog o singilin (ipinaliwanag sa seksyon ng mga tip at trick). Ang paggawa ng mga karagdagang pagbabago sa bersyon ay mahalaga para sa kadahilanang ito, mas madaling makahanap ng isang isyu sa 50 mga komit kaysa sa paitaas ng 2000 na mga paggawa para sa ilang mga bersyon. Inirerekumenda ko lamang ang paggawa ng isang buong pagsasama-sama sa oras na malalaman mo ang lahat ng mga problema na gumawa at mga resolusyon sa tunggalian.

Cherry-picking

Format:

git cherry-pick ..

Halimbawa:

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

Punta ka na

Format:

pumunta sumanib

Halimbawa:

pinagsama ang v3.10.74

Inirerekumenda kong subaybayan ang mga salungatan sa mga pagsasanib na komit sa pamamagitan ng pag-aalis ng mga # marker.

Paano Malutas ang Mga Salungatan

Hindi kami maaaring magbigay ng isang sunud-sunod na gabay para sa paglutas ng bawat solong hidwaan, dahil nagsasangkot ito ng isang mahusay na kaalaman sa wikang C, ngunit narito ang ilang mga pahiwatig.

Kung pinagsasama mo, alamin kung ano ang gumawa na nagdudulot ng hidwaan. Maaari mong gawin ito sa isa sa dalawang paraan:

1. git log -p v $ (gumawa ng kernelversion) .. upang makuha ang mga pagbabago sa pagitan ng iyong kasalukuyang bersyon at ang pinakabagong mula sa upstream. Ang flag na -p ay magbibigay sa iyo ng mga pagbabagong nagawa ng bawat gumawa upang makita mo.
2. Patakbuhin ang git sisihin sa file upang makuha ang mga hash ng bawat gumawa sa lugar. Maaari mo nang patakbuhin ang git show –format = mas buong upang makita kung ang committer ay mula sa mainline / stable, Google, o CodeAurora.

• Alamin kung mayroon ka nang pangako. Ang ilang mga vendor tulad ng Google o CAF ay susubukan na tumingin sa upstream para sa mga kritikal na bug, tulad ng pag-aayos ng Dirty COW, at ang kanilang mga backport ay maaaring sumasalungat sa upstream's. Maaari kang magpatakbo ng git log –grep = ”” at tingnan kung may ibabalik ito. Kung nagagawa ito, maaari mong laktawan ang nakatuon (kung ang pagpili ng seresa gamit ang git reset –hard && git cherry-pick –continue) o huwag pansinin ang mga salungatan (alisin ang<<<<<>>>>>).
• Alamin kung mayroong isang backport na nakakagulo sa resolusyon. Gustong i-backport ng Google at CAF ang ilang mga patch na hindi nais ng stable. Kadalasang kailangan ng stable na iakma ang resolusyon ng mainline na gumawa sa kawalan ng ilang mga patch na pinipili ng Google na i-backport. Maaari kang tumingin sa mainline na gumawa sa pamamagitan ng pagpapatakbo ng git show (ang mainline hash ay magagamit sa mensahe ng gumawa ng matatag na pangako). Kung mayroong isang backport na ginulo, maaari mong itapon ang mga pagbabago o maaari mong gamitin ang pangunahing bersyon (na kung saan ay karaniwang kailangan mong gawin).
• Basahin kung ano ang sinusubukan na gawin at alamin kung ang problema ay naayos na. Minsan maaaring mag-ayos ang CAF ng isang bug na independyente sa upstream, nangangahulugang maaari mong mai-overlap ang kanilang pag-aayos para sa upstream’s o itapon ito, tulad ng nasa itaas.

Kung hindi man, maaaring ito ay isang resulta lamang ng isang karagdagan sa CAF / Google / OEM, kung saan kailangan mo lang i-shuffle ang ilang mga bagay sa paligid.

Narito isang salamin ng linux-stable kernel.org repository sa GitHub, na maaaring mas madali para sa pagtingin sa mga listahan ng gumawa at naiiba para sa paglutas ng kontrahan. Inirerekumenda ko ang pagpunta muna sa view ng listahan ng gumawa at hanapin ang problemang gumawa upang makita ang orihinal na diff upang ihambing ito sa iyo.

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

Maaari mo ring gawin ito sa pamamagitan ng linya ng utos:

git log .. git show

Ang paglutas ng mga resolusyon ay tungkol sa konteksto. Ang dapat mong palaging gawin ay tiyakin na ang iyong huling diff ay tumutugma sa upstream's sa pamamagitan ng pagpapatakbo ng mga sumusunod na utos sa dalawang magkakahiwalay na windows:

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

Paganahin ang rerere

Ang Git ay may tampok na tinatawag na rerere (ibig sabihin sa Reuse Recorded Resolution), nangangahulugang kapag nakakita ito ng isang salungatan, itatala nito kung paano mo ito nalutas upang maaari mo itong magamit muli sa paglaon. Lalo na nakakatulong ito para sa parehong talamak na mga rebaser na may parehong pagsasama at pagpili ng seresa dahil kakailanganin mo lamang na patakbuhin ang git add. && git –pagpatuloy kapag ginawang muli ang daloy ng agos dahil malulutas ang salungatan kung paano mo ito nalutas.

Maaari itong mapagana sa pamamagitan ng pagpapatakbo ng sumusunod na utos sa iyong kernel repo:

git config rerere.enified true

Paano mag-git bisect kapag tumatakbo sa isang tagatala o error sa runtime

Dahil na magdaragdag ka ng isang napakaraming mga commit, posible na magpakilala ka ng isang compiler o error sa runtime. Sa halip na sumuko lamang, maaari mong gamitin ang built-in na tool ng bisect ng git upang malaman ang pangunahing sanhi ng isyu! Sa isip, bubuo at mai-flashing mo ang bawat solong bersyon ng kernel habang idinagdag mo ito kaya't ang pagba-bisite ay kukuha ng mas kaunting oras kung kinakailangan ngunit maaari mong bisahin ang 5000 na gumawa nang walang anumang mga isyu.

Ang gagawin ng git bisect ay kumuha ng isang saklaw ng mga commits, mula sa kung saan ang isyu ay naroroon hanggang sa kung saan wala ito, at pagkatapos ay simulang ihati ang saklaw ng gumawa, pinapayagan kang bumuo at subukan at ipaalam ito kung ito ay mabuti o hindi . Ipagpapatuloy nito ito hanggang sa mailabas nito ang pangako na sanhi ng iyong isyu. Sa puntong iyon, maaari mong ayusin ito o ibalik ito.

1. Simulang bisecting: magsimula ang git bisect
2. Lagyan ng label ang kasalukuyang rebisyon bilang hindi maganda: git bisect bad
3. Lagyan ng marka ang isang rebisyon bilang mabuti: mabuti ang git bisect
4. Bumuo gamit ang bagong rebisyon
5. Batay sa resulta (kung ang isyu ay naroroon o wala), sabihin sa git: git bisect mabuti O git bisect hindi maganda
6. Banlawan at ulitin ang mga hakbang na 4-5 hanggang sa matagpuan ang problema!
7. Balikan o ayusin ang problemang nagawa.

TANDAAN: Kailangang pansamantalang patakbuhin ng mga mergers ang git rebase -i upang mailapat ang lahat ng mga patch sa iyong sangay para sa wastong pag-bisect, dahil ang pag-bisect sa mga pagsasama sa lugar ay madalas na mag-checkout papunta sa upstream commits, nangangahulugang wala kang isa sa mga tukoy na commits ng Android. Maaari akong mapunta sa mas malalim na ito kapag hiniling ngunit magtiwala ka sa akin, kinakailangan ito. Kapag natukoy mo na ang nagawa ng problema, maaari mo itong ibalik o ibalik sa pagsasama.

HUWAG i-squash ang mga upstream update

Maraming mga bagong developer ang natutuksong gawin ito sapagkat ito ay 'mas malinis' at 'mas madaling' pamahalaan. Ito ay kakila-kilabot para sa ilang mga kadahilanan:

• Nawala ang akda. Hindi makatarungan sa iba pang mga developer na itigil ang kanilang kredito para sa kanilang trabaho.
• Imposible ang bisecting. Kung kalabasa mo ang isang serye ng mga pangako at ang isang bagay ay isang isyu sa seryeng iyon, imposibleng sabihin kung ano ang nagdulot ng isang isyu sa isang kalabasa.
• Ang mga hinaharap na cherry-pick ay mas mahirap. Kung kailangan mong muling mag-rebate gamit ang isang squash series, mahirap / imposibleng sabihin kung saan nagmumula ang isang salungatan.

Mag-subscribe sa Linux Kernel mailing list para sa napapanahong pag-update

Upang ma-notify tuwing mayroong isang upstream na pag-update, mag-subscribe sa ang listahan ng linux-kernel-announce . Papayagan ka nitong makakuha ng isang email sa tuwing magpapalabas ng isang bagong kernel upang maaari mong i-update at itulak nang mabilis hangga't maaari.