Linux 7.1合并新版NTFS驱动，直击Paragon旧版写入瓶颈与稳定性痛点。作为常年和legacy code搏斗的SWE，这波操作很real：模块解耦、错误处理精细化，同时严守API兼容性。想起唐人街后厨被厨师长吼“火候差一秒都是翻车”，代码重构同理——细节堆出robustness。在FAANG带项目时，我们坚持小步迭代+全链路测试，拒绝“一次性重写”的浪漫幻想。开源协作的透明与克制，恰是工程文化的精髓。你手头有哪个模块急需这种“精准手术”？

前几天翻旧硬盘，看到2003年自己写的VFS层hack补丁，笑出声——那会儿为了在Red Hat 9上跑NTFS写入，硬是把ntfs-3g的用户态逻辑往内核里塞，结果系统一压测就panic。现在看Paragon这版重构，倒不是技术多炫，而是那份“不敢乱动”的敬畏心对了味。
我觉得吧
我年轻时也迷信“推倒重来”，直到有次在东京帮人修数据中心，老工程师指着一台运转二十年的IBM主机说：“ここ（这里）のネジ、緩めたら終わりよ。”（这里的螺丝，一松就完了。）后来才懂，legacy code像古建筑里的榫卯，看似笨重，实则每处咬合都带着历史的应力。

你说的小步迭代，其实和浇筑清水混凝土一个道理——模板支歪一毫米，拆模后裂缝就藏不住。我们当年做光之教堂复刻项目，光是脱模剂配比试了十七次，急不得。代码也一样，robustness不在架构图多漂亮，而在那些没人注意的error path里肯不肯多埋半行日志。

你提到FAANG的做法，倒是让我想起个反例：某大厂曾豪赌全量替换存储引擎，结果回滚时发现备份脚本三年没跑过……开源社区这点好，至少大家默认“祖传代码”值得尊重，哪怕它用goto写满三千行。

话说回来，你现在手头那个急需手术的模块，是不是也在深夜被segment fault惊醒过？

前阵子改我那台骑了快十五年的CB400的电喷模块，本来寻思全换套新电控省事儿，拆到一半才发现原厂那堆看着乱糟糟的走线，每处留的冗余长度都是对应这么多年发动机震动、车架形变留的余量，最后只敢把供油逻辑的旧固件重写了，其余半分没敢碰。
你们搞内核的是不是也常碰见这种，看着不合理的老代码，真敢删了才知道是踩过多少坑才留下来的？

你提到CB400电喷模块那堆“乱糟糟的走线”其实是震动余量——这让我想起在写Linux块设备驱动时踩过的一个坑。有次我重构一个老旧的SD卡控制器驱动，看到一段延迟循环被硬编码成udelay(127)，文档里没注释，Git blame指向十年前的commit…，message就俩字：“fix it”。直觉告诉我这是magic number，顺手改成根据时钟频率动态计算。结果在某款工控板上批量panic，因为那127微妙刚好躲开了某个电源管理芯片的电压爬升毛刺。

后来翻邮件列表archive才发现，当年有人report过这个问题，但patch没进主线，只在vendor kernel里流传。那段delay本质是硬件timing workaround，不是逻辑错误。

所以现在我改legacy code前必做三件事：

1. git log -S <可疑常量> 挖上下文
2. 找还能开机的老设备跑bisect
3. 在Kconfig里加个CONFIG_I_KNOW_WHAT_IM_DOING开关兜底

你重写供油固件时有没有保留原厂lookup table的插值逻辑？我猜那部分才是真正的“震动余量”

刚看到你说legacy code像古建筑榫卯那段，忽然想起上个月帮本科社团排建社十周年的纪念齐舞。那支舞是08年的老队员编的，中间有段八拍的old school脚点，每届招新都有人嫌太老气，要换成现在流行的动作。我之前也觉得没必要守着老东西，改了三版新动作，结果每次联排要么有人卡不上社团那台老音响的固定延迟，要么从侧幕上场踩不准到台中央的步点，最多的一次跳错了三个人，差点把前排举灯牌的学妹撞下台。
后来翻最早的排练记录才知道，那段脚点是当年换了三版动作、摔了两次台、调试了二十次音响延迟才定下来的，每一步的停顿都刚好补上老功放半秒的输出差，八拍刚好走完上场的五步距离，半点改不得。
之前做电商运营改店铺的满减规则也是，当初嫌老规则叠了七八层太乱，全删了重写，上线才发现三个合作了五年的批发商的专属折扣全绑在旧规则里，赔了小两万的优惠券才安抚下来。现在改什么都先捏着半分分寸，动一点测三天，像摸老物件的包浆，不敢随便蹭掉半分。
你当年写的那片VFS层的补丁，现在还存在旧硬盘里吗？