Kernel-Code für GKI entwickeln

Das generische Kernel-Image (GKI) reduziert die Kernelfragmentierung, indem es eng an den Upstream-Linux-Kernel angeglichen wird. Es gibt jedoch gute Gründe, warum einige Patches nicht vorgelagert werden können, und es gibt Produktpläne, die erfüllt werden müssen. Daher werden einige Patches in den Android Common Kernel (ACK)-Quellen verwaltet, aus denen die GKI erstellt wird.

Entwickler müssen Codeänderungen zuerst über die Linux Kernel Mailing List (LKML) einreichen und Codeänderungen nur dann an den ACKandroid-mainline-Branch senden, wenn es einen triftigen Grund dafür gibt, dass Upstream nicht möglich ist. Im Folgenden finden Sie Beispiele für gültige Gründe und wie Sie damit umgehen sollten.

  • Der Patch wurde an LKML gesendet, aber nicht rechtzeitig für eine Produktveröffentlichung akzeptiert. So gehen Sie mit diesem Patch um:

    • Weisen Sie nach, dass der Patch an LKML gesendet und Kommentare dazu erhalten wurden, oder geben Sie eine geschätzte Zeit an, bis der Patch an Upstream gesendet wird.
    • Entscheiden Sie, wie der Patch in ACK landen soll, genehmigen Sie ihn upstream und entfernen Sie ihn dann aus ACK, wenn die endgültige Upstream-Version in ACK zusammengeführt wird.

  • Der Patch definiert EXPORT_SYMBOLS_GPL() für ein Anbietermodul, konnte aber nicht vorgereicht werden, da es keine In-Tree-Module gibt, die dieses Symbol verwenden. Geben Sie an, warum Ihr Modul nicht vorgereicht werden kann, und welche Alternativen Sie in Betracht gezogen haben, bevor Sie diesen Antrag gestellt haben.

  • Der Patch ist nicht generisch genug für den Upstream und es bleibt keine Zeit, ihn vor einer Produktveröffentlichung zu überarbeiten. Geben Sie für die Bearbeitung dieses Patches einen geschätzten Zeitpunkt an, bis zu dem ein überarbeiteter Patch vorgelagert eingereicht wird. Der Patch wird in ACK nicht akzeptiert, wenn kein Plan zur Einreichung eines überarbeiteten Patches zur Überprüfung vorliegt.

  • Der Patch kann vom Upstream nicht akzeptiert werden, weil… <Grund hier einfügen>. Wenden Sie sich zur Behandlung dieses Patches an das Android-Kernel-Team und arbeiten Sie mit uns an Möglichkeiten zur Refaktorierung des Patches, sodass er zur Überprüfung und Upstream-Prüfung eingereicht werden kann.

Es gibt noch viele weitere mögliche Begründungen. Wenn Sie einen Fehler oder einen Patch einreichen, geben Sie eine gültige Begründung an und rechnen Sie mit einigen Iterationen und Diskussionen. Uns ist bewusst, dass die ACK einige Patches enthält, insbesondere in den frühen Phasen von GKI, während alle lernen, wie sie Upstream-Arbeiten erledigen, aber die Produktzeitpläne dafür nicht lockern können. Die Anforderungen an das Upstreaming werden mit der Zeit strenger.

Patchanforderungen

Patches müssen den Codierungsstandards für den Linux-Kernel entsprechen, die in der Linux-Quellstruktur beschrieben werden, unabhängig davon, ob sie vorgelagert oder zur Bestätigung gesendet werden. Das scripts/checkpatch.pl-Script wird im Rahmen der Presubmit-Tests von Gerrit ausgeführt. Führen Sie es daher im Voraus aus, um sicherzustellen, dass es besteht. Wenn Sie das checkpatch-Script mit derselben Konfiguration wie beim Vorabtest ausführen möchten, verwenden Sie //build/kernel/static_analysis:checkpatch_presubmit. Weitere Informationen finden Sie unter build/kernel/kleaf/docs/checkpatch.md.

ACK-Patches

An ACK gesendete Patches müssen den Codierungsstandards des Linux-Kernels und den Richtlinien für Beiträge entsprechen. Sie müssen ein Change-Id-Tag in die Commit-Nachricht aufnehmen. Wenn Sie den Patch für mehrere Branches einreichen (z. B. android-mainline und android12-5.4), müssen Sie für alle Instanzen des Patches dasselbe Change-Id verwenden.

Patches zur Überprüfung an LKML senden Wenn der Patch:

  • Nachdem es vorgelagert akzeptiert wurde, wird es automatisch in android-mainline zusammengeführt.
  • Wurde nicht upstream akzeptiert, reichen Sie es mit Verweis auf die Upstream-Einreichung oder einer Erklärung dazu ein, warum es nicht an LKML gesendet wurde.android-mainline

Nachdem ein Patch entweder im Upstream-Verfahren oder in android-mainline akzeptiert wurde, kann er in die entsprechende LTS-basierte ACK-Version zurückportiert werden (z. B. android12-5.4 und android11-5.4 für Patches, die Android-spezifischen Code korrigieren). Wenn Sie den Patch an android-mainline senden, können Sie ihn mit neuen Upstream-Release-Kandidaten testen. Außerdem ist sichergestellt, dass der Patch im nächsten LTS-basierten ACK enthalten ist. Ausnahmen sind Fälle, in denen ein vorgelagerter Patch zu android12-5.4 zurückportiert wird, da sich der Patch wahrscheinlich bereits in android-mainline befindet.

Upstream-Patches

Wie in den Richtlinien für Beiträge angegeben, fallen Upstream-Patches für ACK-Kernel in die folgenden Gruppen (in der Reihenfolge der Wahrscheinlichkeit der Annahme aufgeführt).

  • UPSTREAM:: Aus „android-mainline“ ausgewählte Patches werden wahrscheinlich in ACK akzeptiert, wenn es einen vernünftigen Anwendungsfall gibt.
  • BACKPORT:: Patches von Upstream, die sich nicht sauber abgrenzen und geändert werden müssen, werden auch akzeptiert, wenn es einen vernünftigen Anwendungsfall gibt.
  • FROMGIT:: Patches, die aus einem Maintainer-Branch ausgewählt wurden, um sie an den Linux-Mainline einzureichen, können akzeptiert werden, wenn ein bevorstehender Termin vorliegt. Diese müssen sowohl für den Inhalt als auch für den Zeitplan begründet werden.
  • FROMLIST: – Patches, die an LKML gesendet, aber noch nicht in einen Maintainer-Branch aufgenommen wurden, werden wahrscheinlich nicht akzeptiert, es sei denn, die Begründung ist überzeugend genug, dass der Patch unabhängig davon akzeptiert wird, ob er in Upstream-Linux landet (wir gehen davon aus, dass dies nicht der Fall ist). Es muss ein Problem mit den FROMLIST-Patches geben, damit eine Diskussion mit dem Android-Kernel-Team möglich ist.

Android-spezifische Patches

Wenn Sie die erforderlichen Änderungen nicht upstream einbinden können, können Sie versuchen, Out-of-Tree-Patches direkt an ACK zu senden. Wenn Sie Out-of-Tree-Patches einreichen möchten, müssen Sie ein Problem in der IT erstellen, in dem der Patch und die Begründung dafür angegeben werden, warum der Patch nicht vorgereicht werden kann (siehe vorherige Liste für Beispiele). Es gibt jedoch einige Fälle, in denen der Code nicht vorgereicht werden kann. Diese Fälle werden wie unten beschrieben behandelt und müssen den Richtlinien für Beiträge für Android-spezifische Patches entsprechen und im Betreff mit dem Präfix ANDROID: getaggt sein.

Änderungen an gki_defconfig

Alle CONFIG-Änderungen an gki_defconfig müssen sowohl auf die arm64- als auch auf die x86-Version angewendet werden, es sei denn, die CONFIG ist architekturspezifisch. Wenn Sie eine Änderung an einer CONFIG-Einstellung beantragen möchten, erstellen Sie ein Problem in der IT, um die Änderung zu besprechen. Jede CONFIG-Änderung, die sich auf die Kernel Module Interface (KMI) auswirkt, nachdem sie eingefroren ist, wird abgelehnt. Wenn Partner inkonsistente Einstellungen für eine einzelne Konfiguration anfordern, lösen wir Konflikte durch eine Diskussion über die zugehörigen Fehler.

Code, der nicht vorgelagert ist

Änderungen an Code, der bereits Android-spezifisch ist, können nicht weitergeleitet werden. Beispiel: Obwohl der Binder-Treiber vorgelagert wird, können Änderungen an den Prioritätsübernahmefunktionen des Binder-Treibers nicht vorgelagert werden, da sie Android-spezifisch sind. Erläutern Sie in Ihrem Fehlerbericht und Patch, warum der Code nicht weitergeleitet werden kann. Teilen Sie die Patches nach Möglichkeit in Teile auf, die an Upstream-Entwickler gesendet werden können, und Android-spezifische Teile, die nicht an Upstream-Entwickler gesendet werden können, um die Menge des Out-of-Tree-Codes in ACK zu minimieren.

Weitere Änderungen in dieser Kategorie sind Aktualisierungen von KMI-Darstellungsdateien, KMI-Symbollisten, gki_defconfig, Build-Skripts oder Konfiguration oder anderen Skripts, die nicht vorgelagert sind.

Nicht zum Stamm gehörende Module

Upstream-Linux rät ausdrücklich davon ab, Out-of-Tree-Module zu erstellen. Das ist eine vernünftige Position, da Linux-Maintainer keine Garantien für die In-Kernel-Quell- oder Binärkompatibilität übernehmen und keinen Code unterstützen möchten, der nicht im Verzeichnisbaum enthalten ist. Die GKI bietet jedoch ABI-Garantien für Anbietermodule, sodass KMI-Schnittstellen während der unterstützten Lebensdauer eines Kernels stabil bleiben. Daher gibt es eine Reihe von Änderungen, um Anbietermodule zu unterstützen, die für ACK akzeptabel, aber für Upstream nicht akzeptabel sind.

Angenommen, Sie haben einen Patch, der EXPORT_SYMBOL_GPL()-Makros hinzufügt, die Module, die den Export verwenden, sind aber nicht im Quellbaum enthalten. Sie müssen zwar versuchen, EXPORT_SYMBOL_GPL() in Upstream anzufordern und ein Modul bereitzustellen, das das neu exportierte Symbol verwendet. Wenn es jedoch eine triftige Begründung dafür gibt, warum das Modul nicht vorgelagert wird, können Sie den Patch stattdessen an ACK senden. Sie müssen im Problem angeben, warum das Modul nicht hochgeladen werden kann. Fordern Sie nicht die Nicht-GPL-Variante EXPORT_SYMBOL() an.

Ausgeblendete Konfigurationen

Einige In-Tree-Module wählen automatisch ausgeblendete Konfigurationen aus, die in gki_defconfig nicht angegeben werden können. Wenn beispielsweise CONFIG_SND_SOC_SOF=y konfiguriert ist, wird CONFIG_SND_SOC_TOPOLOGY automatisch ausgewählt. Damit eine Out-of-Tree-Modulerstellung möglich ist, enthält GKI einen Mechanismus, mit dem versteckte Konfigurationen aktiviert werden können.

Zum Aktivieren einer ausgeblendeten Konfiguration fügen Sie eine select-Anweisung in init/Kconfig.gki hinzu, damit sie automatisch anhand der Kernel-Konfiguration CONFIG_GKI_HACKS_TO_FIX ausgewählt wird, die in gki_defconfig aktiviert ist. Verwenden Sie diesen Mechanismus nur für ausgeblendete Konfigurationen. Wenn die Konfiguration nicht ausgeblendet ist, muss sie in gki_defconfig entweder explizit oder als Abhängigkeit angegeben werden.

Laderegler

Bei Kernel-Frameworks wie cpufreq, die ladbare Taktgeber unterstützen, können Sie den Standard-Taktgeber überschreiben, z. B. den schedutil-Taktgeber von cpufreq. Wenn Frameworks (z. B. das thermische Framework) keine ladbaren Taktgeber oder Treiber unterstützen, aber dennoch eine anbieterspezifische Implementierung erfordern, erstellen Sie ein Problem in der IT und wenden Sie sich an das Android-Kernel-Team.

Wir arbeiten mit Ihnen und den vorgelagerten Administratoren zusammen, um Ihnen den erforderlichen Support zu bieten.

Anbieter-Hooks

In früheren Releases konnten Sie anbieterspezifische Änderungen direkt in den Kernkernel einfügen. Das ist mit GKI 2.0 nicht möglich, da produktspezifischer Code in Modulen implementiert werden muss und nicht in den Upstream-Kernen oder in ACK akzeptiert wird. Um zusätzliche Funktionen zu ermöglichen, die Partner mit minimalen Auswirkungen auf den Kern-Kernel-Code nutzen, akzeptiert GKI Anbieter-Hooks, mit denen Module aus dem Kern-Kernel-Code aufgerufen werden können. Außerdem können wichtige Datenstrukturen mit Anbieterdatenfeldern aufgefüllt werden, die zum Speichern von anbieterspezifischen Daten zur Implementierung dieser Funktionen verfügbar sind.

Anbieter-Hooks gibt es in zwei Varianten (normal und eingeschränkt), die auf Tracepoints (nicht auf Trace-Ereignissen) basieren, an die Anbietermodule angehängt werden können. Anstatt beispielsweise eine neue sched_exit()-Funktion hinzuzufügen, um eine Abrechnung beim Beenden einer Aufgabe durchzuführen, können Anbieter einen Hook in do_exit() hinzufügen, an den ein Anbietermodul zur Verarbeitung angehängt werden kann. Eine Beispielimplementierung enthält die folgenden Anbieter-Hooks.

  • Normale Anbieter-Hooks verwenden DECLARE_HOOK(), um eine Tracepoint-Funktion mit dem Namen trace_name zu erstellen. Dabei ist name die eindeutige Kennung für den Trace. Normale Anbieter-Hook-Namen beginnen üblicherweise mit android_vh. Der Name für den sched_exit()-Hook wäre also android_vh_sched_exit.
  • Eingeschränkte Anbieter-Hooks sind beispielsweise in Fällen wie Planer-Hooks erforderlich, in denen die angehängte Funktion aufgerufen werden muss, auch wenn die CPU offline ist oder einen nichtatomaren Kontext benötigt. Eingeschränkten Anbieter-Hooks können nicht getrennt werden. Daher können Module, die an einen eingeschränkten Hook angehängt sind, nie entladen werden. Namen eingeschränkter Anbieterhooks beginnen mit android_rvh.

Wenn Sie einen Anbieter-Hook hinzufügen möchten, reichen Sie ein Problem in der IT ein und reichen Sie Patches ein. Wie bei allen Android-spezifischen Patches muss ein Problem vorliegen und Sie müssen eine Begründung angeben. Die Unterstützung für Anbieter-Hooks ist nur in ACK verfügbar. Senden Sie diese Patches daher nicht an Upstream-Linux.

Anbieterfelder zu Strukturen hinzufügen

Sie können Anbieterdaten mit wichtigen Datenstrukturen verknüpfen, indem Sie mithilfe der ANDROID_VENDOR_DATA()-Makros android_vendor_data-Felder hinzufügen. Wenn Sie beispielsweise zusätzliche Funktionen unterstützen möchten, hängen Sie Felder an Strukturen an, wie im folgenden Codebeispiel gezeigt.

Um potenzielle Konflikte zwischen Feldern, die von Anbietern und von OEMs benötigt werden, zu vermeiden, dürfen OEMs niemals Felder verwenden, die mit ANDROID_VENDOR_DATA()-Makros deklariert wurden. Stattdessen müssen OEMs ANDROID_OEM_DATA() verwenden, um android_oem_data-Felder zu deklarieren.

#include <linux/android_vendor.h>
...
struct important_kernel_data {
  [all the standard fields];
  /* Create vendor data for use by hook implementations. The
   * size of vendor data is based on vendor input. Vendor data
   * can be defined as single u64 fields like the following that
   * declares a single u64 field named "android_vendor_data1" :
   */
  ANDROID_VENDOR_DATA(1);

  /*
   * ...or an array can be declared. The following is equivalent to
   * u64 android_vendor_data2[20]:
   */
  ANDROID_VENDOR_DATA_ARRAY(2, 20);

  /*
   * SoC vendors must not use fields declared for OEMs and
   * OEMs must not use fields declared for SoC vendors.
   */
  ANDROID_OEM_DATA(1);

  /* no further fields */
}

Anbieter-Hooks definieren

Fügen Sie dem Kernelcode Anbieter-Hooks als Tracepoints hinzu, indem Sie sie mit DECLARE_HOOK() oder DECLARE_RESTRICTED_HOOK() deklarieren und dann dem Code als Tracepoint hinzufügen. So fügen Sie beispielsweise der vorhandenen Kernelfunktion do_exit() die Option trace_android_vh_sched_exit() hinzu:

#include <trace/hooks/exit.h>
void do_exit(long code)
{
    struct task_struct *tsk = current;
    ...
    trace_android_vh_sched_exit(tsk);
    ...
}

Die trace_android_vh_sched_exit()-Funktion prüft zuerst nur, ob etwas angehängt ist. Wenn ein Anbietermodul jedoch einen Handler mit register_trace_android_vh_sched_exit() registriert, wird die registrierte Funktion aufgerufen. Der Handler muss sich des Kontexts im Hinblick auf gehaltene Sperren, den RCS-Status und andere Faktoren bewusst sein. Der Hook muss in einer Kopfdatei im Verzeichnis include/trace/hooks definiert werden.

Der folgende Code zeigt beispielsweise eine mögliche Deklaration für trace_android_vh_sched_exit() in der Datei include/trace/hooks/exit.h.

/* SPDX-License-Identifier: GPL-2.0 */
#undef TRACE_SYSTEM
#define TRACE_SYSTEM sched
#define TRACE_INCLUDE_PATH trace/hooks

#if !defined(_TRACE_HOOK_SCHED_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TRACE_HOOK_SCHED_H
#include <trace/hooks/vendor_hooks.h>
/*
 * Following tracepoints are not exported in tracefs and provide a
 * mechanism for vendor modules to hook and extend functionality
 */

struct task_struct;

DECLARE_HOOK(android_vh_sched_exit,
             TP_PROTO(struct task_struct *p),
             TP_ARGS(p));

#endif /* _TRACE_HOOK_SCHED_H */

/* This part must be outside protection */
#include <trace/define_trace.h>

Wenn Sie die für den Anbieter-Hook erforderlichen Schnittstellen instanziieren möchten, fügen Sie die Headerdatei mit der Hook-Deklaration zu drivers/android/vendor_hooks.c hinzu und exportieren Sie die Symbole. Im folgenden Code wird beispielsweise die Deklaration des android_vh_sched_exit()-Hooks abgeschlossen.

#ifndef __GENKSYMS__
/* struct task_struct */
#include <linux/sched.h>
#endif

#define CREATE_TRACE_POINTS
#include <trace/hooks/vendor_hooks.h>
#include <trace/hooks/exit.h>
/*
 * Export tracepoints that act as a bare tracehook (i.e. have no trace
 * event associated with them) to allow external modules to probe
 * them.
 */
EXPORT_TRACEPOINT_SYMBOL_GPL(android_vh_sched_exit);

HINWEIS: Datenstrukturen, die in der Hook-Deklaration verwendet werden, müssen vollständig definiert sein, um die ABI-Stabilität zu gewährleisten. Andernfalls ist es nicht sicher, die opaken Zeiger zu dereferenzieren oder den Datentyp in Größenkontexten zu verwenden. Das Include, das die vollständige Definition solcher Datenstrukturen enthält, sollte sich im Abschnitt #ifndef __GENKSYMS__ von drivers/android/vendor_hooks.c befinden. Die Headerdateien in include/trace/hooks dürfen nicht die Kernel-Headerdatei mit den Typdefinitionen enthalten, um CRC-Änderungen zu vermeiden, die das KMI beeinträchtigen. Deklarieren Sie stattdessen die Typen weiter.

An Anbieter-Hooks anhängen

Wenn Sie Anbieter-Hooks verwenden möchten, muss das Anbietermodul einen Handler für den Hook registrieren. Dies geschieht in der Regel während der Modulinitialisierung. Im folgenden Code wird beispielsweise der foo.ko-Modul-Handler für trace_android_vh_sched_exit() dargestellt.

#include <trace/hooks/sched.h>
...
static void foo_sched_exit_handler(void *data, struct task_struct *p)
{
    foo_do_exit_accounting(p);
}
...
static int foo_probe(..)
{
    ...
    rc = register_trace_android_vh_sched_exit(foo_sched_exit_handler, NULL);
    ...
}

Anbieter-Hooks aus Headerdateien verwenden

Wenn Sie Anbieter-Hooks aus Headerdateien verwenden möchten, müssen Sie möglicherweise die Headerdatei des Anbieter-Hooks aktualisieren, um TRACE_INCLUDE_PATH zu dedefinieren. Andernfalls werden Buildfehler ausgegeben, die darauf hinweisen, dass eine Headerdatei für den Tracepoint nicht gefunden werden konnte. Beispiel:

In file included from .../common/init/main.c:111:
In file included from .../common/include/trace/events/initcall.h:74:
.../common/include/trace/define_trace.h:95:10: fatal error: 'trace/hooks/initcall.h' file not found
   95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../common/include/trace/define_trace.h:90:32: note: expanded from macro 'TRACE_INCLUDE'
   90 | # define TRACE_INCLUDE(system) __TRACE_INCLUDE(system)
      |                                ^~~~~~~~~~~~~~~~~~~~~~~
.../common/include/trace/define_trace.h:87:34: note: expanded from macro '__TRACE_INCLUDE'
   87 | # define __TRACE_INCLUDE(system) __stringify(TRACE_INCLUDE_PATH/system.h)
      |                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../common/include/linux/stringify.h:10:27: note: expanded from macro '__stringify'
   10 | #define __stringify(x...)       __stringify_1(x)
      |                                 ^~~~~~~~~~~~~~~~
.../common/include/linux/stringify.h:9:29: note: expanded from macro '__stringify_1'
    9 | #define __stringify_1(x...)     #x
      |                                 ^~
<scratch space>:14:1: note: expanded from here
   14 | "trace/hooks/initcall.h"
      | ^~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

Um diese Art von Buildfehler zu beheben, wenden Sie die entsprechende Korrektur auf die von Ihnen eingefügte Anbieter-Hook-Headerdatei an. Weitere Informationen finden Sie unter https://r.android.com/3066703.

diff --git a/include/trace/hooks/mm.h b/include/trace/hooks/mm.h
index bc6de7e53d66..039926f7701d 100644
--- a/include/trace/hooks/mm.h
+++ b/include/trace/hooks/mm.h
@@ -2,7 +2,10 @@
 #undef TRACE_SYSTEM
 #define TRACE_SYSTEM mm

+#ifdef CREATE_TRACE_POINTS
 #define TRACE_INCLUDE_PATH trace/hooks
+#define UNDEF_TRACE_INCLUDE_PATH
+#endif

Wenn Sie UNDEF_TRACE_INCLUDE_PATH definieren, wird include/trace/define_trace.h angewiesen, TRACE_INCLUDE_PATH nach dem Erstellen der Trace-Punkte aufzuheben.

Kernel-Hauptfunktionen

Wenn Sie mit keiner der vorherigen Methoden eine Funktion aus einem Modul implementieren können, müssen Sie die Funktion dem Kern als Android-spezifische Änderung hinzufügen. Erstellen Sie ein Problem im Issue-Tracker (IT), um die Unterhaltung zu starten.

User Application Programming Interface (UAPI)

  • UAPI-Headerdateien: Änderungen an UAPI-Headerdateien müssen vorgeschaltet erfolgen, es sei denn, die Änderungen betreffen Android-spezifische Schnittstellen. Verwenden Sie anbieterspezifische Headerdateien, um Schnittstellen zwischen Anbietermodulen und Anbieter-Userspace-Code zu definieren.
  • sysfs-Knoten. Fügen Sie dem GKI-Kernel keine neuen sysfs-Knoten hinzu (solche Ergänzungen sind nur in Anbietermodulen gültig). Die von den SoC- und geräteunabhängigen Bibliotheken verwendeten sysfs-Knoten sowie der Java-Code, der das Android-Framework umfasst, können nur auf kompatible Weise geändert werden und müssen vorgelagert werden, wenn sie keine Android-spezifischen sysfs-Knoten sind. Sie können anbieterspezifische sysfs-Knoten erstellen, die vom Nutzerbereich des Anbieters verwendet werden. Standardmäßig wird mit SELinux der Zugriff auf Sysfs-Knoten nach Nutzerbereich verweigert. Es liegt in der Verantwortung des Anbieters, die entsprechenden SELinux-Labels hinzuzufügen, um den Zugriff durch autorisierte Anbietersoftware zu ermöglichen.
  • DebugFS-Knoten Anbietermodule können Knoten in debugfs nur zum Debuggen definieren, da debugfs während des normalen Betriebs des Geräts nicht bereitgestellt wird.