在内核开发的长期演进中，驱动程序的移除并非单纯的技术决策，而是涉及硬件生命周期、维护成本、API 兼容性等多维度的工程权衡。Linux 总线鼠标驱动（bus mouse driver）的去留便是这样一个典型案例，其背后反映了内核社区在遗留代码处理上的系统性方法论。
遗留硬件支持的成本边界
总线鼠标是上世纪八九十年代个人计算机常见的输入设备，通过专用的总线接口卡与主板连接，通常采用 RS-232 串行协议或专用的_busmouse_ 接口。这类硬件在现代计算环境中已经极为罕见 ——1990 年代后期即被 USB HID 设备全面取代。对于内核维护者而言，继续保留总线鼠标驱动意味着需要应对多重隐性成本：首先，驱动代码需要随内核 API 演进持续更新，任何 input 子系统的重构都可能波及这些遗留代码；其次，编译和测试资源被无端消耗，尽管几乎没有任何用户实际使用这些驱动；再者，遗留代码的存在增加了新开发者的认知负担，降低了代码库的可维护性。
从硬件生命周期的统计数据来看，总线鼠标的实际使用量在过去十五年间已接近于零。内核社区采用的量化标准通常是：如果某驱动对应的硬件市占率低于特定阈值，且无活跃用户报告问题，即可启动移除流程。这一阈值虽然从未被正式文档化，但实践中已成为社区共识。
内核 API 演进与子系统统一
Linux 输入子系统的现代化进程是驱动移除的关键推动力。早期内核采用分散的驱动模型，每种外设类型都有独立的子系统 —— 鼠标有 mouse 驱动，键盘有 keyboard 驱动，触摸屏有 touchscreen 驱动。这种架构在设备种类有限的年代尚可接受，但随着 HID（Human Interface Device）标准的普及，统一输入层成为必然选择。
HID 规范自 1999 年被引入 USB 以后，逐步成为人机交互设备的事实标准。Linux 内核通过 usbhid、hid-generic 以及 evdev/libinput 用户空间库，构建了完整的现代输入框架。这一框架不仅支持 USB 设备，还通过 HID over I2C、Bluetooth HID 等协议覆盖了移动设备和嵌入式场景。总线鼠标驱动所代表的旧式输入模型 —— 直接硬件访问、专用协议处理、缺乏热插拔支持 —— 与这一统一架构存在根本性冲突。
更重要的是，总线鼠标驱动依赖的内核 API 已经历多轮演进。许多早期的 register_chrdev、miscdevice 接口已被新的 input_device 管理机制替代。维持兼容性需要额外的适配层，这本身就是一个潜在的不稳定源。
嵌入式系统的特殊考量
对于嵌入式 Linux 开发者而言，驱动移除可能带来特定场景的挑战。工业控制、医疗设备、航空航天等领域的嵌入式系统往往具有超长的硬件生命周期，部分老旧设备可能仍在使用总线鼠标作为人机交互接口。然而，这类系统的内核定制化程度通常较高 —— 厂商往往会冻结特定内核版本，或自行维护必要的驱动补丁。因此，内核主线移除某驱动，并不会直接导致这些系统失效，只是意味着他们需要承担后续的维护责任。
从系统工程的角度看，嵌入式开发者应当尽早规划遗留硬件的迁移路径。具体的工程参数包括：评估系统是否真正需要总线鼠标支持（大多数现代嵌入式设备已转向触控屏或 USB 外设）；如必须保留，评估将驱动代码移至外部内核模块或用户空间驱动的可行性；建立针对内核升级的回归测试流程，确保关键外设在升级后仍可正常工作。
实践建议与监控要点
对于需要管理遗留 Linux 系统的运维工程师，以下参数和监控点值得关注：检查当前内核配置中的 CONFIG_MOUSE_BUS 或类似选项，确认其状态；若系统仍在使用总线鼠标，建议制定迁移计划，包括外设更换、内核回滚或驱动外部化等方案；监控内核邮件列表和 Documentation/feature-removal-schedule.txt 的更新，及时获取驱动移除的时间节点。
总体而言，Linux 总线鼠标驱动的移除是内核持续现代化的必然结果。其背后体现的工程逻辑 —— 以用户实际需求为导向、以代码可维护性为约束、以 API 统一为目标 —— 同样适用于其他遗留组件的评估与处理。在内核快速迭代的背景下，理解这些权衡有助于开发者和管理者做出更加理性的技术决策。
资料来源：Linux 内核文档 Documentation/feature-removal-schedule.txt；内核输入子系统源码树 drivers/input/mouse；Linux Kernel Archive 关于 HID 子系统的官方文档。