Der Kernel - Konfiguration

Wer sich nicht gerade intensiv mit Computern beschäftigt, der wird der Möglichkeit, einen Kernel nach Maß zu generieren, wenig Bedeutung zumessen. Zu komplex mutet die Konfiguration an. Und spätestens nach dem dritten Versuch, der mit einer kryptischen Fehlermeldung endete, landet die Flinte dann im Korn.

Tatsächlich ist es selten notwendig, sich in die Tiefen des Betriebssystems herabzulassen. Die Zeiten, da man durch Entrümpelung den Kernel noch ein paar Maschinenzyklen effizienter trimmte, gehören spätestens seit Athlon und Pentium III der Vergangenheit an. Den Unterschied merken bestenfalls die Benchmark-Programme. Und dort differiert auch nur noch die Zahlenkolonne hinter dem Komma.

Alle (von mir getesteten) Distributoren legen ihren Paketen heutzutage einen stark modularisierten Kernel bei. Nahezu jede verfügbare Eigenschaft liegt zumindest als Modul vor und kann bei Bedarf geladen werden.

Das Backen eines eigenen Kerns ist quasi einzig erforderlich, wenn - aus welchen Gründen auch immer - unbedingt die aktuellsten Kernelversionen verwenden werden müssen. Klar, dass die Aktualität der Distributionen nicht mit dem rasanten Erscheinen neuester (Entwickler-) Versionen Schritt halten kann. Wer nicht warten will, muss nun selbst Hand anlegen und aus den Quellen einen einsatzbereiten Kernel formen.

Andererseits macht es wenig Sinn, jede Distributionsversion mitzunehmen. Meist ändern sich an diesen doch nur wenige Teile, die man sich womöglich schon längst aus dem Netz gezogen hat. Um stets auf der Höhe der Zeit zu bleiben, genügt die Aktualisierung des Kernels. Doch der liegt nur als Quellkode vor, womit man um die Generierung nicht umhin kommt...

Wer übrigens den Kernel nicht übers Modem auf die heimische Platte holen möchte, der sollte mal in linuxspezifischen Zeitschriften schmökern. Regelmäßig enthalten diese CDROM mit den neuesten Programmen und Kernelversionen.

Anmerkung: Nachfolgend beziehen wir uns in den Beispielen immer auf das Verzeichnis /usr/src/linux. Wenn Sie die Kernelquellen unter einem anderen Pfad installiert haben, dann funktionieren die folgenen Aufrufe nur in diesem Stammverzeichnis! Die beschriebene Kernelversion ist 2.4.17.

Der harte Eingriff in die Quellen bleibt den eingefleischten Kernel-Entwicklern vorbehalten. Es sind einfach zu viele Abhängigkeiten zwischen den einzelnen Kodeteilen, als dass Otto Normalverbraucher auch nur den Hauch eine Chance hätte, dort durchzusehen. Glücklicherweise existieren verschiedene Konfigurationshilfen, die menügesteuert etwas Struktur ins Chaos bringen.

make config

Überliefert aus alten Zeiten steht gar ein textbasiertes Frage-Antwort-Spiel zur Verfügung:

Die konfigurierbaren Punkte sind dieselben, wie in den nachstehend vorgestellten Hilfen. Die Konfiguration erfolgt in vorgegebener Reihenfolge. Die nachträgliche Änderung einer einmal getroffenen Auswahl ist nur durch einen erneuten Programmdurchlauf möglich. Eine Option kann aktiviert (Eingabe von [y] bzw. [Y]) oder deaktiviert werden ([n] bzw. [N]). Manche Eigenschaften lassen sich als Modul realisieren. In der Auswahl symbolisiert ein [M] diese Möglichkeit. Hinweise zum Sinn einer Option erhalten Sie durch Eingabe von [?].

make menuconfig

Wenn kein X-Server zur Verfügung steht, ist das auf Dialogboxen aufbauende Werkzeug eine komfortable Hilfe zur Bändigung des Kernels:

Die Navigation erfolgt mit den Cursortasten. Die Anwahl einer Option geschieht durch Eingabe von [y], die Abwahl mittels [n]. Steht die Möglichkeit der Realisierung als Modul zur Verfügung, so setzt [M] diese Variante. Das Wechseln zwischen den Möglichkeiten kann ebenso durch wiederholtes Drücken von [Space] geschehen.

make xconfig

Unter X steht die bequemste Möglichkeit der Kernelkonfiguration (Tcl/Tk) zur Verfügung:

Wir beschreiben die wesentlichen Teile der Konfiguration anhand der durch das X-fähige Werkzeug vorgegebenen Reihenfolge.

make oldconfig

Die zuletzt vollzogene Kernelkonfiguration wird jeweils in der Datei .config im Kernel-Stammverzeichnis gespeichert. Nach einem Kernelpatch oder der Installation neuer Kernelquellen (vergessen Sie nicht, .config zu sichern) besteht berechtigtes Interesse, den neuen Kernel mit identischen Einstellungen zu konfigurieren. Wenn die Datei .config existiert, kann mit:

die automatische Konfiguration angeschoben und das ganze Prozedere der manuellen Menüpunkteauswahl umgangen werden. Manche Distributionen (bspw. SuSE) speichern die aktuelle Kernelkonfiguration in einer Datei »/boot/vmlinuz.config«. Um dessen Konfiguration für eine Kernel-Neuerzeugung zu verwenden, bringen sie das make-Ziel »cloneconfig« mit. Abgesehen von den unterschiedlichen Dateien mit den Kernelinformationen arbeiten oldconfig und cloneconfig identisch.

Aufräumen

Während ein »make clean« nur die Objektdateien entfernt und somit eine spätere Neuübersetzung aller Kernelteile erzwingt, sorgt ein »make mrproper« für ein Rücksetzen der Kernelquellen in den Originalzustand. Im Wesentlichen handelt es sich um das zusätzliche Entfernen der Statusdateien.

Schließlich existiert »make distclean«, das neben »make mrproper« auch noch die Rückstände von Patchvorgängen entsorgt.

Beginnend mit dem ersten Eintrag aus dem Hauptmenü, erläutert der folgende Abschnitt die wesentlichen Optionen der Kernelkonfiguration des Kernels 2.4.17. Es handelt sich im Beispiel um den offiziellen Kernel; der sich von Kerneln der Distributionen meist geringfügig unterscheidet.

Sind Optionen in den Dialogen nicht zugänglich, so ist vermutlich die Aktivierung einer übergeordneten Funktion notwendig bzw. die Aktivierung des nachfolgend beschriebenen Eintrags:

Code maturity level options

Es handelt sich um den Zugang zu »unausgereiften« Bestandteilen des Kernels, die zwar (vermutlich) stabil funktionieren, aber noch nicht den fertigen Status erreicht haben. Vorerst können Sie diese Option deaktiviert lassen. Treffen Sie im Laufe der Konfiguration auf Optionen, die nicht selektierbar sind (grau hinterlegt), die Sie aber benötigen, so kehren Sie in den Dialog zurück und aktivieren diese Option.

Loadable module support

Module sind eigenständige Programmteile, die nur bei Bedarf zum Kernel hinzugefügt werden (rmmod, modprobe, insmod...). Die Realisierung von Komponenten als Module verschlankt den Kernel und verhindert teilweise Ressourcenkonflikte bei Hardware, die auf denselben Einstellungen beharren. Sie sollten Enable loadable module support aktivieren, solange nichts dagegen spricht.

Set version information on all modules symbols gestattet das Verwenden von Modulen anderer Kernel. Sollten Sie kommerzielle Software einsetzen, die eigene Module mit sich bringt, muss diese Option aktiviert sein.

Das Laden von Modulen im Bedarfsfall kann der Kernel eigenständig erledigen, falls Kernel module loader eingebunden wird.

Processor type and features

Wählen Sie bei Processor family den Typ ihres Prozessors, so wird der Kernel auf den Befehlssatz dieses Prozessors optimiert. Sie können durchaus auch Kode für ein Vorgängermodell erzeugen. Dieser wird auf allen Nachfolgeprozessoren laufen, nicht jedoch auf früheren CPUs der Familie.

High Memory Support sollten Sie nur aktivieren, wenn in Ihrem System mehr als 1 Gigabyte RAM stecken. Der Kernel verwendet dann spezielle Mechanismen, um die höheren Speicherbereiche (mit 32 Bit lassen sich nur 4 GB adressieren) ansprechen zu können. Die Diskrepanz zwischen zwischen 1 und 4 GB resultiert aus der Verwendung virtuellen Speichers, den der Kernel zum Zweck der Optimierung grundsätzlich anfordert.

Die Math emulation ist eventuell auf alten Prozessoren (386er, 486er SX) erforderlich, die über keinen zusätzlichen Co-Prozessor verfügen. Aller neueren Modelle haben einen integrierten Co-Prozessor.

MTtr support schadet niemals (auf alten Prozessoren existiert kein solches Register); die Unterstützung ermöglicht aber einen effizienteren - weil Hardware-unterstützten - Speicherschutz.

Multiprocessing muss bei Systemen mit mehreren CPUs integriert werden, um diese auch verwendet zu können.

APIC (Advanced Programmable Interrupt Controller) unterstützen zahlreiche CPUs. Es handelt sich um eine Methode zur Verteilung von Hardware-Interrupts. Die Aktivierung der Option schadet niemals.

General Setup

Network support ist eigentlich immer notwendig, da etliche Programme (Drucken) nur im Netzwerk funktionieren. Dabei ist es unerheblich, ob der Rechner tatsächlich über eine Netzwerkkarte verfügt, da das Loopback-Device eine solche simuliert.

Die nachfolgenden Optionen erfordern eine genaue Kenntnis über das Motherboard Ihres Rechners. Eine SGI Visual Workstation werden wohl die wenigsten daheim stehen haben, deshalb scheidet diese Option aus. Aktuelle Mainboards verwenden den PCI-Bus. Einige Modelle haben auch noch den in die Jahre gekommenen (E)ISA-Bus. Seltener anzutreffen ist dagegen die MCA-Architektur (Microchannel). Aktivieren Sie nur Optionen zu der Hardware, über die Ihr System tatsächlich verfügt, da nicht jede Option auf jeder Plattform funktioniert.

Bei einem PCI-Bus muss der PCI access mode angegeben werden. Dabei handelt es sich um den Mechanismus, nachdem der Kernel die Konfiguration von PCI-Geräten ermittelt. Er kann es dem BIOS überlassen oder es selbst versuchen oder das BIOS konsultieren, wenn seine eigenen Nachforschungen nichts ergeben haben. PCI device name database ermöglicht eine Schnittstelle im Prozess-Dateisystem (/proc/pci, /proc/ioports) und wird empfohlen.

Sind Geräte in Ihrem System, die auch während des Betriebs gewechselt werden können (PCMCIA-Karten, PC-Cards, USB-Geräte), so befähigt die Option Support for hot pluggable devices den Kernel, diese Geräte automatisch zu konfigurieren. Die Unterstützung für PCMCIA/CardBus ist nur notwendig, wenn solche Karten im System stecken.

System V IPC ist erforderlich, falls Sie die den Distributionen beiliegenden Programme nutzen wollen. Nahezu alle großen Anwendungen beinhalten Mechanismen zur Interprozesskommunikation.

Protokollierung über die von Prozessen verwendeten Ressourcen wird mit der Option BSD process accounting veranlasst. Ein Programm kann die vom Kernel gelieferten Daten auswerten (z.B. ps, top).

Der Kernel sollte in heutigen Zeiten immer im Format ELF (Executable linkage format) vorliegen. (»a.out« ist das frühere Format). Bei den nachfolgenden Fragen nach der Unterstützung verschiedenen Binaryformate (ausführbare Programme) muss zumindest Support ELF binaries fest eingebunden werden. Die weiteren Formate können bei Bedarf als Modul realisiert werden, MISC binaries ist bei Zugriff auf den Dos-Emulator, bei Perl oder Java erforderlich.

Die weiteren Optionen betreffen das Power-Management und sind nur für BIOS mit diesen Fähigkeiten von Interesse. An dieser Stelle ist viel Experimentierfreude gefragt, um die Optionen zu finden, mit denen das eigene BIOS zusammen arbeitet (die im Beispiel aktivierten Optionen sollten das automatische Abschalten eines ATX-Rechners nach einem Shutdown ermöglichen).

Binary Emulation Of Other Systems

Die in den 2.2.er Kerneln enthaltende Emulation von Binaries auf Basis von iBCS2 (Intel Binary Compatibility Specification 2) ist in neueren Kernel durch ABI (Application Binary Interface) abgelöst worden. Im Wesentlichen handelt es sich um eine Erweiterung des iBCS-Standards auf andere Hardwareplattformen.

Die unter Support for binary emulation of other systems bez. Support foreign binary formats befindlichen Optionen ermöglichen das direkte Ausfführen von Programmen des jeweiligen Formats unter Linux. Die Unterteilung resultiert vermutlich aus der vorhandenen Quelltextkompatibilität von Linuxprogrammen zu erster Gruppe, während x.out (XENIX) und COFF stets abweichender Quelltext zu Grunde liegt.

Die Option Linux-ABI debugging settings ist nur für Entwickler interessant.

Memory Technologie Devices (Mtd)

Memory Technologie Devices sind einzig für embedded Systeme relevant und werden hier nicht beschrieben.

Parallel Port Support

Über einer parallele Schnittstelle verfügt nahezu jeder Rechner. Typische Geräte, die an diese angeschlossen werden, sind Drucker, ZIP-Laufwerke, manche Scanner usw. Sie benötiden die Option Parallel port support auf jeden Fall, um derartige Hardware ansprechen zu können.

IBM-PCs (also nahezu jeder Heimrechner) sind PC-style hardware und benötigen die Option, um den Parallelport korrekt ansprechen zu können. Darüber hinaus sollten Sie Use FIFO/DMA if available aktivieren, falls Sie die Schnittstellen auch Interrupt gesteuert ansprechen wollen. Die Verwendung von FIFO und DMA lässt sich - sofern sie die Hardware beherrscht - beim Laden der Module (de)aktivieren.

Vor allem für Notebooks existieren PCMCIA-Einsteckkarten, die die Erweiterung um parallele Schnittstellen ermöglichen. Support for PCMCIA management for PC-style ports benötigen Sie einzig, wenn Sie über eine solche Karte verfügen. Die Unterstützung Nicht-Standard-konformer Hardware ist für den normalen Anwender niemals erforderlich.

Für den seltenen Fall, dass ein paralleler Port im ECC- oder ECP-Transfermodus (Error Correction Code bzw. Enhanced Capability Port) betrieben wird, ist IEEE1284 transfer modes einzuschalten (das Handbuch Ihres Motherboards sollte den Status der parallelen Schnittstelle(n) kennen).

Plug & Play

Plug and Play support ermöglicht die Konfiguration von Plug&Play-Karten (Zuweisung von Interrupts und IO-Adressen) durch den Kernel. Im Falle von ISA-PnP-Karten muss zusätzlich ISA Plug and Play support eingeschalten werden. PnP-Karten lassen sich allerdings auch "von Hand" konfigurieren, sodass diese Optionen nicht zwingend erforderlich sind, um solche Karten verwenden zu können.

Block Devices

Normal PC floppy disk support betrifft den Zugriff auf Diskettenlaufwerke. Verfügt der Rechner über ein solches, sollte die Option gesetzt werden - vorzugsweise als Modul, um den Kernel nicht unnötig aufzublähen.

Bei PS/2 ESDI hard disk support handelt es sich um einen Festplattentreiber, der nur auf einer IBM PS/2 Architektur notwendig ist. Aber wer hat eine solche daheim stehen?

Schon eher lagern alte Platten aus den 8086er Zeiten in manchen Schubladen. Wer das Basteln nicht scheut und solche wenige MegaByte umfassenden Speichermedien irgendwie an seinen PC anklemmt, der benötigt XT hard disk support, um solche 8 Bit Festplattencontroller ansprechen zu können.

Ob CDROM-, Bandlaufwerke oder Festplatten... sie alle sind auch in Ausführungen erhältlich, die sie zum Anschluss und Betrieb an der parallelen Schnittstelle befähigen. Neben Parallel port IDE device support sollten sie die Option des entsprechenden Gerätetyps aktivieren. Einige dieser Geräte arbeiten nach herstellerspezifischen Protokollen, die bei Bedarf hinzuzufügen sind.

Der Compaq Smart... support ist bei gleichnamigen Controllern notwendig. Hierbei handelt es sich um RAID-Controller, die häufig in Compaqs ProLiant-Servern eingesetzt werden. Ein weiterer unterstützter RAID-Controller stammt von Mylex, dessen Treiber durch die Option Mylex DAC960/DAC1100 PCI RAID Controller support eingebunden wird.

Loopback device support gestattet das Einbinden einer einzelnen Datei als Device. Notwendig ist die Option, wenn Sie einen Kernel erstellen möchten, der mit einer initialen Ramdisk (siehe nachfolgend) arbeitet. Hilfreich ist die Unterstützung auch beim Brennen von CDs, um die von der Brennsoftware erzeugten Images vor dem Brennen zu testen. Twofish encryption for loop device ermöglicht die Verschlüsselung ganzer Dateisysteme über das Loopback Device.

Beim Network block device handelt es sich um einen Treiber zum Mounten von Dateisystemen von einem Server, wobei der lokale Mountpunkt als normales Blockgerät (bspw. /dev/nd0) erscheint. Aus Sicht des Clients handelt es sich dann um ein lokales Dateisystem.

RAM disk support erlaubt das Mounten eines Teiles des Hauptspeichers als ein Blockgerät. In diesem lassen sich Dateisysteme erzeugen, die sich analog zu Dateisystemen auf den Partitionen einer Festplatte verhalten. Genutzt wird diese Möglichkeit, um im RAM ein minimales Root-Dateisystem zu laden, dass ein Kernel bspw. während der Installation lädt. Somit lassen sich bspw. die Hardwareerkennung realisieren, ohne dass Linux zuvor installiert sein muss. Nähere Information finden Sie im Abschnitt Booten (Systemadministration). Default RAM disk size sollte auf x86er Architekturen auf 4096 Bytes bleiben. Initial RAM disk (initrd) support ermöglicht dem Kernel, vor dem eigentlichen Bootvorgang ein Dateisystem aus einer RAM-Disk zu mounten. Eine solche RAM-Disk legt ein Bootloader dazu an geeigneter Stelle im Hauptspeicher ab.

Multiple Device Support (Raid and LVM)

RAID (Redundant Array of Inexpensive Disks) ist eine Technologie zur Beschleunigung und/oder Steigerung der Ausfallsicherheit bei Festplattenzugriffen. Hierzu werden mehrere gleich große Partitionen verschiedener Festplatten zu logischen Einheiten formiert. Die Art der Verwaltung der Dateien auf solchen logischen Einheiten wird als Raid-Level bezeichnet. Die hier zu konfigurierenden Lösungen sind rein in Software implementiert; sie haben nichts mit den weiter oben erwähnten RAID-Controllern zu tun!

Zunächst werden durch Multi device driver support (RAID and LVM) die notwendigen Gerätedateien (/dev/md*) erzeugt, über die später die Konfiguration eines RAID- bzw. LVM-Systems erfolgen kann.

Einen gänzlich anderen Ansatz verfolgt Raid-1 (mirroring) mode. Hier werden die Daten gespiegelt, d.h. auf jeder beteiligten Partition wird ein genaues Abbild der Daten gespeichert.

Raid-2 basiert auf Fehlererkennung der auf mehrere Platten verteilten Daten mittels Hammings-Codes. Da moderne Platten über eingebaute Fehlererkennung verfügen, wird dieses Level nicht extra von Linux unterstützt. Ebenso wenig implementiert Linux Raid-3, das die Daten auf Byteebene über die Platten verteilt (inklusive Parity-Prüfung). Aus Effizienzgründen ist Letzteres nur als Hardwarerealisierung sinnvoll.

Raid-4/Raid-5 mode arbeiten analog zu Raid-3, wobei die Daten blockweise verteilt werden. Raid-4 legt die Prüfsumme auf einer eigenen Platte ab, während Raid-5 diese über die Platten verteilt..

Logical volume manager (LVM) support ist eine Methode, mehrere Partitionen (auf mehreren Platten) zu einer logischen Einheit zusammenzufassen.

Networking Options

Packet socket benötigen einige wenige Programme (tcpdump), die direkt mit dem Netzwerktreiber kommunizieren, also ohne Verwendung eines Netzwerkprotokolls. Packet socket mmapped IO schaltet den Packet-Protocol-Treiber in einen (eventuell) schnelleren Ein-/Ausgabemechanismus.

Kernel/User netlink socket werden von einer Reihe netzwerkrelevanter Programme benötigt. Derartige Programme kommunizieren mit dem Kernel (genauer mit Kernelmodulen) über einen speziellen Netlink-Socket. Der Kernel hat so eine Möglichkeit, diese Programme von Änderungen im Netzwerk zu unterrichten. Programme wiederum können den Kernel über die Sockets zu konkreten Aktionen veranlassen. Routing messages gestattet Programmen, über Netlink-Sockets Routing-Informationen vom Kernel zu empfangen. Das Senden ist den Programmen nicht gestattet. Netlink device emulation ist nur noch wegen der Kompitibilität zu älteren Programmen im Kernel enthalten. Solche Programme beruhen (noch) nicht auf Mechanismen des Netlink-Sockets und benötigen /dev/tapX, /dev/route,... um die Kernelinformationen zu beziehen.

Network packet filtering ist eine kernelinterne Implementierung eines Firewalls. Es kann sowohl Masquerading und Ipchains ersetzen als auch diese beiden älteren Mechanismen ergänzen. Ein weitere Einsatzbereich ist ein Proxi-Server zur Anbindung von lokalen Clients ohne eigene gültige IP-Adresse. Network packet filtering debugging weist den Kernel zu erweiterten Statusausgaben bez. des Paketfilters an.

Mit Socket filtering können Programme den Kernel anweisen, Pakete mit bestimmten Merkmalen an Sockets - mit Ausnahme von TCP-Sockets - anzunehmen bzw. abzulehnen.

Unix domain sockets ist das Standardverfahren, um Netzwerkverbindungen unter Unix einzurichten. Eine Reihe wichtiger Programme ist auf diese Option angewiesen (u.a. der X-Server, der Syslogd), sodass sie stets gesetzt werden sollte.

Als offenes Protokoll hat sich TCP/IP zur Datenübertragung im Internet und in zahlreichen lokalen Netzwerken etabliert, sodass nahezu jeder Dienst, der unter Unix etwas mit dem Netzwerk zu tun hat, auch der Unterstützung dessen bedarf. TCP/IP networking sollte daher stets aktiviert werden!

Threaded LinUX... (TUX) aktiviert den Kernel-HTTP-Dämon »TUX« (ein weiterer kernelbasierter HTTP-Server steht durch den khttpd zur Verfügung). Durch die Realisierung im Kernel ist dieser Webserver in der Lage, Anforderungen durch direktes Schreiben von Seiten aus dem Cache auf die Netzwerkkarte zu erfüllen, sodass die bei »herkömmlichen (user-space)« Webservern notwendigen Kopieroperationen in den Kerneladressraum und das damit verbunden Umschalten des Kontexts entfallen. TUX arbeitet somit signifikant schneller als ein im Nutzeradressraum angesiedelter Server. TUX bietet mit HTTPAPI eine Programmierschnittstelle, um die Erzeugung dynamischer Webinhalte in dafür spezialisierte Module auslagern zu können. External CGI module erlaubt den Start von CGI-Programmen im Kernel. extended TUX logging format bläht die Statusausgaben weiter auf und debug TUX bewirkt eine Reihe von Meldungen, die TUX über den Syslogd absetzt. Letzteres ist nur für die Entwickler sinnvoll!

IP: multicasting ermöglicht das gleichzeitige Versenden eines Pakets an mehrere Rechner. Hierbei gelangen IP-Adressen aus einem speziellen Adressbereich (Klasse D) zum Einsatz. Oft wird eine Multicast-Adresse auch als Multicast-Gruppe bezeichnet. Jeder Rechner, der einer solchen Gruppe angehört (also die selbe Multicast-Adresse besitzt), erhält jedes Paket, das an die Gruppe adressiert ist. Die Paketvermittlung realisieren spezielle Multicast-Router, die untereinander über das IGMP-Protokoll (Internet Group Management Protocol) kommunizieren.

IP: Advanced router ermöglicht eine detaillierte Konfiguration des Routing-Verhaltens (das Weiterleiten von IP-Paketen) und ist in erster Linie für Linuxsysteme gedacht, deren Hauptaufgabe das Routing ist. Wird die Option gesetzt, kann per IP: policy routing auch die Absenderadresse eines Pakets in die Routing-Entscheidung einbezogen werden. IP: use netfilter MARK value as routing key gestattet die Auswertung des Netfilter-Markierungswertes von Paketen. Mit der Option IP: fast network address translation gestattet dem Router, Änderungen an der Empfänger- und/oder Absenderadresse der durchgeleiteten Pakete vorzunehmen (diese Regeln werden durch NAT (Network Address Translation) beschrieben). IP: equal cost multipath befähigt den Router, für Pakete, die zu konfigurierenden Eigenschaften entsprechen, über unterschiedliche Pfade weiterzuleiten. Diese Pfade werden als gleichwertig angesehen und die Auswahl, welchen ein Paket nimmt, erfolgt zufällig. IP: use TOS value as routing key lässt den Router bei der Wegfindung für ein Paket auch das Feld TOS (Type Of Service) aus dessem Paketkopf einbeziehen. IP: verbose route monitoring veranlasst den Kernel zu ausführlichen Meldungen über das Routing. Die Option nützlich, um abgelehnte Pakete, die auf einen möglichen Angriff hindeuten könnten, zu protokollieren. Die Aufzeichnung erfolgt durch den Kernel Protokollanten klogd. Die Option IP: large routing tables optimiert einen Router zur Verwaltung von Routing-Tabellen mit mehr als 64 Einträgen.

IP: kernel level autoconfiguration baut die für festplattenlose Rechner notwendigen Mechanismen in den Kernel ein, um seine Netzwerkschnittstellen eigenständig mit den via BOOTP oder RARP empfangenen IP-Adressen zu konfigurieren.

Abbildung 16: Kernelkonfiguration - Netzwerk-Grundeinstellungen (Fortsetzung)

BOOTP support ist erforderlich, wenn ein Rechner seine IP-Adresse bereits während des Bootvorgangs mittels BOOTP empfangen soll. Die Option ist für plattenlose Rechner sinnvoll.

RARP support verwendet zum Empfang der IP-Adresse Reverse-ARP, ein Vorgängerprotokoll von BOOTP. Heutzutage ist BOOTP RARP vorzuziehen.

Bei IP: tunneling handelt es sich um ein Verfahren, um Daten eines Protokolls in ein anderes Protokoll einzubetten und mittels dessen zu versenden. Wichtige Anwendungsgebiete sind die Kommunikation zwischen den Rechnern in Virtuellen Privaten Netzwerken (VPN), wobei die verschlüsselten Daten bspw. in PPP eingebettet werden oder der Datenaustausch zwischen Novell-Netzwerken (IPX over IP).

IP: GRE tunnels over IP (Generic Routing Encapsulation) gewährleistet die Übertragung von IPv6-adressierten Datenpaketen über eine IPv4-Infrastruktur (128 Bit bzw. 32 Bit IP-Adressen). Des Weiteren ist GRE in der Lage, Broadcasts (also das gleichzeitige Senden eines Pakets an mehrere Rechner) auf Wide Area Networks (WAN) auszudehnen. Hierfür muss die Option IP: broadcast GRE over IP gesetzt sein.

Ein Router, der auch Multicast-Pakete vermitteln soll, muss IP: multicast routing aktivieren. Üblich ist IP: PIM-SM version 1 support - Sparse Mode PIM (Protocol Independent Multicast) - nach Version 1, der von zahlreicher CISCO-Hardware unterstützt wird. Auf dem Rechner muss zusätzlich noch ein Daemon (pimd-v1) laufen. Geringer Verbreitung erfreut sich dagegen die Version 2 (IP: PIM-SM version 2 support), da die hierzu notwendigen Daemons (pimd oder gated-5) noch im Expermentierstadium sind.

IP: ARP daemon support (EXPERIMENTAL) deligiert die Adressabbildung von IP-Adressen in Hardwareadressen an einen ARP-Daemon. Sinnvoll ist dies nur in sehr großen Netzen mit mehreren tausend Clients, wodurch der Kernel interne ARP-Cache nicht mehr ausreicht, um alle Adressen verwalten zu können.

IP: TCP Explicit Congestion Notification support befähigt einen Router, Clients über Staus im Netzwerk zu informieren, womit sie bspw. eine andere Routenwahl treffen könnten.

IP: TCP syncookie support (disabled by default) ist eine Schutzmaßnahme gegen das so genannte SYN flooding, wobei ein Angreifer versucht, durch massives gezieltes Senden von Paketen an einen konkreten Rechner, dieses von seinen eigentlichen Aufgaben abzuhalten.

The IPv6 protocol (EXPERIMENTAL) ist die Ünterstützung für den Nachfolger des heutigen IP-Protokolls (ipv4). Der wesentliche Unterschied ist der auf 128 Bit erweiterte Adressraum sowie integrierte Authentifizierungsmechanismen. Rechner in Netzwerken, die IPv6 verwenden, benötigen IPv6: enable EUI-64 token format, um das neue Adressformat und die Zuweisung lokaler Adressen zu beherrschen (bei EUI-64 handelt es sich um eine Richtlinie, wie der 64-Bit lange Hostteil der IPv6-Adresse auszusehen hat; im Wesentlichen handelt es sich um eine Abbildung der 48-Bit-MAC-Adresse auf 64 Bit). Im neuen IPv6-Protokoll ist die dynamische Hostkonfiguration (ähnlich dem DHCP) bereits fest verankert und scheint sich gegenüber der Provider-basierten Adressvergabe (eine Art »feste« Netzwerkadresse) durchzusetzen. Da beide Adressformate inkompatibel sind, sollte zur Problemvermeidung, soweit alle Rechner eines Netzwerks komplett umgestellt sind, die Provider-basierte Adressvergabe mittels IPv6: disable provider based addresses deaktiviert werden. Ein Router, der Pakete gleichzeitig filtern soll, muss diese irgendwie an die Filterprogramme weiter reichen, wozu das Netlink-Device dient. Mit IPv6: routing messages via old netlink lassen sich auch die IPv6-Pakete durch das »alte« Device schleusen; empfohlen wird jedoch die Verwendung von Kernel/User network link driver und Routing messages.

Kernel httpd acceleration (EXPERIMENTAL) ist neben TUX der zweite kernelbasierte Webserver. Wie TUX bedingt auch der khttpd einen »richtigen« Webserver im Hintergrund, der die Verarbeitung aller nicht-statischen Seiten erledigt.

Asynchronous Transfer Mode (ATM) ist erforderlich, wenn in Ihrem Rechner eine Netzwerkkarte für diese Hochgeschwindigkeits-Netztechnologie steckt oder wenn Sie ATM-Techniken in herkömmlichen lokalen Netzen emulieren möchten. In heterogenen Netzen, die ebenso IP-Rechner enthalten, ermöglicht Classical IP over ATM die Kommunikation zwischen ATM- und IP-Rechnern. Der ATM-Rechner wird hierzu neben dem ATM-spezifischen ARP auch das herkömmliche »(IP)ARP« unterstützen. Do NOT send ICMP if no neighbour unterdrückt das Senden von ICMP-Nachrichten, falls im ATMARP-Cache des Kernels keine Verbindung zum Zielrechner existiert. Dies kann zu Problemen führen, falls der Eintrag aus dem ARMARP-Cache soeben gelöscht wurde, um veraltete Informationen zu verwerfen. LAN Emulation (LANE) support emuliert ATM-Dienste in bestehenden lokalen Netzwerken (Ethernet, Token Ring). Diese Option ist Voraussetzung für Multi-Protocol Over ATM (MPOA) support, das ATM-Verbindungen sogar über Subnetzwerkgrenzen hinweg ermöglicht. Während LANE auf OSI-Schicht 2 (Hardwareadressen) aufbaut, arbeitet MPOA mit Schicht 3 (IP-Adressen).

Abbildung 17: Kernelkonfiguration - Netzwerk-Grundeinstellungen (Fortsetzung)

The IPX protocol (Internet Packet eXchange) ist das Novell-Pedand zum IP Protokoll. Sie benötigen diese Unterstützung, wenn von Linux aus auf Novell NetWare Druck- oder Dateiserver zugegriffen werden oder Linux als Novell-Client fungieren soll. Um Linux selbst als einen solchen Server zu betreiben, ist das IPX selbstverständlich ebenso Veraussetzung. Ein IPX-Netzwerk besitzt eine (innerhalb eines Verbundes von IPX-Netzwerken) eindeutige Netzwerkadresse. Die Paketvermittlung beruht einzig auf solchen Netzwerkadressen. Bedient nun bspw. ein Dateiserver Clients in mehreren Netzwerken, so müsste der Server aus jedem Netzwerk heraus über eine andere Adresse angesprochen werden. Um dies zu umgehen, kann mittels IPX: Full internal IPX network einem als Server fungierenden Linux-Rechner eine »virtuelle« Netzwerkadresse zugewiesen werden. Er wird somit aus allen verbundenen Netzwerken heraus unter derselben Adresse erreichbar.

Um mit MAC's (Apple-Rechner) zu kommunizieren, muss Linux AppleTalk protocol support aktivieren.

DECnet support integriert ein Netzwerkprotokoll von Digital Equipment Corporation (Compaq) in den Kernel. Dieses auf Ethernet basierende Protokoll verwenden einige Betriebssysteme (VMS, RSX, ULtrIX); ein wesentlicher Unterschied zu TCP/IP ist die Adressierung mittels »Rechnername:Nutzername«. Wenn Sie diese Option wählen, müssen Sie sowohl »/proc file system support« als auch »Sysctl support« aktivieren. DECnet SIOCFIGCONF support sollte stets abgeschalten sein, ebenso DECnet Router Support (EXPERIMENTAL), da sich Letzteres noch in der Entwicklung befindet. Mit DECnet: use FWMARK value as routing key ist die Vorgabe von Routen möglich, die ein Paket zu durchlaufen hat (sonst entscheidet der Router allein über die Wegfindung).

Ein Linuxrechner vermag mittels 802.1d Ethernet Bridging die Aufgaben einer Brücke für Ethernet-Netzwerke zu übernehmen. Natürlich bedarf er dazu auch mehrere Netzwerkkarten, um die einzelnen Netzwerksegmente zu verbinden.

X.25 ist eine Empfehlung des ITU-T (International Telecommunication Union - telecommunications standardization sector) zum Aussehen der Schnittstelle von einem Endteilnehmer zu einem Eintrittspunkt in öffentliche, Paket vermitteltende Netze. Wichtigster Vertreter in Deutschland ist Datex-P. X.25 orientiert sich an den drei unteren Schichten des OSI Referenz Protokolls. Die Option CCITT X.25 Packet Layer (EXPERIMENTAL) aktiviert den Teil des X.25-Treibers, der für den Aufbau einer virtuellen Verbindung von einem zu einem anderen an das X.25-Netzwerk angeschlossenen Computer vornimmt (entspricht OSI-Schicht 3).

Link Access Procedure, Balanced (LAPB) ist der auf OSI-Schicht 2 operierende Teil der X.25-Unterstützung, der durch LAPB Data Link Driver (EXPERIMENTAL) aktiviert wird. Linux behrrscht derzeit einzig X.25 über Ethernet.

802.2 LLC (EXPERIMENTAL) ermöglicht die Verwendung des X.25 Protokolls über das Ethernet.

Frame Diverter (EXPERIMENTAL) ist eine Technik, um in Linuxrechnern, die als Bridges fungieren, den Netzwerkverkehr zwischen einem Router und dem lokalen Ethernet-Netzwerk zu »cachen« (i.d.R. in Verbindung mit Squid).

Acorn Econet/AUN protocols (EXPERIMENTAL) ermöglicht den Zugriff auf Datei- und Druckerserver über das Econet Protokoll, das einst von Acorn entwickelt wurde und heute kaum noch anzutreffen ist. Mit AUN over UDP wird das Econet Protokoll über das UDP und gewöhnliche Ethernetkarten abgewickelt, per Native Econet erfolgt der Datentransfer über »echte« Econet-Netzwerkadapter (falls vorhanden).

Im Internet gelangen andere Kommunikationstechnologien zu Einsatz als in lokalen Netzwerken (X.25, Frame Relay...). Zur Verbindung von lokalen Netzen zu solchen Technologien werden häufig teure Spezialgeräte - die Router - eingesetzt. Alternativ kann ein Linuxrechner mit entsprechenden WAN-Schnittstellen-Karten ausgestattet werden. Mit WAN router wird nun ein Treiber [WAN Link Driver (WLD)] in den Kernel integriert, der einen hardwareunabhängigen Dienst zur Verfügung stellt, auf den die einzelnen Treiber der Schnittstellenkarten zugreifen.

Fast switching (read help!) ist für eine beschleunigte Übertragung zwischen zwei Netzwerkkarten vorgesehen. Da Kartentreiber, die diese Funktion unterstützen, kaum verfügbar sind und sich eine Reihe von Problemen mit anderen Netzwerkoptionen einstellen können, wird von einer Aktivierung abgeraten.

Forwarding between high speed interfaces aktiviert bei manchen Netzwerkkarten (Tulip) das hardwareseitige Drosseln der Datenübertragung falls das Netz einer zu starken Auslastung unterliegt. Die Option sollte nicht aktiviert werden.

IP: Netfilter Configuration

IP: connection tracking (required for masq/NAT) intergriert Datenstrukturen in den Kernel, um Informationen zu Paketen zu speichern, die durch den Rechner vermittelt wurden. Die Option ist u.a. für Masquerading und NAT erforderlich. Um auch FTP-Pakete zu beobachten, muss FTP protocol support aktiviert werden.

Mit IP: user space queueing via NETLINK (EXPERIMENTAL) kann Netfilter Pakete über das Netlink-Device vom Kernel- in den Benutzer-Adressraum kopieren. Diese Option wird benötigt, wenn Pakete manipuliert werden sollen.

IP: ip tables support (required for filtering/masq/NAT) limit match support MAC address match support netfilter mark match support Multiple port match support TOS match support tcpmss match support Connection state match support Unclean match support (EXPERIMENTAL) Owner match support (EXPERIMENTAL) Packet filtering REJECT target support MIRROR target support (EXPERIMENTAL)

IP: Virtual Server Configuration

IP: virtual server support IP virtual server debugging IP masquerading VS table size (the Nth power of 2)

IPVS: round-robin scheduling IPVS: weighted round-robin scheduling IPVS: least-connection scheduling IPVS: weighted least-connection scheduling IPVS: locality-based least-connection scheduling IPVS: locality-based least-connection with replication scheduling IPVS: destination hashing scheduling IPVS: source hashing scheduling

IPv6: Netfilter Configuration

IP6 tables support (required for filtering/masq/NAT) limit match support netfilter mark match support Packet filtering Packet mangling MARK target support

QoS and/or fair queueing

Wenn mehrere Anwendungen gleichzeitig Pakete auf eine Netzwerkschnittstelle senden, dann muss sich Kernel um deren Synchronisation bemühen. Das einfachste Verfahren ist, das Paket als erstes zu senden, das auch als erstes an der Schnittstelle eintraf (FIFO - First In First Out). Genau dieses Prinzip findet Anwendung, wenn Sie QoS and/or fair queueing abschalten.

Zumindest für hoch verfügbare Server ist sicher sinnvoll, wenn bestimmte Pakete bevorzugt behandelt werden, während die Verarbeitung anderer »hintenan« gestellt wird. Das Auswahlverfahren nimmt ein so genannter Scheduler vor.

Telephony Support

Linux telephony support unterstützt Telefon-Adapterkarten. An solchen Karten (keine Modems!) lassen sich herkömmliche Telefonapparate betreiben, die somit zum Telefonieren über das Internet verwendet werden können.

QuickNet Internet LineJack/PhoneJack support ist der Treiber für Karten von Quicknet Technologies, Inc.

ATA/IDE/MFM/RLL support

IDE, ATA and ATAPI Block Devices

SCSI support

Speziell für Notebooks existieren PCMCIA-Einschubkarten, die als SCSI-Controller fungieren. Zum Zugriff auf solche Karten muss PCMCIA SCSI adapter support aktiviert werden. Des Weiteren ist der Treiber für den konkreten Kartentyp unfordlich, also Adaptec AHA152X PCMCIA support für einen Adaptec-Controller, Qlogic PCMCIA support für den Adapter von Qlogic und Future Domain PCMCIA support für den Future Domain PCMCIA-SCSI-Controller.

Firewire support

IEEE 1394 (FireWire) support (EXPERIMENTAL) ist die Unterstützung für einen noch recht neuen seriellen Bus, der vor allem bei Notebooks der gehobenen Klasse anzutreffen ist. Auch manche Videoschnittkarte verfügt ü,ber einen Firewire-Anschluss zur Verbindung mit einer Videokamera. Mit dieser Option werden einzig die Grundfunktionen in den Kernel integriert; zum Betreiben der Hardware ist ein spezieller Treiber erforderlich.

Texas Instruments PCILynx support ist der richtige Treiber für Geräte mit einem PCILynx-Chip der Version 2. Ältere Versionen werden nicht unterstützt. Use PCILynx local RAM aktiviert den RAM auf Boards mit dem PCILynx-Chip, sodass dieser anstelle des normalen Hauptspeichers verwendet wird. Allerding sind derzeit nur einzelnen Prototypen mit lokalem RAM bestückt. Support for non-IEEE1394 local ports gestattet dem Treibercode über Devices in /dev auf den RAM, ROM und die Ports der PCILynx-Boards zuzugreifen. Die Option sollte nicht aktiviert werden.

OHCI (Open Host Controller Interface) support ist der Treiber für Firewire-Controller, die auf OHCI basieren.

Raw IEEE 1394 I/O support ermöglicht Programmen den direkten Zugriff auf den IEEE 1394 Bus und somit auf die angeschlossene Hardware.

Mit Excessive debugging output generieren die Firewire-Treiber erweiterte Statusausgaben inklusive der Header aller empfangenen oder gesendeten Pakete.

I2O device support

Bei Intelligent Input/Output handelt es sich um eine (relativ) treiber- und betriebssystemunabhängige I/O-Architektur, wodurch CPU, Hauptspeicher und Systembus von zeitaufwändigen Ein- und Ausgabeprozessen entbunden werden, indem diese Aufgabe spezielle Prozessoren auf I2O-fähigen Schnittstellenkarten übernehmen. Auf Betriebssystemseite bietet ein OS-Service-Modul (OSM) Schnittstellen an, auf die das hardwarespezifische Modul (HDM) zugreift. Die Schnittstelle selbst wird über I2O support aktiviert.

I2O PCI support ist erforderlich, wenn I2O-Karten am PCI-Bus angeschlossen sind. Die Unterstützung von I2O-fähigen Festplatten u.ä. blockweise arbeitender Geräte wird durch die Option I2O Block OSM aktiviert. Auch einige Netzwerkkarten für Token Ring und FDDI beherrschen I2O und werden über I2O LAN OSM verfügbar. I2O SCSI OSM ist für I2O-SCSI-Controller erforderlich. Mit I2O /proc support landen I2O-relevante Informationen im Verzeichnis /proc/i2o.

Network device support

Amateur Radio support

Irda (infrared) support

ISDN subsystem

Old CD-ROM drivers (not SCSI, not IDE)

Input core support

Character devices

Multimedia devices

Filesystems

Anmerkung: Das Dateisystem, das Ihre Rootpartition beinhaltet, darf nicht als Modul realisiert sein. Alle anderen Dateisysteme, auf die Sie zuzugreifen wünschen, können auch in Form eines Moduls unterstützt werden.

Quota support ermöglicht das Setzen von Limits für die Festplattenausnutzung, sodass verschiedenen Benutzern nur ein bestimmtes Kontingent eingeräumt wird. Im Abschnitt zur Sicherheit unter Linux (Systemadministration) finden Sie weitere Hinweise zur Konfiguration.

Mit Hilfe von Kernel automounter [v4] support ist der Kernel in der Lage, Dateisysteme automatisch zu mounten, sobald auf diese erstmals zugegriffen wird. Aufgrund der erweiterten Funktionsumfangs sollte die neuere Version 4 verwendet werden. Hinweise zur Konfiguration des Automounters stehen im Abschnitt Dateisysteme (Systemadministration).

ReiserFS war das erste ausgereifte Journaling Filesystem für Linux und wird von zahlreichen aktuellen Distributionen als Ersatz zum ext2 eingesetzt. Entgegen weitläufiger Meinungen kann auch von einem ReiserFS gebootet werden, sodass auf ext2 vollständig verzichtet werden kann. Notwendig ist nur ein aktueller Bootloader, der von diesem Dateisystemtyp lesen kann. Von Have reiserfs do extra internal checking ist abzusehen, da die verschärften Pr&uum;fungen zu spürbaren Leistungseinbßen führen. Die Option ist nur für Dateisystementwickler nützlich.

Das Acorn Disc Filing System ist das Standarddateisystem unter RiscOS. Um dieses zu lesen, ist die Option ADFS file system support (EXPERIMENTAL) notwendig. Das Schreiben ist zwar möglich (ADFS write support (DANGEROUS)), aber mit Vorsicht zu genießen.

Mittels Amiga FFS file system support lassen sich Partitionen von AmigaOS ab Version 1.3 lesen und schreiben.

Apple Macintosh file system support (EXPERIMENTAL) gestattet den lesenden und schreibenden Zugriff auf Apple-Dateisysteme.

BFS file system support (EXPERIMENTAL) ist ein Dateisystem, das u.a. von SCO UnixWare verwendet wird. Zum Zugriff auf solche Boot File Systeme (BFS) ist die Option zu aktivieren.

DOS FAT fs support ist erforderlich, um auf FAT-basierende (File Allocation Table) Dateisysteme zugreifen zu können. MSDOS fs support ist für den Zugriff auf DOS-Disketten, bei der Verwendung von UMSDOS (siehe nachfolgend) oder des DOS-Emulators erforderlich. Möchten Sie Linux auch einer DOS-Partition installieren, kommt die Option UMSDOS: Unix-like file system on top of standard MSDOS fs in Frage. Aus Effizienzgründen ist allerdings hiervon abzuraten. Sowohl FAT16 als auch FAT32 lassen sich mit VFAT (Windows-95) fs support lesen und schreiben, solange die Daten darauf unkomprimiert vorliegen.

Bei EFS file system support (read-only) (EXPERIMENTAL) handelt es sich um ein altes und kaum verbreitetes Dateisystem für CDROMs.

Support for the Journalling Flash Filesystem ist ein Dateisystem, das bevorzugt in embedded Systemen eingesetzt wird.

Compressed ROM file system support ist der Treiber für ein für embedded Systeme entwickeltes Dateisystem (CramFs). Die Daten werden hierbei komprimiert auf Compact-Flash-Memory-Karten abgelegt. Virtual memory file system support richtet im Hauptspeicher ein virtuelles Dateisystem ein, das - im Unterschied zu RAM-Disks - seine Größe dynamisch anpassen kann. Simple RAM-based file system support ist ein vollständig im RAM liegendes Dateisystem. Alle drei Dateisysteme werden in Midori-Linux eingesetzt, einem für embedded Systeme optimiertem Linux-System.

ISO 9660 CDROM file system support ist die Unterstützung für das bevorzugte Dateisystem auf CDROM. Für Rechner mit CDROM-Laufwerk ist die Option notwendig. Microsoft Joliet CDROM extensions ist eine Erweiterung des ISO 9660 Dateisystems, um lange Dateinamen im Unicode abzuspeichern. Zwar verwenden nicht viele CDROM tatsächlich die Erweiterung, aber die Aktivierung der Option wird auch nicht schaden.

Wer die Einleitung zum Buch gelesen hat, dem sollte Minix als Vorbild für Linux geläufig sein. Aus diesem Grund bildete das Minix-Dateisystem in frühen Kernelversionen eine tragende Rolle. Heute findet man es, wenn überhaupt, nur noch vereinzelt auf Disketten. In seltenen Fällen wird also Minix fs support benötigt.

NTFS support (read only) gestattet den lesenden Zugriff auf Windows-Partitionen vom Typ. Sie sollten auch nicht versuchen, mittels NTFS write support (DANGEROUS) schreibend auf Systempartitionen zuzugreifen, da es schnell zu einer nicht mehr funktionierenden Windows-Installation fürt (die Treiberentwicklung steckt in den Kinderschuhen, da Microsoft keinerlei Dateils zu den Interna von NTFS preis gibt). Zum Datenaustausch zwischen Windows und Linux sollten Sie die Formatierung einer(aller) Windows-Partitionen mit FAT32 bevorzugen.

OS/2 HPFS file system support betrifft die Unterstützung für IBM's High Performance Dateisystem, das unter OS/2 Verwendung findet. Disketten, die unter OS/2 erstellt wurden, sind mit dem MSDOS-Dateisystem formatiert und bedingen keinen HPFS-Treiber um unter Linux verwendet werden zu können.

Mit /proc file system support wird das virtuelle Prozessdateisystem des Kernels eingebunden. Hierbei handelt es sich nicht um ein physisches Dateisystem, sondern um eine dynamisch erzeugte Struktur, in der der Kernel zur Laufzeit verschiedenste Statusparameter bereit hält. Sie sollten nicht versuchen, diese Option abzuschalten, da zu viele wichtige Programme ohne dieses System nicht mehr korrekt funktionieren.

Die relativ neue Option /proc/config.gz (kernel configuration) speichert die aktuelle Kernelkonfiguration während der Laufzeit in der komprimierten Datei /proc/config.gz. Indem Sie diese entpacken (gunzip) und in das Stammverzeichnis der Kernelquellen als .config abspeichern, können Sie die aktuelle Konfiguration per "make oldconfig" für einen neuen Kernel übernehmen.

Noch ist das Device-Dateisystem im experimentellen Stadium, aber demnächst ist zu erwarten, dass es die Gerätestruktur unterhalb /dev ablösen wird. Mit /dev file system support (EXPERIMENTAL) werden im Verzeichnis /dev nur noch diese Geräte sichtbar, die tatsächlich vorhanden sind und vom Kernel erkannt wurden. Des Weiteren liegen die Gerätedateien nicht mehr direkt unterhalb von /dev, sondern in nach Gerätetypen gruppierten Unterverzeichnissen. Falls Sie mit Linux vertraut sind, können Sie das Device-Dateisystem schon jetzt anwenden, jedoch sind Anpassungen aller Dateien notwendig, die Konfigurationen mit Dateien aus /dev vornehmen (wichtig vor dem ersten Bootversuch: Anpassen der /etc/fstab). Damit der Kernel das Dateisystem schon beim Start einbindet, kann Automatically mount at boot verwendet werden. Die Alternative ist ein Eintrag in /etc/fstab). Für den Treiber- und Kernelentwickler interessant sind die mit Debug devfs verfügbaren Statusmeldungen.

/dev/pts file system for Unix98 PTYs ist ein virtuelles Dateisystem für Pseudoterminals gemäß dem Unix98 Standard. Sie sollten die Optio nur wählen, falls Sie Unix98 PTYs support aktiviert haben (glibc >= 2.1 erforderlich!) und das Dateisystem auch mit "mount -t devpts" aktivieren.

Mit QNX4 file system support (read only) (EXPERIMENTAL) können Festplatten und Disketten gelesen werden, die unter dem System QNX 4 erstellt wurden. Die Unterstützung des Schreibens auf dieses Dateisystem (QNX4FS write support (DANGEROUS)) ist mit Vorsicht zu genießen.

Bei ROM file system support handelt es sich um ein minimales schreibgeschütztes Dateisystem, dass für initiale RAM-Disks auf Installationsdisketten prädistiniert ist. Seine herausragende Eigenschaft ist, dass es dynamisch wächst, wenn bspw. neue Module während der Installation nachgeladen werden und der aktuelle Speicherplatz nicht mehr ausreicht.

Vor Reiserfs-Zeiten war Second extended fs support (kurz: ext2) quasi das Standard-Dateisystem unter Linux. Die Unterstützung gehört zwingend in den Kernel. Mit JFFS debugging verbosity lassen sich die Menge der Statusausgaben dieses Dateisystem einstellen (0 - keine Meldungen, 3 - Maximum).

System V and Coherent file system support (read only) gestattet lesenden Zugriff auf Partitionen und Disketten der Unix-Derivate SCO, Xenix und Coherent. Beschreiben lassen sie sich mit SYSV file system write support (DANGEROUS).

UDF File System support (read only) ist zum Lesen von DVDs erforderlich (und derartig formatierter CD's). Die Entwicklung der Schreibunterstützung UDF write support (DANGEROUS) befindet sich jedoch noch in einer sehr frühen Phase.

Coda file system support (advanced network fs) gestattet einem Linux-Rechner als Client auf Code-Dateisysteme zuzugreifen. Coda selbst ist ein Netzwerkdateisystem ähnlich dem NFS. Darüber hinaus beinhaltet es Mechanismen zur Ausfallsicherheit, Datenverschlüsselung und a.m. Ein Coda-Server benötigt keine Kernelunterstützung.

Das Network Filesystem ist nach wie vor die Standardmethode, um unter Unix Daten im Netzwerk bereit zu stellen. Mit NFS file system support ist es möglich, »frei gegebene« Dateisysteme von einem NFS-Server in die lokale Verzeichnisstruktur zu integrieren. Die Version 3 des NFS-Protokolls versteht ein Client erst, wenn die Option Provide NFSv3 client support (EXPERIMENTAL) aktiviert wurde. Rechner ohne oder mit sehr kleiner Festplatte werden gern es konfiguriert, dass sie ihr Root-Dateisystem via NFS von einem Server mounten (Root file system on NFS).

Der Linux-NFS-Implementierung haftete lange Zeit ein Problem an: der Datentransfer gestaltete sich recht träge. Hauptgrund war die Realisierung des Servers im Nutzeradressraum (Userspace), womit Datenpakete unnötig oft zu kopieren waren. Mit NFS server support wird deshalb der noch relativ junge kernelbasierte NFS-Server aktiv, der merklich z&uuuml;giger die Daten ins Netz schaufelt. Mit Provide NFSv3 server support beherrschr auch der Server die neueste Protokollversion.

Per Server Message Block kommunizieren die LAN-Server in Windows-Netzwerken. Um als Client oder Server (Dateien, Drucker) im Windows-Netzwerk zu fungieren, muss SMB file system support (to mount Windows shares etc.) angewählt werden. Die Option Use default NLS erlaubt die Zeichensatzkonvertierung für Dateinamen und ist i.d.R. nicht notwendig; weitere Aussagen dazu folgen später (Native Language Support).

Novell NetWare Clients verwenden das NCP (NetWare Core Protocol) um über IPX (»Novells IP«) auf ihre Dateiserver zugreifen zu können. Damit Linux einen Novell Client emulieren kann, muss die Option NCP file system support (to mount NetWare volumes) gesetzt werden. Packet signatures erlaubt es, Pakete mit »Unterschriften« zu versehen, um somit ihre Unversehrtheit auf Empfangsseite verifizieren zu können. Diese Option wird kaum benötigt. Mit Proprietary file locking können manche Anwendungen Dateien sperren, die sie von Netzwerkfreigaben bezogen haben; auch diese Option ist selten von Nutzen. Die Option Clear remove/delete inhibit when needed ermöglicht die Bearbeitung von Daten, die auf der Freigabe bereits gelöscht oder umbenannt wurden. Im Normalfall unterscheidet NCP nicht zwischen Groß- und Kleinschreibung der Dateinamen. Um diese zu aktivieren ist Use NFS namespace when available notwendig. Die Beibehaltung der OS2-Dateinamensgebung auf NCP-Netzfreigaben wird durch Use OS2/LONG namespace when available erreicht; indem Fall werden durch Lowercase DOS filenames on LONG namespace volume alle Dateinamen in Kleinbuchstaben konvertiert. Die Option Use Native Language Support erlaubt die Zeichensatzkonvertierung für Dateinamen und ist i.d.R. nicht notwendig; weitere Aussagen dazu folgen später (Native Language Support). Symbolische Links und Ausführungsrechte lassen sich auf Dateien im NCP-Dateisystem nur setzen, wenn Enable symbolic links and execute flags aktiv ist.

Advanced partition selection gestattet den Einbau und die Verwendung von Festplatten, die unter einem anderen Betriebssystem auf einer anderen Architektur partitioniert wurden (bspw. eine Platte aus einem MAC). Da wohl - wenn überhaupt - nur Insider auf so eine Idee kommen, erspare ich mir die Aufzählung der einzelnen Partitionierungsschemata.

Native Language Support sorgt für die Umsetzung von Dateinamen zwischen dem Server-Dateisystem und dem lokalen Ein-/Ausgabe-System. Der voreingestellte Zeichensatz iso8859-1 sollte im mitteleuropäischen Raum zutreffen. Wenn Sie auf Dateien von Servern zugreifen, welche andere Zeichensätze verwenden, sollte Sie die entsprechende Unterstützung ergänzen. I.d.R. brauchen Sie hier also keine Einträge vorzunehmen.

Console drivers

Sound

USB support

Wer über Geräte verfügt, die über den Universal Serial Bus an den Rechner angeschlossen werden, der sollte die Option Support for USB aktivieren. Will die Konfiguration einer solchen Hardware nicht gelingen, kann USB verbose debug messages weiter helfen, womit die Treiber erweiterte Statusmeldungen erzeugen. Es empfiehlt sich, letztere Option zu entfernen, wenn die Geräte endlich laufen sollten; sonst müllt die Systemprotokollierung rasch die Platten zu...

Ebenso für die Fehlersuche nützlich und dennoch Resourcen schonend - ist das USB-Dateisystem, das nach dem Aktivieren von Preliminary USW filesystem unter /proc/usb sichtbar wird. Wenn sich mehrere Geräte um die Bandbreite des Busses bewerben, kann ein »besonders eifriges« Stück Hardware so viele Resourcen belegen, dass andere quasi verhungern. Um etwas Gerechtigkeit herbeizuführen, verhindert Enforce USB bandwidth allocation (EXPERIMENTAL) den Tatendrang von Geräten, die mehr als 90% der Bandbreite anfordern.

Die im Rechner eingebauten USB-Controller können nach zwei Standards realisiert sein, nach dem »Universal Host Controller Interface« (Intel) oder nach »Open Host Controller Interface« (Compaq/Microsoft/National). Als Faustregel ist davon auszugehen, dass die auf Boards mit Intel-PCI- oder VIA-PCI-Chipsätzen anzutreffenden Adapter ersterem Standard folgen und zusammen mit dem Treiber UHCI (intel PIIX4, VIA, ...) support? oder UHCI Alternate Driver (JE) support? ihren Dienst verrichten sollten. SiS- und Ali-Chipsätze unterstützen hingegen den OHCI-Standard und benötigen den mit OHCI (Compaq, iMacs, OPTi, SiS, ALi, ...) support bezeichneten Treiber. Im Zweifelsfall sollten Sie alle drei Treiber als Modul realisieren, so ist durch späteres Testen leicht festzustellen, mit welchem Treiber der Hostadapter zu Rande kommt.

Kernel hacking

Der Dialogtitel beschreibt bereits die Zielgruppe dieser Optionen: den Kernel-Entwickler. Magic SysReq Key (System Request) eröffnet den Zugang zu einigen Tastenkombinationen ([Alt]+[Druck], Taste), um dem Kernel zur sofortigen Bearbeitung der mit der Kombination verbundenen Anweisung zu bewegen. Eine Beschreibung zu den Tasten und den Wirkungen findet sich in der Kerneldokumentation unter »Kernel-Quellverzeichnis/Documentation/sysreq.txt«.

Etliche Parameter des Kernels können per Kommandozeilenoptionen übergeben werden, was allerdings dessen Start mittels eines Bootmanagers bedingt. Ein Kernel, der als Rettungsanker auf einer Diskette untergebracht wird, wird jedoch i.d.R. zum Booten seinen eigenen Startcode, der im Kernelimage zuvorderst steht, verwenden (u.a. weil ein Bootloader selbst wiederum einen Teil des knappen Diskettenplatzes belegen würde). Bei einem solchen Kernel müssen die »wichtigsten« Parameter passen, damit er bspw. das Root-Dateisystem finden und mounten kann.

Möglich wird das Modifizieren dieser Einträge, weil jene jedes Kernelimage an exakt festgelegten Adressen (beginnend bei Offset 504 Bytes) enthält.

Ein Kommando für alle

Zum Auslesen und Setzen dieser Parameter existieren mehrere Kommandos, wobei rdev (Root Device) in Zusammenhang mit Optionen identisch zu den weiteren Kommandos wirkt:

-r
	rdev arbeitet wie ramsize
-R
	rdev arbeitet wie rootflags
-v
	rdev arbeitet wie vidmode
-s
	rdev arbeitet wie swapdev
-h
	Ein kurzer Hilfetext wird ausgegeben

Es ist also egal, ob Sie bspw. die Lage der Swap-Partition mittels swapdev oder mittels rdev -s einstellen. Wir beschränken uns in den Beispielen auf rdev.

Kommandoaufruf

Wird rdev ohne Argumente gerufen, so gibt es einzig die Lage des aktuellen Root-Dateisystems preis. Es befragt hierzu nicht erst den aktiven Kernel, sondern schaut in der Datei /etc/mtab nach:

Um weitere Informationen zu gewinnen, ist das zu betrachtende Kernelimage anzugeben:

Liegt der Kernel auf einer Diskette, so ist er über das entsprechende Device erreichbar (das gilt nur, wenn der Kernel per dd auf das Medium kopiert wurde, was der übliche Weg ist, eine bootbare Diskette zu erzeugen):

Ändern des Rootdevices

Um das Rootdevice permanent im Kernelimage zu ändern, ist das neu zu verwendende Device dem Imagenamen nachzustellen:

Ändern der RAM-Disk-Parameter

Die wenigsten Leser werden mit Ram-Disk tatsächlich in Berührung kommen. Dennoch soll auch diese Thematik angesprochen werden. Eine Ram-Disk verwenden i.d.R. die Distributoren, um die Installationskernel einerseits relativ klein und andererseits umfangreich genug zu halten, um auf jeder Standard-Hardware zu booten. Der Kernel enthält nun im Wesentlichen die Fähigkeiten, um eine solche (komprimierte) Ram-Disk zu laden und das enthaltene Skript zu starten. Dieses Skript kümmert sich dann zumeist um die Erkennung der Hardware und die Einbindung der benötigten Treiber. Eine Einführung in die Thematik ist im Abschnitt Booten (Systemadministration) zu finden.

Was muss der Kernel nun wissen? Zum einen muss ihm mitgeteilt werden, dass er überhaupt eine Ramdisk laden soll. Das, was als Kernelargument load_ramdisk veranlasst, regelt intern das Bit Nummer 14 in einem 2 Byte großen Wert (das »Ramdisk-Wort«). Steht es auf "1", lädt der Kernel die Ramdisk; steht es auf "0", ignoriert er sie. Des Weiteren muss die Ramdisk nicht zwangsläufig auf derselben Diskette liegen, wie der Kernel selbst. Daher stoppt eine "1" in Bit 15 des obigen Wertes den Kernel, sodass die Diskette ggf. gewechselt und die Arbeit nach Betätigen von [Enter] fortgesetzt werden kann (entspricht dem Kernelargument prompt_ramdisk). Die ersten 11 Bytes bestimmen nun den Offset (in 1k Blöcken; Kernelargument ramdisk_start), an dem die Ramdisk auf der Diskette liegt (Bit 11-13 werden nicht belegt).

Als Beispiel nehmen wir den Fall an, dass Kernel und zugehörige Ramdisk hintereinander auf dieselbe Diskette kopiert werden:

Die Ramdisk beginnt somit am 325. Block. Damit der Kernel sie auch lädt, muss das Bit 14 gesetzt sein, also ergibt sich der Wert für das Ramdisk-Wort zu 325+2¹⁴=33093:

Ändern des Video-Modus

Bei heutigen Bildschirmgrößen wirkt die übliche Darstellung mit 80x25-Zeichen etwas unangemessen; etwas »mehr« Text hätte gut und gern auf der Mattscheibe Platz. Um die zu verwendende Auflösung dem Kernel mittzuteilen, ist deren numerische Code zu setzen.

Dabei steht der Wert von -1 für den Standardmodus (also 80x25 Zeichen), eine -2 schaltet den erweiterten VGA-Modus ein (80x50 Zeichen). Die weiteren unterstützen Videomodi werden beginnend bei 1 durchnummeriert; jedoch hängt es von der Grafikkarte ab, welche Modi diese bereit stellt. Aus diesem Grund sollte zunächst -3 gewählt werden, wodurch der Kernel beim Start eine Liste der verfügbaren Modi anzeigt und zur Auswahl auffordert. Entspricht ein Modus Ihren Ansprüchen, können Sie diesen später fest eintragen.

Ändern des Rootflags

Die zulässigen Werte sind "0", um das Rootdevice mit Schreib- und Leseberechtigung zu mounten unt "1", um das Dateisystem schreibgeschützt einzuhängen:

Ändern des Swapdevices

Diese Option ist nur erforderlich, falls der Hauptspeicher stark begrenzt ist (<16..32MB). Der Kernel wird nun bereits während des Startens das eingetragene Swapgerät aktivieren und den verfügbaren Speicher somit um die Swapgröße erweitern. Gerade in Verbindung mit initialen Ramdisks ist ein Minimum an Hauptspeicher Voraussetzung, damit der Kernel booten kann.