Kernelcode für GKI entwickeln

Das Generic Kernel Image (GKI) verringert die Kernel-Fragmentierung, da es sich eng an den Upstream-Linux-Kernel anlehnt. Es gibt jedoch gute Gründe, warum einige Patches nicht upstream akzeptiert werden können. Außerdem müssen Produktzeitpläne eingehalten werden. Daher werden einige Patches in den Quellen des Android Common Kernel (ACK) verwaltet, aus denen der GKI erstellt wird.

Entwickler müssen Codeänderungen in erster Linie über die Linux Kernel Mailing List (LKML) einreichen und Codeänderungen nur dann an den ACK-android-mainline-Branch senden, wenn es einen triftigen Grund dafür gibt, dass Upstream nicht infrage kommt. Im Folgenden finden Sie Beispiele für gültige Gründe und Informationen dazu, wie Sie diese behandeln.

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

    • Geben Sie einen Nachweis dafür an, dass der Patch an die LKML gesendet wurde und Kommentare zum Patch eingegangen sind, oder eine geschätzte Zeit, bis der Patch upstream gesendet wird.
    • Entscheide dich für eine Vorgehensweise, um den Patch in ACK zu übernehmen, ihn upstream genehmigen zu lassen und ihn dann aus ACK zu entfernen, wenn die endgültige Upstream-Version in ACK zusammengeführt wird.

  • Im Patch wird EXPORT_SYMBOLS_GPL() für ein Anbietermodul definiert, er konnte aber nicht upstream eingereicht werden, da es keine In-Tree-Module gibt, die dieses Symbol verwenden. Wenn Sie diesen Patch bearbeiten möchten, geben Sie an, warum Ihr Modul nicht upstream eingereicht 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 der Veröffentlichung eines Produkts zu refaktorieren. Geben Sie für diesen Patch eine geschätzte Zeit an, bis zu der ein refaktorierter Patch upstream eingereicht wird. Der Patch wird in ACK nicht akzeptiert, wenn kein Plan für die Einreichung eines refaktorierten Patches zur Überprüfung upstream vorhanden ist.

  • Der Patch kann von Upstream nicht akzeptiert werden, weil… <insert reason here>. Wende dich an das Android-Kernel-Team, um diesen Patch zu bearbeiten und mit uns an Optionen zu arbeiten, um den Patch so umzugestalten, dass er zur Überprüfung eingereicht und upstream akzeptiert werden kann.

Es gibt noch viele weitere potenzielle Begründungen. Wenn Sie einen Fehler oder Patch einreichen, müssen Sie eine gültige Begründung angeben. Außerdem müssen Sie mit einigen Iterationen und Diskussionen rechnen. Wir wissen, dass das ACK einige Patches enthält, insbesondere in den frühen Phasen von GKI, wenn alle lernen, wie man Upstream arbeitet, aber die Produktzeitpläne nicht gelockert werden können. Die Upstream-Anforderungen werden im Laufe der Zeit voraussichtlich strenger werden.

Patch-Anforderungen

Patches müssen den im Linux-Quellcodebaum beschriebenen Linux-Kernel-Codierungsstandards entsprechen, unabhängig davon, ob sie upstream oder an ACK gesendet werden. Das scripts/checkpatch.pl-Script wird im Rahmen der Gerrit-Vorabtests ausgeführt. Führen Sie es daher im Voraus aus, um sicherzustellen, dass es erfolgreich durchläuft. Wenn Sie das checkpatch-Skript mit derselben Konfiguration wie beim Presubmit-Test 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 Linux-Kernel-Codierungsstandards und den Beitragsrichtlinien entsprechen. Sie müssen in der Commit-Nachricht das Tag Change-Id angeben. Wenn Sie den Patch für mehrere Zweige 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 der LKML zur Upstream-Überprüfung ein. Wenn der Patch:

  • Wenn sie upstream akzeptiert wird, wird sie automatisch in android-mainline zusammengeführt.
  • Nicht upstream akzeptiert. Reichen Sie es bei android-mainline ein und verweisen Sie auf die Upstream-Einreichung oder erläutern Sie, warum es nicht bei LKML eingereicht wurde.

Nachdem ein Patch entweder upstream oder in android-mainline akzeptiert wurde, kann er auf das entsprechende LTS-basierte ACK 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 und sicherstellen, dass er im nächsten LTS-basierten ACK enthalten ist. Ausnahmen sind Fälle, in denen ein Upstream-Patch auf android12-5.4 zurückportiert wird, da der Patch wahrscheinlich bereits in android-mainline enthalten ist.

Upstream-Patches

Wie in den Beitragsrichtlinien angegeben, fallen Upstream-Patches für ACK-Kernel in die folgenden Gruppen (in der Reihenfolge der Wahrscheinlichkeit, dass sie akzeptiert werden).

  • UPSTREAM:: Aus „android-mainline“ ausgewählte Patches werden wahrscheinlich in ACK aufgenommen, wenn es einen angemessenen Anwendungsfall gibt.
  • BACKPORT: – Patches aus dem Upstream, die nicht sauber cherrypicken und geändert werden müssen, werden wahrscheinlich auch akzeptiert, wenn es einen angemessenen Anwendungsfall gibt.
  • FROMGIT: – Patches, die aus einem Maintainer-Branch ausgewählt wurden, um sie für die Einreichung in den Linux-Mainline vorzubereiten, können akzeptiert werden, wenn eine bevorstehende Frist eingehalten werden muss. Diese müssen sowohl für Inhalte als auch für den Zeitplan begründet werden.
  • FROMLIST:: Patches, die an die LKML gesendet, aber noch nicht in einen Maintainer-Branch aufgenommen wurden, werden wahrscheinlich nicht akzeptiert, es sei denn, die Begründung ist so überzeugend, dass der Patch unabhängig davon akzeptiert würde, ob er in Upstream-Linux landet (wir gehen davon aus, dass dies nicht der Fall ist). Es muss ein Problem mit FROMLIST-Patches vorliegen, um die Diskussion mit dem Android-Kernel-Team zu ermöglichen.

Android-spezifische Patches

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

Änderungen an gki_defconfig

Alle CONFIG-Änderungen an gki_defconfig müssen sowohl auf die arm64- als auch auf die x86-Version angewendet werden, sofern die CONFIG nicht architekturabhängig ist. Wenn Sie eine Änderung an einer CONFIG-Einstellung anfordern möchten, erstellen Sie ein Problem in der IT, um die Änderung zu besprechen. Alle CONFIG-Änderungen, die sich auf die Kernelmodulschnittstelle (Kernel Module Interface, KMI) auswirken, nachdem sie eingefroren wurde, werden abgelehnt. Wenn Partner widersprüchliche Einstellungen für eine einzelne Konfiguration anfordern, lösen wir Konflikte durch Diskussionen in den entsprechenden Fehlerberichten.

Code, der nicht im Upstream vorhanden ist

Änderungen an Code, der bereits Android-spezifisch ist, können nicht upstream gesendet werden. Obwohl der Binder-Treiber beispielsweise upstream verwaltet wird, können Änderungen an Funktionen zur Prioritätsvererbung des Binder-Treibers nicht upstream gesendet werden, da sie Android-spezifisch sind. Erkläre in deinem Fehlerbericht und Patch genau, warum der Code nicht upstream gesendet werden kann. Teilen Sie die Patches nach Möglichkeit in Teile auf, die upstream eingereicht werden können, und in Android-spezifische Teile, die nicht upstream eingereicht werden können, um die Menge an Out-of-Tree-Code zu minimieren, der in ACK verwaltet wird.

Andere Änderungen in dieser Kategorie sind Aktualisierungen von KMI-Darstellungsdateien, KMI-Symbollisten, gki_defconfig, Build-Skripten oder der Konfiguration oder anderen Skripten, die nicht upstream vorhanden sind.

Out-of-Tree-Module

Upstream-Linux rät aktiv 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 Quell- oder Binärkompatibilität im Kernel geben und keinen Code unterstützen möchten, der nicht im Baum enthalten ist. Die GKI bietet jedoch ABI-Garantien für Vendormodule, sodass KMI-Schnittstellen für die unterstützte Lebensdauer eines Kernels stabil sind. Daher gibt es eine Klasse von Änderungen zur Unterstützung von Anbietermodulen, die für ACK akzeptabel, aber nicht für Upstream akzeptabel sind.

Angenommen, ein Patch fügt EXPORT_SYMBOL_GPL()-Makros hinzu, die Module, die den Export verwenden, aber nicht im Quellbaum sind. Sie müssen versuchen, EXPORT_SYMBOL_GPL() upstream anzufordern und ein Modul bereitzustellen, das das neu exportierte Symbol verwendet. Wenn es eine gültige Begründung dafür gibt, warum das Modul nicht upstream eingereicht wird, können Sie den Patch stattdessen an ACK senden. Sie müssen im Issue begründen, warum das Modul nicht in den Upstream aufgenommen werden kann. Fordern Sie nicht die Nicht-GPL-Variante EXPORT_SYMBOL() an.

Ausgeblendete Konfigurationen

Bei einigen In-Tree-Modulen werden automatisch ausgeblendete Konfigurationen ausgewählt, die nicht in gki_defconfig angegeben werden können. Wenn beispielsweise CONFIG_SND_SOC_SOF=y konfiguriert ist, wird CONFIG_SND_SOC_TOPOLOGY automatisch ausgewählt. Um die Erstellung von Out-of-Tree-Modulen zu ermöglichen, enthält GKI einen Mechanismus zum Aktivieren verborgener 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 verborgene Konfigurationen. Wenn die Konfiguration nicht verborgen ist, muss sie in gki_defconfig entweder explizit oder als Abhängigkeit angegeben werden.

Ladbare Gouverneure

Bei Kernel-Frameworks (z. B. cpufreq), die ladbare Governors unterstützen, können Sie den Standard-Governor (z. B. den schedutil-Governor von cpufreq) überschreiben. Für Frameworks (z. B. das Thermal Framework), die keine ladbaren Governors oder Treiber unterstützen, aber dennoch eine anbieterspezifische Implementierung erfordern, erstellen Sie ein Problem im IT-System 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 Versionen konnten Sie anbieterspezifische Änderungen direkt in den Core-Kernel einfügen. Mit GKI 2.0 ist das nicht möglich, da produktspezifischer Code in Modulen implementiert werden muss und nicht im Upstream-Core-Kernel oder im ACK akzeptiert wird. Damit Partner Mehrwertfunktionen nutzen können, ohne den Kern-Kernel-Code zu beeinträchtigen, werden in GKI Vendor-Hooks akzeptiert, mit denen Module aus dem Kern-Kernel-Code aufgerufen werden können. Außerdem können wichtige Datenstrukturen mit Anbietern-Datenfeldern aufgefüllt werden, in denen anbieterspezifische Daten zur Implementierung dieser Funktionen gespeichert werden können.

Es gibt zwei Varianten von Anbieter-Hooks (normal und eingeschränkt), die auf Tracepoints (nicht Trace-Ereignissen) basieren, an die Anbietermodule angehängt werden können. Anstatt beispielsweise eine neue sched_exit()-Funktion hinzuzufügen, um beim Beenden einer Aufgabe eine Abrechnung durchzuführen, können Anbieter in do_exit() einen Hook 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, wobei name die eindeutige Kennung für den Trace ist. Gemäß der Konvention beginnen normale Vendor-Hook-Namen mit android_vh. Der Name für den sched_exit()-Hook wäre also android_vh_sched_exit.
  • Eingeschränkte Anbieter-Hooks sind für Fälle wie Scheduler-Hooks erforderlich, in denen die angehängte Funktion auch dann aufgerufen werden muss, wenn die CPU offline ist oder ein nicht atomarer Kontext erforderlich ist. Eingeschränkte Anbieter-Hooks können nicht getrennt werden. Module, die an einen eingeschränkten Hook angehängt werden, können also nie entladen werden. Namen eingeschränkter Vendor-Hooks beginnen mit android_rvh.

Wenn Sie einen Anbieter-Hook hinzufügen möchten, melden Sie ein Problem bei der IT und reichen Sie Patches ein. Wie bei allen Android-spezifischen Patches muss ein Problem vorhanden sein 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 android_vendor_data-Felder mit den ANDROID_VENDOR_DATA()-Makros 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 benötigt werden, und Feldern, die 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 Kernel-Code Anbieter-Hooks als Tracepoints hinzu, indem Sie sie mit DECLARE_HOOK() oder DECLARE_RESTRICTED_HOOK() deklarieren und dann als Tracepoint in den Code einfügen. So fügen Sie beispielsweise trace_android_vh_sched_exit() der vorhandenen Kernel-Funktion do_exit() hinzu:

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

Die Funktion trace_android_vh_sched_exit() 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 den Kontext in Bezug auf gehaltene Sperren, den RCS-Status und andere Faktoren kennen. Der Hook muss in einer Headerdatei im Verzeichnis include/trace/hooks definiert werden.

Der folgende Code enthält 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>

Um die für den Anbieter-Hook erforderlichen Schnittstellen zu instanziieren, fügen Sie die Header-Datei mit der Hook-Deklaration zu drivers/android/vendor_hooks.c hinzu und exportieren Sie die Symbole. Der folgende Code vervollständigt beispielsweise die Deklaration des android_vh_sched_exit()-Hooks.

#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 unsicher, die undurchsichtigen Zeiger zu dereferenzieren oder die Struktur in Kontexten mit fester Größe zu verwenden. Die Include-Anweisung, die die vollständige Definition solcher Datenstrukturen enthält, sollte in den #ifndef __GENKSYMS__-Abschnitt von drivers/android/vendor_hooks.c eingefügt werden. Die Headerdateien in include/trace/hooks dürfen die Kernel-Headerdatei mit den Typdefinitionen nicht enthalten, um CRC-Änderungen zu vermeiden, die das KMI beschädigen. Deklarieren Sie die Typen stattdessen vorab.

An Anbieter-Hooks anhängen

Damit Anbieter-Hooks verwendet werden können, muss im Anbietermodul ein Handler für den Hook registriert werden. Dies erfolgt in der Regel bei der Modulinitialisierung. Der folgende Code zeigt beispielsweise den Modul-Handler foo.ko für trace_android_vh_sched_exit().

#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 Header-Dateien verwenden

Wenn Sie Anbieter-Hooks aus Headerdateien verwenden möchten, müssen Sie möglicherweise die Headerdatei für Anbieter-Hooks aktualisieren, um TRACE_INCLUDE_PATH zu undefinieren. So vermeiden Sie Build-Fehler, die darauf hinweisen, dass eine Headerdatei für Trace-Punkte nicht gefunden wurde. 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 diesen Build-Fehler zu beheben, wenden Sie die entsprechende Korrektur auf die Headerdatei des Vendor-Hooks an, die Sie einbinden. 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

Durch die Definition von UNDEF_TRACE_INCLUDE_PATH wird include/trace/define_trace.h angewiesen, TRACE_INCLUDE_PATH nach dem Erstellen der Trace-Punkte zu undefinieren.

Wichtige Kernel-Funktionen

Wenn Sie mit keiner der vorherigen Techniken ein Feature aus einem Modul implementieren können, müssen Sie das Feature als Android-spezifische Änderung am Core-Kernel 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 upstream erfolgen, sofern es sich nicht um Änderungen an Android-spezifischen Schnittstellen handelt. Verwenden Sie anbieterspezifische Headerdateien, um Schnittstellen zwischen Anbietermodulen und Anbieternutzercode 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 des Android-Frameworks verwendet werden, dürfen nur auf kompatible Weise geändert werden. Wenn es sich nicht um Android-spezifische sysfs-Knoten handelt, müssen sie upstream geändert werden. Sie können anbieterspezifische Sysfs-Knoten erstellen, die vom Anbieter-Userspace verwendet werden. Standardmäßig wird der Zugriff auf sysfs-Knoten durch den Userspace mit SELinux verweigert. Es liegt im Ermessen des Anbieters, die entsprechenden SELinux-Labels hinzuzufügen, um den Zugriff durch autorisierte Anbietersoftware zu ermöglichen.
  • DebugFS-Knoten: In Vendormodulen können Knoten in debugfs nur für das Debugging definiert werden, da debugfs während des normalen Betriebs des Geräts nicht bereitgestellt wird.