Assisted by AI, Revive a 25-Year-Old Kernel Driver with Claude Code

Can you imagine? A Linux kernel driver that's 25 years old can hardly run on modern systems. However, an engineer spent just two evenings leveraging the AI assistant Claude Code to breathe new life into it. This driver used to serve old - fashioned tape devices. After modernization, it can not only be compiled on the latest Linux but also communicate smoothly with real hardware. Truly, AI has done a great job!

Background

Let me briefly introduce the background. One of my hobbies in my spare time is helping people recover data from old tape cartridges, such as QIC - 80 tapes. These tapes were quite popular in the 1990s and were commonly used as backup products by individuals, small businesses, BBS operators, etc. I have a special affection for tape media; the tactile sensation of holding these tapes in my hand always makes the whole process very enjoyable, even though QIC tapes are notoriously known for their numerous design flaws. However, with careful inspection and proper refurbishment, the data on these tapes can still be fully recovered even after many years.

Every time someone brings me a QIC - 80 tape to recover data, I'll boot up an old PC workstation of mine. This computer is connected to the corresponding tape drive, and then I'll start up a very old version of Linux (running CentOS 3.5). The reason I use such an old system is that only this system can use the ftape driver, which is a kernel driver necessary for communicating with the tape drive and can read out the binary content on the tape completely.

This tape drive is connected to the floppy disk controller on the motherboard. It's actually a smart "cost - saving move": usually, high - end tapes require a separate SCSI interface, but in this way, you can directly use the existing floppy disk interface without having to buy additional hardware. Moreover, it can share the same cable with the existing floppy drive! Of course, the cost is that the speed is limited by the floppy disk controller, about 500 Kbps (note, it's kilobits, not kilobytes).

Another problem is that the protocol for communicating with the tape drive through the floppy disk controller is very messy, non - standard, and poorly supported. It's completely a "hacker - style" approach: the motherboard BIOS is completely unaware of the existence of the tape drive, and all controls have to be handled by the user - side software itself, including operating the hardware I/O ports, timing, interrupts, etc., to make the floppy disk controller "obediently" send commands to the tape drive.

Back then, only a few proprietary tools could operate these tape drives under MS - DOS and Windows 3.x/9x. On Linux, the open - source implementation was almost exclusively ftape. Of course, the original DOS/Windows tools can also read tapes, but the advantage of ftape is that it can directly read the "raw" binary content of the tape, regardless of which proprietary software originally wrote it. That's why I prefer to use ftape to export the tape content: first read out the binary content completely, then deal with those proprietary logical formats, and finally extract the files.

The problem is that the ftape driver has not been maintained since around 2000 and was soon removed from the Linux kernel. That's why every time I deal with these tapes, I have to run a very old version of Linux. It would be great if ftape could run on modern Linux distributions - it could retain its original functions while enjoying the conveniences of modern systems.

Asking Claude Code

A few weeks ago, I suddenly thought of making a simple request to Claude Code:

This repository contains a Linux kernel driver for communicating with an old - fashioned tape drive connected to the floppy disk controller (FDC) on the motherboard. Unfortunately, this driver has not been maintained for a long time and can only be compiled under the 2.4 kernel version. I hope to modernize it so that it can be built on the latest kernel version.

Claude replied that it could help me modernize this Linux kernel driver for the old - fashioned tape drive. This is a rather large - scale task that requires updating the code to be compatible with the APIs and conventions of modern kernels.

After several rounds of so - called "combination optimization" and other operations that Claude claimed to perform, I suddenly got a kernel driver that could be compiled without errors.

This is because Claude can read the compiler output and feed it back to itself until the compilation is correct.

Over the long period from the 2.4 kernel to the 6.8 kernel, a large number of kernel functions and structures have been deprecated or replaced.

Surprisingly, Claude found all the outdated parts and replaced them with the correct modern equivalent code, only requiring a small amount of manual adjustment to some of the code (which will be detailed later).

However, at this time, the kernel driver still needed to be compiled as part of the complete kernel tree, while I only wanted it to be an independent loadable kernel module. So I asked:

Is there a way to compile this module in - place without copying it to the kernel source tree?

Claude answered: Yes! You can compile the kernel module outside the kernel source tree without copying it to the kernel source code. Let me create an independent build system for the ftape driver.

... And it actually did it without further prompting.

At the end of this stage, I got a loadable kernel module (a.ko file) that I could try using on actual hardware. Not surprisingly, this module wasn't fully "functional" yet - it could be loaded, but it couldn't communicate correctly with the tape drive.

However, I didn't give up.

From this point on, since loading/unloading the kernel module requires sudo privileges, I couldn't let Claude "iterate" on such sensitive operations on its own.

Fortunately, there are already a large number of log messages in the ftape driver (printk() calls that are printed to dmesg). So I loaded the module myself and manually pasted the dmesg output to Claude, asking it to compare it with the "known good" dmesg log I saved when I successfully read the tape. After several rounds of such iterations, Claude identified the remaining issues preventing the module from communicating with the hardware.

Perfect! This module has some configurable parameters. The problem is that if not configured, all base addresses will default to - 1, and in the configuration function, this value will be converted to 0xffff, resulting in a detection failure.

The reason for the "No such device or address" (ENXIO) error is that the ftape - internal module didn't configure the floppy disk controller with the correct I/O port base address. The problem lies in lines 735 - 737 of fdc - internal.c: if fdc->sra == 0xffff, the function will return - ENXIO. Since no configuration was provided, all values defaulted to - 1, which became 0xffff...

Finally, I got a kernel module that can do the following:

a) It can be loaded;

b) It can detect the tape drive;

c) It can export the content of the test tape!

Insights

Making the ftape driver work on a modern kernel - a task that once seemed completely impossible - was actually accomplished in just two evenings.

GitHub link: https://github.com/dbrant/ftape

It should be emphasized that I have some basic experience with kernel modules and am quite familiar with the C language, so I don't want to over - exaggerate Claude's role in this scenario.

That is to say, it wasn't a matter of giving three instructions and having Claude output a usable kernel module. Instead, it involved multiple rounds of back - and - forth communication and several manual code corrections. Without a basic understanding of the internal mechanisms of kernel modules, this modernization work simply couldn't be done.

This has given me some insights into using such coding assistants:

1. Truly Treat It as a Collaborative Partner

Interacting with Claude Code feels like collaborating with another engineer. Some people compare it to a "junior engineer", and I think that's generally accurate: it will try its best to follow your instructions, cooperate actively, sometimes be over - confident, but quickly apologize when it makes mistakes and say you are "absolutely right".

Therefore, humans still need to provide guidance, make product decisions, follow architectural specifications, and detect potential problems early.

2. Be as Specific as Possible and Use Domain - Related Keywords

I can't claim to have suddenly become a prompt engineer, but I've found that the most effective prompts are: first clearly describe the "language framework" of the function, then point out the gaps in the framework and let the model fill them in.

3. Develop an Intuition for the Types of Tasks Suitable for the Model

These large models are not omnipotent. If you ask it to do things it's not good at, you'll be frustrated and may give up on it before it shows its capabilities. In this regard, understanding how LLMs work is helpful for better judging their advantages and limitations.

4. Use It as a Multiplier of Your Own Abilities

Theoretically, I could have completed this modernization work on my own, but that would have meant learning kernel development methods from 25 years ago and spending weeks looking up documents that are no longer useful today. Instead, I spent a few days communicating with the assistant and having it explain each step of the operation.

Of course, I verified and tested the modifications it made, and at the same time, I learned a lot of actually useful things, such as modern kernel specifications, details of the x86 architecture, and some command - line operation skills, which will all become my commonly used tools.

5. Use It to Quickly Get Started with New Frameworks

I'm not a kernel developer myself, but this experience has sparked my interest in kernel - level work. It turns out that kernel development isn't as difficult as I thought. In another "vibe coding" session, I even made a Flutter application without prior experience with Flutter. If you're like me and like to learn by doing, these tools can significantly speed up your learning of new frameworks and allow you to focus more on high - level architectural thinking.

Summary

All in all, I'm now happy to say that ftape is still alive! 25 years after its last official release, it can finally be compiled and used on modern Linux. I'm still making some further adjustments and adding new features, but I've verified that it works properly, whether with my floppy - disk tape drive or the parallel - port drive it supports.

The physical device setup looks almost the same, but the operating system is now Xubuntu 24.04 instead of the previous CentOS 3.5!

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

This article is from the WeChat official account "CSDN", written by Dmitry Brant and published by 36Kr with authorization.