CHG structuring sources

documentation/linux_configuration.pdf

@@ -1,3 +1,3 @@
 version https://git-lfs.github.com/spec/v1
-oid sha256:301ce743a1da7b6fb2861bad67e349f700eedff69ccb68d069f709f2d1e7cb4b
+oid sha256:24cbec42a594c8600ef9d336f31e1c3bd77d446b344f6d9a6c987a185be8c421
-size 951587
+size 951596

documentation/linux_configuration_02_64-bit_kernel.tex

@@ -0,0 +1,4 @@
+\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

documentation/linux_configuration_03_processor_type_and_features.tex

@@ -0,0 +1,879 @@
+\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.

documentation/linux_configuration_04_mitigations_for_speculative_execution_vulnerabilities.tex

@@ -0,0 +1,74 @@
+
+\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.

documentation/linux_configuration_05_power_management_and_acpi_options.tex

@@ -0,0 +1,679 @@
+
+\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 \texttt{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)\\
+Bereich (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.

documentation/linux_configuration_06_bus_options.tex

@@ -0,0 +1,7 @@
+\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.}

documentation/linux_configuration_07_binary_emulations.tex

@@ -0,0 +1,14 @@
+\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.

documentation/linux_configuration_08_virtualization.tex

@@ -0,0 +1,53 @@
+
+\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.

documentation/linux_configuration_09_general_architecture-dependent_options.tex

@@ -0,0 +1,164 @@
+\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}

documentation/linux_configuration_10_enable_loadable_module_support.tex

@@ -0,0 +1,158 @@
+\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).

documentation/linux_configuration_11_enable_the_block_layer.tex

@@ -0,0 +1,293 @@
+\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.

documentation/linux_configuration_12_executable_file_formats.tex

@@ -0,0 +1,64 @@
+\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.

documentation/linux_configuration_13_memory_management_options.tex

@@ -0,0 +1,492 @@
+\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.