%
% Thomas Kuschel 2023
\newcommand{\version}{V6.6}
\documentclass[10pt,a4paper]{article}
%\documentclass[12pt,a4paper]{report}
\usepackage[a4paper,margin=25mm]{geometry}
\usepackage[ngerman]{babel} %Verwendung von \glqq \qrgg{}
\usepackage{hyperref}
\setcounter{secnumdepth}{5}%numbering down to paragraphs, subparagraphs
%% \usepackage{ulem} %strike through with /sout{}
% you have to install texlive-plaingeneric first :
\usepackage{ulem}

% Hurenkinder und Schusterjungen verhindern
%\clubpenalty10000
%\widowpenalty10000
%\displaywidowpenalty=10000

% The following is to use subparagraph without intending:
\makeatletter
\renewcommand\subparagraph{%
 \@startsection {subparagraph}{5}{\z@ }{3.25ex \@plus 1ex
 \@minus .2ex}{-1em}{\normalfont \normalsize \bfseries }}%
\makeatother

\begin{document}

\section*{Linux Configuration \version}
\subsection{Einführung}
Dieses Dokument dient zur Beschreibung von diversen Einstellungen
bei der Konfiguration mittels \texttt{ make menuconfig } unter Linux.\\
Es wird nicht näher darauf eingegangen, wie der Kernel kompiliert wird
oder welche Voreinstellungen, Programme etc. zum Kompilieren benötigt
werden.\\
Zu Beginn der jeweiligen Konfigurationszeile wird der Standardwert
(Default) angezeigt. Mein Vorschlag folgt danach.\\
Z.\,B. bei CONFIG\_WERROR~[=n]~\textbf{[Y]}\\
Hier ist der Standarwert ein Nein [n], meine persönliche Einstellung ein Ja [Y].\\[0.5em]
\textit{\copyright KW4NZ, Thomas Kuschel\\Wenn Sie Tippfehler finden oder Korrekturen wünschen,
dann schicken Sie dies mit Erläuterungen und dem Hinweis auf die obenstehende
Version \version ~an:
\href{mailto:oe1tkt@gmail.com}{oe1tkt@gmail.com}}
%\section{General setup \( \rightarrow \) }
\section{General setup \texorpdfstring{$\rightarrow$}{->}}

\subsection{Compile also drivers which will not load}
CONFIG\_COMPILE\_TEST [=n] \textbf{[~]}\\
\textit{Kompilieren Sie auch Treiber, die nicht geladen werden können}\\
Einige Treiber können auf einer anderen Plattform kompiliert werden als
auf der, für die sie gedacht sind. Obwohl sie dort nicht geladen werden
können (oder selbst wenn sie geladen werden können, können sie aufgrund
fehlender Hardware-Unterstützung nicht verwendet werden), möchten
Entwickler, im Gegensatz zu Distributoren, solche Treiber vielleicht
trotzdem kompilieren und testen.

\subsection{Compile the kernel with warnings as errors}
CONFIG\_WERROR [=n] \textbf{[Y]}\\
\textit{Den Kernel mit Fehlermeldungen bei Warnungen kompilieren}\\
Ein Build sollte keine Compiler-Warnungen ausgeben, dies aktiviert die
Flags '-Werror' (für C) und '-Dwarnings' (für Rust) um diese Regel
standardmäßig zu setzen. Bestimmte Warnungen von anderen Tools z.~B. der
Linker könnte mit dieser Option Fehler generieren. Deaktivieren ist
sinnvoll, wenn Sie einen neuen (oder sehr alten) Compiler bzw. Linker
mit seltenen, ungewöhnlichen Warnungen haben. Haben Sie auf Ihrer
Architektur Probleme, dann müssen Sie diese Konfiguration deaktivieren,
um den Kernel erfolgreich zu bauen. Im Zweifelsfall sagen sie Y für Ja.

\subsection{Local version -- append to kernel release}
CONFIG\_LOCALVERSION [=] \textbf{[~]}\\
\textit{Lokale Version -- an die Kernelversion anhängen}\\
Type: string\\
Hängen Sie eine zusätzliche Zeichenkette an das Ende Ihrer Kernelversion
an.\\
Dies wird angezeigt, wenn Sie z.\,B. \texttt{uname} eingeben. Die hier
angegebene Zeichenfolge wird an den Inhalt von einem Dateinamen mit
\texttt{localverion*} als Objekt und im Quellbaum, in dieser Reihenfolge
angezeigt. Die Zeichenkette darf maximal 64 Zeichen lang sein.

\subsection{Automatically append version information to the version string}
CONFIG\_LOCALVERSION\_AUTO [=y] \textbf{[Y]}\\
Dies versucht automatisch festzustellen, ob der aktuelle Baum ein
Release-Tree ist, indem es nach \textbf{Git}-Tags sucht, die zur aktuellen
Top-of-Tree-Revision gehören.\\
Eine Zeichenkette des Formats \texttt{-gxxxxxxxx} wird der lokalen Version
hinzugefügt, wenn ein git-basierter Baum gefunden wird.  Die so erzeugte
Zeichenkette wird nach allen passenden \glqq localversion*\grqq -Dateien
und nach dem in CONFIG\_LOCALVERSION eingestellten Wert angehängt. (Die hier
tatsächlich verwendete Zeichenkette sind die ersten 12 Zeichen, die durch
die Ausführung des Befehls erzeugt werden:\\
\indent\texttt{\$ git rev-parse --verify HEAD}\\
der innerhalb des Skripts \glqq scripts/setlocalversion\grqq{}  ausgeführt wird.)
\subsection{Build ID Salt}
CONFIG\_BUILD\_SALT [=] \textbf{[~]}\\
Type: string\\
Dies wird verwendet, um die Binaries und ihre Debug-Infos zu verknüpfen.
Wenn diese Option gesetzt ist, dann wird dieser Wert in die Berechnung der
Build-ID einbezogen. Wird von Distributionen verwendet, die sicherstellen 
wollen, dass es eineindeutige IDs zwischen verschiedenen Builds gibt.
Üblicherweise brauchen wir das nicht.

\subsection{Kernel compression mode \texorpdfstring{$\rightarrow$}{->}}
Der Linux-Kernel ist eine Art selbstextrahierende, ausführbare Datei.
Es stehen mehrere Kompressionsalgorithmen zur Verfügung, die sich in
Effizienz, Kompressions- und Dekompressionsgeschwindigkeit unterscheiden.
Die Komprimierungsgeschwindigkeit ist nur bei der Erstellung eines Kernels
relevant. Die Dekomprimierungsgeschwindigkeit ist bei jedem Systemstart
von Bedeutung. (Eine ältere Version dieser Funktionalität (nur bzip2)
für 2.4 wurde von Christian Ludwig bereitgestellt)
Hohe Komprimierungsoptionen sind vor allem für Benutzer nützlich, die
wenig Festplattenplatz zur Verfügung haben (embedded systems), für die
aber die Ram-Größe weniger wichtig ist.\\
Überblick: Gzip werden von den älteren Kernelversionen unterstützt,\\
Arch Linux (since Linux/x86 5.9.0) Standard: ZSTD (former: XZ since 4.14.4, predecessor GZIP,XZ)\\
Debian 11.6: XZ\\
@TODO Weitere Linux Distributionen
\subsubsection{Gzip}
CONFIG\_KERNEL\_GZIP [=n] \textbf{[~]}\\
Die alte und bewährte gzip-Kompression. Sie bietet ein gutes
Gleichgewicht zwischen Kompressionsrate und
Dekompressionsgeschwindigkeit.
\subsubsection{Bzip2}
CONFIG\_KERNEL\_BZIP2  [=n] \textbf{[~]}\\
Die Kompressionsrate und auch die Geschwindigkeit der ist durchschnittlich. Die Geschwindigkeit
der Dekomprimierung ist die langsamste. Größe des Kernels ist etwa 10~\% kleiner
im Vergleich zu GZIP. Es benötigt auch einen großen Speicherbereich, bei 
modernen Kerneln benötigt man zumindest 8~MB~RAM oder mehr beim Booten.
\subsubsection{LZMA}
CONFIG\_KERNEL\_LZMA [=n] \textbf{[~]}\\
Dieser Kompressionsalgorithmus hat die höchste Komprimierung. Die Geschwindigkeit der
Dekomprimierung liegt zwischen GZIP und BZIP2.
Komprimierung ist die langsamste. Kernelgröße beträgt etwa 33~\% weniger als mit GZIP.
\subsubsection{XZ}
CONFIG\_KERNEL\_XZ [=n] \textbf{[~]}\\
XZ verwendet den LZMA2-Algorithmus und befehlssatzspezifische
BCJ-Filter, die das Komprimierungsverhältnis des ausführbaren
Codes verbessern können. Die Größe des Kernels ist mit XZ im
Vergleich zu GZIP etwa 30~\% kleiner. Auf Architekturen, für die
es einen BCJ-Filter gibt (i386, x86\_64, ARM, IA-64, PowerPC und
SPARC), erzeugt XZ einen um einige Prozent kleineren Kernel als
einfaches LZMA.
Die Geschwindigkeit ist in etwa die gleiche wie bei LZMA: Die Dekomprimierungsgeschwindigkeit von
XZ ist besser als die von bzip2, aber schlechter als die von gzip und LZO.
Die Komprimierung ist langsam.
\subsubsection{LZO}
CONFIG\_KERNEL\_LZO [=n] \textbf{[~]}\\
Kompressionsrate ist die schlechteste aller anderen. Kernelgröße ist etwa 10~\% größer als GZIP.
Jedoch ist die Geschwindigkeit beim Komprimieren und Dekomprimieren die höchste.

\subsubsection{LZ4}
CONFIG\_KERNEL\_LZ4  [=n] \textbf{[~]}\\
LZ4 ist eine LZ77-Typ-Komprimierung mit einer festen, byte-orientierten Enkodierung.\\
Siehe auch \url{http://code.google.com/p/lz4}.\\
Komprimierungsverhältnis ist noch schlechter als LZO. 8~\% größere Kernelgröße als bei LZO.
Dekomprimierung ist jedoch von der Geschwindigkeit her schneller als LZO.

\subsubsection{ZSTD}
CONFIG\_KERNEL\_ZSTD [=y] \textbf{[Y]}\\
ZSTD ist ein Komprimierungsalgorithmus, der auf eine Zwischenkomprimierung
mit schneller Dekomprimierungsgeschwindigkeit abzielt. Er
komprimiert besser als GZIP und dekomprimiert etwa so schnell wie
LZO, ist aber langsamer als LZ4. Sie benötigen mindestens
192~KB~RAM oder mehr zum Booten. Das Kommandozeilenprogramm \texttt{zstd}
ist für die Komprimierung erforderlich.

\subsection{Default init path}
CONFIG\_DEFAULT\_INIT [=] \textbf{[~]}\\
Diese Option legt den Standard-Init-Pfad für das System fest,
wenn in der Kernel-Befehlszeile keine solche init=-Option übergeben wird.
Wenn der angeforderte Pfad nicht vorhanden ist, wird trotzdem versucht,
weitere Orte zu finden (z.~B. /sbin/init usw.). Wenn dieser Pfad leer ist,
wird einfach die Fallback-Liste verwendet, wenn init= nicht übergeben wird.

\subsection{Default hostname}
CONFIG\_DEFAULT\_HOSTNAME [=archlinux] \textbf{[=archlinux]}\\
Diese Option legt den Standard-Hostnamen des Systems fest,
noch bevor der Userspace das Kommando sethostname(2) aufruft.
Der Kernel verwendet hier traditionell ''(none)'', Sie möchten
vielleicht eine andere Voreinstellung verwenden, um ein minimales
System mit weniger Konfiguration benutzbar zu machen.

\subsection{System V IPC}
CONFIG\_SYSVIPC [=y] \textbf{[Y]}\\
Die Inter-Prozess-Kommunikation IPC ist eine Zusammenstellung
aus Bibliotheksfunktionen (libraries) und Systemaufrufen die Prozesse (laufende Programme)
synchronisiert und Daten untereinander austauschen kann. Generell ist das eine gute Sache,
einige Programme würden auch nicht funktionieren wenn Sie hier kein Y (ja) setzen.

\subsection{POSIX Message Queues}
CONFIG\_POSIX\_MQUEUE [=y] \textbf{[Y]}\\
Die POSIX-Variante der Nachrichtenwarteschlangen (message queues) ist ein Teil der IPC.
In POSIX-Nachrichtenwarteschlangen hat jede Nachricht eine Priorität, die über die Reihenfolge
des Empfangs durch einen Prozess entscheidet. Wenn Sie Programme kompilieren und ausführen wollen,
die z.~B. für Solaris geschrieben wurden und die POSIX-Warteschlangen (Funktionen mq\_\*) verwenden,
sagen Sie hier Y.
POSIX-Nachrichtenwarteschlangen sind via Dateisystem als \glqq mqueue\grqq{}  sichtbar und können irgendwo
eingehängt werden, wenn Sie Dateisystemoperationen auf Nachrichtenwarteschlangen durchführen wollen.

\subsection{General notification queue}
CONFIG\_WATCH\_QUEUE [=y] \textbf{[Y]}\\
Dies ist eine allgemeine Benachrichtigungswarteschlange für den Kernel,
um Ereignisse an den Userspace weiterzuleiten, indem sie in Pipes gesplittet werden.
Sie kann in Verbindung mit Watches für Schlüssel-/Schlüsseländerungsbenachrichtigungen (key/keyring) und
Gerätebenachrichtigungen verwendet werden.\\
Bemerkung: Bei Debian Bullseye ist dies nicht gesetzt (N).

\subsection{Enable process\_vm\_readv/writev\ syscalls}
CONFIG\_CROSS\_MEMORY\_ATTACH [=y] \textbf{[Y]}\\
Die Aktivierung dieser Option fügt die Systemaufrufe process\_vm\_readv und
process\_vm\_writev hinzu, die es einem Prozess mit den richtigen Rechten ermöglichen,
direkt aus dem Adressraum eines anderen Prozesses zu lesen oder in diesen zu schreiben.
Weitere Einzelheiten finden Sie in der Manpage.

\subsection{uselib syscall (for libc5 and earlier)}
CONFIG\_USELIB [=n] \textbf{[N]}\\
Diese Option schaltet den uselib-Systemaufruf ein, der im dynamic-Linker von libc5 und früher verwendet wird.
Das aktuelle glibc verwendet diesen Systemaufruf nicht mehr, deshalb kann man diese Option
ausschalten wenn sie
keine Programme mehr verwenden, die auf libc5 (oder früher) compiliert wurden.\\
Bemerkung: Debian Bullseye verwendet dies noch (Y).

\subsection{Auditing support}
CONFIG\_AUDIT [=y] \textbf{[Y]}\\
Aktivieren Sie eine Überwachungsinfrastruktur, die mit einem anderen Kernel-Subsystem
verwendet werden kann, wie z.~B. SELinux (das dies für die Protokollierung der Ausgabe
von avc-Nachrichten benötigt).  Die Systemaufrufüberprüfung ist auf Architekturen,
die sie unterstützen, enthalten.

\subsection{IRQ subsystem  \texorpdfstring{$\rightarrow$}{->}}
Über diese Schnittstelle kann man Funktionen und Parameter für den
Kernelbau auswählen.
Merkmale können entweder eingebaut, modularisiert oder ignoriert werden.
Parameter müssen als dezimale oder hexadezimale Zahlen oder als Text eingegeben
werden.

\subsubsection{Expose irq internals in debugfs}
CONFIG\_GENERIC\_IRQ\_DEBUGFS [=n] \textbf{[N]}\\
Legt interne Zustandsinformationen über debugfs offen.
Hauptsächlich für Entwickler und zur Fehlersuche bei schwer
zu diagnostizierenden Interrupt-Problemen.

\subsection{Timers subsystem \texorpdfstring{$\rightarrow$}{->}}
\subsubsection{Timer tick handling \texorpdfstring{$\rightarrow$}{->}}
Sie müssen aus den folgenden drei Möglichkeiten eine wählen:
\paragraph{Periodic timer ticks (constant rate, no dynticks)} $~$ \\
CONFIG\_HZ\_PERIODIC [=n] \textbf{[N]}\\
Diese Option sorgt dafür, dass der Tick periodisch mit einer konstanten Rate läuft,
auch wenn die CPU ihn nicht braucht.
\paragraph{Idle dynticks system (tickless idle)} $~$ \\
CONFIG\_NO\_HZ\_IDLE [=n] \textbf{[N]}\\
Diese Option ermöglicht ein tickloses idle-System (Leerlaufsystem):
Timer-Interrupts werden nur bei Bedarf ausgelöst, wenn das System im
Leerlauf ist. Dies ist v.a. zum Energiesparen interessant.
\paragraph{Full dynticks system (tickless)} $~$ \\
CONFIG\_NO\_HZ\_FULL [=y] \textbf{[Y]}\\
Diese Option ermöglicht ein tickloses idle-System (Leerlaufsystem):
Timer-Interrupts werden nur bei Bedarf ausgelöst, wenn das System im
Leerlauf ist. Dies ist v.a. zum Energiesparen interessant.\\
Wird bei Linux-Distributionen ausgewählt.

\subsubsection{Force user context tracking}
CONFIG\_CONTEXT\_TRACKING\_USER\_FORCE [=n] \textbf{[N]}\\
Die wichtigste Voraussetzung für das Funktionieren von Full-Dynticks ist die
Unterstützung des Subsystems zur Verfolgung des Benutzerkontextes.
Es gibt aber auch noch andere Abhängigkeiten, die erfüllt werden müssen, damit
die vollständigen Dynticks funktionieren.\\
Diese Option dient zum Testen, wenn eine Systemarchitektur das Backend für die
Benutzerkontextverfolgung implementiert, aber noch nicht alle Anforderungen erfüllt,
um die volle Dynticks-Funktion zu ermöglichen.
Ohne die vollständigen Dynticks gibt es keine Möglichkeit,
die Unterstützung für die Benutzerkontextverfolgung und die Teilsysteme,
die darauf angewiesen sind, zu testen: RCU Userspace extended quiescent state
und tickless cputime accounting. Diese Option kommt mit dem Fehlen des vollständigen
dynticks-Subsystems zurecht, indem sie die Benutzerkontextverfolgung auf
allen CPUs im System erzwingt.

Sagen Sie nur dann ja (Y), wenn Sie an der Entwicklung eines Architektur-Backends
für die Benutzerkontextverfolgung arbeiten.
Sagen Sie ansonsten N, da diese Option einen Overhead mit sich bringt, den Sie in
der Praxis nicht haben wollen.

\subsubsection{Old Idle dynticks config}
CONFIG\_NO\_HZ [=y] \textbf{[N]}
\textit{Alte Leerlauf-Dynticks-Konfiguration}\\
Dies ist der alte Konfigurationseintrag, der Dynticks im Leerlauf aktiviert.
\sout{Wir behalten ihn noch eine Weile bei, um die Abwärtskompatiblität mit älteren
Konfigurations\-dateien zu gewähr\-leisten.}

\subsubsection{High Resolution Timer Support}
CONFIG\_HIGH\_RES\_TIMERS [=y] \textbf{[Y]}\\
\textit{Unterstützung von Timern mit hoher Auflösung}\\
Diese Option aktiviert die Unterstützung hochauflösender Timer.
Wenn ihre Hardware dazu nicht in der Lage ist, erhöht diese
Option nur die Größe des Kernel-Images.

\subsubsection{Clocksource watchdog maximum allowable skew}
CONFIG\_CLOCKSOURCE\_WATCHDOG\_MAX\_SKEW\_US [=100] \textbf{[100]}\\
\textit{Maximal zulässige Abweichung der Watchdog-Taktquelle}\\
Geben Sie den maximal zulässigen Wert für den Watchdog-Versatz
in Mikrosekunden an, bevor die Clocksource als instabil gemeldet wird.
Der Standardwert basiert auf einem Watchdog-Intervall von einer halben
Sekunde und der maximalen Frequenzdrift von NTP von 500 Teilen pro Million.
Wenn die Clocksource gut genug für NTP ist, ist sie auch gut genug
für den Watchdog der Clocksource!\\
Range:  50 -- 1000

\subsection{BPF subsystem \texorpdfstring{$\rightarrow$}{->}}
Berkeley Packet Filter, Firewall-Filtertechnik im Kernel

\subsubsection{Enable bpf() system call}
CONFIG\_BPF\_SYSCALL [=y] \textbf{[Y]}\\
Aktivieren Sie den Systemaufruf bpf(), der es ermöglicht,
BPF-Programme und -Maps über Dateideskriptoren zu manipulieren.

\subsubsection{Enable BPF Just In Time compiler}
CONFIG\_BPF\_JIT [=y] \textbf{[Y]}\\
BPF-Programme werden normalerweise von einem BPF-Interpreter verarbeitet.
Diese Option ermöglicht es dem Kernel, nativen Code zu erzeugen,
wenn ein Programm in den Kernel geladen wird. Dadurch wird die Verarbeitung
von BPF-Programmen erheblich beschleunigt.\\
Beachten Sie, dass ein Administrator diese Funktion durch Ändern aktivieren sollte:\\[0.5em]                                                   
\indent\texttt{/proc/sys/net/core/bpf\_jit\_enable}\\
\indent\texttt{/proc/sys/net/core/bpf\_jit\_harden (optional)}\\
\indent\texttt{/proc/sys/net/core/bpf\_jit\_kallsyms (optional)}

\paragraph{Permanently enable BPF JIT and remove BPF interpreter}$~$\\
CONFIG\_BPF\_JIT\_ALWAYS\_ON [=y] \textbf{[Y]}\\
Aktiviert BPF JIT und entfernt den BPF-Interpreter um spekulative Ausführungen
von BPF-An\-wei\-sun\-gen durch den Interpreter zu verhindern.
Wenn CONFIG\_BPF\_JIT\_ALWAYS\_ON eingeschaltet ist, dann wird
\texttt{/proc/sys/net/core/bpf\_jit\_enable} permanent auf 1 gesetzt, alle
Versuche diese Einstellung auf andere Werte zu legen wird mit einem Fehler
zurückgewiesen.
\subsubsection{Disable unprivileged BPF by default}
CONFIG\_BPF\_UNPRIV\_DEFAULT\_OFF [=y] \textbf{[Y]}\\
Deaktiviert die unprivilegierte BPF standardmäßig, indem der entsprechende Eintrag\\
\texttt{/proc/sys/kernel/unprivileged\_bpf\_disabled} auf 2 gesetzt wird.
Ein Administrator kann sie immer noch wieder aktivieren,
indem er sie später auf 0 setzt, oder sie dauerhaft deaktiviert, indem
er sie auf 1 setzt (von wo aus kein weiterer Übergang auf 0 mehr möglich ist).\\
Unprivilegierte BPF könnte verwendet werden, um bestimmte potenzielle Seitenkanalschwachstellen
für spekulative Ausführung auf nicht gemilderter betroffener Hardware auszunutzen.
Wenn Sie unsicher sind, wie Sie diese Frage beantworten sollen, antworten Sie mit Y.
\subsubsection{Preload BPF file system with kernel specific program
 and map iterators \texorpdfstring{$\rightarrow$}{->}}
BPF\_PRELOAD [=n] \textbf{[N]}\\
Dadurch wird ein Kernelmodul mit mehreren eingebetteten BPF-Programmen erstellt,
die als für den Menschen lesbare Dateien in den BPF-FS-Einhängepunkt
eingefügt werden, was bei der Fehlersuche und der Untersuchung von BPF-Programmen
und -Maps nützlich ist.
\paragraph{bpf\_preload kernel module\\} $~$ \\
\textit{Dies ist nur sichtbar wenn der übergeordnete Punkt aktiviert ist.}\\
CONFIG\_BPF\_PRELOAD\_UMD [=m] \textbf{[~]}\\
Dadurch wird ein Kernelmodul mit mehreren eingebetteten BPF-Programmen
erstellt, die als für den Menschen lesbare Dateien in den BPF-FS-Einhängepunkt eingefügt werden,
was bei der Fehlersuche und der Untersuchung von BPF-Programmen und -Maps nützlich ist.
\subsubsection{Enable BPF LSM Instrumentation}
CONFIG\_BPF\_LSM [=y] \textbf{[Y]}\\
Ermöglicht die Instrumentierung der Sicherheitshaken mit BPF-Programmen zur Implementierung dynamischer
MAC- und Prüfungsrichtlinien. Wenn Sie unsicher sind, wie Sie diese Frage beantworten
sollten, antworten Sie mit N.
\subsection{Preemption Model (Preemptible Kernel (Low-Latency Desktop)) \texorpdfstring{$\rightarrow$}{->}}

Eingestellt auf : Low-Latency, d.h. nur kleine Verzögerungen beim Modell des Multitaskings.
Es gibt drei Einstellungen:
\subsubsection{No Forced Preemption (Server)}
CONFIG\_PREEMPT\_NONE [=n] \textbf{[N]}\\
Das war das traditionelle Linux Modell der Unterbrechungen, das sich auf den Durchsatz konzentrierte.
Wird vor allem für den Server-Einsatz verwendet. Es gibt durchaus gute Performance für die Latenz, jedoch
keine Garantie dafür und es kann zu zufälligen, längeren Verzögerungszeiten kommen.

Für einen Serverbetrieb wird diese Einstellung empfohlen, damit der maximale Durchsatz an Rechenleistung
entsteht.
\subsubsection{Voluntary Kernel Preemption (Desktop)}
CONFIG\_PREEMPT\_VOLUNTARY [=n] \textbf{[N]}\\
Diese Einstellung reduziert die Latenz des Kernels durch zusätzliche \glqq explizite Unterbrechungspunkte\glqq{}
im Kernel.
Diese neuen Unterbrechungspunkte wurden ausgewählt, um die maximale Latenz beim neuerlichen Zuordnen
des Schedulers zu reduzieren und dadurch schnelle Reaktionszeiten der Applikationen zu gewährleisten. --
Auf Kosten eines geringeren Durchsatzes wird dies erreicht.
\subsubsection{Preemptible Kernel (Low-Latency Desktop)}
CONFIG\_PREEMPT [=y] \textbf{[Y]}\\
Bei dieser Einstellung wird die Latenz des Kernels weiter erniedrigt indem der gesamte Code des Kernels
(keine kritischen, geschützten Bereiche) unterbrechbar gemacht wird. Dadurch wird ein reibungsloses
Arbeiten mit Applikationen aus Nutzersicht erreicht, sogar unter Volllast.
Wähle diese Einstellung, wenn man einen Desktop oder ein Embedded-System mit einer Latenz im
Millisekundenbereich möchte. Natürlich geht diese Einstellung mit einem leicht geringerem Durchsatz an
Rechenleistung einher.
\subsection{Preemtion behaviour defined on boot}
CONFIG\_PREEMPT\_DYNAMIC [=y] \textbf{[Y]}\\
Diese Option ermöglicht es, das Präemptionsmodell über den
Kernel-Kommandozeilenparameter zu definieren und damit das
während der Kompilierung definierte Standard-Präemptionsmodell
außer Kraft zu setzen.
Diese Funktion ist vor allem für Linux-Distributionen
interessant, die eine vorgefertigte Kernel-Binärdatei
bereitstellen, um die Anzahl der angebotenen Kernel-Varianten
zu reduzieren und dennoch verschiedene Anwendungsfälle zu
ermöglichen.

Der Laufzeit-Overhead ist vernachlässigbar, wenn
HAVE\_STATIC\_CALL\_INLINE aktiviert ist, aber wenn Laufzeit-Patching
für die spezifische Architektur nicht verfügbar ist,
sollte der potenzielle Overhead in Betracht gezogen werden.
Interessant wird es, wenn derselbe vorgefertigte Kernel
sowohl für Server- als auch für Desktop-Workloads verwendet
werden soll.
\subsection{Core Scheduling for SMT}
CONFIG\_SCHED\_CORE [=y] \textbf{[Y]}\\
Kern-Scheduling für SMT

Diese Option ermöglicht Core Scheduling, ein Mittel zur
koordinierten Auswahl von Aufgaben zwischen SMT-Geschwistern.
Wenn diese Option aktiviert ist - siehe prctl
(PR\_SCHED\_CORE)
 - stellt die Aufgabenauswahl sicher, dass alle SMT-Geschwister
eine Aufgabe aus der gleichen \glqq Kerngruppe\grqq{} ausführen und
den Leerlauf erzwingen, wenn keine passende Aufgabe gefunden
wird.
Diese Funktion wird unter anderem verwendet:

- Entschärfung einiger (nicht aller) SMT-Seitenkanäle;

- Begrenzung der SMT-Interferenz zur Verbesserung des Determinismus und/oder der Leistung.\\
SCHED\_CORE ist standardmäßig deaktiviert. Wenn es aktiviert und unbenutzt ist, was
bei Linux-Distributionen wahrscheinlich der Fall ist,
sollte es keine messbaren Auswirkungen auf die Leistung
haben.

\subsection{CPU/Task time and stats accounting \texorpdfstring{$\rightarrow$}{->}}

\subsubsection{Cputime accounting (Full dynticks CPU time accounting) \texorpdfstring{$\rightarrow$}{->}}
\paragraph{Full dynticks CPU time accounting} $~$\\
CONFIG\_VIRT\_CPU\_ACCOUNTING\_GEN [=y] \textbf{[Y]}\\
Wählen Sie diese Option, um die Berechnung der Task- und CPU-Zeit auf
Full-Dynticks-Systemen zu aktivieren.
Diese Berechnung wird durch die Überwachung aller Kernel-Benutzer-Grenzen mithilfe des
Kontextverfolgungs-Subsystems implementiert.\\
Die Berechnung erfolgt daher auf Kosten eines erheblichen Overheads.\\
Im Moment ist dies nur sinnvoll, wenn Sie an der Entwicklung des vollständigen
Dynticks-Subsystems arbeiten.

\subsubsection{Fine granularity task level IRQ time accounting}
CONFIG\_IRQ\_TIME\_ACCOUNTING [=y] \textbf{[Y]}\\
Wählen Sie diese Option aus, um eine fein granulare Berechnung der
Task-Irq-Zeit zu aktivieren.
Dies geschieht durch das Lesen eines Zeitstempels bei jedem Übergang
zwischen dem softirq- und dem hardirq-Zustand, so dass es zu geringen
Leistungseinbußen kommen kann.\\
Im Zweifelsfall sagen Sie hier N für Nein. 

\subsubsection{BSD Process Accounting}
CONFIG\_BSD\_PROCESS\_ACCT [=y] \textbf{[Y]}\\
Wenn Sie hier Y (für Ja) angeben, kann ein Programm auf Benutzerebene den Kernel
(über einen speziellen Systemaufruf) anweisen, Prozessabrechnungsinformationen
in eine Datei zu schreiben: Jedes Mal, wenn ein Prozess beendet wird, werden
Informationen über diesen Prozess vom Kernel an die Datei angehängt.
Die Informationen beinhalten Dinge wie die Erstellungszeit, den besitzenden
Benutzer, den Befehlsnamen, den Speicherverbrauch, das kontrollierende Terminal
usw. (die vollständige Liste kann in der acct-Struktur in
\textless{}file:include/linux/acct.h\textgreater{} gefunden werden).
Es obliegt dem Programm auf Benutzerebene, nützliche Dinge mit diesen
Informationen zu tun. Dies ist im Allgemeinen eine gute Idee, also sagen
Sie Y für Ja.

\paragraph{BSD Process Accounting version 3 file format} $~$\\
CONFIG\_BSD\_PROCESS\_ACCT\_V3 [=y] \textbf{[Y]}\\
Wenn Sie hier Y (für Ja) angeben, werden die Prozessabrechnungsinformationen
in ein neues Dateiformat geschrieben, das auch die Prozess-IDs der einzelnen
Prozesse und ihrer Eltern protokolliert. Beachten Sie, dass dieses
Dateiformat nicht mit den früheren v0/v1/v2-Dateiformaten kompatibel ist,
so dass Sie aktualisierte Werkzeuge für die Verarbeitung benötigen.
Eine vorläufige Version dieser Werkzeuge ist unter
\url{http://www.gnu.org/software/acct/} verfügbar.

\subsubsection{Export task/process statistics through netlink}
CONFIG\_TASKSTATS [=y] \textbf{[Y]}\\
Export ausgewählter Statistiken für Aufgaben/Prozesse über die generische
Netlink-Schnittstelle. Im Gegensatz zur BSD-Prozessabrechnung sind die
Statistiken während der Lebensdauer von Auf\-gaben/Pro\-zes\-sen als Antwort auf
Befehle verfügbar. Wie BSD-Accounting werden sie beim Beenden von Tasks in
den Benutzerbereich gesendet.\\
Sagen Sie N, wenn Sie unsicher sind.

\paragraph{Enable per-task delay accounting} $~$\\
CONFIG\_TASK\_DELAY\_ACCT [=y] \textbf{[Y]}\\
Sammeln Sie Informationen über die Zeit, die eine Task für das Warten auf
Systemressourcen wie CPU, synchrone Block-E/A-Abwicklung und Auslagerung
von Seiten aufwendet. Solche Statistiken können bei der Festlegung der
Prioritäten eines Tasks im Verhältnis zu anderen Tasks für CPU-, IO-,
RSS-Limits usw. helfen.\\
Sagen Sie N, wenn Sie unsicher sind.

\paragraph{Enable extended accounting over taskstats}$~$\\
CONFIG\_TASK\_XACCT [=y] \textbf{[Y]}\\
Sammeln von erweiterten Task-Accounting-Daten und Senden der Daten an
das Userland zur Verarbeitung über die Taskstats-Schnittstelle.\\
Sagen Sie N, wenn Sie unsicher sind.

\subparagraph{Enable per-task storage I/O accounting}$~$\\
CONFIG\_TASK\_IO\_ACCOUNTING [=y] \textbf{[Y]}\\
Sammeln von Informationen über die Anzahl
der Bytes an Speicher-E/A, die dieser Task verursacht hat.\\
Sagen Sie N, wenn Sie unsicher sind.

\subsubsection{Pressure stall information tracking}
CONFIG\_PSI [=y] \textbf{[Y]}\\
Sammeln Sie Metriken, die anzeigen, wie überlastet die CPU-, Speicher-
und IO-Ka\-pa\-zi\-tät im System sind.

Wenn Sie hier Y angeben, erstellt der Kernel /proc/pressure/ mit die
Druckstatistikdateien cpu, memory und io. Diese zeigen den Anteil der
Walltime an, in dem einige oder alle Tasks im System aufgrund der
Beanspruchung der jeweiligen Ressource verzögert sind.

In Kerneln mit cgroup-Unterstützung verfügen cgroups (nur cgroup2) über
cpu.pressure-,\\*
memory.pressure- und io.pressure-Dateien, die nur die
Druckstaus für die gruppierten Aufgaben zusammenfassen.\\
Weitere Einzelheiten finden Sie unter Documentation/accounting/psi.rst.\\
Sagen Sie N, wenn Sie unsicher sind.

\paragraph{Require boot parameter to enable pressure stall information tracking} $~$\\
CONFIG\_PSI\_DEFAULT\_DISABLED [=n] \textbf{[N]}\\
Wenn diese Option gesetzt ist, ist die Verfolgung von Druck\-stau\-informationen
standardmäßig deaktiviert, kann aber durch die Übergabe von psi=1 auf der
Kernel-Befehlszeile beim Booten aktiviert werden.\\
Diese Funktion fügt dem Task-Wakeup- und Sleep-Pfad des Schedulers etwas Code hinzu.
Der Overhead ist zu gering, um gängige planungsintensive Arbeitslasten in der Praxis
zu beeinträchtigen (z.~B. Web\-server, Memcache), aber es zeigt sich in künstlichen
Scheduler-Stresstests, wie z.~B. Hackbench.\\
Wenn Sie paranoid sind und nicht sicher, wofür der Kernel verwendet wird,
sagen Sie Y für Ja.\\
Sagen Sie N, wenn Sie unsicher sind.

\subsection{CPU isolation}
CONFIG\_CPU\_ISOLATION [=y] \textbf{[Y]}\\
Stellen Sie sicher, dass CPUs, auf denen kritische Aufgaben laufen,
nicht durch irgendwelche \glqq Störquellen\grqq{} wie ungebundene Workqueues, Timers,
kthreads usw. gestört werden.\\
Ungebundene Aufgaben werden auf Housekeeping-CPUs verlagert.
Dies wird durch den Boot-Parameter \glqq isolcpus=\grqq{} gesteuert.\\
Sagen Sie Y für ja, wenn Sie unsicher sind.

\subsection{RCU Subsystem \texorpdfstring{$\rightarrow$}{->}}
Read -- Copy -- Update (Lesen, Kopieren, Aktualisieren)
\subsubsection{Make expert-level adjustments to RCU configuration}
CONFIG\_RCU\_EXPERT [=y] \textbf{[Y]}\\
Diese Option muss aktiviert werden, wenn Sie Anpassungen der RCU-Konfiguration
auf Expertenebene vornehmen möchten.
Standardmäßig können solche Anpassungen nicht vorgenommen werden,
was den oft vorteilhaften Nebeneffekt hat, dass \glqq make oldconfig\grqq{} Sie
davon abhält, alle möglichen detaillierten Fragen darüber zu stellen,
wie Sie zahlreiche obskure RCU-Optionen eingerichtet haben möchten.\\
Sagen Sie Y, wenn Sie Anpassungen an RCU auf Expertenebene vornehmen müssen.\\
Sagen Sie N, wenn Sie unsicher sind.

\subsubsection{Force selection of TASKS\_RCU}
CONFIG\_FORCE\_TASKS\_RCU [=n] \textbf{[N]}\\
Diese Option erzwingt eine aufgabenbasierte RCU-Implementierung die nur
freiwillige Kontextwechsel verwendet (keine Preemption!), Leerlauf und
Benutzermodus-Ausführung als Ruhezustände verwendet.  
Nicht für manuelle Auswahl in den meisten Fällen.

\subsubsection{Force selection of Tasks Rude RCU}
CONFIG\_FORCE\_TASKS\_RUDE\_RCU [=n] \textbf{[N]}\\
Diese Option erzwingt eine Task-basierte RCU-Implementierung, die nur
Kontextwechsel (einschließlich Preemption) und die Ausführung im
Benutzermodus als Ruhezustand verwendet. Sie erzwingt IPIs und
Kontextwechsel auf allen Online-CPUs, auch auf den Idle-CPUs, also
mit Vorsicht verwenden. 
In den meisten Fällen nicht für die manuelle Auswahl geeignet.

\subsubsection{Force selection of Tasks Trace RCU}
CONFIG\_FORCE\_TASKS\_TRACE\_RCU [=n] \textbf{[N]}\\
Diese Option ermöglicht eine Task-basierte RCU-Implementierung, die
explizite rcu\_read\_lock\_trace()-Lesemarker verwendet und es ermöglicht,
dass diese Leser sowohl in der Leerlaufschleife als auch in den
CPU-Hotplug-Codepfaden erscheinen. Es kann IPIs auf Online-CPUs erzwingen,
auch auf Idle-CPUs, also mit Vorsicht verwenden.
In den meisten Fällen nicht für die manuelle Auswahl geeignet.

\subsubsection{Tree-based hierarchical RCU fanout value}
CONFIG\_RCU\_FANOUT [=64] \textbf{[64]}\\
Diese Option steuert den Fanout von hierarchischen Implementierungen von
RCU, so dass RCU auf Maschinen mit einer großen Anzahl von CPUs effizient
arbeiten kann. Dieser Wert muss mindestens die vierte Wurzel von NR\_CPUS
sein, wodurch NR\_CPUS wahnsinnig groß werden kann. Der Standardwert von
RCU\_FANOUT sollte für Produktionssysteme verwendet werden, aber wenn Sie
die RCU-Implementierung selbst einem Stresstest unterziehen, ermöglichen
kleine RCU\_FANOUT-Werte das Testen von Codepfaden für große Systeme auf
kleinen (kleineren) Systemen.\\
Wählen Sie eine bestimmte Zahl, wenn Sie RCU selbst testen.
Nehmen Sie den Standardwert, wenn Sie unsicher sind.\\
Symbol: RCU\_FANOUT [=64]\\
Type  : integer (Ganzzahl)\\
Range : [2 64]

\subsubsection{Tree-based hierarchical RCU leaf-level fanout value}
CONFIG\_RCU\_FANOUT\_LEAF [=16] \textbf{[16]}\\
Diese Option steuert das Fanout auf Blattebene bei hierarchischen
Implementierungen von RCU und ermöglicht es, Cache-Misses gegen
Sperrkonflikte abzuwägen. Systeme, die ihre Scheduling"=Clock"=Interrupts
aus Gründen der Energieeffizienz synchronisieren, werden die
Standardeinstellung bevorzugen, da der kleinere Leaf-Level-Fanout die
Lock-Contention-Level akzeptabel niedrig hält. Sehr große Systeme
(Hunderte oder Tausende von CPUs) werden stattdessen diesen Wert auf den
maximal möglichen Wert setzen wollen, um die Anzahl der Cache-Misses zu
reduzieren, die während der Initialisierung der RCU-Grace-Periode auftreten.
Diese Systeme neigen dazu, CPU-gebunden zu laufen, und werden daher nicht
von synchronisierten Interrupts unterstützt, und neigen daher dazu, sie zu
verzerren, was den Sperrkonflikt so weit reduziert, dass große Fanouts auf
Blattebene gut funktionieren. Das heißt, wenn Sie den Fanout auf Blattebene
auf eine große Zahl setzen, wird dies wahrscheinlich zu problematischen
Sperrkonflikten auf den rcu\_node-Strukturen auf Blattebene führen, es sei
denn, Sie booten mit dem Kernelparameter skew\_tick.\\
Wählen Sie eine bestimmte Zahl, wenn Sie die RCU selbst testen.\\
Wählen Sie den maximal zulässigen Wert für große Systeme, aber bedenken Sie,
dass Sie möglicherweise auch den Kernel-Boot-Parameter skew\_tick setzen
müssen, um Konflikte bei den Sperren der rcu\_node-Strukturen zu vermeiden.
Nehmen Sie den Standardwert, wenn Sie unsicher sind.\\
Symbol: RCU\_FANOUT\_LEAF [=64]\\
Type  : integer (Ganzzahl)\\
Range : [2 64]

\subsubsection{Enable RCU priority boosting}
CONFIG\_RCU\_BOOST [=y] \textbf{[Y]}\\
Diese Option erhöht die Priorität von preemptierten RCU-Lesern, die
die aktuelle preemptible RCU-Schonfrist zu lange blockieren.
Diese Option verhindert auch, dass schwere Lasten den Aufruf von RCU-Callbacks
blockieren.\\
Geben Sie hier Y an, wenn Sie mit Echtzeitanwendungen oder großen Lasten arbeiten.\\
Sagen Sie hier N ein, wenn Sie unsicher sind.

\paragraph{Milliseconds to delay boosting after RCU grace-period start}$~$\\
CONFIG\_RCU\_BOOST\_DELAY [=500] \textbf{[500]}\\
Diese Option gibt die Zeit an, die nach dem Beginn einer bestimmten Karenzzeit
gewartet werden soll, bevor die Priorität von RCU-Lesern, die diese Karenzzeit
blockieren, erhöht wird.\\
Beachten Sie, dass jeder RCU-Leser, der eine beschleunigte RCU-Schonfrist
blockiert, sofort hochgestuft wird.\\ 
Akzeptieren Sie die Standardeinstellung, wenn Sie unsicher sind.\\
Symbol: RCU\_BOOST\_DELAY [=500]\\
Typ : Integer (Ganzzahl)\\
Bereich : [0 3000]

\paragraph{Perform RCU expedited work in a real-time kthread}$~$\\
CONFIG\_RCU\_EXP\_KTHREAD [=n] \textbf{[N]}\\
Verwenden Sie diese Option, um die Latenzzeiten der beschleunigten Neuheitsschonfristen
weiter zu reduzieren, was allerdings mit mehr Störungen verbunden ist.
Diese Option ist standardmäßig auf PREEMPT\_RT=y-Kerneln deaktiviert,
die beschleunigte Neuheitsschonfristen nach dem Booten durch die bedingungslose
Einstellung rcupdate.rcu\_normal\_after\_boot=1 deaktivieren.\\
Akzeptieren Sie die Voreinstellung, wenn Sie unsicher sind.

\subsubsection{Offload RCU callback processing from boot-selected CPUs}
CONFIG\_RCU\_NOCB\_CPU [=y] \textbf{[Y]}\\
Verwenden Sie diese Option, um den Jitter des Betriebssystems für aggressive HPC- oder
Echtzeit-Workloads zu reduzieren.
Sie kann auch verwendet werden, um RCU-Callback-Aufrufe auf energieeffiziente CPUs in
batteriebetriebenen asymmetrischen Multiprozessoren auszulagern. Der Preis für diesen
reduzierten Jitter ist, dass der Overhead von call\_rcu() ansteigt und dass bei einigen
Workloads ein erheblicher Anstieg der Kontextwechselraten zu verzeichnen ist.\\
Diese Option entlastet den Aufruf von Callbacks von der Gruppe von CPUs, die zur
Boot-Zeit durch den rcu\_nocbs-Parameter angegeben wird. Für jede dieser CPUs wird ein
kthread (\glqq rcuox/N\grqq{}) erstellt, um Callbacks aufzurufen, wobei \glqq N\grqq{} die CPU ist, die
entlastet wird, und wobei \glqq x\grqq{} \glqq p\grqq{} für RCU-preempt
(PREEMPTION-Kernel) und \glqq s\grqq{} für
RCU-sched (!PREEMPTION-Kernel) ist. Nichts hindert diesen kthread daran, auf den
angegebenen CPUs zu laufen, aber (1) die kthreads können zwischen jedem Callback
preempted werden, und (2) Affinität oder cgroups können verwendet werden, um die
kthreads zu zwingen, auf jeder gewünschten Gruppe von CPUs zu laufen.\\
Sagen Sie hier Y, wenn Sie trotz des zusätzlichen Overheads ein geringeres
OS-Jitter benötigen.\\
Sagen Sie hier N, wenn Sie unsicher sind.

\paragraph{Offload RCU callback processing from all CPUs by default}$~$\\
CONFIG\_RCU\_NOCB\_CPU\_DEFAULT\_ALL [=n] \textbf{[N]}\\
Verwenden Sie diese Option, um die Callback-Verarbeitung standardmäßig von allen
CPUs zu entlasten, wenn der Boot-Parameter rcu\_nocbs oder nohz\_full nicht vorhanden
ist. Dadurch wird auch die Notwendigkeit vermieden, Boot-Parameter zu verwenden, um
den Effekt der Entlastung aller CPUs beim Booten zu erreichen.\\
Geben Sie hier Y an, wenn Sie alle CPUs standardmäßig beim Booten entlasten wollen.\\
Sagen Sie hier N, wenn Sie sich nicht sicher sind.

\paragraph{Offload RCU callback from real-time kthread}$~$\\
CONFIG\_RCU\_NOCB\_CPU\_CB\_BOOST [=n] \textbf{[N]}\\
Verwenden Sie diese Option, um ausgelagerte Rückrufe als SCHED\_FIFO aufzurufen, um
ein Aushungern durch schwere SCHED\_OTHER-Hintergrundlast zu vermeiden. Natürlich
führt die Ausführung als SCHED\_FIFO während Callback Floods dazu, dass die rcuo[ps]
kthreads die CPU für Hunderte von Millisekunden oder mehr monopolisieren.
Wenn Sie diese Option aktivieren, müssen Sie daher sicherstellen, dass
latenzempfindliche Aufgaben entweder mit höherer Priorität oder auf einer anderen CPU
ausgeführt werden.\\
Geben Sie hier Y an, wenn Sie die RT-Priorität für die Auslagerung von kthreads
festlegen möchten.\\
Sagen Sie hier N, wenn Sie einen !PREEMPT\_RT-Kernel bauen und sich unsicher sind.

\subsubsection{Tasks Trace RCU readers use memory barriers in user and idle}
CONFIG\_TASKS\_TRACE\_RCU\_READ\_MB [=n] \textbf{[N]}\\
Verwenden Sie diese Option, um die Anzahl der IPIs (inter-processor interrupts),
die an CPUs gesendet werden,
die im Benutzerraum ausgeführt werden oder sich im Leerlauf befinden, während Tasks
RCU-Tilgungsfristen verfolgen, weiter zu reduzieren.
Da eine vernünftige Einstellung des Kernel-Boot-Parameters
rcupdate.rcu\_task\_ipi\_delay solche IPIs für viele Arbeitslasten eliminiert, ist
die richtige Einstellung dieser Kconfig-Option vor allem für aggressive
Echtzeitinstallationen und für batteriebetriebene Geräte wichtig, daher die oben
gewählte Standardeinstellung.\\
Sagen Sie hier Y, wenn Sie IPIs hassen.\\
Sagen Sie hier N, wenn Sie leseseitige Speicherbarrieren hassen.\\
Nehmen Sie die Standardeinstellung, wenn Sie unsicher sind.

\subsubsection{RCU callback lazy invocation functionality}
CONFIG\_RCU\_LAZY [=y] \textbf{[Y]}\\
Um Strom zu sparen, sollten Sie RCU-Rückrufe stapeln und nach einer Verzögerung,
einem Speicherdruck oder einer zu großen Rückrufliste flushen.

\subsubsection{RCU callback-batch backup time check}
CONFIG\_RCU\_DOUBLE\_CHECK\_CB\_TIME [=y] \textbf{[Y]}\\
Verwenden Sie diese Option, um eine präzisere Durchsetzung des Modulparameters
rcutree.rcu\_resched\_ns in Situationen zu ermöglichen, in denen ein einziger
RCU-Callback Hunderte von Mikrosekunden lang laufen könnte, wodurch die
32-Callback-Batching-Funktion, die verwendet wird, um die Kosten der feinkörnigen,
aber teuren local\_clock()-Funktion zu amortisieren, unterlaufen wird.\\
Diese Option rundet rcutree.rcu\_resched\_ns auf den nächsten Jiffy auf und setzt
die 32-Callback-Batching-Funktion außer Kraft, wenn diese Grenze überschritten wird.\\
Sagen Sie hier Y, wenn Sie eine strengere Durchsetzung des Rückruflimits benötigen.\\
Sagen Sie hier N, wenn Sie unsicher sind.

\subsection{Kernel .config support}
CONFIG\_IKCONFIG [=y] \textbf{[Y]}\\
Mit dieser Option kann der gesamte Inhalt der \glqq .config\grqq{}-Datei des Linux-Kernels im
Kernel gespeichert werden. Sie dokumentiert, welche Kernel-Optionen in einem
laufenden Kernel oder in einem On-Disk-Kernel verwendet werden.
Diese Informationen können mit dem Skript scripts/extract-ikconfig aus der
Kernel-Image-Datei extrahiert und als Eingabe verwendet werden, um den aktuellen
Kernel neu zu erstellen oder einen anderen Kernel zu bauen.
Sie können auch aus einem laufenden Kernel extrahiert werden, indem
/proc/config.gz gelesen wird, falls dies aktiviert ist (siehe unten).\\
Definiert mit init/Kconfig:686

\subsubsection{Enable access to .config through /proc/config.gz}
CONFIG\_IKCONFIG\_PROC [=y] \textbf{[Y]}\\
Diese Option ermöglicht den Zugriff auf die Kernelkonfigurationsdatei über
/proc/config.gz.

\subsection{Enable kernel headers through /sys/kernel/kheaders.tar.xz}
CONFIG\_IKHEADERS [=m] \textbf{[M]}\\
Diese Option ermöglicht den Zugriff auf die In-Kernel-Header, die während des
Build-Prozesses erzeugt werden. Diese können verwendet werden, um
eBPF-Tracing-Programme oder ähnliche Programme zu erstellen. Wenn Sie die Header
als Modul erstellen, wird ein Modul namens kheaders.ko erstellt, das bei Bedarf
geladen werden kann, um Zugriff auf die Header zu erhalten.

\subsection{Kernel log buffer size (16 \texorpdfstring{$\Rightarrow$}{=>} 64KB, 17 \texorpdfstring{$\Rightarrow$}{=>} 128KB)}
CONFIG\_LOG\_BUF\_SHIFT [=17] \textbf{[17]}\\
Wählen Sie die minimale Größe des Kernel-Protokollpuffers als eine Potenz von 2 aus.
Die endgültige Größe wird durch den Konfigurationsparameter LOG\_CPU\_MAX\_BUF\_SHIFT
beeinflusst, siehe unten. Eine höhere Größe kann auch durch den Boot-Parameter
\glqq log\_buf\_len\grqq{} erzwungen werden.\\
Beispiele:\\
\indent 17 $\Rightarrow$ 128 KB\\
\indent 16 $\Rightarrow$ 64 KB\\
\indent 15 $\Rightarrow$ 32 KB\\
\indent 14 $\Rightarrow$ 16 KB\\
\indent 13 $\Rightarrow$ 8 KB\\
\indent 12 $\Rightarrow$ 4 KB\\
Symbol: LOG\_BUF\_SHIFT\\
Type: Integer (Ganzzahl)\\
Range: [12 25]
\subsection{CPU kernel log buffer size contribution (13 \texorpdfstring{$\Rightarrow$}{=>} 8 KB, 17 \texorpdfstring{$\Rightarrow$}{=>} 128KB)}
CONFIG\_LOG\_BUF\_SHIFT [=12] \textbf{[12]}\\
Diese Option ermöglicht es, die Standardgröße des Ringpuffers entsprechend der Anzahl
der CPUs zu erhöhen. Der Wert definiert den Beitrag jeder CPU als eine Potenz von 2.
Der beanspruchte Speicherplatz beträgt in der Regel nur wenige Zeilen, kann aber viel
mehr sein, wenn Probleme gemeldet werden, z.~B. bei Rückverfolgungen.
Die erhöhte Größe bedeutet, dass ein neuer Puffer zugewiesen werden muss und der
ursprüngliche statische Puffer ungenutzt ist. Dies ist nur auf Systemen mit mehr CPUs
sinnvoll. Daher wird dieser Wert nur verwendet, wenn die Summe der Beiträge größer ist
als die Hälfte des Standard-Kernel-Ringpuffers, wie durch \texttt{LOG\_BUF\_SHIFT} definiert.
Die Standardwerte sind so eingestellt, dass mehr als 16 CPUs erforderlich sind, um die
Zuweisung auszulösen. Diese Option wird auch ignoriert, wenn der Kernelparameter
\glqq log\_buf\_len\grqq{} verwendet wird, da er eine exakte (Zweierpotenz) Größe des
Ringpuffers erzwingt. Die Anzahl der möglichen CPUs wird für diese Berechnung verwendet,
wobei Hotplugging ignoriert wird, so dass die Berechnung für das Worst-Case-Szenario
optimal ist und gleichzeitig ein einfacher Algorithmus ab dem Hochfahren verwendet
werden kann. Beispiele für Verschiebungswerte und ihre Bedeutung:\\
\indent 17 $\Rightarrow$ 128 KB für jede CPU\\
\indent 16 $\Rightarrow$  64 KB für jede CPU\\
\indent 15 $\Rightarrow$  32 KB für jede CPU\\
\indent 14 $\Rightarrow$  16 KB für jede CPU\\
\indent 13 $\Rightarrow$   8 KB für jede CPU\\
\indent 12 $\Rightarrow$   4 KB für jede CPU\\
Symbol: LOG\_CPU\_MAX\_BUF\_SHIFT\\
Type: Integer (Ganzzahl)\\
Range: [0 21]

\subsection{Printk indexing debugfs interface)}
CONFIG\_PRINTK\_INDEX [=y] \textbf{[Y]}\\
Unterstützung für die Indizierung aller zur Kompilierzeit bekannten
printk-Formate unter\\
$<$debugfs$>$/printk/index/$<$module$>$ hinzufügen.
Dies kann als Teil der Wartung von Daemonen, die /dev/kmsg überwachen,
verwendet werden, da es die Überprüfung der in einem Kernel vorhandenen
printk-Formate erlaubt, was die Erkennung von Fällen ermöglicht,
in denen überwachte printks geändert oder nicht mehr vorhanden sind.\\
Es gibt keine zusätzlichen Laufzeitkosten für printk, wenn dies aktiviert ist. 

\subsection{Scheduler features \texorpdfstring{$\rightarrow$}{->}}
Scheduler-Funktionen

\subsubsection{Enable utilization clamping for RT/FAIR tasks}
CONFIG\_UCLAMP\_TASK [=y] \textbf{[Y]}\\
Diese Funktion ermöglicht es dem Scheduler, die geklemmte Auslastung jeder CPU
auf der Grundlage der auf dieser CPU geplanten RUNNABLE-Tasks zu verfolgen.
Mit dieser Option kann der Benutzer die minimale und maximale CPU-Auslastung
angeben, die für RUNNABLE-Aufgaben zulässig ist. Die maximale Auslastung
definiert die maximale Häufigkeit, mit der ein Task laufen soll, während die
minimale Auslastung die minimale Häufigkeit definiert, mit der er laufen soll.\\
Sowohl die Minimal- als auch die Maximalwerte für die Auslastung sind Hinweise
für den Scheduler, um seine Frequenzauswahl zu verbessern, aber sie erzwingen
oder gewähren keine bestimmte Bandbreite für Tasks.\\
Im Zweifelsfall sagen Sie N für Nein.

\paragraph{Number of supported utilization clamp buckets}$~$\\
CONFIG\_UCLAMP\_BUCKETS\_COUNT [=5] \textbf{[5]}\\
Legt die Anzahl der zu verwendenden Klammerbereiche fest. Der Bereich der
einzelnen Buckets ist SCHED\_CAPACITY\_SCALE/UCLAMP\_BUCKETS\_COUNT.
Je höher die Anzahl der Clamp-Buckets, desto feiner die Granularität und
desto höher die Präzision der Clamp-Aggregation und -Verfolgung während der
Laufzeit.
Mit dem minimalen Konfigurationswert haben wir beispielsweise 5 Clamp-Buckets,
die jeweils 20 \% Auslastung verfolgen. Eine um 25 \% gesteigerte Aufgabe
wird im Bucket [20..39]\% gezählt und setzt den effektiven Wert der
Bucketklemme auf 25 \%.
Wenn eine zweite, um 30 \% erhöhte Aufgabe auf derselben CPU eingeplant wird,
wird diese Aufgabe im selben Bucket wie die erste Aufgabe gezählt und erhöht
den effektiven Bucket-Clamp-Wert auf 30 \%.
Der effektive Klemmwert eines Bereichs wird auf seinen Nennwert (20 \% im
obigen Beispiel) zurückgesetzt, wenn keine weiteren Aufgaben mehr in diesem
Bereich gezählt werden. Bei einigen Aufgaben kann eine zusätzliche
Verstärkungs-/Kappungsmarge hinzugefügt werden. Im obigen Beispiel wird
die 25 \%-Aufgabe auf 30 \% angehoben, bis sie die CPU verlässt.
Sollte dies auf bestimmten Systemen nicht akzeptabel sein, ist es immer
möglich, den Spielraum zu verringern, indem die Anzahl der Clamp-Buckets
erhöht wird, um den verbrauchten Speicher gegen die Genauigkeit der
Laufzeitverfolgung einzutauschen.\\
Im Zweifelsfall sollten Sie den Standardwert verwenden.

\subsection{Memory placement aware NUMA scheduler}
CONFIG\_NUMA\_BALANCING [=y] \textbf{[Y]}\\
Diese Option bietet Unterstützung für die automatische
NUMA-kompatible Speicher-/Task-Platzierung.
Der Mechanismus ist recht primitiv und basiert darauf, dass Speicher
migriert wird, wenn er Referenzen auf den Knoten hat, auf dem die Aufgabe läuft.\\
Dieses System ist auf UMA-Systemen inaktiv.

\subsubsection{Automatically enable NUMA aware memory/task placemnent}
CONFIG\_NUMA\_BALANCING\_DEFAULT\_ENABLED [=y] \textbf{[Y]}\\
Wenn diese Option gesetzt ist, wird der automatische NUMA-Ausgleich aktiviert,
wenn das System auf einem NUMA-Rechner läuft.

\subsection{Control Group support \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_CGROUPS [=y] \textbf{[Y]}\\
(Unterstützung der Kontrollgruppe)\\
Diese Option bietet Unterstützung für die Gruppierung von Prozessgruppen zur Verwendung mit Prozesskontrollsubsystemen wie Cpusets, CFS, Speicherkontrolle oder Geräteisolierung.
\\Siehe
\begin{itemize}
\item Dokumentation/scheduler/sched-design-CFS.rst (CFS)
\item Documentation/admin-guide/cgroup-v1/ (Funktionen für Gruppierung,
 Isolierung und Ressourcenkontrolle)
\end{itemize}
Sagen Sie N, wenn Sie unsicher sind.

\subsubsection{Favor dynamic modification latency reduction by default}
CONFIG\_CGROUP\_FAVOR\_DYNMODS [=n] \textbf{[N]}\\
Diese Option aktiviert standardmäßig die Einhängeoption
\glqq favordynmods\grqq{}, die die Latenzzeiten dynamischer C-Gruppen-Änderungen
wie Task-Migrationen und Controller-Ein-/Ausschaltungen
auf Kosten von Hot-Path-Operationen wie Forks und Exits
verteuert.\\
Sagen Sie N, wenn Sie unsicher sind.

\subsubsection{Memory controller}
CONFIG\_MEMCG [=y] \textbf{[Y]}\\
Ermöglicht die Kontrolle über den Speicherbedarf von Tasks in einer cgroup.

\subsubsection{IO controller}
CONFIG\_BLK\_CGROUP [=y] \textbf{[Y]}\\
Generische Block IO Controller cgroup Schnittstelle. Dies ist die gemeinsame
cgroup-Schnittstelle, die von verschiedenen IO-Kontrollstrategien verwendet
werden sollte.\\
Derzeit wird sie vom CFQ IO Scheduler zur Erkennung von Task-Gruppen und zur
Steuerung der Zuweisung von Festplattenbandbreite (proportionale
Zeitscheibenzuweisung) an solche Task-Gruppen verwendet. Sie wird auch von
der Bio-Throttling-Logik in der Blockschicht verwendet, um eine Obergrenze
für die IO-Raten auf einem Gerät einzuführen.\\
Diese Option aktiviert nur die generische Infrastruktur des Block-IO-Controllers.
Man muss auch die tatsächliche IO-Kontrolllogik/-Politik aktivieren.
Um die proportionale Aufteilung der Festplattenbandbreite in CFQ zu aktivieren,
setzen Sie
CONFIG\_BFQ\_GROUP\_IOSCHED=y; für die Aktivierung der Drosselungspolitik
setzen Sie CONFIG\_BLK\_DEV\_THROTTLING=y.\\
Weitere Informationen finden Sie unter
Documentation/admin-guide/cgroup-v1/blkio-controller.rst.

\subsubsection{CPU controller \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_CGROUP\_SCHED [=y] \textbf{[Y]}\\
Diese Funktion ermöglicht es dem CPU-Scheduler, Task-Gruppen zu erkennen und
die Zuweisung von CPU-Bandbreite an solche Task-Gruppen zu steuern.
Er verwendet cgroups, um Tasks zu gruppieren.

\paragraph{Group scheduling for SCHED\_OTHER}$~$\\
CONFIG\_FAIR\_GROUP\_SCHED [=y] \textbf{[Y]}\\
\textit{Für diese Option gibt es keine Hilfe.}

\subparagraph{CPU bandwidth provisioning for FAIR\_GROUP\_SCHED}$~$\\
CONFIG\_CFS\_BANDWIDTH [=y] \textbf{[Y]}\\
Mit dieser Option können Benutzer CPU-Bandbreitenraten (Limits) für Aufgaben
festlegen, die innerhalb des Fair Group Schedulers laufen.
Gruppen, für die kein Limit festgelegt wurde, gelten als uneingeschränkt
und werden ohne Einschränkung ausgeführt.\\
Weitere Informationen finden Sie unter Documentation/scheduler/sched-bwc.rst.

\paragraph{Group scheduling for SCHED\_RR/FIFO}$~$\\
CONFIG\_RT\_GROUP\_SCHED [=n] \textbf{[N]}\\
Mit dieser Funktion können Sie den Task-Gruppen explizit echte CPU-Bandbreite
zuweisen. Wenn sie aktiviert ist, wird es auch unmöglich, Echtzeitaufgaben
für Nicht-Root-Benutzer zu planen, bis Sie ihnen Echtzeitbandbreite zuweisen.\\
Weitere Informationen finden Sie unter Documentation/scheduler/sched-rt-group.rst.

\subsubsection{Utilization clamping per group of tasks}
CONFIG\_UCLAMP\_TASK\_GROUP [=y] \textbf{[Y]}\\
Mit dieser Funktion kann der Scheduler die geklemmte Auslastung jeder CPU auf der
Grundlage der RUNNABLE-Tasks, die derzeit auf dieser CPU geplant sind, verfolgen.
Wenn diese Option aktiviert ist, kann der Benutzer eine minimale und maximale
CPU-Bandbreite angeben, die für jede einzelne Aufgabe in einer Gruppe zulässig ist.
Mit der maximalen Bandbreite kann die maximale Frequenz, die ein Task verwenden kann,
festgelegt werden, während mit der minimalen Bandbreite eine minimale Frequenz
festgelegt werden kann, die ein Task immer verwenden wird.
Bei aktivierter aufgabengruppenbasierter Auslastungsbegrenzung wird ein eventuell
angegebener aufgabenspezifischer Begrenzungswert durch den von cgroup angegebenen
Begrenzungswert eingeschränkt. Sowohl die minimale als auch die maximale Task-Klemmung
kann nicht größer sein als die entsprechende auf Task-Gruppen-Ebene definierte Klemmung.\\
Im Zweifelsfall sagen Sie N.

\subsubsection{PIDs controller}
CONFIG\_CGROUP\_PIDS [=y] \textbf{[Y]}\\
Erzwingt die Begrenzung der Prozessanzahl im Bereich einer cgroup. Jeder Versuch, mehr
Prozesse zu forken, als in der cgroup erlaubt sind, schlägt fehl.
PIDs sind grundsätzlich eine globale Ressource, da es ziemlich trivial ist, eine
PID-Erschöpfung zu erreichen, bevor man auch nur eine konservative kmemcg-Grenze erreicht.
Infolgedessen ist es möglich, ein System zum Stillstand zu bringen, ohne durch andere
cgroup-Richtlinien eingeschränkt zu werden. Der PID-Regler ist dafür ausgelegt, dies zu verhindern.
Es sollte beachtet werden, dass organisatorische Operationen (wie z.~B. das Anhängen an
eine cgroup-Hierarchie) *nicht* durch den PIDs-Controller blockiert werden, da das PIDs-Limit
nur die Fähigkeit eines Prozesses zum Forking, nicht aber zum Anhängen an eine cgroup beeinflusst.

\subsubsection{RDMA controller}
CONFIG\_CGROUP\_RDMA [=y] \textbf{[Y]}\\
Ermöglicht die Durchsetzung der vom IB-Stack definierten RDMA-Ressourcen. Es ist relativ
einfach für Verbraucher, RDMA-Ressourcen zu erschöpfen, was dazu führen kann, dass Ressourcen
für andere Verbraucher nicht mehr verfügbar sind. Der RDMA-Controller ist dafür ausgelegt,
dies zu verhindern. Das Anhängen von Prozessen mit aktiven RDMA-Ressourcen an die
cgroup-Hierarchie ist erlaubt, auch wenn die Grenze der Hierarchie überschritten werden kann.

\subsubsection{Freezer controller}
CONFIG\_CGROUP\_FREEZER [=y] \textbf{[Y]}\\
Ermöglicht das Einfrieren und Aufheben des Einfrierens aller Aufgaben in einer C-Group.
Diese Option betrifft die ORIGINAL cgroup-Schnittstelle. Der cgroup2-Speicher-Controller
enthält standardmäßig wichtige In-Kernel-Speicherverbraucher.\\
Wenn Sie cgroup2 verwenden, sagen Sie N.

\subsubsection{HugeTLB controller}
CONFIG\_CGROUP\_HUGETLB [=y] \textbf{[Y]}\\
Bietet eine cgroup-Steuerung für HugeTLB-Seiten. Wenn Sie dies aktivieren, können Sie die
HugeTLB-Nutzung pro cgroup begrenzen. Die Begrenzung wird während eines Seitenfehlers
durchgesetzt. Da HugeTLB keine Seitenrückforderung unterstützt, bedeutet die Durchsetzung
des Limits zum Zeitpunkt des Seitenfehlers, dass die Anwendung ein SIGBUS-Signal erhält,
wenn sie versucht, über das Limit hinaus auf HugeTLB-Seiten zuzugreifen. Dies setzt voraus,
dass die Anwendung im Voraus weiß, wie viele HugeTLB-Seiten sie für ihre Nutzung benötigt.
Die Kontrollgruppe wird im dritten Page-lru-Zeiger verfolgt. Dies bedeutet, dass wir die
Steuergruppe nicht mit einer riesigen Seite von weniger als 3 Seiten verwenden können.

\subsubsection{Cpuset controller}
CONFIG\_CPUSETS [=y] \textbf{[Y]}\\
Mit dieser Option können Sie CPUSETs erstellen und verwalten, die es ermöglichen, ein System
dynamisch in Gruppen von CPUs und Speicherknoten zu partitionieren und Aufgaben zuzuweisen,
die nur innerhalb dieser Gruppen ausgeführt werden.
Dies ist vor allem auf großen SMP- oder NUMA-Systemen nützlich.\\
Sagen Sie N, wenn Sie unsicher sind.

\paragraph{Include legacy /proc/$<$pid$>$/cpuset file}$~$\\
CONFIG\_PROC\_PID\_CPUSET [=y] \textbf{[Y]}\\
This option will let you create and manage CPUSETs which allow dynamically partitioning a
system into sets of CPUs and Memory Nodes and assigning tasks to run only within those sets.
This is primarily useful on large SMP or NUMA systems.\\
Say N if unsure.

\subsubsection{Device controller}
CONFIG\_CGROUP\_DEVICE [=y] \textbf{[Y]}\\
Bietet einen cgroup-Controller an, der Whitelists für Geräte implementiert,
die ein Prozess in der cgroup mknod oder öffnen kann.

\subsubsection{Simple CPU accounting controller}
CONFIG\_CGROUP\_CPUACCT [=y] \textbf{[Y]}\\*
(Einfacher CPU-Accounting-Controller)\\
Bietet einen einfachen Controller für die Überwachung des gesamten
CPU-Verbrauchs der Tasks in einer cgroup an.

\subsubsection{Perf controller}
CONFIG\_CGROUP\_PERF [=y] \textbf{[Y]}\\
Diese Option erweitert den Modus perf per-cpu, um die Überwachung auf Threads zu beschränken,
die zu der angegebenen cgroup gehören und auf der angegebenen CPU laufen.
Sie kann auch verwendet werden, um die cgroup ID in Stichproben zu haben,
so dass sie Leistungsereignisse zwischen cgroups überwachen kann.\\
Sagen Sie N, wenn Sie unsicher sind.

\subsubsection{Support for eBPF programs attached to cgroups}
CONFIG\_CGROUP\_BPF [=y] \textbf{[Y]}\\
Erlaubt das Anhängen von eBPF-Programmen an eine cgroup mit dem
bpf(2)-Syscall-Befehl\\
\texttt{BPF\_PROG\_ATTACH}.\\
In welchem Kontext auf diese Programme zugegriffen wird, hängt von der Art des Attachments ab.
Zum Beispiel werden Programme, die mit BPF\_CGROUP\_INET\_INGRESS angehängt werden,
auf dem Ingress-Pfad von inet-Sockets ausgeführt.

\subsubsection{Misc resource controller}
CONFIG\_CGROUP\_MISC [=y] \textbf{[Y]}\\
Bietet einen Controller für verschiedene Ressourcen auf einem Host.
Verschiedene skalare Ressourcen sind die Ressourcen auf dem Host-System, die nicht wie die
anderen cgroups abstrahiert werden können. Dieser Controller verfolgt und begrenzt die
verschiedenen Ressourcen, die von einem Prozess verwendet werden, der an eine
cgroup-Hierarchie angeschlossen ist.\\
Weitere Informationen finden Sie im Abschnitt misc cgroup in /Documentation/admin-guide/cgroup-v2.rst.

\subsubsection{Debug controller}
CONFIG\_CGROUP\_DEBUG [=n] \textbf{[N]}\\
Diese Option aktiviert einen einfachen Controller, der Debugging"=Informationen über das
cgroups"=Frame\-work exportiert. Dieser Controller ist nur für das Debugging von Kontroll-C-Gruppen gedacht.
Seine Schnitt\-stellen sind nicht stabil.\\
Sagen Sie N.

\subsection{Namespaces support \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_NAMESPACES [=y] \textbf{[Y]}\\
(Unterstützung von Namensräumen, namespaces)\\
Bietet die Möglichkeit, Aufgaben mit verschiedenen Objekten unter Verwendung derselben Kennung
arbeiten zu lassen. Zum Beispiel kann sich dieselbe IPC-ID auf verschiedene Objekte beziehen oder
dieselbe Benutzer-ID oder pid kann sich auf verschiedene Aufgaben beziehen, wenn sie in verschiedenen
Namensräumen verwendet werden.

\subsubsection{UTS namespace}
CONFIG\_UTS\_NS [=y] \textbf{[Y]}\\
In diesem Namensraum sehen Aufgaben verschiedene Informationen, die mit dem Systemaufruf uname()
bereitgestellt werden 

\subsubsection{TIME namespace}
CONFIG\_TIME\_NS [=y] \textbf{[Y]}\\
In diesem Namespace können boottime und monotone Uhren eingestellt werden.
Die Zeit läuft dann mit der gleichen Geschwindigkeit weiter.

\subsubsection{IPC namespace}
CONFIG\_IPC\_NS [=y] \textbf{[Y]}\\
In diesem Namensraum arbeiten Aufgaben mit IPC-IDs (Interprozess-IDs), die jeweils
verschiedenen IPC-Objekten in verschiedenen Namensräumen entsprechen.

\subsubsection{User namespace}
CONFIG\_USER\_NS [=y] \textbf{[Y]}\\
Dies ermöglicht es Containern, d.h. V-Servern, Benutzernamensräume zu verwenden,
um verschiedene Benutzerinformationen für verschiedene Server bereitzustellen.
Wenn Benutzernamensräume im Kernel aktiviert sind, wird empfohlen, dass die Option \texttt{MEMCG} ebenfalls
aktiviert wird und dass der Benutzerbereich die Speicherkontrollgruppen verwendet,
um die Speichermenge zu begrenzen, die nicht privilegierte Benutzer verwenden können.

\paragraph{Allow unprivileged users to create namespaces}$~$\\
CONFIG\_USERS\_NS\_UNPRIVILEGED [=y] \textbf{[Y]}\\
Wenn diese Funktion deaktiviert ist, können unprivilegierte Benutzer keine neuen Namensräume
erstellen. Die Möglichkeit, dass Benutzer ihre eigenen Namespaces erstellen können, war Teil mehrerer
kürzlich erfolgter lokaler Privilegienerweiterungen. Wenn Sie also Benutzernamespaces benötigen,
aber paranoid bzw. sicherheitsbewusst sind, sollten Sie diese Funktion deaktivieren.
Diese Einstellung kann zur Laufzeit mit dem
\texttt{kernel.unprivileged\_userns\_clone sysctl}
außer Kraft gesetzt werden.\\
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{PID namespace}
CONFIG\_PID\_NS [=y] \textbf{[Y]}\\
Unterstützung von Prozess-ID-Namensräumen.  Dies ermöglicht es, mehrere Prozesse mit der gleichen pid
zu haben, solange sie sich in verschiedenen pid-Namensräumen befinden.  Dies ist ein Baustein von Containern.

\subsubsection{Network namespace}
CONFIG\_NET\_NS [=y] \textbf{[Y]}\\
Ermöglicht es dem Benutzer, scheinbar mehrere Instanzen des Netzwerkstapels zu erstellen.

\subsection{Checkpoint/restore support}
CONFIG\_CHECKPOINT\_RESTORE [=y] \textbf{[Y]}\\
Ermöglicht zusätzliche Kernel-Funktionen in einer Art Checkpoint/Restore.
Insbesondere fügt es zu\-sätz\-liche prctl-Codes zum Einrichten von Prozesstext, Daten- und Heap-Segmentgrößen
sowie einige zusätzliche /proc-Dateisystemeinträge hinzu.\\
Wenn Sie unsicher sind, geben Sie hier N an.


\subsection{Automatic process group scheduling}
CONFIG\_SCHED\_AUTOGROUP [=y] \textbf{[Y]}\\
Mit dieser Option wird der Scheduler für gängige Desktop-Workloads optimiert,
indem automatisch Aufgabengruppen erstellt und aufgefüllt werden.
Diese Trennung von Arbeitslasten isoliert aggressive CPU-Brenner (wie Build-Jobs) von Desktop-Anwendungen.
Die automatische Erstellung von Aufgabengruppen basiert derzeit auf der Aufgabensitzung.

\subsection{Kernel\texorpdfstring{$\rightarrow$}{->}user space relay support (formerly relayfs)}
CONFIG\_RELAY [=y] \textbf{[Y]}\\
Diese Option aktiviert die Unterstützung für die Relaisschnittstelle in bestimmten Dateisystemen
(wie debugfs). Sie wurde entwickelt, um einen effizienten Mechanismus für Werkzeuge und Einrichtungen
zur Weiterleitung großer Datenmengen aus dem Kernelbereich in den Benutzerbereich bereitzustellen.\\
Wenn Sie unsicher sind, sagen Sie N.

\subsection{Initial RAM filesystem and RAM disk (initramfs/initrd) support}
CONFIG\_BLK\_DEV\_INITRD [=y] \textbf{[Y]}\\
Das anfängliche RAM-Dateisystem ist ein ramfs, das vom Bootloader (loadlin oder lilo) geladen und vor
dem normalen Bootvorgang als root eingehängt wird. Es wird typischerweise verwendet, um Module zu laden,
die zum Einhängen des \glqq echten\grqq{} Root-Dateisystems benötigt werden, usw.\\
Siehe $<$file:Documentation/admin-guide/initrd.rst$>$ für Details.
Wenn die RAM-Disk-Unter\-stützung\\
(BLK\_DEV\_RAM) eben\-falls enthalten ist, aktiviert dies auch die anfängliche
RAM-Disk-Unterstützung (initrd) und fügt 15 KByte (auf einigen anderen Architekturen mehr) zur Kernelgröße hinzu.\\
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{Initramfs source file(s)}
CONFIG\_INITRAMFS\_SOURCE [=] \textbf{[~]}\\
Dies kann entweder ein einzelnes cpio-Archiv mit der Endung .cpio oder eine durch Leerzeichen getrennte
Liste von Verzeichnissen und Dateien zur Erstellung des initramfs-Abbilds sein.
Ein cpio-Archiv sollte ein Dateisystemarchiv enthalten, das als initramfs-Abbild verwendet werden soll.
Verzeichnisse sollten ein Dateisystem-Layout enthalten, das in das initramfs-Abbild aufgenommen werden
soll. Die Dateien sollten Einträge in dem Format enthalten, das vom
Programm \texttt{usr/gen\_init\_cpio} im Kernelbaum beschrieben wird.
Wenn mehrere Verzeichnisse und Dateien angegeben werden, wird das initramfs-Abbild die Summe aller
dieser Verzeichnisse und Dateien sein.\\
Siehe $<$file:Documentation/driver-api/early-userspace/early\_userspace\_support.rst$>$
für weitere Details.\\
Wenn Sie sich nicht sicher sind, lassen Sie das Feld leer.\\
Symbol: INITRAMFS\_SOURCE [=]\\
Type : string (Zeichenkette)

\subsubsection{Support initial ramdisk/ramfs compressed using gzip}
CONFIG\_RD\_GZIP [=y] \textbf{[Y]}\\
Unterstützung des Ladens eines gzip-kodierten Anfangs-Ramdisk-
oder Cpio-Puffers.\\
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{Support initial ramdisk/ramfs compressed using bzip2}
CONFIG\_RD\_BZIP2 [=y] \textbf{[Y]}\\
Unterstützung des Ladens eines bzip2-kodierten Anfangs-Ramdisk- 
oder Cpio-Puffers.\\
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{Support initial ramdisk/ramfs compressed using LZMA}
CONFIG\_RD\_LZMA [=y] \textbf{[Y]}\\
Unterstützung des Ladens eines LZMA-kodierten Anfangs-Ramdisk- 
oder Cpio-Puffers.\\
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{Support initial ramdisk/ramfs compressed using XZ}
CONFIG\_RD\_XZ [=y] \textbf{[Y]}\\
Unterstützung des Ladens eines XZ-kodierten Anfangs-Ramdisk- 
oder Cpio-Puffers.\\
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{Support initial ramdisk/ramfs compressed using LZO}
CONFIG\_RD\_LZO [=y] \textbf{[Y]}\\
Unterstützung des Ladens eines LZO-kodierten Anfangs-Ramdisk- 
oder Cpio-Puffers.\\
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{Support initial ramdisk/ramfs compressed using LZ4}
CONFIG\_RD\_LZ4 [=y] \textbf{[Y]}\\
Unterstützung des Ladens eines LZ4-kodierten Anfangs-Ramdisk- 
oder Cpio-Puffers.\\
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{Support initial ramdisk/ramfs compressed using ZSTD}
CONFIG\_RD\_ZSTD [=y] \textbf{[Y]}\\
Unterstützung des Ladens eines ZSTD-kodierten Anfangs-Ramdisk- 
oder Cpio-Puffers.\\
Wenn Sie unsicher sind, sagen Sie Y.

\subsection{Boot config support}
CONFIG\_BOOT\_CONFIG [=y] \textbf{[Y]}\\
Extra boot config ermöglicht es dem Systemadministrator, eine Konfigurationsdatei
als zusätzliche Erweiterung der Kernel-Cmdline beim Booten zu übergeben.
Die Bootkonfigurationsdatei muss am Ende von \mbox{initramfs} mit Prüfsumme, Größe und
magischem Wort angehängt werden.\\
Siehe $<$file:Documentation/admin-guide/bootconfig.rst$>$ für Details.\\
Wenn Sie unsicher sind, sagen Sie Y.


\subsubsection{Force unconditional bootconfig processing}
CONFIG\_BOOT\_CONFIG\_FORCE [=n] \textbf{[N]}\\
Wenn diese Kconfig-Option gesetzt ist, wird die BOOT\_CONFIG-Verarbeitung auch dann
durchgeführt, wenn der Kernel-Boot-Parameter "bootconfig" weggelassen wird.
Tatsächlich gibt es mit dieser Kconfig-Option keine Möglichkeit, den Kernel dazu
zu bringen, die von BOOT\_CONFIG gelieferten Kernel-Boot-Parameter zu ignorieren.\\
Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{Embed bootconfig file in the kernel}
CONFIG\_BOOT\_CONFIG\_EMBED [=n] \textbf{[N]}\\
Eine mit BOOT\_CONFIG\_EMBED\_FILE angegebene bootconfig-Datei in den Kernel einbetten.
Normalerweise wird die bootconfig-Datei mit dem initrd-Image geladen. Wenn das System
jedoch initrd nicht unterstützt, hilft Ihnen diese Option, indem sie eine bootconfig-Datei
beim Erstellen des Kernels einbettet.\\
Wenn Sie unsicher sind, sagen Sie N.

\subsection{Preserve cpio archive mtimes in initramfs}
CONFIG\_INITRAMFS\_PRESERVE\_MTIME [=y] \textbf{[Y]}\\
Jeder Eintrag in einem initramfs cpio-Archiv enthält einen mtime-Wert.
Wenn diese Option aktiviert ist, übernehmen die extrahierten cpio-Einträge diese mtime,
wobei die mtime-Einstellung des Verzeichnisses aufgeschoben wird, bis nach der
Erstellung aller untergeordneten Einträge.\\
Wenn Sie unsicher sind, sagen Sie Y.

\subsection{Compiler optimization level \texorpdfstring{$\rightarrow$}{->}}
Optimierungsgrad des Compilers, Auswahl aus den folgenden zwei Punkten:

\subsubsection{Optimize for performance (-O2)}
CONFIG\_CC\_OPTIMIZE\_FOR\_Performance [=y] \textbf{[Y]}\\
Dies ist die Standardoptimierungsstufe für den Kernel, die mit dem Compiler-Flag \texttt{-O2}
erstellt wird, um die beste Leistung und die hilfreichsten Warnungen bei der
Kompilierung zu erhalten.

\subsubsection{Optimize for size (-Os)}
CONFIG\_CC\_OPTIMIZE\_FOR\_SIZE [=n] \textbf{[N]}\\
Wenn Sie diese Option wählen, wird \texttt{-Os} an Ihren Compiler übergeben,
was zu einem kleineren Kernel führt.

\subsection{Configure standard kernel features (expert users)}
CONFIG\_EXPERT [=n] \textbf{[~]}\\
Mit dieser Option können bestimmte Basis-Kerneloptionen und -einstellungen
deaktiviert oder optimiert werden. Dies ist für spezielle Umgebungen gedacht,
die einen \glqq Nicht-Standard\grqq{}-Kernel tolerieren können.\\
Verwenden Sie diese Option nur, wenn Sie wirklich wissen, was Sie tun.

\subsubsection{Load all symbols for debugging/ksymoops}
CONFIG\_KALLSYMS [=y] \textbf{[Y]}\\
(sichtbar wenn EXPERT [=n])\\
Geben Sie hier Y ein, damit der Kernel symbolische Absturzinformationen und
symbolische Stack-Backtraces ausgibt. Dies erhöht die Größe des Kernels etwas,
da alle Symbole in das Kernel-Image geladen werden müssen.

\paragraph{Test the basic functions and performance of kallsyms}$~$\\
CONFIG\_KALLSYMS\_SELFTEST [=n] \textbf{[N]}\\
Testen Sie die Grundfunktionen und die Leistung einiger Schnittstellen, wie z.~B.
\texttt{kallsyms\_lookup\_name}. Außerdem wird die Kompressionsrate des
kallsyms-Kompressionsalgorithmus für den aktuellen Symbolsatz berechnet.
Starten Sie den Selbsttest automatisch nach dem Systemstart.\\
Es wird empfohlen, \texttt{dmesg | grep kallsyms\_selftest} auszuführen,
um die Testergebnisse zu sammeln.
In der letzten Zeile wird \texttt{finish} angezeigt, was bedeutet,
dass der Test abgeschlossen ist. 

\paragraph{Include all symbols in kallsyms}$~$\\
CONFIG\_KALLSYMS\_ALL [=y] \textbf{[Y]}\\
Normalerweise enthält kallsyms nur die Symbole von Funktionen für schönere
OOPS-Meldungen und Backtraces (d. h. Symbole aus den Abschnitten text und
inittext). Dies ist für die meisten Fälle ausreichend. Nur wenn Sie Kernel-Live-Patching
oder andere weniger häufige Anwendungsfälle (z.~B. wenn ein Debugger verwendet
wird) aktivieren wollen, sind alle Symbole erforderlich (d. h. die Namen von Variablen
aus den Data-Abschnitten usw.).\\
Diese Option stellt sicher, dass alle Symbole in das Kernel-Image geladen werden
(d.h. Symbole aus allen Sektionen), was die Kernelgröße erhöht (je nach Kernelkonfiguration
kann sie 300KiB oder etwas Ähnliches betragen).\\
Sagen Sie N, es sei denn, Sie brauchen wirklich alle Symbole,
oder Kernel-Live-Patching.

\subsection{Kernel Performance Events And Counters \texorpdfstring{$\rightarrow$}{->}}
Kernel-Leistungsereignisse und -Zähler

\subsubsection{Kernel performance events and counters}
CONFIG\_PERF\_EVENTS [=y] \textbf{[Y]}\\
Aktivieren Sie die Kernel-Unterstützung für verschiedene von Software und Hardware
bereitgestellte Leistungsereignisse.

Software-Ereignisse werden entweder integriert oder über die Verwendung von generischen
Tracepoints unterstützt.

Die meisten modernen CPUs unterstützen Leistungsereignisse über Leistungszählerregister.
Diese Register zählen die Anzahl bestimmter Arten von hw-Ereignissen: z.~B. ausgeführte
Anweisungen, erlittene Cachemisses oder falsch vorhergesagte Verzweigungen -- ohne den
Kernel oder Anwendungen zu verlangsamen. Diese Register können auch Unterbrechungen
auslösen, wenn eine bestimmte Anzahl von Ereignissen überschritten wird -- und können so
dazu verwendet werden, ein Profil des Codes zu erstellen, der auf dieser CPU läuft.

Das Linux-Performance-Event-Subsystem bietet eine Abstraktion dieser Software- und
Hardware-Event-Fähigkeiten, die über einen Systemaufruf zugänglich sind und von dem
Dienstprogramm \texttt{perf} in \texttt{tools/perf/} verwendet werden.
Es stellt Zähler pro Task
und pro CPU zur Verfügung und bietet darüber hinaus Ereignisfunktionen.\\
Sagen Sie Y, wenn Sie unsicher sind.

\paragraph{Debug: use vmalloc to back perf mmap() buffers}$~$\\
CONFIG\_DEBUG\_PERF\_USE\_VMALLOC [=n] \textbf{[N]}\\
Verwendung von vmalloc-Speicher zur Sicherung von mmap()-Puffern. Hauptsächlich nützlich zum Debuggen des vmalloc-Codes auf Plattformen, die dies nicht erfordern.
Sagen Sie N, wenn Sie unsicher sind.

\subsection{Profiling support}
CONFIG\_PROFILING [=y] \textbf{[Y]}\\
Sagen Sie hier Y, um die erweiterten Unterstützungsmechanismen für das Profiling zu
aktivieren, die von Profilern verwendet werden.

\subsection{Kexec and crash features \texorpdfstring{$\rightarrow$}{->}}
Kexec und Absturzmerkmale

\subsubsection{Enable kexec system call}
CONFIG\_KEXEC [=y] \textbf{[Y]}\\
\texttt{kexec} ist ein Systemaufruf, der die Fähigkeit implementiert, den aktuellen Kernel
herunterzufahren und einen anderen Kernel zu starten. Es ist wie ein Neustart, aber er ist
unabhängig von der System-Firmware. Und wie ein Neustart können Sie damit jeden Kernel
starten, nicht nur Linux.
Der Name kommt von der Anlehnung mit dem Systemaufruf \texttt{exec}.
Es ist ein fortlaufender Prozess, um sicher zu sein, dass die Hardware eines Rechners
ordnungsgemäß heruntergefahren wird, seien Sie also nicht überrascht, wenn dieser Code bei
Ihnen zunächst nicht funktioniert. Zum Zeitpunkt des Verfassens dieses Artikels ist die
genaue Hardwareschnittstelle noch stark im Wandel, so dass keine gute Empfehlung
ausgesprochen werden kann.

\subsubsection{Enable kexec file based system call}
CONFIG\_KEXEC\_FILE [=y] \textbf{[Y]}\\
(Aktivieren des dateibasierten Systemaufrufs kexec)\\
Dies ist eine neue Version des Systemaufrufs \texttt{kexec}. Dieser Systemaufruf ist dateibasiert und
nimmt Dateideskriptoren als Systemaufrufsargument für Kernel und initramfs anstelle einer Liste
von Segmenten, wie sie vom kexec-Systemaufruf akzeptiert wird.

\paragraph{Verify kernel signature during kexec\_file\_load() syscall}$~$\\
CONFIG\_KEXEC\_SIG [=y] \textbf{[Y]}\\
Mit dieser Option wird der Syscall \texttt{kexec\_file\_load()} auf eine gültige Signatur des
Kernel-Images geprüft. Das Image kann immer noch ohne gültige Signatur geladen werden, es sei denn,
Sie aktivieren auch KEXEC\_SIG\_FORCE, aber wenn es eine Signatur gibt, die überprüft werden kann,
dann muss sie auch gültig sein.
Zusätzlich zu dieser Option müssen Sie die Signaturprüfung für den entsprechenden Kernel-Image-Typ,
der geladen wird, aktivieren, damit dies funktioniert.

\subparagraph{Require a valid signature in kexec\_file\_load() syscall}$~$\\
CONFIG\_KEXEC\_SIG [=n] \textbf{[N]}\\
Diese Option macht die Überprüfung der Kernelsignatur für den Syscall
\texttt{kexec\_file\_load()} zwingend erforderlich.

\subparagraph{Enable bzImage signature verification support}$~$\\
CONFIG\_KEXEC\_BZIMAGE\_VERIFY\_SIG [=n] \textbf{[N]}\\
Aktivierung der Unterstützung von bzImage für die Signaturprüfung.

\subsubsection{kexec jump}
CONFIG\_KEXEC\_JUMP [=y] \textbf{[Y]}\\
Sprung zwischen Original-Kernel und kexeced-Kernel und Aufruf von Code im physikalischen
Adressmodus über KEXEC

\subsubsection{kexec crash dumps}
CONFIG\_KEXEC\_DUMP [=y] \textbf{[Y]}\\
Absturzdump (Speicherauszug) erzeugen, nachdem er von kexec gestartet wurde.
Dies sollte normalerweise nur in speziellen Crash-Dump-Kerneln gesetzt werden, die im Hauptkernel
mit kexec-tools in einen speziell reservierten Bereich geladen werden und dann später nach einem
Absturz von kdump/kexec ausgeführt werden. Der Crash-Dump-Kernel muss mit PHYSICAL\_START auf eine
Speicheradresse kompiliert werden, die nicht vom Hauptkernel oder BIOS verwendet wird, oder er muss
als relocatable image (CONFIG\_RELOCATABLE=y) erstellt werden.\\
Für weitere Details siehe Documentation/admin-guide/kdump/kdump.rst

Für s390 aktiviert diese Option auch zfcpdump.\\
Siehe auch $<$file:Documentation/s390/zfcpdump.rst$>$

\paragraph{Update the crash elfcorehdr on system configuration changes}$~$\\
CONFIG\_CRASH\_HOTPLUG [=y] \textbf{[Y]}\\
Aktivierung der direkten Aktualisierung der Crash-Elfcorehdr (die die Liste der CPUs und
Speicherbereiche enthält, die bei einem Absturz gelöscht werden sollen) als Reaktion auf
Hot-Plug/Unplug oder Online/Offline von CPUs oder Speicher. Dies ist ein sehr viel
fortschrittlicherer Ansatz als der Versuch dies im Userspace zu tun.\\
Wenn Sie unsicher sind, sagen Sie Y.

\subparagraph{Specify the maximum number of memory regions for the elfcorehdr}$~$\\
CONFIG\_CRASH\_MAX\_MEMORY\_RANGES [=8192] \textbf{[8192]}\\
Für den Pfad des Systemaufrufs \texttt{kexec\_file\_load()} ist die maximale Anzahl
der Speicherbereiche anzugeben, die der elfcorehdr-Puffer/das elfcorehdr-Segment aufnehmen kann.
Diese Regionen werden über \texttt{walk\_system\_ram\_res()} ermittelt, z.~B. die
'System RAM'-Einträge in /proc/iomem. Dieser Wert wird mit NR\_CPUS\_DEFAULT kombiniert und mit
\texttt{sizeof(Elf64\_Phdr)} multipliziert, um die endgültige elfcorehdr-Speicherpuffer-/Segmentgröße
zu bestimmen. Der Wert 8192 beispielsweise deckt ein (dünn besiedeltes) 1TiB-System ab,
das aus 128MiB-Memblöcken besteht, und führt zu einer elfcorehdr-Speicher\-puffer-/Segmentgröße
von unter 1MiB. Dies ist eine vernünftige Wahl, um sowohl Baremetal- als auch virtuelle
Maschinenkonfigurationen zu unterstützen.\\
Für den Syscall-Pfad \texttt{kexec\_load()}
ist CRASH\_MAX\_MEMORY\_RANGES Teil der Berechnung hinter dem Wert,
der über das Attribut /sys/kernel/crash\_elfcorehdr\_size bereitgestellt wird.

\section{64-bit kernel}
CONFIG\_64BIT [=y] \textbf{[Y]}\\
Sagen Sie Y für ja, zur Erstellung eines 64-Bit-Kernels - früher bekannt als x86\_64\\
Sagen Sie N für nein, um einen 32-Bit-Kernel zu erstellen - früher bekannt als i386

\section{Processor type and features \texorpdfstring{$\rightarrow$}{->}}
Prozessortyp und Eigenschaften

\subsection{Symmetric multi-processing support}
CONFIG\_SMP [=y] \textbf{[Y]}\\
Dies ermöglicht die Unterstützung von Systemen mit mehr als einer CPU. Wenn Sie ein System mit nur
einer CPU haben, sagen Sie N. Wenn Sie ein System mit mehr als einer CPU haben, sagen Sie Y.
Wenn Sie hier N angeben, läuft der Kernel auf Uni- und Multi\-prozessor"=Maschinen, verwendet aber nur
eine CPU einer Multi\-pro\-zes\-sor"=Ma\-schine.
Wenn Sie hier Y angeben, läuft der Kernel auf vielen, aber nicht auf
allen Uni\-pro\-zes\-sor"=Ma\-schi\-nen.

Auf einer Uni\-pro\-zes\-sor"=Maschine läuft der Kernel schneller, wenn Sie hier N angeben.
Beachten Sie, dass der Kernel nicht auf 486er-Architekturen läuft, wenn Sie hier Y angeben und unter
\glqq Prozessor\-familie\grqq{} die Architektur \glqq 586\grqq{} oder \glqq Pentium\grqq{} auswählen.

Ebenso funktionieren Multi\-pro\-zes\-sor"=Kernel für die \glqq PPro\grqq{}"=Ar\-chi\-tek\-tur
möglicherweise nicht auf allen Pentium"=basierten Boards.

Benutzer von Multi\-prozessor-Maschinen, die hier Y für \glqq Ja\grqq{} angeben, sollten auch
\glqq Ja\grqq{}
zu \glqq Enhanced Real Time Clock Support\grqq{} (siehe unten) sagen.
Der \glqq Advanced Power Management\grqq{}-Code wird deaktiviert, wenn Sie hier
\glqq Y\grqq{} angeben. Siehe auch $<$file:Documentation/arch/x86/i386/IO-APIC.rst$>$,
$<$file:Documentation/admin-guide/lockup-watchdogs.rst$>$ und das SMP-HOWTO, verfügbar unter:\\
\url{http://www.tldp.org/docs.html\#howto}.\\
Wenn Sie nicht wissen, was Sie hier tun sollen, sagen Sie N.

\subsection{Support x2apic}
CONFIG\_X86\_X2APIC [=y] \textbf{[Y]}\\
Dies ermöglicht die Unterstützung von x2apic auf CPUs, die über diese Funktion verfügen.
Dies ermöglicht 32-Bit-Apic-IDs (so dass es sehr große Systeme unterstützen kann) und greift auf den
lokalen apic über MSRs und nicht über mmio zu. Einige Intel-Systeme ab ca. 2022 sind in den x2APIC-Modus
gesperrt und können nicht auf die alten APIC-Modi zurückgreifen, wenn SGX oder TDX im BIOS aktiviert
sind. Ohne Aktivierung dieser Option booten sie mit stark eingeschränkter Funktionalität.\\
Wenn Sie nicht wissen, was Sie hier tun sollen, sagen Sie N.

\subsection{Enable MPS table}
CONFIG\_X86\_MPPARSE [=y] \textbf{[Y]}\\
Für alte smp-Systeme, die keine richtige acpi-Unterstützung haben. Neuere Systeme
(insbesondere mit 64bit-CPUs) mit acpi-Unterstützung, werden von MADT und DSDT überschrieben.

\subsection{x86 CPU resource control support}
CONFIG\_X86\_CPU\_RESCTRL [=y] \textbf{[Y]}\\
Aktivieren Sie die Unterstützung der x86-CPU-Ressourcensteuerung. Unterstützung für die Zuweisung und
Überwachung der Nutzung von Systemressourcen durch die CPU. Intel nennt dies Intel Resource Director
Technology (Intel(R) RDT). Weitere Informationen über RDT finden Sie im Intel x86 Architecture
Software Developer Manual. AMD bezeichnet dies als AMD Platform Quality of Service (AMD QoS).\\
Weitere Informationen über AMD QoS finden Sie im Handbuch AMD64 Technology Platform Quality of Service
Extensions.\\
Sagen Sie N, wenn Sie unsicher sind.

\subsection{Support for extended (non-PC) x86 platforms}
CONFIG\_X86\_EXTENDED\_PLATFORM [=n] \textbf{[N]}\\
Wenn Sie diese Option deaktivieren, unterstützt der Kernel nur Standard-PC-Plattformen
(was die große Mehrheit der Systeme da draußen abdeckt).
Wenn Sie diese Option aktivieren, können Sie die Unterstützung für die folgenden (nicht-PC)
64-Bit-x86-Plattformen auswählen:
\begin{itemize}
	\item Numascale NumaChip
	\item ScaleMP vSMP
	\item SGI Ultraviolet
\end{itemize}
Wenn Sie eines dieser Systeme haben, oder wenn Sie einen generischen Distributionskernel bauen
wollen, geben Sie hier Y an -- andernfalls sagen Sie N.

\subsection{Intel Low Power Subsystem Support}
CONFIG\_X86\_INTEL\_LPSS [=y] \textbf{[Y]}\\
Wählen Sie diese Option, um Unterstützung für das Intel Low Power Subsystem zu erstellen,
wie es auf dem Intel Lynxpoint PCH zu finden ist. Die Auswahl dieser Option ermöglicht Dinge wie
Clock Tree (Common Clock Framework) und Pincontrol, die von den LPSS-Peripherietreibern benötigt werden.

\subsection{AMD ACPI2Platform devices support}
CONFIG\_X86\_AMD\_PLATFORM\_DEVICE [=y] \textbf{[Y]}\\
Wählen Sie diese Option, um AMD-spezifische ACPI-Geräte wie I2C, UART, GPIO, die auf AMD Carrizo
und späteren Chipsätzen zu finden sind, als Plattformgeräte zu interpretieren. I2C und UART hängen
von COMMON\_CLK ab, um den Takt zu setzen. Der GPIO-Treiber ist im PINCTRL-Subsystem implementiert.

\subsection{Intel SoC IOSF Sideband support for SoC platforms}
CONFIG\_IOSF\_MBI [=y] \textbf{[Y]}\\
Diese Option aktiviert die Unterstützung des Seitenband-Registerzugriffs für Intel SoC-Plattformen.
Auf diesen Plattformen wird das IOSF-Seitenband anstelle von MSRs für einige Registerzugriffe
verwendet, vor allem, aber nicht ausschließlich, für thermische und Stromversorgungs-Register.
Treiber können die Verfügbarkeit dieser Geräte abfragen, um festzustellen, ob sie das Seitenband
benötigen, um auf diesen Plattformen zu funktionieren.
Das Seitenband ist auf den folgenden SoC-Produkten verfügbar.
\begin{itemize}
	\item BayTrail
	\item Braswell
	\item Quark
\end{itemize}
Sie sollten Y sagen, wenn Sie einen Kernel auf einem dieser SoCs ausführen.

\subsubsection{Enable IOSF sideband access through debugfs}
CONFIG\_IOSF\_MBI\_DEBUG [=n] \textbf{[N]}\\
Wählen Sie diese Option, um die IOSF-Seitenband-Zugriffsregister (MCR, MDR, MCRX) über debugfs
freizugeben, um Registerinformationen von verschiedenen Einheiten auf dem SoC zu schreiben und
zu lesen. Dies ist sehr nützlich, um Informationen über den Gerätezustand für Debugging und
Analyse zu erhalten. Da es sich um einen allgemeinen Zugriffsmechanismus handelt, müssen die
Benutzer dieser Option das Gerät, auf das sie zugreifen wollen, genau kennen.\\
Wenn Sie die Option nicht benötigen oder im Zweifel sind, sagen Sie N.

\subsection{Single-depth WCHAN output}
CONFIG\_SHED\_OMIT\_FRAME\_POINTER [=y] \textbf{[Y]}\\
Berechne einfachere /proc/$<$PID$>$/wchan-Werte. Wenn diese Option deaktiviert ist, werden die
wchan-Werte zur aufrufenden Funktion zurückgeführt. Dies liefert genauere wchan-Werte, allerdings
auf Kosten eines etwas größeren Planungsaufwands (scheduling overhead).\\
Im Zweifelsfall sagen Sie "Y".

\subsection{Linux guest support \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_HYPERVISOR\_GUEST [=y] \textbf{[Y]}\\
Geben Sie hier Y ein, um Optionen für die Ausführung von Linux unter verschiedenen Hypervisoren zu
aktivieren. Diese Option aktiviert die grundlegende Hypervisor-Erkennung und die Einrichtung der
Plattform.
Wenn Sie N sagen, werden alle Optionen in diesem Untermenü übersprungen und deaktiviert, und die
Linux-Gastunterstützung wird nicht eingebaut.

\subsubsection{Enable paravirtualization code}
CONFIG\_PARAVIRT [=y] \textbf{[Y]}\\
Der Kernel wird so verändert, dass er sich selbst modifizieren kann, wenn er unter einem Hypervisor
ausgeführt wird, was die Leistung gegenüber einer vollständigen Virtualisierung erheblich verbessern
kann. Wenn der Kernel jedoch ohne Hypervisor ausgeführt wird, ist er theoretisch langsamer und etwas
größer.

\subsubsection{paravirt-ops debugging}
CONFIG\_PARAVIRT\_DEBUG [=n] \textbf{[N]}\\
Ermöglicht das Debuggen von paravirt\_ops Interna.
Insbesondere BUG, wenn eine paravirt\_op fehlt, wenn sie aufgerufen wird.

\subsubsection{Paravirtualization layer for spinlocks}
CONFIG\_PARAVIRT\_SPINLOCKS [=y] \textbf{[Y]}\\
Paravirtualisierte Spinlocks ermöglichen es einem pvops-Backend, die Spinlock-Implementierung durch
etwas Virtualisierungsfreundliches zu ersetzen (z.~B. Blockieren der virtuellen CPU anstelle
von Spinning).
Dies hat nur minimale Auswirkungen auf native Kernel und bringt einen deutlichen Leistungsvorteil
für paravirtualisierte KVM/Xen-Kernel.\\
Wenn Sie unsicher sind, wie Sie diese Frage beantworten sollen, antworten Sie mit Y.

\subsubsection{Xen guest support}
CONFIG\_XEN [=y] \textbf{[Y]}\\
Dies ist der Linux-Xen-Port. Wenn Sie dies aktivieren, kann der Kernel in einer
paravirtualisierten Umgebung unter dem Xen-Hypervisor booten.

\paragraph{Xen PV guest support}$~$\\
CONFIG\_XEN\_PV [=y] \textbf{[Y]}\\
Der Betrieb als Xen PV-Gast wird unterstützt.

\subparagraph{Limit Xen pv-domain memory to 512GB}$~$\\
CONFIG\_XEN\_512GB [=y] \textbf{[Y]}\\
Begrenzen der paravirtualisierten Benutzerdomänen auf 512~GB RAM.
Die Xen-Tools und die Tools zur Analyse von Crash-Dumps unterstützen möglicherweise keine pv-Domänen
mit mehr als 512~GB~RAM. Diese Option steuert die Standardeinstellung des Kernels, um nur bis zu
512~GB oder mehr zu verwenden.
Es ist jederzeit möglich, die Standardeinstellung durch Angabe des Boot-Parameters
\texttt{xen\_512gb\_limit} zu ändern.

\paragraph{Xen PVHVM guest support}$~$\\
CONFIG\_XEN\_PVHVM\_GUEST [=y] \textbf{[Y]}\\
Der Betrieb als Xen PVHVM-Gast wird unterstützt.

\paragraph{Enable Xen debug and tuning parameters in debugfs}$~$\\
CONFIG\_XEN\_DEBUG\_FS [=n] \textbf{[N]}\\
Der Betrieb als Xen PV-Gast wird unterstützt.

\paragraph{Xen PVH guest support}$~$\\
CONFIG\_XEN\_PVH [=y] \textbf{[Y]}\\
Der Betrieb als Xen PVH-Gast wird unterstützt.

\subsubsection{Xen Dom0 support}
CONFIG\_XEN\_DOM0 [=y] \textbf{[Y]}\\
Der Betrieb als Xen Dom0-Gast wird unterstützt.

\subsubsection{Always use safe MSR accesses in PV guests}
CONFIG\_XEN\_PV\_MSR\_SAFE [=y] \textbf{[Y]}\\
Verwenden Sie sichere (nicht fehlerhafte) MSR-Zugriffsfunktionen, auch wenn der MSR-Zugriff
ohnehin nicht fehlerhaft sein sollte. Der Standardwert kann mit dem Boot-Parameter
\texttt{xen\_msr\_safe} geändert werden.

\subsubsection{KVM Guest support (including kvmclock)}
CONFIG\_KVM\_GUEST [=y] \textbf{[Y]}\\
Diese Option ermöglicht verschiedene Optimierungen für die Ausführung unter dem KVM-Hypervisor.
Sie beinhaltet eine paravirtualisierte Uhr, so dass der Host dem Gast eine Zeitinfrastruktur wie
die Tageszeit und die Systemzeit zur Verfügung stellt, anstatt sich auf eine PIT-Emulation
(oder wahrscheinlich eine andere) durch das zugrunde liegende Gerätemodell zu verlassen.

\subsubsection{Disable host haltpoll when loading haltpoll driver}
CONFIG\_ARCH\_CPUIDLE\_HALTPOLL [=y] \textbf{[Y]}\\
(Haltpoll des Hosts beim Laden des Haltpoll-Treibers deaktivieren)\\
Wenn Sie unter KVM virtualisieren, deaktiviert den haltpoll des Hosts.

\subsubsection{Support for running PVH guests}
CONFIG\_PVH [=y] \textbf{[Y]}\\
Diese Option aktiviert den PVH-Einstiegspunkt für virtuelle Gastmaschinen,
wie in der x86/HVM Direct Boot ABI angegeben.

\subsubsection{Paravirtual steal time accounting}
CONFIG\_PARAVIRT\_TIME\_ACCOUNTING [=y] \textbf{[Y]}\\
Wählen Sie diese Option aus, um die Berechnung der Zeit für das Stehlen von Aufgaben mit feiner
Granularität zu aktivieren. Die Zeit, die für die Ausführung anderer Aufgaben parallel zur aktuellen
vCPU aufgewendet wird, ist von der vCPU-Leistung abgezogen. Um dies zu berücksichtigen,
kann es zu geringen Leistungseinbußen kommen.\\
Im Zweifelsfall geben Sie hier N an.

\subsubsection{Jailhouse non-root cell support}
CONFIG\_JAILHOUSE\_GUEST [=y] \textbf{[Y]}\\
Diese Option ermöglicht es, Linux als Gast in einer Jailhouse-Nicht-Root-Zelle auszuführen.
Sie können diese Option deaktiviert lassen, wenn Sie Jailhouse nur starten und Linux anschließend
in der Root-Zelle ausführen möchten.

\subsubsection{ACRN Guest support}
CONFIG\_ACRN\_GUEST [=y] \textbf{[Y]}\\
Diese Option ermöglicht die Ausführung von Linux als Gast im ACRN-Hypervisor.
ACRN ist ein flexibler, leichtgewichtiger Referenz-Open-Source-Hypervisor, der mit Blick auf Echtzeit
und Sicherheitskritik entwickelt wurde. Er wurde für eingebettete IOT mit kleinem Platzbedarf und
Echtzeitfunktionen entwickelt. Weitere Einzelheiten finden Sie unter \url{https://projectacrn.org/}.

\subsubsection{Intel TDX (Trust Domain Extensions) - Guest Support}
CONFIG\_INTEL\_TDX\_GUEST [=y] \textbf{[Y]}\\
Unterstützung der Ausführung als Gast unter Intel TDX.\\
Ohne diese Unterstützung kann der Gastkernel nicht booten oder unter TDX laufen. TDX umfasst
Speicherverschlüsselungs- und Integritätsfunktionen, die die Vertraulichkeit und Integrität des
Gastspeicherinhalts und des CPU-Status schützen. TDX-Gäste sind vor einigen Angriffen durch den
VMM geschützt.

\subsection{Processor family (Generic-x86-64) \texorpdfstring{$\rightarrow$}{->}}
Dies ist der Prozessortyp Ihrer CPU. Diese Information wird für Optimierungszwecke verwendet.
Um einen Kernel zu kompilieren, der auf allen unterstützten x86-CPU-Typen laufen kann (wenn auch
nicht optimal schnell), können Sie hier \glqq 486\grqq{} angeben. Beachten Sie, dass der 386er
nicht mehr unterstützt wird, dies schließt AMD/Cyrix/Intel 386DX/DXL/SL/SLC/SX, Cyrix/TI 486DLC/DLC2,
UMC 486SX-S und den NexGen Nx586 ein. Der Kernel läuft nicht notwendigerweise auf älteren
Architekturen als der von Ihnen gewählten, z.~B. läuft ein Pentium-optimierter Kernel auf einem PPro,
aber nicht unbedingt auf einem i486.

Hier sind die empfohlenen Einstellungen für höchste Geschwindigkeit:
\begin{itemize}
	\item \texttt{486} für den AMD/Cyrix/IBM/Intel 486DX/DX2/DX4 oder SL/SLC/SLC2/SLC3/SX/SX2 und UMC U5D oder U5S.
	\item \texttt{586} für generische Pentium-CPUs, denen das TSC-Register (Zeitstempelzähler) fehlt.
	\item \texttt{Pentium-Classic} für den Intel Pentium.
	\item \texttt{Pentium-MMX} für den Intel Pentium MMX.
	\item \texttt{Pentium-Pro} für den Intel Pentium Pro.
	\item \texttt{Pentium-II} für den Intel Pentium II oder den Pre-Coppermine Celeron.
	\item \texttt{Pentium-III} für den Intel Pentium III oder Coppermine Celeron.
	\item \texttt{Pentium-4} für den Intel Pentium 4 oder den P4-basierten Celeron.
	\item \texttt{K6} für den AMD K6, K6-II und K6-III (auch bekannt als K6-3D).
	\item \texttt{Athlon} für die AMD K7-Familie (Athlon/Duron/Thunderbird).
	\item \texttt{Opteron/Athlon64/Hammer/K8} für alle K8 und neuere AMD-CPUs.
	\item \texttt{Crusoe} für die Transmeta Crusoe-Serie.
	\item \texttt{Efficeon} für die Transmeta Efficeon-Reihe.
	\item \texttt{Winchip-C6} für den ursprünglichen IDT-Winchip.
	\item \texttt{Winchip-2} für IDT-Winchips mit 3dNow! Fähigkeiten.
	\item \texttt{AMD Elan} für die 32-Bit AMD Elan Embedded CPU.
	\item \texttt{GeodeGX1} für Geode GX1 (Cyrix MediaGX).
	\item \texttt{Geode GX/LX} für AMD Geode GX und LX Prozessoren.
	\item \texttt{CyrixIII/VIA C3} für VIA Cyrix III oder VIA C3.
	\item \texttt{VIA C3-2} für VIA C3-2 "Nehemiah" (Modell 9 und höher).
	\item \texttt{VIA C7} für VIA C7.
	\item \texttt{Intel P4} für die Pentium 4/Netburst-Mikroarchitektur.
	\item \texttt{Core 2/newer Xeon} für alle Core2 und neueren Intel-CPUs.
	\item \texttt{Intel Atom} für die CPUs mit Atom-Mikroarchitektur.
	\item \texttt{Generic-x86-64} für einen Kernel, der auf jeder x86-64-CPU läuft.
\end{itemize}
Weitere Details finden Sie im Hilfetext der jeweiligen Option. Wenn Sie nicht wissen,
was Sie tun sollen, wählen Sie \texttt{486}.\\[1em]
Derzeit (Kernelversion 6.6.x) können Sie nur aus fünf auswählen:

\subsubsection{Opteron/Athlon64/Hammer/K8}
CONFIG\_MK8 [=n] \textbf{[N]}\\
Wählen Sie diese Option für einen Prozessor der AMD Opteron- oder Athlon64 Hammer"=Fa\-mi\-lie.
Er\-mög\-licht die Verwendung einiger erweiterter Anweisungen und übergibt entsprechende
Optimierungsflags an den GCC.

\subsubsection{Intel P4 / older Netburst based Xeon}
CONFIG\_MPSC [=n] \textbf{[N]}\\
Optimiert für Intel Pentium 4, Pentium D und ältere Nocona/Dempsey Xeon CPUs mit Intel 64bit,
die mit x86-64 kompatibel sind. Beachten Sie, dass die neuesten Xeons (Xeon 51xx und 53xx) nicht
auf dem Netburst-Kern basieren und diese Option nicht verwenden sollten.\\
Sie können sie anhand des Feldes cpu family in /proc/cpuinfo unterscheiden.
Familie 15 ist ein älterer Xeon, Familie 6 ein neuerer.

\subsubsection{Intel P4 / older Netburst based Xeon}
CONFIG\_MCORE2 [=n] \textbf{[Y]}\\
Wählen Sie dies für Intel Core 2 und neuere Core 2 Xeons (Xeon 51xx und 53xx) CPUs.\\
Sie können neuere von älteren Xeons anhand der CPU-Familie in /proc/cpuinfo unterscheiden.
Neuere haben 6 und ältere 15 (kein Tippfehler).

\subsubsection{Intel Atom}
CONFIG\_MATOM [=n] \textbf{[N]}\\
Wählen Sie diese Option für die Intel Atom-Plattform. Intel Atom CPUs haben eine
In-Order-Pipelining-Architektur und können daher von entsprechend optimiertem Code profitieren.
Verwenden Sie einen aktuellen GCC mit spezieller Atom-Unterstützung, um die Vorteile dieser Option
voll ausschöpfen zu können.

\subsubsection{Generic-x86-64}
CONFIG\_GENERIC\_CPU [=y] \textbf{[N]}\\
Allgemeine x86-64-CPU. Läuft gleich gut auf allen x86-64-CPUs.

\subsection{Old AMD GART IOMMU support}
CONFIG\_GART\_IOMMU [=n] \textbf{[N]}\\
Bietet einen Treiber für ältere AMD Athlon64/Opteron/Turion/Sempron GART basierte Hardware
\mbox{IOMMUs} an.
Der GART unterstützt vollen DMA-Zugriff für Geräte mit 32-Bit-Zugriffsbeschränkungen auf Systemen
mit mehr als 3~GB. Dies wird normalerweise für USB, Sound, viele IDE/SATA-Chipsätze und einige andere
Geräte benötigt. Neuere Systeme haben in der Regel eine moderne AMD IOMMU, die über die
Konfigurationsoption CONFIG\_AMD\_IOMMU=y unterstützt wird. In normalen Konfigurationen ist dieser
Treiber nur aktiv, wenn er benötigt wird:
Es sind mehr als 3~GB Arbeitsspeicher vorhanden und das System enthält ein auf 32~Bit
begrenztes Gerät.\\
Wenn Sie unsicher sind, sagen Sie Y.

\subsection{Enable Maximum number of SMP Processors and NUMA Nodes}
CONFIG\_MAXSMP [=n] \textbf{[N]}\\
Aktivieren der maximalen Anzahl von CPUs- und NUMA-Knoten für diese Architektur.\\
Wenn Sie unsicher sind, sagen Sie N.

\subsection{Maximum number of CPUs}
CONFIG\_NR\_CPUS [=320] \textbf{[8]}\\
Hier können Sie die maximale Anzahl von CPUs angeben, die dieser Kernel unterstützen soll.
Wenn CPUMASK\_OFFSTACK aktiviert ist, ist der maximal unterstützte Wert 8192, andernfalls
ist der maximale Wert 512.  Der Mindestwert, der Sinn macht, ist 2.

Dies dient lediglich dazu, Speicher zu sparen: jede unterstützte CPU fügt dem Kernel-Image
etwa 8~kB hinzu.

\subsection{Cluster scheduler support}
CONFIG\_SCHED\_CLUSTER [=y] \textbf{[N]}\\
Die Unterstützung des Cluster-Schedulers verbessert die Entscheidungsfindung des CPU-Schedulers
beim Umgang mit Maschinen, die Cluster von CPUs haben. Mit Cluster sind in der Regel mehrere CPUs
gemeint, die eng beieinander liegen und sich Mid-Level-Caches, Last-Level-Cache-Tags oder interne
Busse teilen.

\subsection{Multi-core scheduler support}
CONFIG\_SCHED\_MC [=y] \textbf{[Y]}\\
Die Unterstützung des Multi-Core-Schedulers verbessert die Entscheidungsfindung des CPU-Schedulers
beim Umgang mit Multi-Core-CPU-Chips auf Kosten eines leicht erhöhten Overheads an einigen Stellen.\\
Wenn Sie unsicher sind, geben Sie hier N an.

\subsubsection{CPU core priorities scheduler support}
CONFIG\_SCHED\_MC\_PRIO [=y] \textbf{[Y]}\\
Bei CPUs mit Intel Turbo-Boost-Max-Technik 3.0 wird die Reihenfolge der Kerne bei der Herstellung
festgelegt, so dass bestimmte Kerne höhere Turbofrequenzen erreichen können
(bei Single-Thread-Arbeitslasten) als andere. Durch die Aktivierung dieser Kernel-Funktion wird
der Scheduler über die TBM3- (auch ITMT-) Prioritätsreihenfolge der CPU-Kerne informiert und passt
die CPU-Auswahllogik des Schedulers entsprechend an, so dass eine höhere Gesamtsystemleistung
erzielt werden kann. Diese Funktion hat keine Auswirkungen auf CPUs ohne diese Funktion.\\
Wenn Sie unsicher sind, geben Sie hier Y an.

\subsection{Reroute for broken boot IRQs}
CONFIG\_X86\_REROUTE\_FOR\_BROKEN\_BOOT\_IRQS [=y] \textbf{[Y]}\\
Diese Option ermöglicht eine Umgehung, die eine Quelle für unerwünschte Unterbrechungen behebt.
Dies wird empfohlen, wenn die Thread-Interrupt-Behandlung auf Systemen verwendet wird, bei denen
die Erzeugung von überflüssigen \glqq Boot-Interrupts\grqq{} nicht deaktiviert werden kann.
Einige Chipsätze erzeugen einen Legacy-INTx-\glqq Boot-IRQ\grqq{}, wenn der IRQ-Eintrag im
IO-APIC des Chipsatzes maskiert ist (wie es z.~B. der RT-Kernel während der Interruptbehandlung
tut). Bei Chipsätzen, bei denen diese Boot-IRQ-Erzeugung nicht deaktiviert werden kann, wird
durch diese Abhilfe die ursprüngliche IRQ-Leitung maskiert, so dass nur der entsprechende
\glqq Boot-IRQ\grqq{} an die CPUs geliefert wird. Die Problemumgehung weist den Kernel außerdem
an, den IRQ-Handler auf der Boot-IRQ-Leitung einzurichten. Auf diese Weise wird nur ein Interrupt
an den Kernel geliefert. Andernfalls kann der zweite Interrupt den Kernel dazu veranlassen,
(lebenswichtige) Interrupt-Leitungen herunterzufahren. Betrifft nur
\glqq defekte\grqq{} Chipsätze. Die gemeinsame Nutzung von Interrupts kann auf diesen Systemen
erhöht werden.

\subsection{Machine Check / overheating reporting}
CONFIG\_X86\_MCE [=y] \textbf{[Y]}\\
(Maschinenprüfung / Überhitzungsmeldung)
Durch die Unterstützung von Machine Check kann der Prozessor den Kernel benachrichtigen,
wenn er ein Problem feststellt (z.~B. Überhitzung, Datenbeschädigung). Welche Maßnahmen der
Kernel ergreift, hängt von der Schwere des Problems ab und reicht von Warnmeldungen bis
zum Anhalten des Rechners.

\subsubsection{Support for deprecated /dev/mcelog character device}
CONFIG\_X86\_MCELOG\_LEGACY [=n] \textbf{[N]}\\
Aktivierung der Unterstützung für /dev/mcelog, die vom alten mcelog-Benutzerraum-Logging-Daemon
(mcelog userspace logging daemon) benötigt wird. Erwägen Sie den Umstieg auf die neue
Generation des rasdaemon.

\subsubsection{Intel MCE features}
CONFIG\_X86\_MCE\_INTEL [=y] \textbf{[Y]}\\
Zusätzliche Unterstützung für Intel-spezifische MCE-Funktionen wie den
Temperaturmonitor (thermal monitor).

\subsubsection{AMD MCE features}
CONFIG\_X86\_MCE\_AMD [=y] \textbf{[N]}\\
Zusätzliche Unterstützung für AMD-spezifische MCE-Funktionen wie den
DRAM-Fehlerschwellenwert (DRAM Error Threshold).

\subsection{Machine check injector support}
CONFIG\_X86\_MCE\_INJECT [=m] \textbf{[M]}\\
Unterstützung bei der Einspeisung von Maschinenprüfungen zu Testzwecken. Wenn Sie nicht wissen,
was eine Maschinenprüfung ist und Sie keine Kernel-Qualitätssicherung durchführen, können Sie
mit Sicherheit N sagen, also nein.

\subsection{Performance monitoring \texorpdfstring{$\rightarrow$}{->}}
Leistungsüberwachung

\subsubsection{Intel uncore performance events}
CONFIG\_PERF\_EVENTS\_INTEL\_UNCORE [=m] \textbf{[M]}\\
Unterstützung für Intel-Uncore-Leistungsereignisse. Diese sind auf NehalemEX
und moderneren Prozessoren verfügbar.

\subsubsection{Intel/AMD rapl performance events}
CONFIG\_PERF\_EVENTS\_INTEL\_RAPL [=m] \textbf{[M]}\\
Unterstützung für Intel- und AMD-RAPL-Leistungsereignisse zur
Leistungsüberwachung auf modernen Prozessoren.

\subsubsection{Intel cstate performance events}
CONFIG\_PERF\_EVENTS\_INTEL\_CSTATE [=m] \textbf{[M]}\\
Einbeziehung der Unterstützung für Intel cstate performance events für die
Leistungsüberwachung auf modernen Prozessoren.

\subsubsection{AMD Processor Power Reporting Mechanism}
CONFIG\_PERF\_EVENTS\_AMD\_POWER [=m] \textbf{[M]}\\
Unterstützung von Stromversorgungsberichten für AMD-Prozessoren.\\
Derzeit wird die Schnitt\-stel\-le X86\_FEATURE\_ACC\_POWER
(CPUID Fn8000\_0007\_EDX[12]) genutzt,
um den durchschnittlichen Stromverbrauch von Prozessoren der Familie 15h zu
berechnen. 

\subsubsection{AMD Uncore performance events}
CONFIG\_PERF\_EVENTS\_AMD\_UNCORE [=m] \textbf{[M]}\\
Unterstützung für AMD-Uncore-Leistungsereignisse für die Verwendung mit z.~B.\\
\texttt{perf stat -e amd\_l3/.../,amd\_df/.../}.\\
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M: das Modul wird \texttt{amd-uncore} genannt.

\subsubsection{AMD Zen3 Branch Sampling support}
CONFIG\_PERF\_EVENTS\_AMD\_BRS [=y] \textbf{[Y]}\\
Aktivieren Sie die AMD Zen3 Branch Sampling-Unterstützung (BRS), die bis zu 16 aufeinanderfolgende
Verzweigungen in Registern erfasst.

\subsubsection{IOPERM and IOPL Emulation}
CONFIG\_X86\_IOPL\_IOPERM [=y] \textbf{[Y]}\\
Dies ermöglicht die ioperm()- und iopl()-Systemaufrufe, die für Legacy-Anwendungen erforderlich sind.
Bei der Legacy-IOPL-Unterstützung handelt es sich um einen weitreichenden Mechanismus, der es dem Userspace
ermöglicht, neben dem Zugriff auf alle 65536 E/A-Ports auch Interrupts zu deaktivieren. Um diesen Zugriff
zu erhalten, benötigt der Aufrufer CAP\_SYS\_RAWIO-Fähigkeiten und die Erlaubnis von potenziell aktiven
Sicherheitsmodulen. Die Emulation schränkt die Funktionalität des Syscalls auf den Zugriff auf alle E/A-Ports
ein, verhindert aber die Möglichkeit, Interrupts aus dem Userspace zu deaktivieren, was bei Verwendung des
Hardware-IOPL-Mechanismus möglich wäre.

\subsubsection{Late microcode loading (DANGEROUS)}
CONFIG\_MICROCODE\_LATE\_LOADING [=n] \textbf{[N]}\\
Das späte Laden von Mikrocode, wenn das System bereits läuft und Befehle ausführt, ist eine heikle
Angelegenheit und sollte nach Möglichkeit vermieden werden. Allein die Abfolge der Synchronisierung
aller Kerne und SMT-Threads ist ein zerbrechlicher Tanz, der nicht garantiert, dass die Kerne nach
dem Laden nicht softlocking werden. Daher sollten Sie dies auf eigenes Risiko tun. Das späte Laden
färbt auch den Kernel.

\subsubsection{/dev/cpu/*/msr - Model-specific register support}
CONFIG\_X86\_MSR [=y] \textbf{[Y]}\\
Dieses Gerät ermöglicht privilegierten Prozessen den Zugriff auf die modellspezifischen x86-Register (MSRs).\\
Es ist ein Zeichengerät mit Major 202 und Minors 0 bis 31 für
\texttt{/dev/cpu/0/msr} bis \texttt{/dev/cpu/31/msr}.
MSR-Zugriffe sind bei Multiprozessorsystemen an eine bestimmte CPU gerichtet.

\subsubsection{/dev/cpu/*/cpuid - CPU information support}
CONFIG\_X86\_CPUID [=y] \textbf{[Y]}\\
Dieses Gerät ermöglicht Prozessen den Zugriff auf den x86 CPUID-Befehl, der auf einem bestimmten Prozessor
ausgeführt werden soll. Es handelt sich um ein Zeichengerät mit Major 203 und Minors 0 bis 31 für
\texttt{/dev/cpu/0/cpuid} bis \texttt{/dev/cpu/31/cpuid}.

\subsubsection{Enable 5-level page tables support}
CONFIG\_X86\_5LEVEL [=y] \textbf{[Y]}\\
5-Level-Paging ermöglicht den Zugriff auf einen größeren Adressraum:
bis zu 128~PiB virtueller Adressraum und 4~PiB physikalischer Adressraum. Es wird von zukünftigen Intel-CPUs
unterstützt werden. Ein Kernel mit aktivierter Option kann auf Rechnern gebootet werden, die 4- oder 5-Level-Paging
unterstützen. Siehe Documentation/arch/x86/x86\_64/5level-paging.rst für weitere Informationen.\\
Sagen Sie N, wenn Sie unsicher sind.

\subsubsection{Enable statistic for Change Page Attribute}
CONFIG\_X86\_CPA\_STATISTICS [=y] \textbf{[Y]}\\
Statistiken über den Mechanismus zum Ändern von Seitenattributen offenlegen, der dabei hilft,
die Wirksamkeit der Erhaltung großer und umfangreicher Seitenzuordnungen zu bestimmen,
wenn Zuordnungsschutzmaßnahmen geändert werden.

\subsubsection{AMD Secure Memory Encryption (SME) support}
CONFIG\_AMD\_MEM\_ENCRYPT [=y] \textbf{[N]}\\
Sagen Sie Ja, um die Unterstützung für die Verschlüsselung des Systemspeichers zu aktivieren.
Dies erfordert einen AMD-Prozessor, der Secure Memory Encryption (SME) unterstützt.

\paragraph{Activate AMD Secure Memory Encryption (SME) by default}$~$\\
CONFIG\_AMD\_MEM\_ENCRYPT\_ACTIVE\_BY\_DEFAULT [=n] \textbf{[N]}\\
Sagen Sie Ja, damit der Systemspeicher standardmäßig verschlüsselt wird, wenn er auf einem
AMD"=Pro\-zes\-sor läuft, der Secure Memory Encryption (SME) unterstützt.
Wenn Sie Y wählen, kann die Verschlüsselung des Systemspeichers mit der Befehlszeilenoption
\texttt{mem\_encrypt=off} deaktiviert werden. Ist der Wert auf N gesetzt, kann die Verschlüsselung
des Systemspeichers mit der Befehlszeilenoption \texttt{mem\_encrypt=on} aktiviert werden.

\subsubsection{NUMA Memory Allocation and Scheduler Support}
CONFIG\_NUMA [=y] \textbf{[Y]}\\
Aktivieren Sie die NUMA-Unterstützung (Non-Uniform Memory Access). Der Kernel wird versuchen, den
von einer CPU verwendeten Speicher dem lokalen Speicher-Controller der CPU zuzuweisen und dem Kernel
mehr Kenntnis über NUMA zu geben.\\
Für 64-Bit wird dies empfohlen, wenn das System Intel Core i7 (oder höher),
AMD Opteron oder EM64T NUMA ist.\\
Für 32-Bit ist dies nur erforderlich, wenn Sie einen 32-Bit-Kernel auf einer 64-Bit-NUMA-Plattform booten.
Andernfalls sollten Sie N angeben.

\paragraph{Old style AMD Opteron NUMA detection}$~$\\
CONFIG\_AMD\_NUMA [=y] \textbf{[N]}\\
Aktivieren Sie die Erkennung der AMD NUMA-Knoten-Topologie. Wenn Sie ein AMD-Multi\-pro\-zes\-sor\-system haben,
sollten Sie hier Y angeben. Dies verwendet eine alte Methode, um die NUMA-Konfiguration direkt von der
eingebauten Northbridge des Opteron zu lesen.\\
Es wird empfohlen, stattdessen
X86\_64\_ACPI\_NUMA zu verwenden,
das auch Priorität hat, wenn beide einkompiliert sind.

\paragraph{ACPI NUMA detection}$~$\\
CONFIG\_X86\_64\_ACOU\_NUMA [=y] \textbf{[Y]}\\
Aktivieren Sie die auf ACPI SRAT basierende Knoten-Topologie-Erkennung.

\paragraph{NUMA emulation}$~$\\
CONFIG\_NUMA\_EMU [=n] \textbf{[N]}\\
Aktivieren Sie die NUMA-Emulation. Eine flache Maschine wird in virtuelle Knoten aufgeteilt, wenn sie mit
\texttt{numa=fake=N} gebootet wird, wobei N die Anzahl der Knoten ist.
Dies ist nur für die Fehlersuche nützlich.

\paragraph{Maximum NUMA Nodes (as a power of 2)}$~$\\
CONFIG\_NODES\_SHIFT [=5]  \textbf{[5]}\\
(Maximale NUMA-Knoten (als eine Potenz von 2))\\
Geben Sie die maximale Anzahl der auf dem Zielsystem verfügbaren NUMA-Knoten an.
Erhöht den reservierten Speicherplatz für verschiedene Tabellen.

\subsubsection{Enable sysfs memory/probe interface}
CONFIG\_ARCH\_MEMORY\_PROBE [=n] \textbf{[N]}\\
Diese Option aktiviert eine sysfs-Speicher/Probe-Schnittstelle für Tests.\\
Siehe Documentation/admin-guide/mm/memory-hotplug.rst für weitere Informationen.
Wenn Sie unsicher sind, wie Sie diese Frage beantworten sollen, antworten Sie mit N.

\subsubsection{Support non-standard NVDIMMs and ADR protected memory}
CONFIG\_X86\_PMEM\_LEGACY [=m] \textbf{[M]}\\
Behandeln Sie Speicher, der mit dem nicht standardmäßigen e820-Typ von 12 markiert ist, wie er vom
Intel Sandy Bridge-EP Referenz-BIOS verwendet wird, als geschützten Speicher.
Der Kernel bietet diese Regionen dem \texttt{pmem}-Treiber an, so dass sie für persistenten Speicher
verwendet werden können.\\
Sagen Sie Y, wenn Sie unsicher sind.

\subsubsection{Check for low memory corruption}
CONFIG\_X86\_CHECK\_BIOS\_CORRUPTION [=y] \textbf{[Y]}\\
Regelmäßige Überprüfung auf Speicherbeschädigung im niedrigen Speicher, die vermutlich durch das BIOS
verursacht wird. Auch wenn dies in der Konfiguration aktiviert ist, zur Laufzeit ist es deaktiviert.
Aktivieren Sie es, indem Sie \texttt{memory\_corruption\_check=1} in der Kernel-Befehlszeile eingeben.
Standardmäßig werden die unteren 64~k des Speichers alle 60 Sekunden überprüft; siehe die Parameter
\texttt{memory\_corruption\_check\_size} und \texttt{memory\_corruption\_check\_period} in
Documentation/admin-guide/kernel-parameters.rst, um dies anzupassen.
Wenn diese Option mit den Standardparametern aktiviert ist, hat sie so gut wie keinen Overhead, da sie
eine relativ kleine Menge an Speicher reserviert und diesen nur selten durchsucht. Sie erkennt Korruption
und verhindert, dass sie das laufende System beeinträchtigt. Sie ist jedoch als Diagnosewerkzeug gedacht;
wenn eine wiederholte BIOS-verursachte Beschädigung stets denselben Speicher betrifft, können Sie
\texttt{memmap=} verwenden, um zu verhindern, dass der Kernel diesen Speicher verwendet.\\[1em]
\noindent\fbox{%
	\parbox{445\unitlength}{Hinweis: Kann ausgeschaltet werden, wenn im \texttt{journalctl} niemals
	\glqq corrupted low memory\grqq{} erscheint.}
}

\paragraph{Set the default setting of memory\_corruption\_check}$~$\\
CONFIG\_X86\_BOOTPARAM\_MEMORY\_CORRUPTION\_CHECK [=y] \textbf{[Y]}\\
Legt fest, ob der Standardstatus von \texttt{memory\_corruption\_check} ein- oder ausgeschaltet ist.

\subsubsection{MTRR (Memory Type Range Register) support}
CONFIG\_MTRR [=y] \textbf{[Y]}\\
Bei Prozessoren der Intel P6-Familie (Pentium Pro, Pentium II und später) können die Memory Type Range Register (MTRRs)
verwendet werden, um den Zugriff des Prozessors auf Speicherbereiche zu steuern. Dies ist besonders nützlich, wenn Sie
eine Videokarte (VGA) an einem PCI- oder AGP-Bus haben. Durch die Aktivierung von Write-Combining können
Bus-Schreibübertragungen zu einer größeren Übertragung kombiniert werden, bevor sie über den PCI/AGP-Bus geleitet
werden. Dies kann die Leistung von Bildschreiboperationen um das 2,5-fache oder mehr erhöhen.
Wenn Sie hier Y angeben, wird eine /proc/mtrr-Datei erstellt, die zur Manipulation der MTRRs Ihres Prozessors verwendet
werden kann. Normalerweise sollte der X-Server dies verwenden.\\
Dieser Code hat eine recht generische Schnittstelle, so dass ähnliche Steuerregister auf anderen Prozessoren ebenfalls
leicht unterstützt werden können:\\
Die Prozessoren Cyrix 6x86, 6x86MX und M II verfügen über Address Range Registers (ARRs), die eine ähnliche
Funktionalität wie MTRRs bieten. In diesen Fällen werden die ARRs zur Emulation der MTRRs verwendet.
Die AMD-Prozessoren K6-2 (Stepping 8 und höher) und K6-3 haben zwei MTRRs. Der Centaur C6 (WinChip) hat 8 MCRs, die
Schreibkombinationen ermöglichen. Alle diese Prozessoren werden von diesem Code unterstützt und es ist sinnvoll, hier
Y anzugeben, wenn Sie einen dieser Prozessoren haben.\\
Die Angabe von Y an dieser Stelle behebt auch ein Problem mit fehlerhaften SMP-BIOSen, die die MTRRs nur für die
Boot-CPU und nicht für die sekundären CPUs setzen. Das kann zu allen möglichen Problemen führen, also ist es gut,
hier Y zu sagen.\\
Sie können sicher Y sagen, auch wenn Ihr Rechner keine MTRRs hat, Sie werden nur etwa 9 KB zu Ihrem Kernel hinzufügen.
Siehe $<$file:Documentation/arch/x86/mtrr.rst$>$ für weitere Informationen.

\paragraph{MTRR cleanup support}$~$\\
CONFIG\_MTRR\_SANITIZER [=y] \textbf{[Y]}\\
Umwandlung des MTRR-Layouts von kontinuierlich in diskret, damit X-Treiber Rückschreibeinträge hinzufügen können.
Kann mit \texttt{disable\_mtrr\_cleanup} in der Kernel-Kommandozeile deaktiviert werden.
Die größte MTRR-Eintragsgröße für einen kontinuierlichen Block kann mit \texttt{mtrr\_chunk\_size} festgelegt werden.\\
Wenn Sie unsicher sind, sagen Sie Y.

\paragraph{MTRR cleanup enable value (0-1)}$~$\\
CONFIG\_MTRR\_SANITIZER [=1] \textbf{[1]}\\
Aktivieren Sie den \glqq mtrr cleanup\grqq{}-Standardwert

\paragraph{MTRR cleanup spare reg num (0-7)}$~$\\
CONFIG\_MTRR\_SANITIZER\_SPARE\_REG\_NR\_DEFAULT [=0] \textbf{[0]}\\
MTRR cleanup spare entries Defaulteintrag, dies kann über
\texttt{mtrr\_spare\_reg\_nr=N} auf der Kernel-Be\-fehls\-zei\-le geändert werden.

\subsubsection{Indirect Branch Tracking}
CONFIG\_X86\_KERNEL\_IBT [=y] \textbf{[Y]}\\
Bauen Sie den Kernel mit Unterstützung für Indirect Branch Tracking auf, eine Hardware-Unterstützung, die die Integrität
des Kontrollflusses an den Rändern schützt. Sie erzwingt, dass alle indirekten Aufrufe auf einer ENDBR-Anweisung landen
müssen, und der Compiler wird den Code mit ihnen instrumentieren, damit dies geschieht.\\
Zusätzlich zur Erstellung des Kernels mit IBT werden alle Funktionen, die keine indirekten Aufrufziele sind, versiegelt,
um zu verhindern, dass sie jemals zu solchen werden.\\
Dies erfordert LTO wie objtool-Läufe und verlangsamt den Bau. Es reduziert jedoch die Anzahl der ENDBR-Anweisungen im
Kernel-Image erheblich.

\subsubsection{Memory Protection Keys}
CONFIG\_X86\_INTEL\_MEMORY\_PROTECTION\_KEYS [=y] \textbf{[Y]}\\
Memory Protection Keys bietet einen Mechanismus zur Erzwingung seitenbasierter Schutzmaßnahmen, ohne dass die
Seitentabellen geändert werden müssen, wenn eine Anwendung ihre Schutzdomänen ändert. Einzelheiten siehe
Documentation/core-api/protection-keys.rst\\
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{TSX enable mode () \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_X86\_INTEL\_MEMORY\_PROTECTION\_KEYS [=y] \textbf{[Y]}\\
Intels TSX-Funktion (Transactional Synchronization Extensions) ermöglicht die Optimierung von Sperrprotokollen durch
Lock Elision, was zu einer spürbaren Leistungssteigerung führen kann.
Andererseits hat sich gezeigt, dass TSX für Seitenkanalangriffe (z.~B. TAA) ausgenutzt werden kann, und es ist
wahrscheinlich, dass in Zukunft weitere Angriffe dieser Art entdeckt werden.
Daher ist TSX standardmäßig nicht aktiviert (aka \texttt{tsx=off}). Ein Administrator kann diese Entscheidung durch den
Befehlszeilenparameter \texttt{tsx=on} außer Kraft setzen.
Auch wenn TSX aktiviert ist, versucht der Kernel, die bestmögliche TAA-Abschwächung zu aktivieren, je nach dem für
den jeweiligen Rechner verfügbaren Mikrocode.
Mit dieser Option kann der Standard-Tsx-Modus zwischen \texttt{tsx=on}, \texttt{=off} und \texttt{=auto}
eingestellt werden. Siehe
Documentation/admin-guide/kernel-parameters.txt für weitere Details.
Sagen Sie off, wenn Sie sich nicht sicher sind, auto, wenn TSX in Gebrauch ist, aber auf sicheren Plattformen
verwendet werden sollte, oder on, wenn TSX in Gebrauch ist und der Sicherheitsaspekt von tsx nicht relevant ist.

\paragraph{off}$~$\\
CONFIG\_X86\_INTEL\_TSX\_MODE\_OFF [=n] \textbf{[N]}\\
TSX ist, wenn möglich, deaktiviert -- entspricht dem Befehlszeilenparameter \texttt{tsx=off}.

\paragraph{on}$~$\\
CONFIG\_X86\_INTEL\_TSX\_MODE\_ON [=n] \textbf{[N]}\\
TSX ist auf TSX-fähiger Hardware immer aktiviert -- gleichbedeutend
mit dem Befehlszeilenparameter \texttt{tsx=on}

\paragraph{auto}$~$\\
CONFIG\_X86\_INTEL\_TSX\_MODE\_AUTO [=y] \textbf{[Y]}\\
TSX wird auf TSX-fähiger Hardware aktiviert, die als sicher gegen Seitenkanalangriffe gilt -- gleichbedeutend
mit dem Befehlszeilenparameter \texttt{tsx=auto}.

\subsubsection{Software Guard eXtensions (SGX)}
CONFIG\_X86\_SGX [=y] \textbf{[Y]}\\
Intel(R) Software Guard eXtensions (SGX) ist eine Reihe von CPU-Befehlen, die von Anwendungen verwendet werden
können, um private Code- und Datenbereiche, die so genannten Enklaven, zu reservieren. Auf den privaten Speicher
einer Enklave kann nur von Code zugegriffen werden, der innerhalb der Enklave läuft. Zugriffe von außerhalb der
Enklave, einschließlich anderer Enklaven, werden von der Hardware nicht zugelassen.\\
Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{X86 userspace shadow stack}
CONFIG\_X86\_USER\_SHADOW\_STACK [=y] \textbf{[Y]}\\
Der Schattenstapelschutz ist eine Hardwarefunktion, die eine Beschädigung der Rücksprungadresse einer Funktion
erkennt. Dies hilft, ROP-Angriffe abzuschwächen. Anwendungen müssen aktiviert sein, um sie zu nutzen, und der
alte Userspace erhält den Schutz nicht "umsonst". CPUs, die Shadow Stacks unterstützen, wurden erstmals im
Jahr~2020 vorgestellt. Weitere Informationen finden Sie unter Documentation/arch/x86/shstk.rst.\\
Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{EFI runtime service support}
CONFIG\_EFI [=y] \textbf{[Y]}\\
Dies ermöglicht es dem Kernel, verfügbare EFI-Laufzeitdienste (wie die EFI-Variablendienste) zu nutzen.\\
Diese Option ist nur auf Systemen mit EFI-Firmware sinnvoll. Außerdem sollten Sie den neuesten ELILO-Lader
verwenden, der unter \url{http://elilo.sourceforge.net} verfügbar ist, um die Vorteile der
EFI-Laufzeitdienste zu nutzen. Aber auch mit dieser Option sollte der resultierende Kernel weiterhin auf
bestehenden Nicht-EFI-Plattformen booten.

\paragraph{EFI stub support}$~$\\
CONFIG\_EFI\_STUB [=y] \textbf{[Y]}\\
Mit dieser Kernel-Funktion kann ein bzImage direkt von der EFI-Firmware geladen werden, ohne dass ein
Bootloader erforderlich ist.\\
Weitere Informationen finden Sie unter Documentation/admin-guide/efi-stub.rst.

\subparagraph{EFI handover protocol (DEPRECATED)}$~$\\
CONFIG\_EFI\_STUB [=y] \textbf{[Y]}\\
(EFI-Übergabeprotokoll (VERALTET))\\
Wählen Sie dies, um Unterstützung für das veraltete EFI-Handover-Protokoll zu erhalten, das alternative
Einstiegspunkte in den EFI-Stub definiert. Dies ist eine Praxis, die keine Grundlage in der UEFI-Spezifikation
hat und ein Vorwissen seitens des Bootloaders über Linux/x86-spezifische Wege der Übergabe der Kommandozeile
und initrd erfordert, und wo im Speicher diese Assets geladen werden können.\\
Im Zweifelsfall sagen Sie Y. Auch wenn die entsprechende Unterstützung im Upstream-GRUB oder anderen
Bootloadern nicht vorhanden ist, bauen die meisten Distros GRUB mit zahlreichen Downstream-Patches und können
sich daher auf das Handover-Protokoll verlassen.

\subparagraph{EFI mixed-mode support}$~$\\
CONFIG\_EFI\_MIXED [=y] \textbf{[Y]}\\
Wenn Sie diese Funktion aktivieren, kann ein 64-Bit-Kernel auf einer 32-Bit-Firmware gebootet werden,
vorausgesetzt, Ihre CPU unterstützt den 64-Bit-Modus.\\
Beachten Sie, dass es nicht möglich ist, einen Mixed-Mode-fähigen Kernel über den EFI-Boot-Stub zu
booten -- es muss ein Bootloader verwendet werden, der das EFI-Handover-Protokoll unterstützt.\\
Wenn Sie unsicher sind, sagen Sie N.

\paragraph{Enable EFI fake memory map}$~$\\
CONFIG\_EFI\_FAKE\_MEMMAP [=n] \textbf{[N]}\\
Wenn Sie hier Y angeben, wird die Boot-Option \texttt{efi\_fake\_mem} aktiviert.
Durch Angabe dieses Parameters können Sie einem bestimmten Speicherbereich beliebige Attribute hinzufügen,
indem Sie die ursprüngliche (von der Firmware bereitgestellte) EFI-Memmap aktualisieren.
Dies ist nützlich für das Debugging von EFI-Memmap-bezogenen Funktionen, z.~B. Address Range Mirroring.

\subsubsection{Timer frequency () \texorpdfstring{$\rightarrow$}{->}}
Ermöglicht die Konfiguration der Timer-Frequenz. Es ist üblich, den Timer-Interrupt mit 1000 Hz laufen
zu lassen, aber 100 Hz kann für Server und NUMA-Systeme vorteilhafter sein, die keine schnelle Reaktion
für die Benutzerinteraktion benötigen und bei denen es zu Buskonflikten und Cacheline-Bounches als Folge
von Timer-Interrupts kommen kann. Beachten Sie, dass der Timer-Interrupt in einer SMP-Umgebung auf jedem
Prozessor auftritt, was zu NR\_CPUS * HZ Anzahl der Timer-Interrupts pro Sekunde führt.

\paragraph{100~Hz}$~$\\
CONFIG\_HZ\_100 [=n] \textbf{[N]}\\
100~Hz ist eine typische Wahl für Server, SMP- und NUMA-Systeme mit vielen Prozessoren, die eine
geringere Leistung aufweisen können, wenn zu viele Timer-Interrupts auftreten.
\paragraph{250~Hz}$~$\\
CONFIG\_HZ\_250 [=n] \textbf{[N]}\\
250~Hz ist ein guter Kompromiss, der eine gute Serverleistung ermöglicht und auch auf SMP- und
NUMA-Systemen eine gute interaktive Reaktionsfähigkeit zeigt. Wenn Sie NTSC-Video oder Multimedia
verwenden, wählen Sie stattdessen 300~Hz.
\paragraph{300~Hz}$~$\\
CONFIG\_HZ\_300 [=y] \textbf{[Y]}\\
300~Hz ist ein guter Kompromiss, der eine gute Serverleistung und gleichzeitig eine gute interaktive
Reaktionsfähigkeit selbst auf SMP- und NUMA-Systemen ermöglicht und sowohl bei PAL- als auch bei
NTSC-Bildraten für Video- und Multimedia-Arbeiten genau eingehalten wird.
\paragraph{1000~Hz}$~$\\
CONFIG\_HZ\_1000 [=n] \textbf{[N]}\\
1000~Hz ist die bevorzugte Wahl für Desktop-Systeme und andere Systeme, die schnelle interaktive
Reaktionen auf Ereignisse erfordern.

\subsubsection{Physical address where the kernel is loaded}
CONFIG\_PHYSICAL\_START [=0x1000000] \textbf{[0x1000000]}\\
Dies gibt die physikalische Adresse an, unter der der Kernel geladen wird. Wenn der Kernel nicht verschiebbar ist
(CONFIG\_RELOCATABLE=n), dekomprimiert sich bzImage an die oben genannte physikalische Adresse und wird von dort
aus gestartet. Andernfalls wird bzImage von der Adresse aus gestartet, an der es vom Bootloader geladen wurde,
und ignoriert die obige physikalische Adresse. In normalen kdump-Fällen muss diese Option nicht gesetzt/geändert
werden, da bzImage nun als vollständig relozierbares Image (CONFIG\_RELOCATABLE=y) kompiliert und zum Laden und
Ausführen von einer anderen Adresse verwendet werden kann. Diese Option ist vor allem für die Leute nützlich,
die kein bzImage für die Erfassung des Crash-Dumps verwenden wollen und stattdessen vmlinux einsetzen wollen.
vmlinux ist nicht relocatable, daher muss ein Kernel speziell kompiliert werden, um von einem bestimmten
Speicherbereich (normalerweise ein reservierter Bereich) zu laufen, und diese Option ist sehr nützlich.
Wenn Sie also bzImage zum Erfassen des Crash-Dumps verwenden, lassen Sie den Wert hier unverändert auf
0x1000000 und setzen Sie CONFIG\_RELOCATABLE=y.\\
Andernfalls, wenn Sie vmlinux für die Aufzeichnung des Crash-Dumps verwenden wollen, ändern Sie diesen Wert
auf den Beginn des reservierten Bereichs. Mit anderen Worten, er kann auf der Grundlage des "X"-Wertes gesetzt
werden, wie er im "crashkernel=YM@XM"-Befehlszeilen-Boot-Parameter angegeben ist, der an den panic-ed-Kernel
übergeben wird. Weitere Details zu Crash Dumps finden Sie in Documentation/admin-guide/kdump/kdump.rst.
Die Verwendung von bzImage für die Aufzeichnung des Crash-Dumps wird empfohlen, da man nicht zwei Kernel
erstellen muss. Derselbe Kernel kann als Produktionskernel und als Erfassungskernel verwendet werden. Die obige
Option sollte verschwinden, nachdem die Unterstützung von relocatable bzImage eingeführt wurde. Sie ist aber noch
vorhanden, weil es Benutzer gibt, die weiterhin vmlinux für die Dump-Erfassung verwenden. Diese Option sollte im
Laufe der Zeit verschwinden. Ändern Sie diese Option nicht, wenn Sie nicht wissen, was Sie tun.

\subsubsection{Build a relocatable kernel}
CONFIG\_RELOCATABLE [=y] \textbf{[Y]}\\
Dadurch wird ein Kernel-Image erstellt, das die Informationen über den Standortwechsel beibehält, so dass es an
einem anderen Ort als den standardmäßigen 1~MB geladen werden kann.
Die Verschiebungen machen das Kernel-Binary etwa 10~\% größer, werden aber zur Laufzeit verworfen.
Eine Anwendung ist der kexec on panic-Fall, bei dem der Wiederherstellungs-Kernel an einer anderen
physikalischen Adresse liegen muss als der primäre Kernel.
Anmerkung: Wenn CONFIG\_RELOCATABLE=y ist, dann läuft der Kernel von der Adresse aus, an der er geladen wurde,
und von der zur Kompilierzeit physische Adresse (CONFIG\_PHYSICAL\_START) als Mindeststandort verwendet.

\paragraph{Randomize the address of the kernel image (KASLR)}$~$\\
CONFIG\_RANDOMIZE\_BASE [=y] \textbf{[Y]}\\
Zur Unterstützung der Kernel Address Space Layout Randomization (KASLR) werden
die physische Adresse, an der das Kernel-Image dekomprimiert wird, und
die virtuelle Adresse, auf die das Kernel-Image abgebildet wird,
randomisiert. Dies ist ein Sicherheitsmerkmal, das Exploit-Versuche verhindert,
die auf der Kenntnis des Speicherorts von Kernel-Code-Interna beruhen.
Bei 64-Bit werden die physische und die virtuelle Adresse des Kernels getrennt randomisiert.
Die physische Adresse liegt irgendwo zwischen 16~MB und dem Anfang des physischen Speichers
(bis zu 64~TB). Die virtuelle Adresse wird von 16~MB bis zu 1~GB randomisiert
(9 Bits Entropie).
Beachten Sie, dass dadurch auch der für Kernel-Module verfügbare Speicherplatz
von 1,5~GB auf 1~GB reduziert wird.
Bei 32-Bit werden die physischen und virtuellen Adressen des Kernels zusammen
randomisiert. Sie werden von 16~MB bis zu 512~MB randomisiert (8 Bits Entropie).\\
Die Entropie wird mit dem RDRAND-Befehl erzeugt, sofern er unterstützt wird.
Wenn RDTSC unterstützt wird, wird sein Wert ebenfalls in den Entropie-Pool
gemischt. Wenn weder RDRAND noch RDTSC unterstützt werden, wird die Entropie aus
dem i8254-Zeitgeber gelesen. Die nutzbare Entropie ist dadurch begrenzt, dass der
Kernel mit 2~GB-Adressierung aufgebaut ist und dass PHYSICAL\_ALIGN mindestens
2~MB betragen muss.
Infolgedessen sind theoretisch nur 10 Bits Entropie möglich, aber die
Implementierungen sind aufgrund des Speicherlayouts noch weiter eingeschränkt.\\
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{Alignment value to which kernel should be aligned}
CONFIG\_PHYSICAL\_ALIGN [=0x200000] \textbf{[0x200000]}\\
Dieser Wert legt die Ausrichtungsbeschränkungen für die physikalische Adresse fest, von der der Kernel geladen und
ausgeführt wird. Der Kernel wird für eine Adresse kompiliert, die den obigen Ausrichtungsbeschränkungen entspricht.
Wenn der Bootloader den Kernel an einer nicht ausgerichteten Adresse lädt und CONFIG\_RELOCATABLE gesetzt ist,
verschiebt sich der Kernel an die nächstgelegene Adresse, die auf den obigen Wert ausgerichtet ist, und wird von
dort aus gestartet.
Wenn der Bootloader den Kernel an einer nicht ausgerichteten Adresse lädt und CONFIG\_RELOCATABLE nicht gesetzt ist,
ignoriert der Kernel die Ladeadresse zur Laufzeit und dekomprimiert sich an die Adresse, für die er kompiliert wurde,
und läuft von dort aus. Die Adresse, für die der Kernel kompiliert wurde, erfüllt bereits die oben genannten
Ausrichtungsbeschränkungen. Das Endergebnis ist also, dass der Kernel von einer physikalischen Adresse aus läuft,
die die oben genannten Ausrichtungsbeschränkungen erfüllt.
Bei 32-Bit muss dieser Wert ein Vielfaches von 0x2000 sein. Bei 64-Bit muss dieser Wert ein Vielfaches von 0x200000 sein.\\
Ändern Sie dies nicht, wenn Sie nicht wissen, was Sie tun.

\subsubsection{Randomize the kernel memory sections}
CONFIG\_RANDOMIZE\_MEMORY [=y] \textbf{[Y]}\\
Randomisiert die virtuelle Basisadresse von Kernel-Speicherabschnitten (physische Speicherzuordnung, vmalloc \& vmemmap).
Dieses Sicherheitsmerkmal macht Exploits, die sich auf vorhersehbare Speicherplätze verlassen, weniger zuverlässig. Die Reihenfolge der
Zuweisungen bleibt unverändert. Entropie wird auf die gleiche Weise wie bei RANDOMIZE\_BASE erzeugt. Aktuelle Implementierung
in der optimalen Konfiguration haben im Durchschnitt 30.000 verschiedene mögliche virtuelle Adressen für jeden Speicherabschnitt.\\
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{Linear Address Masking support}
CONFIG\_ADDRESS\_MASKING [=y] \textbf{[Y]}\\
Linear Address Masking (LAM) ändert die Prüfung, die auf lineare 64-Bit-Adressen angewandt wird, und ermöglicht der Software
die nicht übersetzten Adressbits für Metadaten zu verwenden.\\
Diese Fähigkeit kann für die effiziente Implementierung von Adress-Sanitizern (ASAN) und für Optimierungen in JITs genutzt werden.

\subsubsection{Disable the 32-bit vDSO (needed for glibc 2.3.3)}
CONFIG\_COMPAT\_VDSO [=n] \textbf{[N]}\\
Bestimmte fehlerhafte Versionen der glibc stürzen ab, wenn sie mit einem 32-Bit vDSO konfrontiert werden, das nicht auf die in
der Segmenttabelle angegebene Adresse abgebildet ist.
Adresse zugeordnet ist, die in der Segmenttabelle angegeben ist.\\
Der Fehler wurde eingeführt durch f866314b89d56845f55e6f365e18b31ec978ec3a und behoben durch\\
3b3ddb4f7db98ec9e912ccdf54d35df4aa30e04a und 49ad572a70b8aeb91e57483a11dd1b77e31c4468.\\
Glibc~2.3.3 ist die einzige veröffentlichte Version mit dem Fehler, aber OpenSUSE 9 enthält eine fehlerhafte
\glqq glibc 2.3.2\grqq{}.
Das Symptom des Fehlers ist, dass alles beim Start abstürzt und sagt:\\
\texttt{dl\_main: Assertion \`~(void \*) ph-$>$p\_vaddr == \_rtld\_local.\_dl\_sysinfo\_dso}\\
Wenn Sie hier Y sagen, wird der Standardwert der Bootoption vdso32 von 1 auf 0 geändert, wodurch die
32-Bit vDSO vollständig deaktiviert wird. Dies umgeht zwar den Glibc-Bug, beeinträchtigt aber die Leistung.\\
Wenn Sie unsicher sind, sagen Sie N: Wenn Sie Ihren eigenen Kernel kompilieren, ist es unwahrscheinlich,
dass Sie eine fehlerhafte Version der glibc verwenden.

\subsubsection{vsyscall table for legacy applications () \texorpdfstring{$\rightarrow$}{->}}
Legacy-Benutzercode, der nicht weiß, wie er den vDSO finden kann, erwartet, dass er drei Syscalls ausgeben kann,
indem er feste Adressen im Kernel-Bereich aufruft.
Da dieser Ort nicht mit ASLR randomisiert wird, kann er dazu verwendet werden, die Ausnutzung von Sicherheitslücken
zu unterstützen.
Diese Einstellung kann zur Boot-Zeit über den Kernel-Befehlszeilenparameter
\texttt{vsyscall=[emulate|xonly|none]} geändert werden.\\
Der Emulationsmodus ist veraltet und kann nur noch über die Kernel-Befehlszeile aktiviert werden.
Auf einem System mit ausreichend aktueller glibc (2.14 oder neuer) und ohne statische Binärdateien können Sie
\glqq None\grqq{} ohne Leistungseinbußen verwenden um die Sicherheit zu verbessern.\\
Wenn Sie unsicher sind, wählen Sie \glqq Nur Ausführung emulieren\glqq{}.

\paragraph{Emulate execution only}$~$\\
CONFIG\_LEGACY\_VSYSCALL\_XONLY [=y] \textbf{[Y]}\\
Der Kernel fängt und emuliert Aufrufe in die feste vsyscall-Adresszuordnung und lässt keine Lesezugriffe zu.
Diese Konfiguration wird empfohlen, wenn der Userspace den Legacy-Vsyscall-Bereich verwenden könnte, aber keine
Unterstützung für die binäre Instrumentierung von Legacy-Code benötigt wird. Sie entschärft bestimmte Verwendungen
des vsyscall-Bereichs als Puffer zur Umgehung von ASLR.

\paragraph{None}$~$\\
CONFIG\_LEGACY\_VSYSCALL\_NONE [=n] \textbf{[N]}\\
Es wird überhaupt keine vsyscall-Zu\-ordnung geben. Dies eliminiert jegliches Risiko einer ASLR-Um\-ge\-hung
aufgrund der festen vsyscall-Adressen-Zuordnung. Versuche, die vsyscalls zu verwenden, werden an dmesg gemeldet,
so dass entweder alte oder bösartige Userspace-Programme identifiziert werden können.

\subsubsection{Built-in kernel command line}
CONFIG\_CMDLINE\_BOOL [=n] \textbf{[N]}\\
Ermöglicht die Angabe von Boot-Argumenten für den Kernel zur Erstellungszeit. Auf einigen Systemen
(z.~B. eingebetteten [embedded]) ist es notwendig oder praktisch, einige oder alle Kernel-Boot-Argumente mit
dem Kernel selbst bereitzustellen (d.h. sich nicht darauf zu verlassen, dass der Bootloader sie bereitstellt).
Um Kommandozeilenargumente in den Kernel zu kompilieren, setzen Sie diese Option auf Y und geben Sie dann
die Boot-Argumente in CONFIG\_CMDLINE ein. Bei Systemen mit voll funktionsfähigen Bootloadern
(d.h. nicht eingebetteten) sollte diese Option auf N gesetzt bleiben.

\subsubsection{Enforce strict size checking for sigaltstack}
CONFIG\_STRICT\_SIGALTSTACK\_SIZE [=n] \textbf{[N]}\\
Aus historischen Gründen ist MINSIGSTKSZ eine Konstante, die mit der AVX512-Unterstützung bereits zu klein wurde.
Fügen Sie einen Mechanismus hinzu, um die strenge Überprüfung der Sigaltstack-Größe gegen die tatsächliche Größe
des FPU-Rahmens zu erzwingen. Diese Option aktiviert die Überprüfung standardmäßig. Sie kann auch über die
Kernel-Kommandozeilenoption \texttt{strict\_sas\_size} unabhängig von diesem Konfigurationsschalter gesteuert werden.
Das Aktivieren dieser Option könnte bestehende Anwendungen zerstören, die einen zu kleinen Sigaltstack zuweisen,
aber \glq funktionieren\grq{}, weil sie nie ein Signal geliefert bekommen.\\
Sagen Sie N, wenn Sie diese Prüfung nicht wirklich erzwingen wollen.

\subsubsection{Kernel Live Patching}
CONFIG\_LIVEPATCH [=n] \textbf{[N]}\\
Geben Sie hier Y an, wenn Sie Kernel-Live-Patching unterstützen wollen. Diese Option hat keine Auswirkungen auf die
Laufzeit, bis ein Kernel-\glqq Patch\grqq{}-Modul die von dieser Option bereitgestellte Schnittstelle verwendet,
um einen Patch zu registrieren, was dazu führt, dass Aufrufe der gepatchten Funktionen auf den neuen Funktionscode
im Patch-Modul umgeleitet werden.

\section{Mitigations for speculative execution vulnerabilities \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_SPECULATION\_MITIGATIONS [=y] \textbf{[Y]}\\
Sagen Sie hier Y, um Optionen zu aktivieren, die Abhilfemaßnahmen für Hardware-Schwachstellen durch spekulative
Ausführung ermöglichen. Wenn Sie N sagen, werden alle Abhilfemaßnahmen deaktiviert. Sie sollten wirklich wissen,
was Sie tun, um dies anzugeben.

\subsection{Remove the kernel mapping in user mode}
CONFIG\_PAGE\_TABLE\_ISOLATION [=y] \textbf{[Y]}\\
Diese Funktion reduziert die Anzahl der Hardware-Seitenkanäle, indem sie sicherstellt, dass die meisten
Kernel-Adressen nicht in den Benutzerraum abgebildet werden. Siehe Documentation/arch/x86/pti.rst für
weitere Details.

\subsection{Avoid speculative indirect branches in kernel}
CONFIG\_RETPOLINE [=y] \textbf{[Y]}\\
Kompilieren Sie den Kernel mit den retpoline Compiler-Optionen, um Datenlecks zwischen Kernel und Benutzer
zu verhindern, indem spekulative indirekte Verzweigungen vermieden werden. Erfordert einen Compiler mit
\texttt{-mindirect-branch=thunk-extern} Unterstützung für vollen Schutz. Der Kernel kann langsamer laufen.

\subsubsection{Enable return-thunks}
CONFIG\_RETHUNK [=y] \textbf{[Y]}\\
Kompiliere den Kernel mit der Compileroption return-thunks, um Datenlecks zwischen Kernel und Benutzer zu
verhindern, indem Rückgabespekulationen vermieden werden. Erfordert einen Compiler mit
\texttt{-mfunction-return=thunk-extern} Unterstützung für vollen Schutz. Der Kernel kann langsamer laufen.

\paragraph{Enable UNRET on kernel entry}$~$\\
CONFIG\_CPU\_UNRET\_ENTRY [=y] \textbf{[Y]}\\
Kompiliere den Kernel mit Unterstützung für die \texttt{retbleed=unret}-Abschwächung.

\subsection{Mitigate RSB underflow with call depth tracking}
CONFIG\_CALL\_DEPTH\_TRACKING [=y] \textbf{[Y]}\\
Kompiliere den Kernel mit Call-Depth-Tracking, um das Intel SKL Return-Speculation-Buffer (RSB) Underflow-Problem
zu entschärfen. Die Entschärfung ist standardmäßig ausgeschaltet und muss in der Kernel-Befehlszeile über die
Option \texttt{retbleed=stuff} aktiviert werden. Für nicht betroffene Systeme ist der Overhead dieser Option
marginal, da die Verfolgung der Aufruftiefe zur Laufzeit generierte Call Thunks in einem vom Compiler generierten
Padding-Bereich und Call Patching verwendet. Dies erhöht die Textgröße um $\sim 5$\%. Bei nicht betroffenen Systemen
ist dieser Platz ungenutzt. Auf betroffenen SKL-Systemen führt dies zu einem erheblichen Leistungsgewinn gegenüber
der IBRS-Abschwächung.

\subsubsection{Enable call thunks and call depth tracking debugging}
CONFIG\_CALL\_THUNKS\_DEBUG [=n] \textbf{[N]}\\
Aktiviere Call/Ret-Zähler zur Erkennung von Ungleichgewichten und baue ein lautes dmesg über die Erzeugung von
Callthunks und Call-Patching zur Fehlersuche ein. Die Debug-Ausdrucke müssen in der Kernel-Befehlszeile mit
\texttt{debug-callthunks} aktiviert werden. Aktivieren Sie dies nur, wenn Sie Call Thunks debuggen wollen,
da dies einen spürbaren Laufzeit-Overhead erzeugt. Wenn Sie unsicher sind, sagen Sie N.

\subsection{Enable IBPB on kernel entry}
CONFIG\_CPU\_IBPB\_ENTRY [=y] \textbf{[Y]}\\
Kompiliere den Kernel mit Unterstützung für die \texttt{retbleed=ibpb}-Abschwächung.

\subsection{Enable IBRS on kernel entry}
CONFIG\_CPU\_IBRS\_ENTRY [=y] \textbf{[Y]}\\
Kompiliere den Kernel mit Unterstützung für die \texttt{spectre\_v2=ibrs}-Abschwächung.
Dadurch werden sowohl spectre\_v2 als auch retbleed auf Kosten der Leistung abgeschwächt.

\subsection{Mitigate speculative RAS overflow on AMD}
CONFIG\_CPU\_SRSO [=y] \textbf{[N]}\\
Aktiviert die SRSO-Abschwächung, die auf AMD Zen1-4-Maschinen benötigt wird.

\subsection{Mitigate Straight-Line-Speculation}
CONFIG\_SLS [=y] \textbf{[Y]}\\
Kompiliere den Kernel mit Straight-Line-Speculation-Optionen, um ihn vor Straight-Line-Speculation zu
schützen. Das Kernel-Image könnte etwas größer sein.

\subsection{Force GDS Mitigation}
CONFIG\_GDS\_FORCE\_MITIGATION [=n] \textbf{[N]}\\
Gather Data Sampling (GDS) ist eine Hardware-Schwachstelle, die unberechtigten spekulativen Zugriff auf
Daten ermöglicht, die zuvor in Vektorregistern gespeichert wurden. Diese Option ist gleichbedeutend mit
der Einstellung \texttt{gather\_data\_sampling=force} in der Befehlszeile. Die Mikrocode-Abschwächung
wird verwendet, falls vorhanden, andernfalls wird AVX als Abschwächung deaktiviert. Auf betroffenen
Systemen, denen der Microcode fehlt, wird jeder Userspace-Code, der AVX bedingungslos verwendet, bei
gesetzter Option abbrechen. Das Setzen dieser Option auf Systemen, die nicht für GDS anfällig sind, hat
keine Auswirkungen.\\
Im Zweifelsfall sagen Sie N.

\section{Power management and ACPI options \texorpdfstring{$\rightarrow$}{->}}
Energieverwaltung und ACPI-Optionen

\subsection{Suspend to RAM and standby}
CONFIG\_SUSPEND [=y] \textbf{[Y]}\\
Ermöglicht dem System, in Ruhezustände einzutreten, in denen der Hauptspeicher mit Strom versorgt wird und
somit sein Inhalt erhalten bleibt, wie z.~B. der Suspend-to-RAM-Zustand (z.~B. der ACPI S3-Zustand).

\subsection{Hibernation (aka `suspend to disk')}
CONFIG\_HIBERNATION [=y] \textbf{[Y]}\\
Aktiviert die Funktion \glqq Suspend to Disk\grqq{} (STD),
die in den Benutzeroberflächen gewöhnlich als \glqq Ruhezustand\grqq{}
bezeichnet wird. STD setzt das System an einen Haltepunkt und schaltet es aus; beim Neustart wird dieser Haltepunkt
wiederhergestellt. Sie können Ihren Rechner mit \texttt{echo disk > /sys/power/state} in den Ruhezustand versetzen,
nachdem Sie \texttt{resume=/dev/swappartition} in der Kernel-Befehlszeile in der Konfigurationsdatei Ihres Bootloaders
angegeben haben. Alternativ können Sie auch die zusätzlichen Userland-Tools verwenden, die unter
\url{http://suspend.sf.net} verfügbar sind. Im Prinzip sind weder ACPI noch APM erforderlich, obwohl beispielsweise
ACPI für die letzten Schritte verwendet wird, wenn es verfügbar ist. Einer der Gründe für die Verwendung von
Software-Suspend ist, dass die Firmware-Hooks für Suspend-Zustände wie Suspend-to-RAM (STR) oft nicht sehr gut mit
Linux funktionieren. Es wird ein Abbild erstellt, das in der aktiven Auslagerungsdatei gespeichert wird.
Beim nächsten Start übergeben Sie dem Kernel das Argument \texttt{resume=/dev/swappartition}, damit er das gespeicherte
Abbild erkennt, den Speicherstatus daraus wiederherstellt und wie zuvor weiterarbeitet.
Wenn Sie nicht wollen, dass der vorherige Zustand wiederhergestellt wird, verwenden Sie das Kernel-Befehlszeilenargument
\texttt{noresume}. Beachten Sie jedoch, dass fsck auf Ihren Dateisystemen ausgeführt wird und Sie mkswap auf der
Swap-Partition ausführen müssen, die für den Suspend verwendet wird. In begrenztem Umfang funktioniert es auch mit
Swap-Dateien (für Details siehe $<$file:Documentation/power/swsusp-and-swap-files.rst$>$).
Sie können jetzt booten, ohne den Vorgang fortzusetzen, und ihn später fortsetzen, aber in der Zwischenzeit können Sie
die Swap-Partition(en)/Datei(en), die am Suspendieren beteiligt waren, nicht verwenden. In diesem Fall dürfen Sie auch
nicht die Dateisysteme verwenden, die vor dem Suspendieren gemountet waren. Insbesondere dürfen Sie keine
journalisierten Dateisysteme mounten, die vor dem Suspending gemountet wurden, da diese sonst auf unschöne Weise
beschädigt werden. Weitere Informationen finden Sie in $<$file:Documentation/power/swsusp.rst$>$.

\subsubsection{Userspace snapshot device}
CONFIG\_HIBERNATION\_SNAPSHOT\_DEV [=y] \textbf{[Y]}\\
Gerät, das von den uswsusp-Werkzeugen verwendet wird. Sagen Sie N, wenn kein Snapshotting aus dem Userspace benötigt
wird, dies reduziert auch die Angriffsfläche des Kernels. Im Zweifelsfall sagen Sie Y.

\subsubsection{Default resume partition}
CONFIG\_PM\_STD\_PARTITION [=] \textbf{[~]}\\
Die Standard-Wiederaufnahmepartition ist die Partition, auf der die Suspend-to-Disk-Implementierung nach einem
Suspend-Disk-Image suchen wird. Die hier angegebene Partition wird für fast jeden Benutzer anders sein. Es sollte eine
gültige Swap-Partition sein (zumindest im Moment), die vor dem Suspendieren eingeschaltet wird. Die angegebene
Partition kann durch die Angabe von:\\
\texttt{resume=/dev/<anderes Gerät>}\\
überschrieben werden, wodurch die Partition für die Wiederaufnahme auf das angegebene Gerät gesetzt wird.
Beachten Sie, dass es derzeit keine Möglichkeit gibt, das Gerät anzugeben, auf dem das suspendierte Image
gespeichert werden soll. Es wird einfach das erste verfügbare Swap-Gerät ausgewählt.

\subsection{Opportunistic sleep}
CONFIG\_PM\_AUTOSLEEP [=n] \textbf{[N]}\\
Ermöglicht es dem Kernel, automatisch einen Systemübergang in einen globalen Ruhezustand auszulösen, wenn es keine aktiven Weckquellen gibt.

\subsection{Userspace opportunistic sleep}
CONFIG\_PM\_USERSPACE\_AUTOSLEEP [=n] \textbf{[N]}\\
Benachrichtigt den Kernel über eine aggressive Benutzerraum-Energieverwaltungspolitik für den automatischen Schlaf. Diese Option
ändert das Verhalten verschiedener schlafempfindlicher Codes, um mit häufigen, vom Benutzer initiierten Übergängen in einen
globalen Schlafzustand umzugehen. Wenn Sie hier Y sagen, werden Codepfade deaktiviert, die die meisten Benutzer wirklich aktiviert
lassen sollten. Aktivieren Sie dies nur, wenn es sehr häufig vorkommt, dass man für sehr kurze Zeiträume ($<= 2$~Sekunden) schläft/wach
ist. Nur Plattformen, wie z.~B. Android, die opportunistischen Ruhezustand von einem Userspace-Energieverwaltungsdienst implementieren,
sollten diese Option aktivieren, nicht aber andere Maschinen. Daher sollten Sie hier N sagen, es sei denn, Sie sind sich sehr sicher,
dass Sie dies wollen. Die Option hat andernfalls schlechte, unerwünschte Auswirkungen und sollte nicht nur zum Spaß aktiviert werden.

\subsection{User space wakeup sources interface}
CONFIG\_PM\_WAKELOCKS [=n] \textbf{[N]}\\
Ermöglicht es dem Benutzer, Wakeup-Quellobjekte mit Hilfe einer sysfs-basierten Schnittstelle zu erstellen, zu aktivieren und zu deaktivieren.

\subsection{Device power management core functionality}
CONFIG\_PM\_WAKELOCKS [=y] \textbf{[Y]}\\
Aktivierung von Funktionen, die es ermöglichen, E/A-Geräte in einen energiesparenden (stromsparenden) Zustand zu versetzen, z.~B. nach einer
bestimmten Zeit der Inaktivität (autosuspended), und sie als Reaktion auf ein von der Hardware erzeugtes Wake-up-Ereignis oder eine Anforderung
des Treibers aufzuwecken. Damit diese Funktion funktioniert, ist in der Regel eine Hardwareunterstützung erforderlich, und die Bustreiber der
Busse, an denen die Geräte angeschlossen sind, sind für die tatsächliche Handhabung von Suspendierungsanforderungen und Weckereignissen zuständig.

\subsubsection{Power Management Debug Support}
CONFIG\_PM\_DEBUG [=y] \textbf{[Y]}\\
Diese Option aktiviert verschiedene Debugging-Funktionen im Power-Management-Code. Dies ist hilfreich bei der Fehlersuche und der Meldung
von PM-Fehlern, wie z.~B. der Suspend-Unterstützung.

\paragraph{Extra PM attributes in sysfs for low-level debugging/testing}$~$\\
CONFIG\_PM\_ADVANCED\_DEBUG [=n] \textbf{[N]}\\
Hinzufügen zusätzlicher sysfs-Attribute, die den Zugriff auf einige Power-Management-Felder von Ge\-rä\-te\-ob\-jek\-ten aus dem Userspace ermöglichen.
Wenn Sie kein Kernel-Entwickler sind, der am Debuggen/Testen von Power Management interessiert ist, sagen Sie N für nein.

\paragraph{Test suspend/resume and wakealarm during bootup}$~$\\
CONFIG\_PM\_TEST\_SUSPEND [=n] \textbf{[N]}\\
Mit dieser Option können Sie Ihren Rechner während des Bootvorgangs in den Ruhezustand versetzen und ihn einige Sekunden später mit einem
RTC-Weckalarm aufwecken. Aktivieren Sie dies mit einem Kernelparameter wie \texttt{test\_suspend=mem}. Wahrscheinlich sollten Sie
den RTC-Treiber Ihres Systems statisch einbinden, um sicherzustellen, dass er verfügbar ist, wenn dieser Test läuft.

\subsection{Suspend/resume event tracing}
CONFIG\_PM\_TRACE\_RTC [=y] \textbf{[Y]}\\
Dies ermöglicht es, den letzten PM-Ereignispunkt in der RTC über Neustarts hinweg zu speichern, so dass Sie einen Rechner, der während des
Suspendierens (oder häufiger während des Wiederaufnehmens) einfach hängen bleibt, debuggen können. Um diese Debugging-Funktion zu nutzen,
sollten Sie versuchen, den Rechner in den Suspend-Modus zu versetzen, ihn neu zu starten und dann Folgendes auszuführen\\[.5em]
\texttt{dmesg -s 1000000 | grep 'hash matches'}\\[.5em]
ACHTUNG: Diese Option führt dazu, dass die Echtzeituhr Ihres Rechners nach einem Neustart auf eine ungültige Zeit gesetzt wird.

\subsection{Enable workqueue power-efficient mode by default}
CONFIG\_WQ\_POWER\_EFFICIENT\_DEFAULT [=y] \textbf{[Y]}\\
Pro-CPU-Workqueues werden im Allgemeinen bevorzugt, da sie dank der Cache-Lokalität eine bessere Leistung aufweisen; leider neigen
Pro-CPU-Workqueues dazu, mehr Strom zu verbrauchen als ungebundene Workqueues. Durch die Aktivierung des Kernelparameters
\texttt{workqueue.power\_efficient} werden die Pro-CPU-Workqueues, die nachweislich erheblich zum Stromverbrauch beitragen,
ungebunden, was zu einem messbar geringeren Stromverbrauch auf Kosten eines geringen Leistungsoverheads führt. Diese Konfigurationsoption
legt fest, ob \texttt{workqueue.power\_efficient} standardmäßig aktiviert ist.\\
Im Zweifelsfall sagen Sie N.

\subsection{Energy Model for devices with DVFS (CPUs, GPUs, etc)}
CONFIG\_ENERGY\_MODEL [=y] \textbf{[Y]}\\
Mehrere Teilsysteme (z.~B. das thermische System und/oder der Aufgabenplaner) können Informationen über den Energieverbrauch von Geräten
nutzen, um intelligentere Entscheidungen zu treffen. Diese Konfigurationsoption aktiviert den Rahmen, von dem aus die Subsysteme auf die
Energiemodelle zugreifen können. Die genaue Verwendung des Energiemodells ist subsystemabhängig.\\
Im Zweifelsfall sagen Sie N.

\subsection{ACPI (Advanced Configuration and Power Interface) Support \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_ACPI [=y] \textbf{[Y]}\\
Die Unterstützung von ACPI (Advanced Configuration and Power Interface) für Linux erfordert eine ACPI-kompatible Plattform (Hardware/Firmware)
und setzt das Vorhandensein von OS-directed configuration and power management (OSPM) Software voraus. Mit dieser Option wird Ihr Kernel um
etwa 70K erweitert. Linux ACPI bietet einen robusten funktionalen Ersatz für mehrere ältere Konfigurations- und Energieverwaltungsschnittstellen,
einschließlich der Plug-and-Play-BIOS-Spezifikation (PnP BIOS), der MultiProzessor-Spezifikation (MPS) und der Advanced Power Management (APM)-Spezifikation.
Wenn sowohl ACPI- als auch APM-Unterstützung konfiguriert sind, wird ACPI verwendet.
Die Linux-Unterstützung für ACPI basiert auf der ACPI Component Architecture (ACPI CA) der Intel Corporation. Weitere Informationen über die ACPI~CA
finden Sie unter: \url{https://acpica.org/} ACPI ist eine offene Industriespezifikation, die ursprünglich von Hewlett-Packard, Intel, Microsoft,
Phoenix und Toshiba mitentwickelt wurde. Derzeit wird sie von der ACPI Specification Working Group (ASWG) im Rahmen des UEFI-Forums entwickelt,
und jedes UEFI-Mitglied kann der ASWG beitreten und zur ACPI-Spezifikation beitragen.\\
Die Spezifikation ist verfügbar unter: \url{https://uefi.org/specifications}.

\subsubsection{AML debugger interface}
CONFIG\_ACPI\_DEBUGGER [=n] \textbf{[N]}\\
Aktiviert das In-Kernel-Debugging von AML-Funktionen: Statistiken, interner Objekt-Dump, Aus\-füh\-rung von Einzel\-schritt-Kontroll\-methoden. Dies befindet
sich noch in der Entwicklung, derzeit führt die Aktivierung nur zur Kompilierung der ACPICA-Debugger-Dateien.

\subsubsection{ACPI Serial Port Console Redirection Support}
CONFIG\_ACPI\_SPCR\_TABLE [=y] \textbf{[Y]}\\
Aktiviert die Unterstützung für die Serial Port Console Redirection (SPCR) Tabelle. Diese Tabelle enthält Informationen über die Konfiguration
der earlycon-Konsole.

\subsubsection{ACPI Firmware Performance Data Table (FPDT] support}
CONFIG\_ACPI\_FPDT [=y] \textbf{[Y]}\\
Aktiviert die Unterstützung für die Firmware Performance Data Table (FPDT). Diese Tabelle enthält Informationen über das Timing des Systemstarts,
der S3-Suspend- und S3-Resume-Firmware-Codepfade.

\subsubsection{Allow supported ACPI revision to be overridden}
CONFIG\_ACPI\_FPDT [=y] \textbf{[Y]}\\
(Erlaubt das Überschreiben der unterstützten ACPI-Revision)\\
Die Plattform-Firmware auf einigen Systemen erwartet, dass Linux \glqq 5\grqq{} als unterstützte ACPI-Revision zurückgibt, was dazu führt, dass sie
Systemkonfigurationsinformationen auf eine besondere Weise offenlegt. Basierend darauf, was ACPI als unterstützte Revision exportiert,
konfiguriert beispielsweise das Dell~XPS~13 (2015) sein Audiogerät so, dass es entweder im HDA-Modus oder im I2S-Modus arbeitet, wobei
ersterer unter Linux verwendet werden soll, bis letzterer vollständig unterstützt wird (sowohl im Kernel als auch im Userspace). Diese
Option ermöglicht eine DMI-basierte Besonderheit für den oben genannten Dell-Rechner (so dass HDA-Audio von der Plattform-Firmware dem
Kernel offengelegt wird) und macht es möglich, den Kernel zu zwingen, \glqq 5\grqq{} als unterstützte ACPI-Revision über den
Befehlszeilenschalter \texttt{acpi\_rev\_override} zurückzugeben.

\subsubsection{EC read/write access through /sys/kernel/debug/ec}
CONFIG\_ACPI\_EC\_DEBUGFS [=m] \textbf{[M]}\\
Sagen Sie N, um die Schnittstelle Embedded Controller /sys/kernel/debug zu deaktivieren. Beachten Sie, dass die Verwendung dieser Schnittstelle
Ihren Embedded Controller so verwirren kann, dass ein normaler Neustart nicht ausreicht. Sie müssen dann Ihr System ausschalten und den Akku
des Laptops für einige Sekunden entfernen. Ein Embedded Controller ist in der Regel auf Laptops vorhanden und liest Sensorwerte wie
Batteriestatus und Temperatur aus. Der Kernel greift auf den EC über ACPI-geparsten Code zu, der von BIOS-Tabellen bereitgestellt wird.
Diese Option ermöglicht den direkten Zugriff auf den EC, ohne dass ACPI-Code involviert ist.\\
Somit ist diese Option eine Debug-Option, die beim Schreiben von ACPI-Treibern hilft und zur Identifizierung von ACPI-Code oder
EC-Firmware-Fehlern verwendet werden kann.

\subsubsection{AC Adapter}
CONFIG\_ACPI\_AC [=y] \textbf{[Y]}\\
Dieser Treiber unterstützt das AC-Adapter-Objekt, das anzeigt, ob ein System mit Wechselstrom betrieben wird oder nicht.
Wenn Sie ein System haben, das zwischen Wechselstrom und Batterie umschalten kann, sagen Sie Y. Um diesen Treiber als Modul
zu kompilieren, wählen Sie hier M: Das Modul wird \texttt{ac} heißen.

\subsubsection{Battery}
CONFIG\_ACPI\_BATTERY [=y] \textbf{[Y]}\\
Dieser Treiber bietet Unterstützung für Batterieinformationen über /proc/acpi/battery. Wenn Sie ein mobiles System mit
einer Batterie haben, sagen Sie Y. Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
Das Modul wird \texttt{battery} genannt.

\subsubsection{Button}
CONFIG\_ACPI\_BUTTON [=y] \textbf{[Y]}\\
Dieser Treiber verarbeitet Ereignisse für die Tasten Power, Sleep und Deckel. Ein Daemon liest Ereignisse von Eingabegeräten
oder über Netlink und führt benutzerdefinierte Aktionen wie das Herunterfahren des Systems aus. Dies ist für die
softwaregesteuerte Abschaltung erforderlich. Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
Das Modul wird \texttt{button} genannt.

\subsubsection{Video}
CONFIG\_ACPI\_VIDEO [=m] \textbf{[M]}\\
Dieser Treiber implementiert die ACPI-Erweiterungen für Display-Adapter für integrierte Grafikgeräte auf dem Motherboard,
wie in der ACPI 2.0-Spezifikation, Anhang B, angegeben.
Er unterstützt grundlegende Vorgänge wie das Definieren des Video-POST-Geräts, das Abrufen von EDID-Informationen und
das Einrichten eines Videoausgangs. Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
Das Modul wird \texttt{video} genannt.

\subsubsection{Fan}
CONFIG\_ACPI\_FAN [=y] \textbf{[Y]}\\
Dieser Treiber unterstützt ACPI-Lüftergeräte und ermöglicht es Anwendungen im Benutzermodus, grundlegende
Lüftersteuerungen (Ein, Aus, Status) durchzuführen. Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
Das Modul wird \texttt{fan} genannt.

\subsubsection{ACPI Time and Alarm (TAD) Device Support}
CONFIG\_ACPI\_TAD [=m] \textbf{[N]}\\
Das ACPI Time and Alarm (TAD) Gerät ist eine Alternative zur Real Time Clock (RTC). Seine Weckzeitgeber ermöglichen es dem System,
nach Ablauf einer bestimmten Zeitspanne vom Zustand S3 (oder optional S4/S5) in den Zustand S0 überzugehen.
Im Vergleich zum RTC-Alarm bietet der TAD eine größere Flexibilität bei den Wake-Timern.
Die Zeitfunktionen des TAD behalten die Tageszeitinformationen bei, auch wenn die Plattform ausgeschaltet ist.

\subsubsection{Dock}
CONFIG\_ACPI\_DOCK [=y] \textbf{[Y]}\\
Dieser Treiber unterstützt ACPI-gesteuerte Dockingstationen und Wechsellaufwerkseinschübe wie den IBM Ultrabay
und den Dell Module Bay.

\subsubsection{Processor}
CONFIG\_ACPI\_PROCESSOR [=y] \textbf{[Y]}\\
Dieser Treiber bietet Unterstützung für das ACPI-Prozessor-Paket. Er wird von mehreren Varianten der cpufreq-Treiber
für den Leistungszustand, die Wärmeentwicklung, die Drosselung und den Leerlauf benötigt.
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M: Das Modul heißt dann \texttt{processor}.

\subsubsection{IPMI}
CONFIG\_ACPI\_IPMI [=m] \textbf{[M]}\\
Dieser Treiber ermöglicht dem ACPI den Zugriff auf den BMC-Controller. Und er verwendet die IPMI-Anfrage/Antwort-Nachricht
zur Kommunikation mit dem BMC-Controller, der sich auf dem Server befindet.
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
Das Modul wird als \texttt{acpi\_ipmi} aufgerufen.

\subsubsection{Processor Aggregator}
CONFIG\_ACPI\_PROCESSOR\_AGGREGATOR [=m] \textbf{[M]}\\
ACPI 4.0 definiert einen Prozessor-Aggregator, der es dem Betriebssystem ermöglicht, eine spezifische Prozessorkonfiguration
und -steuerung durchzuführen, die für alle Prozessoren der Plattform gilt. Derzeit ist nur der logische Leerlauf des Prozessors
definiert, der den Stromverbrauch senken soll. Dieser Treiber unterstützt das neue Gerät.

\subsubsection{Thermal Zone}
CONFIG\_ACPI\_THERMAL [=y] \textbf{[Y]}\\
Dieser Treiber unterstützt ACPI-Thermozonen. Die meisten mobilen und einige Desktop-Systeme unterstützen ACPI-Wärmezonen.
Es wird DRINGEND empfohlen, diese Option zu aktivieren, da Ihr(e) Prozessor(en) sonst beschädigt werden können. Um diesen Treiber
als Modul zu kompilieren, wählen Sie hier M: Das Modul wird \texttt{thermal} genannt.

\subsubsection{Allow upgrading ACPI tables via initrd}
CONFIG\_ACPI\_TABLE\_UPGRADE [=y] \textbf{[Y]}\\
Diese Option bietet die Möglichkeit, beliebige ACPI-Tabellen über initrd zu aktualisieren.
Keine funktionale Änderung, wenn keine ACPI-Tabellen über initrd übergeben werden, daher ist es sicher, Y zu sagen.
Siehe Documentation/admin-guide/acpi/initrd\_table\_override.rst für Details

\subsubsection{Debug Statements}
CONFIG\_ACPI\_DEBUG [=y] \textbf{[Y]}\\
Das ACPI-Sub\-system kann Debug-Aus\-gaben er\-zeu\-gen.
Die Angabe von Y aktiviert diese Ausgabe und erhöht die Ker\-nel\-grö\-ße um etwa 50K.\\
Verwenden Sie die Kernel-Befehlszeilen\-parameter \texttt{acpi.debug\_layer} und \texttt{acpi.debug\_level}, die in
Do\-cu\-men\-tation/firmware-guide/acpi/debug.rst und Docu\-men\-tation/admin-guide/kernel-parameters.rst dokumentiert sind,
um die Art und Menge der Debug-Ausgabe zu steuern.

\subsubsection{PCI slot detection driver}
CONFIG\_ACPI\_PCI\_SLOT [=y] \textbf{[Y]}\\
Dieser Treiber erstellt Einträge in \texttt{/sys/bus/pci/slots/} für alle PCI-Steckplätze im System.
Dies kann helfen, PCI-Bus-Adressen, d.h. Segment/Bus/Gerät/Funktions-Tupel, mit physischen Steckplätzen im System zu korrelieren.\\
Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{Container and Module Devices}
CONFIG\_ACPI\_CONTAINER [=y] \textbf{[Y]}\\
Dieser Treiber unterstützt ACPI-Container- und Modulgeräte (IDs ACPI0004, PNP0A05 und PNP0A06).
Dies hilft, Hotplug von Knoten, CPUs und Speicher zu unterstützen.

\subsubsection{Memory Hotplug}
CONFIG\_ACPI\_HOTPLUG\_MEMORY [=y] \textbf{[Y]}\\
Dieser Treiber unterstützt ACPI-Speicher-Hotplug.  Die Treiberfelder enthalten Benachrichtigungen über
ACPI-Speichergeräte (PNP0C80), die Speicherbereiche darstellen, die zur Laufzeit ein- oder ausgeschaltet
werden können. Wenn Ihre Hardware und Firmware das Hinzufügen oder Entfernen von Speichergeräten zur Laufzeit
nicht unterstützen, müssen Sie diesen Treiber nicht aktivieren.

\subsubsection{Smart Battery System}
CONFIG\_ACPI\_SBS [=m] \textbf{[N]}\\
Dieser Treiber unterstützt das Smart Battery System, eine andere Art des Zugriffs auf Batterieinformationen,
die bei einigen Laptops zu finden ist. Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M: Die Module
heißen dann sbs und sbshc.

\subsubsection{Hardware Error Device}
CONFIG\_ACPI\_HED [=y] \textbf{[Y]}\\
Dieser Treiber unterstützt das Hardware Error Device (PNP0C33), das dazu dient, einige über SCI gemeldete
Hardwarefehler zu melden, hauptsächlich die korrigierten Fehler.

\subsubsection{Allow ACPI methods to be inserted/replaced at run time}
CONFIG\_ACPI\_CUSTOM\_METHOD [=m] \textbf{[M]}\\
Mit dieser Debug-Funktion können ACPI-AML-Methoden eingefügt und/oder ersetzt werden, ohne dass das System
neu gestartet werden muss.\\
Für Details siehe: Documentation/firmware-guide/acpi/method-customizing.rst.\\
HINWEIS: Diese Option ist sicherheitsrelevant, da sie es erlaubt, dass root (uid=0) Benutzer in beliebigen
Kernelspeicher schreiben können und so bestimmte Sicherheitsmaßnahmen umgehen können (z.~B. wenn es root
nicht erlaubt ist, zusätzliche Kernelmodule nach dem Booten zu laden, kann diese Funktion verwendet werden,
um diese Einschränkung zu umgehen).

\subsubsection{Boottime Graphics Resource Table support}
CONFIG\_ACPI\_BGRT [=y] \textbf{[Y]}\\
Dieser Treiber bietet Unterstützung für die ACPI Boottime Graphics Resource Table, die es dem Betriebssystem
ermöglicht, Daten aus dem Firmware-Boot-Splash zu beziehen.\\
Er erscheint unter \texttt{/sys/firmware/acpi/bgrt/} .

\subsubsection{ACPI NVDIMM Firmware Interface Table (NFIT)}
CONFIG\_ACPI\_NFIT [=m] \textbf{[M]}\\
Infrastruktur, um ACPI 6-konforme Plattformen auf NVDIMMs zu untersuchen (NFIT) und einen libnvdimm-Gerätebaum
zu registrieren. Zusätzlich zu den Speichergeräten ermöglicht dies libnvdimm auch die Weitergabe von
ACPI.\_DSM-Nachrichten für die Plattform/Dimm-Konfiguration. Um diesen Treiber als Modul zu kompilieren,
wählen Sie hier M: Das Modul wird \texttt{nfit} genannt.

\paragraph{Enable debug for NVDIMM security commands}$~$\\
CONFIG\_NFIT\_SECURITY\_DEBUG [=n] \textbf{[N]}\\
Einige NVDIMM-Geräte und -Controller unterstützen Verschlüsselung und andere Sicherheitsfunktionen.
Die Nutzdaten für die Befehle, die diese Funktionen aktivieren, können sensibles Sicherheitsmaterial
im Klartext enthalten. Deaktivieren Sie das Debuggen dieser Befehls-Payloads standardmäßig. Wenn Sie ein
Kernel-Entwickler sind, der aktiv an der Aktivierung der NVDIMM-Sicherheit arbeitet, sagen Sie Y,
andernfalls sagen Sie N.

\subsubsection{NUMA support}
CONFIG\_ACPI\_NUMA [=y] \textbf{[Y]}\\
\textit{Für diese Option ist keine Hilfe verfügbar.}

\paragraph{ACPI Heterogeneous Memory Attribute Table Support}$~$\\
CONFIG\_ACPI\_HMAT [=y] \textbf{[Y]}\\
Wenn diese Option gesetzt ist, lässt der Kernel die ACPI HMAT (Heterogeneous Memory Attributes Table)
der Plattform auslesen und melden, Speicherinitiatoren mit ihren Zielen registrieren und Leistungsattribute
über das sysfs-Gerät des Knotens exportieren, falls vorhanden.

\subsubsection{ACPI Platform Error Interface (APEI)}
CONFIG\_ACPI\_APEI [=y] \textbf{[Y]}\\
APEI ermöglicht es, Fehler (z.~B. vom Chipsatz) an das Betriebssystem zu melden. Dies verbessert
insbesondere die NMI-Behandlung. Darüber hinaus unterstützt es Fehlerserialisierung und Fehlerinjektion.

\paragraph{ACPI Generic Hardware Error Source}$~$\\
CONFIG\_ACPI\_APEI\_GHES [=y] \textbf{[Y]}\\
Generic Hardware Error Source bietet eine Möglichkeit, Plattform-Hardware-Fehler (z.~B. vom Chipsatz) zu melden.
Sie arbeitet im so genannten \glqq Firmware First\grqq{}-Modus, d. h. Hardwarefehler werden zunächst an die
Firmware gemeldet und dann von der Firmware an Linux weitergeleitet.
Auf diese Weise können einige Nicht-Standard-Hardware-Fehlerregister oder Nicht-Standard-Hardware-Verbindungen
von der Firmware überprüft werden, um wertvollere Hardware-Fehlerinformationen für Linux zu erhalten.

\paragraph{ACPI PCIe AER logging/recovering support}$~$\\
CONFIG\_ACPI\_APEI\_PCIEAER [=y] \textbf{[Y]}\\
PCIe-AER-Fehler können über den APEI-Firmware-First-Modus gemeldet werden. Aktivieren Sie diese Option,
um die entsprechende Unterstützung zu aktivieren.

\subsubsection{ACPI memory error recovering support}
CONFIG\_ACPI\_APEI\_MEMORY\_FAILURE [=y] \textbf{[Y]}\\
Speicherfehler können über den APEI-Firmware-First-Modus gemeldet werden. Aktivieren Sie diese Option,
um die Unterstützung für die Speicherwiederherstellung zu aktivieren.

\subsubsection{APEI Error INJection (EINJ)}
CONFIG\_ACPI\_APEI\_EINJ [=m] \textbf{[M]}\\
EINJ bietet einen Hardware-Fehlerinjektionsmechanismus, der hauptsächlich zur Fehlersuche und zum Testen
der anderen Teile von APEI und einiger anderer RAS-Funktionen verwendet wird.

\subsubsection{APEI Error Record Serialization Table (ERST) Debug Support}
CONFIG\_ACPI\_APEI\_ERST\_DEBUG [=m] \textbf{[M]}\\
ERST ist eine von APEI bereitgestellte Möglichkeit, Hardware-Fehler\-infor\-mationen in einem dauerhaften Speicher
zu speichern und von dort abzurufen. Aktivieren Sie dies, wenn Sie die ERST-Kernel\-un\-ter\-stüt\-zung und
Firmware-Implementierung debuggen und testen wollen.

\subsubsection{Intel DPTF (Dymnamic Platform and Thermal Framework) Support \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_ACPI\_DPTF [=y] \textbf{[Y]}\\
Intel Dynamic Platform and Thermal Framework (DPTF) ist eine Hardware-/Softwarelösung auf Plattformebene für
das Energie- und Wärmemanagement. Als Container für mehrere Energie-/Thermo\-tech\-no\-lo\-gi\-en bietet DPTF einen
koordinierten Ansatz für verschiedene Richtlinien, die den Hardwarezustand eines Systems beeinflussen.

\paragraph{Platform Power DPTF Participant}$~$\\
CONFIG\_DPTF\_POWER [=m] \textbf{[M]}\\
Dieser Treiber bietet Unterstützung für das Dynamic Platform and Thermal Framework (DPTF) Platform Power
Participant Device (INT3407). Dieser Teilnehmer ist für die Offenlegung der Plattformtelemetrie verantwortlich:
\begin{itemize}
	\item max\_platform\_power (max. Plattformleistung)
	\item platform\_power\_source (Plattformstromquelle)
	\item adapter\_rating (Leistung des Netzteils)
	\item battery\_steady\_power (Dauerleistung der Batterie)
	\item ladegerät\_typ (Ladegerättyp)
\end{itemize}
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M: Das Modul heißt dann \texttt{dptf\_power}.

\paragraph{PCH FIVR DPTF Participant}$~$\\
CONFIG\_DPTF\_PCH\_FIVR [=m] \textbf{[M]}\\
Dieser Treiber fügt Unterstützung für Dynamic Platform and Thermal Framework (DPTF) PCH FIVR Participant
Device Support hinzu. Dieser Treiber ermöglicht es, die Frequenz des PCH FIVR (Fully Integrated Voltage Regulator)
zu schalten. Dieser Teilnehmer ist für die Bereitstellung verantwortlich:
\begin{itemize}
	\item freq\_mhz\_low\_clock
	\item freq\_mhz\_high\_clock
\end{itemize}
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M: das Modul wird
\texttt{dptf\_pch\_fivr} heißen.

\subsubsection{Extended Error Log support}
CONFIG\_ACPI\_EXTLOG [=m] \textbf{[M]}\\
Bestimmte Anwendungen wie die vorausschauende Fehleranalyse (Predictive Failure Analysis, PFA) erfordern mehr Informationen
über den Fehler, als in den Prüfbänken der Prozessormaschine beschrieben werden können. Die meisten Server-Prozessoren
protokollieren zusätzliche Informationen über den Fehler in Prozessor-Uncore-Registern. Da die Adressen und das Layout
dieser Register von einem Prozessor zum anderen sehr unterschiedlich sind, kann die Systemsoftware sie nicht ohne weiteres
nutzen. Erschwerend kommt hinzu, dass einige der zusätzlichen Fehlerinformationen nicht ohne detaillierte Kenntnisse der
Plattformtopologie erstellt werden können. Die erweiterte MCA-Protokollierung ermöglicht es der Firmware, der Systemsoftware
synchron mit MCE oder CMCI zusätzliche Fehlerinformationen zu liefern. Dieser Treiber unterstützt diese Funktionalität mit
einem entsprechenden Tracepoint, der diese Informationen an den Userspace weiterleitet.

\subsubsection{ACPI configfs support}
CONFIG\_ACPI\_CONFIGFS [=m] \textbf{[M]}\\
Wählen Sie diese Option, um die Unterstützung für die ACPI-Konfiguration aus dem Userspace zu aktivieren. Die konfigurierbaren
ACPI-Gruppen sind dann unter /config/acpi sichtbar, vorausgesetzt, configfs ist unter /config eingebunden.

\subsubsection{ACPI Platform Firmware Runtime Update and Telemetry}
CONFIG\_ACPI\_PFRUT [=m] \textbf{[M]}\\
Dieser Mechanismus ermöglicht es, bestimmte Teile der Plattform-Firmware während des laufenden Betriebs (Laufzeit) zu
aktualisieren, ohne dass ein Neustart erforderlich ist. Dies ist von entscheidender Bedeutung, wenn das System zu
100~\% verfügbar sein muss und sich die mit einem Neustart verbundene Ausfallzeit nicht leisten kann, oder wenn die vom
System ausgeführte Arbeit besonders wichtig ist, so dass sie nicht unterbrochen werden kann und es nicht sinnvoll ist,
zu warten, bis sie abgeschlossen ist. Der bestehende Firmware-Code kann geändert (Treiber-Update) oder durch Hinzufügen
neuen Codes zur Firmware erweitert werden (Code-Injektion). Außerdem ermöglicht der Telemetrietreiber dem Benutzer, mit
Hilfe der Plattform-Firmware-Laufzeit-Telemetrieschnittstelle Telemetriedaten aus der Firmware abzurufen. Um die Treiber
als Module zu kompilieren, wählen Sie hier M: die Module heißen dann \texttt{pfr\_update} und \texttt{pfr\_telemetry}.

\subsubsection{ACPI PCC Address Space}
CONFIG\_ACPI\_PCC [=y] \textbf{[Y]}\\
Der PCC-Adressraum, der auch als PCC-Operationsbereich bezeichnet wird, bezieht sich auf den Bereich des PCC-Unterraums,
der auf die PCC-Signatur folgt. Die PCC Operation Region arbeitet mit der PCC Table (Platform Communications Channel Table)
zusammen. PCC-Unterräume, die für die Verwendung als PCC Operation Region markiert sind, dürfen nicht als PCC-Unterräume
für die Standard-ACPI-Funktionen wie CPPC, RASF, PDTT und MPST verwendet werden. Diese Standardfunktionen müssen stattdessen
immer die PCC-Tabelle verwenden. Aktivieren Sie diese Funktion, wenn Sie den PCC Address Space Handler einrichten und
installieren möchten, um PCC OpRegion in der Firmware zu behandeln.

\subsubsection{ACPI FFH Address Space}
CONFIG\_ACPI\_FFH [=y] \textbf{[Y]}\\
Der FFH (Fixed Function Hardware) Adressraum, auch FFH Operation Region genannt, erlaubt es, plattformspezifische OpRegions
zu definieren. Aktivieren Sie diese Funktion, wenn Sie den FFH-Adressraum-Handler einrichten und installieren möchten,
um die FFH-OpRegion in der Firmware zu behandeln.

\subsubsection{PMIC (Power Management Integrated Circuit) operation region support}
CONFIG\_PMIC\_OPREGION [=y] \textbf{[Y]}\\
Wählen Sie diese Option, um die Unterstützung für den ACPI-Betriebsbereich des PMIC-Chips zu aktivieren. Der Betriebsbereich
kann zur Steuerung von Stromschienen und zum Lesen/Schreiben von Sensoren auf dem PMIC-Chip verwendet werden.

\subsubsection{ACPI operation region support for TPS68470 PMIC}
CONFIG\_TPS68470\_PMIC\_OPREGION [=y] \textbf{[Y]}\\
Diese Konfiguration fügt ACPI-Betriebsbereich-Unterstützung für TI TPS68470 PMIC hinzu. Der Baustein TPS68470 ist eine
fortschrittliche Energieverwaltungseinheit, die ein Kompaktkameramodul (CCM) mit Strom versorgt, Takte für Bildsensoren
erzeugt, eine Dual-LED für den Blitz ansteuert und zwei LED-Treiber für allgemeine Anzeigen enthält.
Dieser Treiber ermöglicht die Unterstützung der ACPI-Betriebsregion für die Steuerung von Spannungsreglern und Taktgebern.
Bei dieser Option handelt es sich um ein bool, da sie eine ACPI-Betriebsregion bereitstellt, die verfügbar sein muss,
bevor eines der Geräte, die diese Option verwenden, getestet wird.

\subsubsection{Platform Runtime Mechanism Support}
CONFIG\_ACPI\_PRMT [=y] \textbf{[Y]}\\
Der Plattform-Laufzeit-Mechanismus (Platform Runtime Mechanism, PRM) ist eine Firmware-Schnitt\-stelle, die eine Reihe von
ausführbaren Binärdateien bereitstellt, die vom AML-Interpreter oder direkt von Gerätetreibern aufgerufen werden können.
Sagen Sie Y, um den AML-Interpreter für die Ausführung des PRM-Codes zu aktivieren. Während diese Funktion im Prinzip
optional ist, kann das Weglassen dieser Funktion den Rechenaufwand für die Initialisierung einiger Serversysteme erheblich
erhöhen.

\subsection{CPU Frequency scaling \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_CPU\_FREQ [=y] \textbf{[Y]}\\
Mit der CPU-Frequenzskalierung können Sie die Taktfrequenz von CPUs im laufenden Betrieb ändern. Dies ist eine gute Methode,
um Strom zu sparen, denn je niedriger die CPU-Taktfrequenz, desto weniger Strom verbraucht die CPU. Beachten Sie, dass
dieser Treiber die CPU-Taktfrequenz nicht automatisch ändert. Sie müssen entweder einen dynamischen cpufreq-Governor
(siehe unten) nach dem Booten aktivieren oder ein Userspace-Tool verwenden.\\
Details finden Sie in $<$file:Documentation/admin-guide/pm/cpufreq.rst$>$. Im Zweifelsfall sagen Sie N.

\subsubsection{CPU frequency transition statistics}
CONFIG\_CPU\_FREQ\_STAT [=y] \textbf{[Y]}\\
Exportieren Sie CPU-Häufigkeitsstatistiken über sysfs. Im Zweifelsfall sagen Sie N.

\subsubsection{Default CPUFreq governor () \texorpdfstring{$\rightarrow$}{->}}
Diese Option legt fest, welcher CPUFreq-Governor beim Start geladen werden soll.
Im Zweifelsfall ist die Standardeinstellung zu verwenden.

\paragraph{performance}$~$\\
CONFIG\_CPU\_FREQ\_DEFAULT\_GOV\_PERFORMANCE [=n] \textbf{[N]}\\
Verwenden Sie den CPUFreq-Governor \glq performance\grq{} als Standard. Damit wird die Frequenz statisch auf die höchste von
der CPU unterstützte Frequenz eingestellt.

\paragraph{powersave}$~$\\
CONFIG\_CPU\_FREQ\_DEFAULT\_GOV\_POWERSAVE [=n] \textbf{[N]}\\
Verwenden Sie den CPUFreq-Governor \glq powersave\grq{} als Standard. Damit wird die Frequenz statisch auf die niedrigste
von der CPU unterstützte Frequenz eingestellt.

\paragraph{userspace}$~$\\
CONFIG\_CPU\_FREQ\_DEFAULT\_GOV\_USERSPACE [=n] \textbf{[N]}\\
Verwenden Sie den CPUFreq-Governor \glq userspace\grq{} als Standard. Damit können Sie die CPU-Frequenz manuell einstellen
oder ein Userspace-Programm soll die CPU dynamisch einstellen können, ohne den Userspace-Governor manuell
aktivieren zu müssen.

\paragraph{schedutil}$~$\\
CONFIG\_CPU\_FREQ\_DEFAULT\_GOV\_SCHEDUTIL [=y] \textbf{[Y]}\\
Verwenden Sie standardmäßig den CPUFreq-Governor \glq schedutil\grq{}. Wenn Sie sich nicht sicher sind, sehen Sie in
der Hilfe zu diesem Gouverneur nach. Der Fallback-Regler ist \glqq performance\grqq{}.

\subsubsection{`performance' governor}
CONFIG\_CPU\_FREQ\_GOV\_PERFORMANCE [=y] \textbf{[Y]}\\
Dieser cpufreq-Regler setzt die Frequenz statisch auf die höchste verfügbare CPU-Frequenz. Um diesen Treiber
als Modul zu kompilieren, wählen Sie hier M: Das Modul wird \texttt{cpufreq\_performance} heißen.
Im Zweifelsfall sagen Sie Y.

\subsubsection{`powersave' governor}
CONFIG\_CPU\_FREQ\_GOV\_POWERSAVE [=y] \textbf{[Y]}\\
Dieser cpufreq-Regler setzt die Frequenz statisch auf die niedrigste verfügbare CPU-Frequenz. Um diesen Treiber
als Modul zu kompilieren, wählen Sie hier M: Das Modul wird \texttt{cpufreq\_powersave} heißen.
Im Zweifelsfall wählen Sie Y.

\subsubsection{`userspace' governor for userspace frequency scaling}
CONFIG\_CPU\_FREQ\_GOV\_USERSPACE [=y] \textbf{[Y]}\\
Aktivieren Sie diesen cpufreq-Governor, wenn Sie die CPU-Frequenz entweder manuell einstellen wollen oder wenn
ein Userspace-Programm in der Lage sein soll, die CPU dynamisch einzustellen, wie bei
LART \url{http://www.lartmaker.nl/}. Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
das Modul wird cpufreq\_userspace heißen. Im Zweifelsfall sagen Sie Y.

\subsubsection{`ondemand' cpufreq policy governor}
CONFIG\_CPU\_FREQ\_GOV\_ONDEMAND [=y] \textbf{[Y]}\\
`ondemand' -- Dieser Treiber fügt einen dynamischen cpufreq policy governor hinzu.
Der Gouverneur führt eine periodische Abfrage durch und ändert die Frequenz auf der Grundlage der CPU-Auslastung.
Die Unterstützung für diesen Gouverneur hängt von der Fähigkeit der CPU ab, schnelle Frequenzwechsel durchzuführen
(d.h. Frequenzübergänge mit sehr geringer Latenzzeit). Um diesen Treiber als Modul zu kompilieren,
wählen Sie hier M: Das Modul wird \texttt{cpufreq\_ondemand} heißen.
Details finden Sie in $<$file:Documentation/admin-guide/pm/cpufreq.rst$>$. Im Zweifelsfall sagen Sie N.

\subsubsection{`conservative' cpufreq governor}
CONFIG\_CPU\_FREQ\_GOV\_CONSERVATIVE [=y] \textbf{[Y]}\\
`konservativ' -- dieser Treiber ähnelt dem \glqq On-Demand\grqq{}-Regler sowohl in seinem Quellcode als auch in
seinem Zweck, der Unterschied besteht in seiner Optimierung für eine bessere Eignung in einer batteriebetriebenen
Umgebung. Die Frequenz wird sanft erhöht und gesenkt, anstatt auf 100~\% zu springen, wenn die Geschwindigkeit
erforderlich ist. Wenn Sie einen Desktop-Rechner haben, sollten Sie stattdessen den \glqq On-Demand\grqq{}-Regler
in Betracht ziehen. Wenn Sie jedoch einen Laptop, einen PDA oder sogar einen AMD64-basierten Computer verwenden
(wegen der inakzeptablen schrittweisen Latenzprobleme zwischen den minimalen und maximalen Frequenzübergängen in
der CPU), werden Sie wahrscheinlich diesen Regler verwenden wollen. Um diesen Treiber als Modul zu kompilieren,
wählen Sie hier M: Das Modul wird \texttt{cpufreq\_conservative} heißen.\\
Einzelheiten finden Sie in $<$file:Documentation/admin-guide/pm/cpufreq.rst$>$.\\Im Zweifelsfall sagen Sie N.

\subsubsection{`schedutil' cpufreq policy governor}
CONFIG\_CPU\_FREQ\_GOV\_SCHEDUTIL [=y] \textbf{[Y]}\\
Dieser Gouverneur trifft seine Entscheidungen auf der Grundlage der vom Scheduler bereitgestellten Nutzungsdaten.
Er stellt die CPU-Frequenz so ein, dass sie proportional zu dem vom Scheduler gelieferten Verhältnis zwischen
Auslastung und Kapazität ist. Wenn die Auslastung frequenzinvariant ist, ist die neue Frequenz auch proportional
zur maximal verfügbaren Frequenz. Wenn dies nicht der Fall ist, ist sie proportional zur aktuellen Frequenz der CPU.
Der Kipppunkt der Frequenz liegt in beiden Fällen bei einer Auslastung/Kapazität von 80~\%.\\
Im Zweifelsfall sagen Sie N.

\subsubsection*{*** CPU frequency scaling drivers ***}
(Treiber zur Skalierung der CPU-Frequenz)

\subsubsection{Intel P state control}
CONFIG\_X86\_INTEL\_PSTATE [=y] \textbf{[Y]}\\
Dieser Treiber bietet einen P-Status für Intel-Core-Prozessoren. Der Treiber implementiert einen internen
Gouverneur und wird der Skalierungstreiber und Gouverneur für Sandy-Bridge-Prozessoren werden.
Wenn dieser Treiber aktiviert ist, wird er der bevorzugte Skalierungstreiber für Sandy-Bridge-Prozessoren.\\
Im Zweifelsfall sagen Sie N.

\subsubsection{Processor Clocking Control interface driver}
CONFIG\_X86\_PCC\_CPUFREQ [=y] \textbf{[Y]}\\
Dieser Treiber bietet Unterstützung für die PCC-Schnittstelle. Einzelheiten finden Sie unter:\\
$<$file:Documentation/admin-guide/pm/cpufreq\_drivers.rst$>$. Um diesen Treiber als Modul zu kompilieren,
wählen Sie hier M: das Modul wird \texttt{pcc-cpufreq} heißen. Im Zweifelsfall sagen Sie N.

\subsubsection{AMD Processor P-State driver}
CONFIG\_X86\_AMD\_PSTATE [=y] \textbf{[Y]}\\
Dieser Treiber fügt einen CPUFreq-Treiber hinzu, der einen feinkörnigen Frequenzsteuerungsbereich für die
Prozessorleistung anstelle der alten Leistungsstufen verwendet. In den ACPI-Tabellen des Systems muss
\_CPC vorhanden sein.\\
Details finden Sie unter: $<$file:Documentation/admin-guide/pm/amd-pstate.rst$>$.
Im Zweifelsfall sagen Sie N.

\paragraph{AMD Processor P-State default mode}$~$\\
CONFIG\_X86\_AMD\_PSTATE\_DEFAULT\_MODE [=3] \textbf{[3]}\\
Wählen Sie den Standardmodus, den der amd-pstate-Treiber auf unterstützter Hardware verwenden soll.
Der eingestellte Wert hat die folgenden Bedeutungen: 
\begin{itemize}
\item[] 1 \texorpdfstring{$\rightarrow$}{->} Deaktiviert
\item[] 2 \texorpdfstring{$\rightarrow$}{->} Passiv
\item[] 3 \texorpdfstring{$\rightarrow$}{->} Aktiv (EPP)
\item[] 4 \texorpdfstring{$\rightarrow$}{->} Geführt
\end{itemize}
Für Details, siehe: $<$file:Documentation/admin-guide/pm/amd-pstate.rst$>$.\\
Symbol: X86\_AMD\_PSTATE\_DEFAULT\_MODE [=3]\\
Type  : Ganzzahl (integer)\\
Range : [1 4]

\subsubsection{selftest for AMD Processor P-State driver}
CONFIG\_X86\_AMD\_PSTATE\_UT [=m] \textbf{[M]}\\
Dieses Kernelmodul wird für Tests verwendet. Hier kann man mit Sicherheit M sagen.
Es kann auch ohne aktiviertes X86\_AMD\_PSTATE eingebaut werden. Derzeit werden nur Tests für amd-pstate
unterstützt. Wenn X86\_AMD\_PSTATE deaktiviert ist, kann es den Benutzern sagen, dass der Test nur auf dem
amd-pstate Treiber laufen kann, bitte setzen Sie X86\_AMD\_PSTATE aktiviert.
In der Zukunft werden Vergleichstests hinzugefügt werden. Es kann amd-pstate deaktiviert und acpi-cpufreq
aktiviert werden, um Testfälle auszuführen und dann die Testergebnisse zu vergleichen.

\subsubsection{ACPI Processor P-State driver}
CONFIG\_X86\_ACPI\_CPUFREQ [=m] \textbf{[M]}\\
Dieser Treiber fügt einen CPUFreq-Treiber hinzu, der die ACPI Processor Performance States nutzt.
Dieser Treiber unterstützt auch Intel Enhanced Speedstep und neuere AMD-CPUs. Um diesen Treiber als Modul
zu kompilieren, wählen Sie hier M: das Modul wird \texttt{acpi-cpufreq} heißen.\\
Details finden Sie unter $<$file:Documentation/cpu-freq/$>$. Im Zweifelsfall sagen Sie N.

\paragraph{Legacy cpb sysfs knob support for AMD CPUs}$~$\\
CONFIG\_X86\_ACPI\_CPUFREQ\_CPB [=y] \textbf{[Y]}\\
Der powernow-k8-Treiber stellte früher einen sysfs-Regler namens \texttt{cpb} zur Verfügung,
um die Core Performance Boosting-Funktion von AMD-CPUs zu deaktivieren. Diese Datei wurde nun durch den
allgemeineren \glqq boost\grqq{}-Eintrag abgelöst.
Wenn Sie diese Option aktivieren, stellt der acpi\_cpufreq-Treiber aus Kompatibilitätsgründen den alten
Eintrag zusätzlich zum neuen \glqq boost\grqq{}-Eintrag bereit.

\subsubsection{AMD Opteron/Athlon64 PowerNow!}
CONFIG\_X86\_POWERNOW\_K8 [=m] \textbf{[M]}\\
Dies fügt den CPUFreq-Treiber für K8/frühe Opteron/Athlon64-Prozessoren hinzu. Unterstützung für K10 und
neuere Prozessoren ist jetzt in acpi-cpufreq enthalten. Um diesen Treiber als Modul zu kompilieren,
wählen Sie hier M: das Modul wird \texttt{powernow-k8} heißen.\\
Details finden Sie in $<$file:Documentation/cpu-freq/$>$.

\subsubsection{AMD frequency sensitivity feedback powersave bias}
CONFIG\_X86\_AMD\_FREQ\_SENSITIVITY [=m] \textbf{[M]}\\
Dies fügt dem On-Demand-Governor eine AMD-spezifische Powersave-Bias-Funktion hinzu, die es ihm ermöglicht,
auf der Grundlage von Rückmeldungen der Hardware energiebewusstere Entscheidungen über Frequenzänderungen
zu treffen (verfügbar ab AMD-Familie 16h). Durch das Hardware-Feedback erfährt die Software, wie
\glqq empfindlich\grqq{} die Arbeitslasten der CPUs gegenüber Frequenzänderungen sind.
CPU-gebundene Arbeitslasten sind empfindlicher, d. h. sie werden bei einer Frequenzerhöhung besser funktionieren.
Speicher-/IO-gebundene Arbeitslasten reagieren weniger empfindlich, d. h. sie werden nicht unbedingt besser,
wenn die Frequenz erhöht wird.\\
Im Zweifelsfall sagen Sie N.

\subsubsection{Intel Enhanced SpeedStep (deprecated)}
CONFIG\_X86\_SPEEDSTEP\_CENTRINO [=n] \textbf{[N]}\\
Dies ist veraltet und diese Funktionalität ist nun in acpi\_cpufreq (X86\_ACPI\_CPUFREQ) integriert.
Verwenden Sie diesen Treiber anstelle von speedstep\_centrino.
Dies fügt den CPUFreq-Treiber für Enhanced SpeedStep-fähige mobile CPUs hinzu.
Dies bedeutet Intel Pentium M (Centrino) CPUs oder 64bit-fähige Intel Xeons. Um diesen Treiber als Modul
zu kompilieren, wählen Sie hier M: das Modul wird \texttt{speedstep-centrino} heißen.\\
Details finden Sie unter $<$file:Documentation/cpu-freq/$>$. Im Zweifelsfall wählen Sie N.

\subsubsection{Intel Pentium 4 clock modulation}
CONFIG\_X86\_P4\_CLOCKMOD [=m] \textbf{[N]}\\
Dies fügt den CPUFreq-Treiber für Intel Pentium 4 / XEON Prozessoren hinzu. Wenn er aktiviert ist,
senkt er die CPU-Temperatur durch Überspringen von Takten. Dieser Treiber sollte nur in Ausnahmefällen
verwendet werden, wenn eine sehr niedrige Leistung benötigt wird, da er starke Verlangsamungen und spürbare
Latenzen verursacht. Normalerweise sollte stattdessen Speedstep verwendet werden.
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M: das Modul wird \texttt{p4-clockmod} genannt.\\
Für Details werfen Sie einen Blick auf $<$file:Documentation/cpu-freq/$>$. Wenn Sie sich nicht absolut
sicher sind, wählen Sie N.

\subsubsection*{*** shared options ***}
(gemeinsame Optionen)

\subsection{CPU Idle \texorpdfstring{$\rightarrow$}{->}}
(CPU im Leerlauf)

\subsubsection{CPU idle PM support}
CONFIG\_CPU\_IDLE [=y] \textbf{[Y]}\\
CPU idle ist ein allgemeiner Mechanismus zur Unterstützung der softwaregesteuerten Verwaltung der
Prozessorleistung im Leerlauf. Es umfasst modulare plattformübergreifende Regler, die während der
Laufzeit ausgetauscht werden können. Wenn Sie eine ACPI-aktivierte Plattform verwenden, sollten Sie hier Y angeben.
PM steht für \glqq power management\grqq{} -- Verwaltung der Prozessorleistung.

\paragraph{Ladder governor (for periodic timer tick)}$~$\\
CONFIG\_CPU\_IDLE\_GOV\_LADDER [=y] \textbf{[Y]}\\
\textit{Für diese Option gibt es keine Hilfe.}

\paragraph{Menu governor (for tickless system)}$~$\\
CONFIG\_CPU\_IDLE\_GOV\_MENU [=y] \textbf{[Y]}\\
\textit{Für diese Option gibt es keine Hilfe.}

\paragraph{Timer events oriented (TEO) governor (for tickless systems)}$~$\\
CONFIG\_CPU\_IDLE\_GOV\_TEO [=y] \textbf{[Y]}\\
Dieser Gouverneur implementiert eine vereinfachte Methode zur Auswahl des Ruhezustands, die sich auf
Timer-Ereignisse konzentriert und keine Steigerung der Interaktivität bewirkt.
Einige Arbeitslasten profitieren davon, und es sollte im Allgemeinen sicher zu verwenden sein.\\
Sagen Sie hier Y, wenn Sie mit den Alternativen nicht zufrieden sind.

\paragraph{Haltpoll governor (for virtualized systems)}$~$\\
CONFIG\_CPU\_IDLE\_GOV\_HALTPOLL [=y] \textbf{[Y]}\\
Dieser Gouverneur implementiert die Auswahl des Leerlaufzustands von haltpoll, der in Verbindung mit
dem haltpoll cpuidle-Treiber verwendet wird und es ermöglicht, eine bestimmte Zeit lang zu pollen,
bevor der Leerlaufzustand erreicht wird. Einige virtualisierte Arbeitslasten profitieren von dieser Funktion.

\paragraph{Halt poll cpuidle driver}$~$\\
CONFIG\_HALTPOLL\_CPUIDLE [=m] \textbf{[N]}\\
Diese Option aktiviert den \glqq halt poll cpuidle\grqq{}-Treiber, der eine Abfrage vor dem Anhalten
im Gast ermöglicht (effizienter als die Abfrage im Host über halt\_poll\_ns für einige Szenarien).

\subsection{CPUidle Driver for Intel Processors}
CONFIG\_INTEL\_IDLE [=y] \textbf{[Y]}\\
Aktivieren Sie intel\_idle, einen cpuidle-Treiber, der das Wissen über native Intel-Hardware-Idle-Funk\-tio\-nen enthält.
Der acpi\_idle-Treiber kann zur gleichen Zeit konfiguriert werden, um Prozessoren zu behandeln,
die intel\_idle nicht unterstützt.

\section{Bus options (PCI etc.) \texorpdfstring{$\rightarrow$}{->}}
\textit{Bus-Optionen (PCI usw.)}

\subsection{Support mmconfig PCI config space access}
CONFIG\_PCI\_MMCONFIG [=y] \textbf{[Y]}\\
(Unterstützung des mmconfig PCI"=Konfigurationsraumzugriffs)\\
\textit{Für diese Option gibt es keine Hilfe.}

\section{Binary Emulations \texorpdfstring{$\rightarrow$}{->}}
\textit{Binäre Emulationen}

\subsection{IA32 Emulation}
CONFIG\_IA32\_EMULATION [=y] \textbf{[N]}\\
Code einbinden, um ältere 32-Bit-Programme unter einem 64-Bit-Kernel auszuführen.
Sie sollten dies wahrscheinlich aktivieren, es sei denn, Sie sind sich zu 100~\% sicher,
dass Sie keine 32-Bit-Programme mehr haben.

\subsection{x32 ABI for 64-bit mode}
CONFIG\_X86\_X32\_ABI [=n] \textbf{[N]}\\
Fügen Sie Code ein, um Binärdateien für die native 32-Bit-ABI x32 für 64-Bit-Prozessoren auszuführen.
Ein x32-Prozess erhält Zugriff auf die vollständige 64-Bit-Registerdatei und den breiten Datenpfad,
während Zeiger auf 32~Bit belassen werden, um den Speicherbedarf zu verringern.

\section{Virtualization \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_VIRTUALIZATION [=y] \textbf{[Y]}\\
Sagen Sie hier Y, um Optionen für die Verwendung Ihres Linux-Hosts zur Ausführung anderer
Betriebssysteme in virtuellen Maschinen (Gäste) zu erhalten. Diese Option allein fügt keinen
Kernel-Code hinzu. Wenn Sie N sagen, werden alle Optionen in diesem Untermenü übersprungen
und deaktiviert.

\subsection{Kernel-based Virtual Machine (KVM) support}
CONFIG\_KVM [=m] \textbf{[M]}\\
Unterstützung für das Hosten vollständig virtualisierter Gastmaschinen mit
Hardware"=Virtualisierungserweiterungen. Sie benötigen einen relativ aktuellen Prozessor mit
Virtualisierungserweiterungen. Außerdem müssen Sie eines oder mehrere der unten aufgeführten
Prozessormodule auswählen. Dieses Modul ermöglicht den Zugriff auf die Hardware-Funktionen
über einen Geräteknoten namens /dev/kvm. Um dies als Modul zu kompilieren, wählen Sie hier M:
Das Modul wird \texttt{kvm} heißen.\\
Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{KVM for Intel (and compatible) processors support}
CONFIG\_KVM\_INTEL [=m] \textbf{[M]}\\
Bietet Unterstützung für KVM auf Prozessoren, die mit Intels VT-Erweiterungen, auch bekannt
als Virtual Machine Extensions (VMX), ausgestattet sind.
Um dies als Modul zu kompilieren, wählen Sie hier M: das Modul wird \texttt{kvm-intel} genannt.

\paragraph{Software Guard eXtension (SGX) Virtualization}$~$\\
CONFIG\_X86\_SGX\_KVM [=y] \textbf{[Y]}\\
Ermöglicht KVM-Gästen, SGX-Enklaven zu erstellen. Dies schließt die Unterstützung ein,
\glqq rohen\grqq{}, nicht wiederverwendbaren Enklavenspeicher für Gäste über einen Geräteknoten,
z.~B. /dev/sgx\_vepc, freizugeben. Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{KVM for AMD processors support}
CONFIG\_KVM\_AMD [=m] \textbf{[M]}\\
Bietet Unterstützung für KVM auf Prozessoren, die mit Intels VT-Erweiterungen, auch bekannt
Bietet Unterstützung für KVM auf AMD-Prozessoren, die mit den AMD-V (SVM)-Erweiterungen
ausgestattet sind. Um dies als Modul zu kompilieren, wählen Sie hier M:
Das Modul wird \texttt{kvm-amd} genannt.

\paragraph{AMD Secure Encrypted Virtualization (SEV) support}$~$\\
CONFIG\_KVM\_AMD\_SEV [=y] \textbf{[N]}\\
Bietet Unterstützung für den Start von verschlüsselten VMs (SEV) und verschlüsselten VMs
mit verschlüsseltem Status (SEV-ES) auf AMD-Prozessoren.

\subsubsection{System Management Mode emulation}
CONFIG\_KVM\_SMM [=y] \textbf{[Y]}\\
Bietet Unterstützung für KVM zur Emulation des Systemverwaltungsmodus (SMM) in virtuellen
Maschinen. Dies kann von der Firmware der virtuellen Maschine verwendet werden, um UEFI Secure
Boot zu implementieren.

\subsubsection{Support for Xen hypercall interface}
CONFIG\_KVM\_XEN [=y] \textbf{[Y]}\\
Bietet KVM-Unterstützung für das Hosten von Xen HVM-Gästen und die Weitergabe von
Xen-Hyper\-auf\-rufen an den Userspace. Im Zweifelsfall sagen Sie N.

\section{General architecture-dependent options \texorpdfstring{$\rightarrow$}{->}}
(Allgemeine architekturabhängige Optionen)

\subsection{Kprobes}
CONFIG\_KPROBES [=y] \textbf{[Y]}\\
Mit Kprobes können Sie an fast jeder Kerneladresse trappen und eine Callback-Funktion ausführen.
register\_kprobe() legt einen Probepoint fest und spezifiziert den Callback.
Kprobes ist nützlich für Kernel-Debugging, nicht-intrusive Instrumentierung und Tests.\\
Im Zweifelsfall sagen Sie "N".

\subsection{Optimize very unlikely/likely branches}
CONFIG\_JUMP\_LABEL [=y] \textbf{[Y]}\\
Diese Option ermöglicht eine transparente Verzweigungsoptimierung, die die Ausführung bestimmter
fast-immer-wahrer oder fast-immer-falscher Verzweigungsbedingungen im Kernel noch billiger macht.
Bestimmte leistungsempfindliche Kernel-Codes wie Trace-Points, Scheduler-Funktionen, Netzwerk-Code
und KVM haben solche Verzweigungen und bieten Unterstützung für diese Optimierungstechnik.
Wenn festgestellt wird, dass der Compiler \glqq asm goto\grqq{} unterstützt, kompiliert der Kernel
solche Verzweigungen mit einer einfachen nop-Anweisung. Wenn das Bedingungsflag auf true gesetzt wird,
wird der nop-Befehl in einen Sprungbefehl umgewandelt, um den bedingten Befehlsblock auszuführen.
Diese Technik senkt den Overhead und die Belastung der Verzweigungsvorhersage des Prozessors und macht
den Kernel im Allgemeinen schneller. Die Aktualisierung der Bedingung ist zwar langsamer, aber das
kommt immer sehr selten vor. (Bei 32-Bit-x86 können die erforderlichen Optionen, die zu den
Compiler-Flags hinzugefügt werden, die Größe des Kernels leicht erhöhen).

\subsubsection{Static key selftest}
CONFIG\_STATIC\_KEYS\_SELFTEST [=n] \textbf{[N]}\\
Bootzeit-Selbsttest des Branch-Patching-Codes.

\subsection{Static call selftest}
CONFIG\_STATIC\_CALL\_SELFTEST [=n] \textbf{[N]}\\
Bootzeit-Selbsttest des Call-Patching-Codes.

\subsection{Enable seccomp to safely execute untrusted bytecode}
CONFIG\_SECCOMP [=n] \textbf{[N]}\\
Diese Kernel-Funktion ist nützlich für numerische Anwendungen, die während ihrer Ausführung
mit nicht vertrauenswürdigem Bytecode umgehen müssen. Durch die Verwendung von Pipes oder anderen
Transporten, die dem Prozess als Dateideskriptoren zur Verfügung gestellt werden und die
Lese-/Schreib-Syscalls unterstützen, ist es möglich, diese Anwendungen mit seccomp in ihrem eigenen
Adressraum zu isolieren. Sobald seccomp über prctl(PR\_SET\_SECCOMP) oder den seccomp()-Syscall
aktiviert ist, kann es nicht mehr deaktiviert werden, und die Task darf nur einige wenige sichere
Syscalls ausführen, die für jeden seccomp-Modus definiert sind. Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{Show seccomp filter cache status in /proc/pid/seccomp\_cache}
CONFIG\_SECCOMP\_CACHE\_DEBUG [=n] \textbf{[N]}\\
Dies ermöglicht der Schnittstelle /proc/pid/seccomp\_cache die Überwachung der
seccomp-Cache-Daten. Das Dateiformat kann sich ändern. Zum Lesen der Datei ist
CAP\_SYS\_ADMIN erforderlich. Diese Option ist nur zur Fehlersuche gedacht.
Die Aktivierung birgt das Risiko, dass ein Angreifer die seccomp-Filterlogik ableiten kann.\\
Wenn Sie unsicher sind, sagen Sie N.

\subsection{Stack Protector buffer overflow detection}
CONFIG\_STACKPROTECTOR [=y] \textbf{[Y]}\\
Diese Option schaltet die GCC-Funktion \glqq stack-protector\grqq{} ein.
Diese Funktion legt am Anfang von Funktionen einen Canary-Wert (Kanarienvogelwert) auf den
Stack kurz vor der
Rücksprungadresse und überprüft den Wert kurz vor der eigentlichen Rückkehr. Stack-basierte
Pufferüberläufe (die diese Rücksprungadresse überschreiben müssen) überschreiben nun auch den
Canary-Wert, was erkannt wird und der Angriff wird dann durch eine Kernel-Panik neutralisiert.
Bei Funktionen, die ein 8-Byte- oder größeres Zeichenarray auf dem Stack haben, wird die Logik
des Stack-Protector-Canarys hinzugefügt. Diese Funktion erfordert gcc Version 4.2 oder höher,
oder eine gcc-Distribution, die die Funktion zurückportiert hat (\texttt{-fstack-protector}).
Auf einem x86-\glqq defconfig\grqq{}-Build fügt diese Funktion Canary-Prüfungen zu etwa
3\% aller Kernel-Funktionen hinzu, was die Kernel-Codegröße um etwa 0,3\% erhöht.

\subsubsection{Strong Stack Protector}
CONFIG\_STACKPROTECTOR\_STRONG [=y] \textbf{[Y]}\\
Bei Funktionen wird die Stack-Protector-Canary-Logik unter einer der folgenden Bedingungen hinzugefügt:
\begin{itemize}
\item[-] die Adresse einer lokalen Variablen wird als Teil der rechten Seite einer Zuweisung oder eines
Funktionsarguments verwendet
\item[-] die lokale Variable ist ein Array (oder eine Union, die ein Array enthält), unabhängig von Typ oder Länge des Arrays
\item[-] Lokale Variablen werden als Register verwendet
\end{itemize}
Diese Funktion erfordert gcc Version 4.9 oder höher, oder eine gcc-Distribution, die die Funktion
zurück\-por\-tiert hat (\texttt{-fstack-protector-strong}).
Auf einem x86-\glqq defconfig\grqq{}-Build fügt diese Funktion Canary-Prüfungen zu etwa 20\% aller
Kernel-Funktionen hinzu, was die Größe des Kernel-Codes um etwa 2\% erhöht.

\subsection{Link Time Optimization (LTO) () \texorpdfstring{$\rightarrow$}{->}}

\subsubsection{None}
CONFIG\_LTO\_NONE [=y] \textbf{[Y]}\\
Erstellen Sie den Kernel normal, ohne Link Time Optimization (LTO).

\subsection{Provide system calls for 32-bit time\_t}
CONFIG\_COMPAT\_32BIT\_TIME [=y] \textbf{[Y]}\\
Dies ermöglicht die Unterstützung von 32 Bit time\_t zusätzlich zur Unterstützung von
64~Bit time\_t. Dies ist auf allen 32-Bit-Architekturen und 64-Bit-Architekturen als Teil
der Kompatibilitäts-Syscall-Behandlung relevant.

\subsection{Use a virtually-mapped stack}
CONFIG\_VMAP\_STACK [=y] \textbf{[Y]}\\
Aktivieren Sie dies, wenn Sie virtuell gemappte Kernel-Stacks mit Guard Pages verwenden wollen.
Dies führt dazu, dass Kernel-Stack-Überläufe sofort abgefangen werden und keine schwer zu
diagnostizierende Korruption verursachen. Um dies mit Software-KASAN-Modi zu verwenden, muss die
Architektur die Unterstützung von virtuellen Mappings mit echtem Schattenspeicher unterstützen
und KASAN\_VMALLOC muss aktiviert sein.

\subsection{Support for randomizing kernel stack offset on syscall entry}
CONFIG\_RANDOMIZE\_KSTACK\_OFFSET [=y] \textbf{[Y]}\\
Der Kernel-Stack-Offset kann (nach pt\_regs) mit etwa 5~Bits Entropie randomisiert werden,
wodurch Angriffe auf Speicherbeschädigung vereitelt werden, die auf Stack-Adress-Determinismus
oder auf die Offenlegung der Adressen von Cross-Syscalls angewiesen sind.
Die Funktion wird über den Kernel-Boot-Parameter \texttt{randomize\_kstack\_offset=on/off} gesteuert
und hat, wenn sie ausgeschaltet ist, aufgrund der Verwendung von statischen Verzweigungen
(siehe JUMP\_LABEL) keinen Overhead.\\
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{Default state of kernel stack offset randomization}
CONFIG\_RANDOMIZE\_KSTACK\_OFFSET\_DEFAULT [=y] \textbf{[Y]}\\
Die Randomisierung des Kernel-Stack-Offsets wird durch den Kernel-Boot-Parameter\\
\texttt{randomize\_kstack\_offset=on/off} gesteuert, und diese Konfiguration wählt den
Standard-Boot-Status.

\subsection{Locking event counts collection}
CONFIG\_LOCK\_EVENT\_COUNTS [=y] \textbf{[Y]}\\
Ermöglicht eine leichtgewichtige Zählung verschiedener sperrungsbezogener Ereignisse im System
mit minimalen Auswirkungen auf die Leistung. Dies verringert die Wahrscheinlichkeit, dass sich
das Anwendungsverhalten aufgrund von Zeitunterschieden ändert. Die Zählungen werden über
debugfs gemeldet.

\subsection{GCOV-based kernel profiling \texorpdfstring{$\rightarrow$}{->}}
(GCOV-basierte Kernel-Profilierung)

\subsubsection{Enable gcov-based kernel profiling}
CONFIG\_GCOV\_KERNEL [=n] \textbf{[N]}\\
Diese Option aktiviert die gcov-basierte Code-Profilierung (z.~B. für Code-Abdeckungsmessungen).
Wenn Sie unsicher sind, sagen Sie N.\\[.5em]
Geben Sie zusätzlich CONFIG\_GCOV\_PROFILE\_ALL=y an, um Profilerstellungsdaten für den gesamten
Kernel zu erhalten. Um die Profilerstellung für bestimmte Dateien oder Verzeichnisse zu aktivieren,
fügen Sie eine Zeile ähnlich der folgenden in das jeweilige Makefile ein:\\[.5em]
Für eine einzelne Datei (z.~B. main.o):\\
\indent \texttt{GCOV\_PROFILE\_main.o := y}\\[.5em]
Für alle Dateien in einem Verzeichnis:\\
\indent \texttt{GCOV\_PROFILE := y}\\[.5em]
Um Dateien von der Profilerstellung auszuschließen, auch wenn CONFIG\_GCOV\_PROFILE\_ALL
angegeben ist, verwenden Sie:\\
\indent \texttt{GCOV\_PROFILE\_main.o := n}\\[.5em]
und:\\
\indent \texttt{GCOV\_PROFILE := n}\\[.5em]
Beachten Sie, dass das debugfs-Dateisystem gemountet sein muss, um auf die Profilerstellungsdaten
zugreifen zu können.

\subsection{GCC plugins \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_GCC\_PLUGINS [=y] \textbf{[Y]}\\
GCC-Plugins sind ladbare Module, die zusätzliche Funktionen für den Compiler bereitstellen.
Sie sind nützlich für die Laufzeitinstrumentierung und die statische Analyse.\\
Siehe Documentation/kbuild/gcc-plugins.rst für Details.

\subsubsection{Generate some entropy during boot and runtime}
CONFIG\_GCC\_PLUGIN\_LATENT\_ENTROPY [=n] \textbf{[N]}\\
Mit der Eingabe von Y wird der Kernel einen Teil des Kernel-Codes instrumentieren,
um sowohl aus dem ursprünglichen als auch aus dem künstlich erzeugten Programmzustand
etwas Entropie zu gewinnen.
Dies ist insbesondere bei eingebetteten Systemen hilfreich, bei denen es normalerweise wenig
\glqq natürliche\grqq{} Entropiequellen gibt.
Der Preis ist eine gewisse Verlangsamung des Boot-Prozesses (etwa 0,5~\%) und der fork- und
irq-Verarbeitung. Beachten Sie, dass die auf diese Weise extrahierte Entropie nicht
kryptografisch sicher ist!\\
Dieses Plugin wurde von grsecurity/PaX portiert. Mehr Informationen unter:
 \begin{itemize}
	\item[] \url{https://grsecurity.net/}
	\item[] \url{https://pax.grsecurity.net/}
 \end{itemize}


\section{Enable loadable module support \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_MODULES [=y] \textbf{[Y]}\\
Kernel-Module sind kleine Stücke kompilierten Codes, die in den laufenden Kernel eingefügt werden können,
anstatt dauerhaft in den Kernel eingebaut zu werden. Sie verwenden das Werkzeug
\texttt{modprobe}, um sie hinzuzufügen (und manchmal zu entfernen).\\
Wenn Sie hier Y angeben, können viele Teile des Kernels als Module gebaut werden (indem Sie M anstelle
von Y antworten, wo dies angegeben ist):\\
Dies ist besonders nützlich für selten verwendete Optionen, die zum Booten nicht benötigt werden.
Weitere Informationen finden Sie in den Man Pages für \texttt{modprobe},
\texttt{lsmod}, \texttt{modinfo}, \texttt{insmod} und \texttt{rmmod}.\\
Wenn Sie hier Y angeben, müssen Sie \texttt{make modules\_install} ausführen, um die Module unter\\
/lib/modules/ abzulegen, wo sie von modprobe gefunden werden können (möglicherweise müssen Sie dazu
root sein).
Wenn Sie unsicher sind, sagen Sie Y.

\subsection{Module debugging}
CONFIG\_MODULE\_DEBUG [=n] \textbf{[N]}\\
Ermöglicht das Aktivieren/Deaktivieren von Funktionen, die Ihnen beim Debuggen von Modulen helfen können.
Auf Produktionssystemen benötigen Sie diese Optionen nicht.

\subsection{Forced module loading}
CONFIG\_MODULE\_FORCE\_LOAD [=y] \textbf{[Y]}\\
Erlaubt das Laden von Modulen ohne Versionsinformationen (z.~B. \texttt{modprobe --force}).
Erzwungenes Laden von Modulen setzt das `F' (forced) taint Flag und ist normalerweise eine wirklich
schlechte Idee.

\subsection{Module unloading}
CONFIG\_MODULE\_UNLOAD [=y] \textbf{[Y]}\\
Ohne diese Option können Sie keine Module entladen (beachten Sie, dass einige Module möglicherweise
ohnehin nicht entladbar sind), was Ihren Kernel kleiner, schneller und einfacher macht.
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{Forced module unloading}
CONFIG\_MODULE\_FORCE\_UNLOAD [=y] \textbf{[Y]}\\
Mit dieser Option können Sie das Entladen eines Moduls erzwingen, auch wenn der Kernel es für unsicher
hält: Der Kernel wird das Modul entfernen, ohne darauf zu warten, dass jemand die Verwendung des Moduls
beendet (mit der Option \texttt{-f} von \texttt{rmmod}).
Dies ist hauptsächlich für Kernel-Entwickler und verzweifelte Benutzer gedacht. Wenn Sie unsicher sind,
sagen Sie N.

\subsubsection{Tainted module unload tracking}
CONFIG\_MODULE\_UNLOAD\_TAINT\_TRACKING [=y] \textbf{[Y]}\\
Mit dieser Option können Sie eine Aufzeichnung über jedes entladene Modul führen, das den Kernel
beschädigt hat. Zusätzlich zur Anzeige einer Liste der verknüpften (oder geladenen) Module, z.~B.
bei der Erkennung einer schlechten Seite (siehe bad\_page()), werden auch die oben genannten
Details angezeigt. Wenn Sie unsicher sind, sagen Sie N.

\subsection{Module versioning support}
CONFIG\_MODVERSIONS [=n] \textbf{[N]}\\
Normalerweise müssen Sie Module verwenden, die mit Ihrem Kernel kompiliert wurden. Wenn Sie
hier Y angeben, ist es manchmal möglich, Module zu verwenden, die für andere Kernel kompiliert wurden,
indem Sie genügend Informationen zu den Modulen hinzufügen, um (hoffentlich) alle Änderungen zu erkennen,
die sie mit dem von Ihnen verwendeten Kernel inkompatibel machen würden.\\
Wenn Sie unsicher sind, sagen Sie N.

\subsection{Source checksum for all modules}
CONFIG\_MODULE\_SRCVERSION\_ALL [=y] \textbf{[Y]}\\
Module, die eine MODULE\_VERSION enthalten, bekommen ein zusätzliches \glqq srcversion\grqq{}-Feld in
ihre modinfo-Sektion eingefügt, das eine Summe der Quelldateien enthält, aus denen sie entstanden sind.
Dies hilft den Betreuern, genau zu sehen, welche Quelle verwendet wurde, um ein Modul zu bauen
(da andere manchmal die Modulquelle ändern, ohne die Version zu aktualisieren). Mit dieser Option wird
ein solches \glqq srcversion\grqq{}-Feld für alle Module erstellt. Wenn Sie unsicher sind, sagen Sie N.

\subsection{Module signature verification}
CONFIG\_MODULE\_SIG [=y] \textbf{[Y]}\\
Überprüfung von Modulen auf gültige Signaturen beim Laden: Die Signatur wird einfach an das Modul
angehängt. Für weitere Informationen siehe $<$file:Documentation/admin-guide/module-signing.rst$>$.
Beachten Sie, dass diese Option die OpenSSL-Entwicklungspakete als Kernel-Build-Abhängigkeit hinzufügt,
so dass das Signierwerkzeug seine Krypto-Bibliothek verwenden kann. Sie sollten diese Option aktivieren,
wenn Sie entweder CONFIG\_SECURITY\_LOCKDOWN\_LSM oder eine durch eine andere LSM auferlegte
Lockdown-Funktionalität verwenden wollen -- andernfalls werden unsignierte Module unabhängig von der
Lockdown-Policy ladbar sein.
!!!WARNUNG!!! Wenn Sie diese Option aktivieren, MÜSSEN Sie sicherstellen, dass das Modul nach dem
Signieren NICHT gestrippt wird. Dies schließt den Debuginfo-Strip ein, der von einigen Paketierern
(wie z.~B. rpmbuild) durchgeführt wird, sowie die Einbindung in ein initramfs, das die Modulgröße
reduzieren möchte.

\subsubsection{Require modules to be validly signed}
CONFIG\_MODULE\_SIG\_FORCE [=n] \textbf{[N]}\\
Ablehnung von unsignierten Modulen oder signierten Modulen, für die wir keinen Schlüssel haben.
Ohne diesen Schlüssel werden solche Module den Kernel einfach verunreinigen.

\subsubsection{Automatically sign all modules}
CONFIG\_MODULE\_SIG\_ALL [=y] \textbf{[Y]}\\
Signiere alle Module während make modules\_install. Ohne diese Option müssen die Module manuell
signiert werden, und zwar mit dem Werkzeug scripts/sign-file.

\subsection{Which hash algorithm should modules be signed with? () \texorpdfstring{$\rightarrow$}{->}}
Damit wird festgelegt, welche Art von Hashing-Algorithmus bei der Signaturerstellung verwendet wird.
Dieser Algorithmus \textbf{muss} direkt in den Kernel eingebaut werden, damit eine Signaturprüfung
stattfinden kann. Es ist nicht möglich, ein signiertes Modul zu laden, das den Algorithmus enthält,
um die Signatur dieses Moduls zu überprüfen.

\subsubsection{Sign modules with SHA-1}
CONFIG\_MODULE\_SIG\_SHA1 [=n] \textbf{[N]}\\
\textit{Für diese Option gibt es keine Hilfe.}
\subsubsection{Sign modules with SHA-224}
CONFIG\_MODULE\_SIG\_SHA224 [=n] \textbf{[N]}\\
\textit{Für diese Option gibt es keine Hilfe.}
\subsubsection{Sign modules with SHA-256}
CONFIG\_MODULE\_SIG\_SHA256 [=n] \textbf{[N]}\\
\textit{Für diese Option gibt es keine Hilfe.}
\subsubsection{Sign modules with SHA-384}
CONFIG\_MODULE\_SIG\_SHA384 [=n] \textbf{[N]}\\
\textit{Für diese Option gibt es keine Hilfe.}
\subsubsection{Sign modules with SHA-512}
CONFIG\_MODULE\_SIG\_SHA512 [=y] \textbf{[Y]}\\
\textit{Für diese Option gibt es keine Hilfe.}


\subsection{Module compression mode}
Mit dieser Option können Sie den Algorithmus auswählen, der zur Komprimierung von Modulen verwendet
wird, wenn \texttt{make modules\_install} ausgeführt wird. (oder Sie können wählen, dass Module
überhaupt nicht komprimiert werden.) Externe Module werden während der Installation ebenfalls auf
die gleiche Weise komprimiert. Für Module innerhalb einer initrd oder initramfs ist es effizienter,
stattdessen die gesamte initrd oder initramfs zu komprimieren. Dies ist vollständig kompatibel mit
signierten Modulen. Bitte beachten Sie, dass das zum Laden von Modulen verwendete Werkzeug den
entsprechenden Algorithmus unterstützen muss. module-init-tools KANN gzip unterstützen, und kmod KANN
gzip, xz und zstd unterstützen.
Ihr Build-System muss das entsprechende Komprimierungswerkzeug bereitstellen, um die Module zu
komprimieren. Im Zweifelsfall wählen Sie `None'.

\subsubsection{None}
CONFIG\_MODULE\_COMPRESSION\_NONE [=n] \textbf{[N]}\\
Komprimieren Sie die Module nicht. Die installierten Module sind mit der Endung .ko versehen.
\subsubsection{GZIP}
CONFIG\_MODULE\_COMPRESSION\_GZIP [=n] \textbf{[N]}\\
Komprimieren Sie Module mit GZIP. Die installierten Module sind mit der Endung .ko.gz versehen.
\subsubsection{XZ}
CONFIG\_MODULE\_COMPRESSION\_XZ [=n] \textbf{[N]}\\
Komprimieren Sie Module mit XZ. Die installierten Module sind mit der Endung .ko.xz versehen.
\subsubsection{ZSTD}
CONFIG\_MODULE\_COMPRESS\_ZSTD [=y] \textbf{[Y]}\\
Komprimieren Sie Module mit ZSTD. Die installierten Module sind mit der Endung .ko.zst versehen.

\subsection{Support in-kernel module decompression}
CONFIG\_MODULE\_DECOMPRESS [=y] \textbf{[Y]}\\
Unterstützung für die Dekomprimierung von Kernelmodulen durch den Kernel selbst, anstatt sich auf
den Userspace zu verlassen, um diese Aufgabe zu erledigen. Nützlich, wenn die Sicherheitsrichtlinie
für das Load Pinning aktiviert ist. Wenn Sie unsicher sind, sagen Sie N.

\subsection{Allow loading of modules with missing namespace imports}
CONFIG\_MODULE\_ALLOW\_MISSING\_NAMESPACE\_IMPORTS [=y] \textbf{[Y]}\\
Symbole, die mit EXPORT\_SYMBOL\_NS*() exportiert werden, gelten als in einem Namespace exportiert.
Ein Modul, das ein Symbol verwendet, das mit einem solchen Namespace exportiert wurde, muss den
Namespace über MODULE\_IMPORT\_NS() importieren. Es gibt keinen technischen Grund, korrekte
Namespace-Importe zu erzwingen, aber es schafft Konsistenz zwischen Symbolen, die Namespaces
definieren und Benutzern, die Namespaces importieren, die sie verwenden. Diese Option lockert diese
Anforderung und hebt die Durchsetzung beim Laden eines Moduls auf. Wenn Sie unsicher sind, sagen Sie N.

\subsection{Path to modprobe binary}
CONFIG\_MODPROBE\_PATH [=/sbin/modprobe] \textbf{[/sbin/modprobe]}\\
Wenn der Kernel-Code ein Modul anfordert, geschieht dies durch den Aufruf des
User\-space-Dienst\-pro\-gramms
\texttt{modprobe}. Mit dieser Option können Sie den Pfad festlegen, in dem diese Binärdatei
zu finden ist. Dies kann zur Laufzeit über die sysctl-Datei /proc/sys/kernel/modprobe geändert werden.
Wenn Sie diese Option auf eine leere Zeichenkette setzen, wird die Fähigkeit des Kernels,
Module anzufordern, ausgeschaltet (der Userspace kann jedoch weiterhin explizit Module laden).

\section{Enable the block layer \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_BLOCK [=y] \textbf{[Y]}\\
Bietet dem Kernel Unterstützung für die Blockschicht.\\
Deaktivieren Sie diese Option, um die Unterstützung für die Blockschicht aus dem Kernel zu entfernen.
Dies kann für eingebettete Geräte nützlich sein.\\
Wenn diese Option deaktiviert ist:
\begin{itemize}
	\item[-] werden Blockgerätedateien unbrauchbar,
	\item[-] werden einige Dateisysteme (wie ext3) nicht mehr verfügbar.
\end{itemize}
Außerdem werden SCSI-Zeichengeräte und USB-Speicher deaktiviert, da sie verschiedene Definitionen und
Möglichkeiten der Blockschicht nutzen.\\
Sagen Sie hier "Y", es sei denn, Sie wissen, dass Sie wirklich keine Festplatten und dergleichen einbinden wollen.

\subsection{Legacy autoloading support}
CONFIG\_BLOCK\_LEGACY\_AUTOLOAD [=y] \textbf{[Y]}\\
Ermöglicht das Laden von Modulen und das Erstellen von Block-Geräteinstanzen auf der Grundlage
von Zugriffen durch ihre spezielle Gerätedatei. Dies ist ein historisches Linux-Feature und ergibt
in einer udev-Welt, in der Gerätedateien bei Bedarf erstellt werden, keinen Sinn, aber Skripte,
die manuell Geräteknoten erstellen und dann losetup aufrufen, könnten sich auf dieses Verhalten
verlassen.

\subsection{Block layer SG support v4 helper lib}
CONFIG\_BLK\_DEV\_BSGLIB [=y] \textbf{[Y]}\\
Die Teilsysteme werden dies normalerweise bei Bedarf aktivieren. Die Benutzer müssen dies normalerweise
nicht manuell aktivieren. Wenn Sie unsicher sind, sagen Sie N.

\subsection{Block layer data integrity support}
CONFIG\_BLK\_DEV\_INTEGRITY [=y] \textbf{[Y]}\\
Einige Speichermedien erlauben die Speicherung/Abrufung zusätzlicher Informationen, um die Daten zu
schützen. Die Option für die Datenintegrität auf Blockebene bietet Hooks, die von Dateisystemen verwendet
werden können, um eine bessere Datenintegrität zu gewährleisten. Sagen Sie hier Ja, wenn Sie ein
Speichergerät haben, das das T10/SCSI Data Integrity Field oder den T13/ATA External Path Protection
bietet. Im Zweifelsfall sagen Sie N.

\subsection{Zoned block device support}
CONFIG\_BLK\_DEV\_ZONED [=y] \textbf{[Y]}\\
Unterstützung von Blockebenen mit Zonen für Blockgeräte. Diese Option aktiviert die Unterstützung für
ZAC/ZBC/ZNS Host-verwaltete und Host-bewusste Zoned-Block-Geräte. Sagen Sie hier Ja, wenn Sie ein
ZAC-, ZBC- oder ZNS-Speichergerät haben.

\subsection{Block layer bio throttling support}
CONFIG\_BLK\_DEV\_THROTTLING [=y] \textbf{[Y]}\\
Unterstützung der Bio-Drosselung auf der Blockschicht. Sie kann verwendet werden, um die IO-Rate für
ein Gerät zu begrenzen. IO-Rate-Policies sind pro cgroup und man muss blkio cgroup controller mounten
und verwenden, um cgroups zu erstellen und IO-Rate-Policies pro Gerät festzulegen.\\
Siehe Documentation/admin-guide/cgroup-v1/blkio-controller.rst für weitere Informationen.

\subsubsection{Block throttling .low limit interface support (EXPERIMENTAL)}
CONFIG\_BLK\_DEV\_THROTTLING\_LOW [=y] \textbf{[Y]}\\
Hinzufügen der Schnittstelle .low limit für die Blockdrosselung. Das niedrige Limit ist ein
Best-Effort-Limit zur Priorisierung von C-Gruppen. Je nach Einstellung kann das Limit verwendet werden,
um C-Gruppen in Bezug auf Bandbreite/iops zu schützen und die Festplattenressourcen besser zu nutzen.\\
Beachten Sie, dass es sich hierbei um eine experimentelle Schnittstelle handelt, die eines Tages
geändert werden könnte.

\subsection{Enable support for block device writeback throttling}
CONFIG\_BLK\_WBT [=y] \textbf{[Y]}\\
Die Aktivierung dieser Option ermöglicht es der Blockschicht, gepufferte Hintergrund-Schreibvorgänge
der VM zu drosseln, so dass diese reibungsloser ablaufen und weniger Auswirkungen auf die
Vordergrundvorgänge haben. Die Drosselung erfolgt dynamisch nach einem Algorithmus, der lose auf
CoDel basiert und die Echtzeitleistung der Festplatte berücksichtigt.

\subsubsection{Enable writeback throttling by default}
CONFIG\_BLK\_WBT\_MQ [=y] \textbf{[Y]}\\
Aktivieren Sie die Rückschreibdrosselung standardmäßig für anforderungsbasierte Blockgeräte.

\subsection{Enable support for latency based cgroup IO protection}
CONFIG\_BLK\_CGROUP\_IOLATENCY [=y] \textbf{[Y]}\\
Durch die Aktivierung dieser Option wird die .latency-Schnittstelle für die IO-Drosselung aktiviert.
Der IO-Controller versucht, die durchschnittlichen IO-Latenzen unter dem konfigurierten Latenzziel
zu halten und drosselt jeden mit einem höheren Latenzziel als die betroffene Gruppe.\\
Beachten Sie, dass es sich hierbei um eine experimentelle Schnittstelle handelt,
die eines Tages geändert werden könnte.

\subsection{Enable support to track FC I/O Traffic across cgroup applications}
CONFIG\_BLK\_CGROUP\_FC\_APPID [=y] \textbf{[Y]}\\
Die Aktivierung dieser Option ermöglicht die Verfolgung des FC-I/O-Verkehrs über cgroup-Anwendungen
hinweg. Sie ermöglicht es der Fabric und den Speicherzielen, den FC-Verkehr auf der Grundlage von
VM-Tags zu identifizieren, zu überwachen und zu verarbeiten, indem eine anwendungsspezifische
Identifikation in den FC-Frame eingefügt wird.

\subsection{Enable support for cost model based cgroup IO controller}
CONFIG\_BLK\_CGROUP\_IOCOST [=y] \textbf{[Y]}\\
Durch Aktivieren dieser Option wird die .weight-Schnittstelle für die kostenmodellbasierte
proportionale IO-Steuerung aktiviert. Der IO-Controller verteilt die IO-Kapazität zwischen
verschiedenen Gruppen auf der Grundlage ihres Anteils an der Gesamtgewichtsverteilung.

\subsection{Cgroup I/O controller for assigning an I/O priority class}
CONFIG\_BLK\_CGROUP\_IOPRIO [=y] \textbf{[Y]}\\
Aktivieren Sie die Schnittstelle .prio, um Anfragen eine E/A-Prioritätsklasse zuzuweisen.
Die E/A-Prioritätsklasse beeinflusst die Reihenfolge, in der ein E/A-Scheduler und Blockgeräte
Anforderungen verarbeiten. Nur einige E/A-Scheduler und einige Blockgeräte unterstützen E/A-Prioritäten.

\subsection{Block layer debugging information in debugfs}
CONFIG\_BLK\_DEBUG\_FS [=y] \textbf{[Y]}\\
Aufnahme von Debugging-Informationen der Blockschicht in debugfs. Diese Informationen sind vor allem
für Kernel-Entwickler nützlich, aber sie verursachen keine Kosten zur Laufzeit. Wenn Sie nicht gerade
einen Kernel für ein winziges System bauen, sollten Sie hier Y für Ja sagen.

\subsection{Logic for interfacing with Opal enabled SEDs}
CONFIG\_BLK\_SED\_OPAL [=y] \textbf{[Y]}\\
Erstellt die Logik für die Verbindung mit Opal-fähigen Steuergeräten.
Die Aktivierung dieser Option ermöglicht es Benutzern, Sperrbereiche für SED-Geräte mit dem
Opal-Protokoll einzurichten/zu entsperren/zu sperren.

\subsection{Enable inline encryption support in block layer}
CONFIG\_BLK\_INLINE\_ENCRYPTION [=y] \textbf{[Y]}\\
Bauen Sie das blk-crypto-Subsystem auf. Wenn Sie dies aktivieren, kann die Blockschicht die
Verschlüsselung handhaben, so dass Benutzer die Vorteile der Inline-Verschlüsselungshardware
nutzen kön\-nen, falls vorhanden.

\subsubsection{Enable crypto API fallback for blk-crypto}
CONFIG\_BLK\_INLINE\_ENCRYPTION\_FALLBACK [=y] \textbf{[Y]}\\
Wenn dies aktiviert ist, kann die Blockschicht die Inline-Verschlüsselung handhaben, indem sie
auf die Kernel-Krypto-API zurückgreift, wenn keine Inline-Verschlüsselungshardware vorhanden ist.

\subsection{Partition Types \texorpdfstring{$\rightarrow$}{->}}
(Partitionstypen)

\subsubsection{Advanced partition selection}
CONFIG\_PARTITION\_ADVANCED [=y] \textbf{[Y]}\\
Geben Sie hier Y ein, wenn Sie unter Linux Festplatten verwenden möchten, die unter einem Betriebssystem
partitioniert wurden, das auf einer anderen Architektur als Ihr Linux-System läuft.\\
Beachten Sie, dass sich die Antwort auf diese Frage nicht direkt auf den Kernel auswirkt:
Wenn Sie N angeben, überspringt der Konfigurator lediglich alle Fragen zu fremden
Partitionierungsschemata. Wenn Sie unsicher sind, sagen Sie N.

\paragraph{Acorn partition support}$~$\\
CONFIG\_ACORN\_PARTITION [=n] \textbf{[N]}\\
Unterstützung von Festplatten, die unter Acorn-Betriebssystemen partitioniert sind.

\paragraph{AIX basic partition table support}$~$\\
CONFIG\_AIX\_PARTITION [=y] \textbf{[Y]}\\
Geben Sie hier Y ein, wenn Sie das Format der Festplattenpartitionstabelle lesen möchten, das
von IBM- oder Motorola-PowerPC-Maschinen unter AIX verwendet wird. AIX verwendet eigentlich
einen Logical Volume Manager, bei dem \glqq logische Volumes\grqq{} über eine oder mehrere
Festplatten verteilt sein können, aber dieser Treiber funktioniert nur für den einfachen Fall
von zusammenhängenden Partitionen. Andernfalls, sagen wir N.

\paragraph{Alpha OSF partition support}$~$\\
CONFIG\_OSF\_PARTITION [=n] \textbf{[N]}\\
Geben Sie hier Y an, wenn Sie unter Linux Festplatten verwenden möchten, die auf einer
Alpha-Maschine partitioniert wurden.

\paragraph{Amiga partition table support}$~$\\
CONFIG\_AMIGA\_PARTITION [=n] \textbf{[N]}\\
Sagen Sie hier Y, wenn Sie unter Linux Festplatten verwenden möchten, die unter AmigaOS
partitioniert wurden.

\paragraph{Atari partition table support}$~$\\
CONFIG\_ATARI\_PARTITION [=n] \textbf{[N]}\\
Sagen Sie hier Y, wenn Sie unter Linux Festplatten verwenden möchten, die unter dem
Atari-Betriebs\-sys\-tem partitioniert wurden.

\paragraph{Macintosh partition map support}$~$\\
CONFIG\_MAC\_PARTITION [=y] \textbf{[Y]}\\
Sagen Sie hier Y, wenn Sie unter Linux Festplatten verwenden möchten, die auf einem
Macintosh partitioniert wurden.

\paragraph{PC BIOS (MSDOS partition tables) support}$~$\\
CONFIG\_MSDOS\_PARTITION [=y] \textbf{[Y]}\\
Sagen Sie hier Y.

\subparagraph{BSD disklabel (FreeBSD partition tables) support}$~$\\
CONFIG\_BSD\_DISKLABEL [=y] \textbf{[Y]}\\
FreeBSD verwendet ein eigenes Partitionsschema für die Festplatten Ihres PCs. Es benötigt nur
einen Eintrag in der primären Partitionstabelle Ihrer Festplatte und verwaltet diese ähnlich
wie erweiterte DOS-Partitionen, indem es im ersten Sektor eine neue Partitionstabelle im
BSD-Disklabel-Format anlegt. Wenn Sie hier Y angeben, können Sie diese Disklabels lesen und
FreeBSD-Partitionen von Linux aus einbinden, wenn Sie oben bei \glqq UFS file system support\grqq{}
ebenfalls Y angegeben haben. Wenn Sie nicht wissen, was das alles soll, sagen Sie N.

\subparagraph{Minix subpartition support}$~$\\
CONFIG\_MINIX\_SUBPARTITION [=y] \textbf{[Y]}\\
Unterstützung von Minix 2.0.0/2.0.2 Subpartitionstabellen für Linux. Sagen Sie hier Y,
wenn Sie Minix 2.0.0/2.0.2 Subpartitionen mounten und verwenden wollen.

\subparagraph{Solaris (x86) partition table support}$~$\\
CONFIG\_SOLARIS\_X86\_PARTITION [=y] \textbf{[Y]}\\
Wie die meisten Systeme verwendet Solaris x86 ein eigenes Festplattenpartitionstabellenformat,
das mit allen anderen nicht kompatibel ist. Wenn Sie hier Y angeben, können Sie diese
Partitionstabellen lesen und Solaris x86-Partitionen von Linux aus einbinden, wenn Sie oben bei
\glqq UFS-Dateisystemunterstützung\grqq{} ebenfalls Y angegeben haben.

\subparagraph{Unixware slices support}$~$\\
CONFIG\_UNIXWARE\_DISKLABEL [=n] \textbf{[N]}\\
Wie einige Systeme verwendet auch UnixWare eine eigene Slice-Tabelle innerhalb einer Partition
(VTOC -- Virtual Table of Contents). Ihr Format ist mit allen anderen Betriebssystemen nicht
kompatibel. Wenn Sie hier Y angeben, können Sie VTOC lesen und UnixWare-Partitionen von Linux
aus schreibgeschützt einbinden, wenn Sie oben auch Y zu \glqq UFS-Dateisystemunterstützung\grqq{}
oder \glqq System V und Coherent-Dateisystemunterstützung\grqq{} angegeben haben.
Dies wird hauptsächlich verwendet, um Daten von einem UnixWare-Rechner auf Ihren Linux-Rechner
zu übertragen, und zwar über ein Wechselmedium wie magneto-optische, ZIP- oder IDE-Wechselplatten.
Beachten Sie jedoch, dass das Programm \texttt{tar} (\texttt{man tar} oder vorzugsweise
\texttt{info tar}) eine gute Möglichkeit bietet, Dateien und Verzeichnisse zwischen Unixen
(und sogar anderen Betriebssystemen) zu transportieren.
Wenn Sie nicht wissen, was das alles soll, sagen Sie N.

\paragraph{Windows Logical Disk Manager (Dynamic Disk) support}$~$\\
CONFIG\_LDM\_PARTITION [=y] \textbf{[Y]}\\
Sagen Sie hier Y, wenn Sie unter Linux Festplatten verwenden möchten, die mit dem Logical Disk Manager
von Windows 2000/XP oder Vista partitioniert wurden. Sie werden auch als
\glqq dynamische Festplatten\grqq{} bezeichnet.\\
Beachten Sie, dass dieser Treiber nur dynamische Festplatten mit einem schützenden MBR-Label,
d.h. einer DOS-Partitionstabelle, unterstützt. Dynamische Festplatten mit GPT-Label, wie sie mit Vista
erstellt werden können, werden noch nicht unterstützt. Windows 2000 führte das Konzept der
dynamischen Festplatten ein, um die Einschränkungen des PC-Partitionierungsschemata zu umgehen.
Der Logical Disk Manager ermöglicht es dem Benutzer, eine Festplatte neu zu partitionieren und
übergreifende, gespiegelte, striped oder RAID-Volumes zu erstellen, ohne dass ein Neustart
erforderlich ist. Normale Partitionen werden nun unter Windows 2000, XP und Vista als Basisfestplatten
bezeichnet.\\
Für eine ausführlichere Beschreibung lesen Sie $<$file:Documentation/admin-guide/ldm.rst$>$.\\
Wenn Sie unsicher sind, sagen Sie N.

\subparagraph{Windows LDM extra logging}$~$\\
CONFIG\_LDM\_DEBUG [=n] \textbf{[N]}\\
Geben Sie hier Y an, wenn Sie möchten, dass LDM ausführlich protokolliert.
Dies könnte hilfreich sein, wenn der Treiber nicht wie erwartet funktioniert und Sie einen Fehler
melden möchten. Wenn Sie unsicher sind, sagen Sie N.

\paragraph{SGI partition support}$~$\\
CONFIG\_SGI\_PARTITION [=n] \textbf{[N]}\\
Wählen Sie hier Y, wenn Sie das von SGI-Maschinen verwendete Format der
Festplattenpartitionstabelle lesen möchten.

\paragraph{Ultrix partition table support}$~$\\
CONFIG\_ULTRIX\_PARTITION [=n] \textbf{[N]}\\
Sagen Sie hier Y, wenn Sie das von DEC (jetzt Compaq) Ultrix-Maschinen verwendete Format der
Festplattenpartitionstabelle lesen möchten. Andernfalls sagen Sie N.

\paragraph{Sun partition tables support}$~$\\
CONFIG\_SUN\_PARTITION [=n] \textbf{[N]}\\
Wie die meisten Systeme verwendet SunOS ein eigenes Format für Festplattenpartitionstabellen,
das mit allen anderen nicht kompatibel ist.
Wenn Sie hier Y angeben, können Sie diese Partitionstabellen lesen und SunOS-Partitionen von Linux aus
einbinden, wenn Sie oben bei \glqq UFS-Dateisystemunterstützung\grqq{} ebenfalls Y angegeben haben.
Dies wird hauptsächlich benutzt, um Daten von einem SPARC unter SunOS zu Ihrem Linux-Rechner über ein
Wechselmedium wie magneto-optische oder ZIP-Laufwerke zu transportieren; beachten Sie jedoch, dass ein
guter portabler Weg, Dateien und Verzeichnisse zwischen Unixen (und sogar anderen Betriebssystemen) zu
transportieren, durch das \texttt{tar}-Programm (\texttt{man tar} oder vorzugsweise
\texttt{info tar}) gegeben ist. Wenn Sie nicht wissen, was das alles soll, sagen Sie N.

\paragraph{Karma Partition support}$~$\\
CONFIG\_KARMA\_PARTITION [=y] \textbf{[Y]}\\
Sagen Sie hier Y, wenn Sie den Rio Karma MP3-Player mounten möchten, da dieser eine
proprietäre Partitionstabelle verwendet.

\paragraph{EFI GUID Partition support}$~$\\
CONFIG\_EFI\_PARTITION [=y] \textbf{[Y]}\\
Geben Sie hier Y an, wenn Sie unter Linux Festplatten verwenden möchten,
die mit EFI GPT partitioniert wurden.

\paragraph{SYSV68 partition table support}$~$\\
CONFIG\_SYSV68\_PARTITION [=n] \textbf{[N]}\\
Geben Sie hier Y ein, wenn Sie das von Motorola-Delta-Maschinen verwendete Format der
Festplattenpartitionstabelle lesen möchten (unter Verwendung von sysv68). Andernfalls sagen Sie N.

\paragraph{Command line partition support}$~$\\
CONFIG\_CMDLINE\_PARTITION [=n] \textbf{[N]}\\
Sagen Sie hier Y, wenn Sie die Partitionstabelle aus bootargs lesen wollen. Das Format für die
Kommandozeile ist genau wie bei mtdparts.

\subsection{IO Schedulers \texorpdfstring{$\rightarrow$}{->}}
(E/A-Zeitplaner)

\subsubsection{MQ deadline I/O scheduler}
CONFIG\_MQ\_IOSCHED\_DEADLINE [=y] \textbf{[Y]}\\
MQ-Version des Deadline-IO-Schedulers.

\subsubsection{Kyber I/O scheduler}
CONFIG\_MQ\_IOSCHED\_KYBER [=m] \textbf{[M]}\\
Der Kyber E/A-Scheduler ist ein Scheduler mit geringem Aufwand, der sich für Multiqueue- und andere
schnelle Geräte eignet. Bei vorgegebenen Ziellatenzen für Lese- und synchrone Schreibvorgänge passt
er die Tiefe der Warteschlangen selbst an, um dieses Ziel zu erreichen.

\subsubsection{BFQ I/O scheduler}
CONFIG\_IOSCHED\_BFQ [=y] \textbf{[Y]}\\
BFQ E/A-Scheduler für BLK-MQ. BFQ verteilt die Bandbreite des Geräts auf alle Prozesse entsprechend
ihrer Gewichtung, unabhängig von den Geräteparametern und bei jeder Arbeitslast. Es garantiert auch
eine niedrige Latenzzeit für interaktive und weiche Echtzeitanwendungen.\\
Weitere Details in Dokumentation/block/bfq-iosched.rst

\paragraph{BFQ hierarchical scheduling support}$~$\\
CONFIG\_BFQ\_GROUP\_IOSCHED [=y] \textbf{[Y]}\\
Aktivierung der hierarchischen Zeitplanung in BFQ unter Verwendung des blkio (cgroupss-v1)
oder io (cgroupss-v2) Controllers.

\subparagraph{BFQ IO controller debugging}$~$\\
CONFIG\_BFQ\_CGROUP\_DEBUG [=n] \textbf{[N]}\\
Aktivierung einer Hilfe zur Fehlersuche.
Derzeit werden zusätzliche Statistikdateien in einer cgroup exportiert, die für die Fehlersuche
nützlich sein können.

\section{Executable file formats \texorpdfstring{$\rightarrow$}{->}}
(Ausführbare Dateiformate)

\subsection{Kernel support for ELF binaries}
CONFIG\_BINFMT\_ELF [=y] \textbf{[Y]}\\
ELF (Executable and Linkable Format) ist ein Format für Bibliotheken und ausführbare Dateien,
das auf verschiedenen Architekturen und Betriebssystemen verwendet wird.
Wenn Sie hier Y angeben, kann Ihr Kernel ELF-Binärdateien ausführen und wird um etwa 13 KB vergrößert.
Die ELF-Unterstützung unter Linux hat inzwischen die traditionellen Linux a.out-Formate (QMAGIC und ZMAGIC)
fast vollständig ersetzt, da es portabel ist (was jedoch *nicht* bedeutet, dass Sie ausführbare Dateien
von verschiedenen Architekturen oder Betriebssystemen ausführen können) und die Erstellung von
Laufzeitbibliotheken sehr einfach macht. Viele neue ausführbare Dateien werden ausschließlich im
ELF-Format vertrieben. Hier sollten Sie unbedingt Y sagen. Informationen über ELF sind im ELF HOWTO
enthalten, das unter \url{http://www.tldp.org/docs.html#howto} verfügbar ist.
Wenn Sie feststellen, dass Sie nach dem Upgrade von Linux-Kernel 1.2 und der Angabe von Y hier immer
noch keine ELF-Binärdateien ausführen können (sie stürzen einfach ab), dann müssen Sie die neuesten
ELF-Laufzeitbibliotheken installieren, einschließlich \texttt{ld.so} (überprüfen Sie die Datei
$<$file:Documentation/Changes$>$ für den Ort und die neueste Version).

\subsection{Write ELF core dumps with partial segments}
CONFIG\_CORE\_DUMP\_DEFAULT\_ELF\_HEADERS [=y] \textbf{[Y]}\\
ELF-Core-Dump-Dateien beschreiben jede Speicherabbildung des abgestürzten Prozesses und können den
Speicherinhalt jedes einzelnen Prozesses enthalten oder auslassen. Der Inhalt eines unveränderten
Text-Mappings wird standardmäßig weggelassen. Bei einem unveränderten Text-Mapping eines ELF-Objekts
ermöglicht die Aufnahme nur der ersten Seite der Datei in einen Core-Dump die Identifizierung der
Build-ID-Bits in der Datei, ohne dass die E/A-Kosten und der Plattenplatz für das Dump des gesamten
Textes anfallen. Versionen von GDB vor 6.7 werden jedoch von ELF-Core-Dump-Dateien in diesem Format
verwirrt. Das Verhalten des Kerndumps kann pro Prozess mit der Pseudodatei /proc/PID/coredump\_filter
gesteuert werden; diese Einstellung wird vererbt.
Siehe Dokumentation/filesystems/proc.rst für Details.
Diese Konfigurationsoption ändert die Standardeinstellung von coredump\_filter, die beim Booten zu
sehen ist.
Wenn Sie unsicher sind, sagen Sie Y.

\subsection{Kernel support for scripts starting with \#!}
CONFIG\_BINFMT\_SCRIPT [=y] \textbf{[Y]}\\
(Kernel-Unterstützung für Skripte, die mit \#!, dem Shebang, anfangen)
Geben Sie hier Y an, wenn Sie interpretierte Skripte ausführen wollen, die mit \#! beginnen,
gefolgt von dem Pfad zu einem Interpreter. Sie können diese Unterstützung als Modul bauen; bis dieses
Modul jedoch geladen ist, können Sie keine Skripte ausführen.
Wenn Sie also dieses Modul aus einem initramfs laden wollen, darf der Teil des initramfs vor dem Laden
dieses Moduls nur aus kompilierten Binärdateien bestehen. Die meisten Systeme werden nicht booten,
wenn Sie hier M oder N angeben. Wenn Sie unsicher sind, sagen Sie Y.

\subsection{Kernel support for MISC binaries}
CONFIG\_BINFMT\_MISC [=y] \textbf{[Y]}\\
Wenn Sie hier Y sagen, wird es möglich sein, Wrapper-gesteuerte Binärformate in den Kernel einzubinden.
Dies ist vor allem dann sinnvoll, wenn Sie Programme verwenden, die einen Interpreter benötigen, wie
Java, Python, .NET oder Emacs-Lisp. Es ist auch nützlich, wenn Sie häufig DOS-Programme unter dem
Linux-DOS-Emulator DOSEMU ausführen (lesen Sie das DOSEMU-HOWTO, verfügbar unter
\url{http://www.tldp.org/docs.html#howto}). Sobald Sie eine solche Binärklasse beim Kernel registriert
haben, können Sie eines dieser Programme einfach starten, indem Sie seinen Namen an einer
Shell-Eingabeaufforderung eingeben; Linux wird es automatisch an den richtigen Interpreter weiterleiten.
Sie können auch andere nette Dinge tun.\\
Lesen Sie die Datei $<$file:Documentation/admin-guide/binfmt-misc.rst$>$,
um zu erfahren, wie Sie diese Funktion nutzen können,
$<$file:Documentation/admin-guide/java.rst$>$, um zu erfahren, wie Sie Java-Unterstützung einbinden
können, und $<$file:Documentation/admin-guide/mono.rst$>$, um zu erfahren, wie Sie Mono-basierte
.NET-Unterstützung einbinden können.
Um binfmt\_misc zu verwenden, müssen Sie es mounten:
\texttt{mount binfmt\_misc -t binfmt\_misc /proc/sys/fs/binfmt\_misc}
Sie können hier M für Modulunterstützung sagen und später das Modul laden, wenn Sie es brauchen;
das Modul heißt \texttt{binfmt\_misc}. Wenn Sie nicht wissen, was Sie an dieser Stelle antworten sollen,
sagen Sie Y.

\section{Memory Management options \texorpdfstring{$\rightarrow$}{->}}
(Speicherverwaltungsoptionen)

\subsection{Support for paging of anonymous memory (swap) \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_SWAP [=y] \textbf{[Y]}\\
Mit dieser Option können Sie wählen, ob Sie Unterstützung für so genannte Swap-Geräte oder
Swap-Dateien in Ihrem Kernel haben möchten, die dazu dienen, mehr virtuellen Speicher als
den tatsächlichen Arbeitsspeicher in Ihrem Computer bereitzustellen.
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{Compressed cache for swap pages}
CONFIG\_ZSWAP [=y] \textbf{[Y]}\\
Ein leichtgewichtiger komprimierter Cache für Auslagerungsseiten.  Er nimmt Seiten, die gerade ausgelagert
werden, und versucht, sie in einem dynamisch zugewiesenen RAM-basierten Speicherpool zu komprimieren. Dies
kann zu einer erheblichen E/A-Reduzierung auf dem Swap-Gerät führen und in dem Fall, in dem die
Dekomprimierung aus dem RAM schneller ist als das Lesen aus dem Swap-Gerät, auch die Arbeitslastleistung
verbessern.

\paragraph{Enable the compressed cache for swap pages by default}$~$\\
CONFIG\_ZSWAP\_DEFAULT\_ON [=y] \textbf{[Y]}\\
Wenn diese Option ausgewählt ist, wird der komprimierte Cache für Auslagerungsseiten beim Booten aktiviert,
andernfalls wird er deaktiviert. Die hier getroffene Auswahl kann mit der Kernel-Kommando\-zei\-len\-option
\texttt{zswap.enabled=} überschrieben werden.

\paragraph{Invalidate zswap entries when pages are loaded}$~$\\
CONFIG\_ZSWAP\_EXCLUSIVE\_LOADS\_DEFAULT\_ON [=n] \textbf{[N]}\\
Wenn diese Option ausgewählt ist, werden exklusive Lasten für zswap beim Booten aktiviert, andernfalls wird
sie deaktiviert. Wenn exklusive Ladungen aktiviert sind, wird beim Laden einer Seite aus zswap der
zswap-Eintrag sofort ungültig gemacht, anstatt ihn in zswap zu belassen, bis der Swap-Eintrag freigegeben
wird. Dadurch wird vermieden, dass sich zwei Kopien derselben Seite im Speicher befinden (komprimiert und
unkomprimiert), nachdem eine Seite aus zswap geladen wurde. Der Preis dafür ist, dass die Seite neu
komprimiert wird, wenn sie nie verschmutzt wurde und erneut ausgelagert werden muss.

\paragraph{Default compressor () \texorpdfstring{$\rightarrow$}{->}}
Wählt den Standardkomprimierungsalgorithmus für den komprimierten Cache für Auslagerungsseiten aus.
Einen Überblick darüber, welche Leistung von einem bestimmten Kompressionsalgorithmus erwartet werden kann,
finden Sie in den Benchmarks auf der folgenden LWN-Seite: \url{https://lwn.net/Articles/751795/}\\
Im Zweifelsfall wählen Sie \texttt{LZO}.
Die hier getroffene Auswahl kann durch Verwendung der Kernel-Befehls\-zeilen\-option
\texttt{zswap.compressor=} überschrieben werden.

\subparagraph{Deflate}$~$\\
CONFIG\_ZSWAP\_COMPRESSOR\_DEFAULT\_DEFLATE [=n] \textbf{[N]}\\
Verwenden Sie den Deflate-Algorithmus als Standard-Komprimierungsalgorithmus.
\subparagraph{LZO}$~$\\
CONFIG\_ZSWAP\_COMPRESSOR\_DEFAULT\_LZO [=n] \textbf{[N]}\\
Verwenden Sie den LZO-Algorithmus als Standard-Komprimierungsalgorithmus.
\subparagraph{842}$~$\\
CONFIG\_ZSWAP\_COMPRESSOR\_DEFAULT\_842 [=n] \textbf{[N]}\\
Verwenden Sie den 842-Algorithmus als Standard-Komprimierungsalgorithmus.
\subparagraph{LZ4}$~$\\
CONFIG\_ZSWAP\_COMPRESSOR\_DEFAULT\_LZ4 [=n] \textbf{[N]}\\
Verwenden Sie den LZ4-Algorithmus als Standard-Komprimierungsalgorithmus.
\subparagraph{LZ4HC}$~$\\
CONFIG\_ZSWAP\_COMPRESSOR\_DEFAULT\_LZ4HC [=n] \textbf{[N]}\\
Verwenden Sie den LZ4HC-Algorithmus als Standard-Komprimierungsalgorithmus.
\subparagraph{zstd}$~$\\
CONFIG\_ZSWAP\_COMPRESSOR\_DEFAULT\_ZSTD [=y] \textbf{[Y]}\\
Verwenden Sie den zstd-Algorithmus als Standard-Komprimierungsalgorithmus.

\paragraph{Default allocator () \texorpdfstring{$\rightarrow$}{->}}$~$\\
Wählt den Standardzuweiser für den komprimierten Cache für Auslagerungsseiten aus. Die Voreinstellung ist
aus Kompatibilitätsgründen \glqq zbud\grqq{}, aber lesen Sie bitte die Beschreibung der einzelnen Zuweiser
unten, bevor Sie die richtige Wahl treffen. Die hier getroffene Auswahl kann mit der
Kernel-Kommandozeilenoption \texttt{zswap.zpool=} überschrieben werden.

\subparagraph{zbud}$~$\\
CONFIG\_ZSWAP\_ZPOOL\_DEFAULT\_ZBUD [=n] \textbf{[N]}\\
Verwendung des zbud-Allokators als Standard-Allokator.

\subparagraph{z3fold}$~$\\
CONFIG\_ZSWAP\_ZPOOL\_DEFAULT\_Z3FOLD [=n] \textbf{[N]}\\
Verwendung des z3fold-Allokators als Standard-Allokator.

\subparagraph{zsmalloc}$~$\\
CONFIG\_ZSWAP\_ZPOOL\_DEFAULT\_ZSMALLOC [=n] \textbf{[N]}\\
Verwendung des zsmalloc-Allokators als Standard-Allokator.

\paragraph{2:1 compression allocator (zbud) \texorpdfstring{$\rightarrow$}{->}}$~$\\
CONFIG\_ZBUD [=y] \textbf{[Y]}\\
Ein spezieller Allokator für die Speicherung komprimierter Seiten. Er ist für die Speicherung von bis zu zwei
komprimierten Seiten pro physischer Seite ausgelegt.
Dieses Design schränkt zwar die Speicherdichte ein, hat aber einfache und deterministische
Rückgewinnungseigenschaften, die es einem Ansatz mit höherer Dichte vorziehen, wenn die Rückgewinnung
verwendet wird.

\paragraph{3:1 compression allocator (z3fold) \texorpdfstring{$\rightarrow$}{->}}$~$\\
CONFIG\_Z3FOLD [=y] \textbf{[Y]}\\
Ein spezieller Allokator für die Speicherung komprimierter Seiten. Er ist für die Speicherung von bis zu drei
komprimierten Seiten pro physischer Seite ausgelegt.
Es handelt sich um ein ZBUD-Derivat, so dass die Einfachheit und der Determinismus weiterhin gegeben sind.

\paragraph{N:1 compression allocator (zsmalloc) \texorpdfstring{$\rightarrow$}{->}}$~$\\
CONFIG\_ZSMALLOC [=y] \textbf{[Y]}\\
zsmalloc ist ein Slab-basierter Speicherallokator, der für die effiziente Speicherung von Seiten
verschiedener Komprimierungsstufen entwickelt wurde. Er erreicht die höchste Speicherdichte mit der
geringsten Fragmentierung.

\subparagraph{Export zsmalloc statistics}$~$\\
CONFIG\_ZSMALLOC\_STAT [=n] \textbf{[N]}\\
Diese Option ermöglicht es dem Code in zsmalloc, verschiedene Statistiken über die Vorgänge in zsmalloc zu
sammeln und diese Informationen über debugfs in den Userspace zu exportieren. Wenn Sie unsicher sind,
sagen Sie N.

\subparagraph{Maximum number of physical pages per-zspage}$~$\\
CONFIG\_ZSMALLOC\_CHAIN\_SIZE [=8] \textbf{[8]}\\
Diese Option legt die Obergrenze für die Anzahl der physischen Seiten fest, aus denen eine zmalloc-Seite
(zspage) bestehen kann. Die optimale zspage-Kettengröße wird für jede Größenklasse während der
Initialisierung des Pools berechnet.\\
Eine Änderung dieser Option kann die Eigenschaften der Größenklassen
verändern, z.~B. die Anzahl der Seiten pro zspage und die Anzahl der Objekte pro zspage.
Dies kann auch zu unterschiedlichen Konfigurationen des Pools führen, da zsmalloc Größenklassen mit
ähnlichen Eigenschaften zusammenführt.\\
Weitere Informationen finden Sie in der Dokumentation zu zsmalloc.

\subsection{SLAB allocator options \texorpdfstring{$\rightarrow$}{->}}

\subsubsection{Choose SLAB allocator (SLUB (Unqueued Allocator)) \texorpdfstring{$\rightarrow$}{->}}
Diese Option ermöglicht die Auswahl eines Slab-Allokators.

\paragraph{SLAB (DEPRECATEDUnqueued Allocator)}$~$\\
CONFIG\_SLAB\_DEPRECATED [=n] \textbf{[N]}\\
Veraltet und soll in ein paar Zyklen entfernt werden. Ersetzt durch SLUB. Wenn Sie nicht auf SLUB umsteigen
können, wenden Sie sich bitte an linux-mm@kvack.org und an die Personen, die im Abschnitt SLAB ALLOCATOR der
MAINTAINERS-Datei aufgeführt sind, und erläutern Sie die Gründe. Der reguläre Slab-Allokator, der sich
bewährt hat und bekanntermaßen in allen Umgebungen gut funktioniert. Er organisiert Cache-Hot-Objekte in
Warteschlangen pro CPU und pro Knoten.

\paragraph{SLUB (Unqueued Allocator)}$~$\\
CONFIG\_SLUB [=y] \textbf{[Y]}\\
SLUB ist ein Slab-Allokator, der die Nutzung von Cache-Zeilen minimiert, anstatt Warteschlangen von gecachten
Objekten zu verwalten (SLAB-Ansatz). Die Zwischenspeicherung pro CPU wird durch Slabs von Objekten anstelle
von Objekt-Warteschlangen realisiert. SLUB kann den Speicher effizient nutzen und verfügt über verbesserte
Diagnosefunktionen. SLUB ist die Standardwahl für einen Slab-Allokator.

\subsubsection{Allow slab caches to be merged}
CONFIG\_SLAB\_MERGE\_DEFAULT [=y] \textbf{[Y]}\\
Um die Fragmentierung des Kernspeichers zu verringern, können Slab-Caches zusammengelegt werden, wenn sie
die gleiche Größe und andere Merkmale aufweisen. Dies birgt das Risiko, dass Kernel-Heap-Überläufe Objekte
aus zusammengeführten Caches überschreiben können (und das Cache-Layout leichter zu kontrollieren ist),
wodurch solche Heap-Angriffe von Angreifern leichter ausgenutzt werden können. Wenn die Caches nicht gemischt
werden, können diese Arten von Angriffen normalerweise nur Objekte im selben Cache beschädigen. Um die
Zusammenführung zur Laufzeit zu deaktivieren, kann \texttt{slab\_nomerge} in der Kernel-Befehlszeile
übergeben werden.

\subsubsection{Randomize slab freelist}
CONFIG\_SLAB\_FREELIST\_RANDOM [=y] \textbf{[Y]}\\
Die Reihenfolge der Freelist bei der Erstellung neuer Seiten wird zufällig festgelegt.
Dieses Sicherheitsmerkmal verringert die Vorhersagbarkeit der Kernel-Slab-Zuweisung gegen Heap-Überläufe.

\subsubsection{Harden slab freelist metadata}
CONFIG\_SLAB\_FREELIST\_HARDENED [=y] \textbf{[Y]}\\
Viele Kernel-Heap-Angriffe zielen auf Slab-Cache-Metadaten und andere Infrastrukturen ab.
Diese Optionen bringen geringfügige Leistungseinbußen mit sich, um den Kernel-Slab-Allokator gegen gängige
Freelist-Angriffsmethoden zu härten. Einige Slab-Implementierungen haben mehr Sanity-Checking als andere.
Diese Option ist am effektivsten mit CONFIG\_SLUB.

\subsubsection{Enable SLUB performance statistics}
CONFIG\_SLUB\_STATS [=n] \textbf{[N]}\\
SLUB-Statistiken sind nützlich, um das Zuweisungsverhalten von SLUBs zu debuggen und Wege zur Optimierung
der Zuweisungsfunktion zu finden. Diese Funktion sollte niemals für den produktiven Einsatz aktiviert werden,
da die Führung von Statistiken die Zuweisungsfunktion um einige Prozentpunkte verlangsamt.
Der Befehl \texttt{slabinfo} unterstützt die Ermittlung der aktivsten Slabs, um herauszufinden,
welche Slabs für eine bestimmte Last relevant sind. Versuchen Sie Folgendes: \texttt{slabinfo -DA}

\subsubsection{SLUB per cpu partial cache}
CONFIG\_SLUB\_CPU\_PARTIAL [=y] \textbf{[Y]}\\
Partielle Zwischenspeicher pro CPU beschleunigen die Zuweisung und Freigabe von Objekten, die lokal auf einem
Prozessor liegen, zum Preis einer größeren Unbestimmtheit bei der Latenzzeit der Freigabe. Bei Überlauf
werden diese Caches geleert, was das Einnehmen von Sperren erfordert, die Latenzspitzen verursachen können.
Normalerweise würde man sich bei einem Echtzeitsystem für nein entscheiden.

\subsubsection{Randomize slab caches for normal kmalloc}
CONFIG\_RANDOM\_KMALLOC\_CACHES [=n] \textbf{[N]}\\
Eine Härtungsfunktion, die mehrere Kopien von Slab-Caches für die normale kmalloc-Allokation erstellt und
kmalloc veranlasst, eine zufällig auf der Grundlage der Code-Adresse auszuwählen, was es Angreifern
erschwert, verwundbare Speicherobjekte auf den Heap zu sprühen, um Speicherschwachstellen auszunutzen.
Gegenwärtig ist die Anzahl der Kopien auf 16 festgelegt, ein angemessen großer Wert, der die für verschiedene
Subsysteme oder Module zugewiesenen Speicherobjekte effektiv in verschiedene Caches aufteilt, und zwar auf
Kosten eines begrenzten Grades an Speicher- und CPU-Overhead, der mit der Hardware und der Systemauslastung
zusammenhängt.

\subsection{Page allocator randomization}
CONFIG\_SHUFFLE\_PAGE\_ALLOCATOR [=y] \textbf{[Y]}\\
Die Randomisierung der Seitenzuweisung verbessert die durchschnittliche Auslastung eines direkt abgebildeten
Memory-Side-Cache. In Abschnitt 5.2.27 Heterogeneous Memory Attribute Table (HMAT) der ACPI 6.2a-Spezifikation
finden Sie ein Beispiel dafür, wie eine Plattform das Vorhandensein eines speicherseitigen Cache anzeigt.
Es gibt auch zufällige Sicherheitsvorteile, da es die Vorhersagbarkeit von Seitenzuweisungen reduziert, um
SLAB\_FREELIST\_RANDOM zu ergänzen, aber die Standardgranularität des Shufflings auf MAX\_ORDER,
d.h. die 10. Reihenfolge der Seiten wird auf der Grundlage der Cache-Nutzung auf x86 ausgewählt.
Die Randomisierung verbessert zwar die Cache-Nutzung, kann sich aber auf Plattformen ohne Cache negativ auf
die Arbeitslast auswirken. Aus diesem Grund wird die Randomisierung standardmäßig nur aktiviert, wenn zur
Laufzeit ein direkt zugeordneter Memory-Side-Cache erkannt wird. Andernfalls kann die Randomisierung mit dem
Kernel-Befehlszeilenparameter \texttt{page\_alloc.shuffle} zwangsweise aktiviert werden.
Sagen Sie Y, wenn Sie unsicher sind.

\subsection{Disable heap randomization}
CONFIG\_COMPAT\_BRK [=n] \textbf{[N]}\\
Die Randomisierung der Heap-Platzierung macht Heap-Exploits schwieriger, aber sie macht auch alte
Binärdateien (einschließlich aller libc5-basierten) kaputt. Diese Option ändert die Standardeinstellung beim
Booten auf Heap-Randomisierung deaktiviert und kann zur Laufzeit überschrieben werden, indem
/proc/sys/kernel/randomize\_va\_space auf 2 gesetzt wird. Auf nicht-alten Distributionen (nach 2000)
ist N normalerweise eine sichere Wahl.

\subsection{Sparse Memory virtual memmap}
CONFIG\_SPARSEMEM\_VMEMMAP [=y] \textbf{[Y]}\\
SPARSEMEM\_VMEMMAP verwendet eine virtuell gemappte Memmap, um texttt{pfn\_to\_page} und\\
\texttt{page\_to\_pfn} Operationen zu optimieren.
Dies ist die effizienteste Option, wenn genügend Kernel-Res\-sour\-cen verfügbar sind.

\subsection{Memory hotplug \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_HOTPLUG [=y] \textbf{[Y]}\\
\textit{Für diese Option gibt es keine Hilfe.}

\subsubsection{Online the newly added memory blocks by default}
CONFIG\_MEMORY\_HOTPLUG\_DEFAULT\_ONLINE [=y] \textbf{[Y]}\\
Diese Option legt die Standardeinstellung für die Hotplug-Onlining-Richtlinie für Speicher fest\\
(/sys/devices/system/memory/auto\_online\_blocks), die bestimmt, was mit neu hinzugefügten
Speicherbereichen geschieht.
Die Richtlinieneinstellung kann jederzeit zur Laufzeit geändert werden.\\
Siehe Documentation/admin-guide/mm/memory-hotplug.rst für weitere Informationen.
Geben Sie hier Y an, wenn Sie möchten, dass alle Hotplug-Speicherblöcke standardmäßig im
\glqq Online\grqq{}-Zustand erscheinen. Geben Sie hier N an, wenn Sie möchten, dass die
Standardrichtlinie alle Hot-Plugged-Speicherblöcke im \glqq Offline\grqq{}-Zustand hält.

\subsubsection{Allow for memory hot remove}
CONFIG\_MEMORY\_HOTREMOVE [=y] \textbf{[Y]}\\
\textit{Für diese Option gibt es keine Hilfe.}

\subsection{Allow for balloon memory compaction/migration}
CONFIG\_BALLOON\_COMPACTION [=y] \textbf{[Y]}\\
Die durch das Ballooning verursachte Speicherfragmentierung kann die Anzahl der zusammenhängenden
2-MB-Speicher\-blöcke, die in einem Gastsystem verwendet werden können, erheblich verringern, was zu
Leistungseinbußen aufgrund der geringeren Anzahl transparenter großer Seiten führt, die vom Gastsystem
verwendet werden können. Das Zulassen der Verdichtung und Migration für Speicherseiten, die als Teil von
Speicher-Ballon-Geräten eingetragen sind, vermeidet das oben beschriebene Szenario und trägt zur Verbesserung
der Speicherdefragmentierung bei.

\subsection{Allow for memory compaction}
CONFIG\_COMPACTION [=y] \textbf{[Y]}\\
Die Verdichtung ist die einzige Speicherverwaltungskomponente, die zuverlässig Speicherblöcke hoher Ordnung
(größere, physisch zusammenhängende Blöcke) bildet. Die Seitenzuweisung ist in hohem Maße auf die Verdichtung
angewiesen, und das Fehlen dieser Funktion kann bei Speicheranforderungen hoher Ordnung zu unerwarteten
OOM-Killer-Aufrufen führen. Sie sollten diese Option nicht deaktivieren, es sei denn, es gibt wirklich einen
triftigen Grund dafür, und dann wären wir sehr daran interessiert, diesen unter
\href{mailto:linux-mm@kvack.org}{linux-mm@kvack.org} zu erfahren.

\subsection{Free page reporting}
CONFIG\_PAGE\_REPORTING [=y] \textbf{[Y]}\\
Die Meldung freier Seiten ermöglicht die inkrementelle Erfassung freier Seiten vom Buddy-Allokator mit
dem Ziel, diese Seiten einer anderen Einheit, z.~B. einem Hypervisor, zu melden, damit der Speicher
innerhalb des Hosts für andere Zwecke freigegeben werden kann.

\subsection{Page migration}
CONFIG\_MIGRATION [=y] \textbf{[Y]}\\
Ermöglicht die Migration des physischen Standorts von Seiten von Prozessen, während die virtuellen
Adressen nicht geändert werden. Dies ist in zwei Situationen nützlich. Erstens auf NUMA-Systemen, um
Seiten näher an die zugreifenden Prozessoren zu bringen. Zweitens bei der Zuweisung großer Seiten,
da durch die Migration Seiten verlagert werden können, um eine große Seitenzuweisung zu erfüllen,
anstatt sie zurückzufordern.

\subsection{Enable KSM for page merging}
CONFIG\_KSM [=y] \textbf{[Y]}\\
Aktivieren Sie Kernel Samepage Merging: KSM scannt in regelmäßigen Abständen die Bereiche des Adressraums
einer Anwendung, die laut einer Anwendung zusammengeführt werden können. Wenn er Seiten mit identischem
Inhalt findet, ersetzt er die vielen Instanzen durch eine einzige Seite mit diesem Inhalt und spart so
Speicher, bis eine oder eine andere Anwendung den Inhalt ändern muss. Empfohlen für die Verwendung mit KVM
oder mit anderen doppelten Anwendungen.\\
Siehe Documentation/mm/ksm.rst für weitere Informationen: KSM ist inaktiv, bis ein Programm festgestellt hat,
dass ein Bereich MADV\_MERGEABLE ist, und root /sys/kernel/mm/ksm/run auf 1 gesetzt hat
(wenn CONFIG\_SYSFS gesetzt ist).

\subsection{Low address space to protect from user allocation}
CONFIG\_DEFAULT\_MMAP\_MIN\_ADDR [=65536] \textbf{[65536]}\\
Dies ist der Teil des niedrigen virtuellen Speichers, der vor der Zuweisung an den Benutzerraum geschützt werden
sollte. Wenn ein Benutzer davon abgehalten wird, auf niedrige Seiten zu schreiben, kann dies dazu beitragen, die
Auswirkungen von NULL-Zeiger-Fehlern im Kernel zu verringern. Für die meisten ia64-, ppc64- und x86-Benutzer mit
viel Adressraum ist ein Wert von 65536 angemessen und sollte keine Probleme verursachen.
Auf Arm und anderen Architekturen sollte er nicht höher als 32768 sein. Programme, die die vm86-Funktionalität nutzen oder
diesen niedrigen Adressraum abbilden müssen, benötigen CAP\_SYS\_RAWIO oder deaktivieren diesen Schutz,
indem sie den Wert auf 0 setzen. Dieser Wert kann nach dem Booten mit dem Parameter /proc/sys/vm/mmap\_min\_addr
geändert werden.

\subsection{Enable recovery from hardware memory errors}
CONFIG\_MEMORY\_FAILURE [=y] \textbf{[Y]}\\
Ermöglicht die Wiederherstellung von Code nach einigen Speicherfehlern auf Systemen mit MCA-Wieder\-her\-stel\-lung.
Dadurch kann ein System auch dann weiterlaufen, wenn ein Teil des Speichers unkorrigierte Fehler aufweist. Dies
erfordert spezielle Hardwareunterstützung und in der Regel ECC-Speicher.

\subsubsection{HWPoison pages injector}
CONFIG\_HWPOISON\_INJECT [=m] \textbf{[M]}\\
\textit{Für diese Option gibt es keine Hilfe.}

\subsection{Transparent Hugepage Support \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_TRANSPARENT\_HUGEPAGE [=y] \textbf{[Y]}\\
Transparent Hugepages erlaubt es dem Kernel, große Seiten und große tlb transparent für die Anwendungen zu
verwenden, wann immer dies möglich ist. Diese Funktion kann die Rechenleistung bestimmter Anwendungen verbessern,
indem sie Seitenfehler bei der Speicherzuweisung beschleunigt, die Anzahl der tlb-Misses verringert und das
Durchlaufen der Seitentabelle beschleunigt.
Wenn der Speicher bei eingebetteten Systemen begrenzt ist, können Sie N angeben.

\subsubsection{Transparent Hugepage Support sysfs defaults () \texorpdfstring{$\rightarrow$}{->}}
Wählt die sysfs-Vorgaben für die transparente Hugepage-Unterstützung aus.

\paragraph{always}$~$\\
CONFIG\_TRANSPARENT\_HUGEPAGE\_ALWAYS [=y] \textbf{[Y]}\\
Die ständige Aktivierung von Transparent Hugepage kann den Speicherbedarf von Anwendungen erhöhen, ohne dass
dies einen garantierten Nutzen hat, aber es funktioniert automatisch für alle Anwendungen.

\paragraph{madvise}$~$\\
CONFIG\_TRANSPARENT\_HUGEPAGE\_MADVISE [=n] \textbf{[N]}\\
Die Aktivierung von Transparent Hugepage madvise bringt nur eine Leistungsverbesserung für die Anwendungen, die
madvise(MADV\_HUGEPAGE) verwenden, aber es besteht nicht die Gefahr, dass der Speicherbedarf von Anwendungen
ohne garantierten Nutzen erhöht wird.

\subsubsection{Read-only THP for filesystems (EXPERIMENTAL)}
CONFIG\_READ\_ONLY\_THP\_FOR\_FS [=y] \textbf{[Y]}\\
Erlaubt khugepaged, schreibgeschützte Seiten in THP zu speichern. Dies ist als experimentell gekennzeichnet, da
es sich um eine neue Funktion handelt. Schreibunterstützung für Datei-THPs wird in den nächsten Release-Zyklen
entwickelt werden.

\subsection{Contiguous Memory Allocator}
CONFIG\_CMA [=y] \textbf{[Y]}\\
Dadurch wird der Contiguous Memory Allocator aktiviert, der es anderen Subsystemen ermöglicht, große, physisch
zusammenhängende Speicherblöcke zuzuweisen. CMA reserviert einen Speicherbereich und erlaubt nur die Zuweisung
beweglicher Seiten aus diesem Bereich. Auf diese Weise kann der Kernel den Speicher als Pagecache verwenden,
und wenn ein Subsystem einen zusammenhängenden Bereich anfordert, werden die zugewiesenen Seiten verschoben,
um die zusammenhängende Anforderung zu bedienen. Wenn Sie unsicher sind, sagen Sie N für nein.

\subsubsection{CMA debug messages (DEVELOPMENT)}
CONFIG\_CMA\_DEBUG [=n] \textbf{[N]}\\
Schaltet Debug-Meldungen in CMA ein. Dies erzeugt KERN\_DEBUG-Meldungen für jeden CMA-Aufruf sowie verschiedene
Meldungen während der Verarbeitung von Aufrufen wie dma\_alloc\_from\_contiguous(). Diese Option hat keinen
Einfluss auf Warn- und Fehlermeldungen.

\subsubsection{CMA debugfs interface}
CONFIG\_CMA\_DEBUGFS [=y] \textbf{[Y]}\\
Schaltet die DebugFS-Schnittstelle für CMA ein.

\subsubsection{CMA information through sysfs interface}
CONFIG\_CMA\_SYSFS [=y] \textbf{[Y]}\\
Diese Option legt einige sysfs-Attribute offen, um Informationen von CMA zu erhalten.

\subsubsection{Maximum count of the CMA areas}
CONFIG\_CMA\_AREAS [=7] \textbf{[7]}\\
CMA ermöglicht es, CMA-Bereiche für bestimmte Zwecke zu erstellen, die hauptsächlich als privater Bereich des
Geräts verwendet werden. Mit diesem Parameter wird die maximale Anzahl von CMA-Bereichen im System festgelegt.
Wenn Sie unsicher sind, belassen Sie den Standardwert \glqq 7\grqq{} bei UMA und
\glqq 19\grqq{} bei NUMA.

\subsection{Track memory changes}
CONFIG\_MEM\_SOFT\_DIRTY [=y] \textbf{[Y]}\\
Diese Option ermöglicht die Verfolgung von Speicheränderungen durch Einführung eines Soft-Dirty-Bits auf
pte-s. Dieses Bit wird gesetzt, wenn jemand in eine Seite schreibt, genau wie das reguläre Dirty Bit, aber
im Gegensatz zu letzterem kann es von Hand gelöscht werden. Siehe Documentation/admin-guide/mm/soft-dirty.rst
für weitere Details.

\subsection{Defer initialisation of struct pages to kthreads}
CONFIG\_DEFERRED\_STRUCT\_PAGE\_INIT [=n] \textbf{[N]}\\
Normalerweise werden alle Strukturseiten beim Frühstart in einem einzigen Thread initialisiert. Auf sehr
großen Rechnern kann dies sehr viel Zeit in Anspruch nehmen. Wenn diese Option gesetzt ist, wird bei großen
Maschinen eine Teilmenge der memmap beim Booten aufgerufen und der Rest parallel initialisiert. Dies kann
sich auf die Leistung von Aufgaben auswirken, die zu Beginn der Lebensdauer des Systems ausgeführt werden,
bis diese kthreads die Initialisierung abgeschlossen haben.

\subsection{Enable idle page tracking}
CONFIG\_IDLE\_PAGE\_TRACKING [=y] \textbf{[Y]}\\
Diese Funktion ermöglicht es, die Anzahl der Benutzerseiten zu schätzen, die in einem bestimmten Zeitraum
nicht berührt wurden. Diese Information kann nützlich sein, um die Grenzen der Speichergruppen und/oder die
Platzierung von Aufträgen innerhalb eines Rechenclusters zu optimieren.\\
Siehe Documentation/admin-guide/mm/idle\_page\_tracking.rst für weitere Einzelheiten.

\subsection{Device memory (pmem, HMM, etc...) hotplug support}
CONFIG\_ZONE\_DEVICE [=y] \textbf{[Y]}\\
Die Hotplug-Unterstützung für Gerätespeicher ermöglicht es, pmem oder andere vom Gerätetreiber entdeckte
Speicherregionen in der Memmap zu etablieren. Dies ermöglicht pfn\_to\_page()-Lookups von ansonsten
\glqq gerätephysikalischen\grqq{} Adressen, was unter anderem für die Verwendung einer DAX-Zuordnung
in einer O\_DIRECT-Operation erforderlich ist. Wenn FS\_DAX aktiviert ist, dann sagen Sie Y.

\subsection{Unaddressable device memory (GPU memory, ...)}
CONFIG\_DEVICE\_PRIVATE [=y] \textbf{[Y]}\\
Ermöglicht die Erstellung von Strukturseiten zur Darstellung von nicht adressierbarem Gerätespeicher,
d.~h. Speicher, auf den nur vom Gerät (oder einer Gruppe von Geräten) aus zugegriffen werden kann.
Wahrscheinlich sollten Sie auch HMM\_MIRROR auswählen.

\subsection{Collect percpu memory statistics}
CONFIG\_PERCPU\_STATS [=n] \textbf{[N]}\\
Diese Funktion sammelt Statistiken und stellt sie über debugfs zur Verfügung. Die Informationen umfassen
globale und pro Chunk-Statistiken, die dazu beitragen können, die Speichernutzung der CPU zu verstehen.

\subsection{Enable infrastructure for get\_user\_pages()-related unit tests}
CONFIG\_GUP\_TEST [=n] \textbf{[N]}\\
Stellt /sys/kernel/debug/gup\_test zur Verfügung, das wiederum eine Möglichkeit bietet, ioctl-Aufrufe zu
machen, die kernelbasierte Unit-Tests für die get\_user\_pages*()- und pin\_user\_pages*()-Familie von
API-Aufrufen starten können. Diese Tests umfassen Benchmark-Tests für die schnellen Varianten von
get\_user\_pages*() und pin\_user\_pages*() sowie Smoke-Tests für die nicht schnellen Varianten.
Es gibt auch einen Untertest, der die Ausführung von dump\_page() auf bis zu acht Seiten
(ausgewählt durch Befehlszeilen-Args) innerhalb des Bereichs der User-Space-Adressen ermöglicht.
Diese Seiten werden entweder über pin\_user\_pages*() oder über get\_user\_pages*() angeheftet, wie durch
andere Befehlszeilenargumente angegeben.\\
Siehe tools/testing/selftests/mm/gup\_test.c

% 13.23
\subsection{Enable a module to run time tests on dma\_pool}
CONFIG\_DMAPOOL\_TEST [=n] \textbf{[N]}\\
Stellt ein Testmodul zur Verfügung, das viele Blöcke unterschiedlicher Größe alloziert und freigibt und
berichtet, wie lange es dauert. Damit soll ein konsistenter Weg gefunden werden, um zu messen, wie sich
Änderungen an den dma\_pool\_alloc/free-Routinen auf die Leistung auswirken.

\subsection{Anonymous VMS name support}
CONFIG\_ANON\_VMA\_NAME [=y] \textbf{[Y]}\\
Erlaubt die Benennung anonymer virtueller Speicherbereiche. Mit dieser Funktion können virtuellen
Speicherbereichen Namen zugewiesen werden.\\
Die zugewiesenen Namen können später aus /proc/pid/maps und
/proc/pid/smaps abgerufen werden und helfen bei der Identifizierung einzelner anonymer Speicherbereiche.
Die Zuweisung eines Namens für einen anonymen virtuellen Speicherbereich kann verhindern, dass dieser
Bereich aufgrund des unterschiedlichen Namens mit benachbarten virtuellen Speicherbereichen zusammengelegt
wird.

\subsection{Enable userfaultfd() system call}
CONFIG\_USERFAULTFD [=y] \textbf{[Y]}\\
Aktivieren Sie den Systemaufruf userfaultfd(), der das Abfangen und Behandeln von Seitenfehlern im
Userland ermöglicht.

\subsection{Userfaultfd write protection support for shmem/hugetlbfs}
CONFIG\_PTE\_MARKER\_UFFD\_WP [=y] \textbf{[Y]}\\
Ermöglicht die Erstellung von Marker-PTEs für den Userfaultfd-Schreibschutz.
Sie ist erforderlich, um den userfaultfd-Schreibschutz für dateigebundene Speichertypen wie shmem
und hugetlbfs zu aktivieren.

\subsection{Multi-Gen LRU}
CONFIG\_LRU\_GEN [=y] \textbf{[Y]}\\
Eine hochleistungsfähige LRU-Implementierung zur Überbelegung von Speicher.\\
Siehe Documentation/admin-guide/mm/multigen\_lru.rst für Details.

\subsubsection{Enable by default}
CONFIG\_LRU\_GEN\_ENABLED [=y] \textbf{[Y]}\\
Mit dieser Option wird das Multi-Gen-LRU standardmäßig aktiviert.

\subsubsection{Full stats for debugging}
CONFIG\_LRU\_GEN\_STATS [=n] \textbf{[N]}\\
Aktivieren Sie diese Option nicht, es sei denn, Sie möchten sich die historischen Statistiken der
ausgeschiedenen Generationen zu Fehlersuchzwecken ansehen.
Diese Option hat einen Speicher-Overhead pro memcg und pro Knoten.

\subsection{Data Access Monitoring \texorpdfstring{$\rightarrow$}{->}}
(Überwachung des Datenzugriffs)

\subsubsection{DAMON: Data Access Monitoring Framework}
CONFIG\_DAMON [=y] \textbf{[Y]}\\
Damit wird ein Rahmen geschaffen, der es den Kernel-Subsystemen ermöglicht, die Zugriffshäufigkeit der
einzelnen Speicherbereiche zu überwachen. Diese Informationen können für eine leistungsorientierte
Speicherverwaltung auf DRAM-Ebene nützlich sein.
Weitere Informationen finden Sie unter\\
\url{https://damonitor.github.io/doc/html/latest-damon/index.html}.

\paragraph{Data access monitoring operations for virtual address spaces}$~$\\
CONFIG\_DAMON\_VADDR [=y] \textbf{[Y]}\\
Damit werden die Standardoperationen zur Überwachung des Datenzugriffs für DAMON erstellt, die
für virtuelle Adressräume funktionieren.

\paragraph{Data access monitoring operations for the physical address space}$~$\\
CONFIG\_DAMON\_PADDR [=y] \textbf{[Y]}\\
Damit werden die Standardvorgänge zur Datenzugriffsüberwachung für DAMON erstellt,
die für den physischen Adressraum funktionieren.

\subsubsection{DAMON sysfs interface}
CONFIG\_DAMON\_SYSFS [=y] \textbf{[Y]}\\
Dies bildet die sysfs-Schnittstelle für DAMON. Der Benutzerbereich kann die Schnittstelle für
die Über"-wachung beliebiger Datenzugriffe verwenden.

\subsubsection{DAMON debugfs interface (DEPRECATED!)}
CONFIG\_DAMON\_DBGFS [=y] \textbf{[N]}\\
Damit wird die debugfs-Schnittstelle für DAMON erstellt. Die Benutzerraum-Administratoren können
die Schnittstelle für die Überwachung beliebiger Datenzugriffe verwenden. Wenn Sie unsicher sind,
sagen Sie N.\\
Dies ist veraltet, daher sollten Benutzer auf die sysfs-Schnittstelle (DAMON\_SYSFS) umsteigen.
Wenn Sie auf diese Schnittstelle angewiesen sind und nicht umsteigen können, melden Sie bitte
Ihren Anwendungsfall an damon@lists.linux.dev und linux-mm@kvack.org.

\subsubsection{Build DAMON-based reclaim (DAMON\_RECLAIM)}
CONFIG\_DAMON\_RECLAIM [=y] \textbf{[Y]}\\
Damit wird das DAMON-basierte Reklamationssubsystem aufgebaut. Es findet Seiten, auf die lange
Zeit nicht mehr mit DAMON zugegriffen wurde (Cold) und fordert diese zurück. Dies wird als
proaktive und leichtgewichtige Rückgewinnung bei geringem Speicherdruck vorgeschlagen, während
die traditionelle, auf Seitenscans basierende Rückgewinnung bei hohem Druck verwendet wird.

\subsubsection{Build DAMON-based LRU-lists sorting (DAMON\_LRU\_SORT)}
CONFIG\_DAMON\_LRU\_SORT [=y] \textbf{[Y]}\\
Damit wird das DAMON-basierte LRU-Listensortier-Subsystem aufgebaut. Es versucht, häufig
zugegriffene (heiße) Seiten zu schützen, während selten zugegriffene (kalte) Seiten unter
Speicherdruck zuerst zurückgefordert werden.

\section{Networking support \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_NET [=y] \textbf{[Y]}\\
Wenn Sie nicht wirklich wissen, was Sie tun, sollten Sie hier Y sagen. Der Grund dafür ist,
dass einige Programme die Netzwerkunterstützung des Kernels benötigen, auch wenn sie auf einem
eigenständigen Rechner laufen, der nicht mit einem anderen Computer verbunden ist. Wenn Sie von
einem älteren Kernel aufrüsten, sollten Sie auch Ihre Netzwerkwerkzeuge aktualisieren, da
Änderungen am Kernel und an den Werkzeugen oft Hand in Hand gehen. Die Werkzeuge sind in dem
Paket \texttt{net-tools} enthalten, dessen Standort und Versionsnummer in
$<$file:Documentation/Changes$>$ angegeben sind.\\
Für eine allgemeine Einführung in Linux-Netzwerke ist es sehr empfehlenswert,
das NET-HOWTO zu lesen, das unter 
\url{http://www.tldp.org/docs.html#howto} verfügbar ist.

\subsection{Networking options \texorpdfstring{$\rightarrow$}{->}}
(Vernetzungsoptionen)

\subsubsection{Packet socket}
CONFIG\_PACKET [=y] \textbf{[Y]}\\
Das Packet-Protokoll wird von Anwendungen verwendet, die direkt mit Netzwerkgeräten kommunizieren,
ohne dass ein dazwischenliegendes Netzwerkprotokoll im Kernel implementiert ist, z.~B. tcpdump.
Wenn Sie wollen, dass diese Anwendungen funktionieren, wählen Sie Y. Um diesen Treiber als Modul
zu kompilieren, wählen Sie hier M: Das Modul wird \texttt{af\_packet} heißen.\\
Wenn Sie unsicher sind, wählen Sie Y.

\paragraph{Packet: sockets monitoring interface}$~$\\
CONFIG\_PACKET\_DIAG [=m] \textbf{[M]}\\
Unterstützung für die PF\_PACKET-Sockel-Überwachungsschnittstelle, die vom Werkzeug
\texttt{ss} verwendet wird. Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{Unix domain sockets}
CONFIG\_UNIX [=y] \textbf{[Y]}\\
Wenn Sie hier Y angeben, wird die Unterstützung für Unix-Domain-Sockets einbezogen;
Sockets sind der Standard-Unix-Mechanismus für den Aufbau von und den Zugriff auf
Netzwerkverbindungen. Viele häufig verwendete Programme wie das X-Window-System und syslog
verwenden diese Sockets, auch wenn Ihr Rechner nicht an ein Netzwerk angeschlossen ist.
Wenn Sie nicht gerade an einem eingebetteten System oder etwas Ähnlichem arbeiten, sollten Sie
hier also unbedingt Y sagen. Sagen Sie Y, wenn Sie nicht genau wissen, was Sie tun.

\paragraph{UNIX: socket monitoring interface}$~$\\
CONFIG\_UNIX\_DIAG [=m] \textbf{[M]}\\
Unterstützung für die vom Tool \texttt{ss} verwendete UNIX-Socket-Überwachungsschnittstelle.
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{Transport Layer Security support}
CONFIG\_TLS [=m] \textbf{[M]}\\
Aktivierung der Kernel-Unterstützung für das TLS-Protokoll. Dadurch kann die symmetrische
Verschlüsselung des TLS-Protokolls im Kernel durchgeführt werden.
Wenn Sie unsicher sind, sagen Sie N.

\paragraph{Transport Layer Security HW offload}$~$\\
CONFIG\_TLS\_DEVICE [=y] \textbf{[Y]}\\
Aktivierung der Kernel-Unterstützung für die HW-Auslagerung des TLS-Protokolls.
Wenn Sie unsicher sind, sagen Sie N.

\paragraph{Transport Layer Security TCP stack bypass}$~$\\
CONFIG\_TLS\_TOE [=n] \textbf{[N]}\\
Aktivierung der Kernel-Unterstützung für das Legacy-HW-Offload des TLS-Protokolls, das mit der
Semantik des Linux-Netzwerkstacks inkompatibel ist. Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{Transformation user configuration interface}
CONFIG\_XFRM\_USER [=y] \textbf{[Y]}\\
Unterstützung für Transformation(XFRM)-Benutzerkonfigurationsschnittstelle wie IPsec, die von
nativen Linux-Tools verwendet wird. Wenn Sie unsicher sind, sagen Sie Y.

\paragraph{Compatible ABI support}$~$\\
CONFIG\_XFRM\_USER\_COMPAT [=n] \textbf{[N]}\\
Transformation(XFRM)-Benutzerkonfigurationsschnittstelle wie IPsec, die von kompatiblen
Linux"=Anwendungen verwendet wird. Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{Transformation virtual interface}
CONFIG\_XFRM\_Interface [=m] \textbf{[M]}\\
Damit wird eine virtuelle Schnittstelle zum Routen des IPsec-Verkehrs bereitgestellt.
Wenn Sie unsicher sind, sagen Sie N.  

\subsubsection{Transformation sub policy support}
CONFIG\_XFRM\_SUB\_POLICY [=y] \textbf{[Y]}\\
Unterstützung von Unterrichtsrichtlinien für Entwickler. Durch die Verwendung der
Unterrichtlinie mit der Hauptrichtlinie können zwei Richtlinien gleichzeitig auf dasselbe
Paket angewendet werden. Eine Richtlinie, die kürzer im Kernel lebt, sollte eine Unterrichtlinie
sein. Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{Transformation migrate database}
CONFIG\_XFRM\_MIGRATE [=y] \textbf{[Y]}\\
Eine Funktion zur dynamischen Aktualisierung von Locator(s) einer bestimmten
IPsec"=Sicherheitsassoziation. Diese Funktion ist z.~B. in einer mobilen IPv6-Umgebung mit
IPsec-Konfiguration erforderlich, in der mobile Knoten ihren Verbindungspunkt zum Internet
ändern. Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{Transformation statistics}
CONFIG\_XFRM\_STATISTICS [=y] \textbf{[Y]}\\
Diese Statistik ist keine SNMP/MIB-Spezifikation, sondern zeigt Statistiken über
Transformationsfehler (oder Fast-Fehler) bei der Paketverarbeitung für Entwickler. Wenn Sie
unsicher sind, sagen Sie N.

\subsubsection{PF\_KEY sockets}
CONFIG\_NET\_KEY [=m] \textbf{[M]}\\
PF\_KEYv2-Buchsenfamilie, kompatibel zu KAME-Buchsen. Sie sind erforderlich, wenn Sie die von
KAME portierten IPsec-Tools verwenden wollen. Sagen Sie Y, wenn Sie nicht wissen, was Sie tun.

\paragraph{PF\_KEY MIGRATE}$~$\\
CONFIG\_NET\_KEY\_MIGRATE [=y] \textbf{[Y]}\\
Hinzufügen einer PF\_KEY MIGRATE Nachricht zur PF\_KEYv2 Socket Familie. Die PF\_KEY
MIGRATE"=Nachricht wird zur dynamischen Aktualisierung von Locator(s) einer bestimmten
IPsec"=Sicherheitsassoziation verwendet. Diese Funktion ist z.~B. in einer mobilen
IPv6"=Umgebung mit IPsec-Konfiguration erforderlich, in der mobile Knoten ihren Verbindungspunkt
zum Internet ändern. Detaillierte Informationen sind im Internet-Entwurf
$<$draft-sugimoto-mip6-pfkey-migrate$>$ zu finden. Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{SMC socket protocol family}
CONFIG\_SMC [=m]] \textbf{[M]}\\
SMC-R bietet eine \glqq Sockets over RDMA\grqq{}-Lösung, die die RDMA over Converged Ethernet
(RoCE)-Technologie nutzt, um AF\_INET-TCP-Verbindungen transparent zu aktualisieren. Die
Linux"=Implementierung der SMC-R-Lösung ist als separate Socket-Familie SMC konzipiert.
Wählen Sie diese Option, wenn Sie SMC-Socket-Anwendungen ausführen möchten.

\paragraph{SMC socket protocol family}$~$\\
CONFIG\_SMC\_DIAG [=m]] \textbf{[M]}\\
Unterstützung für die SMC-Socket-Überwachungsschnittstelle, die von Tools wie \texttt{smcss} verwendet
wird. Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{XDP sockets}
CONFIG\_XDP\_SOCKETS [=y]] \textbf{[Y]}\\
XDP-Sockets ermöglichen einen Kanal zwischen XDP-Programmen und Userspace-Anwendungen.

\paragraph{XDP sockets: monitoring interface}$~$\\
CONFIG\_XDP\_SOCKETS\_DIAG [=m]] \textbf{[M]}\\
Unterstützung für die vom \texttt{ss}-Tool verwendete PF\_XDP-Socket-Überwachungsschnittstelle.
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{TCP/IP networking}
CONFIG\_INET [=y]] \textbf{[Y]}\\
Dies sind die Protokolle, die im Internet und in den meisten lokalen Ethernets verwendet werden.
Es wird dringend empfohlen hier Y anzugeben (dadurch wird Ihr Kernel um etwa 400~KB vergrößert),
da einige Programme (z.~B. das X-Window-System) TCP/IP verwenden, auch wenn Ihr Rechner nicht
mit einem anderen Computer verbunden ist. Sie erhalten das sogenannte Loopback-Gerät, mit dem
Sie sich selbst anpingen können (was ein großer Spaß ist!). Eine ausgezeichnete Einführung in
die Linux-Netzwerktechnik finden Sie im Linux Networking HOWTO, erhältlich bei
\url{http://www.tldp.org/docs.html#howto}. Wenn Sie hier Y sagen
und auch zu \glqq /proc file system support\grqq{} und \glqq Sysctl support\grqq{} unten,
können Sie verschiedene Aspekte des Verhaltens des TCP/IP-Codes ändern, indem Sie in die
(virtuellen) Dateien in /proc/sys/net/ipv4/* schreiben; die Optionen werden in der Datei
$<$file:Documentation/networking/ip-sysctl.rst$>$ erläutert.
Kurze Antwort: Sagen Sie Y.

\paragraph{IP: multicasting}$~$\\
CONFIG\_IP\_MULTICAST [=y] \textbf{[Y]}\\
Dabei handelt es sich um einen Code zur gleichzeitigen Adressierung mehrerer vernetzter Computer,
der Ihren Kernel um etwa 2~KB vergrößert. Sie brauchen Multicasting, wenn Sie am MBONE teilnehmen
wollen, einem Netz mit hoher Bandbreite über dem Internet, das Audio- und Videoübertragungen
überträgt. Weitere Informationen über MBONE finden Sie im WWW unter
\url{https://www.savetz.com/mbone/}.
Für die meisten Leute ist es sicher, N zu sagen.

\paragraph{IP: advanced router}$~$\\
CONFIG\_IP\_ADVANCED\_ROUTER [=y] \textbf{[Y]}\\
Wenn Sie beabsichtigen, Ihren Linux-Rechner hauptsächlich als Router zu betreiben,
d.h. als Com\-pu\-ter, der Netz\-werk\-pakete weiterleitet und umverteilt, sagen Sie Y;
Ihnen werden dann mehrere Optionen angezeigt, die eine genauere Kontrolle über den
Routing"=Prozess ermöglichen.\\
Die Antwort auf diese Frage wirkt sich nicht direkt auf den Kernel aus: Wenn Sie mit N antworten,
überspringt der Konfigurator einfach alle Fragen zum erweiterten Routing.
Beachten Sie, dass Ihr Rechner nur dann als Router fungieren kann, wenn Sie die IP"=Weiterleitung
in Ihrem Kernel aktivieren; dies können Sie tun, indem Sie \glqq /proc file system support\grqq{}
und \glqq Sysctl support\grqq{} mit Y beantworten und die folgende Zeile\\[.5em]
\texttt{echo "1" > /proc/sys/net/ipv4/ip\_forward}\\[.5em]
beim Booten ausführen, nachdem das Dateisystem /proc eingehängt wurde.\\
Wenn Sie die IP-Weiterleitung einschalten, sollten Sie den rp\_filter in Betracht ziehen, der
eingehende Pakete automatisch zurückweist, wenn der Routing-Tabelleneintrag für ihre Quelladresse
nicht mit der Netzwerkschnittstelle übereinstimmt, an der sie ankommen. Dies hat
Sicherheitsvorteile, weil es das so genannte IP-Spoofing verhindert, kann aber Probleme bereiten,
wenn Sie asymmetrisches Routing verwenden (Pakete von Ihnen zu einem Host nehmen einen anderen
Weg als Pakete von diesem Host zu Ihnen) oder wenn Sie einen nicht routingfähigen Host betreiben,
der mehrere IP-Adressen auf verschiedenen Schnittstellen hat. Um rp\_filter einzuschalten,
verwenden Sie:

\texttt{echo 1 $>$ /proc/sys/net/ipv4/conf/<Gerät>/rp\_filter}\\
oder

\texttt{echo 1 $>$ /proc/sys/net/ipv4/conf/all/rp\_filter}\\
Beachten Sie, dass einige Distributionen dies in Startskripten aktivieren.
Für Details über rp\_filter strict und loose mode lesen Sie
$<$file:Documentation/networking/ip-sysctl.rst$>$. Wenn Sie unsicher sind, geben Sie hier N an.

\subparagraph{FIB TRIE statistics}$~$\\
CONFIG\_IP\_FIB\_TRIE\_STATS [=y] \textbf{[Y]}\\
Behalten Sie die Statistiken über die Struktur der FIB TRIE-Tabelle im Auge. Nützlich zum Testen
und Messen der TRIE-Leistung.

\subparagraph{IP: policy routing}$~$\\
CONFIG\_IP\_MULTIPLE\_TABLES [=y] \textbf{[Y]}\\
Normalerweise entscheidet ein Router, was mit einem empfangenen Paket zu tun ist, und zwar
ausschließlich auf der Grundlage der endgültigen Zieladresse des Pakets. Wenn Sie hier Y angeben,
kann der Linux-Router auch die Quelladresse des Pakets berücksichtigen. Darüber hinaus kann auch
das TOS-Feld (Type-Of-Service) des Pakets für Routing-Entscheidungen verwendet werden.\\
Weitere Informationen finden Sie in der Linux-Dokumentation Advanced Routing and Traffic Control
unter \url{https://lartc.org/howto/lartc.rpdb.html}.
Wenn Sie unsicher sind, sagen Sie N.

\subparagraph{IP: equal cost multipath}$~$\\
CONFIG\_IP\_ROUTE\_MULTIPATH [=y] \textbf{[Y]}\\
Normalerweise geben die Routing-Tabellen eine einzige Aktion an, die für ein bestimmtes Paket auf
deterministische Weise durchgeführt wird. Wenn Sie hier jedoch Y sagen, ist es möglich, mehrere
Aktionen an ein Paketmuster zu knüpfen und damit mehrere alternative Wege für diese Pakete
festzulegen. Der Router betrachtet alle diese Pfade als gleich teuer und wählt einen von ihnen
auf nicht-deterministische Weise aus, wenn ein passendes Paket eintrifft.

\subparagraph{IP: verbose route monitoring}$~$\\
CONFIG\_IP\_ROUTE\_VERBOSE [=y] \textbf{[Y]}\\
Wenn Sie hier Y angeben, was empfohlen wird, gibt der Kernel ausführliche Meldungen über das
Routing aus, zum Beispiel Warnungen über empfangene Pakete, die seltsam aussehen und auf einen
Angriff oder ein falsch konfiguriertes System hindeuten könnten. Die Informationen werden vom
klogd-Daemon verarbeitet, der für die Kernelmeldungen zuständig ist (\glqq man klogd\grqq{}).

\paragraph{IP: kernel level autoconfiguration}$~$\\
CONFIG\_IP\_ADVANCED\_ROUTER [=n] \textbf{[N]}\\
Dies ermöglicht die automatische Konfiguration der IP-Adressen von Geräten und der Routing-Tabelle
beim Booten des Kernels auf der Grundlage von Informationen, die entweder über die
Kernel-Befehlszeile oder über BOOTP- oder RARP-Protokolle bereitgestellt werden.
Sie müssen Y nur für plattenlose Maschinen angeben, die zum Booten Netzwerkzugriff benötigen
(in diesem Fall sollten Sie auch Y für \glqq Root file system on NFS\grqq{} angeben),
da alle anderen Maschinen das Netzwerk in ihren Startskripten konfigurieren.

\paragraph{IP: tunneling}$~$\\
CONFIG\_NET\_IPIP [=m] \textbf{[M]}\\
Tunneling bedeutet, dass Daten eines Protokolltyps in ein anderes Protokoll eingekapselt und über
einen Kanal gesendet werden, der das einkapselnde Protokoll versteht. Dieser spezielle Tunneling-Treiber
implementiert die Verkapselung von IP innerhalb von IP, was sich zwar ziemlich sinnlos anhört, aber
nützlich sein kann, wenn Sie Ihren (oder einen anderen) Rechner in einem anderen Netz erscheinen lassen
wollen, als er tatsächlich ist, oder wenn Sie die Möglichkeiten von Mobile-IP nutzen wollen
(wodurch Laptops nahtlos zwischen Netzen wechseln können, ohne ihre IP-Adressen zu ändern). Wenn Sie
diese Option mit Y bestätigen, werden zwei Module ( = Code, der in den laufenden Kernel eingefügt und
aus ihm entfernt werden kann, wann immer Sie wollen) erzeugt. Die meisten Leute werden das nicht
brauchen und können N sagen.

\paragraph{IP: GRE demultiplexer}$~$\\
CONFIG\_NET\_IPGRE\_DEMUX [=m] \textbf{[M]}\\
Dies ist ein Hilfsmodul zum Demultiplexen von GRE-Paketen anhand von GRE-Versionsfeldkriterien.
Erforderlich für die Module \texttt{ip\_gre} und \texttt{pptp}.

\paragraph{IP: GRE tunnels over IP}$~$\\
CONFIG\_NET\_IPGRE [=m] \textbf{[M]}\\
Tunneling bedeutet, dass Daten eines Protokolltyps in ein anderes Protokoll eingekapselt und
über einen Kanal gesendet werden, der das einkapselnde Protokoll versteht. Dieser spezielle
Tunneling-Treiber implementiert GRE (Generic Routing Encapsulation) und ermöglicht derzeit die
Verkapselung von IPv4 oder IPv6 über eine bestehende IPv4-Infrastruktur. Dieser Treiber ist
nützlich, wenn der andere Endpunkt ein Cisco-Router ist: Cisco mag GRE viel lieber als den
anderen Linux-Tunneltreiber (\glqq IP-Tunneling\grqq{} oben). Außerdem erlaubt GRE die
Weiterverteilung von Multicast durch den Tunnel.

\subparagraph{IP: broadcast GRE over IP}$~$\\
CONFIG\_NET\_IPGRE\_BROADCAST [=y] \textbf{[Y]}\\
Eine Anwendung von GRE/IP ist der Aufbau eines Broadcast-WAN (Wide Area Network), das wie
ein normales Ethernet-LAN (Local Area Network) aussieht, aber über das gesamte Internet
verteilt werden kann. Wenn Sie das tun wollen, sagen Sie hier und bei
\glqq IP-Multicast-Routing\grqq{} unten Y.

\paragraph{IP: multicast routing}$~$\\
CONFIG\_IP\_MROUTE [=y] \textbf{[Y]}\\
Dies wird verwendet, wenn Ihr Rechner als Router für IP-Pakete mit mehreren Zieladressen
fungieren soll. Er wird für das MBONE benötigt, ein Netzwerk mit hoher Bandbreite über dem
Internet, das Audio- und Videoübertragungen überträgt. Um dies zu tun, würden Sie
wahrscheinlich das Programm \texttt{mrouted} ausführen. Wenn Sie davon noch nichts gehört
haben, brauchen Sie es nicht.

\subparagraph{IP: multicast policy routing}$~$\\
CONFIG\_IP\_MROUTE\_MULTIPLE\_TABLES [=y] \textbf{[Y]}\\
Normalerweise führt ein Multicast-Router einen Userspace-Daemon aus und entscheidet auf der
Grundlage der Quell- und Zieladressen, was mit einem Multicast-Paket geschehen soll.
Wenn Sie hier Y angeben, kann der Multicast-Router auch Schnittstellen und Paketmarkierungen
berücksichtigen und mehrere Instanzen von Userspace-Dämonen gleichzeitig laufen lassen, von
denen jeder eine einzelne Tabelle bearbeitet.
Wenn Sie unsicher sind, sagen Sie N.

\subparagraph{IP: PIM-SM version 1 support}$~$\\
CONFIG\_IP\_PIMSM\_V1 [=y] \textbf{[Y]}\\
Kernelseitige Unterstützung für Sparse Mode PIM (Protocol Independent Multicast) Version 1.
Dieses Multicast-Routing-Protokoll ist weit verbreitet, da Cisco es unterstützt.
Sie benötigen eine spezielle Software, um es zu verwenden (pimd-v1).\\
Weitere Informationen
über PIM finden Sie unter \url{http://netweb.usc.edu/pim/}. Sagen Sie Y, wenn Sie
PIM-SM~v1 verwenden wollen. Beachten Sie, dass Sie hier N sagen können, wenn Sie nur
Dense Mode PIM verwenden wollen.

\subparagraph{IP: PIM-SM version 2 support}$~$\\
CONFIG\_IP\_PIMSM\_V2 [=y] \textbf{[Y]}\\
Kernelseitige Unterstützung für Sparse Mode PIM Version 2. Um dies nutzen zu können, benötigen
Sie einen experimentellen Routing-Daemon, der dies unterstützt (pimd oder gated-5). Dieses
Routing-Protokoll ist nicht weit verbreitet, also sagen Sie N, es sei denn, Sie wollen
damit spielen.

\paragraph{IP: TCP syncookie support}$~$\\
CONFIG\_SYN\_COOKIES [=y] \textbf{[Y]}\\
Normale TCP/IP-Netzwerke sind anfällig für einen Angriff, der als "SYN-Flooding" bekannt ist.
Dieser Denial-of-Service-Angriff verhindert, dass legitime Remote-Benutzer während eines laufenden
Angriffs eine Verbindung zu Ihrem Computer herstellen können, und erfordert vom Angreifer, der von
einem beliebigen Ort im Internet aus operieren kann, nur sehr wenig Arbeit. SYN-Cookies bieten
Schutz gegen diese Art von Angriffen. Wenn Sie hier "Y" eingeben, verwendet der TCP/IP-Stack ein
kryptografisches Herausforderungsprotokoll, das als "SYN-Cookies" bekannt ist, um legitime Benutzer
in die Lage zu versetzen, weiterhin eine Verbindung herzustellen, selbst wenn Ihr Rechner angegriffen
wird.
Die rechtmäßigen Benutzer brauchen ihre TCP/IP-Software nicht zu ändern; SYN-Cookies arbeiten für sie
transparent. Technische Informationen über SYN-Cookies finden Sie unter
\url{https://cr.yp.to/syncookies.html}. Wenn Sie SYN-geflutet werden, ist die vom Kernel gemeldete
Quelladresse wahrscheinlich vom Angreifer gefälscht worden; sie wird nur als Hilfe bei der Rückverfolgung
der Pakete zu ihrer tatsächlichen Quelle gemeldet und sollte nicht als absolute Wahrheit angesehen werden.
SYN-Cookies können eine korrekte Fehlermeldung auf Clients verhindern, wenn der Server wirklich überlastet
ist. Wenn dies häufig vorkommt, schalten Sie sie besser aus. Wenn Sie hier Y angeben, können Sie
SYN-Cookies zur Laufzeit deaktivieren, indem Sie Y zu \glqq /proc file system support\grqq{} und
\glqq Sysctl support\grqq{}
unten angeben und den Befehl \texttt{echo 0 $>$ /proc/sys/net/ipv4/tcp\_syncookies} ausführen
nachdem das /proc-Dateisystem eingehängt wurde. Wenn Sie unsicher sind, sagen Sie N.

\paragraph{Virtual (secure) IP: tunneling}$~$\\
CONFIG\_NET\_IPVTI [=m] \textbf{[M]}\\
Tunneling bedeutet, dass Daten eines Protokolltyps in ein anderes Protokoll eingekapselt und über einen
Kanal gesendet werden, der das einkapselnde Protokoll versteht. Dies kann mit xfrm mode tunnel
verwendet werden, um die Vorstellung eines sicheren Tunnels für IPSEC zu vermitteln und dann ein
Routing-Protokoll darüber zu legen.

\paragraph{IP: Foo (IP protocols) over UDP}$~$\\
CONFIG\_NET\_FOU [=m] \textbf{[M]}\\
Mit Foo over UDP kann jedes IP-Protokoll direkt über UDP gekapselt werden, einschließlich Tunneln
(IPIP, GRE, SIT). Durch die Verkapselung in UDP können Netzwerkmechanismen und Optimierungen für UDP
(wie ECMP und RSS) genutzt werden, um einen besseren Service zu bieten.

\paragraph{IP: FOU encapsulation of IP tunnels}$~$\\
CONFIG\_NET\_FOU\_IP\_TUNNELS [=y] \textbf{[Y]}\\
Ermöglicht die Konfiguration von FOU- oder GUE-Kapselung für IP-Tunnel. Wenn diese Option aktiviert ist,
können IP-Tunnel für die Verwendung von FOU- oder GUE-Kapselung konfiguriert werden.

\paragraph{IP: AH transformation}$~$\\
CONFIG\_INET\_AH [=m] \textbf{[M]}\\
Unterstützung für IPsec AH (Authentication Header).
AH kann mit verschiedenen Authentifizierungsalgorithmen verwendet werden. Diese Option aktiviert nicht
nur die AH-Unterstützung selbst, sondern auch die generischen Implementierungen der Algorithmen, die
nach RFC~8221 implementiert werden MÜSSEN. Wenn Sie andere Algorithmen benötigen, müssen Sie diese in
der Krypto-API aktivieren. Sie sollten auch beschleunigte Implementierungen aller benötigten Algorithmen
aktivieren, sofern verfügbar.
Wenn Sie unsicher sind, sagen Sie Y.

\paragraph{IP: ESP transformation}$~$\\
CONFIG\_INET\_ESP [=m] \textbf{[M]}\\
Unterstützung für IPsec ESP (Encapsulating Security Payload).
ESP kann mit verschiedenen Verschlüs\-selungs- und Authentifizierungsalgorithmen verwendet werden. Diese
Option aktiviert nicht nur die ESP"=Unterstützung selbst, sondern auch die generischen Implementierungen
der Algorithmen, die nach RFC~8221 implementiert werden MÜSSEN. Wenn Sie andere Algorithmen benötigen,
müssen Sie diese in der Krypto-API aktivieren. Sie sollten auch beschleunigte Implementierungen aller
benötigten Algorithmen aktivieren, sofern verfügbar. Wenn Sie unsicher sind, sagen Sie Y.

\subparagraph{IP: ESP transformation offload}$~$\\
CONFIG\_INET\_ESP\_OFFLOAD [=m] \textbf{[M]}\\
Unterstützung für ESP-Transformationsoffload. Dies ist nur dann sinnvoll, wenn das System wirklich IPsec
verwendet und einen hohen Durchsatz erzielen möchte. Ein typisches Desktop-System braucht dies nicht,
selbst wenn es IPsec verwendet.
Wenn Sie unsicher sind, sagen Sie N.

\subparagraph{IP: ESP in TCP encapsulation (RFC~8229)}$~$\\
CONFIG\_INET\_ESPINTCP [=y] \textbf{[Y]}\\
Unterstützung für die RFC~8229-Kapselung von ESP und IKE über TCP/IPv4-Sockets.
Wenn Sie unsicher sind, sagen Sie N.

\paragraph{IP: IPComp transformation}$~$\\
CONFIG\_INET\_IPCOMP [=m] \textbf{[M]}\\
Unterstützung für das IP Payload Compression Protocol
(IPComp) (RFC~3173), das normalerweise für IPsec benötigt wird.\\
Wenn Sie unsicher sind, sagen Sie Y.

\paragraph{INET: socket monitoring interface}$~$\\
CONFIG\_INET\_DIAG [=m] \textbf{[M]}\\
Unterstützung für die INET (TCP, DCCP usw.) Socket"=Überwachungsschnittstelle, die von nativen Linux"=Tools
wie \texttt{ss} verwendet wird. \texttt{ss} ist in iproute2 enthalten und kann derzeit heruntergeladen werden
unter: \url{http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2}\\ 
Wenn Sie unsicher sind, sagen Sie Y.

\subparagraph{UDP: socket monitoring interface}$~$\\
CONFIG\_INET\_UDP\_DIAG [=m] \textbf{[M]}\\
Unterstützung für die UDP-Socket-Überwachungsschnittstelle, die vom Tool \texttt{ss} verwendet wird. 
Wenn Sie unsicher sind, sagen Sie Y.

\subparagraph{RAW: socket monitoring interface}$~$\\
CONFIG\_INET\_RAW\_DIAG [=m] \textbf{[M]}\\
Unterstützung für die vom \texttt{ss}-Tool verwendete RAW-Socket-Überwachungsschnittstelle.
Wenn Sie unsicher sind, sagen Sie Y.

\subparagraph{INET: allow privileged process to administratively close sockets}$~$\\
CONFIG\_INET\_DIAG\_DESTROY [=y] \textbf{[Y]}\\
Stellt eine SOCK\_DESTROY-Operation zur Verfügung, die es privilegierten Prozessen (z.~B. einem
Verbindungsmanager oder einem Netzwerkverwaltungsprogramm wie \texttt{ss}) ermöglicht, von anderen Prozessen
geöffnete Sockets zu schließen. Das Schließen eines Sockets auf diese Weise unterbricht alle blockierenden
Lese-/Schreib-/Verbindungsoperationen auf dem Socket und bewirkt, dass sich zukünftige Socket-Aufrufe so
verhalten, als ob der Socket getrennt worden wäre. Wenn Sie unsicher sind, sagen Sie N.

\paragraph{TCP: advanced congestion control \texorpdfstring{$\rightarrow$}{->}}$~$\\
CONFIG\_TCP\_CONG\_ADVANCED [=y] \textbf{[Y]}\\
Unterstützung für die Auswahl verschiedener TCP-Staukontrollmodule. Fast alle Benutzer können hier sicher nein
sagen, und es wird eine sichere Standardauswahl getroffen (CUBIC mit neuem Reno als Fallback).
Wenn Sie unsicher sind, sagen Sie N.

\subparagraph{Binary Increase Congestion (BIC) control}$~$\\
CONFIG\_TCP\_CONG\_BIC [=m] \textbf{[M]}\\
BIC-TCP ist eine rein senderseitige Änderung, die eine lineare RTT-Fairness bei großen Fenstern gewähr"-lei"-stet
und gleichzeitig Skalierbarkeit und begrenzte TCP-Freundlichkeit bietet. Das Protokoll kombiniert zwei
Verfahren, die additive Erhöhung und die binäre Sucherhöhung. Bei großen Überlastungsfenstern ge"-währ"-lei"-stet
die additive Erhöhung mit einem großen Inkrement eine lineare RTT-Fairness sowie eine gute Skalierbarkeit.
Bei kleinen Überlastungsfenstern sorgt die binäre Sucherhöhung für TCP-Freundlichkeit.\\
Siehe \url{http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/} 

\subparagraph{CUBIC TCP}$~$\\
CONFIG\_TCP\_CONG\_CUBIC [=y] \textbf{[Y]}\\
Dies ist die Version 2.0 von BIC-TCP, die neben anderen Techniken eine kubische Wachstumsfunktion verwendet.\\
Siehe \url{http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/cubic-paper.pdf}

\subparagraph{TCP Westwood+}$~$\\
CONFIG\_TCP\_CONG\_WESTWOOD [=m] \textbf{[M]}\\
TCP Westwood+ ist eine absenderseitige Modifikation des TCP-Reno-Protokollstapels, die die Leistung der
TCP-Überlastungssteuerung optimiert. Es basiert auf einer Ende-zu-Ende-Bandbreitenschätzung, um das
Überlastungsfenster und den Schwellenwert für den langsamen Start nach einer Überlastungsepisode festzulegen.
Auf der Grundlage dieser Schätzung legt TCP Westwood+ adaptiv einen Schwellenwert für den langsamen Start und
ein Überlastungsfenster fest, das die zum Zeitpunkt des Auftretens der Überlastung genutzte Bandbreite
berücksichtigt. TCP Westwood+ erhöht die Fairness gegenüber TCP Reno in kabelgebundenen Netzen und den
Durchsatz über drahtlose Verbindungen erheblich.

\subparagraph{H-TCP}$~$\\
CONFIG\_TCP\_CONG\_HTCP [=m] \textbf{[M]}\\*
H-TCP ist eine nur sendeseitige Modifikation des TCP-Reno-Protokollstapels, die die Leistung der
TCP-Überlastungssteuerung für Hochgeschwindigkeitsnetzverbindungen optimiert. Es verwendet einen Mode\-switch,
um die Alpha- und Beta-Parameter von TCP Reno auf der Grundlage der Netzbedingungen und in einer Weise zu
ändern, die gegenüber anderen Reno- und H-TCP-Datenströmen fair ist.

\subparagraph{High Speed TCP}$~$\\
CONFIG\_TCP\_CONG\_HSTCP [=m] \textbf{[M]}\\*
Sally Floyds High Speed TCP (RFC~3649) Staukontrolle. Eine Modifikation des
TCP"=Über"-lastungs"-steuerungs"-mechanismus
zur Verwendung mit großen Überlastungsfenstern. In einer Tabelle wird angegeben, um wie viel das
Überlastungsfenster vergrößert werden soll, wenn eine ACK empfangen wird.
Für weitere Einzelheiten siehe \url{https://www.icir.org/floyd/hstcp.html}

\subparagraph{TCP-Hybla congestion control algorithm}$~$\\
CONFIG\_TCP\_CONG\_HYBLA [=m] \textbf{[M]}\\*
TCP-Hybla ist eine Änderung, die nur auf der Absenderseite vorgenommen wird, um die Benachteiligung von
Verbindungen mit langen Übertragungszeiten und großen Bandbreiten zu beseitigen, z.~B. wenn
Satellitenverbindungen beteiligt sind, insbesondere wenn sie einen gemeinsamen Engpass mit normalen
terrestrischen Verbindungen teilen.

\subparagraph{TCP Vegas}$~$\\
CONFIG\_TCP\_CONG\_VEGAS [=m] \textbf{[M]}\\*
TCP Vegas ist eine absenderseitige Änderung von TCP, die den Beginn einer Überlastung durch Schät"-zung der
Bandbreite vorwegnimmt. TCP Vegas passt die Übertragungsrate durch Änderung des Über"-las"-tungs"-fens"-ters an.
TCP Vegas sollte weniger Paketverluste verursachen, ist aber nicht so aggressiv wie TCP Reno.

\subparagraph{TCP NV}$~$\\
CONFIG\_TCP\_CONG\_NV [=m] \textbf{[M]}\\*
TCP NV ist ein Nachfolger von TCP Vegas. Es wurde geändert, um mit 10G-Netzen, Messrauschen durch LRO, GRO und
Unterbrechungskoaleszenz fertig zu werden. Außerdem wird der cwnd-Wert nicht mehr linear, sondern multiplikativ
verringert.\\
Es ist zu beachten, dass die Stauvermeidung (cwnd wird verringert, wenn die Anzahl der Pakete in der
Warteschlange steigt) im Allgemeinen nicht mit der Staukontrolle (cwnd wird nur verringert, wenn es zu
Paketverlusten kommt) koexistieren kann, da die Fairness nicht gewährleistet ist. Ein Szenario, in dem sie
sicher koexistieren können, ist, wenn die CA-Flüsse RTTs~$\ll$~CC-Flüsse RTTs haben.
Für weitere Einzelheiten siehe \url{http://www.brakmo.org/networking/tcp-nv/}

\subparagraph{Scalable TCP}$~$\\
CONFIG\_TCP\_CONG\_SCALABLE [=m] \textbf{[M]}\\*
Scalable TCP ist eine Änderung von TCP nur auf der Absenderseite, die einen MIMD-Algorithmus zur Staukontrolle
verwendet, der einige nette Skalierungseigenschaften hat, obwohl er bekanntermaßen Probleme mit der Fairness hat.
Siehe \url{http://www.deneholme.net/tom/scalable/}

\subparagraph{TCP Low Priority}$~$\\
CONFIG\_TCP\_CONG\_LP [=m] \textbf{[M]}\\*
TCP Low Priority (TCP-LP), ein verteilter Algorithmus, dessen Ziel es ist, nur die überschüssige Bandbreite des
Netzes im Vergleich zum \glqq fairen Anteil\grqq{} der Bandbreite, wie er von TCP angestrebt wird, zu nutzen.
Siehe \url{http://www-ece.rice.edu/networks/TCP-LP/}

\subparagraph{TCP Veno}$~$\\
CONFIG\_TCP\_CONG\_VENO [=m] \textbf{[M]}\\*
TCP Veno ist eine rein senderseitige Erweiterung von TCP, um einen besseren Durchsatz in drahtlosen Netzen zu
erzielen. TCP Veno nutzt die Zustandsunterscheidung, um die schwierige Beurteilung der Paketverlustart zu umgehen.
TCP Veno verkleinert das Überlastungsfenster als Reaktion auf zufällige Paketverluste.
Siehe \url{http://ieeexplore.ieee.org/xpl/freeabs\_all.jsp?arnumber=1177186}

\subparagraph{YeAH TCP}$~$\\
CONFIG\_TCP\_CONG\_YEAH [=m] \textbf{[M]}\\*
YeAH-TCP ist ein absenderseitiger Hochgeschwindigkeits"=TCP"=Überlastungskontrollalgorithmus, der ei"-nen gemischten
Verlust-/Verzögerungsansatz zur Berechnung des Überlastungsfensters verwendet. Seine Entwurfsziele sind hohe
Effizienz, interne, RTT- und Reno-Fairness, Widerstandsfähigkeit gegenüber Verbindungsverlusten und eine möglichst
geringe Belastung der Netzelemente.\\
Weitere Einzelheiten finden Sie hier:
\url{http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf} or
\href{https://www.gdt.id.au/~gdt/presentations/2010-07-06-questnet-tcp/reference-materials/papers/baiocchi+castellani+vacirca-yeah-tcp-yet-another-highspeed-tcp.pdf}
{Link via www.gdt.id.au}

\subparagraph{TCP Illinois}$~$\\
CONFIG\_TCP\_CONG\_ILLINOIS [=m] \textbf{[M]}\\*
TCP-Illinois ist eine absenderseitige Modifikation von TCP Reno für Hochgeschwindigkeitsverbindungen mit langer
Verzögerung. Es nutzt die Round-Trip-Zeit, um die Alpha- und Beta-Parameter anzupassen, um einen höheren
durchschnittlichen Durchsatz zu erreichen und Fairness zu wahren.
Für weitere Einzelheiten siehe: \url{http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html}

\end{document}
