Treiber

Aktuelle Linux-Kernel unterstützen eine große Anzahl von Geräten. Gerätetreiber füllen etwa die Hälfte des gesamten Quellbaums (oder sogar zwei Drittel, wenn Sie den architekturspezifischen Code, den Sie nicht verwenden, nicht mitrechnen). Sie bestehen zusammen aus fast 1500 C-Dateien und mehr als 800 Header-Dateien.

Das Verzeichnis drivers selbst enthält keine einzige Quelldatei, sondern nur Unterverzeichnisse (und natürlich ein Makefile).

Die Strukturierung einer großen Menge von Quellcode ist nicht einfach, und die Entwickler sind keinen strikten Regeln gefolgt. Die ursprüngliche Aufteilung zwischen drivers/char und drivers/block ist heutzutage uneffizient. Es sind außerdem weitere Verzeichnisse angelegt worden, um diverse Anforderungen zu erfüllen. Die generischsten Zeichen- und Block-Treiber stehen aber weiterhin in drivers/char und drivers/block, weswegen wir dort anfangen.

drivers/char

Das Verzeichnis drivers/char ist wahrscheinlich das wichtigste in der ganzen drivers-Hierarchie, weil es eine Menge treiberunabhängigen Codes enthält.

Die generische TTY-Schicht (wie auch die Line Disciplines, die TTY-Software-Treiber und ähnliche Features) ist in diesem Verzeichnis implementiert. Die Datei console.c definiert den Terminal-Typ linux (indem sie die speziellen Fluchtsequenzen und die Tastatur-Encodierung implementiert). vt.c definiert die virtuellen Konsolen und enthält auch den Code, um von einer virtuellen Konsole auf eine andere zu wechseln. Die Unterstützung der Zwischenablage auf der Linux-Text-Konsole ist in selection.c implementiert, die Default-Line Discipline in n_tty.c.

Es gibt noch weitere Dateien, die wahrscheinlich entgegen Ihrer Erwartung, geräteunabhängig sind. lp.c implementiert einen generischen Parallel-Port-Druckertreiber, der auch die Console-on-line-printer-Fähigkeit enthält. Dieser ist geräteunabhängig, weil der parport-Gerätetreiber die Operationen auf die eigentliche Hardware abbildet (wie Sie in Abbildung 2-2 sehen können). Entsprechend implementiert keyboard.c die höheren Ebenen der Tastatursteuerung; diese Datei exportiert die Funktion handle_scancode, so daß plattformspezifische Tastaturtreiber (wie pc_keyb.c im gleichen Verzeichnis) von der verallgemeinerten Verwaltung profitieren können. mem.c implementiert /dev/mem, /dev/null und /dev/zero: grundlegende Ressourcen, ohne die man nicht auskommt.

Übrigens wird mem.c immer mitkompiliert, weil es auch das Zuhause von chr_dev_init ist, was wiederum mehrere andere Treiber initialisiert, sofern diese mitkompiliert werden.

Es gibt noch andere geräte- und plattformunabhängige Quelldateien in drivers/char. Wenn Sie sich die Aufgaben der einzelnen Dateien anschauen wollen, dann beginne Sie am besten im Makefile dieses Verzeichnisses, einer interessanten und weitgehend selbsterklärenden Datei.

drivers/block

Wie das gerade beschriebene Verzeichnis drivers/char, so gibt es auch drivers/block schon seit langem in der Linux-Entwicklung. Hier fanden sich früher alle Block-Gerätetreiber, weswegen hier auch immer noch einiger geräteunabhängiger Code zu finden ist.

Die wichtigste Datei ist ll_rw_blk.c (low-level read-write block). Sie implementiert alle Anfrage-Verwaltungsfunktionen, die wir in Kapitel 12> beschrieben haben.

Relativ neu in diesem Verzeichnis ist blkpg.c (kam mit 2.3.3 hinzu). Diese Datei implementiert generischen Code für die Partitions- und Geometrie-Verwaltung in Block-Geräten. Der hiesige Code ersetzt gemeinsam mit dem oben beschriebenen Verzeichnis fs/partitions das, was früher “generic hard disk”-Unterstützung hieß. Die Datei namens genhd.c existiert immer noch, enthält heutzutage aber nur noch die generischen Initialisierungsfunktionen für Block-Treiber (ähnlich derjenigen für Zeichen-Treiber in mem.c). Eine der von blkpg.c exportierten öffentlichen Funktionen ist blk_ioctl, die wir in “>” in Kapitel 12> behandelt haben.

Die letzte geräteunabhängige Datei in drivers/block ist elevator.c. Diese Datei implementiert den Mechanismus zur Änderung der Fahrstuhl-Funktion eines Block-Gerätetreibers. Diese Funktionalität kann durch die in “>” kurz eingeführten ioctl-Befehle ausgenutzt werden.

Neben den Hardware-abhängigen Gerätetreibern, die Sie in drivers/block sicher erwarten, enthält dieses Verzeichnis auch Software-Gerätetreiber, die von Haus aus plattformunabhängig sind, genau wie die Treiber sbull und spull, die wir in diesem Buch eingeführt haben. Es handelt sich um die RAM-Disk in rd.c, das “Network Block Device” in nbd.c und das Loopback-Block-Gerät in loop.c. Letzteres wird dazu verwendet, Dateien so einzuhängen, als wären es Block-Geräte. (Siehe dazu die Man-Page von mount, wo die -o loop-Option beschrieben wird.) Das Network Block Device kann für den Zugriff auf entfernte Ressourcen als Block-Gerät verwendet werden (und ermöglicht so beispielsweise ein entferntes Swap-Gerät).

Andere Dateien in diesem Verzeichnis implementieren Treiber für bestimmte Hardware, darunter verschiedene Diskettenlaufwerke, den altmodischen x86-XT-Festplatten-Controller und einige weitere. Die wichtigsten Familien von Block-Treibern sind in separate Verzeichnisse verschoben worden.

drivers/ide

Die Familie der IDE-Gerätetreiber befand sich früher in drivers/block, ist aber so gewachsen, daß sie in ein eigenes Verzeichnis verschoben wurde. Die IDE-Schnittstelle ist mit der Zeit immer mehr erweitert und verbessert worden, um mehr als nur konventionelle Festplatten zu unterstützen. Beispielsweise werden inzwischen auch IDE-Bandlaufwerke unterstützt.

Das Verzeichnis drivers/ide ist eine Welt für sich, mit ein wenig allgemeinem Code und einer eigenen Programmierschnittstelle. Sie werden bemerken, daß einige Dateien in diesem Verzeichnis nur einige wenige Kilobytes lang sind. Diese enthalten nur den Code zur Erkennung des IDE-Controllers und verwenden dann den verallgemeinerten IDE-Treiber für alles andere — ein interessanter Lesestoff, wenn Sie an IDE-Treibern interessiert sind.

drivers/md

In diesem Verzeichnis geht es um die RAID-Funktionalität und die Abstraktion des Logical Volume Managers. Der Code registriert seine eigenen Major-Nummern für Zeichen- und Block-Treiber, kann also als Treiber wie die traditionellen Treiber angesehen werden. Trotzdem wird der Code davon getrennt gehalten, weil er nichts mit direktem Hardware-Zugriff zu tun hat.

drivers/cdrom

Dieses Verzeichnis enthält die generische CD-ROM-Schnittstelle. Sowohl die IDE- als auch die SCSI-cdrom-Treiber benutzen drivers/cdrom/cdrom.c für einen Teil ihrer Funktionalität. Die Haupteinsprungpunkte in der Datei sind register_cdrom und unregister_cdrom; der Aufrufer übergibt diesen Funktionen einen Zeiger auf eine struct cdrom_device_info, das wichtigste Objekt in der CD-ROM-Verwaltung.

Andere Dateien in diesem Verzeichnis kümmern sich um bestimmte Hardware-Laufwerke, die weder IDE noch SCSI verwenden. Diese Geräte sind heutzutage reichlich selten, weil sie in Anbetracht moderner IDE-Controller als veraltet angesehen werden können.

drivers/scsi

Alles rund um den SCSI-Bus befindet sich traditionell in diesem Verzeichnis. Dazu gehören die Controller-unabhängige Unterstützung für bestimmte Geräte (wie Festplatten und Bandlaufwerke) sowie Treiber für bestimmte SCSI-Controller.

Die Verwaltung der SCSI-Schnittstelle ist über mehrere Dateien verteilt: scsi.c, hosts.c, scsi_ioctl.c und ein Dutzend weitere. Wenn Sie an der gesamten Liste interessiert sind, schauen Sie besser in das Makefile, wo scsi_mod-objs definiert ist. Alle öffentlichen Einsprungpunkte in diese Dateiengruppe sind in scsi_syms.c zusammengefaßt.

Code, der eine bestimmte Art von Hardware-Laufwerken unterstützt, wird über den Aufruf von scsi_register_module mit dem Argument MODULE_SCSI_DEV in das SCSI-System eingebunden. So werden die Festplattenunterstützung von sd.c, die CD-ROM-Unterstützung von sr.c (die intern wiederum die cdrom_-Funktionen verwendet), die Bandlaufwerk-Unterstützung von st.c und die generischen Geräte von sg.c implementiert.

Der “generische” Treiber wird verwendet, um User-Space-Programmen direkten Zugriff auf SCSI-Geräte zu geben. Das zugrundeliegende Gerät kann so ziemlich alles sein; sowohl CD-Brenner als auch Scanner verwenden das generische SCSI-Gerät, um auf die angesteuerte Hardware zuzugreifen. Durch Öffnen der /dev/sg-Geräte kann ein User-Space-Treiber alles Notwendige selbst machen, ohne Unterstützung vom Kernel zu benötigen.

Host-Adapter (also die SCSI-Controller-Hardware) können durch den Aufruf von scsi_register_module mit dem Argument MODULE_SCSI_HA in das Kern-System eingebaut werden. Die meisten Treiber tun das einfach durch die in scsi_module.c bereitgestellte Registrierungsfähigkeit: Die Quelldatei des Treibers definiert ihre statischen Datenstrukturen und bindet dann scsi_module.c ein. Diese Datei definiert Standard-Initialisierungs- und Aufräum-Funktionen, basierend auf <linux/init.h> und dem Mechanismus der init-Aufrufe. Diese Technik erlaubt es Treibern, ganz ohne #ifdefs entweder als Module oder als einkompilierte Funktionen verwendet zu werden.

Interessanterweise ist einer der in drivers/scsi unterstützten Host-Adapter der Code für die IDE-SCSI-Emulation, ein Software-Host-Adapter, der auf IDE-Geräte abbildet. Dieser wird zum Beispiel für das CD-Mastering verwendet: Das System sieht alle Laufwerke als SCSI-Geräte, und das User-Space-Programm muß nichts als SCSI verstehen.

Beachten Sie bitte, daß mehrere SCSI-Treiber in Linux von den Herstellern zur Verfügung gestellt wurden und nicht aus Ihrer bevorzugten Hacker-Gemeinde stammen; daher sind nicht alle besonders amüsant zu lesen.

drivers/net

Wie Sie vielleicht erwarten, befinden sich in diesem Verzeichnis die meisten Schnittstellen-Adapter. Im Gegensatz zu drivers/scsi enthält dieses Verzeichnis nicht die Kommunikationsprotokolle selbst. Diese liegen in net im Top-Level-Verzeichnis. Trotzdem ist in drivers/net ein Stückchen Software-Abstraktion zu finden, insbesondere die Implementation der verschiedenen Line Disciplines, die bei der Netzwerk-Kommunikation über serielle Leitungen verwendet werden.

Die Line Discipline ist die Software-Schicht, die für die Daten zuständig ist, die über die Kommunikationsleitung übertragen werden. Jedes TTY-Gerät hat eine zugehörige Line Discipline. Jede Line Discipline wird durch eine Nummer identifiziert, die wie üblich als symbolischer Name angegeben wird. Die Default-Line Discipline in Linux ist N_TTY, damit sind die normalen TTY-Verwaltungsroutinen als drivers/char/n_tty.c gemeint.

Bei PPP, SLIP oder anderen Kommunikationsprotokollen muß die Default-Line Discipline aber ersetzt werden. User-Space-Programme ändern die Line Discipline in N_PPP oder N_SLIP. Wenn das Gerät abschließend geschlossen wird, wird der Default wieder eingesetzt. Genau deswegen beenden sich pppd und slattach auch nicht nach dem Einrichten der Verbindung: Sobald sie sich beenden würden, würde das Gerät geschlossen und die Default-Line Discipline restauriert werden.

Die Aufgabe der Initialisierung von Netzwerk-Treibern ist noch nicht auf den init-Aufruf-Mechanismus übergegangen, weil es einige subtile technische Details gibt, die das verhindern. Die Initialisierung geschieht daher immer noch auf die alte Art und Weise: Die Datei Space.c führt die Initialisierung durch, indem sie eine Liste mit bekannter Hardware und Suchen nach den jeweiligen Geräten durchsucht. Die Liste wird durch #ifdef-Anweisungen gesteuert, die bestimmen, welche Geräte überhaupt einkompiliert sind.

drivers/sound

Wie drivers/scsi und drivers/net enthält dieses Verzeichnis alle Treiber für Soundkarten. Der Inhalt des Verzeichnisses ähnelt dem des SCSI-Verzeichnisses: Einige wenige Dateien bilden den Kern des Sound-Systems; individuelle Gerätetreiber bauen darauf auf. Das Kern-Sound-System kümmert sich darum, die Major-Nummer SOUND_MAJOR anzufordern und alle Aufrufe an die zugrundeliegenden Gerätetreiber weiterzuleiten. Ein Hardware-Treiber meldet sich beim Kern-System an, indem er die in dev_table.c definierte Funktion sound_install_audiodrv aufruft.

Die Liste der geräteunabhängigen Dateien in diesem Verzeichnis ist ziemlich lang, weil sie auch die generische Unterstützung für Mixer, Sequencer usw. enthält. Wenn Sie darin weiterforschen wollen, sollten Sie mit dem Makefile anfangen, um zu sehen, was was ist.

drivers/video

Hier finden Sie alle Framebuffer-Video-Geräte. Das Verzeichnis kümmert sich um die Video-Ausgabe, nicht um die Video-Eingabe. Wie in drivers/sound implementiert auch hier das gesamte Verzeichnis einen einzigen Zeichen-Gerätetreiber; ein Kern-Framebuffer-System leitet die Zugriffe auf die diversen auf dem Computer jeweils verfügbaren Framebuffer weiter.

Der Einsprungpunkt in /dev/fb-Geräte befindet sich in fbmem.c. Die Datei registriert die Major-Nummer und pflegt eine interne Liste, welches Framebuffer-Gerät für welche Minor-Nummer zuständig ist. Ein Hardware-Treiber registriert sich selbst durch Aufrufen von register_framebuffer, wobei ein Zeiger auf eine struct fb_info übergeben wird. Diese Datenstruktur enthält alles, was zur Verwaltung der Geräte notwendig ist, darunter die Methoden open und release, aber keine read-, write- und mmap-Methoden; diese werden verallgemeinert in fbmem.c selbst implementiert.

Neben dem Framebuffer-Speicher kümmert sich dieses Verzeichnis auch um Framebuffer-Konsolen. Weil das Layout der Pixel im Framebuffer zu einem gewissen Grad standardisiert ist, konnten die Kernel-Entwickler eine generische Konsolen-Unterstützung für diverse Layouts von Video-Speicher implementieren. Sobald ein Hardware-Treiber seine eigene struct fb_info registriert, bekommt er automatisch eine Text-Konsole zugewiesen, die dem deklarierten Layout des Video-Speichers entspricht.

Leider gibt es in diesem Bereich keine wirkliche Standardisierung, so daß der Kernel derzeit 17 unterschiedliche Bildschirm-Layouts unterstützt, die von den ziemlich gängigen 16-Bit- und 32-Bit-Farb-Displays bis zu den haarigen Pixel-Plazierungen unter VGA und auf dem Mac reichen. Die Dateien, die Text in Framebuffer schreiben, heißen fbcon-name.c.

Wenn das erste Framebuffer-Gerät registriert wird, ruft die Funktion register_framebuffer take_over_console auf (was von drivers/char/console.c exportiert wird), um den aktuellen Framebuffer als System-Konsole einzurichten. Beim Booten, also vor der Initialisierung der Framebuffer, ist die Konsole entweder der native Textbildschirm oder, wenn es einen solchen nicht gibt, die erste serielle Schnittstelle. Die Kommandozeile, die den Kernel startet, kann den Default natürlich überschreiben, indem sie ein bestimmtes Konsolen-Gerät auswählt. Die Kernel-Entwickler haben take_over_console geschrieben, um Framebuffer-Konsolen unterstützen zu können, ohne den Boot-Code zu verkomplizieren. (Framebuffer-Treiber benötigen normalerweise PCI- oder eine andere Unterstützung und können daher nicht zu früh im Boot-Vorgang aktiv sein.) take_over_console ist aber nicht auf Framebuffer beschränkt, sondern steht jedem Code für jede Hardware zur Verfügung. Wenn Sie Kernel-Meldungen über einen Morse-Telegraphen oder UDP-Netzwerkpakete verschicken wollen, dann können Sie das tun, indem Sie take_over_console von Ihrem Kernel-Modul aus aufrufen.

drivers/input

Die Eingabeverwaltung ist eine weitere Funktionalität, die dazu gedacht ist, Aktivitäten, die mehreren Treibern gemein sind, zu vereinfachen und zu standardisieren. Die zentrale Datei hier heißt input.c. Sie registriert sich selbst als Zeichen-Treiber mit der Major-Nummer INPUT_MAJOR. Ihre Aufgabe besteht darin, Ereignisse von den Gerätetreibern zu sammeln und diese Ereignisse an die höheren Schichten weiterzuleiten.

Die Eingabe-Schnittstelle wird in <linux/input.h> definiert. Alle Treiber registrieren sich selbst durch Aufruf von input_register_device. Nach der Registrierung können Benutzer durch Aufrufen von input_event neue Ereignisse in das System einspeisen.

Module höherer Ebene können sich bei input.c registrieren, indem sie input_register_handler aufrufen und die Art von Ereignissen angeben, an denen sie interessiert sind. Auf diese Weise meldet beispielsweise keybdev.c sein Interesse an Tastaturereignissen an (die in dieser Datei am Ende dann an driver/char/keyboard.c weitergeleitet werden).

Ein Modul höherer Ebene kann auch eigene Minor-Nummern registrieren, um eigene Datei-Operationen zu verwenden und der Eigentümer einer Eingabe-Gerätedatei in /dev zu werden. Derzeit ist es aber für Dritt-Module nicht leicht, Minor-Nummern zu registrieren, weswegen dieses Feature derzeit nur von den Dateien in drivers/input verläßlich verwendet werden kann. Minor-Nummern werden derzeit zur Unterstützung von Mäusen, Joysticks und generischen Ereigniskanälen im User-Space verwendet.

drivers/media

Dieses Verzeichnis wurde mit der Version 2.4.0-test7 eingeführt und faßt diverse Kommunikationsmedien zusammen; derzeit handelt es sich dabei um Radio- und Video-Eingabe. Sowohl die media/radio- als auch die media/video-Treiber bauen auf der Datei video/videodev.c auf, die wiederum die “Video For Linux”-API implementiert.

video/videodev.c ist ein generischer Container. Er fordert eine Major-Nummer an und stellt diese den Hardware-Treibern zur Verfügung. Die einzelnen Treiber niedrigerer Ebene registrieren sich durch Aufruf von video_register_device. Sie übergeben dabei einen Zeiger auf ihre eigene struct video_device sowie einen Integer-Wert, der den Typ des Geräts angibt. Derzeit unterstützt werden Framegrabber (VFL_TYPE_GRABBER), Radios (VFL_TYPE_RADIO), Teletext-Geräte (VFL_TYPE_VTX) sowie undecodierte Informationen in der vertikalen Austastlücke (VFL_TYPE_VBI).

Bus-spezifische Verzeichnisse

Einige der Unterverzeichnisse im Verzeichnis drivers werden nur für Geräte verwendet, die an eine bestimmte Bus-Architektur angeschlossen werden. Diese sind von den generischen Verzeichnissen char und block getrennt worden, weil ein recht großer Teil des Codes Bus-Architektur-spezifisch (und nicht gerätespezifisch) ist.

Das Unterverzeichnis mit den wenigsten Einträgen ist drivers/pci. Es enthält nur den Code, der mit den PCI-Controllern (oder dem System-BIOS) kommuniziert, wohingegen die PCI-Hardware-Treiber über den ganzen Kernel verteilt sind. Der PCI-Bus ist so weit verbreitet, daß es nicht sinnvoll ist, alle PCI-Karten an einer Stelle zu sammeln.

Falls Sie sich fragen, ob es ein spezielles Verzeichnis für ISA gibt, dann lautet die Antwort nein. Es gibt keine ISA-spezifischen Hilfsdateien, weil der Bus keine Ressourcen-Verwaltung oder Standardisierung kennt, auf der man eine Software-Schicht aufbauen könnte. ISA-Hardware-Treiber passen am besten nach drivers/char, drivers/sound oder in ein ähnliches Verzeichnis.

Die anderen Bus-spezifischen Verzeichnisse enthalten alles von weniger bekannten internen Computer-Bussen bis hin zu weit verbreiteten externen Schnittstellen-Standards.

Zu den ersteren gehören drivers/sbus, drivers/nubus, drivers/zorro (der in Amiga-Computern verwendete Bus), drivers/dio (der Bus der HP300-Computer) und drivers/tc (Turbo Channel, verwendet in MIPS DECstations). Während sbus sowohl SBus-Hilfsfunktionen als auch Treiber für einige SBus-Geräte enthalten, enthält die anderen nur Hilfsfunktionen. Hardware-Treiber auf der Basis aller dieser Busse finden Sie in drivers/net, drivers/scsi, oder welches Verzeichnis auch immer auf die jeweilige Hardware paßt. Einige wenige dieser Busse werden derzeit sogar nur von einem einzigen Treiber verwendet.

Zu den Verzeichnissen für externe Busse gehören drivers/usb, drivers/pcmcia, drivers/parport (generische Cross-Plattform-Unterstützung für den Parallel-Port, definiert eine ganz neue Klasse von Gerätetreibern), drivers/isdn (alle von Linux unterstützten ISDN-Controller und deren gemeinsame Hilfsfunktionen), drivers/atm (desgleichen für ATM-Netzwerk-Verbindungen) sowie drivers/ieee1394 (FireWire).

Plattform-spezifische Verzeichnisse

Manche Computer-Plattformen haben einen eigenen Verzeichnisbaum in der drivers-Hierarchie. Solche Plattform-spezifischen Verzeichnisbäume findet man immer dann, wenn die Kernel-Entwicklung für eine Plattform eine Zeitlang neben dem Haupt-Quellbaum hergelaufen ist, ohne mit diesem wieder synchronisiert worden zu sein. In diesen Fällen helfen die separaten Verzeichnisbäume bei der Pflege. Dazu gehören beispielsweise drivers/acorn (alte ARM-basierte Computer), drivers/macintosh, drivers/sgi (Silicon Graphics-Workstations) und drivers/s390 (IBM-Mainframes). Es lohnt sich nicht sehr, sich diesen Code anzuschauen, sofern Sie nicht an einer dieser Plattformen interessiert sind.

Andere Unterverzeichnisse

Es gibt in drivers noch andere Unterverzeichnisse, die aber unserer Meinung nach sehr spezifisch und nicht allgemein interessant sind. drivers/mtd implementiert eine Memory Technology Device-Schicht, mit der Solid State-Festplatten (Flash-Speicher und andere Arten von EEPROMs) angesteuert werden können. drivers/i2c enthält eine Implementation des i2c-Protokolls. i2c ist der “Inter Integrated Circuit”, ein zweidrahtiger Bus, der intern von mehreren modernen Peripherie-Geräten verwendet wird, besonders von Framebuffern. drivers/i2o kümmert sich entsprechend um I2O-Geräte (ein proprietärer Hochgeschwindigkeitskommunikationsstandard für bestimmte PCI-Geräte, der unter Druck der Bewegung für freie Software veröffentlicht worden ist). drivers/pnp ist eine Ansammlung von allgemeinem ISA-Plug-and-Play-Code aus diversen Treibern, aber glücklicherweise verwenden die meisten Hersteller den PnP-Hack heutzutage nicht mehr.

Unter drivers/ finden Sie auch die Anfänge der Unterstützung neuer Geräte-Klassen, die derzeit nur in sehr wenigen Geräten zu finden sind.

Dies ist der Fall mit der Fiber Channel-Unterstützung (drivers/fc4) und mit drivers/telephony. Es gibt sogar ein leeres Verzeichnis namens drivers/misc, das für “diverse Geräte, die nirgendwo anders hinpassen” gedacht ist. Der Verzeichnis enthält keinen Code, aber ein leeres Makefile, das das gerade genannte Zitat im englischen Original als Kommentar enthält.

Der Linux-Kernel ist so riesig, daß es unmöglich ist, alles auf einigen wenigen Seiten zu behandeln. Außerdem verändert er sich ständig, und immer, wenn man denkt, daß man fertig ist, haben die Hacker schon wieder einen Patch veröffentlicht, der viel neues Material enthält. Es kann gut sein, daß das misc-Verzeichnis in 2.4 nicht mehr leer ist, wenn Sie dies lesen.

Obwohl wir das nicht für wahrscheinlich halten, kann es doch sein, daß die Kernel-Versionen 2.6 oder 3.0 deutlich anders als 2.4 sein wird; leider aktualisiert sich die Auflage dieses Buches nicht automatisch, um neue Versionen zu behandeln, so daß es mit der Zeit veralten wird. Obwohl wir uns sowohl in diesem Kapitel als auch im Rest des Buches bemüht haben, die aktuelle Kernel-Version zu behandeln, gibt es doch keinen Ersatz für das direkte Lesen des Quellcodes.