Com actualitzar el nucli d'Android a l'última versió estable de Linux

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

La part que consumeix més temps és la presentació inicial; un cop estigueu al dia, no trigarà gens a fusionar-se en una nova versió, que normalment no conté més de 100 confirmacions. Els avantatges que això comporta (més estabilitat i una millor seguretat per als vostres usuaris) haurien de necessitar aquest procés.

Com combinar el nucli estable de Linux en un nucli d’Android

Primer heu d’esbrinar quina versió del nucli està executant el vostre dispositiu Android.

Per trivial que sembli, cal saber per on heu de començar. Executeu l'ordre següent a l'arbre del nucli:

fer kernelversion

Tornarà la versió que feu servir. Els dos primers números s’utilitzaran per esbrinar la branca que necessiteu (per exemple, linux-4.4.y per a qualsevol nucli 4.4) i l’últim número s’utilitzarà per determinar quina versió heu de començar per combinar (per exemple, si esteu a 4.4) .21, fusionareu el següent 4.4.22).

Agafeu la font més recent del nucli de kernel.org

kernel.org allotja la font més recent del nucli a el dipòsit estable de Linux . A la part inferior d'aquesta pàgina, hi haurà tres enllaços de recuperació. Segons la meva experiència, el mirall de Google sol ser el més ràpid, però els vostres resultats poden variar. Executeu les ordres següents:

git remote add linux-stable https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit buscar linux-stable

Decidiu si voleu combinar el nucli sencer o seleccioneu les confirmacions

A continuació, haureu de triar si voleu combinar els commit o cherry-pick. Aquests són els avantatges i els inconvenients de cadascun i quan és possible que vulgueu fer-los.

NOTA: Si la font del nucli té la forma de tarball, és molt probable que hàgiu de fer una selecció general, en cas contrari obtindreu milers de conflictes de fitxers, ja que el git està poblant l'historial basant-se exclusivament en la versió anterior, no en el que ha canviat l'OEM o CAF Només heu de passar al pas 4.

Recol·lecció de cireres:

Pros:

• És més fàcil resoldre els conflictes, ja que sabeu exactament el conflicte que causa un problema.
• És més fàcil tornar a modificar, ja que cada lliurament es fa tot sol.
• Més fàcil de dividir en dos si es produeixen problemes

Contres:

• Es triga més, ja que cada compromís s’ha de seleccionar individualment.
• Una mica més difícil de saber si el compromís és a primera vista aigües amunt

Vaja

Pros :

• És més ràpid, ja que no cal esperar a que es fusionin tots els pegats nets.
• És més fàcil veure quan una confirmació prové del riu amunt ja que no serà el committer, serà el mantenidor del riu amunt.

Contres:

• Resoldre conflictes pot ser una mica més difícil, ja que haureu de buscar quina comissió està causant el conflicte mitjançant git log / git blame, no us ho dirà directament.
• El repassat és difícil ja que no es pot tornar a crear una combinació, sinó que oferireu una selecció completa de totes les confirmacions de manera individual. Tanmateix, no hauríeu de tornar a canviar de freqüència sovint, en lloc d’utilitzar git revert i git merge sempre que sigui possible.

Recomanaria fer una selecció general per esbrinar qualsevol conflicte de problemes inicialment, fer una combinació i, a continuació, revertir els compromisos del problema després perquè l'actualització sigui més fàcil (ja que la fusió és més ràpida després d'estar actualitzada).

Afegiu les confirmacions al vostre origen, una versió cada vegada

La part més important d’aquest procés és la versió única a la vegada. POT haver-hi un pedaç de problemes a la vostra sèrie ascendent, que podria causar problemes d’arrencada o trencar alguna cosa com el so o la càrrega (s’explica a la secció de consells i trucs). Fer canvis de versió incrementals és important per aquest motiu, és més fàcil trobar un problema en 50 confirmacions que més de 2000 en algunes versions. Només us recomanaria fer una combinació completa un cop hàgiu conegut tots els compromisos i resolucions de conflictes.

Recol·lecció de cireres

Format:

git cherry-pick ..

Exemple:

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

Vaja

Format:

vés a fusionar

Exemple:

git merge v3.10.74

Recomano fer un seguiment dels conflictes en els compromisos de combinació traient els # marcadors.

Com resoldre conflictes

No podem donar una guia pas a pas per resoldre tots els conflictes, ja que implica un bon coneixement del llenguatge C, però hi ha alguns consells.

Si esteu fusionant, esbrineu quina comissió està causant el conflicte. Podeu fer-ho de dues maneres:

1. git log -p v $ (make kernelversion) .. per obtenir els canvis entre la versió actual i la darrera de la versió anterior. El senyalador -p us proporcionarà els canvis fets per cada commit perquè pugueu veure-ho.
2. Executeu git blame al fitxer per obtenir els hash de cada commit a la zona. A continuació, podeu executar git show –format = fuller per veure si el committer era de mainline / stable, Google o CodeAurora.

• Esbrineu si ja teniu el commit. Alguns proveïdors com Google o CAF intentaran cercar cap amunt per detectar errors crítics, com ara la correcció Dirty COW, i els seus ports posteriors podrien entrar en conflicte amb els d’upstream. Podeu executar git log –grep = ”” i veure si retorna alguna cosa. Si ho fa, podeu ometre la confirmació (si la selecció de cirera utilitza git reset –hard && git cherry-pick –continue) o ignorar els conflictes (elimineu la<<<<<>>>>>).
• Esbrineu si hi ha hagut un backport que estorbi la resolució. A Google i a CAF els agrada fer backport de certs pegats que no serien estables. Sovint, Stable haurà d’adaptar la resolució del compromís principal a l’absència de determinats pegats que Google opta per fer backport. Podeu veure el commit principal executant git show (el hash principal estarà disponible al missatge commit del commit estable). Si hi ha un backport que l'embolica, podeu descartar els canvis o utilitzar la versió principal (que és el que normalment haureu de fer).
• Llegiu què intenta fer el commit i comproveu si el problema ja està solucionat. De vegades, CAF pot corregir un error independent de la pujada, és a dir, podeu sobreescriure la seva solució per pujar o descartar-la, com a l’anterior.

En cas contrari, pot ser només el resultat d’una incorporació de CAF / Google / OEM, en aquest cas només cal que barregeu algunes coses.

Aquí està un mirall del dipòsit de kernel.org linux-stable a GitHub, que pot ser més fàcil per buscar llistes de compromisos i diferències per a la resolució de conflictes. Recomano anar primer a la visualització de llista de commit i localitzar el commit de problemes per veure la diferència original per comparar-la amb la vostra.

URL d'exemple: https://github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

També podeu fer-ho mitjançant la línia d’ordres:

git log .. git show

Resoldre resolucions té a veure amb el context. El que heu de fer SEMPRE és assegurar-vos que les diferències finals coincideixin amb les anteriors executant les ordres següents en dues finestres diferents:

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

Activa la versió de nou

Git té una característica anomenada rerere (significa Reutilitzar la resolució enregistrada), el que significa que quan detecta un conflicte, registrarà com el vau resoldre per poder-lo tornar a utilitzar més endavant. Això és especialment útil tant per als rebasers crònics amb fusió com per a la selecció de cireres, ja que només haureu d'executar git add. && git: continueu en refer la recuperació de la pujada anterior, ja que el conflicte es resoldrà com el vau resoldre prèviament.

Es pot habilitar executant l'ordre següent al dipòsit del nucli:

git config rerere.enabled true

Com es divideix en git quan s’executa un error en el compilador o en temps d’execució

Tenint en compte que afegirà un nombre considerable de confirmacions, és molt possible que introduïu un error de compilació o d'execució. En lloc de renunciar-hi, podeu utilitzar l'eina de bisect integrada de git per esbrinar la causa arrel del problema. Idealment, anireu construint i intermitent cada versió del nucli a mesura que l'afegiu, de manera que la divisió trigarà menys temps si cal, però podeu dividir 5000 confirmacions sense cap problema.

El que farà git bisect és agafar una sèrie de confirmacions, des d'on el problema és present fins a on no era present, i després començar a reduir a la meitat l'interval de confirmacions, cosa que us permetrà construir i provar i fer-li saber si és bo o no . Continuarà fins que escupi el commit que causa el problema. En aquest moment, podeu solucionar-lo o revertir-lo.

1. Comença a dividir: comença a dividir git
2. Etiqueu la revisió actual com a mala: git bisecta malament
3. Etiqueta una revisió com a bona: git divideix bé
4. Construeix amb la nova revisió
5. Segons el resultat (si el problema és present o no), digueu a git: git bisecta bé O git bisecta malament
6. Esbandiu i repetiu els passos 4-5 fins que trobeu la confirmació del problema.
7. Reverteix o soluciona la confirmació del problema.

NOTA: Les fusions hauran d’executar temporalment git rebase -i per aplicar tots els pegats a la vostra sucursal per a una divisió adequada, ja que la divisió amb les combinacions en lloc sovint es realitza el pagament als compromisos anteriors, és a dir, que no teniu cap compromís específic d’Android. Puc aprofundir en això a petició, però confieu en mi, és necessari. Un cop hàgiu identificat la confirmació del problema, podeu revertir-la o tornar-la a incloure a la combinació.

NO aixafeu les actualitzacions aigües amunt

Molts desenvolupadors nous tenen la temptació de fer-ho, ja que és 'més net' i 'més fàcil' de gestionar. Això és terrible per algunes raons:

• L’autoria es perd. No és injust per a altres desenvolupadors que se’ls restringeixi el seu treball.
• Bisecar és impossible. Si elimineu una sèrie de confirmacions i alguna cosa és un problema d’aquesta sèrie, és impossible saber quina confirmació va causar un problema en una carbassa.
• Les futures recerques són més difícils. Si heu de tornar a fer servir una sèrie aixafada, és difícil / impossible saber d’on resulta un conflicte.

Subscriviu-vos a la llista de correu del nucli Linux per obtenir actualitzacions oportunes

Per rebre notificacions sempre que hi hagi una actualització ascendent, subscriviu-vos a la llista linux-kernel-announce . Això us permetrà rebre un correu electrònic cada vegada que es publiqui un nucli nou perquè pugueu actualitzar i empènyer el més ràpidament possible.