kā

Kā atjaunināt Android kodolu uz jaunāko Linux stabilo versiju

Mēs esam iekļāvuši ceļvežus par Android kodoliem, piemēram, “Kā izveidot pielāgotu kodolu” un “Labākie pielāgotie kodoli Android ierīcēm”, taču šodien mēs jums parādīsim, kā augšup paņemt kodolu pret jaunāko Linux stabilo versiju.

Lūdzu, ņemiet vērā, ka tas ir uzlabotas lietas - ja jūs nekad iepriekš neesat sastādījis kodola, jums jāievēro iepriekš pievienotā rokasgrāmata “Kā izveidot pielāgotu kodolu”, un šajā rokasgrāmatā tiks iekļauta ķiršu atlasīšana un saistību apvienošana no jaunākajiem Linux- stabils kodola ar savu Android kodolu, pirms jūs to kompilējat.

Jūsu Android kodola jaunināšana uz jaunāko Linux stabilu sniedz daudz pozitīvu priekšrocību, piemēram, to, ka esat atjaunināts ar jaunākajām drošības saistībām un kļūdu labojumiem - dažus no plusiem un mīnusiem mēs izskaidrosim šajā rokasgrāmatā vēlāk.

Kas ir stabils Linux kodols?

Linux stabils, kā norāda nosaukums, ir stabila Linux kodola daļa. Otra roka ir pazīstama kā “mainline”, kas ir galvenā filiāle . Visa Linux kodola izstrāde notiek galvenajā līnijā, un parasti tas notiek šādi:

Linuss Torvalds divu nedēļu laikā no saviem uzturētājiem ņems ķekars plāksteru.
Pēc šīm divām nedēļām viņš atbrīvo rc1 (piemēram, 4.14-rc1) kodolu.
Katru nedēļu nākamajās 6-8 nedēļās viņš izlaidīs citu RC (piemēram, 4.14-rc2, 4.14-rc3 utt.) Kodolu, kurā ir TIKAI kļūdu un regresijas labojumi.
Tiklīdz tas tiks uzskatīts par stabilu, tas tiks izlaists kā tarbols lejupielādei vietnē org (piemēram, 4.14).

Kas ir LTS kodoli?

Katru gadu Gregs izvēlēsies vienu kodolu un uzturēs to divus gadus (LTS) vai sešus gadus (pagarināts LTS). Tie ir izstrādāti tā, lai tiem būtu produkti, kuriem nepieciešama stabilitāte (piemēram, Android tālruņi vai citas IOT ierīces). Process ir tieši tāds pats kā iepriekš, tas notiek tikai ilgāku laiku. Pašlaik ir seši LTS kodoli (kurus vienmēr var apskatīt kernel.org izlaidumu lapā):

4.14 (LTS), uztur Gregs Kroahs-Hartmans
4, 9 (LTS), uztur Gregs Kroahs-Hartmans
4.4 (eLTS), uztur Gregs Kroahs-Hartmans
4.1 (LTS), uztur Saša Levins
3.16 (LTS), uztur Bens Hjūdžings
3.2 (LTS), uztur Bens Hutings

Kādas ir mana Android kodola augšupielādes uz Linux Stable priekšrocības?

Atklājot / labojot svarīgas ievainojamības, stabilie kodoli ir pirmie, kas tos iegūst. Tādējādi jūsu Android kodols būs daudz drošāks pret uzbrukumiem, drošības trūkumiem un tikai kļūdām kopumā.

Linux stabilajā versijā ir labojumi daudziem draiveriem, kurus mana Android ierīce neizmanto, vai tas lielākoties nav vajadzīgs?

Jā un nē, atkarībā no tā, kā jūs definējat “lielākoties”. Linux kodolā var būt daudz kodu, kas Android sistēmā netiek izmantots, taču tas negarantē, ka, apvienojot jaunas versijas, no šiem failiem nebūs konfliktu! Saprotiet, ka faktiski neviens neveido katru kodola daļu, pat ne visizplatītākajos Linux distros, piemēram, Ubuntu vai Mint. Tas nenozīmē, ka jums nevajadzētu lietot šos labojumus, jo ir draiveru, kurus jūs vadāt, labojumi. Piemēram, ņemiet arm / arm64 un ext4, kas ir visizplatītākā Android arhitektūra un failu sistēma. 4.4. Punktā no 4.4.78 (jaunākās Oreo CAF birkas versija) līdz 4.4.121 (jaunākais augšupvērstais tags) ir šādi skaitļi šo sistēmu izdarītajām darbībām:

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

Visietilpīgākā daļa ir sākotnējā audzināšana; Kad esat visu laiku atjaunināts, nepaiet ne mazums laika, lai apvienotos jaunā laidienā, kurā parasti nav vairāk par 100 saistībām. Tomēr šī procesa dēļ ir jāizmanto priekšrocības, ko tas sniedz (lielāka stabilitāte un labāka drošība lietotājiem).

Kā sapludināt Linux stabilo kodolu Android kodolā

Vispirms jums ir jāizdomā, kāda kodola versija darbojas jūsu Android ierīcē.

Tik mazsvarīgs, kā tas šķiet, ir jāzina, kur jums jāsāk. Savā kodola kokā palaidiet šādu komandu:

 veikt kodolu

Tas atgriezīs jūsu izmantoto versiju. Pirmie divi cipari tiks izmantoti, lai izdomātu nepieciešamo filiāli (piemēram, linux-4.4.y jebkuram 4.4 kodolam), un pēdējais numurs tiks izmantots, lai noteiktu, kura versija jums jāsāk ar apvienošanu (piemēram, ja jūs izmantojat 4.4. .21, nākamo sapludināsit 4.4.22).

Satveriet jaunāko kodola avotu no kernel.org

kernel.org atrodas jaunākais kodola avots Linux stabilā krātuvē. Šīs lapas apakšā būs trīs ienest saites. Pēc manas pieredzes Google spogulis mēdz būt visātrākais, taču jūsu rezultāti var atšķirties. Izpildiet šīs komandas:

 git tālvadības pievienošana Linux stabils //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit ienākt linux-stabila

Izlemiet, vai vēlaties apvienot visu kodolu vai izvēlēties “ķiršu izvēlē” saistības

Tālāk jums būs jāizvēlas, vai vēlaties apvienot saistības vai izvēlēties ķiršu. Šeit ir plusi un mīnusi katram un kad jūs varētu vēlēties tos izdarīt.

PIEZĪME: Ja jūsu kodola avots ir tarbols, jums, visticamāk, vajadzēs ķiršu izvēli, pretējā gadījumā jūs iegūsit tūkstošiem failu konfliktu, jo GIT vēsture balstās tikai uz augšupēju, nevis to, kas ir OEM vai CAF mainīts. Pāriet tikai uz 4. darbību.

Ķiršu lasīšana:

Plusi:

Vieglāk atrisināt konfliktus, jo precīzi zināt, kas konfliktu rada problēmu.
Vieglāk atkārtot savu darbību, jo katra apņemšanās ir viena pati.
Vieglāk sadalīt, ja rodas problēmas

Mīnusi:

Tas prasa ilgāku laiku, jo katra apņemšanās ir jāizvēlas atsevišķi.
Nedaudz grūtāk pateikt, vai saistības no pirmā acu uzmetiena ir no augšupējās puses

Apvienot

Plusi :

Tas notiek ātrāk, jo jums nav jāgaida, kad visi tīrāki plāksteri tiks apvienoti.
Vieglāk ir redzēt, kad saistības tiek veiktas no augšējās puses, jo jūs nebūsit izdarītājs, bet gan augšupējais uzturētājs.

Mīnusi:

Konfliktu risināšana var būt nedaudz grūtāka, jo jums būs jāmeklē, kuras saistības izraisa konfliktu, izmantojot git log / git vainu, tas jums to tieši nepateiks.
Atjaunošana ir sarežģīta, jo jūs nevarat atkārtoti apvienot apvienošanu. Tā piedāvās izvēlēties visas saistības individuāli. Tomēr jums nevajadzētu rebasing bieži, tā vietā, kur iespējams, izmantojiet git revert un git merge.

Es ieteiktu veikt izvēli, lai sākotnēji izdomātu visus problēmu konfliktus, veiktu apvienošanu, pēc tam atgrieztu problēmu, tāpēc vēlāk atjaunināšana ir vienkāršāka (jo apvienošana notiek ātrāk pēc atjaunināšanas).

Pievienojiet saistības savam avotam, vienu versiju vienlaikus

Vissvarīgākā šī procesa sastāvdaļa ir viena versija vienlaikus. Jūsu augšupējās sērijās VAR BŪT problēmu ielāps, kas var izraisīt sāknēšanas problēmu vai sabojāt kaut ko līdzīgu skaņai vai lādēšanai (paskaidrots sadaļā Padomi un triki). Lai veiktu papildu versiju izmaiņas, ir svarīgi šī iemesla dēļ, ir vieglāk atrast problēmu 50 apņemšanās, nekā dažām versijām pārsniedzot 2000 saistību. Es ieteiktu veikt pilnīgu apvienošanu tikai tad, kad jūs zināt visas problēmas un konfliktu risinājumus.

Ķiršu lasīšana

Formāts:

 Git ķiršu izvēlēties ..

Piemērs:

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

Apvienot

Formāts:

 git sapludināt

Piemērs:

git merge v3.10.74

Es iesaku izsekot konfliktiem apvienošanās saistībās, noņemot # marķierus.

Kā atrisināt konfliktus

Mēs nevaram sniegt soli pa solim katra konflikta atrisināšanu, jo tas prasa labas C valodas zināšanas, taču šeit ir daži padomi.

Ja jūs apvienojaties, noskaidrojiet, kādas saistības izraisa konfliktu. To var izdarīt vienā no diviem veidiem:

git log -pv $ (veikt kodola versiju) .. lai iegūtu izmaiņas starp jūsu pašreizējo versiju un jaunāko no augšpus. P-karodziņš parādīs izmaiņas, ko izdarījusi katra apņemšanās, lai jūs varētu redzēt.
Palaidiet vainu failā, lai iegūtu katras sadaļas sajaukumu šajā apgabalā. Pēc tam varat palaist vietni git show –format = pilnāks, lai redzētu, vai izdarītājs ir bijis mainline / stabils, Google vai CodeAurora.

Izdomājiet, vai jums jau ir saistības. Daži pārdevēji, piemēram, Google vai CAF, mēģinās meklēt kritiskas kļūdas, piemēram, Dirty COW labojumus, un viņu aizmugures dati varētu būt pretrunā ar augšupējiem. Varat palaist git log –grep = ”” un redzēt, vai tas kaut ko atgriež. Ja tas tā notiek, varat izlaist saistības (ja ķiršu atlasīšana, izmantojot git reset - grūti && git ķiršu izvēle - turpināt) vai ignorēt konfliktus (noņemiet <<<<< >>>>>).
Noskaidrojiet, vai ir bijis aizmugures ziņojums, kas izjauc izšķirtspēju. Google un CAF vēlas dublēt noteiktus ielāpus, kas nekļūtu stabili. Stabilai bieži būs jāpielāgo galvenā apņemšanās izšķirtspēja, ņemot vērā noteiktu izlaišanu, kuras Google izvēlas atbalstīt. Varat aplūkot galvenās līnijas apņemšanos, palaižot Git Show (galvenās līnijas hash būs pieejams stabilas saistības saistīšanas ziņojumā). Ja rodas sabojāšanās ar backport, jūs varat vai nu atmest izmaiņas, vai arī varat izmantot galvenās līnijas versiju (kas parasti jums būs jādara).
Izlasiet, ko cenšas paveikt, un pārbaudiet, vai problēma jau ir novērsta. Dažreiz CAF var novērst kļūdu, kas nav atkarīga no augšupējās, ti, jūs varat vai nu pārrakstīt to labojumus augšupējā straumē, vai arī to atmest, tāpat kā iepriekš.

Pretējā gadījumā tas var būt tikai CAF / Google / OEM pievienošanas rezultāts, un tādā gadījumā jums vienkārši jāpārmaisa dažas lietas.

Šeit ir linux-stabila kernel.org repozitorija GitHub spogulis, kuru var vieglāk meklēt saistību sarakstus un konfliktu risināšanas diferenciāļus. Es iesaku vispirms doties uz saistību saraksta skatu un atrast problēmu, lai redzētu sākotnējo atšķirību, lai salīdzinātu to ar jūsu pašu.

URL piemērs: //github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

To var izdarīt arī, izmantojot komandrindu:

 git log .. git šovs

Rezolūciju risināšana ir saistīta ar kontekstu. Tas, kas jums vienmēr būtu jādara, ir pārliecināties, ka galīgā diferenciālā vērtība sakrīt ar augšdaļu, palaižot šīs komandas divos atsevišķos logos:

 git diff HEAD git diff v $ (veikt kodolu apgriezienus) .. $ (git tags - sort = -taggerdate -lv $ (veikt kodola pārstrādi | cut-d. -f 1, 2) * | head-n1)

Iespējot atkārtotu atskaņošanu

Git ir funkcija ar nosaukumu rerere (apzīmē ierakstu atkārtotu izmantošanu), kas nozīmē, ka, atklājot konfliktu, tas reģistrēs, kā jūs to atrisinājāt, lai jūs vēlāk varētu to atkārtoti izmantot. Tas ir īpaši noderīgi abiem hroniskajiem rebasers gan apvienojot, gan izvēloties ķiršus, jo jums būs nepieciešams tikai palaist git add. && git - turpiniet, atkārtojot augšupielādi, jo konflikts tiks atrisināts tā, kā jūs to iepriekš atrisinājāt.

To var iespējot, palaižot šo komandu kodola repo:

 git config rerere.enabled true

Kā atbrīvoties no dalīšanas, nonākot kompilatorā vai izpildlaika kļūda

Ņemot vērā, ka jūs pievienosit ievērojamu skaitu apņemšanos, jums ir ļoti iespējams ieviest kompilatoru vai izpildlaika kļūdu. Tā vietā, lai tikai padotos, varat izmantot git iebūvēto bisekta rīku, lai noskaidrotu problēmas galveno cēloni! Ideālā gadījumā jūs izveidosit un mirgos katru kodola versiju, kad to pievienosit, tāpēc sadalīšana prasīs mazāk laika, ja nepieciešams, bet jūs varat sadalīt 5000 saistības bez jebkādām problēmām.

Gis bisect darīs, izmantojot dažādas saistības, sākot ar aktuālo jautājumu līdz vietai, kur tas vēl nebija, un tad sāciet uz pusi samazināt saistību diapazonu, ļaujot jums izveidot un pārbaudīt, kā arī paziņot, vai tas ir labi vai nē. . Tas turpināsies līdz brīdim, kad tas izspiež saistības, kas izraisīja jūsu problēmu. Tajā brīdī jūs varat to labot vai mainīt.

Sāciet dalīšanu: divreiz sākiet
Atzīmēt pašreizējo versiju kā sliktu: git bisect bad
Apzīmējiet labojumu kā labu: git bisect good
Veidojiet ar jauno versiju
Balstoties uz rezultātu (ja problēma ir vai nav), sakiet git: git bisect good VAI git bisect bad
Noskalojiet un atkārtojiet 4.-5. Darbību, līdz tiek atrasta problēma!
Atjaunot vai novērst problēmas apņemšanos.

PIEZĪME. Apvienošanās gadījumiem būs īslaicīgi jāpalaiž git rebase -i, lai pareizi piemērotu sadalīšanu jūsu filiālē visus plāksterus, jo sadalīšana, veicot vietējos apvienojumus, bieži tiek pārbaudīta augšupējās saistībās, kas nozīmē, ka jums nav nevienas no īpašajām Android saistībām. Pēc pieprasījuma es varu iedziļināties šajā jautājumā, bet ticiet man, tas ir vajadzīgs. Kad esat identificējis problēmas izdarīšanu, varat to atgriezt vai atjaunot apvienošanā.

NEVAJADZIET augšupējos atjauninājumus

Daudziem jauniem izstrādātājiem ir kārdinājums to darīt, jo tas ir “tīrāks” un “vieglāk” pārvaldāms. Tas ir briesmīgi vairāku iemeslu dēļ:

Zūd autorība. Tas ir negodīgi attiecībā pret citiem izstrādātājiem, ja viņu darbam tiek noteikts kredīts.
Sadalīšana nav iespējama. Ja jūs sašņorējat virkni izdarīto lietu un kaut kas ir jautājums šajā sērijā, nav iespējams pateikt, kādas saistības izraisīja skvoša problēmu.
Nākotnes ķiršu izlase ir grūtāka. Ja jums ir nepieciešams atgriezties ar sašaurinātu sēriju, ir grūti / neiespējami pateikt, no kurienes rodas konflikts.

Lai savlaicīgi atjauninātu, abonējiet Linux kodola adresātu sarakstu

Lai saņemtu paziņojumu par atjauninājumu augšupielādi, abonējiet linux-kodola paziņojumu sarakstu. Tas ļaus jums saņemt e-pastu katru reizi, kad tiek izlaists jauns kodols, lai jūs varētu atjaunināt un virzīt pēc iespējas ātrāk.