Kernelcode für GKI entwickeln

Das generische Kernel-Image (GKI) reduziert die Kernel-Fragmentierung, indem es eng ausgerichtet ist. mit dem vorgelagerten Linux-Kernel. Es gibt jedoch gute Gründe, einige Patches können Upstream nicht akzeptabel sein und es gibt Produktpläne, müssen erfüllt sein, sodass einige Patches im Android Common Kernel (ACK) verwaltet werden auf denen die GKI basiert.

Entwickler müssen Codeänderungen mithilfe von Linux Kernel Mailing im Upstream einreichen. Liste (LKML) als erste Wahl auf und sende Codeänderungen an die ACK. android-mainline-Zweig nur, wenn es einen triftigen Grund gibt, warum Upstream nicht umsetzbar sind. 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 das Patch an LKML gesendet wurde, und fügen Sie Kommentare hinzu. für den Patch erhalten haben, oder eine geschätzte Zeit, in der der Patch vorgelagerte Emissionen.
    • Entscheide dich für eine Vorgehensweise, um den Patch in ACK zu erhalten und genehmigen zu lassen. und dann aus Bestätigung herausnehmen, wenn die endgültige Upstream-Version zu ACK zusammengeführt.

  • Der Patch definiert EXPORT_SYMBOLS_GPL() für ein Anbietermodul, konnte aber nicht vorgelagert werden, da es keine integrierten Module gibt, . 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 von 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 ausführen, 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 einen Change-Id hinzufügen. -Tag in der Commit-Nachricht; wenn Sie das Patch an mehrere Zweige senden (für Beispiel android-mainline und android12-5.4), müssen Sie dieselben Change-Id für alle Instanzen des Patches.

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

  • Wenn sie vorgelagert sind, wird sie automatisch mit „android-mainline“ zusammengeführt.
  • Werden nicht akzeptiert, senden Sie sie an android-mainline mit einer Ein Verweis auf die vorgelagerte Einreichung oder eine Erklärung, warum sie nicht an LKML gesendet.

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 der Patch wahrscheinlich bereits in android-mainline enthalten 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: – Patches aus „android-mainline“ werden wahrscheinlich akzeptiert, wenn es einen sinnvollen Anwendungsfall gibt.
  • BACKPORT: – Flecken aus der Upstream-Phase, die sich nicht sauber abtrennen lassen und die Sie benötigen. Änderungen werden auch akzeptiert, wenn eine angemessene Verwendung Fall.
  • FROMGIT:: Patches von einem Administrator eines Zweigs zur Vorbereitung gepflückt. für die Einreichung an Linux Mainline kann angenommen werden, wenn es eine bevorstehende Frist. Dies muss sowohl im Hinblick auf den Inhalt als auch für den Zeitplan gerechtfertigt sein.
  • 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. Das Einreichen von Patches erfordert dass Sie ein Problem in der IT anlegen, das den Patch und die Begründung dafür angibt, Der Patch kann nicht vorgelagert werden. Beispiele finden Sie in der vorherigen Liste. Es gibt jedoch einige Fälle, in denen der Code nicht vorgereicht werden kann. Diese Fälle werden im Folgenden behandelt und müssen nach dem Beitrag Richtlinien für Android-spezifische Patches und mit dem Präfix ANDROID: in der Person.

Ä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. Änderung beantragen auf eine CONFIG-Einstellung setzen, erstellen Sie ein Problem in der IT-Abteilung, um die Änderung zu besprechen. Alle CONFIG-Änderungen, die sich nach dem Einfrieren auf die Kernel-Modul-Schnittstelle (KMI) auswirken, werden abgelehnt. Wenn Partner einen Konflikt verursachen, Einstellungen für eine einzelne Konfiguration vornehmen, lösen wir Konflikte durch Diskussionen Fehler beheben.

Code, der nicht vorgelagert ist

Änderungen an Code, der bereits Android-spezifisch ist, können nicht in Upstream gesendet werden. Beispiel: Obwohl der Bindertreiber vorgelagert wird, können Änderungen an priorisierte Vererbungsfunktionen des Binder-Treibers können nicht vorgeschaltet werden. weil sie Android-spezifisch sind. Erläutern Sie in Ihrem Fehlerbericht und Patch, warum der Code nicht weitergeleitet werden kann. Teile die Patches nach Möglichkeit in einzelne Stücke, vorgelagerte Elemente und Android-spezifische Artikel, die nicht eingereicht werden können Upstream, um die Menge an Out-of-Tree-Code, der in ACK verwaltet wird, 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 aktiv vom Support 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 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 Anbieter zu unterstützen, Module, die für ACK akzeptabel, aber für Upstream nicht akzeptabel sind.

Angenommen, Sie haben einen Patch, mit dem EXPORT_SYMBOL_GPL()-Makros hinzugefügt werden, Module, die den Export verwenden, befinden sich nicht in der Quellstruktur. 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 integrierte Module wählen automatisch ausgeblendete Konfigurationen aus, die nicht angegeben werden können in „gki_defconfig“. Beispiel: CONFIG_SND_SOC_TOPOLOGY ist ausgewählt automatisch, wenn CONFIG_SND_SOC_SOF=y konfiguriert ist. Um Out-of-Tree-Modulerstellung bietet GKI einen Mechanismus, mit dem versteckte Konfigurationen aktiviert werden können.

Um eine ausgeblendete Konfiguration zu aktivieren, fügen Sie in init/Kconfig.gki eine select-Anweisung hinzu, basierend auf der Kernel-Konfiguration CONFIG_GKI_HACKS_TO_FIX automatisch ausgewählt, 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.

Gouverneure zum Laden

Für Kernel-Frameworks (z. B. cpufreq), die ladebare Governoren unterstützen, kann den Standard-Gouverneur überschreiben (z. B. den schedutil-Gouverneur 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. Darüber hinaus können wichtige Datenstrukturen mit Anbieterdatenfelder, in denen anbieterspezifische Daten für die Implementierung gespeichert werden können diese Funktionen.

Es gibt zwei Varianten von Anbieter-Hooks (normal und eingeschränkt), die auf Tracepoints (keine Trace-Ereignisse), an die Anbietermodule angehängt werden können. Beispiel: anstatt eine neue sched_exit()-Funktion hinzuzufügen, um bei der Aufgabe eine Ressourcenerfassung vorzunehmen. Exit können Anbieter einen Hook in do_exit() hinzufügen, an den ein Anbietermodul angehängt werden kann. zu verarbeiten. Eine Beispielimplementierung enthält die folgenden Anbieter-Hooks.

  • Normale Anbieter-Hooks verwenden DECLARE_HOOK(), um eine Tracepoint-Funktion zu erstellen mit dem Namen trace_name, wobei name ist die eindeutige Kennung für die Trace. Konventionsgemäß beginnen normale Namen von Anbieter-Hooks mit android_vh, sodass lautet der Name für den sched_exit()-Hook 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.

Um einen Anbieter-Hook hinzuzufügen, melden Sie ein Problem in der IT und reichen Sie Patches ein (wie bei allen Android-spezifische Patches, ein Problem muss vorhanden sein und Sie müssen Begründung). 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 wichtigen Datenstrukturen zuordnen, indem Sie android_vendor_data-Felder mit den ANDROID_VENDOR_DATA()-Makros. Für Um zusätzliche Funktionen zu unterstützen, hängen Sie beispielsweise Felder wie gezeigt an Strukturen an. im folgenden Codebeispiel.

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. Um beispielsweise trace_android_vh_sched_exit() zum vorhandene do_exit()-Kernelfunktion:

#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. Registriert ein Anbietermodul einen Handler jedoch mithilfe von register_trace_android_vh_sched_exit() 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 stellt 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>

Fügen Sie die Headerdatei hinzu, um die für den Anbieter-Hook erforderlichen Schnittstellen zu instanziieren mit der Hook-Deklaration in drivers/android/vendor_hooks.c und exportieren Sie die . Beispielsweise vervollständigt der folgende Code die Deklaration des android_vh_sched_exit()-Hook.

#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 innerhalb der Hook-Deklaration verwendet werden, müssen vollständig definiert, um die ABI-Stabilität zu gewährleisten. Andernfalls ist es nicht sicher, dereferenzieren die undurchsichtigen Zeiger oder verwenden die Struktur in einem größeren Kontext. Das Include, das die vollständige Definition solcher Datenstrukturen enthält, sollte sich im Abschnitt #ifndef __GENKSYMS__ von drivers/android/vendor_hooks.c befinden. Der Header Dateien in include/trace/hooks sollten nicht die Kernel-Header-Datei mit dem geben Sie Definitionen ein, um CRC-Änderungen zu vermeiden, die die KMI beeinträchtigen. Stattdessen vorwärts die Typen deklariert werden.

An Anbieter-Hooks anhängen

Zur Verwendung von Anbieter-Hooks muss das Anbietermodul einen Handler für den Hook registrieren (normalerweise 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.

Wenden Sie die entsprechende Fehlerkorrektur auf den Anbieter-Hook an, um diesen Build-Fehler zu beheben. enthalten. 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 Festlegen von UNDEF_TRACE_INCLUDE_PATH wird include/trace/define_trace.h angewiesen, TRACE_INCLUDE_PATH nach dem Erstellen der Trace-Punkte nicht mehr definieren.

Kernel-Hauptfunktionen

Wenn keine der vorherigen Techniken es Ihnen ermöglicht, eine Funktion aus einem Modul zu implementieren, müssen Sie die Funktion als Android-spezifische Modifikation Kernel. Erstellen Sie ein Problem im Issue Tracker (IT), um das Gespräch zu beginnen.

User Application Programming Interface (UAPI)

  • UAPI-Headerdateien: Änderungen an UAPI-Headerdateien muss vorgelagert sein, es sei denn, die Änderungen betreffen Android-spezifische Schnittstellen. Schnittstellen mit anbieterspezifischen Header-Dateien definieren zwischen den Anbietermodulen und dem Userspace-Code des Anbieters.
  • sysfs-Knoten Fügen Sie dem GKI-Kernel keine neuen sysfs-Knoten hinzu, sind nur in Anbietermodulen gültig). sysfs-Knoten, die vom SoC- und geräteunabhängige Bibliotheken und Java-Code, die das Android-Framework bilden dürfen nur auf kompatible Weise geändert werden und müssen vorgelagert werden, wenn Es sind keine Android-spezifischen sysfs-Knoten. Sie können anbieterspezifische sysfs-Knoten, die vom Nutzerbereich des Anbieters verwendet werden. Standardmäßig Der Zugriff auf Sysfs-Knoten nach Userspace wird 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.