Kernelcode für GKI entwickeln

Das generische Kernel-Image (GKI) reduziert die Kernel-Fragmentierung, indem es eng an den Upstream-Linux-Kernel angeglichen wird. Es gibt jedoch triftige Gründe, warum einige Patches nicht vorgelagert akzeptiert werden können, und es gibt Produktzeitpläne, die eingehalten werden müssen. Daher werden einige Patches in den ACK-Quellen (Android Common Kernel) gepflegt, aus denen der 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 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… <insert reason here>. Wenden Sie sich an das Android-Kernel-Team und arbeiten Sie mit uns zusammen, um den Patch so umzustrukturieren, dass er zur Überprüfung eingereicht und in die Upstream-Version aufgenommen 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 im Linux-Quellcodebaum beschriebenen Codierungsstandards für den Linux-Kernel entsprechen, unabhängig davon, ob sie Upstream oder an ACK 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.

Reichen Sie Patches zuerst bei LKML zur Vorabüberprüfung ein. Wenn der Patch:

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

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 Upstream-Patch nach android12-5.4 zurückportiert wird, da er wahrscheinlich bereits in android-mainline vorhanden ist.

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 aus dem Upstream, die nicht sauber ausgewählt wurden und geändert werden müssen, werden wahrscheinlich 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 akzeptiert wird, unabhängig davon, 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 der Grund 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. Alle CONFIG-Änderungen, die sich nach dem Einfrieren auf die Kernelmodulschnittstelle (KMI) auswirken, werden abgelehnt. Wenn Partner widersprüchliche 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. Auch wenn der Binder-Treiber vorgelagert verwaltet wird, können Änderungen an den Prioritätsübernahmefunktionen des Binder-Treibers nicht vorgelagert gesendet 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-Scripts oder Konfigurationen oder anderer Scripts, die nicht vorgelagert sind.

Nicht zum Stamm gehörende Module

Upstream-Linux rät ausdrücklich von der Unterstützung für das Erstellen von Out-of-Tree-Modulen ab. 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 Stammbaum 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() im Upstream anzufordern und ein Modul bereitzustellen, das das neu exportierte Symbol verwendet. Wenn es jedoch eine gültige Begründung dafür gibt, warum das Modul nicht im Upstream eingereicht wird, können Sie den Patch stattdessen an ACK senden. Sie müssen im Problem angeben, warum das Modul nicht hochgeladen werden kann. Fordere nicht die Variante an, die nicht der GPL unterliegt (EXPORT_SYMBOL()).

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. Für das Erstellen von Modulen außerhalb des Stammverzeichnisses enthält GKI einen Mechanismus zum Aktivieren ausgeblendeter Konfigurationen.

Wenn Sie eine ausgeblendete Konfiguration aktivieren möchten, fügen Sie in init/Kconfig.gki eine select-Anweisung hinzu, damit sie basierend auf der CONFIG_GKI_HACKS_TO_FIX-Kernelkonfiguration, die in gki_defconfig aktiviert ist, automatisch ausgewählt wird. 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.

Ladebare Regler

Bei Kernel-Frameworks wie cpufreq, die ladbare Taktregler unterstützen, können Sie den Standardregler überschreiben, z. B. den schedutil-Regler von cpufreq. Wenn Frameworks (z. B. das thermische Framework) keine ladbaren Taktmanager 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 Upstream-Maintainern zusammen, um die erforderliche Unterstützung hinzuzufügen.

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-Kerneln oder in ACK akzeptiert wird. Um Mehrwertfunktionen zu ermöglichen, auf die Partner angewiesen sind, mit minimalen Auswirkungen auf den Kernkernelcode, akzeptiert GKI Anbieter-Hooks, mit denen Module aus dem Kernkernelcode 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 Ressourcenerfassung 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.

  • Bei normalen Anbieter-Hooks wird DECLARE_HOOK() verwendet, 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 in Fällen wie Scheduler-Hooks erforderlich, in denen die verknüpfte Funktion auch dann aufgerufen werden muss, wenn die CPU offline ist oder einen nicht atomaren Kontext erfordert. 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 zu vermeiden, die von Anbietern und OEMs benötigt werden, 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 Kopfdatei 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 Typ 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 die Typen stattdessen 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 Headerdatei des Anbieter-Hooks 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 zulässig. sysfs-Knoten, die von den SoC- und geräteunabhängigen Bibliotheken und dem Java-Code verwendet werden, aus dem das Android-Framework besteht, können nur auf kompatible Weise geändert werden und müssen vorgelagert geändert werden, wenn es sich nicht um Android-spezifische sysfs-Knoten handelt. Sie können anbieterspezifische sysfs-Knoten erstellen, die vom Nutzerbereich des Anbieters verwendet werden. Standardmäßig wird der Zugriff auf sysfs-Knoten durch den Userspace mit SELinux 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.