UPD Memory Management options
This commit is contained in:
@@ -3047,13 +3047,846 @@ Kernel-Code hinzu. Wenn Sie N sagen, werden alle Optionen in diesem Untermenü
|
||||
und deaktiviert.
|
||||
|
||||
\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
|
||||
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
|
||||
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.
|
||||
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}
|
||||
|
||||
Reference in New Issue
Block a user