kako da

Kako ažurirati Android Kernel na najnoviji Linux Stable

Opisali smo vodiče za Android kernele, poput "Kako napraviti prilagođenu jezgru" i "Najbolje prilagođene jezgre za Android", ali danas ćemo vam pokazati kako nadograditi svoje jezgre na najnoviji Linux stabilizator.

Imajte na umu da su to napredne stvari - ako nikada prije niste sastavili kernel, slijedite gore navedeni vodič "Kako izgraditi prilagođeno jezgro", a ovaj će vodič uključivati branje trešanja i spajanje obveza iz najnovijeg Linux-a, stabilno jezgro s vašim Android kernelom prije nego što ga sastavite.

Ažuriranje vašeg kernela na Android na najnoviju stabilnost Linuxa ima puno pozitivnih prednosti, poput ažuriranja s najnovijim sigurnosnim odredbama i pogreškama - neke od prednosti i nedostataka objasnit ćemo kasnije u ovom vodiču.

Što je Linux stabilno jezgro?

Linux stabilan kao što samo ime govori stabilna je ruka Linux kernela. Druga ruka je poznata kao "glavna linija", što je glavna grana . Sav razvoj kernela Linuxa odvija se u glavnoj liniji i uglavnom slijedi ovaj postupak:

Linus Torvalds za dva će tjedna uzeti hrpu flastera od svojih održavača.
Nakon ta dva tjedna, on oslobađa rc1 (npr. 4.14-rc1) kernel.
Za svaki tjedan u sljedećih 6-8 tjedana, on će pustiti još jedan RC (npr. 4.14-rc2, 4.14-rc3, itd.) Kernel, koji sadrži SAMO ispravke grešaka i regresije.
Jednom kada se ocijeni stabilnim, bit će objavljen kao tarball za preuzimanje na org (npr. 4.14).

Što su LTS jezgre?

Svake godine Greg će odabrati jedno jezgro i održavati ga dvije godine (LTS) ili šest godina (produženi LTS). Dizajnirani su tako da imaju proizvode koji trebaju stabilnost (poput Android telefona ili drugih IOT uređaja). Proces je potpuno isti kao gore, događa se samo duže vrijeme. Trenutno postoji šest LTS jezgara (koje se uvijek mogu vidjeti na stranici izdanja kernel.org):

4.14 (LTS), održao Greg Kroah-Hartman
4, 9 (LTS), održavao Greg Kroah-Hartman
4.4 (eLTS), održavao Greg Kroah-Hartman
4.1 (LTS), održava Saša Levin
3.16 (LTS), a održava Ben Hutchings
3.2 (LTS), koji održava Ben Hutchings

Koje su prednosti nadogradnje mog Android jezgre na Linux Stable?

Kada se otkriju / fiksiraju važne ranjivosti, prvi su ih dobili stabilni jezgri. Tako će vaše Android kernel biti puno sigurniji od napada, sigurnosnih propusta i općenito grešaka.

Stabilnost Linuxa sadrži popravke za puno upravljačkih programa koji moj Android uređaj ne koristi, nije li to uglavnom nepotrebno?

Da i ne, ovisno o tome kako definirate "uglavnom". Linux kernel može sadržavati puno koda koji se ne koristi u sustavu Android, ali to ne jamči da neće biti sukoba tih datoteka prilikom spajanja novih verzija! Shvatite da gotovo nitko ne gradi svaki pojedini dio kernela, pa čak ni najobičnije Linux distribucije poput Ubuntu ili Mint. To ne znači da ne biste trebali uzimati te popravke, jer postoje ispravke za upravljačke programe koje DOSTE pokrećete. Na primjer, uzmite arm / arm64 i ext4, koji su najčešći Android arhitektura i datotečni sustav. U 4.4, od 4.4.78 (verzija najnovije oznake Oreo CAF) do 4.4.121 (najnovija oznaka uzvodno), to su sljedeći brojevi za naredbe tih sustava:

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

Dio koji troši najviše vremena je početni odgoj; nakon što budete ažurirani, ne treba vam vremena za spajanje u novo izdanje, koje obično sadrži ne više od 100 obveza. Prednosti koje ovo donosi (veća stabilnost i veća sigurnost za vaše korisnike) ipak bi trebale zahtijevati ovaj postupak.

Kako spojiti stabilni kernel Linuxa u Android Kernel

Prvo trebate saznati koja je verzija kernela na vašem Android uređaju.

Koliko god ovo izgledalo trivijalno, potrebno je znati odakle trebate započeti. Izvedite sljedeću naredbu u vašem stablu jezgre:

 napraviti kernelverziju

Vratit će vam verziju na kojoj ste. Prva dva broja koristit će se za utvrđivanje potrebne grane (npr. Linux-4.4.y za bilo koji 4.4 kernel), a posljednji će se broj koristiti za određivanje verzije koju trebate započeti spajanjem (npr. Ako ste na 4.4 .21, spojit ćete sljedeći 4.4.22).

Uzmi najnoviji izvor kernela s kernel.org

kernel.org čuva najnoviji kernel izvor u Linux-stabilnom spremištu. Na dnu stranice nalaze se tri dohvaćene veze. Prema mom iskustvu, Google-ovo ogledalo obično je najbrže, ali vaši se rezultati mogu razlikovati. Pokrenite sljedeće naredbe:

 git daljinsko dodavanje Linux-stabilnog //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit dohvaćanje Linux-stabilnog

Odlučite želite li spojiti čitavu jezgru ili odabrati trešnje

Zatim ćete morati odabrati želite li spojiti obveze ili odabire trešanja. Evo prednosti i nedostataka svakog od njih i kada ih možda želite učiniti.

NAPOMENA: Ako je vaš kernel izvor u obliku tarbola, najvjerojatnije ćete trebati odabrati, u protivnom ćete dobiti tisuće sukoba datoteka jer git puni povijest utemeljenu isključivo na uzvodnoj strani, a ne na onome što OEM ili CAF imaju promijenila. Jednostavno prijeđite na korak 4.

Branje trešanja:

Pros:

Lakše ćete riješiti sukobe jer točno znate koji sukob uzrokuje problem.
Lakše za ponovno postavljanje podataka jer je svaka obveza samostalna.
Jednostavnije za dijeljenje ako naiđete na probleme

Cons:

Potrebno je duže vrijeme jer se svaka obveza pojedinačno bira.
Malo je teže utvrditi je li počinjenje od prvog pogleda uzlazno

Sjediniti

Pros :

Brže je jer ne morate čekati da se svi čisti flasteri spoje.
Lakše je vidjeti kada je počinjenje izvodno, jer vi nećete biti počinitelj, uzlazni će biti.

Cons:

Rješavanje sukoba može biti malo teže jer ćete trebati potražiti koji počinitelj uzrokuje sukob koristeći git log / git blame, to vam neće izravno reći.
Oslobađanje je teško jer spajanje ne možete ponovo postaviti, ono će ponuditi da odaberete sve obveze pojedinačno. Međutim, ne biste trebali često objavljivati nove verzije, umjesto toga upotrijebite git revert i git merge gdje je to moguće.

Preporučio bih vam da odaberete trešnju da biste prvo otkrili bilo kakve probleme u sukobu, napravili spajanje, a zatim problem ponovo počinili nakon čega je ažuriranje lakše (jer je spajanje brže nakon ažuriranja).

Dodajte obveze svom izvoru, jednu po jednu verziju

Najvažniji dio ovog postupka je pojedinačna verzija. U nadolazećoj seriji MOŽE postojati problem zakrpa, što može uzrokovati problem s dizanjem ili slomiti nešto poput zvuka ili punjenja (objašnjeno u odjeljku savjeta i trikova). Zbog toga je važno izvršiti inkrementalne izmjene verzija, zato je lakše pronaći problem u 50 uređanja nego na 2000 inačica za neke verzije. Preporučio bih vam potpuno spajanje tek kada saznate sve probleme i počinjenja sukoba.

Branje trešanja

Format:

 git cherry-pick ..

Primjer:

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

Sjediniti

Format:

 git spajanje

Primjer:

git spajanje v3.10.74

Preporučujem da pratite sukobe u objedinjavanjima uklanjanjem # markera.

Kako riješiti sukobe

Ne možemo dati detaljni vodič za rješavanje svakog pojedinog sukoba, jer uključuje dobro poznavanje jezika C, ali evo nekoliko savjeta.

Ako se spajate, shvatite koja počiniteljica uzrokuje sukob. To možete učiniti na dva načina:

git log -pv $ (napraviti kernelversion) .. da biste dobili promjene između vaše trenutne verzije i najnovije od uzvodne verzije. Zastavica -p dat će vam promjene koje izvršava svaka obveza kako biste ih mogli vidjeti.
Pokrenite git krivnju na datoteci da biste dobili heševe svake izmjene u tom području. Zatim možete pokrenuti git show –format = fuller da vidite je li počinitelj iz mainline / stable, Googlea ili CodeAurora.

Otkrijte imate li obveze već. Neki dobavljači poput Googlea ili CAF-a pokušati će potražiti uzlazne kritične pogreške, poput popravka prljavih COW-a, a njihove bi stražnjice mogle biti u sukobu s upstream-ovim. Možete pokrenuti git log –grep = ”” i vidjeti hoće li se nešto vratiti. Ako to učinite, možete preskočiti počinjenje (ako je branje trešanja pomoću gita resetirati –hard && git cherry-pick-nastaviti) ili zanemariti sukobe (uklonite <<<<< >>>>>).
Otkrijte je li nastao povratni sloj koji je zabrljao razlučivost. Google i CAF vole podupirati određene zakrpe koje stabilna ne bi bila. Stabilni će često morati prilagoditi razlučivost glavnih obveza apscesu nekih zakrpa koje Google odluči podržati. Na glavnoj odredbi možete pogledati pokretanjem git show-a (hash glavne linije bit će dostupan u poruci završavanja stabilne obveze). Ako se pojačava povratna pomoć, možete odbaciti promjene ili možete koristiti verziju glavne linije (što je obično što trebate učiniti).
Pročitajte što pokušaj čini i provjerite je li problem već riješen. Ponekad CAF može ispraviti bug neovisan o uzvodnom toku, što znači da možete ispraviti njihov ispravak za uzvodno ili ga odbaciti, kao gore.

Inače je možda samo rezultat dodatka CAF / Google / OEM, au tom slučaju neke stvari morate pomiješati okolo.

Ovdje je zrcalo Linux-stabilnog kernel.org spremišta na GitHub-u, koje može biti lakše u potrazi za popisima počinjenja i razlikovati se za rješavanje sukoba. Preporučam da prvo pogledate popis popisa i odredite problem da biste vidjeli izvorni različak da biste ga usporedili s vašim.

Primjer URL-a: //github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

To možete učiniti i putem naredbenog retka:

 git log .. git show

Rješavanje rezolucija odnosi se na kontekst. Ono što biste Uvijek trebali učiniti je osigurati da se vaš konačni razlika podudara s uzvodnim putem tako što ćete u dva odvojena prozora pokrenuti sljedeće naredbe:

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

Omogući ponovno upotrebu

Git ima značajku koja se zove rerere (zalaže se za Ponovno ponovno snimljeno razlučivanje), što znači da kada otkrije sukob, zabilježit će kako ste ga riješili tako da ga možete ponovo koristiti kasnije. Ovo je posebno korisno za oboje kronične programere spajanja i branja trešanja jer ćete jednostavno trebati pokrenuti git add. && git - nastavite kod ponovnog postavljanja uzvodne pojave jer će se riješiti sukob kako ste ga ranije riješili.

To se može omogućiti pokretanjem sljedeće naredbe u vašem kerpo repo-u:

 git config rerere.enabled true

Kako git bisect kada naletite na prevoditelj ili greška prilikom izvođenja

S obzirom na to da ćete dodavati znatan broj stavki, vrlo je moguće da uvedete pogrešku prevoditelja ili prevoditelja. Umjesto da odustanete, pomoću gitovog ugrađenog alata za bisektstvo možete otkriti korijen uzroka problema! U idealnom slučaju ćete praviti i bljeskati svaku pojedinu verziju kernela dok je dodate, tako da će rezanje datoteka trajati manje vremena ako je potrebno, ali možete i bez problema razdvojiti 5000 počinjenja.

Ono što će napraviti git bisect je uzeti niz preuzimanja, od mjesta gdje je problem prisutan do mjesta na kojem nije bilo, a zatim počnite prepoloviti raspon počinjenja, omogućujući vam da sastavite i testirate i obavijestite je li dobro ili ne, To će nastaviti sve dok ne iskaže počinitelj koji je uzrokovao vaš problem. U tom trenutku to možete popraviti ili vratiti.

Započni biseiting: početak git bisect
Označite trenutnu reviziju kao lošu: git bisect bad
Označite reviziju kao dobra: git bisect good
Gradite s novom revizijom
Na temelju rezultata (ako je problem prisutan ili ne) recite git: git bisect good ILI git bisect bad
Isperite i ponovite korake 4-5 dok problem ne bude pronađen!
Vratite ili popravite počinjenje problema.

NAPOMENA: Spajanja će trebati privremeno pokrenuti git rebase -i kako biste primijenili sve zakrpe na vašu podružnicu radi pravilnog određivanja bisekata, jer će se bisegmanti sa mješavinama na mjestu često puta naplaćivati na pretprojektnim narudžbama, što znači da nemate nijednu Android obvezu. Mogu na ovaj zahtjev ući u više detalja, ali vjerujte mi, potrebno je. Nakon što identificirate počinjenje problema, možete ga vratiti ili ponovo uspostaviti u spajanju.

NEMOJTE smanjiti nadogradnje

Dosta novih programera dolazi u iskušenje jer je to „čistije“ i „lakše“ za upravljanje. Ovo je grozno iz nekoliko razloga:

Autorstvo je izgubljeno. Ostali programeri nisu fer da im se kredit oduzme za rad.
Dijeljenje je nemoguće. Ako iskombinirate niz obveza i nešto je problem u toj seriji, nemoguće je reći što je počinjenje prouzročilo problem u squashu.
Buduće breskve teže su. Ako se trebate ponovno sastaviti sa istisnutom serijom, teško je / nemoguće reći odakle dolazi sukob.

Pretplatite se na Linux Kernel popis za slanje radi pravovremenih ažuriranja

Da biste bili obaviješteni kad god postoji nadogradnja, pretplatite se na linux-kernel-najavni popis. To će vam omogućiti da dobijete e-poštu svaki put kada se objavi novo jezgro, tako da možete ažurirati i gurnuti što je brže moguće.