So aktualisieren Sie Ihren Android-Kernel auf den neuesten Linux Stable
Bitte wissen Sie, dass dies ist fortgeschritten Zeug – Wenn Sie noch nie zuvor einen Kernel kompiliert haben, sollten Sie die oben verlinkte Anleitung „So erstellen Sie einen benutzerdefinierten Kernel“ befolgen. In diesem Handbuch werden Commits aus dem neuesten Linux-stabilen Kernel mit Ihrem Android-Kernel ausgewählt und zusammengeführt bevor Sie es kompilieren.
Das Upstreaming Ihres Android-Kernels auf den neuesten Linux-Stable bietet viele positive Vorteile, z. B. die Aktualisierung der neuesten Sicherheitsverpflichtungen und Bugfixes. Einige der Vor- und Nachteile werden später in diesem Handbuch erläutert.
Was ist ein Linux-stabiler Kernel?
Wie der Name schon sagt, ist Linux-Stable der stabile Arm des Linux-Kernels. Der andere Arm ist als “Hauptschnur” bekannt Hauptzweig. Die gesamte Linux-Kernel-Entwicklung erfolgt in der Hauptzeile und folgt im Allgemeinen diesem Prozess:
- Linus Torvalds wird zwei Wochen lang ein paar Patches von seinen Betreuern nehmen.
- Nach diesen zwei Wochen gibt er einen rc1-Kernel (z. B. 4.14-rc1) frei.
- Für jede Woche für die nächsten 6-8 Wochen wird er einen weiteren RC-Kernel (z. B. 4.14-rc2, 4.14-rc3 usw.) veröffentlichen, der NUR Fehler- und Regressionskorrekturen enthält.
- Sobald es als stabil eingestuft ist, wird es als Tarball zum Download auf veröffentlicht org(zB 4.14).
Was sind LTS-Kernel?
Jedes Jahr wählt Greg einen Kernel aus und wartet ihn entweder zwei Jahre (LTS) oder sechs Jahre (erweiterte LTS). Diese sind für Produkte konzipiert, die Stabilität benötigen (wie Android-Telefone oder andere IOT-Geräte). Der Vorgang ist genau der gleiche wie oben, er dauert nur länger. Derzeit gibt es sechs LTS-Kernel (die immer angezeigt werden können Die Veröffentlichungsseite von kernel.org):
Welche Vorteile bietet das Upstreaming meines Android-Kernels auf Linux Stable?
Wenn wichtige Schwachstellen aufgedeckt / behoben werden, sind die stabilen Kernel die ersten, die sie erhalten. Somit ist Ihr Android-Kernel viel sicherer gegen Angriffe, Sicherheitslücken und nur Fehler im Allgemeinen.
Der Linux-Stable enthält Korrekturen für viele Treiber, die mein Android-Gerät nicht verwendet. Ist dies nicht meistens unnötig?
Ja und Nein, je nachdem, wie Sie “meistens” definieren. Der Linux-Kernel enthält möglicherweise viel Code, der im Android-System nicht verwendet wird. Dies garantiert jedoch nicht, dass beim Zusammenführen neuer Versionen keine Konflikte mit diesen Dateien auftreten! Verstehe das virtuell niemand Erstellt jeden einzelnen Teil des Kernels, nicht einmal die gängigsten Linux-Distributionen wie Ubuntu oder Mint. Dies bedeutet nicht, dass Sie diese Korrekturen nicht vornehmen sollten, weil dort SIND Korrekturen für Treiber Sie MACHEN Lauf. Nehmen wir zum Beispiel arm / arm64 und ext4, die die am häufigsten verwendete Android-Architektur bzw. das häufigste Dateisystem sind. In 4.4, von 4.4.78 (Version des neuesten Oreo CAF-Tags) bis 4.4.121 (neuestes Upstream-Tag), sind dies die folgenden Nummern für die Commits dieser Systeme:
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
Der zeitaufwändigste Teil ist das anfängliche Aufrufen; Sobald Sie auf dem neuesten Stand sind, dauert es nicht lange, bis eine neue Version zusammengeführt wird, die normalerweise nicht mehr als 100 Commits enthält. Die damit verbundenen Vorteile (mehr Stabilität und bessere Sicherheit für Ihre Benutzer) sollten diesen Prozess jedoch erforderlich machen.
So führen Sie den stabilen Linux-Kernel zu einem Android-Kernel zusammen
Zuerst müssen Sie herausfinden, welche Kernel-Version auf Ihrem Android-Gerät ausgeführt wird.
So trivial dies auch erscheint, es ist notwendig zu wissen, wo Sie beginnen müssen. Führen Sie den folgenden Befehl in Ihrem Kernelbaum aus:
make kernelversion
Es wird die Version zurückgeben, auf der Sie sich befinden. Die ersten beiden Zahlen werden verwendet, um den Zweig zu ermitteln, den Sie benötigen (z. B. Linux-4.4.y für einen beliebigen 4.4-Kernel), und die letzte Zahl wird verwendet, um zu bestimmen, welche Version Sie mit dem Zusammenführen beginnen müssen (z. B. wenn Sie 4.4 verwenden) .21, Sie werden als nächstes 4.4.22 zusammenführen).
Holen Sie sich die neueste Kernelquelle von kernel.org
kernel.org beherbergt die neueste Kernelquelle in das Linux-stabile Repository. Am Ende dieser Seite befinden sich drei Abruflinks. Nach meiner Erfahrung ist der Spiegel von Google in der Regel der schnellste, aber Ihre Ergebnisse können variieren. Führen Sie die folgenden Befehle aus:
git remote add linux-stable https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit fetch linux-stable
Entscheiden Sie, ob Sie den gesamten Kernel zusammenführen oder die Commits auswählen möchten
Als Nächstes müssen Sie auswählen, ob Sie die Commits oder Cherry-Pick zusammenführen möchten. Hier sind die Vor- und Nachteile der einzelnen und wann Sie sie tun möchten.
HINWEIS: Wenn Ihre Kernelquelle die Form eines Tarballs hat, müssen Sie höchstwahrscheinlich eine Auswahl treffen, andernfalls treten Tausende von Dateikonflikten auf, da git den Verlauf nur auf der Grundlage des Upstreams auffüllt und nicht auf der Grundlage dessen, was der OEM oder CAF geändert hat. Fahren Sie einfach mit Schritt 4 fort.
Rosinenpickerei:
Vorteile:
- Einfachere Lösung von Konflikten, da Sie genau wissen, welcher Konflikt ein Problem verursacht.
- Einfacher neu zu starten, da jedes Commit für sich ist.
- Einfacher zu halbieren, wenn Probleme auftreten
Nachteile:
- Es dauert länger, da jedes Commit einzeln ausgewählt werden muss.
- Etwas schwieriger zu erkennen, ob das Commit auf den ersten Blick von oben erfolgt
Verschmelzen
Vorteile::
- Es ist schneller, da Sie nicht warten müssen, bis alle sauberen Patches zusammengeführt wurden.
- Es ist einfacher zu erkennen, wann ein Commit vom Upstream stammt, da Sie nicht der Committer, sondern der Upstream-Betreuer sind.
Nachteile:
- Das Lösen von Konflikten kann etwas schwieriger sein, da Sie mithilfe von Git-Protokoll / Git-Schuld nachschlagen müssen, welches Commit den Konflikt verursacht. Dies wird Ihnen nicht direkt mitgeteilt.
- Das erneute Basieren ist schwierig, da Sie eine Zusammenführung nicht neu starten können. Es bietet die Möglichkeit, alle Festschreibungen einzeln auszuwählen. Sie sollten jedoch nicht häufig neu gründen, sondern nach Möglichkeit git revert und git merge verwenden.
Ich würde empfehlen, zunächst eine Auswahl zu treffen, um etwaige Problemkonflikte herauszufinden, eine Zusammenführung durchzuführen und anschließend die Commits für das Problem zurückzusetzen, damit die Aktualisierung einfacher ist (da die Zusammenführung nach der Aktualisierung schneller erfolgt).
Fügen Sie die Commits Ihrer Version nacheinander hinzu
Der wichtigste Teil dieses Prozesses ist jeweils eine Version. Möglicherweise befindet sich in Ihrer Upstream-Serie ein Problem-Patch, der zu Problemen beim Booten oder Unterbrechen von Sound oder Aufladen führen kann (siehe Abschnitt Tipps und Tricks). Aus diesem Grund ist es wichtig, inkrementelle Versionsänderungen vorzunehmen. Bei einigen Versionen ist es einfacher, ein Problem bei 50 Commits zu finden als bei mehr als 2000 Commits. Ich würde eine vollständige Zusammenführung nur empfehlen, wenn Sie alle Problem-Commits und Konfliktlösungen kennen.
Rosinenpickerei
Format:
git cherry-pick <previous_tag>..<next_tag>
Beispiel:
Git Cherry-Pick v3.10.73..v3.10.74
Verschmelzen
Format:
git merge <next_tag>
Beispiel:
git merge v3.10.74
Ich empfehle, die Konflikte bei Zusammenführungs-Commits durch Entfernen der # -Markierungen zu verfolgen.
So lösen Sie Konflikte
Wir können keine schrittweise Anleitung zur Lösung jedes einzelnen Konflikts geben, da dies gute Kenntnisse der C-Sprache erfordert, aber hier einige Hinweise.
Wenn Sie zusammenführen, finden Sie heraus, welches Commit den Konflikt verursacht. Sie können dies auf zwei Arten tun:
- git log -pv $ (Kernelversion erstellen) ..
, um die Änderungen zwischen Ihrer aktuellen Version und der neuesten Version vom Upstream abzurufen. Das Flag -p gibt Ihnen die Änderungen an, die bei jedem Commit vorgenommen wurden, damit Sie sehen können. - Führen Sie Git-Schuld auf die Datei aus, um die Hashes jedes Commits in dem Bereich zu erhalten. Sie können dann git show –format = fuller ausführen, um festzustellen, ob der Committer von Mainline / Stable, Google oder CodeAurora stammt.
- Finden Sie heraus, ob Sie das Commit bereits haben. Einige Anbieter wie Google oder CAF werden versuchen, Upstream nach kritischen Fehlern zu suchen, wie z. B. das Dirty COW-Update, und ihre Backports können mit den Upstreams in Konflikt stehen. Sie können git log –grep = ”
” ausführen und prüfen, ob etwas zurückgegeben wird. Wenn dies der Fall ist, können Sie das Commit überspringen (wenn Sie mit git reset –hard && git cherry-pick –continue auswählen) oder die Konflikte ignorieren (entfernen Sie das <<<<<< und alles zwischen ======) und >>>>>>). - Finden Sie heraus, ob es einen Backport gibt, der die Auflösung durcheinander bringt. Google und CAF portieren gerne bestimmte Patches zurück, die stabil nicht funktionieren würden. Stable muss häufig die Auflösung des Mainline-Commits an das Fehlen bestimmter Patches anpassen, die Google für den Backport wählt. Sie können sich das Mainline-Commit ansehen, indem Sie git show
ausführen (der Mainline-Hash ist in der Commit-Nachricht des stabilen Commits verfügbar). Wenn ein Backport es vermasselt, können Sie entweder die Änderungen verwerfen oder die Hauptversion verwenden (was normalerweise der Fall ist). - Lesen Sie, was das Commit versucht, und prüfen Sie, ob das Problem bereits behoben ist. Manchmal kann CAF einen Fehler beheben, der vom Upstream unabhängig ist, was bedeutet, dass Sie entweder den Fix für Upstreams überschreiben oder ihn wie oben verwerfen können.
Andernfalls ist dies möglicherweise nur ein Ergebnis einer CAF / Google / OEM-Erweiterung. In diesem Fall müssen Sie nur einige Dinge durcheinander bringen.
Hier ist ein Spiegel des linux-stabilen kernel.org-Repositorys auf GitHub, was das Nachschlagen von Commit-Listen und Diffs zur Konfliktlösung einfacher machen kann. Ich empfehle, zuerst in die Commit-Listenansicht zu wechseln und das Problem-Commit zu suchen, um das ursprüngliche Diff zu sehen und es mit Ihrem zu vergleichen.
Beispiel-URL: https://github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c
Sie können dies auch über die Befehlszeile tun:
git log <current_version>..<version_being_added> <path> git show <hash>
Beim Lösen von Auflösungen dreht sich alles um den Kontext. Was Sie IMMER tun sollten, ist sicherzustellen, dass Ihr endgültiges Diff mit dem Upstream übereinstimmt, indem Sie die folgenden Befehle in zwei separaten Fenstern ausführen:
git diff HEAD git diff v$(make kernelversion)..$(git tag --sort=-taggerdate -l v$(make kernelversion | cut -d . -f 1,2)* | head -n1)
Aktivieren Sie Rerere
Git hat eine Funktion namens rerere (steht für Reuse Recorded Resolution). Wenn ein Konflikt erkannt wird, wird aufgezeichnet, wie Sie ihn gelöst haben, damit Sie ihn später wiederverwenden können. Dies ist besonders hilfreich für beide chronischen Rebaser, die sowohl verschmelzen als auch Kirschen pflücken, da Sie nur git add ausführen müssen. && git
Sie kann aktiviert werden, indem Sie den folgenden Befehl in Ihrem Kernel-Repo ausführen:
git config rerere.enabled true
Wie man halbiert, wenn man auf einen Compiler oder einen Laufzeitfehler stößt
Da Sie eine beträchtliche Anzahl von Commits hinzufügen, ist es sehr gut möglich, dass Sie einen Compiler- oder Laufzeitfehler einführen. Anstatt einfach aufzugeben, können Sie das in git integrierte Halbierungswerkzeug von git verwenden, um die Hauptursache des Problems herauszufinden! Im Idealfall erstellen und flashen Sie jede einzelne Kernel-Version, während Sie sie hinzufügen, sodass das Halbieren bei Bedarf weniger Zeit in Anspruch nimmt, Sie jedoch 5000 Commits ohne Probleme halbieren können.
Git Bisect führt eine Reihe von Commits durch, von dem Ort, an dem das Problem vorliegt, bis zu dem Ort, an dem es nicht vorhanden war, und halbiert dann den Commit-Bereich, sodass Sie ihn erstellen, testen und wissen lassen können, ob er gut ist oder nicht . Dies wird so lange fortgesetzt, bis das Commit, das Ihr Problem verursacht, ausgespuckt wird. An diesem Punkt können Sie es entweder reparieren oder zurücksetzen.
- Beginnen Sie mit der Halbierung: Start der Git-Halbierung
- Beschriften Sie die aktuelle Version als schlecht: git bisect bad schlecht
- Kennzeichnen Sie eine Revision als gut: git bisect good
- Erstellen Sie mit der neuen Version
- Sagen Sie git basierend auf dem Ergebnis (ob das Problem vorliegt oder nicht) git: git bisect gut ODER git bisect schlecht
- Spülen und wiederholen Sie die Schritte 4 bis 5, bis das Problem festgeschrieben ist!
- Setzen Sie das Problem-Commit zurück oder beheben Sie es.
HINWEIS: Fusionen müssen vorübergehend git rebase -i
Squash-Upstream-Updates NICHT
Viele neue Entwickler sind versucht, dies zu tun, da es „sauberer“ und „einfacher“ zu verwalten ist. Das ist aus mehreren Gründen schrecklich:
- Die Urheberschaft geht verloren. Es ist unfair gegenüber anderen Entwicklern, wenn ihre Kredite für ihre Arbeit gestrichen werden.
- Eine Halbierung ist unmöglich. Wenn Sie eine Reihe von Commits quetschen und etwas in dieser Serie ein Problem darstellt, ist es unmöglich zu sagen, welches Commit ein Problem bei einem Squash verursacht hat.
- Zukünftige Kirschpicks sind schwieriger. Wenn Sie mit einer gequetschten Serie neu aufbauen müssen, ist es schwierig / unmöglich zu sagen, woher ein Konflikt stammt.
Abonnieren Sie die Linux Kernel-Mailingliste für zeitnahe Updates
Abonnieren Sie, um benachrichtigt zu werden, wenn ein Upstream-Update vorliegt die Linux-Kernel-Announce-Liste. Auf diese Weise erhalten Sie jedes Mal eine E-Mail, wenn ein neuer Kernel veröffentlicht wird, damit Sie so schnell wie möglich aktualisieren und pushen können.
