Generisches Kernel-Image

Die Android Gemeinsame Kerneln (ACKs) sind die Basis für alle Android - Produkt - Kernel. Hersteller- und Gerätekernel sind ACKs nachgelagert. Anbieter fügen Unterstützung für SoCs und Peripheriegeräte hinzu, indem sie den Kernel-Quellcode ändern und Gerätetreiber hinzufügen. Diese Modifikationen können umfangreich sein, bis zu dem Punkt , dass so viel wie 50% des Codes auf einem Gerät ausgeführt wird , out-of-Baum - Code (nicht von stromaufwärts oder Linux aus AOSP gemeinsamer Kernel).

Somit besteht ein Gerätekernel aus:

  • Upstream: Der Linux-Kernel von kernel.org
  • AOSP: Zusätzliche Android-spezifische Patches von AOSP-Gemeinsamen Kerneln
  • Anbieter: SoC- und Peripherie-Aktivierungs- und Optimierungspatches von Anbietern
  • OEM/Gerät: Zusätzliche Gerätetreiber und Anpassungen

Fast jedes Gerät verfügt über einen benutzerdefinierten Kernel. Das ist Kernel-Fragmentierung.

Android-Kernel-Hierarchie führt zu Fragmentierung

Abbildung 1. Android kernel Hierarchie führt zu einer Fragmentierung

Die Kosten der Fragmentierung

Die Kernel-Fragmentierung hat mehrere negative Auswirkungen auf die Android-Community.

Sicherheitsupdates sind arbeitsintensiv

Sicherheits - Patches zitiert im Android Security Bulletin (ASB) muss in jedem der Geräte Kernel zurückportiert werden. Aufgrund der Kernel-Fragmentierung ist es jedoch unerschwinglich, Sicherheitskorrekturen auf Android-Geräten im Feld zu verbreiten.

Schwierig, langfristig unterstützte Updates zusammenzuführen

Das Long-Term unterstützt (LTS) Versionen enthalten Sicherheitsupdates und andere kritische Fehlerbehebung. Bei LTS-Versionen auf dem neuesten Stand zu bleiben, hat sich als der effektivste Weg erwiesen, um Sicherheitskorrekturen bereitzustellen. Auf Pixel-Geräten wurde festgestellt, dass 90% der im ASB gemeldeten Kernel-Sicherheitsprobleme bereits für Geräte behoben wurden, die auf dem neuesten Stand bleiben.

Bei all den benutzerdefinierten Modifikationen in den Gerätekerneln ist es jedoch schwierig, die LTS-Fixes einfach in die Gerätekernel einzufügen.

Verhindert Upgrades der Android-Plattform-Version

Die Fragmentierung erschwert neue Android-Funktionen, die Kernel-Änderungen an Geräten im Feld erfordern. Der Android-Framework-Code muss davon ausgehen, dass bis zu fünf Kernel-Versionen unterstützt werden und keine Kernel-Änderungen für die neue Plattformversion vorgenommen wurden (Android 10 unterstützt die Kernel 3.18, 4.4, 4.9, 4.14 und 4.19, die in einigen Fällen nicht vorhanden waren seit Android 8 im Jahr 2017 um neue Funktionen erweitert).

Es ist schwierig, Kernel-Änderungen zurück zu Upstream-Linux beizutragen

Mit allen Änderungen am Kernel werden die meisten Flaggschiff-Geräte mit einer Kernel-Version ausgeliefert, die bereits mindestens 18 Monate alt ist. Zum Beispiel wurde die 4,14 - Kernel veröffentlicht kernel.org im November 2017 und die ersten Android - Handys mit 4.14 Kernel im Frühjahr 2019 ausgeliefert.

Diese lange Verzögerung zwischen der Veröffentlichung des Upstream-Kernels und den Produkten erschwert es der Android-Community, benötigte Funktionen und Treiber in die Upstream-Kernel einzuspeisen, sodass es schwierig ist, das Fragmentierungsproblem zu beheben.

Behebung der Fragmentierung: Generic Kernel Image

Die generische Kernel - Image (GKI) Projektes Adressen Kernel Fragmentierung durch die Core - Kernel Vereinheitlichung und SoC und Board Support aus dem Core - Kernel in ladbare Module zu bewegen. Die GKI Kernel stellt eine stabile Kernel - Modul - Schnittstelle (KMI) für Kernel - Module, so Module und Kernel unabhängig aktualisiert werden können.

Die GKI:

  • Wird aus den ACK Quellen gebaut.
  • Ist ein Single-Kernel - Binär - Plus zugeordnet ladbare Module pro Architektur, pro LTS - Release (derzeit nur arm64 für android11-5.4 und android12-5.4 ).
  • Ist mit allen Android - Plattform Versionen getestet, die für die zugeordnete ACK unterstützt werden. Es gibt keine Funktionsverschlechterung für die Lebensdauer einer GKI-Kernelversion
  • Stellt eine stabile KMI an den Fahrer innerhalb einer bestimmten LTS.
  • Enthält keine SOC- oder Board-spezifischen Code.

So sieht ein Android-Gerät mit implementierter GKI aus.

GKI-Architektur

Abbildung 2. GKI Architektur

GKI ist eine komplexe Änderung, die in mehreren Stufen eingeführt wird, beginnend mit den v5.4-Kernels in der Android 11-Plattformversion.

GKI 1.0 – GKI-Kompatibilitätsanforderungen

Bei einigen Geräten, die mit der Android 11-Plattformversion gestartet werden, erfordert die Treble-Kompatibilität GKI-Tests für Geräte mit v5.4-Kernel.

Partitionen für GKI-Kompatibilitätstests

Abbildung 3. Partitions für GKI Kompatibilitätstests

GKI Kompatibilität bedeutet , dass das Gerät der VTS und CTS-on-GSI + GKI Tests mit dem generischen System Bild (GSI) hindurchgeht und dem GKI kernel durch Blinken des GKI Boot - Image in die installierten boot - Partition und GSI Systembild in der system Die Geräte können mit einem anderen Produkt Kernel versenden und ladbare Module verwenden können , dass GKI nicht bieten. Doch sowohl das Produkt als auch GKI Kerne müssen Module aus den gleichen laden vendor_boot und vendor Partitionen. Daher müssen alle Produktkernel dieselbe Binärkernelmodulschnittstelle (KMI) haben. Anbieter können das KMI für Produktkernel erweitern, solange es mit dem GKI-KMI kompatibel bleibt. Es gibt keine Anforderung, dass Anbietermodule in GKI 1.0 entladbar sind.

GKI 1.0-Ziele

  • Führen Sie keine Regressionen in VTS oder CTS ein, wenn der Produktkernel durch den GKI-Kernel ersetzt wird.
  • Reduzieren Sie den Kernel-Wartungsaufwand für OEMs und Anbieter, um mit gängigen AOSP-Kerneln auf dem neuesten Stand zu bleiben.
  • Nehmen Sie grundlegende Android-Änderungen in Kernel auf, unabhängig davon, ob ein Gerät auf eine neue Android-Plattformversion aktualisiert oder neu gestartet wird.
  • Unterbrechen Sie niemals den Android-Benutzerbereich.
  • Trennen Sie hardwarespezifische Komponenten vom Kernel als ladbare Module.

GKI 2.0 - GKI-Produkte

Einige Geräte , dass Start mit dem Android - 12 (2021) Plattform - Release mit Kernel - Versionen V5.10 oder höher zu Schiff mit dem GKI - Kernel benötigt. Signierte Boot-Images werden zur Verfügung gestellt und regelmäßig mit LTS und kritischen Bugfixes aktualisiert. Da die Binärstabilität für das KMI aufrechterhalten wird, können diese Boot-Images ohne Änderungen an den Hersteller-Images installiert werden.

GKI 2.0-Ziele

  • Führen Sie mit GKI keine signifikanten Leistungs- oder Leistungsregressionen ein.
  • Ermöglichen Sie OEMs, Kernel-Sicherheitsfixes und Bugfixes (LTS) ohne Beteiligung des Anbieters bereitzustellen.
  • Reduzieren Sie die Kosten für die Aktualisierung der Hauptkernelversion für Geräte (z. B. von v5.10 auf den LTS-Kernel 2021).
  • Behalten Sie nur eine GKI-Kernel-Binärdatei pro Architektur bei, indem Sie die Kernel-Versionen mit einem klaren Upgrade-Prozess aktualisieren.

GKI-Design

KMI-Kernelzweige

GKI Kerne werden von den ACK KMI Kernel Zweigen gebaut, die im Detail beschrieben sind in Android Gemeinsamen Kernels . Die KMI ist eindeutig durch die Kernel - Version und die Android - Plattform - Release identifiziert, so dass die Zweige genannt werden <androidRelease>-<kernel version> . Zum Beispiel wird der 5,4 KMI Kernel Zweig für Android 11 genannt android11-5.4. Es wird erwartet , dass für Android 12 es zwei zusätzliche KMI Kerne, (nicht nur , wie das neue Verzweigung Modell in Zukunft Fortschritte zu demonstrieren begangen und gezeigt) android12-5.4 und ein zweiter Kernel auf der 5.10 LTS - Kernel veröffentlichte im Dezember basierend 2020.

KMI-Kernel-Hierarchie

Abbildung 4 zeigt die Zweighierarchie für die 5.10 KMI-Kernel. android12-5.10 ist der KMI Kernel Android 12 entspricht und android13-5.10 entspricht Android T (AOSP experimentell) (nicht verpflichtet und nur zeigen , gezeigt , wie die neue Verzweigung Modell in der Zukunft voranschreiten).

KMI-Kernel-Hierarchie für 5.10

Abbildung 4. KMI kernel Hierarchie für 5.10

Wie in 4 gezeigt, ist der KMI Zweig Zyklus durch drei Phasen: Entwicklung (DEV), die Stabilisierung (STAB), und eingefroren. Diese Phasen werden im Detail beschrieben in Android Gemeinsamen Kerneln .

Nachdem der KMI-Kernel eingefroren ist, werden keine KMI-brechenden Änderungen akzeptiert, es sei denn, es wird ein schwerwiegendes Sicherheitsproblem identifiziert, das nicht behoben werden kann, ohne das stabile KMI zu beeinträchtigen. Der Zweig bleibt während seiner gesamten Lebensdauer eingefroren.

Fehlerkorrekturen und Partnerfunktionen können in einen eingefrorenen Zweig aufgenommen werden, solange das vorhandene KMI nicht beschädigt ist. Das KMI kann mit neuen exportierten Symbolen erweitert werden, solange die Schnittstellen des aktuellen KMI nicht betroffen sind. Wenn dem KMI neue Schnittstellen hinzugefügt werden, werden sie sofort stabil und können nicht durch zukünftige Änderungen beschädigt werden.

Beispielsweise ist eine Änderung, die einer von einer KMI-Schnittstelle verwendeten Struktur ein Feld hinzufügt, nicht zulässig, da sie die Schnittstellendefinition ändert:

struct foo {
  int original_field1;
  int original_field2;
  int new_field; // Not allowed
};

int do_foo(struct foo &myarg)
{
  do_something(myarg);
}
EXPORT_SYMBOL_GPL(do_foo);

Das Hinzufügen einer neuen Funktion ist jedoch in Ordnung:

struct foo_ext {
  struct foo orig_foo;
  int new_field;
};

int do_foo2(struct foo_ext &myarg)
{
  do_something_else(myarg);
}
EXPORT_SYMBOL_GPL(do_foo2);

KMI-Stabilität

Um die GKI-Ziele zu erreichen, ist es wichtig, einen stabilen KMI für die Fahrer aufrechtzuerhalten. Der GKI-Kernel wird in binärer Form erstellt und ausgeliefert, aber vom Anbieter ladbare Module werden in einem separaten Baum erstellt. Der resultierende GKI-Kernel und die Module müssen so funktionieren, als wären sie zusammen gebaut worden. Für GKI-Kompatibilitätstests wird das Boot-Image, das den Kernel enthält, durch ein Boot-Image ersetzt, das den GKI-Kernel enthält, und die ladbaren Module im Hersteller-Image müssen mit jedem Kernel korrekt funktionieren.

Der KMI enthält nicht alle Symbole im Kernel oder sogar alle der über 30.000 exportierten Symbole. Stattdessen werden die Symbole, die von Modulen verwendet werden können, explizit in einem Satz von Symbollistendateien aufgelistet, die öffentlich im Stamm des Kernelbaums verwaltet werden. Die Vereinigung aller Symbole in allen Symbollistendateien definiert den als stabil gehaltenen Satz von KMI-Symbolen. Ein Beispiel Symbolliste Datei ist abi_gki_aarch64_db845c , die die Symbole für die erforderliche erklärt Dragon 845c .

Nur die in einer Symbolliste aufgeführten Symbole und ihre zugehörigen Strukturen und Definitionen werden als Teil des KMI betrachtet. Sie können Änderungen an Ihren Symbollisten vornehmen, wenn die von Ihnen benötigten Symbole nicht vorhanden sind. Nachdem sich neue Schnittstellen in einer Symbolliste befinden und somit Teil der KMI-Beschreibung sind, werden sie als stabil gehalten und dürfen nach dem Einfrieren des Zweigs nicht aus der Symbolliste entfernt oder geändert werden.

Jeder KMI-Kernelbaum hat seinen eigenen Satz von Symbollisten. Es wird nicht versucht, ABI-Stabilität zwischen verschiedenen KMI-Kernelzweigen bereitzustellen. Zum Beispiel kann die KMI für android11-5.4 ist völlig unabhängig von der KMI für android12-5.4 .

Im Allgemeinen hat die Linux - Community auf dem Begriff der im Kernel ABI Stabilität stirnrunzelnd für den Mainline - Kernel. Angesichts unterschiedlicher Toolchains, Konfigurationen und eines sich ständig weiterentwickelnden Linux-Mainline-Kernels ist es nicht möglich, einen stabilen KMI in Mainline aufrechtzuerhalten. Dies ist jedoch in der stark eingeschränkten GKI-Umgebung möglich. Die Einschränkungen sind:

  • Die KMI ist nur dann stabil innerhalb der gleichen LTS kernel (beispielsweise android11-5.4 ).
    • Keine KMI Stabilität wird für beibehalten android-mainline .
  • Nur die spezifische Clang Werkzeugkette in AOSP zugeführt , und für den entsprechenden Zweig definiert ist , für den Aufbau von Kernel und Modulen verwendet.
  • Nur Symbole, von denen bekannt ist, dass sie von Modulen verwendet werden, wie in einer Symbolliste angegeben, werden auf Stabilität überwacht und als KMI-Symbole berücksichtigt.
    • Daraus ergibt sich, dass Module nur KMI-Symbole verwenden dürfen. Dies wird durch fehlgeschlagene Modulladevorgänge erzwungen, wenn Nicht-KMI-Symbole erforderlich sind.
  • Nachdem der KMI-Zweig eingefroren wurde, können keine Änderungen den KMI zerstören, einschließlich:
    • Konfigurationsänderungen
    • Kernel-Code-Änderungen
    • Toolchain-Änderungen (einschließlich Updates)

KMI-Überwachung

ABI Monitoring - Tools überwachen KMI Stabilität während preSubmit Tests. Änderungen, die das KMI verletzen, bestehen beim Pre-Submit-Test nicht und müssen überarbeitet werden, um kompatibel zu sein. Diese Tools stehen Partnern und der Öffentlichkeit zur Integration in ihre Build-Prozesse zur Verfügung. Das Android-Kernel-Team verwendet diese Tools, um KMI-Brüche während der Entwicklung und beim Zusammenführen von LTS-Versionen zu finden. Wenn während einer LTS-Zusammenführung ein KMI-Bruch erkannt wird, wird der KMI beibehalten, indem entweder die störenden Patches entfernt oder die Patches so umgestaltet werden, dass sie kompatibel sind.

Der KMI gilt als defekt, wenn ein vorhandenes KMI-Symbol auf inkompatible Weise geändert wird. Beispiele:

  • Neues Argument zu einer KMI-Funktion hinzugefügt
  • Neues Feld zu einer Struktur hinzugefügt, die von einer KMI-Funktion verwendet wird
  • Neuer Aufzählungswert hinzugefügt, der die Werte von Aufzählungen ändert, die von einer KMI-Funktion verwendet werden
  • Konfigurationsänderung, die das Vorhandensein von Datenelementen ändert, die sich auf das KMI auswirken

Das Hinzufügen neuer Symbole unterbricht nicht unbedingt KMI, aber neue Symbole, die verwendet werden, müssen einer Symbolliste und der ABI-Darstellung hinzugefügt werden. Anderenfalls werden zukünftige Änderungen an diesem Teil des KMI nicht anerkannt.

Von Partnern wird erwartet, dass sie die ABI-Überwachungstools verwenden, um den KMI zwischen ihrem Produktkernel und dem GKI-Kernel zu vergleichen und sicherzustellen, dass sie kompatibel sind.

Die neueste android11-5.4 binäre GKI Kernel kann heruntergeladen werden unter ci.android.com ( kernel_aarch64 baut).

Einzel-Compiler

Eine Compiler-Änderung kann das interne Kernel-Datenstruktur-Layout ändern, das sich auf die ABI auswirkt. Da es wichtig ist, das KMI stabil zu halten, muss die zum Erstellen des GKI-Kernels verwendete Toolchain vollständig mit der Toolchain kompatibel sein, die zum Erstellen von Anbietermodulen verwendet wird. Der GKI-Kernel wird mit der in AOSP enthaltenen LLVM-Toolchain erstellt.

Ab Android 10 müssen alle Android-Kernel mit einer LLVM-Toolchain erstellt werden. Bei GKI muss die LLVM-Toolchain, die zum Erstellen von Produktkerneln und Anbietermodulen verwendet wird, dieselbe ABI wie die LLVM-Toolchain von AOSP generieren und die Partner müssen sicherstellen, dass die KMI mit dem GKI-Kernel kompatibel ist.

Die Android - Kernel - Build - Dokumentation beschreibt , wie die Referenz GKI Kernel gebaut wird. Insbesondere stellt das dokumentierte Verfahren sicher, dass die richtige Toolchain und Konfiguration verwendet wird, um den Kernel zu bauen. Downstream-Partner werden ermutigt, die gleichen Tools für die Produktion des endgültigen Kernels zu verwenden, um Inkompatibilitäten zu vermeiden, die durch die Toolchain oder andere Build-Zeit-Abhängigkeiten verursacht werden.

Kernel-Konfigurationen

Der GKI - Kernel mit integrierten arch/arm64/configs/gki_defconfig . Da sich diese Konfigurationen auf das KMI auswirken, werden die GKI-Konfigurationen sehr sorgfältig verwaltet. Für die eingefrorenen KMI-Kernel können Konfigurationen nur hinzugefügt oder entfernt werden, wenn dies keine Auswirkungen auf die KMI hat.

Der GKI-Kernel muss für die Ausführung auf verschiedenen Geräten konfiguriert werden. Daher muss es über integrierte Unterstützung für alle Subsysteme und Optionen verfügen, die für all diese Geräte erforderlich sind, ausgenommen die ladbaren Module, die zur Aktivierung der Hardware verwendet werden. Die Partner sollten die benötigten Konfigurationsänderungen verlangen zu dev Kernel.

Boot-Änderungen

Um eine saubere Trennung zwischen den GKI und verwendeten Komponenten zu erleichtern, das boot enthält Partition nur generische Komponenten, einschließlich dem Kernels und ein RAM - Disk mit GKI - Modulen. Eine neue Version des Boot-Headers (v3) wird definiert, um die Konformität mit der GKI-Architektur anzuzeigen. Die GKI-Version der Boot-Images wird von Google bereitgestellt und ersetzt beim Testen der GKI-Kompatibilität die Version des Boot-Images des Anbieters.

Der RAM - Disk zur ersten Stufe init , recovery und fastbootd ist ein initramfs Bild , das aus zwei CPIO Archiven , die von der Bootloader konkateniert werden. Das erste CPIO Archiv stammt aus der neuen vendor_boot Partition. Die zweite kommt von der boot - Partition.

Eine Zusammenfassung der Änderungen finden Sie hier. Siehe Vendor - Boot - Partition für weitere Einzelheiten.

Bootpartition

Die boot - Partition enthält einen Kopf, Kern, und ein cpio - Archiv des allgemeinen Teils des Boot - RAM - Disk.

Mit einem Boot Header v3 boot - Partition, diese Abschnitte des Standes der boot - Partition nicht mehr vorhanden sind :

  • Bootloader der zweiten Stufe: Wenn ein Gerät über einen Bootloader der zweiten Stufe verfügt, muss dieser in seiner eigenen Partition gespeichert werden.
  • DTB: Der DTB wird in der gespeicherten Vendor - Boot - Partition .

Die boot - Partition enthält ein CPIO - Archiv mit den GKI Komponenten:

  • GKI Kernel - Module befindet sich in /lib/modules/
  • first_stage_init und Bibliotheken es hängt davon ab ,
  • fastbootd und recovery (verwendet in A / B und virtuellen A / B - Geräte)

Die GKI Boot - Image wird von Google bereitgestellt und muss verwendet werden GKI Kompatibilitätstests .

Die neueste arm64 android11-5.4 boot.img ist zum Herunterladen von ci.android.com in den aosp_arm64 Build Artefakte des aosp-master - Zweig.

Das neueste arm64 android11-5.4 Kernel - Image ( Image.gz ) kann heruntergeladen werden unter ci.android.com in den kernel_aarch64 Build Artefakte des aosp_kernel-common-android11-5.4 Zweig.

Boot-Partition des Anbieters

Die vendor_boot Partition wird mit GKI eingeführt. Es ist A/B mit Virtual A/B und besteht aus einem Header, der Hersteller-Ramdisk und dem Gerätebaum-Blob. Die Vendor-Ramdisk ist ein CPIO-Archiv, das die Vendor-Module enthält, die für den Gerätestart erforderlich sind. Dazu gehören Module zur Aktivierung kritischer SoC-Funktionen sowie Speicher- und Anzeigetreiber, die zum Booten des Geräts und zum Anzeigen von Begrüßungsbildschirmen erforderlich sind.

Das CPIO-Archiv enthält:

  • Erste Phase der init - Anbieter Kernel - Module befindet sich in /lib/modules/
  • modprobe Konfigurationsdateien in sich /lib/modules
  • modules.load Datei , um die Module zu laden während der ersten Stufe angibt init

Bootloader-Anforderung

Der Bootloader muss das generische Ramdisk CPIO Bild (von der Last - boot - vendor_boot Partition ) in dem Speicher unmittelbar nach dem Anbieter Ramdisk CPIO Bild (von der vendor_boot Partition ). Nach der Dekomprimierung ist das Ergebnis die generische Ramdisk, die über die Dateistruktur der Ramdisk des Herstellers gelegt wird.

GKI-Kompatibilitätstests

Für die Android 11-Plattformversion müssen Geräte, die mit einem v5.4-Kernel gestartet wurden, die VTS- und CTS-on-GSI-Tests mit dem von Google bereitgestellten GKI-Boot-Image ausführen.

Beitrag zum GKI-Kernel

Der GKI Kern wird aus dem AOSP gemeinsamen Kernel gebaut , beginnend mit android11-5.4 . Alle eingereichten Patches müssen entsprechen diesen Beitrag Leitlinien , die zwei Strategien dokumentieren:

  1. Best: Machen Sie alle Änderungen Linux Upstream. Gegebenenfalls auf die stabilen Releases zurückportieren. Diese Patches werden automatisch in die entsprechenden gemeinsamen AOSP-Kernel eingebunden. Wenn sich der Patch bereits in Upstream-Linux befindet, senden Sie einen Backport des Patches, der den unten aufgeführten Patch-Anforderungen entspricht.
  2. Weniger gut: Entwickeln Sie Ihre Patches aus Baum (von einer vorgeschalteten Linux Sicht). Es sei denn , die Patches einen Android-spezifischen Fehler sind Befestigungs, sind sie sehr unwahrscheinlich , in Kauf genommen werden , wenn sie nicht mit abgestimmt worden sind kernel-team@android.com .

Für Partner, die GKI implementieren, kann es triftige Gründe geben, warum Out-of-Tree-Patches erforderlich sind (insbesondere wenn Siliziumzeitpläne eingehalten werden müssen). Für diese Fälle Datei ein Buganizer Problem.

Sende GKI Änderungen durch Gerrit zum android-mainline Zweig und dann auf andere Release Zweige zurückportiert nach Bedarf.

Der mit ladbaren Modulen verbundene Quellcode muss nicht zum GKI-Kernel-Quellbaum beigetragen werden, es wird jedoch dringend empfohlen, alle Treiber an Upstream-Linux zu senden.

Anfordern von Backports von Mainline

Im Allgemeinen können Mainline-Patches, die von GKI-Partnern benötigt werden, auf die GKI-Kernel zurückportiert werden. Laden Sie den Patch Gerrit nach dem Beitrag Richtlinien .

Wenn der Patch im Upstream gepostet, aber noch nicht akzeptiert wurde, wird empfohlen, zu warten, bis er akzeptiert wird. Wenn der Zeitplan es nicht zulässt, auf die Upstream-Annahme des Patches zu warten, melden Sie ein Buganizer-Problem.

GKI-Konfigurationen hinzufügen und entfernen

Das Hinzufügen oder Entfernen von configs in beantragen arch/arm64/configs/gki_defconfig , Datei eine Buganizer Frage eindeutig erklärt , den Antrag und die Begründung. Wenn kein Buganizer-Projekt zugänglich ist, posten Sie den Patch mit der Konfigurationsänderung an Gerrit und stellen Sie sicher, dass in der Commit-Nachricht der Grund für die Notwendigkeit der Konfiguration eindeutig angegeben ist.

Konfigurationsänderungen in eingefrorenen KMI-Kernels dürfen KMI nicht beeinflussen.

Kernel-Code ändern

Von Änderungen am Kern-Kernel-Code in allgemeinen AOSP-Kerneln wird abgeraten. Senden Sie zuerst Patches an Upstream-Linux und portieren Sie sie dann zurück. Wenn es einen guten Grund für eine Kernel-Änderung gibt, reichen Sie ein Buganizer-Problem ein, in dem Sie die Anfrage und die Begründung klar angeben. Ohne Buganizer-Problem werden keine Android-spezifischen Funktionen akzeptiert. Senden Sie eine E - Mail an kernel-team@android.com , wenn Sie keine Buganizer Problem erstellen können.

Exportieren von Symbolen über EXPORT_SYMBOL_GPL()

Senden Sie keine Patches stromaufwärts, die nur Symbolexporte enthalten. Um für die Upstream - Linux, Additionen in Betracht gezogen werden EXPORT_SYMBOL_GPL() erfordern eine Baum modularen Treiber, der das Symbol verwendet, so sind die neuen Treiber oder Änderungen an einem bestehenden Treiber im gleichen Patchset wie der Export.

Beim Upstream-Versenden von Patches muss die Commit-Nachricht eine klare Begründung dafür enthalten, warum der Patch benötigt wird und für die Community von Vorteil ist. Exporte zu ermöglichen, um Treiber oder Funktionen außerhalb des Baumes zu nutzen, ist kein überzeugendes Argument für Upstream-Maintainer.

Wenn der Patch aus irgendeinem Grund nicht stromaufwärts gesendet werden kann, melden Sie ein Buganizer-Problem und erklären Sie, warum der Patch nicht stromaufwärts gesendet werden kann. Im Allgemeinen werden Symbole, die die unterstützte Schnittstelle zu einem Kernel-Subsystem darstellen, wahrscheinlich als Export akzeptiert. Es ist jedoch unwahrscheinlich, dass zufällige interne Hilfsfunktionen akzeptiert werden, und Sie werden aufgefordert, Ihren Code umzugestalten, um deren Verwendung zu vermeiden.

Hinzufügen eines Symbols zu einer KMI-Symbolliste

Die KMI-Symbollisten müssen mit GKI-Kernelsymbolen aktualisiert werden, die von Anbietermodulen verwendet werden. Da nur KMI-Symbole als stabil beibehalten werden, lässt GKI das Laden von Modulen nicht zu, wenn sie auf einem Nicht-KMI-Symbol basieren.

Das extract_symbols Skript extrahiert die relevanten Symbole aus einem Kernel - Build - Baum und kann verwendet werden , um eine KMI Symbolliste zu aktualisieren. Beachten Sie die Symbol - Eintrag Dokumentation für weitere Details.