% Device Drivers (15)

\section{Device Drivers \texorpdfstring{$\rightarrow$}{->}}
\textit{(Gerätetreiber)}

\subsection{EISA support ---}
CONFIG\_EISA [=n] \textbf{[~]}\\*
Der Extended Industry Standard Architecture (EISA)-Bus wurde als offene Alternative
zum IBM MicroChannel"=Bus entwickelt.
Der EISA-Bus bot einige der Funktionen des IBM"=MicroChannel"=Busses und war gleichzeitig
abwärtskompatibel mit Karten, die für den älteren ISA"=Bus hergestellt wurden.
Der EISA-Bus wurde zwischen 1988 und 1995 in begrenztem Umfang eingesetzt,
als er durch den PCI-Bus überflüssig wurde.
Geben Sie hier Y an, wenn Sie einen Kernel für einen EISA"=basierten Rechner erstellen.
Ansonsten sagen Sie N.

\subsection{PCI support \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_PCI [=y] \textbf{[Y]}\\*
Diese Option aktiviert die Unterstützung für den lokalen PCI-Bus, einschließlich der
Unterstützung für PCI-X und die Grundlagen für die Unterstützung von PCI Express.\\
Sagen Sie hier Y, wenn Sie nicht wissen, was Sie tun.

\subsubsection{PCI Express Port Bus support}
CONFIG\_PCIEPORTBUS [=y] \textbf{[Y]}\\*
Dadurch wird die Unterstützung für den PCI Express Port Bus aktiviert. Benutzer können
dann die Unterstützung für Native Hot-Plug, Advanced Error Reporting, Power Management
Events und Downstream Port Containment aktivieren.

\paragraph{PCI Express Hotplug driver}$~$\\
CONFIG\_HOTPLUG\_PCI\_PCIE [=y] \textbf{[Y]}\\*
Sagen Sie hier Y, wenn Sie ein Motherboard haben, das natives PCIe"=Hotplug unterstützt.
Thunderbolt/USB4 PCIe-Tunneling hängt von nativem PCIe"=Hotplug ab.
Im Zweifelsfall sagen Sie N.

\paragraph{PCI Express Advanced Error Reporting support}$~$\\
CONFIG\_PCIEAER [=y] \textbf{[Y]}\\*
Dies ermöglicht die Unterstützung des PCI Express Root Port Advanced Error Reporting
(AER) Treibers. Die an den Root Port gesendeten Fehlermeldungen werden vom PCI Express
AER"=Treiber verarbeitet.

\subparagraph{PCI Express error injection support}$~$\\
CONFIG\_PCIEAER\_INJECT [=m] \textbf{[M]}\\*
Dies aktiviert den PCI Express Root Port Advanced Error Reporting (AER) Software-Fehlerinjektor.
Das Debuggen von AER-Code ist ziemlich schwierig, da es schwierig ist, verschiedene echte
Hardwarefehler auszulösen. Software"=basierte Fehlerinjektion kann fast alle Arten von Fehlern
mit Hilfe eines Userspace"=Hilfswerkzeugs \texttt{aer-inject} vortäuschen,
das unter folgender Adresse erhältlich ist
\url{https://git.kernel.org/cgit/linux/kernel/git/gong.chen/aer-inject.git/}

\subparagraph{PCI Express CXL RAS support}$~$\\
CONFIG\_PCIEAER\_CXL [=y] \textbf{[Y]}\\*
Aktiviert die CXL"=Fehlerbehandlung.
Wenn Sie unsicher sind, sagen Sie Y.

\subparagraph{PCI Express ECRC settings control}$~$\\
CONFIG\_PCIE\_ECRC [=y] \textbf{[Y]}\\*
Wird verwendet, um Firmware-/Bios-Einstellungen für PCI Express ECRC
(Transaction Layer End-to-End CRC Checking) außer Kraft zu setzen.
Im Zweifelsfall sagen Sie N.

\subsubsection{PCI Express ASPM control}
CONFIG\_PCIEASPM [=y] \textbf{[Y]}\\*
Dies ermöglicht dem Betriebssystem die Kontrolle über PCI Express ASPM
(Active State Power Management) und Clock Power Management.
ASPM unterstützt den Zustand L0/L0s/L1.\\
ASPM wird zunächst von der Firmware eingerichtet. Wenn diese Option aktiviert ist, kann Linux
diesen Status ändern, um ASPM bei bekanntermaßen schlechter Hardware oder Konfigurationen zu
deaktivieren und bei bekanntermaßen sicherer Hardware zu aktivieren.
ASPM kann zur Laufzeit über \texttt{/sys/module/pcie\_aspm/parameters/policy}
deaktiviert oder aktiviert werden.
Im Zweifelsfall sagen Sie Y.


\paragraph{Default ASPM policy (BIOS default) \texorpdfstring{$\rightarrow$}{->}}$~$\\
\textit{Für diese Option gibt es keine Hilfe.}

\subparagraph{BIOS default}$~$\\
CONFIG\_PCIEASPM\_DEFAULT [=y] \textbf{[Y]}\\*
Verwenden Sie die BIOS"=Standardeinstellungen für PCI Express ASPM.

\subparagraph{Powersave}$~$\\
CONFIG\_PCIEASPM\_POWERSAVE [=n] \textbf{[~]}\\*
Aktiviert PCI Express ASPM L0s und L1 wo möglich, auch wenn das BIOS dies nicht getan hat.

\subparagraph{Power Supersave}$~$\\
CONFIG\_PCIEASPM\_POWER\_SUPERSAVE [=n] \textbf{[~]}\\*
Wie PCIEASPM\_POWERSAVE, nur dass auch L1-Substates aktiviert werden, wo dies möglich ist.
Dies würde zu höheren Energieeinsparungen führen, während man in L1 bleibt,
wo die Komponenten dies unterstützen.

\subparagraph{Performance}$~$\\
CONFIG\_PCIEASPM\_POWER\_PERFORMANCE [=n] \textbf{[~]}\\*
Deaktivieren Sie PCI Express ASPM L0s und L1, auch wenn das BIOS sie aktiviert hat.

%15.2.3
\subsubsection{PCI Express Downstream Port Containment support}
CONFIG\_PCIE\_DPC [=y] \textbf{[Y]}\\*
Dies ermöglicht die Unterstützung von PCI Express Downstream Port Containment (DPC) Treibern.
DPC"=Ereignisse von Root- und Downstream"=Ports werden durch den DPC"=Treiber verarbeitet.
Wenn Ihr System nicht über diese Fähigkeit verfügt oder Sie diese Funktion nicht nutzen möchten,
können Sie mit N antworten.

%15.2.4
\subsubsection{PCI Express Precision Time Measurement support}
CONFIG\_PCIE\_PTM [=y] \textbf{[Y]}\\*
Dies ermöglicht die Unterstützung von PCI Express Precision Time Measurement (PTM).
Dies ist nur sinnvoll, wenn Sie Geräte haben, die PTM unterstützen, aber es ist sicher,
sie zu aktivieren, auch wenn Sie sie nicht haben.

%15.2.5
\subsubsection{PCI Express Error Disconnect Recover support}
CONFIG\_PCIE\_EDR [=y] \textbf{[Y]}\\*
Diese Option fügt die Unterstützung für Error Disconnect Recover hinzu, wie in der
Downstream Port Containment Related Enhancements ECN der PCI Firmware Specification r3.2 beschrieben.
Aktivieren Sie diese Option, wenn Sie ein hybrides DPC-Modell unterstützen möchten, das sowohl
Firmware als auch Betriebssystem zur Implementierung von DPC verwendet.

\subsubsection{Message Signaled Interrupts (MSI and MSI-X)}
CONFIG\_PCI\_MSI [=y] \textbf{[Y]}\\*
Damit können Gerätetreiber MSI (Message Signaled Interrupts) aktivieren.
Message Signaled Interrupts ermöglichen es einem Gerät, einen Interrupt zu erzeugen, indem es ein
eingehendes Memory Write auf seinem PCI-Bus verwendet, anstatt einen Geräte"=IRQ-Pin zu aktivieren.
Die Verwendung von PCI MSI"=Interrupts kann beim Booten des Kernels mit der Option
\texttt{pci=nomsi} deaktiviert werden. Dadurch wird MSI für das gesamte System deaktiviert.
Wenn Sie nicht wissen, was Sie hier tun sollen, sagen Sie Y.

\subsubsection{PCI Debugging}
CONFIG\_PCI\_DEBUG [=n] \textbf{[~]}\\*
Geben Sie hier Y an, wenn Sie möchten, dass der PCI-Kern eine Reihe von Debug"=Meldungen in
das Systemprotokoll schreibt. Wählen Sie dies, wenn Sie ein Problem mit der
PCI"=Unterstützung haben und mehr über die Vorgänge erfahren möchten.
Im Zweifelsfall sagen Sie N.

\subsubsection{Enable PCI resource re-allocation detection}
CONFIG\_PCI\_REALLOC\_ENABLE\_AUTO [=n] \textbf{[~]}\\*
Geben Sie hier Y an, wenn Sie möchten, dass der PCI-Kern erkennt, ob die Neuzuweisung von
PCI"=Ressourcen aktiviert werden muss. Sie können jederzeit
\texttt{pci=realloc=on} oder \texttt{pci=realloc=off} verwenden, um dies zu überschreiben.
Es werden automatisch PCI"=Ressourcen neu zugewiesen, wenn SR-IOV BARs nicht vom BIOS
zugewiesen wurden.
Im Zweifelsfall sagen Sie N.

\subsubsection{PCI Stub driver}
CONFIG\_PCI\_STUB [=y] \textbf{[Y]}\\*
Sagen Sie hier Y oder M, wenn Sie ein PCI-Gerät reservieren wollen, wenn es einem
Gastbetriebssystem zugewiesen werden soll.
Im Zweifelsfall sagen Sie N.

%15.2.10
\subsubsection{PCI PF Stub driver}
CONFIG\_PCI\_\_PF\_STUB [=m] \textbf{[M]}\\*
Geben Sie hier Y oder M an, wenn Sie die Unterstützung für Geräte, die SR-IOV"=Unterstützung
benötigen, aktivieren möchten, während die PF (Physical Function) selbst keine eigentlichen
Dienste auf dem Host selbst, wie z.~B. Speicher oder Netzwerke, bereitstellt.
Im Zweifelsfall sagen Sie N.

\subsubsection{Xen PCI Frontend}
CONFIG\_XEN\_PCIDEV\_FRONTEND [=m] \textbf{[M]}\\*
Der PCI-Geräte"=Frontend"=Treiber ermöglicht es dem Kernel, beliebige PCI"=Geräte aus
einem PCI"=Back"-end zu importieren, um PCI"=Treiber"=Domänen zu unterstützen.

\subsubsection{PCI IOV support}
CONFIG\_PCI\_IOV [=y] \textbf{[Y]}\\*
E/A-Virtualisierung ist eine PCI"=Funktion, die von einigen Geräten unterstützt wird und
es ihnen ermöglicht, virtuelle Geräte zu erstellen, die ihre physischen Ressourcen gemeinsam nutzen.
Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{PCI PRI support}
CONFIG\_PCI\_PRI [=y] \textbf{[Y]}\\*
PRI ist das PCI Page Request Interface. Es ermöglicht PCI"=Geräten, die sich hinter einer
IOMMU befinden, sich von Seitenfehlern zu erholen.
Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{PCI PASID support}
CONFIG\_PCI\_PASID [=y] \textbf{[Y]}\\*
Process Address Space Identifiers (PASIDs) können von PCI"=Geräten für den gleichzeitigen Zugriff
auf mehr als einen IO"=Adressraum verwendet werden. Um diese Funktion nutzen zu können, ist eine
IOMMU erforderlich, die auch PASIDs unterstützt.
Wählen Sie diese Option, wenn Sie eine solche IOMMU haben und den Treiber dafür in Ihren Kernel
kompilieren wollen.
Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{PCI peer-to-peer transfer support}
CONFIG\_PCI\_P2PDMA [=y] \textbf{[Y]}\\*
Ermöglicht Treibern die Durchführung von PCI-Peer-to-Peer"=Transaktionen zu und von BARs, die in
anderen Geräten exponiert sind, die den Teil der Hierarchie darstellen, in dem Peer-to-Peer-DMA
von der PCI"=Spezifikation garantiert wird (d.~h. alles unterhalb einer einzelnen PCI"=Bridge).
Viele PCIe"=Root"=Komplexe unterstützen keine P2P"=Transaktionen, und es ist schwer zu sagen,
welche sie überhaupt unterstützen. Daher müssen P2P-DMA"=Transaktionen derzeit zwischen Geräten
hinter demselben Root-Port erfolgen.
Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{Hyper-V PCI Frontend}
CONFIG\_PCI\_HYPERV [=m] \textbf{[M]}\\*
Der PCI-Geräte-Frontend-Treiber ermöglicht es dem Kernel, beliebige PCI"=Geräte aus einem
PCI"=Back"-end zu importieren, um PCI"=Treiber"=Domänen zu unterstützen.

\subsubsection{VGA Arbitration}
CONFIG\_VGA\_ARB [=y] \textbf{[Y]}\\*
Einige \glqq alte\grqq{} VGA"=Geräte, die auf PCI implementiert sind, haben in der Regel die
gleichen hart dekodierten Adressen wie auf ISA. Wenn auf mehrere PCI"=Geräte gleichzeitig
zugegriffen wird, müssen diese irgendwie koordiniert werden. Weitere Einzelheiten finden Sie
unter Documentation/gpu/vgaarbiter.rst. Wählen Sie dies, um VGA"=Arbiter zu aktivieren.

\paragraph{Maximum number of GPUs}$~$\\
CONFIG\_VGA\_ARB\_MAX\_GPUS [=10] \textbf{[10]}\\*
Reserviert Platz im Kernel, um die Ressourcensperre für mehrere GPUS aufrechtzuerhalten.
Der Overhead für jede GPU ist sehr gering.\\
Typ: Ganzzahl (integer)

\subsubsection{Support for PCI Hotplug \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_HOTPLUG\_PCI [=y] \textbf{[Y]}\\*
Geben Sie hier Y ein, wenn Sie ein Motherboard mit einem PCI-Hotplug-Controller haben.
Damit können Sie PCI-Karten hinzufügen und entfernen, während der Rechner eingeschaltet ist und läuft.
Thunderbolt/USB4 PCIe-Tunneling hängt vom nativen PCIe-Hotplug ab.
Im Zweifelsfall sagen Sie N.

%15.2.18.1
\paragraph{ACPI PCI Hotplug driver}$~$\\
CONFIG\_HOTPLUG\_PCI\_ACPI [=y] \textbf{[Y]}\\*
Geben Sie hier Y ein, wenn Sie ein System haben, das PCI Hotplug mit ACPI unterstützt.
Im Zweifelsfall sagen Sie N.
%15.2.18.1.1
\subparagraph{ACPI PCI Hotplug driver IBM extensions}$~$\\
CONFIG\_HOTPLUG\_PCI\_ACPI\_IBM \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Geben Sie hier Y ein, wenn Sie ein IBM-System haben, das PCI-Hotplug über ACPI unterstützt.
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M: Das Modul wird
\texttt{acpiphp\_ibm} heißen.
Im Zweifelsfall sagen Sie N.
\\\begin{scriptsize}
Der Laptop ist kein IBM-System.
\end{scriptsize}

\paragraph{CompactPCI Hotplug driver}$~$\\
CONFIG\_HOTPLUG\_PCI\_CPCI \colorbox{yellow!80}{[=y] \textbf{[~]}}\\*
Geben Sie hier Y ein, wenn Sie eine CompactPCI"=Systemkarte mit CompactPCI"=Hotswap"=Unterstützung
gemäß der PICMG~2.1"=Spezifikation besitzen.
Im Zweifelsfall sagen Sie N.
\\\begin{scriptsize}
Im Laptop ist diese CompactPCI-Karte nicht verbaut.
\end{scriptsize}

\subparagraph{Ziatech ZT5550 CompactPCI Hotplug driver}$~$\\
CONFIG\_HOTPLUG\_PCI\_CPCI\_ZT5550 \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Sagen Sie hier Y, wenn Sie eine Ziatech ZT5550 CompactPCI-Systemkarte von Performance Technologies
(früher Intel, früher nur Ziatech) besitzen.
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
Das Modul heißt dann \texttt{cpcihp\_zt5550}.
Im Zweifelsfall sagen Sie N.
\\\begin{scriptsize}
Im Laptop ist diese CompactPCI-Karte nicht verbaut.
\end{scriptsize}

\subparagraph{Generic port I/O CompactPCI Hotplug driver}$~$\\
CONFIG\_HOTPLUG\_PCI\_CPCI\_GENERIC \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Sagen Sie hier Y, wenn Sie eine CompactPCI"=Systemkarte haben, die das \#ENUM-Hotswap-Signal als
ein Bit in einem Systemregister ausgibt, das über Standard"=Port-I/O gelesen werden kann.
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
Das Modul wird \texttt{cpcihp\_generic} genannt.
Im Zweifelsfall sagen Sie N.
\\\begin{scriptsize}
Im Laptop ist diese CompactPCI-Karte nicht verbaut.
\end{scriptsize}

\paragraph{SHPC PCI Hotplug driver}$~$\\
CONFIG\_HOTPLUG\_PCI\_SHPC \colorbox{yellow!80}{[=y] \textbf{[~]}}\\*
Geben Sie hier Y ein, wenn Sie ein Motherboard mit einem SHPC PCI Hotplug Controller haben.
Im Zweifelsfall sagen Sie N.

\subsubsection{PCI controller drivers \texorpdfstring{$\rightarrow$}{->}}
\textit{(PCI-Controller-Treiber)}

\paragraph{Intel Volume Management Device Driver}$~$\\
CONFIG\_VMD \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Fügt Unterstützung für das Intel Volume Management Device (VMD) hinzu. VMD ist eine sekundäre
PCI-Host"=Brücke, die es ermöglicht, PCI-Express-Root-Ports und daran angeschlossene Geräte aus
der Standard-PCI-Domäne zu entfernen und in die VMD-Domäne zu verschieben. Dadurch stehen mehr
Bus"=Ressourcen zur Verfügung, als dies bei einer einzelnen Domäne möglich wäre.
Wenn Sie wissen, dass Ihr System über einen dieser Ports verfügt und Geräte daran angeschlossen
sind, sagen Sie Y; wenn Sie sich nicht sicher sind, sagen Sie N.
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
Das Modul wird \texttt{vmd} genannt.

\paragraph{Microsoft Hyper-V PCI Interface}$~$\\
CONFIG\_PCI\_HYPERV\_INTERFACE \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Das Hyper-V PCI Interface ist ein Hilfstreiber, der es anderen
Treibern ermöglicht, eine gemeinsame Schnittstelle mit dem Hyper-V
PCI Frontend-Treiber zu haben.

\paragraph{Cadence-based PCIe controllers ---}$~$\\
\textit{Cadence-basierte PCIe-Steuerungen, keine Auswahl}

\paragraph{DesignWare-based PCIe controllers \texorpdfstring{$\rightarrow$}{->}}$~$\\
\textit{DesignWare-basierte PCIe-Steuerungen}

%15.2.19.4.1
\subparagraph{Amlogic Meson PCIe controller}$~$\\
CONFIG\_PCI\_MESON \colorbox{yellow!80}{[=y] \textbf{[~]}}\\*
Sagen Sie hier Y, wenn Sie die Unterstützung des PCI-Controllers
auf Amlogic-SoCs aktivieren wollen. Der PCI-Controller auf Amlogic
basiert auf DesignWare"=Hardware und daher verwendet der Treiber die
DesignWare"=Kernfunktionen zur Implementierung des Treibers.

\subparagraph{Platform bus based DesignWare PCIe controller (host mode)}$~$\\
CONFIG\_PCIe\_DW\_PLAT\_HOST \colorbox{yellow!80}{[=y] \textbf{[~]}}\\*
Ermöglicht die Unterstützung des PCIe-Controllers in der Designware-IP
für den Betrieb im Host-Modus. Es gibt zwei Instanzen des PCIe-Controllers
in Designware IP. Dieser Controller kann entweder als EP oder RC arbeiten.
Um hostspezifische Funktionen zu aktivieren, muss PCIE\_DW\_PLAT\_HOST
ausgewählt werden und um gerätespezifische Funktionen zu aktivieren,
muss PCI\_DW\_PLAT\_EP ausgewählt werden.

\paragraph{Mobiveil-based PCIe controllers ---}$~$\\
\textit{Mobiveil-basierte PCIe-Steuerungen, keine Auswahl}

\subsubsection{PCI Endpoint \texorpdfstring{$\rightarrow$}{->}}
\textit{(PCI-Endgerät}

\paragraph{PCI Endpoint Support}$~$\\
CONFIG\_PCI\_ENDPOINT [=n] \textbf{[~]}\\*
Aktivieren Sie diese Konfigurationsoption, um einen konfigurierbaren PCI"=Endpunkt
zu unterstützen. Dies sollte aktiviert werden, wenn die Plattform über einen
PCI"=Controller verfügt, der im Endpunktmodus arbeiten kann.\\
Durch die Aktivierung dieser Option wird die Endpunkt"=Bibliothek erstellt, die
eine Endpunkt"=Controller"=Bibliothek und eine Endpunkt"=Funktionsbibliothek
enthält.
Im Zweifelsfall sollten Sie N angeben, um die Endpunktunterstützung zu
deaktivieren.

\subsubsection{PCI switch controller drivers \texorpdfstring{$\rightarrow$}{->}}
\textit{(PCI-Switch-Controller-Treiber}

\paragraph{MicroSemi Switchtec PCIe Switch Management Driver}$~$\\
CONFIG\_PCI\_SW\_SWITCHTEC \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Ermöglicht die Unterstützung der Management"=Schnittstelle für die MicroSemi
Switchtec"=Serie von PCIe"=Switches. Unterstützt den Userspace"=Zugriff, um
MRPC"=Befehle über /dev/switchtecX-Geräte an den Switch zu senden.
Siehe $<$file:Documentation/driver-api/switchtec.rst$>$ für weitere Informationen.

\subsubsection{CXL (Compute Express Link) Devices Support \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_CXL\_BUS \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
CXL ist ein Bus, der elektrisch mit PCI Express kompatibel ist, aber drei Protokolle
auf diese Signalisierung aufbaut (CXL.io, CXL.cache und CXL.mem).
Das CXL.cache"=Protokoll ermöglicht es Geräten, Cachelines lokal zu halten, das
CXL.mem"=Protokoll ermöglicht es Geräten, vollständig kohärente Speicherziele zu
sein, das CXL.io"=Protokoll entspricht PCI Express. Sagen Sie Y, um die Unterstützung
für die Konfiguration und Verwaltung von Geräten zu aktivieren, die diese Protokolle
unterstützen.

\paragraph{PCI manageability}$~$\\
CONFIG\_CXL\_PCI \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Die CXL-Spezifikation definiert eine Unterklasse \glqq CXL"=Speichergerät\grqq{}
in der PCI"=Basisklasse der \glqq Speicher"=Controller\grqq{}.
Geräte, die mit diesem Klassencode gekennzeichnet sind, bieten Unterstützung
für flüchtigen und/oder dauerhaften Speicher, der in die Systemadresszuordnung
(Host-managed Device Memory (HDM)) eingeordnet werden kann.
Sagen Sie \glqq y/m\grqq{}, um einen Treiber zu aktivieren, der sich
an CXL"=Speichererweiterungsgeräte anschließt, die durch den Klassencode
des Speichergeräts für die Konfiguration und Verwaltung hauptsächlich über
die Mailbox"=Schnittstelle aufgezählt werden.
Siehe Kapitel~2.3 Typ~3 CXL Gerät in der CXL~2.0 Spezifikation für weitere Details.
Wenn Sie unsicher sind, sagen Sie M.

\subparagraph{RAW Command Interface for Memory Devices}$~$\\
CONFIG\_CXL\_MEM\_RAW\_COMMANDS [=n] \textbf{[~]}\\*
Aktivieren Sie die CXL RAW-Befehlsschnittstelle.\\
Die ioctl"=Schnittstelle des CXL"=Treibers kann für jeden spezifizierten Opcode
eine Kernel"=ioctl"=Befehlsnummer zuweisen. Zu jedem beliebigen Zeitpunkt kann
die Anzahl der in der Spezifikation definierten Opcodes, die ein Gerät
implementieren kann, die Anzahl der zugehörigen ioctl"=Funktionsnummern des
Kernels übersteigen. Die Diskrepanz entsteht entweder durch Auslassung, weil die
Spezifikation zu neu ist, oder durch das Design. Beim Prototyping neuer Hardware
oder bei der Entwicklung/Debugging des Treibers ist es nützlich, alle möglichen
Befehle an die Hardware übermitteln zu können, sogar Befehle, die den Kernel zum
Absturz bringen könnten, da sie sich auf den vom Kernel verwendeten Speicher
auswirken könnten.\\
Wenn Sie CXL"=Hardware oder den Treiber entwickeln, sagen Sie Y, andernfalls
sagen Sie N.

\paragraph{CXL ACPI: Platform Support}$~$\\
CONFIG\_CXL\_ACPI \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Aktiviert die Unterstützung von HDM"=Ressourcen (Host Managed Device Memory), die
von der ACPI"=CXL"=Speicherlayoutbeschreibung einer Plattform veröffentlicht werden.
Siehe Kapitel~9.14.1 CXL Early Discovery Table (CEDT) in der CXL~2.0 Spezifikation
und CXL Fixed Memory Window Structures (CEDT.CFMWS)
(\url{https://www.computeexpresslink.org/spec-landing}).
Der CXL-Kern nutzt diese Ressourcen, um die Wurzel einer cxl\_port"=Decodierungshierarchie
zu veröffentlichen, um Regionen abzubilden, die System"=RAM oder von LIBNVDIMM zu
verwaltende Festspeicherregionen darstellen.
Wenn Sie unsicher sind, sagen Sie M.

\paragraph{CXL PMEM: Persistent Memory Support}$~$\\
CONFIG\_CXL\_PMEM \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Zusätzlich zu den typischen Speicherressourcen kann eine Plattform auch die Unterstützung
von über CXL angeschlossenem persistenten Speicher ankündigen. Diese Unterstützung wird
über einen Brückentreiber zwischen CXL und dem LIBNVDIMM"=System"=Subsystem verwaltet.
Sagen Sie \glqq Y/M\grqq{}, um die Unterstützung für die Aufzählung und Bereitstellung der
Kapazität des persistenten Speichers von CXL"=Speichererweiterungen zu aktivieren.
Wenn Sie unsicher sind, sagen Sie M.

\paragraph{CXL: Memory Expansion}$~$\\
CONFIG\_CXL\_MEM \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Das CXL.mem-Protokoll ermöglicht es einem Gerät, als Anbieter von \glqq System-RAM\grqq{}
und/oder \glqq persistentem Speicher\grqq{} zu fungieren, der vollständig kohärent ist,
als wäre der Speicher an den typischen CPU"=Speicher"=Controllern angeschlossen.
Dies wird als HDM \glqq Host-managed Device Memory\grqq{} bezeichnet.
Sagen Sie Y/M, um einen Treiber zu aktivieren, der sich an CXL.mem"=Geräte zur
Speichererweiterung und Steuerung von HDM anschließt.
Eine detaillierte Beschreibung von HDM finden Sie in Kapitel~9.13 der CXL~2.0"=Spezifikation.
Wenn Sie unsicher sind, sagen Sie M.

\paragraph{CXL: Region Support}$~$\\
CONFIG\_CXL\_REGION \colorbox{yellow!80}{[=y] \textbf{[~]}}\\*
Ermöglicht dem CXL-Kern die Aufzählung und Bereitstellung von CXL"=Regionen. Eine CXL"=Region
wird durch einen oder mehrere CXL"=Expander definiert, die einen bestimmten
systemphysikalischen Adressbereich dekodieren. Für CXL"=Regionen, die von der
Plattform"=Firmware eingerichtet wurden, ermöglicht diese Option die Behandlung von
Speicherfehlern, um die Geräte zu identifizieren, die an einem bestimmten verschachtelten
Speicherbereich teilnehmen. Andernfalls wird das von der Plattform-Firmware verwaltete CXL
durch Aufnahme in die Systemadresskarte aktiviert und benötigt keinen Treiber.
Wenn Sie unsicher sind, sagen Sie Y.

\subparagraph{CXL: Region Cache Management Bypass (TEST)}$~$\\
CONFIG\_CXL\_REGION\_INVALIDATION\_TEST [=n] \textbf{[~]}\\*
Die Verwaltungs- und Sicherheitsoperationen von CXL Region machen möglicherweise den Inhalt
von CPU"=Caches ungültig, ohne diese Caches zu benachrichtigen, damit sie die betroffenen
Cachelines ungültig machen. Der CXL"=Region"=Treiber versucht, Caches zu invalidieren, wenn
diese Ereignisse eintreten. Wenn diese Invalidierung fehlschlägt, kann die Region nicht
aktiviert werden. Die Gründe für das Scheitern der Cache"=Invalidierung liegen darin, dass
die CPU keinen Cache"=Invalidierungsmechanismus bereitstellt. Zum Beispiel ist die Verwendung
von wbinvd auf Bare Metal x86 beschränkt. Zu Testzwecken kann das Umschalten dieser Option
jedoch die Datenintegritätssicherheit deaktivieren und mit der Aktivierung von Regionen
fortfahren, wenn im CPU"=Cache widersprüchliche Inhalte vorhanden sind.//
Wenn Sie unsicher sind oder wenn dieser Kernel für Produktionsumgebungen gedacht ist,
wählen Sie N.

\paragraph{CXL Performance Monitoring Unit}$~$\\
CONFIG\_CXL\_PMU \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Support performance monitoring as defined in CXL rev~3.0 section~13.2: Performance Monitoring.
CXL components may have one or more CXL Performance Monitoring Units (CPMUs).\\
Say Y/M to enable a driver that will attach to performance monitoring units and provide
standard perf based interfaces.
If unsure say M.

\subsection{PCCard (PCMCIA/Cardbus) support \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_PCCARD [=m] \textbf{[M]}\\*
Sagen Sie hier Y, wenn Sie PCMCIA- oder PC"=Karten an Ihren Linux"=Computer anschließen wollen.
Das sind kreditkartengroße Geräte wie Netzwerkkarten, Modems oder Festplatten, die oft in
Laptops verwendet werden. Es gibt eigentlich zwei Arten dieser Karten: 16-Bit-PCMCIA- und
32-Bit"=CardBus"=Karten.
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
Das Modul wird pcmcia\_core heißen.

\subsubsection{16-bit PCMCIA support}
CONFIG\_PCMCIA \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Diese Option ermöglicht die Unterstützung von 16-Bit-PCMCIA"=Karten. Die meisten älteren
PC"=Karten sind solche 16-Bit PCMCIA"=Karten. Wenn Sie also nicht wissen, dass Sie nur
32"=Bit CardBus"=Karten verwenden, geben Sie hier Y oder M an.
Um 16-Bit PCMCIA"=Karten zu verwenden, benötigen Sie in den meisten Fällen unterstützende
Software. (siehe die Datei $<$file:Documentation/Changes$>$ für Ort und Details).
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
Das Modul wird \texttt{pcmcia} heißen.
Wenn Sie unsicher sind, sagen Sie Y.

\paragraph{Load CIS updates from userspace}$~$\\
CONFIG\_PCMCIA\_LOAD\_CIS \colorbox{yellow!80}{[=y] \textbf{[~]}}\\*
Einige PCMCIA"=Karten benötigen eine aktualisierte Karteninformationsstruktur (CIS), die aus
dem Userspace geladen werden muss, um korrekt zu funktionieren. Wenn Sie hier Y angeben und
Ihr Userspace korrekt eingerichtet ist, wird diese automatisch mit dem 
In-Kernel"=Firmware"=Loader und dem Hotplug"=Subsystem geladen, anstatt sich auf cardmgr von
pcmcia-cs zu verlassen.
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{32-bit CardBus support}
CONFIG\_CARDBUS \colorbox{yellow!80}{[=y] \textbf{[M]}}\\*
CardBus ist eine Bus-Mastering-Architektur für PC-Karten, die 32-Bit-PC-Karten ermöglicht
(der ursprüngliche PCMCIA"=Standard sieht nur einen 16-Bit breiten Bus vor).
Viele neuere PC-Karten sind eigentlich CardBus-Karten.
Um 32-Bit-PC-Karten zu verwenden, benötigen Sie auch eine CardBus"=kompatible Host"=Bridge.
Praktisch alle modernen PCMCIA"=Bridges sind dazu in der Lage, und die meisten von ihnen
sind \glqq Yenta-kompatibel\grqq{}, d.~h. sie sagen auch Y oder M.
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection*{*** PC-card bridges ***}
\textit{(*** PC-card-Brücken ***)}
\subsubsection{CardBus yenta-compatible bridge support}
CONFIG\_YENTA \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Diese Option ermöglicht die Unterstützung von CardBus-Host-Bridges. Praktisch alle modernen
PCMCIA"=Bridges sind CardBus-kompatibel. Eine \glqq Brücke\grqq{} ist die Hardware in Ihrem
Computer, in die PCMCIA-Karten eingesteckt werden.
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
Das Modul wird \texttt{yenta\_socket} heißen.
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{Cirrus PD6729 compatible bridge support}
CONFIG\_PD6729 \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Dies bietet Unterstützung für das Cirrus PD6729 PCI-zu-PCMCIA"=Bridge"=Gerät, das in einigen
älteren Laptops und PCMCIA-Kartenlesern zu finden ist.

\subsubsection{i82092 compatible bridge support}
CONFIG\_I82092 \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Dies bietet Unterstützung für das Intel I82092AA PCI-zu-PCMCIA"=Brückengerät, das in einigen
älteren Laptops und häufiger in Evaluierungsboards für den Chip zu finden ist.

\subsection{RapidIO support ---}% \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_PCCARD [=n] \textbf{[~]}\\*
Wenn Sie hier Y angeben, wird der Kernel Treiber und Infrastrukturcode zur Unterstützung von
RapidIO"=Verbindungsgeräten enthalten.

\subsection{Generic Driver Options \texorpdfstring{$\rightarrow$}{->}}
\textit{Allgemeine Treiberoptionen}

\subsubsection{Support for uevent helper}
CONFIG\_UEVENT\_HELPER [=n] \textbf{[~]}\\*
Das uevent"=Hilfsprogramm wird vom Kernel für jedes uevent gegabelt.
Vor der Umstellung auf die netlink"=basierte uevent"=Quelle wurde es verwendet, um
Hotplug"=Skripte mit Kernel"=Geräteereignissen zu verbinden. Es zeigte normalerweise auf ein
Shell"=Skript unter /sbin/hotplug.
Dies sollte heute nicht mehr verwendet werden, da übliche Systeme beim Booten oder bei der
Geräteerkennung viele Ereignisse in einem sehr kurzen Zeitrahmen erzeugen. Ein geforkter
Prozess pro Ereignis kann so viele Prozesse erzeugen, dass es zu einer hohen Systembelastung
kommt, oder auf kleineren Systemen ist bekannt, dass es zu Out"=of"=Memory"=Situationen
während des Bootvorgangs kommt.

\subsubsection{Maintain a devtmpfs filesystem to mount at /dev}
CONFIG\_DEVTMPFS [=y] \textbf{[Y]}\\*
Dadurch wird eine tmpfs/ramfs"=Dateisysteminstanz bereits beim Booten erzeugt. In diesem
Dateisystem verwaltet der Kernel"=Treiberkern Geräteknoten mit ihren Standardnamen und
Berechtigungen für alle registrierten Geräte mit einer zugewiesenen Major/Minor"=Nummer.
Der Userspace kann den Inhalt des Dateisystems nach Bedarf ändern, Symlinks hinzufügen und
die erforderlichen Berechtigungen vergeben.
Er stellt ein voll funktionsfähiges /dev"=Verzeichnis zur Verfügung, auf dem normalerweise
udev läuft, das die Berechtigungen verwaltet und sinnvolle Symlinks hinzufügt.
In sehr begrenzten Umgebungen kann es ein ausreichend funktionierendes /dev ohne weitere
Hilfe bereitstellen. Es erlaubt auch einfache Rettungssysteme und geht zuverlässig mit
dynamischen Major/Minor"=Nummern um.
Hinweis: Wenn CONFIG\_TMPFS nicht aktiviert ist, wird stattdessen das einfachere
ramfs"=Dateisystem verwendet.

\paragraph{Automount devtmpfs at /dev, after the kernel mounted the rootfs}$~$\\
CONFIG\_DEVTMPFS\_MOUNT %\colorbox{yellow!80}%
{[=y] \textbf{[Y]}}\\*
Dies weist den Kernel an, das Dateisystem devtmpfs automatisch unter /dev einzuhängen,
direkt nachdem der Kernel das Root"=Dateisystem eingehängt hat. Das Verhalten kann mit
dem Kommandozeilenparameter: \texttt{devtmpfs.mount=$0|1$} überschrieben werden.
Diese Option hat keinen Einfluss auf initramfs"=basiertes Booten, hier muss das
devtmpfs"=Dateisystem immer manuell eingehängt werden, nachdem das rootfs eingehängt
wurde.\\
Wenn diese Option aktiviert ist, kann ein System im Rettungsmodus mit
\texttt{init=/bin/sh} gebootet werden, auch wenn das /dev"=Verzeichnis auf dem rootfs
komplett leer ist.

\paragraph{Use nosuid,noexec mount options on devtmpfs}$~$\\
CONFIG\_DEVTMPFS\_SAFE [=y] \textbf{[Y]}\\*
Dies weist den Kernel an, die Einhängeflags MS\_NOEXEC und MS\_NOSUID beim Einhängen
von devtmpfs zu berücksichtigen.\\
Beachten Sie: Wenn dies aktiviert ist, können Dinge wie /dev/mem nicht mit dem
PROT\_EXEC"=Flag gemappt werden. Dies kann z.~B. Nicht"=KMS"=Grafiktreiber beschädigen.

\subsubsection{Select only drivers that don't need compile-time external firmware}
CONFIG\_STANDALONE [=y] \textbf{[Y]}\\*
Wählen Sie diese Option, wenn Sie keine magische Firmware für Treiber haben,
die diese benötigen.\\
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{Disable drivers features which enable custom firmware building}
CONFIG\_PREVENT\_FIRMWARE\_BUILD [=y] \textbf{[Y]}\\*
Sagen Sie ja, um Treiberfunktionen zu deaktivieren, die es ermöglichen, eine
benutzerdefinierte Treiber"=Firmware zur Kernel"=Erstellungszeit zu erstellen.
Diese Treiber verwenden nicht die Kernel"=Firmware"=API zum Laden der Firmware
(CONFIG\_FW\_LOADER), sondern ihren eigenen benutzerdefinierten Lademechanismus.
Die benötigte Firmware wird in der Regel mit dem Treiber ausgeliefert, das
Erstellen der Treiber"=Firmware sollte nur notwendig sein, wenn Sie eine
aktualisierte Firmware"=Quelle haben.\\
Firmware sollte nicht als Teil des Kernels gebaut werden.
Heutzutage sollte man dies immer verhindern und hier Y sagen.
Es gibt nur zwei alte Treiber, die die Erstellung ihrer Firmware zur
Kernel"=Erstellungszeit ermöglichen:
\begin{itemize}
	\item CONFIG\_WANXL durch CONFIG\_WANXL\_BUILD\_FIRMWARE
	\item CONFIG\_SCSI\_AIC79XX durch CONFIG\_AIC79XX\_BUILD\_FIRMWARE
\end{itemize}

\subsubsection{Firmware loader \texorpdfstring{$\rightarrow$}{->}}
\textit{(Firmware-Ladeprogramm)}

\paragraph{Firmware loading facility}$~$\\
CONFIG\_FW\_LOADER [=y] \textbf{[Y]}\\*
Damit wird die Möglichkeit zum Laden der Firmware im Kernel aktiviert.
Der Kernel sucht zunächst nach eingebauter Firmware, wenn er welche hat.
Anschließend sucht er in einer Reihe von Dateisystempfaden nach der gewünschten
Firmware:
\begin{itemize}
	\item firmware\_class Pfad-Modulparameter oder Kernel-Boot-Parameter
	\item /lib/firmware/updates/UTS\_RELEASE
	\item /lib/firmware/updates
	\item /lib/firmware/UTS\_RELEASE
	\item /lib/firmware
\end{itemize}
Die Aktivierung dieser Funktion vergrößert Ihr Kernel"=Image nur um etwa 828~Bytes.
Aktivieren Sie diese Option nur, wenn Sie sicher sind, dass Sie keine Firmware
benötigen.
Normalerweise wollen Sie diese Funktion eingebaut haben (=y), aber Sie können sie
auch als Modul aktivieren, in diesem Fall wird das Modul \texttt{firmware\_class}
gebaut.
Sie sollten auch sicherstellen, dass Sie diese integrierte Funktion aktivieren,
wenn Sie die integrierte Firmware (CONFIG\_EXTRA\_FIRMWARE) aktivieren wollen.

\subparagraph{Log filenames and checksums for loaded firmware}$~$\\
CONFIG\_FW\_LOADER\_DEBUG [=y] \textbf{[Y]}\\*
Wählen Sie diese Option, um mit dynamischem Debugging die Dateinamen der Firmware
und SHA256"=Prüfsummen für jede geladene Firmware"=Datei im Kernel-Protokoll zu
protokollieren.

\subparagraph{Build named firmware blobs into the kernel binary}$~$\\
CONFIG\_EXTRA\_FIRMWARE [=] \textbf{[~]}\\*
Gerätetreiber, die Firmware benötigen, können normalerweise damit umgehen, dass
der Kernel Firmware aus den verschiedenen unterstützten
\texttt{/lib/firmware/}"=Pfaden
lädt. Diese Option ermöglicht es Ihnen, Firmware"=Dateien in den Kernel
einzubauen. Eingebaute Firmware"=Suchen haben Vorrang vor Firmware"=Suchvorgängen
unter Verwendung Ihres Dateisystems über die unterstützten
\texttt{/lib/firmware}"=Pfade,
die unter CONFIG\_FW\_LOADER dokumentiert sind.
Dies kann zu Testzwecken nützlich sein oder wenn die Firmware zu einem frühen
Zeitpunkt beim Booten benötigt wird und man sich nicht darauf verlassen kann,
dass die Firmware in einer initrd oder initramfs abgelegt ist.
Diese Option ist eine Zeichenkette und nimmt die (durch Leerzeichen getrennten)
Namen der Firmware"=Dateien auf -- die gleichen Namen, die in MODULE\_FIRMWARE()
und request\_firmware() im Quelltext erscheinen. Diese Dateien sollten in dem
Verzeichnis vorhanden sein, das mit der Option EXTRA\_FIRMWARE\_DIR angegeben
wurde, was standardmäßig /lib/firmware ist.
Sie könnten zum Beispiel \texttt{CONFIG\_EXTRA\_FIRMWARE=\dq usb8388.bin\dq} setzen,
die Datei usb8388.bin nach /lib/firmware kopieren und den Kernel bauen.
Dann wird jede request\_firmware(\glqq usb8388.bin\grqq{}) intern im Kernel
befriedigt, ohne dass das Dateisystem zur Laufzeit eingesehen werden muss.
WARNUNG: Wenn Sie zusätzliche Firmware"=Dateien in Ihr binäres Kernel"=Image
einbinden, die nicht unter den Bedingungen der GPL verfügbar sind, dann kann es
eine Verletzung der GPL sein, das resultierende Image zu verteilen, da es
sowohl GPL- als auch Nicht"=GPL"=Arbeiten kombiniert. Sie sollten einen eigenen
Anwalt konsultieren, bevor Sie ein solches Image weitergeben.\\
HINWEIS: Komprimierte Dateien werden in EXTRA\_FIRMWARE nicht unterstützt.

\subparagraph{Enable the firmware sysfs fallback mechanism}$~$\\
CONFIG\_FW\_LOADER\_USER\_HELPER [=n] \textbf{[~]}\\*
Mit dieser Option wird eine sysfs"=Lademöglichkeit aktiviert, um das Laden von
Firmware in den Kernel über den Userspace als Fallback"=Mechanismus zu
ermöglichen, und zwar nur dann, wenn die direkte Dateisystem"=Suche des Kernels
nach der Firmware unter Verwendung der verschiedenen
\texttt{/lib/firmware/}"=Pfade oder des im Modulparameter \texttt{firmware\_class}
path angegebenen Pfades oder des Kernel"=Boot"=Parameters \texttt{firmware\_class}
path fehlgeschlagen ist, wenn die firmware\_class eingebaut ist.
Einzelheiten zur Arbeit mit dem sysfs"=Fallback"=Mechanismus finden Sie in
Documentation/driver-api/firmware/fallback-mechanisms.rst.\\
Die direkte Dateisystem"=Suche nach Firmware wird nun immer zuerst verwendet.
Wenn die direkte Dateisystem"=Suche des Kernels nach Firmware die angeforderte
Firmware nicht findet, wird eine sysfs"=Fallback"=Lademöglichkeit zur Verfügung
gestellt, und der Userspace wird durch uevents darüber informiert. Das uevent
kann unterdrückt werden, wenn der Treiber es explizit anfordert. Wenn der
benutzerdefinierte Fallback"=Mechanismus verwendet wird, muss der Userspace
immer bestätigen, dass die Firmware nicht gefunden wurde, da die
Zeitüberschreitung für den Fallback"=Mechanismus deaktiviert ist und
fehlgeschlagene Anfragen für immer verweilen.
Dies war früher die Standard"=Firmware"=Lademöglichkeit, und udev lauschte
auf uvents, um Firmware für den Kernel zu laden. Die Funktionalität der
Firmware"=Lademöglichkeit in udev wurde entfernt, so dass sie nicht mehr als
Ausweichmechanismus verwendet werden kann. Linux verlässt sich nicht mehr auf
einen Fallback"=Mechanismus im Userspace und verwendet diesen auch nicht mehr.
Wenn Sie sich auf einen solchen Mechanismus verlassen müssen, wenden Sie sich
an die freizügig lizenzierte Firmwared:
\url{https://github.com/teg/firmwared}\\
Da dies früher die Standardfunktion zum Laden von Firmware war, kann es sein,
dass ein alter Userspace existiert, der sich darauf verlässt, und daher kann
dieser Mechanismus niemals aus dem Kernel entfernt werden.
Sie sollten diese Funktionalität nur aktivieren, wenn Sie sicher sind, dass
Sie einen Ausweichmechanismus benötigen und einen Userspace"=Mechanismus
bereithalten, um Firmware zu laden, falls diese nicht gefunden wird. Ein
Hauptgrund dafür kann sein, dass Sie Treiber haben, die eine eingebaute
Firmware benötigen und aus irgendeinem Grund die benötigte Firmware nicht in
initramfs unterbringen können.
Ein weiterer Grund, warum Kernel diese Funktion aktiviert haben können, ist
die Unterstützung eines Treibers, der explizit auf diesen Fallback"=Mechanismus
angewiesen ist. Derzeit benötigen nur zwei Treiber diese Funktion:
\begin{itemize}
	\item CONFIG\_LEDS\_LP55XX\_COMMON
	\item CONFIG\_DELL\_RBU
\end{itemize}
Abgesehen von der Unterstützung der oben genannten Treiber kann ein weiterer
Grund dafür sein, dass Ihre Firmware außerhalb der Pfade liegt, nach denen der
Kernel sucht, und nicht mit dem Modulparameter firmware\_class path oder dem
Boot"=Parameter firmware\_class path des Kernels angegeben werden kann, wenn
firmware\_class eingebaut ist.
Ein moderner Anwendungsfall könnte darin bestehen, während der Bereitstellung
vorübergehend eine benutzerdefinierte Partition einzuhängen, auf die nur der
Userspace Zugriff hat, und diese dann zu verwenden, um nach der benötigten
Firmware zu suchen und sie zu holen. Eine solche Art von Treiberfunktionalität
wird von den Herstellern möglicherweise nicht einmal gewünscht, so dass sie
nur als Schnittstelle für die Bereitstellung unterstützt werden muss.
Da die Firmware"=Lademöglichkeit von udev entfernt wurde, können Sie
firmwared oder einen Fork davon verwenden, um die Art und Weise, wie Sie
Firmware auf der Grundlage von ausgegebenen uevents laden wollen, anzupassen.
Wenn Sie diese Option aktivieren, erhöht sich die Größe Ihres Kernel"=Images
um etwa 13436~Bytes.\\
Wenn Sie sich unsicher sind, sagen Sie hier N, es sei denn, Sie sind eine
Linux"=Distribution und müssen die beiden oben genannten Treiber unterstützen
oder Sie sind sich sicher, dass Sie eine wirklich benutzerdefinierte
Firmware"=Lademöglichkeit im Userspace unterstützen müssen.

\subparagraph{Enable compressed firmware support}$~$\\
CONFIG\_FW\_LOADER\_COMPRESS [=y] \textbf{[Y]}\\*
Diese Option aktiviert die Unterstützung für das Laden komprimierter
Firmware"=Dateien. Der Aufrufer der Firmware"=API erhält den dekomprimierten
Dateiinhalt. Die komprimierte Datei wird nur dann als Fallback geladen, wenn
das Laden der Rohdatei zunächst fehlgeschlagen ist.\\
Die Unterstützung für komprimierte Firmware gilt nicht für Firmware-Images,
die in das Kernel-Image eingebaut sind (CONFIG\_EXTRA\_FIRMWARE).

\subsubparagraph{Enable XZ-compressed firmware support}$~$\\
CONFIG\_FW\_LOADER\_COMPRESS\_XZ [=y] \textbf{[Y]}\\*
Mit dieser Option wird die Unterstützung für XZ"=komprimierte Dateien
hinzugefügt. Die Dateien müssen entweder mit dem Integritätsprüfungstyp
\texttt{none} oder \texttt{crc32} komprimiert sein (übergeben Sie die Option
\texttt{\dq -C crc32\dq} an den Befehl \texttt{xz}).

\subsubparagraph{Enable ZSTD-compressed firmware support}$~$\\
CONFIG\_FW\_LOADER\_COMPRESS\_ZSTD [=y] \textbf{[Y]}\\*
Mit dieser Option wird die Unterstützung für ZSTD"=komprimierte Dateien
hinzugefügt.

\subparagraph{Enable firmware caching during suspend}$~$\\
CONFIG\_FW\_CACHE [=y] \textbf{[Y]}\\*
Da die Firmware"=Zwischenspeicherung uevent"=Meldungen erzeugt, die über
einen Netlink"=Socket gesendet werden, kann sie auf vielen Plattformen ein
Suspendieren verhindern. Es ist auch nicht immer nützlich, daher haben wir
auf solchen Plattformen die Option.\\
Wenn Sie unsicher sind, sagen Sie Y.

\subparagraph{Enable users to initiate firmware updates using sysfs}$~$\\
CONFIG\_FW\_UPLOAD [=y] \textbf{[Y]}\\*
Durch die Aktivierung dieser Option können Gerätetreiber eine persistente
\texttt{sysfs}"=Schnittstelle bereitstellen, über die Firmware"=Updates aus
dem Userspace initiiert werden können. Beispielsweise laden FPGA"=basierte
PCIe"=Karten beim Booten der Karte Firmware und FPGA"=Images aus dem lokalen
FLASH. Die Images im FLASH können durch neue, vom Benutzer bereitgestellte
Images aktualisiert werden. Aktivieren Sie dieses Gerät, um Karten zu
unterstützen, die auf vom Benutzer initiierte Updates für Firmware"=Dateien
angewiesen sind.
Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{Driver Core verbose debug message}
CONFIG\_DEBUG\_DRIVER [=n] \textbf{[~]}\\*
Geben Sie hier Y an, wenn Sie möchten, dass der Treiberkern eine Reihe von
Debugmeldungen in das Systemprotokoll schreibt. Wählen Sie dies, wenn Sie ein
Problem mit dem Treiberkern haben und mehr über die Vorgänge erfahren möchten.
Wenn Sie sich nicht sicher sind, wählen Sie hier N.

\subsubsection{Managed device resources verbose debug messages}
CONFIG\_DEBUG\_DEVRES [=n] \textbf{[~]}\\*
Diese Option aktiviert den Kernelparameter devres.log. Wenn sie auf einen Wert
ungleich Null gesetzt ist, werden Devres"=Debug"=Meldungen gedruckt. Wählen
Sie diese Option, wenn Sie ein Problem mit devres haben oder die
Ressourcenverwaltung für ein verwaltetes Gerät debuggen wollen. 
\texttt{devres.log}
kann vom sysfs"=Knoten aus ein- und ausgeschaltet werden.\\
Wenn Sie sich diesbezüglich unsicher sind, sagen Sie hier N.

\subsubsection{Test driver remove calls during probe (UNSTABLE)}
CONFIG\_DEBUG\_TEST\_DRIVER\_REMOVE [=n] \textbf{[~]}\\*
Geben Sie hier Y an, wenn Sie möchten,
dass der Treiberkern die Funktionen zum Entfernen von Treibern durch den
Aufruf von probe, remove, probe testet. Dadurch wird der Entfernungspfad
getestet, ohne dass der Treiber entbunden oder das Treibermodul entladen
werden muss.
Es wird erwartet, dass diese Option Fehler findet und Ihr System unbrauchbar
machen kann. Sie sollten hier N angeben, es sei denn, Sie wollen diese
Funktion ausdrücklich testen.

\subsubsection{Build kernel module to test asynchronous driver probing}
CONFIG\_TEST\_ASYNC\_DRIVER\_PROBE [=n] \textbf{[~]}\\*
Die Aktivierung dieser Option erzeugt ein Kernelmodul, mit dem die asynchrone
Treiberprüfung durch den Gerätekern getestet werden kann.
Der Modulname lautet \texttt{test\_async\_driver\_probe.ko}\\
Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{Enable verbose DMA\_FENCE\_TRACE messages}
CONFIG\_DMA\_FENCE\_TRACE [=n] \textbf{[~]}\\*
Aktivieren Sie die Druckfunktion DMA\_FENCE\_TRACE. Dies fügt dem
Konsolenprotokoll zusätzlichen Spam hinzu, erleichtert aber die Diagnose
von Problemen im Zusammenhang mit Blockierungen bei DMA"=Puffern, die von
mehreren Geräten gemeinsam genutzt werden.

\subsubsection{sync\_state() behavior defaults to timeout instead of strict}
CONFIG\_FW\_DEVLINK\_SYNC\_STATE\_TIMEOUT [=n] \textbf{[~]}\\*
Dies entspricht dem Hinzufügen des Kernel"=Kommandozeilenparameters\\
\texttt{\dq fw\_devlink.sync\_state=timeout\dq}.\\
Geben Sie das Warten auf Verbraucher auf und rufen Sie sync\_state() auf
allen Geräten auf, die ihre sync\_state()"=Aufrufe noch nicht erhalten haben,
nachdem deferred\_probe\_timeout abgelaufen ist oder durch late\_initcall(),
wenn !CONFIG\_MODULES. Sie sollten hier fast immer N auswählen, es sei denn,
Sie haben bereits erfolgreich mit der Kommandozeilenoption auf jedem
System/Board getestet, auf dem Ihr Kernel voraussichtlich funktionieren wird.

\subsection{Bus devices \texorpdfstring{$\rightarrow$}{->}}
\textit{(Bus-Geräte)}

\subsubsection{Modem Host Interface (MHI) bus}
CONFIG\_MHI\_BUS [=m] \textbf{[M]}\\*
Bustreiber für das MHI"=Protokoll. Modem Host Interface (MHI) ist ein
Kommunikationsprotokoll, das von den Host"=Prozessoren zur Steuerung und
Kommunikation mit Modemgeräten über einen Hochgeschwindigkeits"=Peripheriebus
oder gemeinsamen Speicher verwendet wird.

\paragraph{Debugfs support for the MHI bus}$~$\\
CONFIG\_MHI\_BUS\_DEBUG [=n] \textbf{[~]}\\*
Aktiviert die Unterstützung von debugfs für die Verwendung mit dem MHI-Transport.
Ermöglicht das Lesen und/oder Ändern einiger Werte innerhalb des MHI"=Controllers
zu Debug- und Testzwecken.

\paragraph{MHI PCI controller driver}$~$\\
CONFIG\_MHI\_BUS\_PCI\_GENERIC [=m] \textbf{[M]}\\*
Dieser Treiber bietet einen MHI PCI"=Controller"=Treiber für Geräte wie Qualcomm
SDX55"=basierte PCIe"=Modems.

\subsubsection{Modem Host Interface (MHI) bus Endpoint implementation}
CONFIG\_MHI\_BUS\_EP [=m] \textbf{[M]}\\*
Bustreiber für das MHI-Protokoll. Modem Host Interface (MHI) ist ein
Kommunikationsprotokoll, das von einem Host"=Prozessor zur Steuerung und
Kommunikation eines Modemgeräts über einen Hochgeschwindigkeits"=Peripheriebus
oder einen gemeinsamen Speicher verwendet wird.
MHI\_BUS\_EP implementiert das MHI"=Protokoll für die Endpunktgeräte, wie z.~B.
das SDX55"=Modem, das über PCIe mit dem Host"=Rechner verbunden ist.

%15.7
\subsection{Cache Drivers ---}
\textit{(Pufferspeicher-Treiber)}

\subsection{Connector -- unified userspace 
\texorpdfstring{$\leftrightarrow$}{<->} kernelspace linker 
\texorpdfstring{$\rightarrow$}{->}}
CONFIG\_CONNECTOR [=y] \textbf{[Y]}\\*
Dies ist ein vereinheitlichter Userspace $\leftrightarrow$
Kernelspace"=Anschluss,
der auf dem Netlink"=Socket"=Protokoll aufbaut.
Connector"=Unterstützung kann auch als Modul gebaut werden.
Wenn dies der Fall ist, wird das Modul \texttt{cn} genannt.

\subsubsection{Report process events to userspace}
CONFIG\_PROC\_EVENTS [=y] \textbf{[Y]}\\*
Einen Konnektor bereitstellen, der Prozessereignisse an den Userspace meldet.
Senden Sie Ereignisse wie fork, exec, id-Änderung (uid, gid, suid, etc.)
und exit.

%15.9
\subsection{Firmware Drivers \texorpdfstring{$\rightarrow$}{->}}
\textit{(Firmware-Treiber)}

\subsubsection{ARM System Control and Management Interface Protocol ---}
\textit{(ARM-Systemsteuerungs- und Verwaltungsschnittstellenprotokoll)}

\subsubsection{BIOS Enhanced Disk Drive calls determine boot disk}
CONFIG\_EDD [=m] \textbf{[M]}\\*
Geben Sie hier Y oder M an, wenn Sie die BIOS Enhanced Disk Drive Services
aktivieren wollen, die das BIOS im realen Modus aufruft, um festzustellen,
von welcher Festplatte das BIOS zu booten versucht. Diese Information wird
dann über sysfs exportiert.
Diese Option ist experimentell und es ist bekannt, dass sie bei einigen
obskuren Konfigurationen nicht bootet. Die meisten BIOS"=Hersteller von
Festplattencontrollern implementieren diese Funktion noch nicht.

\paragraph{Sets default behavior for EDD detection to off}$~$\\
CONFIG\_EDD\_OFF [=n] \textbf{[~]}\\*
Sagen Sie Y, wenn Sie EDD standardmäßig deaktivieren wollen, obwohl es in
den Kernel einkompiliert ist. Sagen Sie N, wenn Sie EDD standardmäßig
aktivieren wollen. EDD kann mit dem Kernelparameter
\texttt{edd=$\{$on|skipmbr|off$\}$} dynamisch eingestellt werden.

%15.9.3
\subsubsection{Export DMI identification via sysfs to userspace}
CONFIG\_DMIID [=y] \textbf{[Y]}\\*
Geben Sie hier Y an, wenn Sie SMBIOS/DMI"=Systemidentifikationsinformationen
aus dem Userspace über \texttt{/sys/class/dmi/id/} abfragen wollen oder
wenn Sie
DMI"=basiertes automatisches Laden von Modulen wünschen.

%15.9.4
\subsubsection{DMI table support in sysfs}
CONFIG\_DMI\_SYSFS [=y] \textbf{[Y]}\\*
Geben Sie hier Y oder M ein, um den Export der Rohdaten der DMI"=Tabelle
über sysfs zu aktivieren. Dies ist nützlich, um die Daten zu konsumieren,
ohne überhaupt Zugriff auf \texttt{/dev/mem} zu benötigen.
Die Tabellen befinden sich unter \texttt{/sys/firmware/dmi}, wenn diese
Option aktiviert und geladen ist.

\subsubsection{iSCSI Boot Firmware Table Attributes}
CONFIG\_ISCSI\_IBFT\_FIND [=y] \textbf{[Y]}\\*
Mit dieser Option kann der Kernel den Speicherbereich finden, in dem sich
die ISCSI Boot Firmware Table (iBFT) befindet. Dies ist notwendig, damit das
Modul iSCSI Boot Firmware Table Attributes richtig funktioniert.

\subsubsection{iSCSI Boot Firmware Table Attributes module}
CONFIG\_ISCSI\_IBFT [=m] \textbf{[M]}\\*
Diese Option aktiviert die Unterstützung für die Erkennung und Offenlegung
der iSCSI Boot Firmware Table (iBFT) über sysfs im Userspace. Wenn Sie die
iSCSI"=Boot"=Parameter während des Systemstarts dynamisch erkennen möchten,
geben Sie Y an.
Andernfalls sagen Sie N.

\subsubsection{QEMU fw\_cfg device support in sysfs}
CONFIG\_FW\_CFG\_SYSFS [=m] \textbf{[M]}\\*
Geben Sie hier Y oder M ein, um den Export der QEMU"=Firmware"=Konfigurationsdatei
(fw\_cfg) über sysfs zu aktivieren. Die Einträge befinden sich unter
\texttt{/sys/firmware/fw\_cfg}, wenn diese Option aktiviert und geladen ist.

\paragraph{QEMU fw\_cfg device parameter parsing}$~$\\
CONFIG\_FW\_CFG\_SYSFS\_CMDLINE [=n] \textbf{[~]}\\*
Ermöglicht die Initialisierung des Geräts \texttt{qemu\_fw\_cfg} über die
Kernel"=Befehlszeile oder über einen Modulparameter.\\
WARNUNG: Die Verwendung falscher Parameter (insbesondere der Basisadresse)
kann Ihr System zum Absturz bringen.

\subsubsection{Mark VGA/VBE/EFI FB as generic system framebuffer}
CONFIG\_SYSFB\_SIMPLEFB [=y] \textbf{[Y]}\\*
Firmwares stellen oft anfängliche Grafik"=Framebuffer zur Verfügung, so dass
das BIOS, der Bootloader oder der Kernel die grundlegende Videoausgabe während
des Bootens zur Benutzerführung und Fehlersuche anzeigen kann. In der
Vergangenheit wurden hierfür die VESA-BIOS"=Erweiterungen und EFI"=Framebuffer
verwendet, die meist auf x86"=BIOS oder EFI"=Systeme beschränkt sind.\\
Wenn diese Option aktiviert ist, werden VGA/VBE/EFI"=Framebuffer als
generische Framebuffer markiert, so dass stattdessen die neuen generischen
System"=Framebuffer"=Treiber verwendet werden können. Wenn der Framebuffer
nicht mit den generischen Modi kompatibel ist, wird er als
Fallback"=Plattform"=Framebuffer angezeigt, so dass Legacy"=Treiber wie
efifb, vesafb und uvesafb ihn verwenden können.
Wenn diese Option nicht ausgewählt ist, werden alle System"=Framebuffer wie
üblich als Fallbac"=-Plattform"=Framebuffer gekennzeichnet.
Hinweis: Ältere fbdev"=Treiber, einschließlich vesafb, efifb und uvesafb,
sind nicht in der Lage, generische System"=Framebuffer zu erkennen, wenn
diese Option aktiviert ist. Es wird dringend empfohlen, simplefb als Ersatz
zu aktivieren, wenn Sie diese Option wählen. simplefb kann korrekt mit
generischen System"=Framebuffern umgehen. Sie sollten jedoch vesafb und
andere als Ersatz aktivieren, wenn ein System"=Framebuffer nicht mit
simplefb kompatibel ist.
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{Google Firmware Drivers \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_GOOGLE\_FIRMWARE [=y] \textbf{[Y]}\\*
Diese Firmware-Treiber werden von Google"=Servern, Chromebooks und anderen
Geräten mit Coreboot"=Firmware verwendet.
Im Zweifelsfall sagen Sie N.

\paragraph{SMI interface for Google platforms}$~$\\
CONFIG\_GOOGLE\_SMI [=n] \textbf{[~]}\\*
Sagen Sie hier Y, wenn Sie SMI-Callbacks für Google"=Plattformen aktivieren
wollen. Dies bietet eine Schnittstelle zum Schreiben und Löschen des
Ereignisprotokolls. Wenn CONFIG\_EFI ebenfalls aktiviert ist, bietet dieser
Treiber eine Schnittstelle zum Lesen und Schreiben von NVRAM"=Variablen.

\paragraph{CBMEM entries in sysfs}$~$\\
CONFIG\_GOOGLE\_CBMEM [=m] \textbf{[M]}\\*
CBMEM ist ein nach unten wachsender Speicherbereich, der vom Coreboot-BIOS
erstellt wird und mit Tags versehene Datenstrukturen des BIOS enthält.
Diese Datenstrukturen stellen Dinge wie die verifizierten Boot"=Firmware"=Variablen,
das Flash"=Layout, das Firmware"=Ereignisprotokoll und mehr dar.
Diese Option aktiviert das cbmem"=Modul, das den Kernel veranlasst, nach
Coreboot"=CBMEM"=Einträgen zu suchen und den Speicher für jeden Eintrag in
sysfs unter \texttt{/sys/bus/coreboot/devices/cbmem-$<$id$>$} freizugeben.

\paragraph{Coreboot Table Access}$~$\\
CONFIG\_GOOGLE\_COREBOOT\_TABLE [=m] \textbf{[M]}\\*
Diese Option aktiviert das Modul coreboot\_table, das anderen Firmware"=Modulen
den Zugriff auf die coreboot"=Tabelle ermöglicht. Der Zugriff auf den Zeiger
der coreboot"=Tabelle erfolgt über das ACPI"=Objekt "GOOGCB00" oder den
Gerätebaumknoten /firmware/coreboot.
Wenn Sie unsicher sind, sagen Sie N.

\paragraph{Firmware Memory Console -- X86 Legacy support}$~$\\
CONFIG\_GOOGLE\_MEMCONSOLE\_X86\_LEGACY [=n] \textbf{[~]}\\*
Diese Option ermöglicht es dem Kernel, in der EBDA auf Google-Servern nach
einem Firmware"=Protokoll zu suchen. Wenn es gefunden wird, wird dieses
Protokoll in der Datei \texttt{/sys/firmware/log} in das
Benutzerland (userland) exportiert.

\paragraph{Coreboot Framebuffer}$~$\\
CONFIG\_GOOGLE\_FRAMEBUFFER\_COREBOOT [=m] \textbf{[M]}\\*
Diese Option ermöglicht es dem Kernel, in der Coreboot-Tabelle nach einem Framebuffer
zu suchen. Wird er gefunden, wird er mit \texttt{simplefb} registriert.

\paragraph{Firmware Memory Console}$~$\\
CONFIG\_GOOGLE\_MEMCONSOLE\_COREBOOT [=m] \textbf{[M]}\\*
Diese Option ermöglicht es dem Kernel, in der coreboot"=Tabelle nach einem
Firmware"=Protokoll zu suchen. Wenn es gefunden wird, wird dieses Protokoll
in der Datei \texttt{/sys/firmware/log} in das Benutzerland (userland)
exportiert.

\paragraph{Vital Product Data}$~$\\
CONFIG\_GOOGLE\_VPD [=m] \textbf{[M]}\\*
Diese Option ermöglicht es dem Kernel, den Inhalt von Google VPD unter
\texttt{/sys/firmware/vpd} zu veröffentlichen.

\subsubsection{EFI (Extensible Firmware Interface) Support \texorpdfstring{$\rightarrow$}{->}}
\textit{(EFI-Unterstützung (Erweiterbare Firmware-Schnittstelle))}

\paragraph{Register efivars backend for pstore}$~$\\
CONFIG\_EFI\_VARS\_PSTORE [=y] \textbf{[Y]}\\*
Sagen Sie hier Y, um die Verwendung von \texttt{efivars} als Backend für
\texttt{pstore} zu aktivieren. Dies ermöglicht das Schreiben von
Konsolenmeldungen, Crash"=Dumps oder anderen von pstore unterstützten Daten
in EFI"=Variablen.

\subparagraph{Disable using efivars as a pstore backend by default}$~$\\
CONFIG\_EFI\_VARS\_PSTORE\_DEFAULT\_DISABLE [=y] \textbf{[Y]}\\*
Wenn Sie hier Y angeben, wird die Verwendung von efivars als Speicher-Backend für
pstore standardmäßig deaktiviert. Diese Einstellung kann mit dem Parameter
\texttt{pstore\_disable} des \texttt{efivars}-Moduls außer Kraft gesetzt werden.

\paragraph{Reserve EFI Specific Purpose Memory}$~$\\
CONFIG\_EFI\_SOFT\_RESERVE [=y] \textbf{[Y]}\\*
Auf Systemen mit gemischten Leistungsklassen des Speichers kann EFI mit einem Attribut
einen bestimmten Zweck des Speichers angeben (siehe EFI\_MEMORY\_SP in UEFI~2.8).
Ein mit diesem Attribut gekennzeichneter Speicherbereich kann im Vergleich zum allgemeinen
\glqq System"=RAM\grqq{}"=Pool des Systems einzigartige Leistungsmerkmale aufweisen. In der Erwartung,
dass ein solcher Speicher anwendungsspezifisch genutzt wird und sein EFI"=Basistyp
\glqq konventionell\grqq{} ist, antwortet Y, damit der Kernel ihn als
\glqq Soft Reserved\grqq{}-Ressource reserviert und standardmäßig für den Direktzugriff
(device-dax) reserviert. Der Speicherbereich kann später optional dem Page Allocator durch
die Systemadministrator"=Policy über die device"=dax kmem"=Funktion zugewiesen werden.
Sagen Sie N, damit der Kernel diesen Speicher standardmäßig als \glqq System-RAM\grqq{}
behandelt.\\
Wenn Sie unsicher sind, sagen Sie Y.

\paragraph{Adjust memory attributes in EFISTUB}$~$\\
CONFIG\_EFI\_DXE\_MEM\_ATTRIBUTES [=y] \textbf{[Y]}\\*
Die UEFI-Spezifikation garantiert nicht, dass der gesamte Speicher sowohl zum Schreiben
als auch zum Ausführen zugänglich ist, wie es der Kernel erwartet.\\
Verwenden Sie DXE-Dienste, um Speicherschutzattribute während des Bootens über EFISTUB
zu prüfen und zu ändern, um sicherzustellen, dass die vom Kernel verwendeten
Speicherbereiche beschreibbar und ausführbar sind.

\paragraph{EFI Bootloader Control}$~$\\
CONFIG\_EFI\_BOOTLOADER\_CONTROL [=m] \textbf{[M]}\\*
Dieses Modul installiert einen Reboot-Hook, so dass, wenn reboot() mit einem
String-Argument NNN aufgerufen wird, \glqq NNN\grqq{} in die EFI"=Variable
\glqq LoaderEntryOneShot\grqq{} kopiert wird, um vom Bootloader gelesen zu werden.\\
Wenn die Zeichenkette mit einem der in seiner Konfiguration definierten Boot-Labels
übereinstimmt, bootet der Bootloader einmal mit diesem Label.
Die EFI"=Variable
\glqq LoaderEntryRebootReason\grqq{} wird mit dem Reboot"=Grund gesetzt:
\glqq reboot\grqq{} oder \glqq shutdown\grqq{}. Der Bootloader liest diesen
Reboot"=Grund ein und ergreift bestimmte Maßnahmen entsprechend seiner Richtlinie.

\paragraph{EFI capsule loader}$~$\\
CONFIG\_EFI\_CAPSULE\_LOADER [=m] \textbf{[M]}\\*
Diese Option stellt eine Laderschnittstelle \texttt{/dev/efi\_capsule\_loader} zur Verfügung,
über die Benutzer EFI"=Kapseln laden können. Dieser Treiber erfordert eine funktionierende
Runtime"=Kapselunterstützung in der Firmware, die viele OEMs nicht bieten.\\
Die meisten Benutzer sollten N sagen.

\paragraph{EFI Runtime Service Tests Support}$~$\\
CONFIG\_EFI\_TEST [=n] \textbf{[~]}\\*
Dieser Treiber verwendet die \texttt{efi.$<$service$>$}"=Funktionszeiger direkt, anstatt über die
efivar"=API zu gehen, da er nicht versucht, das Kernel"=Subsystem zu testen, sondern nur
die UEFI"=Laufzeitdienstschnittstellen, die von der Firmware bereitgestellt werden.
Dieser Treiber wird von der Firmware Test Suite (FWTS) zum Testen der
UEFI"=Laufzeitschnittstellen der Firmware verwendet.
Details zur FWTS sind verfügbar unter:
\url{https://wiki.ubuntu.com/FirmwareTestSuite}
Sagen Sie hier Y, um die Unterstützung der Laufzeitdienste über \texttt{/dev/efi\_test}
zu aktivieren.
Wenn Sie unsicher sind, sagen Sie N.

\paragraph{Apple Device Properties}$~$\\
CONFIG\_APPLE\_PROPERTIES [=y] \textbf{[Y]}\\*
Rufen Sie Eigenschaften von EFI auf Apple Macs ab und weisen Sie sie Geräten zu, was eine
verbesserte Unterstützung von Apple"=Hardware ermöglicht. Zu den Eigenschaften, die sonst
fehlen würden, gehören das Thunderbolt"=Geräte"=ROM und die GPU"=Konfigurationsdaten.
Wenn Sie unsicher sind, sagen Sie Y, wenn Sie einen Mac haben. Andernfalls N.

\paragraph{Reset memory attack mitigation}$~$\\
CONFIG\_RESET\_ATTACK\_MITIGATION [=n] \textbf{[~]}\\*
Verlangen Sie, dass die Firmware den Inhalt des RAM nach einem Neustart unter Verwendung
der TCG Platform Reset Attack Mitigation Spezifikation löscht. Dies schützt davor, dass ein
Angreifer das System gewaltsam neu startet, während es noch Geheimnisse im RAM enthält, ein
anderes Betriebssystem startet und die Geheimnisse extrahiert. Diese Funktion sollte nur
aktiviert werden, wenn Userland so konfiguriert ist, dass das MemoryOverwriteRequest"=Flag
beim sauberen Herunterfahren gelöscht wird, nachdem die Geheimnisse entfernt wurden, da sie
sonst auch bei sauberen Neustarts ausgelöst wird.

\paragraph{EFI Runtime Configuration Interface Table Version 2 Support}$~$\\
CONFIG\_EFI\_RCI2\_TABLE [=y] \textbf{[Y]}\\*
Zeigt den Inhalt der Runtime Configuration Interface Table Version~2 auf
Dell EMC PowerEdge"=Systemen als binäres Attribut \glqq rci2\grqq{} im
Verzeichnis \texttt{/sys/firmware/efi/tables} an.
Die RCI2"=Tabelle enthält BIOS HII im XML"=Format und wird zum Auffüllen der
BIOS"=Setup"=Seite im Dell EMC OpenManage Server Administrator"=Tool verwendet.
Die BIOS"=Setup"=Seite enthält BIOS"=Tokens, die konfiguriert werden können.
Geben Sie hier Y für Dell EMC PowerEdge"=Systeme an.

\paragraph{Clear Busmaster bit on PCI bridges during ExitBootServices()}$~$\\
CONFIG\_EFI\_DISABLE\_PCI\_DMA [=n] \textbf{[~]}\\*
Deaktivieren Sie das Busmaster"=Bit im Kontrollregister auf allen PCI"=Brücken, während Sie
ExitBootServices() aufrufen und die Kontrolle an den Laufzeitkernel übergeben. Die
System"=Firmware kann die IOMMU so konfigurieren, dass böswillige PCI"=Geräte nicht in der
Lage sind, das Betriebssystem über DMA anzugreifen. Da die Firmware jedoch nicht garantieren
kann, dass das Betriebssystem IOMMU"=fähig ist, wird sie die IOMMU"=Konfiguration abbauen,
wenn ExitBootServices() aufgerufen wird. Dadurch bleibt ein Zeitfenster, in dem ein
feindliches Gerät noch Schaden anrichten kann, bevor Linux die IOMMU erneut konfiguriert.
Wenn Sie hier Y angeben, wird der EFI"=Stub das Busmaster"=Bit auf allen PCI"=Brücken
löschen, bevor ExitBootServices() aufgerufen wird. Dadurch wird verhindert, dass böswillige
PCI"=Geräte DMA durchführen können, bis der Kernel das Busmastering nach der Konfiguration
der IOMMU wieder aktiviert.
Diese Option kann bei einigen Geräten mit schlechtem Verhalten zu Fehlern führen und sollte
nicht ohne Test aktiviert werden. Die Kernel"=Befehlszeilenoptionen
\texttt{efi=disable\_early\_pci\_dma} oder \texttt{efi=no\_disable\_early\_pci\_dma} können
verwendet werden, um diese Option außer Kraft zu setzen.

\paragraph{Load custom ACPI SSDT overlay from an EFI variable}$~$\\
CONFIG\_EFI\_CUSTOM\_SSDT\_OVERLAYS [=y] \textbf{[Y]}\\*
Ermöglicht das Laden eines ACPI-SSDT-Overlays aus einer EFI"=Variablen, die durch eine
Kernel"=Befehlszeilenoption angegeben wird.
Siehe Documentation/admin-guide/acpi/ssdt-overlays.rst für weitere Informationen.

\paragraph{Disable EFI runtime services support by default}$~$\\
CONFIG\_EFI\_DISABLE\_RUNTIME [=n] \textbf{[N]}\\*
Erlaubt es, die Unterstützung der EFI-Laufzeitdienste standardmäßig zu deaktivieren.
Dies kann bereits durch die Verwendung der Option \texttt{efi=noruntime} erreicht werden,
aber es könnte nützlich sein, diese Voreinstellung ohne einen Kernel"=Befehlszeilenparameter zu haben.
Die EFI"=Laufzeitdienste sind standardmäßig deaktiviert, wenn PREEMPT\_RT aktiviert ist, da Messungen
gezeigt haben, dass einige EFI"=Funktionsaufrufe zu viel Zeit benötigen, um abgeschlossen zu werden,
was zu großen Latenzen führen kann, was ein Problem für Echtzeit"=Kernel darstellt.
Diese Voreinstellung kann mit der Option \texttt{efi=runtime} außer Kraft gesetzt werden.

\paragraph{EFI Confidential Computing Secret Area Support}$~$\\
CONFIG\_EFI\_COCO\_SECRET [=y] \textbf{[Y]}\\*
Confidential Computing"=Plattformen (z.~B. AMD SEV) ermöglichen es dem Gastbesitzer, während
des Starts der Gast"=VM auf sichere Weise Geheimnisse einzubringen. Die Geheimnisse werden in
einem bestimmten reservierten EFI"=Speicherbereich abgelegt.
Um die Geheimnisse im Kernel verwenden zu können, muss der Ort des geheimen Bereichs (wie in
der EFI"=Konfigurationstabelle veröffentlicht) beibehalten werden.
Wenn Sie hier Y angeben, wird die Adresse des EFI"=Geheimbereichs für die Verwendung im Kernel
beibehalten. Dadurch kann das Modul \texttt{virt/coco/efi\_secret} auf die Secrets zugreifen,
was wiederum Userspace"=Programmen den Zugriff auf die injizierten Secrets ermöglicht.

\subsubsection{Qualcomm firmware drivers ---}
\textit{(Qualcomm-Firmware-Treiber)}

\subsubsection{Tegra firmware drivers ---}
\textit{(Tegra-Firmware-Treiber)}

\subsection{GNSS receiver support \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_GNSS \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Sagen Sie hier Y, wenn Sie einen GNSS"=Empfänger (z.~B. einen GPS"=Empfänger) haben.
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
Das Modul wird \texttt{gnss} genannt.

\subsubsection{Mediatek GNSS receiver support}
CONFIG\_GNSS\_MTK\_SERIAL \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Sagen Sie hier Y, wenn Sie einen Mediatek"=basierten GNSS"=Empfänger haben, der eine
serielle Schnittstelle verwendet.
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M: Das Modul wird
\texttt{gnss-mtk} genannt.
Wenn Sie unsicher sind, wählen Sie N.

\subsubsection{SiRFstar GNSS receiver support}
CONFIG\_GNSS\_SIRF\_SERIAL \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Sagen Sie hier Y, wenn Sie einen SiRFstar"=basierten GNSS"=Empfänger haben, der eine
serielle Schnittstelle verwendet.
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M: Das Modul
wird \texttt{gnss-sirf} genannt.
Wenn Sie unsicher sind, wählen Sie N.

\subsubsection{u-blox GNSS receiver support}
CONFIG\_GNSS\_UBX\_SERIAL \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Sagen Sie hier Y, wenn Sie einen GNSS-Empfänger von u-blox haben, der eine serielle
Schnittstelle verwendet.
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
Das Modul wird \texttt{gnss-ubx} genannt.
Wenn Sie unsicher sind, wählen Sie N.

\subsubsection{USB GNSS receiver support}
CONFIG\_GNSS\_USB \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Geben Sie hier Y ein, wenn Sie einen GNSS-Empfänger haben, der eine
USB-Schnittstelle verwendet.
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
Das Modul wird \texttt{gnss-usb} genannt.
Wenn Sie unsicher sind, sagen Sie N.

\subsection{Memory Technology Devices (MTD) support \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_MTD \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
Memory Technology Devices sind Flash-, RAM- und ähnliche Chips, die häufig für
Solid"=State"=Dateisysteme auf eingebetteten Geräten verwendet werden. Diese Option
bietet die allgemeine Unterstützung für MTD"=Treiber, um sich beim Kernel zu registrieren,
und für potenzielle Benutzer von MTD"=Geräten, um die vorhandenen Geräte aufzulisten und
einen Zugriff auf sie zu erhalten. Sie ermöglicht es Ihnen auch, individuelle Treiber für
bestimmte Hardware und Benutzer von MTD"=Geräten auszuwählen.
Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{MTD test support (DANGEROUS)}
CONFIG\_MTD\_TESTS [=n] \textbf{[~]}\\*
Mit dieser Option werden verschiedene MTD-Tests in die Kompilierung einbezogen. Die Tests
sollten normalerweise als Kernelmodule kompiliert werden. Die Module führen verschiedene
Prüfungen und Verifizierungen durch, wenn sie geladen werden.\\
WARNUNG: Einige der Tests werden das gesamte MTD"=Gerät, das sie testen, LÖSCHEN.
Verwenden Sie diese Tests nicht, wenn Sie nicht wirklich wissen, was Sie tun.

\subsubsection{Partition parsers \texorpdfstring{$\rightarrow$}{->}}
\textit{(Partitionsparser)}

\paragraph{Command line partition table parsing}$~$\\
CONFIG\_MTD\_CMDLINE\_PARTS [=n] \textbf{[~]}\\*
Ermöglicht die generische Konfiguration der MTD"=Partitionstabellen über die Kernel"=Befehlszeile.
Mehrere Flash"=Ressourcen werden für Hardware unterstützt, bei der verschiedene Arten von
Flash"=Speicher verfügbar sind.
Die Parsing"=Funktionen müssen immer noch vom Treiber für Ihr spezielles Gerät aufgerufen werden.
Das wird nicht automatisch geschehen. Der SA1100"=Map"=Treiber (CONFIG\_MTD\_SA1100) verfügt zum
Beispiel über eine entsprechende Option.
Das Format für die Befehlszeile ist wie folgt:\\[0.5em]
\texttt{mtdparts=$<$mtddef$>$[;$<$mtddef]\\
$<$mtddef$>$ := $<$mtd-id$>$:$<$partdef$>$[,$<$partdef$>$]\\
$<$partdef$>$ := $<$size$>$[@offset][$<$name$>$][ro]\\
%$<$mtd-id$>$ := eindeutige Kennung, die bei der Zuordnung von Treiber/Gerät verwendet wird\\
$<$mtd-id$>$ := eindeutige Kennung für die Zuordnung von Treiber/Gerät\\
$<$size$>$ := Standard-Linux-Memsize ODER \dq{}-\dq{}, um den verbleibenden Platz zu kennzeichnen\\
$<$name$>$ := (NAME)}\\[0.5em]
Aufgrund der Art und Weise, wie Linux mit der Kommandozeile umgeht, sind in der Partitionsdefinition
keine Leerzeichen erlaubt, auch nicht in den mtd"=id's und Partitionsnamen.\\
Beispiele:\\
1 Flash-Ressource (mtd-id \glqq sa1100\grqq{}), mit 1 einzigen beschreibbaren Partition:\\
\texttt{mtdparts=sa1100:-}\\
Gleiches Flash, aber 2 benannte Partitionen, von denen die erste schreibgeschützt ist:\\
\texttt{mtdparts=sa1100:256k(ARMboot)ro,-(root)}\\
Wenn Sie unsicher sind, sagen Sie N.

\paragraph{RedBoot partition table parsing}$~$\\
CONFIG\_MTD\_REDBOOT\_PARTS [=n] \textbf{[~]}\\*
RedBoot ist ein ROM"=Monitor und Bootloader, der mit mehreren \glqq Images\grqq{} in
Flash"=Geräten umgeht, indem er eine Tabelle in einen der Löschblöcke auf dem Gerät
einfügt, ähnlich einer Partitionstabelle, die die Offsets, Längen und Namen aller im
Flash gespeicherten Images enthält.
Wenn Sie einen Code benötigen, der diese Tabelle erkennt und analysiert und
MTD"=\glqq{}Partitionen\grqq{} entsprechend jedem Bild in der Tabelle registriert,
aktivieren Sie diese Option.
Die Parsing"=Funktionen müssen weiterhin vom Treiber für Ihr spezielles Gerät
aufgerufen werden. Das wird nicht automatisch geschehen.
Der SA1100"=Kartentreiber (CONFIG\_MTD\_SA1100) verfügt beispielsweise über eine
Option für diese Funktion.

\subsubsection*{*** User Modules And Translation Layers ***}
\textit{(*** Benutzermodule und Übersetzungsschichten ***)}

\subsubsection{Caching block device access to MTD devices}
CONFIG\_MTD\_BLOCK [=m] \textbf{[M]}\\*
Obwohl die meisten Flash"=Chips eine zu große Löschgröße haben, um als Blockbausteine nützlich zu sein,
ist es möglich, MTD"=Bausteine, die auf RAM"=Chips basieren, auf diese Weise zu verwenden.
Dieses Blockgerät ist ein Benutzer von MTD"=Geräten, die diese Funktion erfüllen.
Beachten Sie, dass das Mounten eines JFFS2"=Dateisystems nicht die Verwendung von mtdblock erfordert.
Es ist möglich, ein rootfs unter Verwendung des MTD"=Geräts in den \texttt{root=}"=Bootargs als
\texttt{root=mtd2} oder \texttt{root=mtd:name\_of\_device} zu mounten.\\
Später kann es erweitert werden, um Lese-/Lösch-/Modifizierungs-/Schreibzyklen auf Flash"=Chips
durchzuführen, um eine kleinere Blockgröße zu emulieren. Dies ist natürlich sehr unsicher, könnte aber
für Dateisysteme nützlich sein, auf die fast nie geschrieben wird.
Für die Verwendung mit DiskOnChip"=Geräten benötigen Sie diese Option nicht. Aktivieren Sie für diese
Geräte stattdessen die NFTL"=Unterstützung (CONFIG\_NFTL).

\paragraph{Readonly block device access to MTD devices}$~$\\
CONFIG\_MTD\_BLOCK\_RO [=n] \textbf{[~]}\\*
Damit können Sie schreibgeschützte Dateisysteme (wie cramfs) von einem MTD"=Gerät einhängen, ohne den
Overhead (und die Gefahr) des Caching"=Treibers.\\
Sie benötigen diese Option nicht für die Verwendung mit DiskOnChip"=Geräten. Aktivieren Sie für diese
stattdessen die NFTL"=Unterstützung (CONFIG\_NFTL).

\subsubsection*{*** Note that in some cases UBI block is preferred. See MTD\_UBI\_BLOCK. ***}
\textit{(*** Beachten Sie, dass in einigen Fällen der UBI"=Block vorzuziehen ist. Siehe MTD\_UBI\_BLOCK. ***)}

\subsubsection{FTL (Flash Translation Layer) support}
CONFIG\_FTL [=n] \textbf{[~]}\\*
Dies bietet Unterstützung für den ursprünglichen Flash Translation Layer, der Teil der PCMCIA"=Spezifikation ist.
Es verwendet eine Art Pseudo"=Dateisystem auf einem Flash"=Gerät, um ein Blockgerät mit 512-Byte"=Sektoren zu
emulieren, auf das ein \glqq normales\grqq{} Dateisystem gelegt wird.\\
Es kann sein, dass die in diesem Code verwendeten Algorithmen patentiert sind, es sei denn, Sie leben in der
freien Welt, in der Softwarepatente nicht legal sind -- in den USA ist es nur erlaubt, diesen Code auf
PCMCIA"=Hardware zu verwenden, obwohl es Ihnen unter den Bedingungen der GPL natürlich erlaubt ist, den
Code nach Belieben zu kopieren, zu verändern und zu verbreiten. Verwenden Sie ihn einfach nicht.

\subsubsection{NFTL (NAND Flash Translation Layer) support}
CONFIG\_NFTL [=n] \textbf{[~]}\\*
Dies bietet Unterstützung für den NAND Flash Translation Layer, der auf den DiskOnChip"=Geräten von M"=Systems
verwendet wird. Es verwendet eine Art Pseudo"=Dateisystem auf einem Flash"=Gerät, um ein Blockgerät mit
512-Byte"=Sektoren zu emulieren, auf das ein \glqq normales\grqq{} Dateisystem gelegt wird.
Es kann sein, dass die in diesem Code verwendeten Algorithmen patentiert sind, es sei denn, Sie leben in der
freien Welt, wo Softwarepatente nicht legal sind -- in den USA dürfen Sie diesen Code nur auf
DiskOnChip"=Hardware verwenden, obwohl es Ihnen unter den Bedingungen der GPL natürlich erlaubt ist, den
Code nach Belieben zu kopieren, zu verändern und zu verteilen. Verwenden Sie ihn einfach nicht.

\subsubsection{INFTL (Inverse NAND Flash Translation Layer) support}
CONFIG\_INFTL [=n] \textbf{[~]}\\*
Dies bietet Unterstützung für den Inverse NAND Flash Translation Layer, der auf den neueren DiskOnChip"=Geräten
von M"=Systems verwendet wird. Dabei wird eine Art Pseudo"=Dateisystem auf einem Flash"=Gerät verwendet,
um ein Blockgerät mit 512-Byte"=Sektoren zu emulieren, auf das ein \glqq normales\grqq{} Dateisystem gelegt wird.
Es kann sein, dass die in diesem Code verwendeten Algorithmen patentiert sind, es sei denn, Sie leben in der
freien Welt, wo Softwarepatente nicht legal sind -- in den USA dürfen Sie diesen Code nur auf
DiskOnChip"=Hardware verwenden, obwohl es Ihnen unter den Bedingungen der GPL natürlich erlaubt ist, den Code
nach Belieben zu kopieren, zu verändern und zu verteilen. Verwenden Sie ihn einfach nicht.

\subsubsection{Resident Flash Disk (Flash Translation Layer) support}
CONFIG\_RFD\_FTL [=n] \textbf{[~]}\\*
Dies bietet Unterstützung für die Flash"=Übersetzungsschicht, bekannt als Resident Flash Disk (RFD),
wie sie vom Embedded BIOS von General Software verwendet wird. Es gibt einen Hinweis unter:\\
\url{http://www.gensw.com/pages/prod/bios/rfd.htm}

\subsubsection{NAND SSFDC (SmartMedia) read only translation layer}
CONFIG\_SSFDC [=n] \textbf{[~]}\\*
Dies ermöglicht den Nur-Lese-Zugriff auf SmartMedia"=formatierten NAND"=Flash.
Sie können es mit dem FAT"=Dateisystem mounten.

\subsubsection{SmartMedia/xD new translation layer}
CONFIG\_SM\_FTL [=n] \textbf{[~]}\\*
Dies ermöglicht EXPERIMENTAL R/W Unterstützung für SmartMedia/xD FTL (Flash translation layer).
Die Schreibunterstützung ist nur leicht getestet, daher wird dieser Treiber nicht für die Verwendung
mit wertvollen Daten empfohlen (wenn Sie wertvolle Daten haben, machen Sie auf jeden Fall Backups,
egal welche Software/Hardware Sie verwenden, denn man weiß nie, was Ihre Daten frisst...)
Wenn Sie nur R/O-Zugriff benötigen, können Sie einen älteren R/O-Treiber verwenden (CONFIG\_SSFDC)

\subsubsection{Log panic/oops to an MTD buffer}
CONFIG\_MTD\_OOPS [=n] \textbf{[~]}\\*
Dadurch können Panic- und Oops-Meldungen in einem Ringspeicher in einer Flash"=Partition protokolliert
werden, wo sie zu einem späteren Zeitpunkt wieder gelesen werden können.

\subsubsection{Log panic/oops to an MTD buffer based on pstore}
CONFIG\_MTD\_PSTORE [=m] \textbf{[M]}\\*
Dadurch können Panic- und Oops-Meldungen in einem Ringspeicher in einer Flash"=Partition protokolliert
werden, wo sie nach dem Mounten des pstore"=Dateisystems als Dateien zurückgelesen werden können.
Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{Swap on MTD device support}
CONFIG\_MTD\_SWAP [=n] \textbf{[~]}\\*
Bietet einen flüchtigen Block"=Gerätetreiber auf der mtd"=Partition, der für Swapping geeignet ist.
Die Zuordnung der geschriebenen Blöcke wird nicht gespeichert.
Der Treiber bietet Verschleißausgleich durch Speicherung des Löschzählers im OOB.

\subsubsection{Retain master device when partitioned}
CONFIG\_MTD\_PARTITIONED\_MASTER [=y] \textbf{[Y]}\\*
Aus historischen Gründen ist standardmäßig entweder ein Master vorhanden oder mehrere Partitionen,
aber nicht beides. Die Befürchtung war, dass Daten, die in mehreren Partitionen aufgelistet sind,
gefährlich sind; SCSI tut dies jedoch, und es ist häufig für Anwendungen nützlich. Diese Konfigurationsoption
lässt den Master bestehen, auch wenn das Gerät partitioniert ist. Sie macht außerdem das übergeordnete Gerät
der Partition zum Master"=Gerät und nicht das, was hinter dem Master"=Gerät liegt.

\subsubsection{RAM/ROM/Flash chip drivers \texorpdfstring{$\rightarrow$}{->}}
\textit{(RAM/ROM/Flash-Chip-Treiber)}

\paragraph{Detect flash chips by Common Flash Interface (CFI) probe}$~$\\
CONFIG\_MTD\_CFI [=n] \textbf{[~]}\\*
Die Common Flash Interface-Spezifikation wurde von Intel, AMD und anderen Flash"=Herstellern entwickelt und
bietet eine universelle Methode zum Testen der Fähigkeiten von Flash"=Geräten. Wenn Sie ein CFI"=kompatibles
Gerät unterstützen möchten, müssen Sie diese Option aktivieren. Weitere Informationen über CFI finden Sie unter
\url{https://www.amd.com/products/nvd/overview/cfi.html}.

\paragraph{Detect non-CFI AMD/JEDEC-compatible flash chips}$~$\\
CONFIG\_MTD\_JEDECPROBE [=n] \textbf{[~]}\\*
Diese Option ermöglicht das Sondieren von Flash-Chips im JEDEC-Stil, die nicht mit dem Common Flash Interface
kompatibel sind, verwendet aber für alle identifizierten Chips, die tatsächlich in allen Bereichen außer der
Sondierungsmethode kompatibel sind, die gemeinsamen CFI"=konformen Flash"=Treiber. Dies deckt die meisten
AMD/Fujitsu"=kompatiblen Chips und auch nicht"=CFI"=Intel"=Chips ab.

\paragraph{Support for RAM chips in bus mapping}$~$\\
CONFIG\_MTD\_RAM [=n] \textbf{[~]}\\*
Diese Option ermöglicht die grundlegende Unterstützung von RAM"=Chips, auf die über einen
Bus"=Mapping"=Treiber zugegriffen wird.

\paragraph{Support for ROM chips in bus mapping}$~$\\
CONFIG\_MTD\_ROM [=m] \textbf{[M]}\\*
Diese Option ermöglicht die grundlegende Unterstützung von ROM"=Chips, auf die über einen
Bus"=Mapping"=Treiber zugegriffen wird.

\paragraph{Support for absent chips in bus mapping}$~$\\
CONFIG\_MTD\_ABSENT [=n] \textbf{[~]}\\*
Diese Option aktiviert die Unterstützung für einen Dummy"=Treiber, der zur Zuweisung von
Platzhalter"=MTD"=Geräten auf Systemen mit gesockelten oder austauschbaren Medien verwendet wird.
Die Verwendung dieses Treibers als Fallback"=Chip"=Sonde bewahrt die erwartete
Registrierungsreihenfolge der MTD"=Geräteknoten auf dem System unabhängig vom Vorhandensein von
Medien. Geräteknoten, die mit diesem Treiber erstellt werden, geben beim Zugriff -ENODEV zurück.

\subsubsection{Mapping drivers for chip access \texorpdfstring{$\rightarrow$}{->}}
\textit{(Abbildung von Treibern für den Chipzugriff)}

\paragraph{Support non-linear mappings of flash chips}$~$\\
CONFIG\_MTD\_COMPLEX\_MAPPINGS [=n] \textbf{[~]}\\*
Dies führt dazu, dass die Chiptreiber komplizierte Paged"=Mappings von Flash"=Chips ermöglichen.

\paragraph{Flash device in physical memory map}$~$\\
CONFIG\_MTD\_PHYSMAP [=n] \textbf{[~]}\\*
Damit steht ein \glqq Mapping\grqq{}-Treiber zur Verfügung, der es dem NOR"=Flash- und
ROM"=Treibercode ermöglicht, mit Chips zu kommunizieren, die physisch im Speicher der CPU abgebildet sind.
Sie müssen die physikalische Adresse und Größe der Flash"=Chips auf Ihrer speziellen Karte sowie die
Busbreite konfigurieren, entweder statisch mit Konfigurationsoptionen oder zur Laufzeit.
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M: Das Modul wird \texttt{physmap} heißen.

\paragraph{NOR flash on Intel Vermilion Range Expansion Bus CS0}$~$\\
CONFIG\_MTD\_INTEL\_VR\_NOR [=n] \textbf{[~]}\\*
Kartentreiber für eine NOR-Flash-Bank, die sich auf dem Erweiterungsbus des Intel Vermilion Range Chipsatzes befindet.

\paragraph{Map driver for platform device RAM (mtd-ram)}$~$\\
CONFIG\_MTD\_PLATRAM [=n] \textbf{[~]}\\*
Kartentreiber für RAM-Bereiche, die über das Gerätesystem der Plattform beschrieben werden.
Mit dieser Auswahl wird automatisch der \texttt{map\_ram}-Treiber ausgewählt.

\subsubsection{Self-contained MTD device drivers \texorpdfstring{$\rightarrow$}{->}}
\textit{(Eigenständige MTD-Gerätetreiber)}

\paragraph{Ramix PMC551 PCI Mezzanine RAM card support)}$~$\\
CONFIG\_MTD\_PMC551 [=n] \textbf{[~]}\\*
Dies bietet einen MTD"=Gerätetreiber für die Ramix PMC551 RAM PCI"=Karte von Ramix Inc.
\url{http://www.ramix.com/products/memory/pmc551.html}.
Diese Geräte gibt es in Speicherkonfigurationen von $\qtyrange{32}{1000}{\mebi\byte}$.
Wenn Sie ein solches Gerät haben, sollten Sie dies aktivieren.
Wenn dieser Treiber als Modul kompiliert wird, erhalten Sie die Möglichkeit, die Größe des Blendenfensters,
das in den Speicher des Geräts zeigt, zu wählen. Das bedeutet, dass der Kernel bei einer 1G"=Karte normalerweise
eine 1G"=Speicherabbildung als Ansicht des Geräts verwenden wird.
Als Modul können Sie ein 1M"=Fenster in den Speicher wählen, und der Treiber wird das Fenster um den Speicher
des PMC551 \glqq herumschieben\grqq{}. Dies war besonders bei den 2.2"=Kerneln auf PPC"=Architekturen nützlich,
da der Kernel nur begrenzten Speicherplatz zur Verfügung hatte.

\paragraph{Support for AT45xxx DataFlash}$~$\\
CONFIG\_MTD\_DATAFLASH [=n] \textbf{[~]}\\*
Dies ermöglicht den Zugriff auf AT45xxx DataFlash"=Chips über SPI. Manchmal sind DataFlash"=Chips in Karten
im MMC"=Format verpackt; zu diesem Zeitpunkt kann der MMC"=Stack diese nicht verarbeiten.

\paragraph{Microchip 23K256 SRAM}$~$\\
CONFIG\_MTD\_MCHP23K256 [=n] \textbf{[~]}\\*
Dies ermöglicht den Zugriff auf Microchip 23K256 SRAM"=Chips über SPI.
Richten Sie Ihre spi"=Geräte mit den richtigen plattenspezifischen Plattformdaten oder einer
Gerätebaumbeschreibung ein, wenn Sie eine Gerätepartitionierung angeben möchten.

\paragraph{Microchip 48L640 EERAM}$~$\\
CONFIG\_MTD\_MCHP48L640 [=n] \textbf{[~]}\\*
Dies ermöglicht den Zugriff auf Microchip 48L640 EERAM-Chips über SPI.

\paragraph{Support SST25L (non JEDEC) SPI Flash chips}$~$\\
CONFIG\_MTD\_SST25L [=n] \textbf{[~]}\\*
Dies ermöglicht den Zugriff auf die nicht-JEDEC SST25L SPI-Flash-Chips, die für die Programm- und
Datenspeicherung verwendet werden.
Richten Sie Ihre spi-Geräte mit den richtigen plattformspezifischen Daten ein, wenn Sie eine
Gerätepartitionierung festlegen möchten.

\paragraph{Uncached system RAM}$~$\\
CONFIG\_MTD\_SLRAM [=n] \textbf{[~]}\\*
Wenn Ihre CPU nicht den gesamten physischen Speicher Ihres Rechners zwischenspeichern kann, können
Sie ihn dennoch als Speicher oder Swap verwenden, indem Sie diesen Treiber verwenden, um ihn dem
System als Memory Technology Device vorzustellen.

\paragraph{Physical system RAM}$~$\\
CONFIG\_MTD\_PHRAM [=m] \textbf{[M]}\\*
Dies ist eine Neuimplementierung des obigen \texttt{slram}-Treibers.
Verwenden Sie diesen Treiber, um auf physischen Speicher zuzugreifen, auf den der Kernel selbst
keinen Zugriff hat, also auf Speicher jenseits der \texttt{mem=xxx}-Grenze, nvram, Speicher auf
der Grafikkarte usw...

\paragraph{Test driver using RAM}$~$\\
CONFIG\_MTD\_MTDRAM [=m] \textbf{[M]}\\*
Dies aktiviert einen Test"=MTD"=Gerätetreiber, der vmalloc() zur Bereitstellung von Speicher verwendet.
Sie wollen wahrscheinlich N sagen, es sei denn, Sie testen etwas.

\paragraph{MTDRAM device size in KiB}$~$\\
CONFIG\_MTDRAM\_TOTAL\_SIZE [=4096] \textbf{[4096]}\\*
Damit können Sie die Gesamtgröße des vom MTDRAM"=Treiber emulierten MTD"=Geräts konfigurieren.
Wenn der MTDRAM"=Treiber als Modul gebaut wurde, ist es auch möglich, dies als Parameter beim
Laden des Moduls anzugeben.

\paragraph{MTDRAM erase block size in KiB}$~$\\
CONFIG\_MTDRAM\_ERASE\_SIZE [=128] \textbf{[128]}\\*
Damit können Sie die Größe der Löschblöcke in dem vom MTDRAM"=Treiber emulierten Gerät konfigurieren.
Wenn der MTDRAM"=Treiber als Modul gebaut ist, ist es auch möglich, dies als Parameter beim
Laden des Moduls anzugeben.

\paragraph{MTD using block device}$~$\\
CONFIG\_MTD\_BLOCK2MTD [=m] \textbf{[M]}\\*
Mit diesem Treiber kann ein Blockgerät als MTD erscheinen. Er wird im Allgemeinen in den folgenden
Fällen verwendet:\\
Wenn Sie Compact Flash als MTD verwenden, erscheinen diese dem System normalerweise als ATA"=Laufwerk.
Testen von MTD"=Benutzern (z.~B. JFFS2) auf großen Medien und Medien, die während eines Schreibvorgangs
entfernt werden könnten (Verwendung des Diskettenlaufwerks).

\paragraph*{*** Disk-On-Chip Device Drivers ***}$~$\\
\textit{(*** Disk-On-Chip-Gerätetreiber ***)}

\paragraph{M-Systems Disk-On-Chip G3}$~$\\
CONFIG\_MTD\_DOCG3 [=n] \textbf{[~]}\\*
Dies ist ein MTD"=Gerätetreiber für die M"=Systems DiskOnChip G3"=Geräte.
Der Treiber bietet Zugriff auf G3 DiskOnChip, vertrieben von M"=Systems und jetzt Sandisk.
Die Unterstützung ist sehr experimentell und bietet keinen Zugriff auf Schreiboperationen.

\subsubsection{NAND \texorpdfstring{$\rightarrow$}{->}}
\textit{(Not AND)}

\paragraph{OneNAND Device Support ---}$~$\\
CONFIG\_MTD\_ONENAND [=n] \textbf{[~]}\\*
Dies ermöglicht die Unterstützung des Zugriffs auf alle Arten von OneNAND"=Flash"=Geräten.

\paragraph{Raw/Parallel NAND Device Support \texorpdfstring{$\rightarrow$}{->}}$~$\\
CONFIG\_MTD\_RAW\_NAND [=m] \textbf{[M]}\\*
Dies ermöglicht die Unterstützung des Zugriffs auf alle Arten von rohen/parallelen NAND"=Flash"=Geräten.
Für weitere Informationen siehe \url{http://www.linux-mtd.infradead.org/doc/nand.html}.

\subparagraph*{*** Raw/parallel NAND flash controllers ***}$~$\\
\textit{(*** Rohe/parallele NAND"=Flash"=Kontroller ***)}

\subparagraph{Denali NAND controller on Intel Moorestown}$~$\\
CONFIG\_MTD\_NAND\_DENALI\_PCI [=n] \textbf{[~]}\\*
Aktivieren Sie den Treiber für NAND"=Flash auf Intel Moorestown, unter Verwendung des
Denali NAND"=Controller"=Kerns.

\subparagraph{OLPC CAF \boldmath${\sim}$I NAND controller}$~$\\
CONFIG\_MTD\_NAND\_CAFE [=n] \textbf{[~]}\\*
Verwenden Sie NAND-Flash, das mit dem CAF $\sim$I-Chip verbunden ist, der für den OLPC"=Laptop entwickelt wurde.

\subparagraph{Macronix raw NAND controller}$~$\\
CONFIG\_MTD\_NAND\_MXIC [=n] \textbf{[~]}\\*
Damit wird der Macronix Raw-NAND"=Controller"=Treiber ausgewählt.

\subparagraph{GPIO assisted NAND controller}$~$\\
CONFIG\_MTD\_NAND\_GPIO [=n] \textbf{[~]}\\*
Dies ermöglicht einen NAND"=Flash"=Treiber, bei dem Steuersignale mit GPIO"=Pins verbunden
sind und Befehle und Daten über eine Memory"=Mapped"=Schnittstelle übertragen werden.

\subparagraph{Generic NAND controller}$~$\\
CONFIG\_MTD\_NAND\_PLATFORM [=n] \textbf{[~]}\\*
Dies implementiert einen generischen NAND"=Treiber für On-SOC"=Plattformgeräte. Sie müssen
plattformspezifische Funktionen über platform\_data bereitstellen.

\subparagraph{Support for Arasan NAND flash controller}$~$\\
CONFIG\_MTD\_NAND\_ARASAN [=n] \textbf{[~]}\\*
Aktiviert den Treiber für den Arasan NAND"=Flash"=Controller auf Zynq Ultrascale+ MPSoC.

\subparagraph*{*** Misc ***}$~$\\
\textit{(*** Sonstiges ***)}

\subparagraph{Support for NAND Flash Simulator}$~$\\
CONFIG\_MTD\_NAND\_NANDSIM [=m] \textbf{[M]}\\*
Der Simulator kann verschiedene NAND"=Flash"=Chips für die MTD"=Nand"=Schicht simulieren.

\subparagraph{Ricoh xD card reader}$~$\\
CONFIG\_MTD\_NAND\_RICOH [=n] \textbf{[~]}\\*
Unterstützung für den xD"=Kartenleser Ricoh R5C852 aktivieren.
Sie müssen auch entweder die \glqq NAND SSFDC (SmartMedia) Nur"=Lese"=Übersetzungsschicht\grqq{}
oder die neue experimentelle, schreibbare \glqq SmartMedia/xD new translation layer\grqq{} aktivieren.

\subparagraph{DiskOnChip 2000, Millennium and Millennium Plus (NAND reimplementation)}$~$\\
CONFIG\_MTD\_NAND\_DISKONCHIP [=n] \textbf{[~]}\\*
Dies ist eine Neuimplementierung von M-Systems DiskOnChip 2000, Millennium und Millennium Plus
als Standard"=NAND"=Gerätetreiber, im Gegensatz zu den früheren eigenständigen MTD"=Gerätetreibern.
Dies sollte unter anderem den korrekten JFFS2"=Betrieb auf diesen Geräten ermöglichen.

\paragraph{SPI NAND device Support ---}$~$\\
CONFIG\_MTD\_SPI\_NAND [=n] \textbf{[~]}\\*
Dies ist der Grundrahmen für die SPI-NAND-Gerätetreiber.

\paragraph{ECC engine support \texorpdfstring{$\rightarrow$}{->}}$~$\\
\textit{(ECC-Motorunterstützung)}

\subparagraph{Software Hamming ECC engine}$~$\\
CONFIG\_MTD\_NAND\_ECC\_SW\_HAMMING [=y] \textbf{[Y]}\\*
Dies ermöglicht die Unterstützung der Software"=Hamming"=Fehlerkorrektur. Diese Korrektur
kann bis zu 1~Bitfehler pro Chunk korrigieren und bis zu 2~Bitfehler erkennen.
Während sie bei alten Bauteilen weit verbreitet war, erfordern neuere NAND"=Chips in der
Regel eine stärkere Korrektur und in diesem Fall wird BCH oder RS bevorzugt.

\subsubparagraph{NAND ECC Smart Media byte order}$~$\\
CONFIG\_MTD\_NAND\_ECC\_SW\_HAMMING\_SMC [=y] \textbf{[Y]}\\*
Software-ECC gemäß der Smart"=Media"=Spezifikation. Bei der ursprünglichen
Linux"=Implementierung waren Byte 0 und 1 vertauscht.

\subparagraph{Software BCH ECC engine}$~$\\
CONFIG\_MTD\_NAND\_ECC\_SW\_BCH [=y] \textbf{[Y]}\\*
Dies ermöglicht die Unterstützung der Software"=BCH"=Fehlerkorrektur. Binäre BCH"=Codes
sind leistungs"-fähiger und rechenintensiver als traditionelle Hamming"=ECC"=Codes.
Sie werden bei NAND"=Geräten verwendet, die mehr als 1~Bit Fehlerkorrektur benötigen.

\subparagraph{Macronix external hardware ECC engine}$~$\\
CONFIG\_MTD\_NAND\_ECC\_MXIC [=y] \textbf{[Y]}\\*
Dies ermöglicht die Unterstützung für die Hardware"=ECC"=Engine von Macronix.

\subsubsection{LPDDR \& LPDDR2 PCM memory drivers \texorpdfstring{$\rightarrow$}{->}}
\textit{(LPDDR \& LPDDR2 PCM-Speichertreiber)}

\paragraph{Support for LPDDR flash chips}$~$\\
CONFIG\_MTD\_LPDDR [=n] \textbf{[~]}\\*
Diese Option ermöglicht die Unterstützung von LPDDR"=Flash"=Chips (Low Power Double Data Rate).
Synonym für Mobile"=DDR. Es handelt sich um einen neuen Standard für DDR"=Speicher, der für
batterie"-betriebene Systeme gedacht ist.

\subsubsection{SPI NOR device support \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_MTD\_SPI\_NOR [=m] \textbf{[M]}\\*
Dies ist der Rahmen für den SPI NOR, der von den SPI"=Gerätetreibern und dem SPI NOR"=Gerätetreiber
verwendet werden kann.

\paragraph{Use small 4096 B erase sectors}$~$\\
CONFIG\_MTD\_SPI\_NOR\_USE\_4K\_SECTORS [=y] \textbf{[Y]}\\*
Viele Flash"=Speicher unterstützen das Löschen von kleinen Sektoren ($\qty{4096}{\byte}$). Je nach
Verwendung kann diese Funktion im Vergleich zum Löschen ganzer Blöcke ($\num{32}$/$\qty{64}{\kibi\byte}$)
einen Leistungsgewinn bringen. Das Ändern eines kleinen Teils des Flash"=Inhalts ist mit kleinen
Sektoren normalerweise schneller. Andererseits sollte das Löschen schneller sein, wenn
$\qty{64}{\kibi\byte}$-Blöcke anstelle von 16~$\sim$W $\qty{4}{\kibi\byte}$-Sektoren verwendet werden.

Bitte beachten Sie, dass einige Tools/Treiber/Dateisysteme möglicherweise nicht mit einer
Löschgröße von $\qty{4096}{\byte}$ arbeiten (z.~B. UBIFS benötigt mindestens $\qty{15}{\kibi\byte}$).

\paragraph{Software write protection at boot (Disable SWP on flashes
 w/ volatile protection bits) \texorpdfstring{$\rightarrow$}{->}}$~$\\
\textit{Für diese Option gibt es keine Hilfe.}

\subparagraph{Disable SWP on any flashes (legacy behavior)}$~$\\
CONFIG\_MTD\_SPI\_NOR\_SWP\_DISABLE [=n] \textbf{[~]}\\*
Mit dieser Option wird der Software"=Schreibschutz für alle SPI"=Flashes beim Booten deaktiviert.
Je nach Flash"=Chip werden dadurch entweder die Blockschutzbits gelöscht oder ein
\glqq Global Unprotect\grqq{}"=Befehl ausgeführt.
Verwenden Sie diesen Befehl nicht, wenn Sie beabsichtigen, den Software"=Schreibschutz Ihres
SPI"=Flashs zu verwenden. Dies dient nur dazu, die Abwärtskompatibilität zu erhalten.

\subparagraph{Disable SWP on flashes w/ volatile protection bits}$~$\\
CONFIG\_MTD\_SPI\_NOR\_SWP\_DISABLE\_ON\_VOLATILE [=y] \textbf{[Y]}\\*
Einige SPI"=Flash"=Geräte verfügen über flüchtige Blockschutzbits, d.~h. nach dem Einschalten oder
einem Reset ist das Flash"=Gerät standardmäßig softwaremäßig schreibgeschützt.
Mit dieser Option wird der Software"=Schreibschutz für diese Art von Flashs deaktiviert, während er
für alle anderen SPI"=Flashs, die nichtflüchtige Schreibschutzbits haben, aktiviert bleibt.
Wenn der Software"=Schreibschutz je nach Flash deaktiviert wird, werden entweder die Blockschutzbits
gelöscht oder ein \glqq Global Unprotect\grqq{}"=Befehl ausgegeben.
Wenn Sie unsicher sind, wählen Sie diese Option.

\subparagraph{Keep software write protection as is}$~$\\
CONFIG\_MTD\_SPI\_NOR\_SWP\_KEEP [=n] \textbf{[~]}\\*
Wenn Sie diese Option wählen, wird der Software"=Schreibschutz eines SPI"=Flashs nicht geändert.
Wenn Ihr Flash über einen Software"=Schreibschutz verfügt oder nach dem Einschalten automatisch
über einen Software"=Schreibschutz verfügt, müssen Sie ihn manuell entsperren,
bevor Sie darauf schreiben können.

\subsubsection{Enable UBI -- Unsorted block images \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_MTD\_UBI [=m] \textbf{[M]}\\*
UBI ist eine Softwareschicht über der MTD"=Schicht, die die Verwendung von LVM"=ähnlichen logischen Volumes
auf MTD"=Geräten zulässt, einige Komplexitäten von Flash"=Chips wie Abnutzung und fehlerhafte Blöcke
verbirgt und einige andere nützliche Funktionen bietet. Weitere Einzelheiten finden Sie auf der MTD"=Website
(\url{www.linux-mtd.infradead.org}).

\paragraph{UBI wear-leveling threshold}$~$\\
CONFIG\_MTD\_UBI\_WL\_THRESHOLD [=4096] \textbf{[4096]}\\*
Dieser Parameter legt die maximale Differenz zwischen dem höchsten Löschzählerwert und dem niedrigsten
Löschzählerwert der Löschsperren von UBI"=Geräten fest. Wenn dieser Schwellenwert überschritten wird,
beginnt das UBI mit dem Verschleißausgleich, indem es Daten von Löschblöcken mit niedrigem Löschzähler
zu Löschblöcken mit hohem Löschzähler verschiebt.
Der Standardwert sollte für SLC"=NAND"=Blitzgeräte, NOR"=Blitzgeräte und andere Blitzgeräte mit einem
Löschblock"=Lebenszyklus von \num{100000} oder mehr in Ordnung sein.
Bei MLC-NAND"=Blitzgeräten, die in der Regel eine Lebensdauer von weniger als \num{10000} haben,
sollte der Schwellenwert jedoch herabgesetzt werden (z.~B. auf 128 oder 256, obwohl er keine Potenz
von 2 sein muss).

\paragraph{Maximum expected bad eraseblock count per 1024 eraseblocks}$~$\\
CONFIG\_MTD\_UBI\_BEB\_LIMIT [=20] \textbf{[20]}\\*
Diese Option gibt an, wie viele fehlerhafte physische Eraseblocks UBI auf dem MTD"=Gerät erwartet
(pro 1024~Eraseblocks). Wenn der zugrundeliegende Flash keine schlechten Eraseblocks zulässt (z.~B. NOR-Flash),
wird dieser Wert ignoriert.

In den NAND"=Datenblättern wird oft die minimale und maximale NVM (Number of Valid Blocks) für die Lebensdauer
des Flashs angegeben. Die maximal zu erwartenden fehlerhaften Löschblöcke pro 1024~Löschblöcke können dann
berechnet werden als \glqq $1024 \cdot (1 - \mathit{MinNVB} / \mathit{MaxNVB})$\grqq{}, was für die meisten NANDs 20 ergibt
(MaxNVB ist im Grunde die Gesamtzahl der Löschblöcke auf dem Chip).
Anders ausgedrückt, wenn dieser Wert 20 ist, wird UBI versuchen, etwa $\qty{1,9}{\percent}$ der
physischen Eraseblocks für die Behandlung schlechter Blöcke zu reservieren. Und das sind
$\qty{1,9}{\percent}$ der Eraseblocks auf dem gesamten NAND"=Chip, nicht nur auf der MTD"=Partition,
die UBI zuordnet. Das bedeutet, dass, wenn Sie z.~B. einen NAND"=Flash"=Chip haben, der maximal
40~Bad Eraseblocks zulässt und auf zwei MTD"=Partitionen derselben Größe aufgeteilt ist,
UBI 40 Eraseblocks reserviert, wenn es eine Partition anhängt.
Diese Option kann durch den UBI-Modulparameter \texttt{mtd=} oder durch den ioctl \texttt{attach}
außer Kraft gesetzt werden.
Lassen Sie den Standardwert, wenn Sie unsicher sind.

\paragraph{UBI Fastmap (Experimental feature)}$~$\\
CONFIG\_MTD\_UBI\_FASTMAP [=n] \textbf{[~]}\\*
Wichtig: Diese Funktion ist bisher experimentell und das On"=Flash"=Format für Fastmap kann sich
in den nächsten Kernel"=Versionen ändern Fastmap ist ein Mechanismus, der das Anhängen eines
UBI"=Geräts in nahezu konstanter Zeit ermöglicht. Anstatt das gesamte MTD"=Gerät zu scannen,
muss nur ein Kontrollpunkt (Fastmap genannt) auf dem Gerät lokalisiert werden.
Die On"=Flash"=Fastmap enthält alle Informationen, die zum Anhängen des Geräts benötigt werden.
Die Verwendung der Fastmap ist nur bei großen Geräten sinnvoll, bei denen das Anschließen durch
Scannen lange dauert. UBI installiert nicht automatisch eine Fastmap auf alten Images, aber Sie
können den UBI"=Modulparameter fm\_autoconvert auf 1 setzen, wenn Sie dies wünschen.
Bitte beachten Sie, dass fastmap"=fähige Images auch mit UBI"=Implementierungen ohne
fastmap"=Unterstützung verwendbar sind. Auf typischen Flash"=Geräten passt die gesamte Fastmap
in ein PEB. UBI reserviert PEBs, um zwei Fastmaps zu speichern.
Im Zweifelsfall sagen Sie N.

\paragraph{MTD devices emulation driver (gluebi)}$~$\\
CONFIG\_MTD\_UBI\_GLUEBI [=n] \textbf{[~]}\\*
Diese Option aktiviert gluebi -- einen zusätzlichen Treiber, der MTD"=Geräte auf
UBI"=Volumes emuliert: für jedes UBI"=Volume wird ein MTD"=Gerät erstellt, und alle
E/A an dieses MTD"=Gerät werden auf das UBI"=Volume umgeleitet. Dies ist praktisch,
um MTD"=orientierte Software (wie JFFS2) auf UBI"=Volumes laufen zu lassen.
Aktivieren Sie dies nicht, es sei denn, Sie verwenden Legacy"=Software.

\paragraph{Read-only block devices on top of UBI volumes}$~$\\
CONFIG\_MTD\_UBI\_BLOCK [=n] \textbf{[~]}\\*
Mit dieser Option wird die Unterstützung von UBI"=Block"=Geräten mit Lesefunktion aktiviert.
UBI"=Blockgeräte werden über UBI"=Volumes gelegt, was bedeutet, dass der UBI"=Treiber Dinge
wie schlechte Eraseblocks und Bitflips transparent behandelt. Sie können jedes
blockorientierte Dateisystem auf UBI"=Volumes im Nur"=Lese"=Modus legen (z.~B. ext4), aber
es ist wahrscheinlich am praktischsten für Nur"=Lese"=Dateisysteme, wie squashfs.
Wenn diese Option ausgewählt ist, wird diese Funktion in den UBI"=Treiber integriert.
Im Zweifelsfall sagen Sie N.

\subsubsection{HyperBus support ---}
CONFIG\_MTD\_HYPERBUS [=n] \textbf{[~]}\\*
Dies ist der Rahmen für den HyperBus, der vom HyperBus"=Controller"=Treiber zur Kommunikation
mit HyperFlash verwendet werden kann. Siehe Cypress HyperBus Spezifikation für weitere Details.

\subsection{Device Tree and Open Firmware support ---}
CONFIG\_OF [=n] \textbf{[~]}\\*
Diese Option aktiviert die Gerätebaum"=Infrastruktur. Sie wird automatisch von Plattformen
ausgewählt, die sie benötigen, oder kann manuell für Unittests, Overlays oder
Compile"=Coverage aktiviert werden.

\subsection{Parallel port support \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_PARPORT [=m] \textbf{[M]}\\*
Wenn Sie Geräte verwenden wollen, die an den Parallelport Ihres Rechners angeschlossen
sind (der Anschluss am Computer mit 25~Löchern), z.~B. Drucker, ZIP"=Laufwerk,
PLIP"=Link (Parallel Line Internet Protocol wird hauptsächlich verwendet, um ein
Mini"=Netzwerk zu erstellen, indem die Parallelports zweier lokaler Rechner verbunden
werden) usw., dann müssen Sie hier Y sagen; lesen Sie bitte
$<$file:Documentation/admin-guide/parport.rst$>$ und $<$file:drivers/parport/BUGS-parport$>$.
Aus"-führ"-liche Informationen über Treiber für viele Geräte, die an den Parallelport
angeschlossen werden, finden Sie unter \url{http://www.torque.net/linux-pp.html} im WWW.
Es ist möglich, eine einzige parallele Schnittstelle mit mehreren Geräten zu teilen,
und es ist sicher, alle entsprechenden Treiber in den Kernel zu kompilieren. Um die
Parallelport"=Unterstützung als Modul zu kompilieren, wählen Sie hier M:
Das Modul wird \texttt{parport} genannt.
Wenn Sie mehr als eine parallele Schnittstelle haben und beim Laden des Moduls angeben
wollen, welche Schnittstelle und welcher IRQ von diesem Treiber verwendet werden soll,
werfen Sie einen Blick auf $<$file:Documentation/admin-guide/parport.rst$>$.
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{PC-style hardware}
CONFIG\_PARPORT\_PC [=m] \textbf{[M]}\\*
Wenn Sie einen PC-ähnlichen Parallelanschluss haben, sollten Sie hier Y eingeben.
Alle IBM-PC"=kompatiblen Computer und einige Alphas verfügen über parallele
Schnittstellen im PC"=Stil. PA-RISC"=Besitzer sollten hier nur Y angeben, wenn
sie einen SuperIO"=Parallelport haben.
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
Das Modul heißt dann \texttt{parport\_pc}.
Wenn Sie unsicher sind, sagen Sie Y.

\paragraph{Multi-IO cards (parallel and serial)}$~$\\
CONFIG\_PARPORT\_SERIAL [=m] \textbf{[M]}\\*
Dies fügt Unterstützung für Multi"=IO-PCI"=Karten hinzu, die parallele und
serielle Schnittstellen haben. Sie sollten hier Y oder M sagen. Wenn Sie M
sagen, wird das Modul \texttt{parport\_serial} genannt.

\paragraph{Use FIFO/DMA if available}$~$\\
CONFIG\_PARPORT\_PC\_FIFO [=y] \textbf{[Y]}\\*
Viele Chipsätze für parallele Anschlüsse bieten Hardware, die das Drucken beschleunigen
kann. Sagen Sie hier Y, wenn Sie dies nutzen wollen.
Der Kernel muss nicht nur einen FIFO oder eine DMA"=Fähigkeit haben, sondern auch wissen,
welchen IRQ die parallele Schnittstelle hat. Standardmäßig werden die Interrupts der
parallelen Schnittstelle nicht verwendet, und somit auch nicht der FIFO.\\
Siehe $<$file:Documentation/admin-guide/parport.rst$>$, um herauszufinden, wie man
festlegt, welchen IRQ/DMA man verwenden will.

\paragraph{SuperIO chipset support}$~$\\
CONFIG\_PARPORT\_PC\_SUPERIO [=y] \textbf{[Y]}\\*
Wenn man hier Y sagt, kann man einige Sonden für Super"=IO"=Chipsätze aktivieren,
um Dinge wie Basis"-adressen, IRQ"=Leitungen und DMA"=Kanäle herauszufinden.
Es ist sicher, N zu sagen.
\paragraph{Support for PCMCIA management for PC-style ports}$~$\\
CONFIG\_PARPORT\_PC\_PCMCIA [=m] \textbf{[M]}\\*
Geben Sie hier Y an, wenn Sie PCMCIA"=Unterstützung für Ihre parallelen
PC"=Anschlüsse benötigen. Wenn Sie unsicher sind, sagen Sie N.

\subsubsection{IEEE~1284 transfer modes}
CONFIG\_PARPORT\_1284 [=y] \textbf{[Y]}\\*
Wenn Sie einen Drucker haben, der die Statusrückmeldung oder die Geräte"=ID
unterstützt, oder ein Gerät verwenden möchten, das erweiterte parallele
Anschlussübertragungsmodi wie EPP und ECP verwendet, geben Sie hier Y ein,
um erweiterte IEEE~1284-Übertragungsmodi zu aktivieren. Sagen Sie auch Y,
wenn Sie möchten, dass die Geräte"=ID"=Informationen in
\texttt{/proc/sys/dev/parport/*/autoprobe*} erscheinen.
Es ist sicher, N zu sagen.

\subsection{Plug and Play support \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_PNP [=y] \textbf{[Y]}\\*
Plug and Play (PnP) ist ein Standard für Peripheriegeräte, der es ermöglicht,
diese Peripheriegeräte per Software zu konfigurieren, z.~B. IRQs oder andere
Parameter zuzuweisen. Es werden keine Jumper auf den Karten benötigt, stattdessen
werden die Werte den Karten über das BIOS, das Betriebssystem oder ein
Benutzerprogramm zugewiesen.
Geben Sie hier Y an, wenn Sie möchten, dass Linux Ihre Plug"=and"=Play"=Geräte
konfiguriert. Sie sollten dann auch bei allen folgenden Protokollen mit
Y antworten. Alternativ können Sie hier auch N angeben und Ihre PnP"=Geräte mit
Hilfe von Userspace"=Dienstprogrammen wie dem Paket isapnptools konfigurieren.
Wenn Sie unsicher sind, sagen Sie Y.

\subsubsection{PNP debugging messages}
CONFIG\_PNP\_DEBUG\_MESSAGES [=y] \textbf{[Y]}\\*
Geben Sie hier Y an, wenn Sie möchten, dass die PNP"=Schicht bei Bedarf
Debugging"=Meldungen erzeugen kann. Die Meldungen können beim Booten mit dem
Kernelparameter pnp.debug aktiviert werden.

Mit dieser Option können Sie etwas Platz sparen, wenn Sie nicht möchten, dass
die Meldungen sogar in den Kernel eingebaut werden.
Wenn Sie Zweifel daran haben, sagen Sie hier Y.

\subsubsection*{*** Protocols ***}
\textit{(*** Protokolle ***)}

\subsection{Block devices \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_BLK\_DEV [=y] \textbf{[Y]}\\*
Sagen Sie hier Y, um die Optionen für verschiedene Blockgerätetreiber zu sehen.
Diese Option allein fügt keinen Kernelcode hinzu.
Wenn Sie N sagen, werden alle Optionen in diesem Untermenü übersprungen und
deaktiviert; tun Sie dies nur, wenn Sie wissen, was Sie tun.


%%
%% \texorpdfstring{$\rightarrow$}{->}
%% \textit{Für diese Option gibt es keine Hilfe.}