25年旧驱动重获新生：AI助手Claude Code的奇迹

想象一下吧！一段源自25年前的Linux内核驱动，在现代系统上几乎无法运行——但一位工程师借助AI助手Claude Code，仅用了两个晚上，就让它重获新生。这个驱动原本服务于老旧磁带设备，如今经过现代化改造，不仅能在最新Linux上编译，还能与真实硬件顺利通信。这无疑是AI的大功一件！

背景介绍

简单介绍一下背景，我的业余爱好之一是帮助人们从旧磁带盒中恢复数据，例如QIC-80磁带。这种磁带在1990年代非常流行，是个人、小型企业、BBS运营者等常用的备份产品。我对磁带介质有着特别的情感；手里握着这些磁带的触感，总能让整个过程变得非常愉快，尽管QIC磁带因设计缺陷而臭名昭著。不过，只要经过仔细检查和适当翻新，这些磁带上的数据即便多年之后仍然可以完全恢复。

每次有人送来QIC-80磁带让我恢复数据时，我都会启动一台老旧PC工作站，这台电脑上连着对应的磁带驱动器，然后启动一个非常老的Linux版本（搭载的是CentOS 3.5）。之所以用这么老的系统，是因为只有这个系统才能用ftape驱动，这是与磁带驱动器通信所必需的内核驱动，可以把磁带上的二进制内容完整读取出来。

这种磁带驱动器是接在主板的软驱控制器上的。这其实是个聪明的“省钱招”：本来高端磁带通常要用单独的SCSI接口，但这样你就可以直接用已经有的软驱接口，不用额外买硬件。而且它还能和现有的软驱共用同一条排线！当然，代价是速度被软驱控制器限制了，大概只有500 Kbps（注意，是千比特，不是千字节）。

当年只有少数专有工具能在MS-DOS和Windows 3.x/9x下操作这些磁带驱动器，而在Linux上，开源实现几乎只有ftape这一种。当然，用原来的DOS/Windows工具也能读取磁带，但ftape的优势在于它能直接读取磁带的“原始”二进制内容，不管最初是哪个专有软件写入的。这也是我更喜欢使用ftape来导出磁带内容的原因：先把二进制内容完整读出来，再去处理那些专有的逻辑格式，最后再提取出文件。

问题是，ftape驱动从大约2000年起就不再维护了，很快也从Linux内核中被移除。这就是为什么每次处理这种磁带时，我都不得不运行一个非常老的Linux版本。如果ftape能在现代Linux发行版上运行，那就太好了——既能保留原有功能，又能享受现代系统的各种便利。

向Claude Code发问

几周前，我突然想到向Claude Code提出一个简单的请求：

这个仓库是一个Linux内核驱动，用于与主板上连接到软盘控制器（FDC）的老式磁带驱动器通信。不幸的是，这个驱动已经很久没有维护了，而且只能在2.4版本的内核下编译。我希望将其现代化，使其能够在最新版本的内核上构建。

Claude回应说，它可以帮我现代化这个用于老式磁带驱动器的Linux内核驱动。这是一项相当庞大的任务，需要更新代码以兼容现代内核的API和约定。

经过几轮所谓的“组合优化”以及Claude自称的其他操作后，我突然得到了一个可以编译且无错误的内核驱动。

这是因为Claude能够读取编译器输出，并将其反馈给自身，直到编译正确为止。

从2.4内核到6.8内核的漫长时间里，有大量内核函数和结构已被弃用或替换。

令人惊讶的是，Claude找到了所有过时的部分，并用正确的现代等效代码替换了它们，只需要对部分代码做少量手动调整（稍后会详细说明）。

不过，此时的内核驱动仍然需要作为完整内核树的一部分来编译，而我只是希望它能成为一个独立的可加载内核模块。于是我问：

有没有办法只在原地编译这个模块，而不用把它复制到内核源码树里？

Claude回答：可以！你可以在内核源码树外编译内核模块，无需复制到内核源代码中。我来为ftape驱动创建一个独立的构建系统吧。

...结果它真的做到了，而且无需进一步提示。

在这个阶段结束时，我得到了一个可加载的内核模块（.ko文件），可以尝试在实际硬件上使用。不出意料的是，这个模块还没有完全起“作用”——它能加载，但无法正确与磁带驱动通信。

不过我没有放弃。

心得体会

使用ftape驱动在现代内核上工作——曾经看似完全不可能的任务——居然在两个晚上就完成了。

GitHub地址：https://github.com/dbrant/ftape

需要强调的是，我自己对内核模块有一些基础经验，对C语言也比较熟悉，所以我不想过度夸大Claude在这个场景中的作用。

也就是说，这并不是三条指令就让Claude输出了一个可用的内核模块，而是经历了多轮来回交流以及几次手动修正代码。如果没有对内核模块内部机制的基本理解，这种现代化工作根本无法完成。

这让我对使用此类编码助手有了一些心得：

• 真正把它当作协作伙伴