UPD Generic Driver Options

documentation/linux_configuration.tex

@@ -1,6 +1,13 @@
 %
 % Thomas Kuschel 2023
 \newcommand{\version}{V6.7}
+% preconditions:
+% install on ARCH linux:
+%  pacman -S texlive-plaingeneric
+%  pacman -S texlive-binextra
+%  pacman -S texlive-langgerman
+%  pacman -S hyphen hyphen-de
+
 \documentclass[10pt,a4paper]{article}
 %\documentclass[12pt,a4paper]{report}
 \usepackage[a4paper,margin=25mm]{geometry}
@@ -10007,6 +10014,269 @@ 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.
+
 \end{document}
 
 \texorpdfstring{$\rightarrow$}{->}