Az Android kernel frissítése a legújabb stabil Linux rendszerre

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

A legidőigényesebb rész a kezdeti felhozatal; ha naprakész vagy, egyáltalán nem kell idő egyesülni egy új kiadásban, amely általában legfeljebb 100 elkötelezettséget tartalmaz. Ennek előnyei (nagyobb stabilitás és jobb biztonság a felhasználók számára) szükségessé teszik ezt a folyamatot.

Hogyan lehet egyesíteni a Linux stabil kernelt egy Android kernellé

Először ki kell derítenie, hogy az Android készüléke melyik kernverzióval fut.

Bármennyire is triviálisnak tűnik, tudnunk kell, hogy hol kell kezdeni. Futtassa a következő parancsot a kernefában:

kernelversion

Visszaadja az Ön által használt verziót. Az első két szám segítségével megtudhatjuk a szükséges ágat (pl. Linux-4.4.y bármely 4.4 kernel esetében), az utolsó számot pedig annak meghatározására használjuk, hogy melyik verziót kell elindítanod az egyesítéssel (pl. Ha 4.4-es verziót használsz) .21, majd egyesül a 4.4.22.)

Fogja meg a kernel.org legfrissebb kernelforrását

kernel.org ház a legújabb kernelforrás a linux-stabil adattár . Az oldal alján három lekérési link lesz. Tapasztalataim szerint a Google tükre általában a leggyorsabb, de az eredményei eltérhetnek. Futtassa a következő parancsokat:

git remote add linux-stabil https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit linux-stabil lekérése

Döntse el, hogy össze kívánja-e vonni a teljes kernelt, vagy cseresznyével válassza ki a végrehajtásokat

Ezután meg kell választania, hogy egyesíteni kívánja-e az elkövetéseket vagy a cseresznyeválasztást. Itt vannak előnyei és hátrányai mindegyiknek, és mikor érdemes megtenni őket.

JEGYZET: Ha a rendszermag forrása egy tarball formátumú, akkor valószínűleg meg kell válogatnia, különben több ezer fájlkonfliktusot fog kapni, mert a git az előzményeket pusztán az upstream alapján tölti be, nem pedig az OEM vagy a CAF változását. Csak ugorjon a 4. lépésre.

Kimazsolázzák:

Előnyök:

• Könnyebb megoldani a konfliktusokat, mivel pontosan tudja, hogy mely konfliktus okozza a problémát.
• Könnyebb újrabázolni, mivel minden elkötelezettség önmagában van.
• Könnyebb kettéosztani, ha problémák merülnek fel

Hátrányok:

• Ez hosszabb időt vesz igénybe, mivel minden egyes elkötelezettséget külön kell kiválasztani.
• Kicsit nehezebb megmondani, hogy az elkötelezettség első ránézésre az áramlási iránytól származik-e

Megy

Előnyök :

• Gyorsabb, mivel nem kell megvárni az összes tiszta folt összeolvadását.
• Könnyebben belátható, ha egy elkötelezettség a felsőbb szintről származik, mivel nem te leszel az elkövető, hanem az upstream fenntartó.

Hátrányok:

• A konfliktusok megoldása kissé bonyolultabb lehet, mivel a git log / git blame használatával meg kell vizsgálnia, hogy melyik elkövető okozza a konfliktust, ez közvetlenül nem fogja megmondani.
• Az újbóli futtatás nehéz, mivel nem lehet újraalapozni az egyesítést, felajánlja, hogy az összes elkötelezettet külön-külön válogatja össze. Nem szabad azonban gyakran újrabázolni, ehelyett a git revert és a git merge lehetőségeket használja.

Azt javaslom, hogy végezzen el egy cseresznyeválasztást, hogy kezdetben kiderítse a problémás konfliktusokat, végezzen egyesítést, majd állítsa vissza a problémát, hogy utána visszavonja a problémát, így a frissítés könnyebb (mivel az egyesítés gyorsabb, miután naprakész volt).

Adja hozzá a kötelezettségvállalásokat a forráshoz, egy-egy verzióval

Ennek a folyamatnak a legfontosabb része az egy-egy verzió. Előfordulhat, hogy problémás javítás van az upstream sorozatában, ami problémát okozhat az indítással, vagy megszakíthat valamit, például a hangot vagy a töltést (elmagyarázza a tippek és trükkök részben). Emiatt fontos a növekményes verzióváltoztatások végrehajtása, könnyebb megtalálni a problémát 50 változtatásban, mint egyes verzióknál 2000-től feljebb. Csak akkor ajánlom a teljes egyesítést, ha ismeri az összes problémát és konfliktusmegoldást.

Kimazsolázzák

Formátum:

git cherry-pick ..

Példa:

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

Megy

Formátum:

menj össze

Példa:

git merge v3.10.74

Azt javaslom, hogy a # jelölők eltávolításával kövesse nyomon az összefésülési műveletek ütközéseit.

Hogyan lehet megoldani a konfliktusokat

Nem adhatunk lépésről lépésre útmutatást minden egyes konfliktus megoldásához, mivel ez a C nyelv jó ismeretét vonja maga után, de íme néhány tipp.

Ha összeolvad, derítse ki, hogy mi az elkövetés okozza a konfliktust. Ezt kétféleképpen teheti meg:

1. git log -p v $ (kernelversion készítése) .. hogy az aktuális és a legújabb verzió közötti változásokat az upstream-től kapja. A -p flag megadja az egyes elkötelezettek által végrehajtott módosításokat, így láthatja.
2. Futtassa a git blame fájlt, hogy megkapja a terület minden egyes elkötelezettségének hash-ját. Ezután futtathatja a git show –format = fuller elemet, hogy lássa, a fővonali / stabil, a Google vagy a CodeAurora származik-e.

• Kitalálja, hogy megvan-e már az elkötelezettség. Egyes szállítók, mint például a Google vagy a CAF, megpróbálják felkeresni a kritikus hibákat, például a Dirty COW javítást, és hátlapjaik ütközhetnek az upstream szolgáltatásokkal. Futtathatja a git log –grep = ”” logot, és megnézheti, hogy ad-e vissza valamit. Ha mégis megtörténik, akkor kihagyhatja az elkötelezettséget (ha a cseresznyeválogatás a git reset használatával –hard && git cherry-pick –folytatja), vagy figyelmen kívül hagyhatja az ütközéseket (eltávolíthatja a<<<<<>>>>>).
• Kitalálja, van-e olyan háttérport, amely elrontja a felbontást. A Google és a CAF szívesen támogat bizonyos javításokat, amelyek nem stabilak. A Stable-nek gyakran ki kell igazítania a fővonal elkötelezettségének felbontását bizonyos olyan javítások hiányához, amelyeknek a Google a backport mellett dönt. Megtekintheti a fővonal elkötelezettségét a git show futtatásával (a fővonal kivonata elérhető lesz a stabil elkötelezettség üzenetében). Ha van egy backport, amely elrontja, akkor elvetheti a módosításokat, vagy használhatja a mainline verziót (amit általában meg kell tennie).
• Olvassa el, hogy az elkövető mit próbál csinálni, és nézze meg, hogy a probléma már megoldódott-e. Néha a CAF kijavíthatja az upstreamtől független hibát, vagyis felülírhatja a javítást az upstream számára, vagy elvetheti, mint fent.

Ellenkező esetben ez csak a CAF / Google / OEM hozzáadásának eredménye lehet, ebben az esetben csak néhány dolgot kell összekevernie.

Itt van a linux-stabil kernel.org adattár tükre a GitHubon, amely könnyebben megkeresheti az elkötelezettségi listákat és diff-eket a konfliktusok megoldásához. Javaslom, hogy először lépjen az elkötelezettség nézetre, és keresse meg a probléma elkötelezettségét, hogy lássa az eredeti diff-et, hogy összehasonlítsa azt a sajátjával.

Példa URL-re: https://github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

Megteheti a parancssoron keresztül is:

git log .. git show

A felbontások megoldása a kontextusról szól. MINDIG azt kell tennie, hogy a következő parancsokat két külön ablakban futtatva győződjön meg arról, hogy a végső különbség megfelel-e az upstream-nek:

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

Engedélyezze az újraírást

A Git rendelkezik a rerere nevű funkcióval (a rögzített felbontás újrafelhasználása), ami azt jelenti, hogy amikor konfliktust észlel, rögzíti, hogyan oldotta meg, hogy később újra felhasználhassa. Ez különösen hasznos mind a krónikus rebaserek számára, mind az összevonással, mind a cseresznye szedéssel, mivel csak a git add futtatására van szükség. && git –folytassa az upstream előhívás átdolgozásakor, mivel a konfliktus megoldódik, ahogyan korábban megoldotta.

Engedélyezhető a következő parancs futtatásával a rendszermag-repóban:

git config rerere.enabled igaz

Hogyan lehet kettévágni fordító vagy futásidejű hiba esetén

Tekintettel arra, hogy jelentős számú elkötelezettséget fog hozzáadni, nagyon lehetséges, hogy fordító- vagy futásidejű hibát vezet be. Ahelyett, hogy feladnád, használhatod a git beépített bisect eszközét, hogy kiderítsd a probléma kiváltó okát! Ideális esetben minden egyes kernelváltozatot ki fog építeni és villogni, ahogy hozzáadja, így a felezés szükség esetén kevesebb időt vesz igénybe, de az 5000 elkötelezettséget fel lehet gondozni ketté.

Amit a git bisect tesz, az az, hogy egy sor elkötelezettséget vállal, ahonnan a probléma fennáll, és ott, ahol nem volt jelen, majd kezdje el megfelezni az elkötelezettségi tartományt, lehetővé téve számodra, hogy felépítsd és tesztelhesd, és tudasd vele, hogy ez jó-e vagy sem. . Addig folytatja ezt, amíg ki nem köpi a problémát okozó elkötelezettséget. Ezen a ponton vagy kijavíthatja, vagy visszavonhatja.

1. Indítsa el a kettéosztást: git bisect start
2. Címkézze az aktuális verziót rossznak: git bisect bad
3. Jelölje meg a revíziót jónak: git bisect good
4. Építsen az új verzióval
5. Az eredmény alapján (ha a probléma fennáll vagy sem) mondja el a gitnek: git bisect good OR git bisect bad
6. Öblítse le és ismételje meg a 4-5. Lépést, amíg a probléma elkövetése megtalálható!
7. Visszaállíthatja vagy kijavíthatja a problémát.

JEGYZET: Az összeolvadásoknak ideiglenesen futtatniuk kell a git rebase -i alkalmazást, hogy az összes javítást az ágadra illesszék a megfelelő felezés érdekében, mivel a kettéhúzás a meglévő összeolvadásokkal gyakran időnként fizetni fog az upstream kötelezettségvállalásoknál, ami azt jelenti, hogy egyik Android-specifikus kötelezettségvállalásod sincs. Kérésre részletesebben elmélyülhetek ebben, de bízz bennem, szükség van rá. Miután azonosította a probléma elkövetését, visszaállíthatja vagy újraalapozhatja az egyesítésbe.

NE tömörítse az upstream frissítéseket

Sok új fejlesztő kísértést érez erre, mivel „tisztább” és „könnyebb” kezelni. Ez néhány okból rettenetes:

• A szerzőség elveszett. Tisztességtelen más fejlesztőkkel szemben, hogy a munkájukért megkapják a hitelt.
• A kettéválasztás lehetetlen. Ha elkötelez egy sor elkötelezettséget, és valami kérdéses abban a sorozatban, akkor lehetetlen megmondani, hogy mely elkövetés okozott problémát egy tökben.
• A jövő cseresznye-válogatása nehezebb. Ha újrabázolni kell egy összecsapott sorozattal, nehéz / lehetetlen megmondani, honnan ered egy konfliktus.

Feliratkozás a Linux kernel levelezőlistájára az időszerű frissítésekért

Ha értesítést szeretne kapni, amikor egy upstream frissítésről van szó, iratkozzon fel a következőre: a linux-kernel-announce listát . Ez lehetővé teszi, hogy e-mailt kapjon minden alkalommal, amikor egy új kernel kiadásra kerül, így a lehető leggyorsabban frissítheti és tolhatja.