Einen 25 Jahre alten Kernel-Treiber mit Claude Code modernisieren

• Der ftape-Treiber ist der einzige Linux-Open-Source-Kernel-Treiber, mit dem sich Daten von Backup-Bändern aus den 1990er-Jahren (QIC-80) wiederherstellen lassen.
• Allerdings wurde der Treiber seit etwa 2000 nicht mehr gewartet und ließ sich daher nur noch in alten Linux-Umgebungen verwenden.
• Mithilfe von Claude Code wurde der alte Quellcode so refaktoriert, dass er zum aktuellen Linux-Kernel passt, und erfolgreich in ein eigenständiges Kernel-Modul umgewandelt.
• Dabei wandelte Claude automatisch veraltete Funktionen und Strukturen in moderne APIs um, während der Nutzer die Ausgaben manuell analysierte und einige Konfigurationsfehler korrigierte.
• Die Arbeit mit dem AI-Coding-Agenten lieferte Einblicke in die Verstärkung der Fähigkeiten von Programmierern und darin, wie man sich schnell in neue Technologien und Frameworks einarbeitet.

---

Hintergrund: Wiederherstellung alter Backup-Bänder und der ftape-Treiber

• Das Wiederherstellen von Daten aus Bandkassetten wie QIC-80 ist eines der Hobbys des Autors.
• Für diese Bänder wird meist ein spezielles Bandlaufwerk benötigt, das an einen Floppy-Controller angeschlossen ist.
  • Solche Laufwerke wurden in den 1990er-Jahren vor allem von kleinen Unternehmen oder Privatpersonen für Backups verwendet.
  • Die Nutzung des Floppy-Controllers war eine günstige Lösung ohne separaten SCSI-Adapter, hatte aber mehrere Nachteile wie Geschwindigkeitsbegrenzungen (500 Kbps) und ein nicht standardisiertes Protokoll.
• Um mit diesen Bandgeräten zu kommunizieren, ist unter Linux der ftape-Kernel-Treiber unverzichtbar.
  • Nur mit ftape lassen sich die reinen rohen Binärdaten lesen, was für die Wiederherstellung zwingend erforderlich ist.
• Da der ftape-Treiber jedoch seit etwa 2000 nicht mehr gepflegt wurde, ließ er sich auf modernen Linux-Kernels nicht mehr verwenden.
  • Daher musste zum Wiederherstellen der Daten jedes Mal ein veraltetes Linux-System (z. B. CentOS 3.5) direkt gebootet werden.

Beginn der Modernisierung des Kernel-Treibers mit Claude Code

• Claude Code wurde zusammen mit einer Beschreibung des Repositorys gebeten, den Treiber so zu modernisieren, dass er auf aktuellen Kernels gebaut werden kann.
• Claude identifizierte und ersetzte veraltete Funktionen und Strukturen passend zu den aktuellen Kernel-APIs und -Strukturen.
  • Nach mehreren Feedback-Runden und manuellen Korrekturen entstand Treibercode, der fehlerfrei kompiliert.
• Der ursprüngliche Code ließ sich anfangs nur innerhalb des gesamten Kernel-Source-Trees bauen, doch auf zusätzliche Anfrage wurde automatisch ein eigenständiges Build-System für externe Module erzeugt.
  • Dadurch konnte das Kernel-Modul separat als .ko-Datei gebaut werden, woraufhin die Tests mit angeschlossener echter Hardware begannen.

Der Weg zur Problemlösung

• Das Kernel-Modul wurde zwar korrekt geladen, doch es traten Probleme bei Laufwerkserkennung und Kommunikation auf.
  • Da für die Arbeiten sudo-Rechte nötig waren, konnte Claude die wiederholte Ausführung nicht selbst übernehmen; stattdessen wurden dmesg-Logs manuell weitergegeben, um die Ursache nachzuverfolgen.
• Durch den Vergleich der Logs mit früheren erfolgreichen Fällen fand Claude Fehler bei einer nicht gesetzten Standard-I/O-Port-Adresse sowie bei der Initialisierung von Parametern.
  • Ein Standardwert wurde von -1 in 0xffff umgewandelt, wodurch die Erkennung scheiterte; nach dem Zurücksetzen auf die korrekte Adresse war das Problem behoben.
• Am Ende wurde das Modul korrekt geladen, und ein Daten-Dump von einem Testband gelang erfolgreich.

Erkenntnisse aus der Zusammenarbeit mit einem AI-Coding-Agenten

• Die Interaktion mit Claude Code fühlte sich an wie die „Zusammenarbeit mit einem Junior-Entwickler“ und damit wie echte Arbeit mit einem Ingenieur.
  • Der Nutzer muss Architekturentscheidungen, Problemerkennung und die Richtung weiterhin selbst aktiv vorgeben.
• Je konkreter die Anfrage und je stärker sie domänenspezifische Schlüsselwörter enthält, desto wirksamer ist der Einsatz.
• Die Produktivität eines AI-Agenten steigt stark an, wenn er Aufgaben des passenden Typs erhält; dafür braucht es ein Gefühl für Grenzen und Stärken.
• Die eigene Leistungsfähigkeit wurde durch die AI vervielfacht. Eine Aufgabe, die manuell mehrere Wochen gedauert hätte, konnte mit alltäglichen Gesprächen und Feedback in wenigen Tagen abgeschlossen werden.
  • Dabei wurden auch praktisch nützliche Fähigkeiten wie moderne Praktiken der Kernel-Entwicklung, x86-Architektur und neue Command-Line-Tools gelernt.
• Besonders hervorgehoben wird, dass sich die erste Einarbeitung und Anpassung an neue Frameworks (Rust, Flutter usw.) dadurch massiv beschleunigen lässt.

Fazit: ftape lebt wieder

• Nach 25 Jahren lässt sich ftape wieder unter aktuellem Linux bauen und verwenden.
• Der Autor arbeitet weiter an zusätzlichen Verbesserungen und Tests und hat neben Floppy-basierten Laufwerken auch Unterstützung für parallelportbasierte Geräte bestätigt.
• Die physische Hardware ist nahezu dieselbe wie früher, doch das Betriebssystem hat sich von CentOS 3.5 zu Xubuntu 24.04 gewandelt.

Referenz

• Der Quellcode des ftape-Projekts ist auf GitHub veröffentlicht.
• Weitere Informationen, etwa zur Liste der gesammelten Geräte des Autors, finden sich im persönlichen Blog.

[GN⁺]

Hacker-News-Kommentar

• Ich habe das Modul selbst geladen und die dmesg-Ausgabe immer wieder manuell in Claude hineinkopiert.
  Einer der Hauptgründe, warum ich Claude nutze, ist, dass es lang laufende Prozesse starten, deren Ausgabe lesen und sie zum Debuggen verwenden kann.
  Es gab verschiedene Hacky-Wege, um den manuellen Schritt hier zu überspringen — zum Beispiel dmesg an einen lokalen UDP-Port zu pipen und Claude einen Listener starten zu lassen.

• Ich halte das für ein gutes Beispiel.
  Ich denke, man bekommt beim Einsatz solcher Tools zwei Haupteffekte.
  Erstens kann Claude in Frameworks, mit denen ich bereits vertraut bin, die repetitiven Teile schnell per Pattern Matching erfassen und meine Produktivität massiv steigern.
  Zweitens kann ich mich auch in neue Frameworks deutlich schneller einarbeiten — das ist besonders hilfreich in großen Unternehmen mit vielen unterschiedlichen Stacks.
  Um die Fähigkeiten von AI wirklich richtig einzuschätzen, muss man viel Zeit in sich schnell verändernde Technologien und Frameworks investieren.
  Wenn man Claude Code oder Claude 4.0 nicht über 100 Stunden oder mehr genutzt hat, kennt man sein Potenzial womöglich nicht wirklich.
  Das Szenario „Nicht-Programmierer codieren nach Gefühl und geraten in Probleme“ ist auf X (früher Twitter) vermutlich der Regelfall, aber erfahrene Entwickler machen eine völlig andere Erfahrung, wenn sie kontinuierlich Zeit investieren.

  • Genau das ist der Kernpunkt.
    Ich nutze Claude Code inzwischen ohne einen einzigen Tag Unterbrechung als Hauptwerkzeug für Änderungen an bestehenden Codebasen.
    Durch Versuch und Irrtum habe ich meinen eigenen Prozess entwickelt, was meine Produktivität und meine Bereitschaft zu größeren Experimenten stark erhöht hat.
    Besonders gefällt mir, dass Claude Code, sobald ich Datenstrukturen, Schema und interne APIs im Voraus entworfen habe, die UI interner Tools fast auf Anhieb gut bauen kann.
    Es ermöglicht abstrakteres Denken jenseits einfacher Fleißarbeit oder der Komplexität von Frameworks und war damit ein großer Wendepunkt in meinen 16 Jahren Berufserfahrung.

  • Stimmt.
    Im Grunde hat der Autor Claude gebeten, einen Linux-2.4-Treiber nach 6.8 zu portieren.
    Da es online genügend relevantes Material gibt, hat Claude den Großteil der Arbeit übernommen, und nur bei den wirklich komplexen Kernteilen war die Expertise des Autors nötig.
    Die Formulierung „AI als Werkzeug nutzen, das die eigenen Fähigkeiten explosiv verstärkt“ trifft es für mich wirklich.
    Wenn die eigenen Fähigkeiten hier null sind, bleibt auch das Ergebnis mit AI nahe null oder führt sogar zu negativer Produktivität.

  • Bei uns im Team gibt es auch Leute, die mit LLMs mutig neue Bereiche angehen, aber selbst wenn man allen Claude 4 thinking agent gibt, kommt oft eine Menge unsinniger Code heraus.
    Wenn man den Großteil seiner Coding-Karriere auf Pattern Matching aufgebaut hat, macht der LLM-Agent im Grunde noch einmal Pattern Matching obendrauf, und für Teammitglieder ohne diese Erfahrung ist das eher unerquicklich.
    LLM-Agenten machen das Pattern Matching, zu dem Menschen fähig sind, sehr viel schneller, aber allgemein scheinen sie Menschen darin nicht wirklich überlegen zu sein.

  • Nicht nur beim Erkunden neuer Frameworks, sondern auch bei neuen Sprachen ist das nützlich.
    Unser Team arbeitet mit Ruby, und weil Ruby gut lesbar ist, kann man den LLM Code schreiben lassen und selbst nur die Entscheidungen treffen, ohne die Syntax eigens lernen zu müssen.
    Selbst ohne Ruby zu kennen, kann man so sofort Code auf dem vom Team akzeptierten Niveau schreiben und auch in einer fremden Umgebung direkt produktiv sein.
    (Zur Einordnung: Die Teammitglieder reviewen die Pull Requests.)

  • Die Formulierung „ein Werkzeug, das die eigenen Fähigkeiten explosiv verstärkt“ habe ich diese Woche beim zehnmaligen Neuaufsetzen eines kleinen Projekts wirklich gespürt.
    Seine Stärke zeigt sich, wenn ich von AI unordentlich erzeugte Dinge mit etwas Anleitung in Markup, Styles, JS usw. sauber konsolidieren lasse.
    In Umgebungen wie Startups mit schwachen Coding-Konventionen sind solche Pattern-Matching-Anfragen schwerer anzuwenden, aber in einer starken und reifen Codebasis wirkt es vermutlich ganz anders.

• Ich denke, man sollte Prompts mit möglichst konkreten, domänenspezifischen Schlüsselwörtern formulieren.
  Wenn das technische Verständnis für eine bestimmte Sprache oder ein Framework fehlt, entsteht im Prompt Unschärfe, die das LLM dann eigenmächtig auffüllt, wodurch leicht Ergebnisse entstehen, die von der eigentlichen Absicht abweichen.
  Genau diese Unschärfe ist die Ursache von Bugs.
  Das ist die Kehrseite der „explosiven Verstärkung“.

  • Wenn man nur sagt: „Klasse C braucht einen Tupel-Konstruktor“, würde ich erwarten, dass Claude mit „Moment mal …“ antwortet.

• Bei solchen Artikeln denke ich immer daran, dass vor der Einführung von LLMs im Verhältnis zur Nachfrage tatsächlich viel zu wenig erledigt wurde.

  • Ich glaube immer noch, dass der Engpass nicht die „Ausführung“, sondern „marktfähige Ideen“ sind.
    Es gibt nicht so viele Dinge, für die Menschen tatsächlich Geld zahlen wollen.

  • Das Problem ist nicht immer ein Mangel an Arbeit, sondern oft ein Mangel an Menschen mit dem nötigen Vorwissen und der Erfahrung für diese Arbeit.
    Ohne Erfahrung in der Kernel-Entwicklung wird man selbst mit guten Prompts kaum dieselben Ergebnisse wie der Autor erzielen.
    Theoretisch wirkt es so, als könne man mit der Kraft von LLMs alle alten Treiber auf moderne Kernel „modernisieren“, aber in der Praxis braucht es zwingend menschliche Aufsicht durch Erfahrene, und die Zahl solcher Experten ist im Vergleich zur Zahl der zu pflegenden Treiber viel zu klein.
    Es gibt eine gute Diskussion und ein Interview mit Alan Kay und Joe Armstrong, in denen sie Probleme ansprechen, die dadurch entstehen, dass der meiste Code nicht so entwickelt wird, dass man einfach das Ziel wechselt und neu kompiliert.
    Wenn es neben dem Code eine formale Spezifikation gäbe, wäre das Umziehen eines Treibers auf ein neues Kernel-Ziel einfach eine Art „Neukompilieren der Spezifikation“.
    Da wir uns aber derzeit nicht auf eine Spezifikation, sondern auf alten Code stützen, betreibt das LLM beim Übertragen alten Codes in modernen Code nur Pattern Matching an ähnlichem Code, ohne die eigentliche Bedeutung wirklich zu verstehen oder garantieren zu können — deshalb ist menschliches Können unverzichtbar.

• Ich hatte schon die Ahnung, dass AI die Einstiegshürde für Kernel-Hacking senken würde.
  Inzwischen habe ich immer wieder das Gefühl, dass das tatsächlich stimmt.
  Bald könnte die Unterstützung für Embedded-/ARM-Hardware deutlich breiter werden, und es könnten sogar neue Betriebssysteme für leichte Smart Devices entstehen.

  • Wenn man AI gut nutzt, kann man seine Fähigkeiten schnell steigern.
    Die meisten verlangen von AI aber, „gleich das ganze Haus zu bauen“, obwohl sie viel effektiver ist, wenn man sie als „Hilfe beim Hämmern“ einsetzt.

• Ich halte das für ein gutes Beispiel eines Entwicklers, der die Rolle und die Grenzen von AI versteht und sie passend einsetzt.
  Besonders eindrucksvoll fand ich, dass er den Treiber dank seiner Skepsis als separates Modul gebaut hat.

• Ich möchte auf einen „wichtigen Hinweis“ eingehen, den sonst niemand erwähnt hat.
  Der Autor sagt ausdrücklich, dass man Claudes Ergebnis nicht überhöhen sollte, weil er selbst etwas Erfahrung mit Kernel-Modulen hat und C gut beherrscht.
  Mit anderen Worten: Das Kernel-Modul war nicht wirklich nach nur drei Fragen fertig, sondern es gab viele Gesprächsrunden und mehrfaches manuelles Nachbearbeiten des Codes.
  Er sagt selbst, dass eine Modernisierung ohne grundlegendes Verständnis des inneren Aufbaus von Kernel-Modulen unmöglich gewesen wäre — ein Kontext, den man bei jedem Code-Generierungswerkzeug im Kopf behalten sollte.
  Außerdem beschreibt er die Zusammenarbeit mit Claude Code als ähnlich wie die Erfahrung mit einem Junior Engineer: Es macht alles, was man ihm sagt, und wenn man Fehler anspricht, entschuldigt es sich sofort und lobt einen, was eher anbiedernd als wirklich ingenieurhaft wirkt.
  Schließlich sagt der Autor, dass er diese Arbeit im Zweifel auch allein hätte erledigen können, dafür aber noch einmal lernen müsste, wie Kernel-Entwicklung vor 25 Jahren funktionierte.
  Das führt zurück zur eigentlichen Essenz von Modernisierungsarbeit: „Legacy-Lösungen korrekt zu verstehen und zu erkennen, was gebraucht wird.“
  Entscheidend und zugleich interessant ist, dass gerade das Nicht-Lernen-Müssen hier als Vorteil genannt wird.

  • Eine gatekeepingartige Haltung ist schädlich.
    Ich finde es sehr gut, wenn ein Agent mir Projekte erklärt, die ich nicht kenne.
    Kürzlich habe ich den Firefox-Sourcecode geklont und mit qwen-code nach den AI-Funktionen von Firefox und deren Implementierung gefragt und dabei wirklich großartig gelernt.
    Die Art zu lernen ist dadurch viel besser geworden.

• Ich denke, das ist eine Veränderung, die Menschen mehr Möglichkeiten gibt.
  Der Autor hat über lange Zeit mit Leidenschaft an Side Projects gearbeitet, und ein Upgrade der Werkzeuge ist wirklich etwas Gutes.
  Wenn ein Bereich aber zu speziell ist, fehlt in der Community oft Unterstützung — und genau dort können LLMs helfen, indem sie maßgeschneiderte Probleme lösen.
  Die Einstiegshürden sinken immer weiter, und es kommt eine Zeit, in der auch Menschen mit wenig technischem Hintergrund selbst einfachere Spezialfälle lösen können.
  Das ist eine positive Entwicklung, die mehr Menschen ermöglicht, sich daran zu versuchen.

• Mich würde interessieren, wie sich die Geschwindigkeit nach dem Upgrade verändert hat.

  • Da dieselbe Hardware mit demselben Treiber gesteuert wird, dürfte die Geschwindigkeit gleich geblieben sein.