UPD Generic Driver Options

documentation/linux_configuration.tex

@@ -9737,7 +9737,7 @@ 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$}{->}}
+\subsubsection{PCI controller drivers \texorpdfstring{$\rightarrow$}{->}}
 \textit{(PCI-Controller-Treiber)}
 
 \paragraph{Intel Volume Management Device Driver}$~$\\
@@ -9751,6 +9751,262 @@ 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 ***}
+
+\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.
+
 \end{document}
 
 \texorpdfstring{$\rightarrow$}{->}