UPD Memory Management options
This commit is contained in:
Binary file not shown.
@@ -3047,7 +3047,7 @@ Kernel-Code hinzu. Wenn Sie N sagen, werden alle Optionen in diesem Untermenü
|
|||||||
und deaktiviert.
|
und deaktiviert.
|
||||||
|
|
||||||
\subsection{Kernel-based Virtual Machine (KVM) support}
|
\subsection{Kernel-based Virtual Machine (KVM) support}
|
||||||
CONFIG\_KVM [=y] \textbf{[Y]}\\
|
CONFIG\_KVM [=m] \textbf{[M]}\\
|
||||||
Unterstützung für das Hosten vollständig virtualisierter Gastmaschinen mit
|
Unterstützung für das Hosten vollständig virtualisierter Gastmaschinen mit
|
||||||
Hardware-Vir\-tuali\-sierungs\-er\-wei\-terungen. Sie benötigen einen relativ aktuellen Prozessor mit
|
Hardware-Vir\-tuali\-sierungs\-er\-wei\-terungen. Sie benötigen einen relativ aktuellen Prozessor mit
|
||||||
Vir\-tuali\-sierungs\-er\-wei\-ter\-ungen. Außerdem müssen Sie eines oder mehrere der unten aufgeführten
|
Vir\-tuali\-sierungs\-er\-wei\-ter\-ungen. Außerdem müssen Sie eines oder mehrere der unten aufgeführten
|
||||||
@@ -3056,4 +3056,837 @@ Prozessormodule auswählen. Dieses Modul ermöglicht den Zugriff auf die Hardwar
|
|||||||
Das Modul wird \texttt{kvm} heißen.\\
|
Das Modul wird \texttt{kvm} heißen.\\
|
||||||
Wenn Sie unsicher sind, sagen Sie N.
|
Wenn Sie unsicher sind, sagen Sie N.
|
||||||
|
|
||||||
|
\subsubsection{KVM for Intel (and compatible) processors support}
|
||||||
|
CONFIG\_KVM\_INTEL [=m] \textbf{[M]}\\
|
||||||
|
Bietet Unterstützung für KVM auf Prozessoren, die mit Intels VT-Erweiterungen, auch bekannt
|
||||||
|
als Virtual Machine Extensions (VMX), ausgestattet sind.
|
||||||
|
Um dies als Modul zu kompilieren, wählen Sie hier M: das Modul wird \texttt{kvm-intel} genannt.
|
||||||
|
|
||||||
|
\paragraph{Software Guard eXtension (SGX) Virtualization}$~$\\
|
||||||
|
CONFIG\_X86\_SGX\_KVM [=y] \textbf{[Y]}\\
|
||||||
|
Ermöglicht KVM-Gästen, SGX-Enklaven zu erstellen. Dies schließt die Unterstützung ein,
|
||||||
|
\glqq rohen\grqq{}, nicht wiederverwendbaren Enklavenspeicher für Gäste über einen Geräteknoten,
|
||||||
|
z.B. /dev/sgx\_vepc, freizugeben. Wenn Sie unsicher sind, sagen Sie N.
|
||||||
|
|
||||||
|
\subsubsection{KVM for AMD processors support}
|
||||||
|
CONFIG\_KVM\_AMD [=m] \textbf{[M]}\\
|
||||||
|
Bietet Unterstützung für KVM auf Prozessoren, die mit Intels VT-Erweiterungen, auch bekannt
|
||||||
|
Bietet Unterstützung für KVM auf AMD-Prozessoren, die mit den AMD-V (SVM)-Erweiterungen
|
||||||
|
ausgestattet sind. Um dies als Modul zu kompilieren, wählen Sie hier M:
|
||||||
|
Das Modul wird \texttt{kvm-amd} genannt.
|
||||||
|
|
||||||
|
\paragraph{AMD Secure Encrypted Virtualization (SEV) support}$~$\\
|
||||||
|
CONFIG\_KVM\_AMD\_SEV [=y] \textbf{[N]}\\
|
||||||
|
Bietet Unterstützung für den Start von verschlüsselten VMs (SEV) und verschlüsselten VMs
|
||||||
|
mit verschlüsseltem Status (SEV-ES) auf AMD-Prozessoren.
|
||||||
|
|
||||||
|
\subsubsection{System Management Mode emulation}
|
||||||
|
CONFIG\_KVM\_SMM [=y] \textbf{[Y]}\\
|
||||||
|
Bietet Unterstützung für KVM zur Emulation des Systemverwaltungsmodus (SMM) in virtuellen
|
||||||
|
Maschinen. Dies kann von der Firmware der virtuellen Maschine verwendet werden, um UEFI Secure
|
||||||
|
Boot zu implementieren.
|
||||||
|
|
||||||
|
\subsubsection{Support for Xen hypercall interface}
|
||||||
|
CONFIG\_KVM\_XEN [=y] \textbf{[Y]}\\
|
||||||
|
Bietet KVM-Unterstützung für das Hosten von Xen HVM-Gästen und die Weitergabe von
|
||||||
|
Xen-Hyper\-auf\-rufen an den Userspace. Im Zweifelsfall sagen Sie N.
|
||||||
|
|
||||||
|
\section{General architecture-dependent options \texorpdfstring{$\rightarrow$}{->}}
|
||||||
|
(Allgemeine architekturabhängige Optionen)
|
||||||
|
|
||||||
|
\subsection{Kprobes}
|
||||||
|
CONFIG\_KPROBES [=y] \textbf{[Y]}\\
|
||||||
|
Mit Kprobes können Sie an fast jeder Kerneladresse trappen und eine Callback-Funktion ausführen.
|
||||||
|
register\_kprobe() legt einen Probepoint fest und spezifiziert den Callback.
|
||||||
|
Kprobes ist nützlich für Kernel-Debugging, nicht-intrusive Instrumentierung und Tests.\\
|
||||||
|
Im Zweifelsfall sagen Sie "N".
|
||||||
|
|
||||||
|
\subsection{Optimize very unlikely/likely branches}
|
||||||
|
CONFIG\_JUMP\_LABEL [=y] \textbf{[Y]}\\
|
||||||
|
Diese Option ermöglicht eine transparente Verzweigungsoptimierung, die die Ausführung bestimmter
|
||||||
|
fast-immer-wahrer oder fast-immer-falscher Verzweigungsbedingungen im Kernel noch billiger macht.
|
||||||
|
Bestimmte leistungsempfindliche Kernel-Codes wie Trace-Points, Scheduler-Funktionen, Netzwerk-Code
|
||||||
|
und KVM haben solche Verzweigungen und bieten Unterstützung für diese Optimierungstechnik.
|
||||||
|
Wenn festgestellt wird, dass der Compiler \glqq asm goto\grqq{} unterstützt, kompiliert der Kernel
|
||||||
|
solche Verzweigungen mit einer einfachen nop-Anweisung. Wenn das Bedingungsflag auf true gesetzt wird,
|
||||||
|
wird der nop-Befehl in einen Sprungbefehl umgewandelt, um den bedingten Befehlsblock auszuführen.
|
||||||
|
Diese Technik senkt den Overhead und die Belastung der Verzweigungsvorhersage des Prozessors und macht
|
||||||
|
den Kernel im Allgemeinen schneller. Die Aktualisierung der Bedingung ist zwar langsamer, aber das
|
||||||
|
kommt immer sehr selten vor. (Bei 32-Bit-x86 können die erforderlichen Optionen, die zu den
|
||||||
|
Compiler-Flags hinzugefügt werden, die Größe des Kernels leicht erhöhen).
|
||||||
|
|
||||||
|
\subsubsection{Static key selftest}
|
||||||
|
CONFIG\_STATIC\_KEYS\_SELFTEST [=n] \textbf{[N]}\\
|
||||||
|
Bootzeit-Selbsttest des Branch-Patching-Codes.
|
||||||
|
|
||||||
|
\subsection{Static call selftest}
|
||||||
|
CONFIG\_STATIC\_CALL\_SELFTEST [=n] \textbf{[N]}\\
|
||||||
|
Bootzeit-Selbsttest des Call-Patching-Codes.
|
||||||
|
|
||||||
|
\subsection{Enable seccomp to safely execute untrusted bytecode}
|
||||||
|
CONFIG\_SECCOMP [=n] \textbf{[N]}\\
|
||||||
|
Diese Kernel-Funktion ist nützlich für numerische Anwendungen, die während ihrer Ausführung
|
||||||
|
mit nicht vertrauenswürdigem Bytecode umgehen müssen. Durch die Verwendung von Pipes oder anderen
|
||||||
|
Transporten, die dem Prozess als Dateideskriptoren zur Verfügung gestellt werden und die
|
||||||
|
Lese-/Schreib-Syscalls unterstützen, ist es möglich, diese Anwendungen mit seccomp in ihrem eigenen
|
||||||
|
Adressraum zu isolieren. Sobald seccomp über prctl(PR\_SET\_SECCOMP) oder den seccomp()-Syscall
|
||||||
|
aktiviert ist, kann es nicht mehr deaktiviert werden, und die Task darf nur einige wenige sichere
|
||||||
|
Syscalls ausführen, die für jeden seccomp-Modus definiert sind. Wenn Sie unsicher sind, sagen Sie Y.
|
||||||
|
|
||||||
|
\subsubsection{Show seccomp filter cache status in /proc/pid/seccomp\_cache}
|
||||||
|
CONFIG\_SECCOMP\_CACHE\_DEBUG [=n] \textbf{[N]}\\
|
||||||
|
Dies ermöglicht der Schnittstelle /proc/pid/seccomp\_cache die Überwachung der
|
||||||
|
seccomp-Cache-Daten. Das Dateiformat kann sich ändern. Zum Lesen der Datei ist
|
||||||
|
CAP\_SYS\_ADMIN erforderlich. Diese Option ist nur zur Fehlersuche gedacht.
|
||||||
|
Die Aktivierung birgt das Risiko, dass ein Angreifer die seccomp-Filterlogik ableiten kann.\\
|
||||||
|
Wenn Sie unsicher sind, sagen Sie N.
|
||||||
|
|
||||||
|
\subsection{Stack Protector buffer overflow detection}
|
||||||
|
CONFIG\_STACKPROTECTOR [=y] \textbf{[Y]}\\
|
||||||
|
Diese Option schaltet die GCC-Funktion \glqq stack-protector\grqq{} ein.
|
||||||
|
Diese Funktion legt am Anfang von Funktionen einen Kanarienvogelwert auf den Stack kurz vor der
|
||||||
|
Rücksprungadresse und überprüft den Wert kurz vor der eigentlichen Rückkehr. Stack-basierte
|
||||||
|
Pufferüberläufe (die diese Rücksprungadresse überschreiben müssen) überschreiben nun auch den
|
||||||
|
Canary-Wert, was erkannt wird und der Angriff wird dann durch eine Kernel-Panik neutralisiert.
|
||||||
|
Bei Funktionen, die ein 8-Byte- oder größeres Zeichenarray auf dem Stack haben, wird die Logik
|
||||||
|
des Stack-Protector-Canarys hinzugefügt. Diese Funktion erfordert gcc Version 4.2 oder höher,
|
||||||
|
oder eine gcc-Distribution, die die Funktion zurückportiert hat (\texttt{-fstack-protector}).
|
||||||
|
Auf einem x86-\glqq defconfig\grqq{}-Build fügt diese Funktion Canary-Prüfungen zu etwa
|
||||||
|
3\% aller Kernel-Funktionen hinzu, was die Kernel-Codegröße um etwa 0,3\% erhöht.
|
||||||
|
|
||||||
|
\subsubsection{Strong Stack Protector}
|
||||||
|
CONFIG\_STACKPROTECTOR\_STRONG [=y] \textbf{[Y]}\\
|
||||||
|
Bei Funktionen wird die Stack-Protector-Canary-Logik unter einer der folgenden Bedingungen hinzugefügt:
|
||||||
|
\begin{itemize}
|
||||||
|
\item[-] die Adresse einer lokalen Variablen wird als Teil der rechten Seite einer Zuweisung oder eines
|
||||||
|
Funktionsarguments verwendet
|
||||||
|
\item[-] die lokale Variable ist ein Array (oder eine Union, die ein Array enthält), unabhängig von Typ oder Länge des Arrays
|
||||||
|
\item[-] Lokale Variablen werden als Register verwendet
|
||||||
|
\end{itemize}
|
||||||
|
Diese Funktion erfordert gcc Version 4.9 oder höher, oder eine gcc-Distribution, die die Funktion
|
||||||
|
zurück\-por\-tiert hat (\texttt{-fstack-protector-strong}).
|
||||||
|
Auf einem x86-\glqq defconfig\grqq{}-Build fügt diese Funktion Canary-Prüfungen zu etwa 20\% aller
|
||||||
|
Kernel-Funktionen hinzu, was die Größe des Kernel-Codes um etwa 2\% erhöht.
|
||||||
|
|
||||||
|
\subsection{Link Time Optimization (LTO) () \texorpdfstring{$\rightarrow$}{->}}
|
||||||
|
|
||||||
|
\subsubsection{None}
|
||||||
|
CONFIG\_LTO\_NONE [=y] \textbf{[Y]}\\
|
||||||
|
Erstellen Sie den Kernel normal, ohne Link Time Optimization (LTO).
|
||||||
|
|
||||||
|
\subsection{Provide system calls for 32-bit time\_t}
|
||||||
|
CONFIG\_COMPAT\_32BIT\_TIME [=y] \textbf{[Y]}\\
|
||||||
|
Dies ermöglicht die Unterstützung von 32 Bit time\_t zusätzlich zur Unterstützung von
|
||||||
|
64~Bit time\_t. Dies ist auf allen 32-Bit-Architekturen und 64-Bit-Architekturen als Teil
|
||||||
|
der Kompatibilitäts-Syscall-Behandlung relevant.
|
||||||
|
|
||||||
|
\subsection{Use a virtually-mapped stack}
|
||||||
|
CONFIG\_VMAP\_STACK [=y] \textbf{[Y]}\\
|
||||||
|
Aktivieren Sie dies, wenn Sie virtuell gemappte Kernel-Stacks mit Guard Pages verwenden wollen.
|
||||||
|
Dies führt dazu, dass Kernel-Stack-Überläufe sofort abgefangen werden und keine schwer zu
|
||||||
|
diagnostizierende Korruption verursachen. Um dies mit Software-KASAN-Modi zu verwenden, muss die
|
||||||
|
Architektur die Unterstützung von virtuellen Mappings mit echtem Schattenspeicher unterstützen
|
||||||
|
und KASAN\_VMALLOC muss aktiviert sein.
|
||||||
|
|
||||||
|
\subsection{Support for randomizing kernel stack offset on syscall entry}
|
||||||
|
CONFIG\_RANDOMIZE\_KSTACK\_OFFSET [=y] \textbf{[Y]}\\
|
||||||
|
Der Kernel-Stack-Offset kann (nach pt\_regs) mit etwa 5~Bits Entropie randomisiert werden,
|
||||||
|
wodurch Angriffe auf Speicherbeschädigung vereitelt werden, die auf Stack-Adress-Determinismus
|
||||||
|
oder auf die Offenlegung der Adressen von Cross-Syscalls angewiesen sind.
|
||||||
|
Die Funktion wird über den Kernel-Boot-Parameter \texttt{randomize\_kstack\_offset=on/off} gesteuert
|
||||||
|
und hat, wenn sie ausgeschaltet ist, aufgrund der Verwendung von statischen Verzweigungen
|
||||||
|
(siehe JUMP\_LABEL) keinen Overhead.\\
|
||||||
|
Wenn Sie unsicher sind, sagen Sie Y.
|
||||||
|
|
||||||
|
\subsubsection{Default state of kernel stack offset randomization}
|
||||||
|
CONFIG\_RANDOMIZE\_KSTACK\_OFFSET\_DEFAULT [=y] \textbf{[Y]}\\
|
||||||
|
Die Randomisierung des Kernel-Stack-Offsets wird durch den Kernel-Boot-Parameter\\
|
||||||
|
\texttt{randomize\_kstack\_offset=on/off} gesteuert, und diese Konfiguration wählt den
|
||||||
|
Standard-Boot-Status.
|
||||||
|
|
||||||
|
\subsection{Locking event counts collection}
|
||||||
|
CONFIG\_LOCK\_EVENT\_COUNTS [=y] \textbf{[Y]}\\
|
||||||
|
Ermöglicht eine leichtgewichtige Zählung verschiedener sperrungsbezogener Ereignisse im System
|
||||||
|
mit minimalen Auswirkungen auf die Leistung. Dies verringert die Wahrscheinlichkeit, dass sich
|
||||||
|
das Anwendungsverhalten aufgrund von Zeitunterschieden ändert. Die Zählungen werden über
|
||||||
|
debugfs gemeldet.
|
||||||
|
|
||||||
|
\subsection{GCOV-based kernel profiling \texorpdfstring{$\rightarrow$}{->}}
|
||||||
|
(GCOV-basierte Kernel-Profilierung)
|
||||||
|
|
||||||
|
\subsubsection{Enable gcov-based kernel profiling}
|
||||||
|
CONFIG\_GCOV\_KERNEL [=n] \textbf{[N]}\\
|
||||||
|
Diese Option aktiviert die gcov-basierte Code-Profilierung (z. B. für Code-Abdeckungsmessungen).
|
||||||
|
Wenn Sie unsicher sind, sagen Sie N.\\[.5em]
|
||||||
|
Geben Sie zusätzlich CONFIG\_GCOV\_PROFILE\_ALL=y an, um Profilerstellungsdaten für den gesamten
|
||||||
|
Kernel zu erhalten. Um die Profilerstellung für bestimmte Dateien oder Verzeichnisse zu aktivieren,
|
||||||
|
fügen Sie eine Zeile ähnlich der folgenden in das jeweilige Makefile ein:\\[.5em]
|
||||||
|
Für eine einzelne Datei (z.B. main.o):\\
|
||||||
|
\indent \texttt{GCOV\_PROFILE\_main.o := y}\\[.5em]
|
||||||
|
Für alle Dateien in einem Verzeichnis:\\
|
||||||
|
\indent \texttt{GCOV\_PROFILE := y}\\[.5em]
|
||||||
|
Um Dateien von der Profilerstellung auszuschließen, auch wenn CONFIG\_GCOV\_PROFILE\_ALL
|
||||||
|
angegeben ist, verwenden Sie:\\
|
||||||
|
\indent \texttt{GCOV\_PROFILE\_main.o := n}\\[.5em]
|
||||||
|
und:\\
|
||||||
|
\indent \texttt{GCOV\_PROFILE := n}\\[.5em]
|
||||||
|
Beachten Sie, dass das debugfs-Dateisystem gemountet sein muss, um auf die Profilerstellungsdaten
|
||||||
|
zugreifen zu können.
|
||||||
|
|
||||||
|
\subsection{GCC plugins \texorpdfstring{$\rightarrow$}{->}}
|
||||||
|
CONFIG\_GCC\_PLUGINS [=y] \textbf{[Y]}\\
|
||||||
|
GCC-Plugins sind ladbare Module, die zusätzliche Funktionen für den Compiler bereitstellen.
|
||||||
|
Sie sind nützlich für die Laufzeitinstrumentierung und die statische Analyse.\\
|
||||||
|
Siehe Documentation/kbuild/gcc-plugins.rst für Details.
|
||||||
|
|
||||||
|
\subsubsection{Generate some entropy during boot and runtime}
|
||||||
|
CONFIG\_GCC\_PLUGIN\_LATENT\_ENTROPY [=n] \textbf{[N]}\\
|
||||||
|
Mit der Eingabe von Y wird der Kernel einen Teil des Kernel-Codes instrumentieren,
|
||||||
|
um sowohl aus dem ursprünglichen als auch aus dem künstlich erzeugten Programmzustand
|
||||||
|
etwas Entropie zu gewinnen.
|
||||||
|
Dies ist insbesondere bei eingebetteten Systemen hilfreich, bei denen es normalerweise wenig
|
||||||
|
\glqq natürliche\grqq{} Entropiequellen gibt.
|
||||||
|
Der Preis ist eine gewisse Verlangsamung des Boot-Prozesses (etwa 0,5~\%) und der fork- und
|
||||||
|
irq-Verarbeitung. Beachten Sie, dass die auf diese Weise extrahierte Entropie nicht
|
||||||
|
kryptografisch sicher ist!\\
|
||||||
|
Dieses Plugin wurde von grsecurity/PaX portiert. Mehr Informationen unter:
|
||||||
|
\begin{itemize}
|
||||||
|
\item[] \url{https://grsecurity.net/}
|
||||||
|
\item[] \url{https://pax.grsecurity.net/}
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
|
||||||
|
\section{Enable loadable module support \texorpdfstring{$\rightarrow$}{->}}
|
||||||
|
CONFIG\_MODULES [=y] \textbf{[Y]}\\
|
||||||
|
Kernel-Module sind kleine Stücke kompilierten Codes, die in den laufenden Kernel eingefügt werden können,
|
||||||
|
anstatt dauerhaft in den Kernel eingebaut zu werden. Sie verwenden das Werkzeug
|
||||||
|
\texttt{modprobe}, um sie hinzuzufügen (und manchmal zu entfernen).\\
|
||||||
|
Wenn Sie hier Y angeben, können viele Teile des Kernels als Module gebaut werden (indem Sie M anstelle
|
||||||
|
von Y antworten, wo dies angegeben ist):\\
|
||||||
|
Dies ist besonders nützlich für selten verwendete Optionen, die zum Booten nicht benötigt werden.
|
||||||
|
Weitere Informationen finden Sie in den Man Pages für \texttt{modprobe},
|
||||||
|
\texttt{lsmod}, \texttt{modinfo}, \texttt{insmod} und \texttt{rmmod}.\\
|
||||||
|
Wenn Sie hier Y angeben, müssen Sie \texttt{make modules\_install} ausführen, um die Module unter\\
|
||||||
|
/lib/modules/ abzulegen, wo sie von modprobe gefunden werden können (möglicherweise müssen Sie dazu
|
||||||
|
root sein).
|
||||||
|
Wenn Sie unsicher sind, sagen Sie Y.
|
||||||
|
|
||||||
|
\subsection{Module debugging}
|
||||||
|
CONFIG\_MODULE\_DEBUG [=n] \textbf{[N]}\\
|
||||||
|
Ermöglicht das Aktivieren/Deaktivieren von Funktionen, die Ihnen beim Debuggen von Modulen helfen können.
|
||||||
|
Auf Produktionssystemen benötigen Sie diese Optionen nicht.
|
||||||
|
|
||||||
|
\subsection{Forced module loading}
|
||||||
|
CONFIG\_MODULE\_FORCE\_LOAD [=y] \textbf{[Y]}\\
|
||||||
|
Erlaubt das Laden von Modulen ohne Versionsinformationen (z.B. \texttt{modprobe --force}).
|
||||||
|
Erzwungenes Laden von Modulen setzt das `F' (forced) taint Flag und ist normalerweise eine wirklich
|
||||||
|
schlechte Idee.
|
||||||
|
|
||||||
|
\subsection{Module unloading}
|
||||||
|
CONFIG\_MODULE\_UNLOAD [=y] \textbf{[Y]}\\
|
||||||
|
Ohne diese Option können Sie keine Module entladen (beachten Sie, dass einige Module möglicherweise
|
||||||
|
ohnehin nicht entladbar sind), was Ihren Kernel kleiner, schneller und einfacher macht.
|
||||||
|
Wenn Sie unsicher sind, sagen Sie Y.
|
||||||
|
|
||||||
|
\subsubsection{Forced module unloading}
|
||||||
|
CONFIG\_MODULE\_FORCE\_UNLOAD [=y] \textbf{[Y]}\\
|
||||||
|
Mit dieser Option können Sie das Entladen eines Moduls erzwingen, auch wenn der Kernel es für unsicher
|
||||||
|
hält: Der Kernel wird das Modul entfernen, ohne darauf zu warten, dass jemand die Verwendung des Moduls
|
||||||
|
beendet (mit der Option \texttt{-f} von \texttt{rmmod}).
|
||||||
|
Dies ist hauptsächlich für Kernel-Entwickler und verzweifelte Benutzer gedacht. Wenn Sie unsicher sind,
|
||||||
|
sagen Sie N.
|
||||||
|
|
||||||
|
\subsubsection{Tainted module unload tracking}
|
||||||
|
CONFIG\_MODULE\_UNLOAD\_TAINT\_TRACKING [=y] \textbf{[Y]}\\
|
||||||
|
Mit dieser Option können Sie eine Aufzeichnung über jedes entladene Modul führen, das den Kernel
|
||||||
|
beschädigt hat. Zusätzlich zur Anzeige einer Liste der verknüpften (oder geladenen) Module, z.B.
|
||||||
|
bei der Erkennung einer schlechten Seite (siehe bad\_page()), werden auch die oben genannten
|
||||||
|
Details angezeigt. Wenn Sie unsicher sind, sagen Sie N.
|
||||||
|
|
||||||
|
\subsection{Module versioning support}
|
||||||
|
CONFIG\_MODVERSIONS [=n] \textbf{[N]}\\
|
||||||
|
Normalerweise müssen Sie Module verwenden, die mit Ihrem Kernel kompiliert wurden. Wenn Sie
|
||||||
|
hier Y angeben, ist es manchmal möglich, Module zu verwenden, die für andere Kernel kompiliert wurden,
|
||||||
|
indem Sie genügend Informationen zu den Modulen hinzufügen, um (hoffentlich) alle Änderungen zu erkennen,
|
||||||
|
die sie mit dem von Ihnen verwendeten Kernel inkompatibel machen würden.\\
|
||||||
|
Wenn Sie unsicher sind, sagen Sie N.
|
||||||
|
|
||||||
|
\subsection{Source checksum for all modules}
|
||||||
|
CONFIG\_MODULE\_SRCVERSION\_ALL [=y] \textbf{[Y]}\\
|
||||||
|
Module, die eine MODULE\_VERSION enthalten, bekommen ein zusätzliches \glqq srcversion\grqq{}-Feld in
|
||||||
|
ihre modinfo-Sektion eingefügt, das eine Summe der Quelldateien enthält, aus denen sie entstanden sind.
|
||||||
|
Dies hilft den Betreuern, genau zu sehen, welche Quelle verwendet wurde, um ein Modul zu bauen
|
||||||
|
(da andere manchmal die Modulquelle ändern, ohne die Version zu aktualisieren). Mit dieser Option wird
|
||||||
|
ein solches \glqq srcversion\grqq{}-Feld für alle Module erstellt. Wenn Sie unsicher sind, sagen Sie N.
|
||||||
|
|
||||||
|
\subsection{Module signature verification}
|
||||||
|
CONFIG\_MODULE\_SIG [=y] \textbf{[Y]}\\
|
||||||
|
Überprüfung von Modulen auf gültige Signaturen beim Laden: Die Signatur wird einfach an das Modul
|
||||||
|
angehängt. Für weitere Informationen siehe $<$file:Documentation/admin-guide/module-signing.rst$>$.
|
||||||
|
Beachten Sie, dass diese Option die OpenSSL-Entwicklungspakete als Kernel-Build-Abhängigkeit hinzufügt,
|
||||||
|
so dass das Signierwerkzeug seine Krypto-Bibliothek verwenden kann. Sie sollten diese Option aktivieren,
|
||||||
|
wenn Sie entweder CONFIG\_SECURITY\_LOCKDOWN\_LSM oder eine durch eine andere LSM auferlegte
|
||||||
|
Lockdown-Funktionalität verwenden wollen -- andernfalls werden unsignierte Module unabhängig von der
|
||||||
|
Lockdown-Policy ladbar sein.
|
||||||
|
!!!WARNUNG!!! Wenn Sie diese Option aktivieren, MÜSSEN Sie sicherstellen, dass das Modul nach dem
|
||||||
|
Signieren NICHT gestrippt wird. Dies schließt den Debuginfo-Strip ein, der von einigen Paketierern
|
||||||
|
(wie z.B. rpmbuild) durchgeführt wird, sowie die Einbindung in ein initramfs, das die Modulgröße
|
||||||
|
reduzieren möchte.
|
||||||
|
|
||||||
|
\subsubsection{Require modules to be validly signed}
|
||||||
|
CONFIG\_MODULE\_SIG\_FORCE [=n] \textbf{[N]}\\
|
||||||
|
Ablehnung von unsignierten Modulen oder signierten Modulen, für die wir keinen Schlüssel haben.
|
||||||
|
Ohne diesen Schlüssel werden solche Module den Kernel einfach verunreinigen.
|
||||||
|
|
||||||
|
\subsubsection{Automatically sign all modules}
|
||||||
|
CONFIG\_MODULE\_SIG\_ALL [=y] \textbf{[Y]}\\
|
||||||
|
Signiere alle Module während make modules\_install. Ohne diese Option müssen die Module manuell
|
||||||
|
signiert werden, und zwar mit dem Werkzeug scripts/sign-file.
|
||||||
|
|
||||||
|
\subsection{Which hash algorithm should modules be signed with? () \texorpdfstring{$\rightarrow$}{->}}
|
||||||
|
Damit wird festgelegt, welche Art von Hashing-Algorithmus bei der Signaturerstellung verwendet wird.
|
||||||
|
Dieser Algorithmus \textbf{muss} direkt in den Kernel eingebaut werden, damit eine Signaturprüfung
|
||||||
|
stattfinden kann. Es ist nicht möglich, ein signiertes Modul zu laden, das den Algorithmus enthält,
|
||||||
|
um die Signatur dieses Moduls zu überprüfen.
|
||||||
|
|
||||||
|
\subsubsection{Sign modules with SHA-1}
|
||||||
|
CONFIG\_MODULE\_SIG\_SHA1 [=n] \textbf{[N]}\\
|
||||||
|
\textit{Für diese Option gibt es keine Hilfe.}
|
||||||
|
\subsubsection{Sign modules with SHA-224}
|
||||||
|
CONFIG\_MODULE\_SIG\_SHA224 [=n] \textbf{[N]}\\
|
||||||
|
\textit{Für diese Option gibt es keine Hilfe.}
|
||||||
|
\subsubsection{Sign modules with SHA-256}
|
||||||
|
CONFIG\_MODULE\_SIG\_SHA256 [=n] \textbf{[N]}\\
|
||||||
|
\textit{Für diese Option gibt es keine Hilfe.}
|
||||||
|
\subsubsection{Sign modules with SHA-384}
|
||||||
|
CONFIG\_MODULE\_SIG\_SHA384 [=n] \textbf{[N]}\\
|
||||||
|
\textit{Für diese Option gibt es keine Hilfe.}
|
||||||
|
\subsubsection{Sign modules with SHA-512}
|
||||||
|
CONFIG\_MODULE\_SIG\_SHA512 [=y] \textbf{[Y]}\\
|
||||||
|
\textit{Für diese Option gibt es keine Hilfe.}
|
||||||
|
|
||||||
|
|
||||||
|
\subsection{Module compression mode}
|
||||||
|
Mit dieser Option können Sie den Algorithmus auswählen, der zur Komprimierung von Modulen verwendet
|
||||||
|
wird, wenn \texttt{make modules\_install} ausgeführt wird. (oder Sie können wählen, dass Module
|
||||||
|
überhaupt nicht komprimiert werden.) Externe Module werden während der Installation ebenfalls auf
|
||||||
|
die gleiche Weise komprimiert. Für Module innerhalb einer initrd oder initramfs ist es effizienter,
|
||||||
|
stattdessen die gesamte initrd oder initramfs zu komprimieren. Dies ist vollständig kompatibel mit
|
||||||
|
signierten Modulen. Bitte beachten Sie, dass das zum Laden von Modulen verwendete Werkzeug den
|
||||||
|
entsprechenden Algorithmus unterstützen muss. module-init-tools KANN gzip unterstützen, und kmod KANN
|
||||||
|
gzip, xz und zstd unterstützen.
|
||||||
|
Ihr Build-System muss das entsprechende Komprimierungswerkzeug bereitstellen, um die Module zu
|
||||||
|
komprimieren. Im Zweifelsfall wählen Sie `None'.
|
||||||
|
|
||||||
|
\subsubsection{None}
|
||||||
|
CONFIG\_MODULE\_COMPRESSION\_NONE [=n] \textbf{[N]}\\
|
||||||
|
Komprimieren Sie die Module nicht. Die installierten Module sind mit der Endung .ko versehen.
|
||||||
|
\subsubsection{GZIP}
|
||||||
|
CONFIG\_MODULE\_COMPRESSION\_GZIP [=n] \textbf{[N]}\\
|
||||||
|
Komprimieren Sie Module mit GZIP. Die installierten Module sind mit der Endung .ko.gz versehen.
|
||||||
|
\subsubsection{XZ}
|
||||||
|
CONFIG\_MODULE\_COMPRESSION\_XZ [=n] \textbf{[N]}\\
|
||||||
|
Komprimieren Sie Module mit XZ. Die installierten Module sind mit der Endung .ko.xz versehen.
|
||||||
|
\subsubsection{ZSTD}
|
||||||
|
CONFIG\_MODULE\_COMPRESS\_ZSTD [=y] \textbf{[Y]}\\
|
||||||
|
Komprimieren Sie Module mit ZSTD. Die installierten Module sind mit der Endung .ko.zst versehen.
|
||||||
|
|
||||||
|
\subsection{Support in-kernel module decompression}
|
||||||
|
CONFIG\_MODULE\_DECOMPRESS [=y] \textbf{[Y]}\\
|
||||||
|
Unterstützung für die Dekomprimierung von Kernelmodulen durch den Kernel selbst, anstatt sich auf
|
||||||
|
den Userspace zu verlassen, um diese Aufgabe zu erledigen. Nützlich, wenn die Sicherheitsrichtlinie
|
||||||
|
für das Load Pinning aktiviert ist. Wenn Sie unsicher sind, sagen Sie N.
|
||||||
|
|
||||||
|
\subsection{Allow loading of modules with missing namespace imports}
|
||||||
|
CONFIG\_MODULE\_ALLOW\_MISSING\_NAMESPACE\_IMPORTS [=y] \textbf{[Y]}\\
|
||||||
|
Symbole, die mit EXPORT\_SYMBOL\_NS*() exportiert werden, gelten als in einem Namespace exportiert.
|
||||||
|
Ein Modul, das ein Symbol verwendet, das mit einem solchen Namespace exportiert wurde, muss den
|
||||||
|
Namespace über MODULE\_IMPORT\_NS() importieren. Es gibt keinen technischen Grund, korrekte
|
||||||
|
Namespace-Importe zu erzwingen, aber es schafft Konsistenz zwischen Symbolen, die Namespaces
|
||||||
|
definieren und Benutzern, die Namespaces importieren, die sie verwenden. Diese Option lockert diese
|
||||||
|
Anforderung und hebt die Durchsetzung beim Laden eines Moduls auf. Wenn Sie unsicher sind, sagen Sie N.
|
||||||
|
|
||||||
|
\subsection{Path to modprobe binary}
|
||||||
|
CONFIG\_MODPROBE\_PATH [=/sbin/modprobe] \textbf{[/sbin/modprobe]}\\
|
||||||
|
Wenn der Kernel-Code ein Modul anfordert, geschieht dies durch den Aufruf des
|
||||||
|
User\-space-Dienst\-pro\-gramms
|
||||||
|
\texttt{modprobe}. Mit dieser Option können Sie den Pfad festlegen, in dem diese Binärdatei
|
||||||
|
zu finden ist. Dies kann zur Laufzeit über die sysctl-Datei /proc/sys/kernel/modprobe geändert werden.
|
||||||
|
Wenn Sie diese Option auf eine leere Zeichenkette setzen, wird die Fähigkeit des Kernels,
|
||||||
|
Module anzufordern, ausgeschaltet (der Userspace kann jedoch weiterhin explizit Module laden).
|
||||||
|
|
||||||
|
\section{Enable the block layer \texorpdfstring{$\rightarrow$}{->}}
|
||||||
|
CONFIG\_BLOCK [=y] \textbf{[Y]}\\
|
||||||
|
Bietet dem Kernel Unterstützung für die Blockschicht.\\
|
||||||
|
Deaktivieren Sie diese Option, um die Unterstützung für die Blockschicht aus dem Kernel zu entfernen.
|
||||||
|
Dies kann für eingebettete Geräte nützlich sein.\\
|
||||||
|
Wenn diese Option deaktiviert ist:
|
||||||
|
\begin{itemize}
|
||||||
|
\item[-] werden Blockgerätedateien unbrauchbar,
|
||||||
|
\item[-] werden einige Dateisysteme (wie ext3) nicht mehr verfügbar.
|
||||||
|
\end{itemize}
|
||||||
|
Außerdem werden SCSI-Zeichengeräte und USB-Speicher deaktiviert, da sie verschiedene Definitionen und
|
||||||
|
Möglichkeiten der Blockschicht nutzen.\\
|
||||||
|
Sagen Sie hier "Y", es sei denn, Sie wissen, dass Sie wirklich keine Festplatten und dergleichen einbinden wollen.
|
||||||
|
|
||||||
|
\subsection{Legacy autoloading support}
|
||||||
|
CONFIG\_BLOCK\_LEGACY\_AUTOLOAD [=y] \textbf{[Y]}\\
|
||||||
|
Ermöglicht das Laden von Modulen und das Erstellen von Block-Geräteinstanzen auf der Grundlage
|
||||||
|
von Zugriffen durch ihre spezielle Gerätedatei. Dies ist ein historisches Linux-Feature und ergibt
|
||||||
|
in einer udev-Welt, in der Gerätedateien bei Bedarf erstellt werden, keinen Sinn, aber Skripte,
|
||||||
|
die manuell Geräteknoten erstellen und dann losetup aufrufen, könnten sich auf dieses Verhalten
|
||||||
|
verlassen.
|
||||||
|
|
||||||
|
\subsection{Block layer SG support v4 helper lib}
|
||||||
|
CONFIG\_BLK\_DEV\_BSGLIB [=y] \textbf{[Y]}\\
|
||||||
|
Die Teilsysteme werden dies normalerweise bei Bedarf aktivieren. Die Benutzer müssen dies normalerweise
|
||||||
|
nicht manuell aktivieren. Wenn Sie unsicher sind, sagen Sie N.
|
||||||
|
|
||||||
|
\subsection{Block layer data integrity support}
|
||||||
|
CONFIG\_BLK\_DEV\_INTEGRITY [=y] \textbf{[Y]}\\
|
||||||
|
Einige Speichermedien erlauben die Speicherung/Abrufung zusätzlicher Informationen, um die Daten zu
|
||||||
|
schützen. Die Option für die Datenintegrität auf Blockebene bietet Hooks, die von Dateisystemen verwendet
|
||||||
|
werden können, um eine bessere Datenintegrität zu gewährleisten. Sagen Sie hier Ja, wenn Sie ein
|
||||||
|
Speichergerät haben, das das T10/SCSI Data Integrity Field oder den T13/ATA External Path Protection
|
||||||
|
bietet. Im Zweifelsfall sagen Sie N.
|
||||||
|
|
||||||
|
\subsection{Zoned block device support}
|
||||||
|
CONFIG\_BLK\_DEV\_ZONED [=y] \textbf{[Y]}\\
|
||||||
|
Unterstützung für zonierte Blockgeräte auf Blockebene. 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 J, 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-Partitionierungsschemas zu umgehen.
|
||||||
|
Der Logical Disk Manager ermöglicht es dem Benutzer, eine Festplatte neu zu partitionieren und
|
||||||
|
übergreifende, gespiegelte, striped oder RAID-Volumes zu erstellen, ohne dass ein Neustart
|
||||||
|
erforderlich ist. Normale Partitionen werden nun unter Windows 2000, XP und Vista als Basisfestplatten
|
||||||
|
bezeichnet.\\
|
||||||
|
Für eine ausführlichere Beschreibung lesen Sie $<$file:Documentation/admin-guide/ldm.rst$>$.\\
|
||||||
|
Wenn Sie unsicher sind, sagen Sie N.
|
||||||
|
|
||||||
|
\subparagraph{Windows LDM extra logging}$~$\\
|
||||||
|
CONFIG\_LDM\_DEBUG [=n] \textbf{[N]}\\
|
||||||
|
Geben Sie hier Y an, wenn Sie möchten, dass LDM ausführlich protokolliert.
|
||||||
|
Dies könnte hilfreich sein, wenn der Treiber nicht wie erwartet funktioniert und Sie einen Fehler
|
||||||
|
melden möchten. Wenn Sie unsicher sind, sagen Sie N.
|
||||||
|
|
||||||
|
\paragraph{SGI partition support}$~$\\
|
||||||
|
CONFIG\_SGI\_PARTITION [=n] \textbf{[N]}\\
|
||||||
|
Wählen Sie hier Y, wenn Sie das von SGI-Maschinen verwendete Format der
|
||||||
|
Festplattenpartitionstabelle lesen möchten.
|
||||||
|
|
||||||
|
\paragraph{Ultrix partition table support}$~$\\
|
||||||
|
CONFIG\_ULTRIX\_PARTITION [=n] \textbf{[N]}\\
|
||||||
|
Sagen Sie hier Y, wenn Sie das von DEC (jetzt Compaq) Ultrix-Maschinen verwendete Format der
|
||||||
|
Festplattenpartitionstabelle lesen möchten. Andernfalls sagen Sie N.
|
||||||
|
|
||||||
|
\paragraph{Sun partition tables support}$~$\\
|
||||||
|
CONFIG\_SUN\_PARTITION [=n] \textbf{[N]}\\
|
||||||
|
Wie die meisten Systeme verwendet SunOS ein eigenes Format für Festplattenpartitionstabellen,
|
||||||
|
das mit allen anderen nicht kompatibel ist.
|
||||||
|
Wenn Sie hier Y angeben, können Sie diese Partitionstabellen lesen und SunOS-Partitionen von Linux aus
|
||||||
|
einbinden, wenn Sie oben bei \glqq UFS-Dateisystemunterstützung\grqq{} ebenfalls Y angegeben haben.
|
||||||
|
Dies wird hauptsächlich benutzt, um Daten von einem SPARC unter SunOS zu Ihrem Linux-Rechner über ein
|
||||||
|
Wechselmedium wie magneto-optische oder ZIP-Laufwerke zu transportieren; beachten Sie jedoch, dass ein
|
||||||
|
guter portabler Weg, Dateien und Verzeichnisse zwischen Unixen (und sogar anderen Betriebssystemen) zu
|
||||||
|
transportieren, durch das \texttt{tar}-Programm (\texttt{man tar} oder vorzugsweise
|
||||||
|
\texttt{info tar}) gegeben ist. Wenn Sie nicht wissen, was das alles soll, sagen Sie N.
|
||||||
|
|
||||||
|
\paragraph{Karma Partition support}$~$\\
|
||||||
|
CONFIG\_KARMA\_PARTITION [=y] \textbf{[Y]}\\
|
||||||
|
Sagen Sie hier Y, wenn Sie den Rio Karma MP3-Player mounten möchten, da dieser eine
|
||||||
|
proprietäre Partitionstabelle verwendet.
|
||||||
|
|
||||||
|
\paragraph{EFI GUID Partition support}$~$\\
|
||||||
|
CONFIG\_EFI\_PARTITION [=y] \textbf{[Y]}\\
|
||||||
|
Geben Sie hier Y an, wenn Sie unter Linux Festplatten verwenden möchten,
|
||||||
|
die mit EFI GPT partitioniert wurden.
|
||||||
|
|
||||||
|
\paragraph{SYSV68 partition table support}$~$\\
|
||||||
|
CONFIG\_SYSV68\_PARTITION [=n] \textbf{[N]}\\
|
||||||
|
Geben Sie hier Y ein, wenn Sie das von Motorola-Delta-Maschinen verwendete Format der
|
||||||
|
Festplattenpartitionstabelle lesen möchten (unter Verwendung von sysv68). Andernfalls sagen Sie N.
|
||||||
|
|
||||||
|
\paragraph{Command line partition support}$~$\\
|
||||||
|
CONFIG\_CMDLINE\_PARTITION [=n] \textbf{[N]}\\
|
||||||
|
Sagen Sie hier Y, wenn Sie die Partitionstabelle aus bootargs lesen wollen. Das Format für die
|
||||||
|
Kommandozeile ist genau wie bei mtdparts.
|
||||||
|
|
||||||
|
\subsection{IO Schedulers \texorpdfstring{$\rightarrow$}{->}}
|
||||||
|
(E/A-Zeitplaner)
|
||||||
|
|
||||||
|
\subsubsection{MQ deadline I/O scheduler}
|
||||||
|
CONFIG\_MQ\_IOSCHED\_DEADLINE [=y] \textbf{[Y]}\\
|
||||||
|
MQ-Version des Deadline-IO-Schedulers.
|
||||||
|
|
||||||
|
\subsubsection{Kyber I/O scheduler}
|
||||||
|
CONFIG\_MQ\_IOSCHED\_KYBER [=m] \textbf{[M]}\\
|
||||||
|
Der Kyber E/A-Scheduler ist ein Scheduler mit geringem Aufwand, der sich für Multiqueue- und andere
|
||||||
|
schnelle Geräte eignet. Bei vorgegebenen Ziellatenzen für Lese- und synchrone Schreibvorgänge passt
|
||||||
|
er die Tiefe der Warteschlangen selbst an, um dieses Ziel zu erreichen.
|
||||||
|
|
||||||
|
\subsubsection{BFQ I/O scheduler}
|
||||||
|
CONFIG\_IOSCHED\_BFQ [=y] \textbf{[Y]}\\
|
||||||
|
BFQ E/A-Scheduler für BLK-MQ. BFQ verteilt die Bandbreite des Geräts auf alle Prozesse entsprechend
|
||||||
|
ihrer Gewichtung, unabhängig von den Geräteparametern und bei jeder Arbeitslast. Es garantiert auch
|
||||||
|
eine niedrige Latenzzeit für interaktive und weiche Echtzeitanwendungen.\\
|
||||||
|
Weitere Details in Dokumentation/block/bfq-iosched.rst
|
||||||
|
|
||||||
|
\paragraph{BFQ hierarchical scheduling support}$~$\\
|
||||||
|
CONFIG\_BFQ\_GROUP\_IOSCHED [=y] \textbf{[Y]}\\
|
||||||
|
Aktivierung der hierarchischen Zeitplanung in BFQ unter Verwendung des blkio (cgroupss-v1)
|
||||||
|
oder io (cgroupss-v2) Controllers.
|
||||||
|
|
||||||
|
\subparagraph{BFQ IO controller debugging}$~$\\
|
||||||
|
CONFIG\_BFQ\_CGROUP\_DEBUG [=n] \textbf{[N]}\\
|
||||||
|
Aktivierung einer Hilfe zur Fehlersuche.
|
||||||
|
Derzeit werden zusätzliche Statistikdateien in einer cgroup exportiert, die für die Fehlersuche
|
||||||
|
nützlich sein können.
|
||||||
|
|
||||||
|
\section{Executable file formats \texorpdfstring{$\rightarrow$}{->}}
|
||||||
|
(Ausführbare Dateiformate)
|
||||||
|
|
||||||
|
\subsection{Kernel support for ELF binaries}
|
||||||
|
CONFIG\_BINFMT\_ELF [=y] \textbf{[Y]}\\
|
||||||
|
ELF (Executable and Linkable Format) ist ein Format für Bibliotheken und ausführbare Dateien,
|
||||||
|
das auf verschiedenen Architekturen und Betriebssystemen verwendet wird.
|
||||||
|
Wenn Sie hier Y angeben, kann Ihr Kernel ELF-Binärdateien ausführen und wird um etwa 13 KB vergrößert.
|
||||||
|
Die ELF-Unterstützung unter Linux hat inzwischen die traditionellen Linux a.out-Formate (QMAGIC und ZMAGIC)
|
||||||
|
fast vollständig ersetzt, da es portabel ist (was jedoch *nicht* bedeutet, dass Sie ausführbare Dateien
|
||||||
|
von verschiedenen Architekturen oder Betriebssystemen ausführen können) und die Erstellung von
|
||||||
|
Laufzeitbibliotheken sehr einfach macht. Viele neue ausführbare Dateien werden ausschließlich im
|
||||||
|
ELF-Format vertrieben. Hier sollten Sie unbedingt Y sagen. Informationen über ELF sind im ELF HOWTO
|
||||||
|
enthalten, das unter \url{http://www.tldp.org/docs.html#howto} verfügbar ist.
|
||||||
|
Wenn Sie feststellen, dass Sie nach dem Upgrade von Linux-Kernel 1.2 und der Angabe von Y hier immer
|
||||||
|
noch keine ELF-Binärdateien ausführen können (sie stürzen einfach ab), dann müssen Sie die neuesten
|
||||||
|
ELF-Laufzeitbibliotheken installieren, einschließlich \texttt{ld.so} (überprüfen Sie die Datei
|
||||||
|
$<$file:Documentation/Changes$>$ für den Ort und die neueste Version).
|
||||||
|
|
||||||
|
\subsection{Write ELF core dumps with partial segments}
|
||||||
|
CONFIG\_CORE\_DUMP\_DEFAULT\_ELF\_HEADERS [=y] \textbf{[Y]}\\
|
||||||
|
ELF-Core-Dump-Dateien beschreiben jede Speicherabbildung des abgestürzten Prozesses und können den
|
||||||
|
Speicherinhalt jedes einzelnen Prozesses enthalten oder auslassen. Der Inhalt eines unveränderten
|
||||||
|
Text-Mappings wird standardmäßig weggelassen. Bei einem unveränderten Text-Mapping eines ELF-Objekts
|
||||||
|
ermöglicht die Aufnahme nur der ersten Seite der Datei in einen Core-Dump die Identifizierung der
|
||||||
|
Build-ID-Bits in der Datei, ohne dass die E/A-Kosten und der Plattenplatz für das Dump des gesamten
|
||||||
|
Textes anfallen. Versionen von GDB vor 6.7 werden jedoch von ELF-Core-Dump-Dateien in diesem Format
|
||||||
|
verwirrt. Das Verhalten des Kerndumps kann pro Prozess mit der Pseudodatei /proc/PID/coredump\_filter
|
||||||
|
gesteuert werden; diese Einstellung wird vererbt.
|
||||||
|
Siehe Dokumentation/filesystems/proc.rst für Details.
|
||||||
|
Diese Konfigurationsoption ändert die Standardeinstellung von coredump\_filter, die beim Booten zu
|
||||||
|
sehen ist.
|
||||||
|
Wenn Sie unsicher sind, sagen Sie Y.
|
||||||
|
|
||||||
|
\subsection{Kernel support for scripts starting with \#!}
|
||||||
|
CONFIG\_BINFMT\_SCRIPT [=y] \textbf{[Y]}\\
|
||||||
|
(Kernel-Unterstützung für Skripte, die mit \#!, dem Shebang, anfangen)
|
||||||
|
Geben Sie hier Y an, wenn Sie interpretierte Skripte ausführen wollen, die mit \#! beginnen,
|
||||||
|
gefolgt von dem Pfad zu einem Interpreter. Sie können diese Unterstützung als Modul bauen; bis dieses
|
||||||
|
Modul jedoch geladen ist, können Sie keine Skripte ausführen.
|
||||||
|
Wenn Sie also dieses Modul aus einem initramfs laden wollen, darf der Teil des initramfs vor dem Laden
|
||||||
|
dieses Moduls nur aus kompilierten Binärdateien bestehen. Die meisten Systeme werden nicht booten,
|
||||||
|
wenn Sie hier M oder N angeben. Wenn Sie unsicher sind, sagen Sie Y.
|
||||||
|
|
||||||
|
\subsection{Kernel support for MISC binaries}
|
||||||
|
CONFIG\_BINFMT\_MISC [=y] \textbf{[Y]}\\
|
||||||
|
Wenn Sie hier Y sagen, wird es möglich sein, Wrapper-gesteuerte Binärformate in den Kernel einzubinden.
|
||||||
|
Dies ist vor allem dann sinnvoll, wenn Sie Programme verwenden, die einen Interpreter benötigen, wie
|
||||||
|
Java, Python, .NET oder Emacs-Lisp. Es ist auch nützlich, wenn Sie häufig DOS-Programme unter dem
|
||||||
|
Linux-DOS-Emulator DOSEMU ausführen (lesen Sie das DOSEMU-HOWTO, verfügbar unter
|
||||||
|
\url{http://www.tldp.org/docs.html#howto}). Sobald Sie eine solche Binärklasse beim Kernel registriert
|
||||||
|
haben, können Sie eines dieser Programme einfach starten, indem Sie seinen Namen an einer
|
||||||
|
Shell-Eingabeaufforderung eingeben; Linux wird es automatisch an den richtigen Interpreter weiterleiten.
|
||||||
|
Sie können auch andere nette Dinge tun.\\
|
||||||
|
Lesen Sie die Datei $<$file:Documentation/admin-guide/binfmt-misc.rst$>$,
|
||||||
|
um zu erfahren, wie Sie diese Funktion nutzen können,
|
||||||
|
$<$file:Documentation/admin-guide/java.rst$>$, um zu erfahren, wie Sie Java-Unterstützung einbinden
|
||||||
|
können, und $<$file:Documentation/admin-guide/mono.rst$>$, um zu erfahren, wie Sie Mono-basierte
|
||||||
|
.NET-Unterstützung einbinden können.
|
||||||
|
Um binfmt\_misc zu verwenden, müssen Sie es mounten:
|
||||||
|
\texttt{mount binfmt\_misc -t binfmt\_misc /proc/sys/fs/binfmt\_misc}
|
||||||
|
Sie können hier M für Modulunterstützung sagen und später das Modul laden, wenn Sie es brauchen;
|
||||||
|
das Modul heißt \texttt{binfmt\_misc}. Wenn Sie nicht wissen, was Sie an dieser Stelle antworten sollen,
|
||||||
|
sagen Sie Y.
|
||||||
|
|
||||||
|
\section{Memory Management options \texorpdfstring{$\rightarrow$}{->}}
|
||||||
|
(Speicherverwaltungsoptionen)
|
||||||
|
|
||||||
|
\subsection{Support for paging of anonymous memory (swap) \texorpdfstring{$\rightarrow$}{->}}
|
||||||
|
CONFIG\_SWAP [=y] \textbf{[Y]}\\
|
||||||
|
Mit dieser Option können Sie wählen, ob Sie Unterstützung für so genannte Swap-Geräte oder
|
||||||
|
Swap-Dateien in Ihrem Kernel haben möchten, die dazu dienen, mehr virtuellen Speicher als
|
||||||
|
den tatsächlichen Arbeitsspeicher in Ihrem Computer bereitzustellen.
|
||||||
|
Wenn Sie unsicher sind, sagen Sie Y.
|
||||||
|
|
||||||
|
\subsubsection{Compressed cache for swap pages}
|
||||||
|
CONFIG\_ZSWAP [=y] \textbf{[Y]}\\
|
||||||
|
Ein leichtgewichtiger komprimierter Cache für Auslagerungsseiten. Er nimmt Seiten, die gerade ausgelagert
|
||||||
|
werden, und versucht, sie in einem dynamisch zugewiesenen RAM-basierten Speicherpool zu komprimieren. Dies
|
||||||
|
kann zu einer erheblichen E/A-Reduzierung auf dem Swap-Gerät führen und in dem Fall, in dem die
|
||||||
|
Dekomprimierung aus dem RAM schneller ist als das Lesen aus dem Swap-Gerät, auch die Arbeitslastleistung
|
||||||
|
verbessern.
|
||||||
|
|
||||||
|
\paragraph{Enable the compressed cache for swap pages by default}$~$\\
|
||||||
|
CONFIG\_ZSWAP\_DEFAULT\_ON [=y] \textbf{[Y]}\\
|
||||||
|
Wenn diese Option ausgewählt ist, wird der komprimierte Cache für Auslagerungsseiten beim Booten aktiviert,
|
||||||
|
andernfalls wird er deaktiviert. Die hier getroffene Auswahl kann mit der Kernel-Kommando\-zei\-len\-option
|
||||||
|
\texttt{zswap.enabled=} überschrieben werden.
|
||||||
|
|
||||||
|
\paragraph{Invalidate zswap entries when pages are loaded}$~$\\
|
||||||
|
CONFIG\_ZSWAP\_EXCLUSIVE\_LOADS\_DEFAULT\_ON [=n] \textbf{[N]}\\
|
||||||
|
Wenn diese Option ausgewählt ist, werden exklusive Lasten für zswap beim Booten aktiviert, andernfalls wird
|
||||||
|
sie deaktiviert. Wenn exklusive Ladungen aktiviert sind, wird beim Laden einer Seite aus zswap der
|
||||||
|
zswap-Eintrag sofort ungültig gemacht, anstatt ihn in zswap zu belassen, bis der Swap-Eintrag freigegeben
|
||||||
|
wird. Dadurch wird vermieden, dass sich zwei Kopien derselben Seite im Speicher befinden (komprimiert und
|
||||||
|
unkomprimiert), nachdem eine Seite aus zswap geladen wurde. Der Preis dafür ist, dass die Seite neu
|
||||||
|
komprimiert wird, wenn sie nie verschmutzt wurde und erneut ausgelagert werden muss.
|
||||||
|
|
||||||
|
\paragraph{Default compressor () \texorpdfstring{$\rightarrow$}{->}}
|
||||||
|
Wählt den Standardkomprimierungsalgorithmus für den komprimierten Cache für Auslagerungsseiten aus.
|
||||||
|
Einen Überblick darüber, welche Leistung von einem bestimmten Kompressionsalgorithmus erwartet werden kann,
|
||||||
|
finden Sie in den Benchmarks auf der folgenden LWN-Seite: \url{https://lwn.net/Articles/751795/}\\
|
||||||
|
Im Zweifelsfall wählen Sie \texttt{LZO}.
|
||||||
|
Die hier getroffene Auswahl kann durch Verwendung der Kernel-Befehls\-zeilen\-option
|
||||||
|
\texttt{zswap.compressor=} überschrieben werden.
|
||||||
|
|
||||||
|
\subparagraph{Deflate}$~$\\
|
||||||
|
CONFIG\_ZSWAP\_COMPRESSOR\_DEFAULT\_DEFLATE [=n] \textbf{[N]}\\
|
||||||
|
Verwenden Sie den Deflate-Algorithmus als Standard-Komprimierungsalgorithmus.
|
||||||
|
\subparagraph{LZO}$~$\\
|
||||||
|
CONFIG\_ZSWAP\_COMPRESSOR\_DEFAULT\_LZO [=n] \textbf{[N]}\\
|
||||||
|
Verwenden Sie den LZO-Algorithmus als Standard-Komprimierungsalgorithmus.
|
||||||
|
\subparagraph{842}$~$\\
|
||||||
|
CONFIG\_ZSWAP\_COMPRESSOR\_DEFAULT\_842 [=n] \textbf{[N]}\\
|
||||||
|
Verwenden Sie den 842-Algorithmus als Standard-Komprimierungsalgorithmus.
|
||||||
|
\subparagraph{LZ4}$~$\\
|
||||||
|
CONFIG\_ZSWAP\_COMPRESSOR\_DEFAULT\_LZ4 [=n] \textbf{[N]}\\
|
||||||
|
Verwenden Sie den LZ4-Algorithmus als Standard-Komprimierungsalgorithmus.
|
||||||
|
\subparagraph{LZ4HC}$~$\\
|
||||||
|
CONFIG\_ZSWAP\_COMPRESSOR\_DEFAULT\_LZ4HC [=n] \textbf{[N]}\\
|
||||||
|
Verwenden Sie den LZ4HC-Algorithmus als Standard-Komprimierungsalgorithmus.
|
||||||
|
\subparagraph{zstd}$~$\\
|
||||||
|
CONFIG\_ZSWAP\_COMPRESSOR\_DEFAULT\_ZSTD [=y] \textbf{[Y]}\\
|
||||||
|
Verwenden Sie den zstd-Algorithmus als Standard-Komprimierungsalgorithmus.
|
||||||
|
|
||||||
|
\paragraph{Default allocator () \texorpdfstring{$\rightarrow$}{->}}$~$\\
|
||||||
|
Wählt den Standardzuweiser für den komprimierten Cache für Auslagerungsseiten aus. Die Voreinstellung ist
|
||||||
|
aus Kompatibilitätsgründen \glqq zbud\grqq{}, aber lesen Sie bitte die Beschreibung der einzelnen Zuweiser
|
||||||
|
unten, bevor Sie die richtige Wahl treffen. Die hier getroffene Auswahl kann mit der
|
||||||
|
Kernel-Kommandozeilenoption \texttt{zswap.zpool=} überschrieben werden.
|
||||||
|
|
||||||
|
\subparagraph{zbud}$~$\\
|
||||||
|
CONFIG\_ZSWAP\_ZPOOL\_DEFAULT\_ZBUD [=n] \textbf{[N]}\\
|
||||||
|
Verwendung des zbud-Allokators als Standard-Allokator.
|
||||||
|
|
||||||
|
\subparagraph{z3fold}$~$\\
|
||||||
|
CONFIG\_ZSWAP\_ZPOOL\_DEFAULT\_Z3FOLD [=n] \textbf{[N]}\\
|
||||||
|
Verwendung des z3fold-Allokators als Standard-Allokator.
|
||||||
|
|
||||||
|
\subparagraph{zsmalloc}$~$\\
|
||||||
|
CONFIG\_ZSWAP\_ZPOOL\_DEFAULT\_ZSMALLOC [=n] \textbf{[N]}\\
|
||||||
|
Verwendung des zsmalloc-Allokators als Standard-Allokator.
|
||||||
|
|
||||||
|
\paragraph{2:1 compression allocator (zbud) \texorpdfstring{$\rightarrow$}{->}}$~$\\
|
||||||
|
CONFIG\_ZBUD [=y] \textbf{[Y]}\\
|
||||||
|
Ein spezieller Allokator für die Speicherung komprimierter Seiten. Er ist für die Speicherung von bis zu zwei
|
||||||
|
komprimierten Seiten pro physischer Seite ausgelegt.
|
||||||
|
Dieses Design schränkt zwar die Speicherdichte ein, hat aber einfache und deterministische
|
||||||
|
Rückgewinnungseigenschaften, die es einem Ansatz mit höherer Dichte vorziehen, wenn die Rückgewinnung
|
||||||
|
verwendet wird.
|
||||||
|
|
||||||
|
\paragraph{3:1 compression allocator (z3fold) \texorpdfstring{$\rightarrow$}{->}}$~$\\
|
||||||
|
CONFIG\_Z3FOLD [=y] \textbf{[Y]}\\
|
||||||
|
Ein spezieller Allokator für die Speicherung komprimierter Seiten. Er ist für die Speicherung von bis zu drei
|
||||||
|
komprimierten Seiten pro physischer Seite ausgelegt.
|
||||||
|
Es handelt sich um ein ZBUD-Derivat, so dass die Einfachheit und der Determinismus weiterhin gegeben sind.
|
||||||
|
|
||||||
|
\paragraph{N:1 compression allocator (zsmalloc) \texorpdfstring{$\rightarrow$}{->}}$~$\\
|
||||||
|
CONFIG\_ZSMALLOC [=y] \textbf{[Y]}\\
|
||||||
|
zsmalloc ist ein Slab-basierter Speicherallokator, der für die effiziente Speicherung von Seiten
|
||||||
|
verschiedener Komprimierungsstufen entwickelt wurde. Er erreicht die höchste Speicherdichte mit der
|
||||||
|
geringsten Fragmentierung.
|
||||||
|
|
||||||
|
\subparagraph{Export zsmalloc statistics}$~$\\
|
||||||
|
CONFIG\_ZSMALLOC\_STAT [=n] \textbf{[N]}\\
|
||||||
|
Diese Option ermöglicht es dem Code in zsmalloc, verschiedene Statistiken über die Vorgänge in zsmalloc zu
|
||||||
|
sammeln und diese Informationen über debugfs in den Userspace zu exportieren. Wenn Sie unsicher sind,
|
||||||
|
sagen Sie N.
|
||||||
|
|
||||||
|
\subparagraph{Maximum number of physical pages per-zspage}$~$\\
|
||||||
|
CONFIG\_ZSMALLOC\_CHAIN\_SIZE [=8] \textbf{[8]}\\
|
||||||
|
Diese Option legt die Obergrenze für die Anzahl der physischen Seiten fest, aus denen eine zmalloc-Seite
|
||||||
|
(zspage) bestehen kann. Die optimale zspage-Kettengröße wird für jede Größenklasse während der
|
||||||
|
Initialisierung des Pools berechnet.\\
|
||||||
|
Eine Änderung dieser Option kann die Eigenschaften der Größenklassen
|
||||||
|
verändern, z. B. die Anzahl der Seiten pro zspage und die Anzahl der Objekte pro zspage.
|
||||||
|
Dies kann auch zu unterschiedlichen Konfigurationen des Pools führen, da zsmalloc Größenklassen mit
|
||||||
|
ähnlichen Eigenschaften zusammenführt.\\
|
||||||
|
Weitere Informationen finden Sie in der Dokumentation zu zsmalloc.
|
||||||
|
|
||||||
\end{document}
|
\end{document}
|
||||||
|
|||||||
Reference in New Issue
Block a user