Hoe u uw Android-kernel bijwerkt naar de nieuwste Linux-stabiele

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

Het meest tijdrovende deel is het eerste gesprek; als je eenmaal helemaal up-to-date bent, kost het geen tijd om samen te voegen in een nieuwe release, die meestal niet meer dan 100 commits bevat. De voordelen die dit met zich meebrengt (meer stabiliteit en betere beveiliging voor uw gebruikers) zouden dit proces echter noodzakelijk moeten maken.

Hoe Linux stabiele kernel samen te voegen in een Android-kernel

Eerst moet u erachter komen welke kernelversie uw Android-apparaat gebruikt.

Hoe triviaal dit ook lijkt, het is noodzakelijk om te weten waar u moet beginnen. Voer het volgende commando uit in je kernelboom:

maak kernelversion

Het keert terug naar de versie die u gebruikt. De eerste twee nummers zullen worden gebruikt om erachter te komen welke branch je nodig hebt (bijv. Linux-4.4.y voor elke 4.4 kernel) en het laatste nummer zal worden gebruikt om te bepalen welke versie je nodig hebt om te beginnen met samenvoegen (bijv. Als je op 4.4 .21, hierna voegt u 4.4.22 samen).

Pak de nieuwste kernelbron van kernel.org

kernel.org herbergt de nieuwste kernel-bron in de linux-stabiele repository . Onderaan die pagina staan ​​drie ophaallinks. In mijn ervaring is de spiegel van Google meestal de snelste, maar uw resultaten kunnen variëren. Voer de volgende opdrachten uit:

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

Beslis of je de hele kernel wilt mergen of kies voor de commits

Vervolgens moet je kiezen of je de commits of cherry-pick wilt samenvoegen. Hier zijn de voor- en nadelen van elk en wanneer u ze misschien wilt doen.

NOTITIE: Als je kernel source de vorm heeft van een tarball, zul je hoogstwaarschijnlijk moeten cherry-picken, anders krijg je duizenden bestandsconflicten omdat git de geschiedenis vult op basis van puur stroomopwaarts, niet wat de OEM of CAF heeft veranderd. Ga gewoon door naar stap 4.

De krenten uit de pap halen:

Voordelen:

• Makkelijker om conflicten op te lossen, omdat u precies weet welk conflict een probleem veroorzaakt.
• Makkelijker te rebasen omdat elke commit op zichzelf staat.
• Gemakkelijker te splitsen als u problemen tegenkomt

Nadelen:

• Het duurt langer omdat elke commit afzonderlijk moet worden gekozen.
• Iets moeilijker te zeggen of commit op het eerste gezicht van stroomopwaarts is

Gaan

Voordelen :

• Het is sneller omdat u niet hoeft te wachten tot alle schone patches zijn samengevoegd.
• Het is gemakkelijker om te zien wanneer een commit van upstream komt, aangezien je niet de committer bent, maar de upstream onderhouder.

Nadelen:

• Het oplossen van conflicten kan wat moeilijker zijn omdat je met git log / git blame moet opzoeken welke commit het conflict veroorzaakt, het zal je niet direct vertellen.
• Rebasen is moeilijk omdat je een merge niet kunt rebasen, het zal aanbieden om alle commit afzonderlijk te cherry-picken. Je zou echter niet vaak moeten rebasen, in plaats daarvan git revert en git merge gebruiken waar mogelijk.

Ik zou aanraden om een ​​cherry-pick te doen om aanvankelijk eventuele probleemconflicten te achterhalen, een merge uit te voeren, en daarna de probleemcommits terug te draaien, zodat updaten gemakkelijker is (aangezien het samenvoegen sneller gaat nadat het up-to-date is).

Voeg de commits toe aan uw broncode, één versie per keer

Het belangrijkste onderdeel van dit proces is het gedeelte met één versie tegelijk. Er is MOGELIJK een probleempatch in uw upstream-serie, die een probleem met het opstarten kan veroorzaken of iets zoals geluid of opladen kan breken (uitgelegd in het gedeelte met tips en trucs). Het aanbrengen van incrementele versiewijzigingen is daarom belangrijk, het is gemakkelijker om een ​​probleem te vinden in 50 commits dan meer dan 2000 commits voor sommige versies. Ik zou alleen aanraden om een ​​volledige samenvoeging uit te voeren als je alle problemen en conflictoplossingen kent.

De krenten uit de pap halen

Formaat:

git cherry-pick ..

Voorbeeld:

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

Gaan

Formaat:

ga samenvoegen

Voorbeeld:

git merge v3.10.74

Ik raad aan om de conflicten in merge-commits bij te houden door de # -markeringen te verwijderen.

Conflicten oplossen

We kunnen geen stapsgewijze handleiding geven voor het oplossen van elk afzonderlijk conflict, aangezien het een goede kennis van de C-taal vereist, maar hier zijn een paar tips.

Als je aan het mergen bent, zoek dan uit welke commit het conflict veroorzaakt. U kunt dit op twee manieren doen:

1. git log -p v $ (make kernelversion) .. om de veranderingen tussen je huidige versie en de laatste upstream te krijgen. De vlag -p geeft je de veranderingen die door elke commit zijn gedaan, zodat je ze kunt zien.
2. Voer git blame uit op het bestand om de hashes van elke commit in het gebied te krijgen. Je kunt dan git show –format = fuller draaien om te zien of de committer afkomstig was van mainline / stable, Google of CodeAurora.

• Zoek uit of je de commit al hebt. Sommige leveranciers zoals Google of CAF zullen proberen stroomopwaarts te zoeken naar kritieke bugs, zoals de Dirty COW-oplossing, en hun backports kunnen conflicteren met stroomopwaartse bugs. Je kunt git log –grep = ”” uitvoeren en kijken of het iets teruggeeft. Als dat het geval is, kun je de commit overslaan (als cherry-picking met git reset –hard && git cherry-pick –continue) of de conflicten negeren (verwijder de<<<<<>>>>>).
• Zoek uit of er een backport is die de resolutie verpest. Google en CAF willen graag bepaalde patches ondersteunen die stabiel niet zouden zijn. Stable zal vaak de resolutie van de mainline commit moeten aanpassen aan het ontbreken van bepaalde patches die Google ervoor kiest om te backporteren. Je kunt de mainline commit bekijken door git show uit te voeren (de mainline hash zal beschikbaar zijn in het commit bericht van de stabiele commit). Als er een backport is die het verprutst, kun je de wijzigingen negeren of je kunt de hoofdversie gebruiken (wat je normaal gesproken moet doen).
• Lees wat de commit probeert te doen en kijk of het probleem al is opgelost. Soms kan CAF een bug onafhankelijk van upstream repareren, wat betekent dat u hun fix voor upstream's kunt overschrijven of weggooien, zoals hierboven.

Anders kan het gewoon het resultaat zijn van een CAF / Google / OEM-toevoeging, in welk geval je gewoon wat dingen hoeft te schudden.

Hier is een spiegel van de linux-stabiele kernel.org-repository op GitHub, wat gemakkelijker kan zijn voor het opzoeken van commit-lijsten en diffs voor conflictoplossing. Ik raad aan om eerst naar de vastleglijstweergave te gaan en de probleembevestiging te lokaliseren om de originele diff te zien en deze te vergelijken met de jouwe.

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

U kunt het ook doen via de opdrachtregel:

git log .. git show

Het oplossen van resoluties heeft alles te maken met context. Wat je ALTIJD moet doen, is ervoor zorgen dat je uiteindelijke diff overeenkomt met stroomopwaarts door de volgende opdrachten in twee afzonderlijke vensters uit te voeren:

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

Schakel opnieuw in

Git heeft een functie genaamd rerere (staat voor Reuse Recorded Resolution), wat betekent dat wanneer het een conflict detecteert, het zal registreren hoe je het hebt opgelost, zodat je het later opnieuw kunt gebruiken. Dit is vooral handig voor zowel chronische rebasers met zowel merging als cherry-picking, aangezien je alleen git add hoeft uit te voeren. && git - ga door bij het opnieuw uitvoeren van de upstream-weergave, aangezien het conflict zal worden opgelost zoals je het eerder hebt opgelost.

Het kan worden ingeschakeld door het volgende commando uit te voeren in je kernel-repo:

git config rerere.enabled true

Hoe git bisect te gebruiken bij het tegenkomen van een compiler of runtime-fout

Aangezien je een aanzienlijk aantal commits gaat toevoegen, is het heel goed mogelijk dat je een compiler- of runtime-fout introduceert. In plaats van gewoon op te geven, kun je de ingebouwde tool van Git gebruiken om de hoofdoorzaak van het probleem te achterhalen! Idealiter zul je elke afzonderlijke kernelversie bouwen en flashen terwijl je deze toevoegt, zodat het in tweeën delen minder tijd kost indien nodig, maar je kunt zonder problemen 5000 commits in tweeën delen.

Wat git bisect zal doen is een reeks commits aannemen, van waar het probleem aanwezig is tot waar het niet aanwezig was, en dan beginnen met het halveren van het commit-bereik, waardoor je kunt bouwen en testen en het laten weten of het goed is of niet . Het zal hiermee doorgaan totdat het de commit uitspuugt die je probleem veroorzaakt. Op dat moment kunt u het repareren of terugdraaien.

1. Begin in twee delen: git bisect start
2. Label de huidige revisie als slecht: git bisect bad
3. Label een revisie als goed: git bisect good
4. Bouw met de nieuwe revisie
5. Op basis van het resultaat (als het probleem aanwezig is of niet), vertel git: git bisect good OF git bisect bad
6. Spoel en herhaal stap 4-5 totdat de probleemcommissie is gevonden!
7. Herstel of herstel de probleemcommissie.

NOTITIE: Mergers zullen tijdelijk git rebase -i moeten uitvoeren om alle patches op je branch toe te passen voor een juiste doorsnijding, aangezien het halveren met de merges op zijn plaats vaak het afrekenen naar de upstream commits zal vertragen, wat betekent dat je geen van de Android-specifieke commits hebt. Ik kan hier op verzoek dieper op ingaan, maar geloof me, het is nodig. Als je eenmaal de probleemcommit hebt geïdentificeerd, kun je het terugdraaien of rebasen in de merge.

Plet de upstream-updates NIET

Veel nieuwe ontwikkelaars komen in de verleiding om dit te doen omdat het 'schoner' en 'gemakkelijker' te beheren is. Dit is om een ​​paar redenen vreselijk:

• Het auteurschap is verloren. Het is oneerlijk jegens andere ontwikkelaars om hun krediet op te schorten voor hun werk.
• Doorsnijden is onmogelijk. Als je een reeks commits squasht en er is iets een probleem in die reeks, is het onmogelijk om te zeggen welke commit een probleem veroorzaakte bij een squash.
• Toekomstige cherry-picks zijn moeilijker. Als je moet rebasen met een geplette serie, is het moeilijk / onmogelijk om te zeggen waar een conflict vandaan komt.

Abonneer u op de Linux Kernel-mailinglijst voor tijdige updates

Als u een melding wilt ontvangen wanneer er een upstream-update is, abonneert u zich op de linux-kernel-aankondigingslijst . Hierdoor kun je elke keer dat er een nieuwe kernel wordt uitgebracht een e-mail ontvangen, zodat je zo snel mogelijk kunt updaten en pushen.