Bei der Entwicklung des Linux-Kernels spielen sich wahre Dramen ab, das zeigt die Historie der IDE-Schicht am besten. Deutlich wird hier aber auch, wie die Community schwere Krisen bewältigt.

IDE, Kürzel für Integrated Driver Electronics, ist jenes Protokoll, das für die Flachbandkabel von der Festplatte zum Mainboard gilt. Wer also kein SCSI- oder Diskless-System betreibt, kann ohne funktionierende IDE-Schicht mit seinem Rechner gar nichts anfangen. Umso erstaunlicher, dass gerade die Entwicklung dieser wichtigen Treiberschicht mehrfach auf Messer Schneide stand.

Die IDE-Schicht - von Natur aus schwierig

IDE ist nicht irgendein ganz normaler Treiber oder Standard. Das ursprüngliche Design definierte Compaq Mitte der 80er Jahre, seitdem hat sich daraus ein Gemisch aus unterschiedlichen anderen Standards und herstellerspezifischen Variationen entwickelt, die den Support zum Alptraum machen. Bis zur Mitte der 90er Jahre hatte Mark Lord bei der IDE-Treiberentwicklung den Hut auf, letztlich eine Sisyphosarbeit.

IDE-Treiber gehören zu den ersten Verdächtigen, wenn bei irgendeinem Nutzer Daten beschädigt werden. Aus diesem Grunde analysierten Mark und sein Team unzählige Reports über verlorene Daten: Sie führten die meisten Ausfälle auf Hardwarefehler zurück, gelegentlich auch auf Bugs im Kernel, manchmal aber tatsächlich auf die IDE-Schicht selbst. Die Treiber verbesserten sich, aber die Reports wurden nicht weniger, für kaputte Dateisysteme gibt es viele Ursachen. Oft schob man der IDE-Schicht so lange die Schuld zu, bis die wahre Ursache offen lag. Dagegen ließ sich kaum etwas tun.

Im Sommer 1998 kam es dann zum Eklat. Der Kernel steckte tief in der 2.1-Entwicklungsphase, auf dem Weg zu 2.2, und immer wieder tauchten Meldungen über Beschädigungen von Festplatten bei angeschaltetem DMA-Support auf. Alan Cox ging Hinweisen nach, dass es nicht an diesem liegt, sondern an dem SMP-Code, also einer ganz anderen Baustelle. Damals war SMP-Unterstützung per Default aktiviert, vor allem weil Linus Torvalds selbst ein SMP-System benutzte. Das machte es schwer, Fehlerursachen einzugrenzen; deaktivierte SMP-Systeme zu Vergleichszwecken waren selten.

Linus weigerte sich SMP schon in 2.1 zu deaktivieren. Ihn frustrierte hingegen, dass Mark Lord den DMA-Support nicht per Default abschaltete. Mit einem einzeiligen Patch in Version 2.1.111 klemmte Linus schließlich DMA komplett ab, es gab nicht einmal eine Konfigurationsoption. Linus war sich zwar fast sicher, dass die Probleme nicht durch Marks Arbeit verursacht wurden, wollte aber mit dieser Aktion die "Angelegenheit aufs Radar bringen".

Damit hatte er den Bogen überspannt. Mark trat offiziell als Maintainer zurück, lieferte eine Zeit lang aber nach wie vor Patches, sogar das umstrittene zur Default-mäßigen DMA-Deaktivierung, das Linus so sehr wollte. In diesen Wochen des Interregnums begann Andre Hedricks Aufstieg zu einem der aktivsten IDE-Entwickler, was allerdings, wie sich zeigen sollte, das weitere Schicksal der IDE-Schicht nicht einfacher machte. Zunächst aber wurde Andre mit Kernelversion 2.1.122 IDE-Maintainer und leistete zusammen mit einer Handvoll anderer Leute, inklusive Mark Lord, jahrelang gute Arbeit.

Der Treiber unterstützte mehr und mehr Hardware und alle waren sich einig, dass Datenverlust durch schlechte Linux-Treiber das absolut Unakzeptable ist. Andre trat deshalb mit Hardwareherstellern und Standardisierungsgremien in Verbindung, unterzeichnete NDAs, die ihm Zugang zu vertraulichen Informationen über zukünftige Hardware erlaubten; aber er durfte sein Wissen nicht mit anderen Linux-Hackern teilen.

Geheimnisvolle Hardware

Trotz aller Fortschritte blieb der IDE-Code verwirrend, wurde sogar durch die zahlreichen, nun eigeflossenen Geheimnisse der Hardwarehersteller noch undurchschaubarer. Manches, was wie simpelste Aufräumarbeit aussah, wirkte sich verheerend auf das Gesamtsystem aus. Naive Einsteiger lasen die Spezifikationen, um besser zu verstehen, was vorging - nur um zu erfahren, dass diese oft völlig andere Intentionen haben, als der Text aussagt.

Ohne eine riesige Menge an Arbeit ließ sich nicht das kleinste Schräubchen bewegen, selbst wer diese Arbeit leistete, stieß oft auf ein Industriegeheimnis und alles war vergebens. Im Februar 2002 (Kernelversionen 2.4.17 und 2.5.3) wurde klar, dass nur Andre Hedrick und vielleicht noch zwei bis drei andere den Code verstehen konnten. Selbst sehr erfahrene Programmierer hatten keine Chance mehr. Zu dieser Zeit häuften sich erneut die Fehlerreports. Das motivierte zwar viele Entwickler, sich auf den IDE-Code zu stürzen, die meisten mussten aber hilflos akzeptieren, dass Andre ihre Patches zurückwies - das tat er gelegentlich auch, wenn sie laut Linus korrekt waren.

Manchen gelang es aber doch, nützlichen Code beizutragen, allen voran Marcin Dalecki. Er begann immer mehr Aufräum-Patches an Andre zu schicken, die tief in das System eingriffen. Andre fühlte sich bedrängt und verdächtigte Marcin sogar, einen Geheimplan zu verfolgen, zusammen mit der Wagniskapital-Firma, die ihn beschäftigte. Der Konflikt spitzte sich zu und Linus wurde zu einer Entscheidung gedrängt. Er stellte sich auf die Seite von Marcin und warf Andre Kritikunfähigkeit und bewusste Lügen über die Funktion mancher Patches vor. Schließlich machte Linus Marcin zum Maintainer.

Marcin schüttelte eine Menge hässlichen Code raus, musste sich aber den Vorwurf gefallen lassen, dass er ihn nicht immer durch besseren ersetzte. Die IDE-Schicht des 2.5er Entwicklungskernels büßte mehr und mehr Funktionalität ein und wurde immer instabiler. Die Entwicklergemeinde zeigte Nervosität. Schließlich landete Jens Axboe einen Befreiungsschlag in Form der Vorwärtsportierung der 2.4-Treiber auf 2.5. Daraufhin schöpften einige wieder Mut und das Entwicklungstempo zog an.

Abbildung 1: Zwischen den Kernelversionen 2.4.20 (unten) und 2.4.21-pre4 (oben) sind in der IDE-Schicht schon mit bloßem Auge deutliche Unterschiede zu sehen.

Bei der Entwicklung des Linux-Kernels spielen sich wahre Dramen ab, das zeigt die Historie der IDE-Schicht am besten. Deutlich wird hier aber auch, wie die Community schwere Krisen bewältigt.