Hogyan lehet frissíteni az Android rendszermagját a legújabb Linux stabil rendszerre

Fedeztünk fel útmutatókat az Android rendszermagjairól, például a „Hogyan hozzunk létre egyéni kernelt” és a „Legjobb egyedi rendszermagok Androidra”, de ma megmutatjuk, hogyan lehet a kernelt felfelé fordítani a legújabb Linux stabil ellen.

Kérjük, vegye figyelembe, hogy ez fejlett dolgok - ha még soha nem állított össze egy kernelt, akkor kövesse a fent hivatkozott “Hogyan készítsünk egy egyedi kernelt” útmutatót, és ez az útmutató magában foglalja a cseresznye kiválasztását és a legújabb Linuxra vonatkozó kötelezettségvállalások egyesítését - stabil kernel az Android rendszermaggal, mielőtt lefordítja.

Az Android kernel legfrissebb Linux stabiljába történő felépítése sok pozitív előnnyel jár, például az, hogy naprakész a legújabb biztonsági elkötelezettségekkel és a hibajavításokkal - néhány előnyeiről és hátrányairól magyarázatot adunk ebben az útmutatóban.

Mi a Linux-stabil kernel?

A Linux szerint stabil, amint a neve azt sugallja, a Linux kernel stabil karja. A másik kar úgynevezett „mainline”, amely a fő ág . A Linux kernel fejlesztése a mainline-ban történik, és általában ezt a folyamatot követi:

1. Linus Torvalds két hétig egy csomó javítást fog elvégezni karbantartóitól.
2. Ez a két hét után kiad egy rc1 (pl. 4.14-rc1) kernelt.
3. A következő 6-8 hét minden hétig kiad egy újabb RC (pl. 4.14-rc2, 4.14-rc3 stb.) Kernelt, amely CSAK CSAK hiba- és regressziós javításokat tartalmaz.
4. Amint azt stabilnak tekintik, tarbálként kerül kiadásra az org-on történő letöltésre (pl. 4.14).

Mik az LTS kernelek?

Greg minden évben kiválaszt egy kernelt, és akár két évig (LTS), vagy hat évig (kiterjesztett LTS) fenntartja azt. Ezeket úgy tervezték, hogy stabilitást igénylő termékek legyenek (például Android telefonok vagy más IOT eszközök). A folyamat pontosan megegyezik a fentiekkel, csak hosszabb ideig történik. Jelenleg hat LTS-kernel van (amelyek mindig megtekinthetők a kernel.org kiadások oldalon):

• 4.14 (LTS), fenntartja Greg Kroah-Hartman
• 4, 9 (LTS), fenntartja Greg Kroah-Hartman
• 4.4 (eLTS), fenntartja Greg Kroah-Hartman
• 4.1 (LTS), fenntartja Sasha Levin
• 3.16 (LTS), karbantartója Ben Hutchings
• 3.2 (LTS), karbantartója Ben Hutchings

Milyen előnyei vannak annak, ha az Android rendszermagot a Linux Stable-hez tovább frissítjük?

A fontos sebezhetőségek feltárásakor / javításakor a stabil kernelek képesek először ezeket megszerezni. Így az Android rendszermag sokkal biztonságosabb lesz a támadások, a biztonsági hibák és általában a hibák ellen.

A Linux stabil része javításokat tartalmaz sok olyan illesztőprogramhoz, amelyet Android-eszköz nem használ, főleg felesleges?

Igen és nem, attól függően, hogy hogyan határozza meg „leginkább”. Lehet, hogy a Linux kernel tartalmaz egy csomó kódot, amelyet nem használnak az Android rendszerben, de ez nem garantálja, hogy az új verziók egyesítésekor ezek a fájlok nem fognak ütközni! Tudja meg, hogy gyakorlatilag senki sem épít a kernel minden egyes részét, még a leggyakoribb Linux disztrókat sem, például az Ubuntu vagy a Mint. Ez nem azt jelenti, hogy nem kellene ezeket a javításokat elvégeznie, mert vannak javítások az Ön által futtatott illesztőprogramokhoz. Vegyük például a arm / arm64 és az ext4 fájlokat, amelyek a leggyakoribb Android architektúra és fájlrendszer. A 4.4. Pontban, a 4.4.78-ról (a legfrissebb Oreo CAF-címke verziója) és a 4.4.121-ig (a legújabb upstream címke), ezek a rendszerek az alábbi számok:

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

A legigényesebb rész a kezdeti nevelés; Ha már naprakész vagy, egyáltalán nem vesz igénybe az új kiadás egyesítése, amely általában legfeljebb 100 elkötelezettséget tartalmaz. Ennek az előnyeinek (nagyobb stabilitás és jobb biztonság a felhasználók számára) ennek a folyamatnak azonban szükségessé kell válnia.

Hogyan egyesíthetjük a Linux stabil kernelét egy Android rendszermaghoz

Először ki kell találnia, hogy melyik rendszermag-verzió fut az Android-eszközén.

Bármi triviális, mint amilyennek látszik, tudnia kell, hogy kezdje el. Futtassa a következő parancsot a kernelfában:

 kernelverziót készíteni 

Vissza fogja jeleníteni a használt verziót. Az első két számot a szükséges ág kiszámításához használja (pl. Linux-4.4.y bármely 4.4 kernel esetén), az utolsó szám pedig annak meghatározására szolgál, hogy melyik verziót kell kezdenie az egyesítéssel (pl. Ha a 4.4-en van .21, ezt követően a 4.4.22 egyesül).

Ragadja meg a kernel.org legújabb kernelforrását

A kernel.org a legújabb kernelforrást tartalmazza a linux-stabil lerakatban. Az oldal alján három lekérési link található. Tapasztalataim szerint a Google tükörje általában a leggyorsabb, de az eredmények eltérőek lehetnek. Futtassa a következő parancsokat:

 git remote add linux-stabil //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit letöltés linux-stabil 

Döntse el, hogy szeretné-e egyesíteni a teljes kernelt, vagy cseresznye-válogatottan akarja-e elkötelezni magát

Ezután ki kell választania, hogy egyesíti-e a kötelezettségvállalásokat vagy a cseresznye-válogatást. Itt vannak az előnyei és hátrányai, és mikor érdemes megtenni őket.

MEGJEGYZÉS: Ha a kernel forrása tarbál formájában van, akkor valószínűleg cseresznyét kell választania, különben több ezer fájlkonfliktus lesz, mert a git a történelem pusztán az upstream-en alapul, nem pedig az OEM vagy a CAF megváltozott. Csak ugorjon a 4. lépésre.

Kimazsolázzák:

Előnyök:

• Könnyen megoldható a konfliktus, mivel pontosan tudja, mi okozza a problémát.
• Könnyebb újrabecsülni, mivel minden kötelezettségvállalás önmagában van.
• Könnyebb elválasztani, ha problémákba ütközik

Hátrányok:

• Hosszabb időt vesz igénybe, mivel minden kötelezettségvállalást külön kell megválasztani.
• Kicsit nehezebb megmondani, hogy az elkötelezettség első pillantásra az előző szakaszban van-e

Összeolvad

Előnyök :

• Ez gyorsabb, mivel nem kell megvárnia az összes tiszta javítás összeolvadását.
• Könnyebben észrevehető, ha egy kötelezettségvállalás upstream-től származik, mivel nem leszel elkövető, az upstream fenntartó lesz.

Hátrányok:

• A konfliktusok megoldása egy kicsit nehezebb lehet, mivel a git log / git hibával kell megvizsgálnia, melyik elkövető okozza a konfliktust. Ez közvetlenül nem fogja mondani.
• A visszavágás nehéz, mivel nem tudja újra összevonni az egyesülést, felajánlja, hogy az összes kötelezettségvállalást külön-külön megválasztja. Ugyanakkor nem szabad gyakran pihennie, inkább a git revert és a git merge lehetőséget használja.

Azt javasolnám, hogy csinálj egy cseresznyefajtát a problémák konfliktusainak kiderítéséhez, összevonással, majd utána visszatérve a problémakötelezettségvállalásokra, így a frissítés könnyebb (mivel az egyesítés gyorsabb, ha naprakészek).

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

Ennek a folyamatnak a legfontosabb része az egy-egy verzió. Lehet, hogy van egy probléma javítás az upstream sorozatban, amely problémákat okozhat a rendszerindításkor, vagy megszakíthat valamit, például hangot vagy töltést (a tippeket és trükköket ismertető szakaszban olvashat). Ezért fontos a növekményes változatváltoztatás, ezért könnyebb megtalálni a problémát 50 megbízásnál, mint egyes verziók esetén a 2000-nél nagyobb mértékben. Csak azt javasolnám, hogy végezzen teljes összeolvadást, ha tudomása van az összes problémáról és a konfliktus megoldásáról.

Kimazsolázzák

Formátum:

 git cseresznye-válogatás .. 

Példa:

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

Összeolvad

Formátum:

 git merge 

Példa:

git merge v3.10.74

Azt javaslom, hogy nyomon kövesse a konfliktusokat az egyesítési kötelezettségvállalásokban a # jelölők eltávolításával.

A konfliktusok megoldása

Nem adhatunk lépésről lépésre útmutatást minden egyes konfliktus megoldására, mivel ez magában foglalja a C nyelv jó ismereteit, de itt van néhány tipp.

Összeolvadás esetén derítse ki, hogy mi okozza a konfliktust. Ezt megteheti a következő két módszer egyikével:

1. git log -pv $ (make kernelversion) .. hogy megkapja a változásokat a jelenlegi verzió és a legfrissebb között az upstreamről. A -p zászló megadja az egyes elkötelezettségek által elvégzett változtatásokat, így láthatja őket.
2. Futtassa a git hibát a fájlban, hogy megkapja a körzeten belüli egyes kivonatok kivonatát. Ezután futtathatja a git show –format = teljesebb verziót, hogy megtudja, az elkövető a mainline / stabil, a Google vagy a CodeAurora oldalról származott.

• Rájössze, hogy már rendelkezik-e elkötelezettséggel. Egyes szállítók, például a Google vagy a CAF, megkísérelnek felkeresni a kritikus hibákat, például a Dirty COW javítást, és hátrányaik ütközhetnek az upstream termékekkel. Futtathatja a git log –grep = ”” parancsot, és megnézheti, hoz-e vissza valamit. Ha igen, akkor kihagyhatja az elkötelezettséget (ha a cseresznye-szedés git reset –hard && git cseresznye-válogatással folytatódik), vagy figyelmen kívül hagyhatja a konfliktusokat (távolítsa el a <<<<< >>>>>).
• Mutassa be, hogy volt-e olyan backport, amely zavarja a felbontást. A Google és a CAF szeretne bizonyos javításokat visszaadni, amelyek nem lennének stabilak. A stabil szereplőknek gyakran módosítaniuk kell a mainline állásfoglalásának azon döntését, hogy hiányoznak bizonyos javítások, amelyeket a Google a visszamenőleges döntéshez választ. A git show futtatásával megnézheti a fővonal elkötelezettségét (a mainline kivonat elérhető lesz a stabil átadási üzenetben). Ha van egy hátrányos adat, ez elronthatja a módosításokat, vagy használhatja a mainline verziót (amit általában meg kell tennie).
• Olvassa el, hogy mit tesz a kötelezettségvállalás, és ellenőrizze, hogy a probléma már megoldódott-e. A CAF néha javíthat egy hibát az upstreamtől függetlenül, vagyis felülírhatja a upstream javítását, vagy el is dobhatja azt, mint fent.

Máskülönben ez csak egy CAF / Google / OEM kiegészítés eredménye, ebben az esetben csak meg kell változtatnia néhány dolgot.

Itt található a GitHubon található Linux-stabil kernel.org lerakat tükrözője, amely könnyebben megkönnyítheti a kötelező listák és a konfliktusmegoldások diffúzióinak felkutatását. Azt javaslom, hogy először keresse meg a kötelezettségvállalási lista nézetet, és keresse meg a problémát, hogy látja az eredeti eltérést, hogy összehasonlítsa a sajátval.

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

Ezt a parancssoron keresztül is megteheti:

 git log .. git show 

A határozatok megoldása a kontextusra vonatkozik. Mindössze annyit kell tennie, hogy ellenőrizze, hogy a végleges diff értéke megegyezik-e az upstream-kel, ha a következő parancsokat futtatja két külön ablakban:

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

Az újracsatlakozás engedélyezése

A Gitnek van egy olyan funkciója, melynek neve a rerere (a rögzített felbontás újrafelhasználása). Ez azt jelenti, hogy amikor konfliktust észlel, rögzíti, hogyan oldotta meg, így később újra felhasználhatja. Ez különösen akkor hasznos mind a krónikus újbóli átalakítóknál, mind az összeolvadással, mind a cseresznyével, mivel csak a git add-t kell futtatnia. && git - folytassa az upstream visszaváltás újrakezdésekor, mivel a konfliktus úgy oldódik meg, ahogyan azt korábban megoldotta.

Engedélyezhető a következő parancs futtatásával a kernel repo-jában:

 git config rerere.enabled true 

Hogyan lehet elválasztani a fordítót vagy futásidejű hibát futtatva?

Tekintettel arra, hogy jelentős számú megbízást ad hozzá, nagyon valószínű, hogy bevezet egy fordítót vagy futásidejű hibát. Ahelyett, hogy csak feladná, használhatja a git beépített bisect eszközét a probléma kiváltó okainak kiderítésére! Ideális esetben minden egyes kernel verziót elkészít és villog, amikor hozzáteszi, így a felbontás kevesebb időt vesz igénybe, ha szükséges, de az elválasztást 5000 elem nélkül végezheti el.

Amit a bisect megteszi, az az, hogy egy sor kötelezettségvállalást feltesz, attól a pillanattól kezdve, ahol nem volt jelen, majd elkezdi a felére csökkenteni a kötelezettségvállalási tartományt, lehetővé téve az ön felépítését és tesztelését, és tudatja vele, hogy jó vagy sem . Folytatja ezt addig, amíg ki nem szünteti a problémáját okozó kötelezettséget. Ezen a ponton javíthatja vagy visszaállíthatja.

1. Keresztező felemelés: indítsa el a felezetet
2. Nevezze meg az aktuális verziót rossznak: git bisect bad
3. Jelölje meg a revíziót jónak: git bisect good
4. Építsd az új verzióval
5. Az eredmény alapján (ha a probléma fennáll vagy sem), mondja meg a git: git bisect jó VAGY git bisect bad
6. Öblítse le és ismételje meg a 4-5. Lépést, amíg a probléma megszűnik!
7. Visszaállíthatja vagy kijavíthatja a problémát.

MEGJEGYZÉS: Az egyesüléseknek ideiglenesen futtatniuk kell a git rebase -i parancsot az ágon a helyes feldaraboláshoz, mivel a helyes egyesítésekkel történő elválasztás gyakran alkalommal kijelentkezik az upstream kötelezettségekre, azaz az Android-hoz nem tartozik semmiféle konkrét kötelezettségvállalás. Kérésre elmélyülhetek ezzel, de bízz bennem, erre szükség van. Miután azonosította a probléma elkövetését, visszaállíthatja vagy újracsatlakozhatja az egyesítésbe.

NE töltse le az upstream frissítéseket

Nagyon sok új fejlesztő kísérti ezt, mivel „tisztább” és „könnyebb” kezelni. Ez néhány ok miatt szörnyű:

• A szerzőség elveszett. Méltánytalan más fejlesztőkkel szemben, ha munkájukhoz hitelt írnak elő.
• Az elválasztás lehetetlen. Ha elköt egy sor elkötelezettséget, és valami kérdés abban a sorozatban, lehetetlen megmondani, hogy melyik elkötelezettség okozta problémát egy squash-ban.
• A jövőbeni cseresznyefajták nehezebbek. Ha újracsinálni kell egy összecsapott sorozattal, nehéz / lehetetlen megmondani, honnan származik a konfliktus.

Iratkozzon fel a Linux Kernel levelezőlistájára az időben történő frissítéshez

Feliratkozás a linux-kernel-bejelentett listára annak érdekében, hogy értesítést kapjon bármilyen upstream frissítésről. Ez lehetővé teszi, hogy e-mailt kapjon minden új kernel kiadásakor, így a lehető leggyorsabban frissítheti és tovább tudja nyomtatni.