AI赋能：25年老旧Linux内核驱动ftape的现代化重生之路

您能想象吗？一个沉寂了四分之一个世纪的Linux内核驱动，在当今的现代操作系统上原本几乎无法运行——然而，一位工程师凭借AI助手Claude Code，仅用两个夜晚就让它奇迹般复活。这个驱动曾服务于老旧的磁带存储设备，如今经过全面现代化改造，不仅能在最新的Linux内核上顺利编译，还能与真实的硬件设备流畅通信。这无疑是人工智能技术在代码重构领域的一次重要突破！

背景介绍

简单来说，我的一个业余爱好是帮助人们从旧式磁带盒中恢复珍贵数据，例如QIC-80磁带。这种磁带在1990年代极为流行，是个人用户、小型企业、BBS运营商等广泛采用的备份介质。我对磁带存储有着特殊的情感；手持这些实体磁带的触感，总能让整个数据恢复过程充满乐趣，尽管QIC磁带以其设计缺陷而闻名。但只要经过细致检查和适当维护，这些磁带上的数据即使历经多年仍能完整复原。

每当有人委托我恢复QIC-80磁带数据时，我都会启动那台老旧的PC工作站，上面连接着专用的磁带驱动器，并运行一个非常古老的Linux版本（基于CentOS 3.5）。之所以依赖这个旧系统，是因为只有它才能支持ftape驱动——这是与磁带驱动器通信所必需的内核驱动，能够完整读取磁带上的原始二进制内容。

这种磁带驱动器通过主板的软驱控制器连接。这实际上是一个巧妙的“经济型设计”：传统高端磁带通常需要独立的SCSI接口，但这样设计允许用户直接利用现有的软驱接口，无需额外购置硬件。它甚至可以与现有软驱共享同一条排线！当然，代价是速度受限于软驱控制器，大约只有500 Kbps（请注意，这是千比特每秒，而非千字节）。

另一个挑战是，通过软驱控制器与磁带驱动器通信的协议非常混乱、非标准化，且支持性差。这完全是一种“黑客式”方法：主板BIOS根本无法识别磁带驱动器，所有控制都必须由用户端软件手动处理，包括操作硬件I/O端口、管理时序、处理中断等，以迫使软驱控制器将命令传递给磁带驱动器。

当年只有少数专有工具能在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文件），可以尝试在实际硬件上使用。毫不意外，这个模块尚未完全“工作”——它能加载，但无法正确与磁带驱动器通信。

但我并未放弃。

从这一步开始，由于加载/卸载内核模块需要sudo权限，我不能再让Claude自行“迭代”这种敏感操作。

幸运的是，ftape驱动内已有大量日志信息（printk()调用会输出到dmesg），于是我手动加载模块，并将dmesg输出粘贴给Claude，让它与我之前保存的、成功读取磁带时的“已知良好”dmesg日志进行对比。经过几轮这样的迭代，Claude找出了阻止模块与硬件通信的剩余问题。

完美！该模块有一些可配置参数。问题在于，如果不进行配置，所有基地址默认为-1，而在配置函数中，这个值会被转换为0xffff，导致检测失败。

“No such device or address”（ENXIO）错误的原因是ftape-internal模块未使用正确的I/O端口基地址配置软驱控制器。问题出在fdc-internal.c的第735–737行：如果fdc->sra == 0xffff，函数将返回-ENXIO。由于未提供任何配置，所有值默认为-1，从而变为0xffff……

最终，我获得了一个能够实现以下功能的内核模块：

a) 成功加载；

b) 检测到磁带驱动器；

c) 导出测试磁带的内容！

经验与感悟

让ftape驱动在现代内核上运行——这项曾经看似不可能的任务——竟在两个晚上内完成。

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

需要强调的是，我个人对内核模块有一定基础经验，对C语言也较为熟悉，因此我不想过度夸大Claude在此场景中的作用。

换言之，这并不是仅通过三条指令就让Claude输出一个可用内核模块，而是经历了多轮交流互动，以及几次手动代码修正。若缺乏对内核模块内部机制的基本理解，这种现代化工作根本无从谈起。

这让我对使用此类编码助手有了几点深刻体会：

1. 将其视为真正的协作伙伴

与Claude Code互动的感觉如同与另一位工程师合作。有人将其比作“初级工程师”，我认为大致准确：它会尽力遵循指示，积极配合，有时自信过度，但犯错时会迅速道歉并承认您的正确性。

因此，人类仍需提供指导框架、做出产品决策、遵循架构规范，并及早发现潜在问题。

2. 尽量具体明确，善用领域关键词

我不敢自称突然成为提示词工程师，但我发现最有效的提示方式是：先清晰描述功能的“语言框架”，再指出框架中的空缺，让模型填补细节。

3. 培养对适合模型处理任务类型的直觉

这些大型语言模型并非万能，如果让其处理不擅长的事务，您可能会感到沮丧，并在其展现能力前放弃。在这方面，了解LLM的工作原理很有帮助，能让您更好判断其优势与局限。

4. 将其作为个人能力的倍增器

理论上，我完全可以独立完成这次现代化工作，但那意味着需要学习25年前的内核开发方法，花费数周时间查阅如今已无用的文档。相反，我用几天时间与助手交流，让它解释每一步操作。

当然，我会验证和测试它所做修改，同时也学到了许多实用知识，例如现代内核规范、x86架构细节，以及一些命令行技巧，这些都将成为我的常用工具集。

5. 用它快速掌握新框架

我本身并非内核开发者，但这次经历激发了我对内核级工作的兴趣，事实证明内核开发并不像想象中那么困难。在另一次“氛围编码”体验中，我甚至未使用过Flutter就构建了一个Flutter应用。如果您和我一样，喜欢在实践中学习，这些工具能大幅加速您掌握新框架的进程，让您更专注于高层次架构思考。

总结

总而言之，现在我欣慰地宣布，ftape依然充满活力！在距其最后一次官方发布已25年之后，它终于能在现代Linux系统上编译和使用。我仍在进行一些进一步调整和功能添加，但已验证其正常工作，无论是我的软驱磁带驱动器，还是其支持的并口驱动器。

物理设备设置几乎保持不变，但操作系统现已升级为Xubuntu 24.04，而非昔日的CentOS 3.5！

原文链接：https://dmitrybrant.com/2025/09/07/using-claude-code-to-modernize-a-25-year-old-kernel-driver