Unterstützung durch KI: Wiederbelebung eines 25 Jahre alten Kern-Treibers mit Claude Code

Können Sie sich das vorstellen? Ein Linux-Kernel-Treiber aus vor 25 Jahren kann auf modernen Systemen praktisch nicht mehr laufen – aber ein Ingenieur hat ihn in zwei Nächten mit Hilfe des KI-Assistenten Claude Code wiederbelebt. Dieser Treiber diente einst alten Magnetbandgeräten und wurde nun modernisiert. Er lässt sich nicht nur auf der neuesten Linux-Version kompilieren, sondern kann auch problemlos mit echter Hardware kommunizieren. Ein großer Erfolg für die KI!

Hintergrund

Eine kurze Hintergrundinfo: Eines meiner Hobbys ist es, Menschen bei der Wiederherstellung von Daten aus alten Magnetbandkassetten zu helfen, beispielsweise aus QIC-80-Bändern. Diese Bänder waren in den 1990er Jahren sehr beliebt und dienten als Backupprodukt für Privatpersonen, kleine Unternehmen, BBS-Betreiber usw. Ich habe eine besondere Verbundenheit mit Magnetbandmedien; das Gefühl, diese Bänder in der Hand zu halten, macht den gesamten Prozess sehr angenehm, obwohl QIC-Bänder für ihre vielen Designfehler berüchtigt sind. Mit sorgfältiger Prüfung und entsprechender Überholung können die Daten auf diesen Bändern auch nach vielen Jahren vollständig wiederhergestellt werden.

Wenn jemand mir QIC-80-Bänder zur Datenwiederherstellung bringt, starte ich meinen alten PC-Arbeitsplatz, an den der entsprechende Magnetbandlaufwerk angeschlossen ist, und ein sehr altes Linux-System (CentOS 3.5). Ich nutze dieses alte System, weil nur hier der ftape-Treiber funktioniert, ein Kernel-Treiber, der für die Kommunikation mit dem Magnetbandlaufwerk erforderlich ist und die binären Inhalte des Bandes vollständig auslesen kann.

Dieser Magnetbandlaufwerk ist an den Diskettenlaufwerkcontroller der Mainboard angeschlossen. Dies ist eine clevere Kostensenkung: Hochwertige Magnetbänder benötigen normalerweise einen separaten SCSI-Anschluss, hier können Sie jedoch einfach den vorhandenen Diskettenlaufwerkanschluss nutzen, ohne zusätzliche Hardware zu kaufen. Darüber hinaus können Diskettenlaufwerk und Magnetbandlaufwerk die gleiche Datenleitung teilen! Natürlich hat dies den Nachteil, dass die Geschwindigkeit durch den Diskettenlaufwerkcontroller begrenzt ist, auf etwa 500 Kbps (beachten Sie, dies sind Kilobits, nicht Kilobytes).

Ein weiteres Problem ist, dass das Protokoll zur Kommunikation zwischen Diskettenlaufwerkcontroller und Magnetbandlaufwerk sehr unregelmäßig, nicht standardisiert und schlecht unterstützt ist. Dies ist eine echte "Hacker-Methode": Das Mainboard-BIOS ist gar nicht erst von der Existenz des Magnetbandlaufwerks informiert, und alle Steuerungen müssen von der Client-Software selbst übernommen werden, einschließlich der Bedienung der Hardware-E/A-Ports, der Zeitsteuerung und der Interrupts, damit der Diskettenlaufwerkcontroller die Befehle an den Magnetbandlaufwerk sendet.

Damals gab es nur wenige proprietäre Tools, die diese Magnetbandlaufwerke unter MS-DOS und Windows 3.x/9x bedienen konnten. Unter Linux war die Open-Source-Implementierung fast ausschließlich ftape. Natürlich können Sie auch die alten DOS/Windows-Tools nutzen, um die Bänder auszulesen, aber ftape hat den Vorteil, dass es die "rohen" binären Inhalte des Bandes direkt auslesen kann, unabhängig davon, welches proprietäre Programm die Daten ursprünglich geschrieben hat. Aus diesem Grund bevorzuge ich ftape, um die Bandinhalte zu exportieren: Zuerst lese ich die Binärdaten vollständig aus, bearbeite dann das proprietäre logische Format und extrahiere schließlich die Dateien.

Das Problem ist, dass der ftape-Treiber seit etwa 2000 nicht mehr gewartet wird und bald aus dem Linux-Kernel entfernt wurde. Deshalb muss ich jedes Mal, wenn ich mit diesen Bändern arbeite, ein sehr altes Linux-System nutzen. Es wäre toll, wenn ftape auf modernen Linux-Distributionen laufen würde – so könnte ich die alten Funktionen behalten und zugleich die Vorteile moderner Systeme nutzen.

Fragen an Claude Code

Vor einigen Wochen kam mir plötzlich der Gedanke, Claude Code eine einfache Anfrage zu stellen:

Dieses Repository enthält einen Linux-Kernel-Treiber, der für die Kommunikation mit einem alten Magnetbandlaufwerk dient, das an den Diskettenlaufwerkcontroller (FDC) des Mainboards angeschlossen ist. Leider wird dieser Treiber seit langem nicht mehr gewartet und kann nur auf einem Kernel der Version 2.4 kompiliert werden. Ich möchte ihn modernisieren, damit er auf der neuesten Kernel-Version gebaut werden kann.

Claude hat geantwortet, dass es mir helfen kann, diesen Linux-Kernel-Treiber für das alte Magnetbandlaufwerk zu modernisieren. Dies ist eine ziemlich umfangreiche Aufgabe, da der Code auf die API und die Konventionen des modernen Kernels angepasst werden muss.

Nach einigen Runden sogenannter "Kombinationsoptimierungen" und anderen von Claude genannten Operationen hatte ich plötzlich einen Kernel-Treiber, der sich fehlerfrei kompilieren ließ.

Dies liegt daran, dass Claude die Ausgabe des Compilers lesen und bis zur erfolgreichen Kompilierung in die eigene Verarbeitung einfließen lassen kann.

Seit der Kernel-Version 2.4 bis zur Version 6.8 wurden viele Kernel-Funktionen und -Strukturen deprecated oder ersetzt.

Überraschenderweise hat Claude alle veralteten Teile gefunden und durch die richtigen modernen Äquivalente ersetzt, wobei nur geringfügige manuelle Anpassungen an einigen Teilen des Codes erforderlich waren (die ich später genauer beschreiben werde).

Allerdings musste der Kernel-Treiber weiterhin als Teil des gesamten Kernelbaums kompiliert werden, während ich ihn gerne als eigenständiges, ladbares Kernelmodul hätte. Also fragte ich:

Gibt es eine Möglichkeit, dieses Modul direkt vor Ort zu kompilieren, ohne es in den Kernel-Quellcodebaum zu kopieren?

Claude hat geantwortet: Ja! Sie können Kernelmodule außerhalb des Kernel-Quellcodebaums kompilieren, ohne sie in den Quellcode zu kopieren. Ich erstelle für Sie ein eigenständiges Build-System für den ftape-Treiber.

… und tatsächlich hat es das geschafft, ohne dass ich weitere Hinweise geben musste.

Am Ende dieser Phase hatte ich ein ladbares Kernelmodul (.ko-Datei), das ich auf echter Hardware testen konnte. Kein Wunder, dass das Modul noch nicht vollständig funktionierte – es ließ sich laden, aber es konnte nicht richtig mit dem Magnetbandlaufwerk kommunizieren.

Aber ich gab nicht auf.

Ab diesem Punkt konnte ich Claude nicht mehr die sensiblen Vorgänge des Laden/Entladens von Kernelmodulen überlassen, da hierfür sudo-Berechtigungen erforderlich sind.

Glücklicherweise enthält der ftape-Treiber bereits viele Logmeldungen (printk()-Aufrufe, die in dmesg erscheinen). Also habe ich das Modul selbst geladen und die dmesg-Ausgabe manuell an Claude übermittelt, damit es sie mit den zuvor gespeicherten, "bekannt guten" dmesg-Logs beim erfolgreichen Auslesen eines Bandes vergleichen konnte. Nach einigen Runden dieser Iterationen hat Claude die verbleibenden Probleme gefunden, die die Kommunikation des Moduls mit der Hardware verhinderten.

Perfekt! Dieses Modul hat einige einstellbare Parameter. Das Problem ist, dass alle Basisadressen standardmäßig auf -1 gesetzt werden, wenn keine Konfiguration vorgenommen wird. In der Konfigurationsfunktion wird dieser Wert in 0xffff umgewandelt, was zu einem Fehlschlag der Erkennung führt.

Der Grund für den Fehler "No such device or address" (ENXIO) ist, dass das ftape-internal-Modul den Diskettenlaufwerkcontroller nicht mit der richtigen I/O-Port-Basisadresse konfiguriert hat. Das Problem liegt in den Zeilen 735–737 von fdc-internal.c: Wenn fdc->sra == 0xffff, gibt die Funktion -ENXIO zurück. Da keine Konfiguration vorgenommen wurde, werden alle Werte standardmäßig auf -1 gesetzt, was dann 0xffff wird …

Schließlich habe ich ein Kernelmodul, das folgende Dinge kann:

a) Es lässt sich laden;

b) Es erkennt das Magnetbandlaufwerk;

c) Es kann den Inhalt eines Testbandes exportieren!

Erfahrungen

Das funktionieren lassen des ftape-Treibers auf einem modernen Kernel – eine Aufgabe, die einmal völlig unmöglich schien – wurde in nur zwei Nächten erledigt.

GitHub-Adresse: https://github.com/dbrant/ftape

Es muss betont werden, dass ich selbst einige Grundkenntnisse über Kernelmodule habe und mich gut mit der Programmiersprache C auskenne. Deshalb möchte ich die Rolle von Claude in diesem Szenario nicht übertrieben darstellen.

Das heißt, es war nicht so, dass ich Claude mit drei Anweisungen ein funktionsfähiges Kernelmodul ausgeben ließ. Es gab vielmehr mehrere Runden von Kommunikation und einige manuelle Code-Korrekturen. Ohne ein grundlegendes Verständnis der internen Mechanismen von Kernelmodulen wäre diese Modernisierung überhaupt nicht möglich gewesen.

Dies hat mir einige Erkenntnisse über die Verwendung solcher Codier-Assistenten gebracht:

1. Betrachten Sie es wirklich als Kooperationspartner

Das Interagieren mit Claude Code fühlt sich an wie die Zusammenarbeit mit einem anderen Ingenieur. Manche vergleichen es mit einem "Junior-Ingenieur", und ich finde, das stimmt grob: Es macht sein Bestes, um Ihren Anweisungen zu folgen, kooperiert aktiv, ist manchmal zu selbstbewusst, aber entschuldigt sich schnell, wenn es einen Fehler macht, und nennt Sie "absolut richtig".

Deshalb müssen Menschen weiterhin als "Schranken" fungieren, Produktentscheidungen treffen, sich an Architekturrichtlinien halten und potenzielle Probleme frühzeitig erkennen.

2. Seien Sie so konkret wie möglich und verwenden Sie domainrelevante Schlüsselwörter

Ich möchte nicht behaupten, dass ich plötzlich ein Prompt-Engineer bin, aber ich habe festgestellt, dass die effektivsten Hinweise so aussehen: Beschreiben Sie zuerst die "Sprachstruktur" der Funktion und weisen Sie dann die Lücken in dieser Struktur aus, damit das Modell diese ergänzen kann.

3. Entwickeln Sie ein Gefühl für die Arten von Aufgaben, die gut an das Modell zu übergeben sind

Diese großen Modelle sind nicht allmächtig. Wenn Sie ihnen etwas zu tun geben, was sie nicht gut können, werden Sie frustriert sein und womöglich auf sie verzichten, bevor sie ihre Fähigkeiten zeigen können. In dieser Hinsicht ist es hilfreich, zu verstehen, wie LLMs funktionieren, damit Sie besser einschätzen können, was ihre Stärken und Schwächen sind.

4. Nutzen Sie es als Multiplikator für Ihre eigenen Fähigkeiten

Theoretisch hätte ich diese Modernisierung auch alleine durchführen können, aber das hätte bedeutet, dass ich die Kernel-Entwicklungsmethoden aus vor 25 Jahren lernen und wochenlang in veraltete Dokumentation schauen müsste. Stattdessen habe ich ein paar Tage damit verbracht, mit dem Assistenten zu kommunizieren und ihm von jedem Schritt erklären zu lassen.

Natürlich habe ich die von ihm vorgenommenen Änderungen verifiziert und getestet und dabei auch viel praktisch Nützliches gelernt, wie z. B. moderne Kernel-Spezifikationen, Details der x86-Architektur und einige Tipps für die Kommandozeilenbedienung, die ich nun regelmäßig einsetzen werde.

5. Nutzen Sie es, um schnell in neue Frameworks einzusteigen

Ich bin kein Kernel-Entwickler, aber diese Erfahrung hat mein Interesse an der Kernel-Entwicklung geweckt. Tatsächlich ist die Kernel-Entwicklung nicht so schwierig, wie man denkt. In einer anderen "vibe coding"-Situation habe ich sogar eine Flutter-Anwendung entwickelt, ohne jemals zuvor mit Flutter gearbeitet zu haben. Wenn Sie wie ich gerne beim Tun lernen, können diese Tools Ihre Lernkurve für neue Frameworks stark verkürzen und Ihnen mehr Zeit für die Architekturplanung geben.

Zusammenfassung

Zusammenfassend kann ich nun mit Freude sagen, dass ftape wieder lebt! 25 Jahre nach seiner letzten offiziellen Veröffentlichung lässt es sich endlich auf modernem Linux kompilieren und nutzen. Ich mache noch einige weitere Anpassungen und füge neue Funktionen hinzu, aber ich habe bereits bestätigt, dass es funktioniert, sowohl mit meinem Disketten-Magnetbandlaufwerk als auch mit dem von ihm unterstützten Parallelanschlusslaufwerk.

Die physische Gerätekonfiguration sieht fast gleich aus, aber das Betriebssystem ist jetzt Xubuntu 24.04 statt des früheren CentOS 3.5!

Original-Artikel: https://dmitrybrant.com/2025/09/07/using-claude-code-to-modernize-a-25-year-old-kernel-driver

Dieser Artikel stammt aus dem WeChat-Account "CSDN", vom Autor Dmitry Brant, und wurde von 36Kr mit Genehmigung veröffentlicht.