Linux用户空间能否优雅模拟字符设备文件用于应用测试？

我有一个用户空间应用，会打开Linux设备文件句柄（如/dev/foobar）并向其发送ioctl指令。测试时需要复现设备返回给用户空间的特定响应序列，希望用测试替身对象替换设备句柄，让测试夹具能控制被模拟系统调用的结果。不想为测试卸载原有驱动并加载测试替身驱动——这需要提升权限且会干扰其他并发访问该设备的测试用例。

我目前考虑了几种方案，但想知道是否有其他未想到的选项：

• 使用LD_PRELOAD模拟glibc封装的系统调用，如open()、read()、ioctl()等。虽可行，但需拦截、分析并过滤所有open()/close()调用，仅作用于/dev/foobar，类似状态机；且不确定测试框架是否支持为单个测试用例覆盖LD_PRELOAD。
• 在与驱动交互的用户空间代码中增加间接层，通过新接口控制测试，比如添加“是否处于测试模式”的条件判断或用动态分派实现。但这会对生产代码造成侵入性修改，还会将测试逻辑泄露到生产逻辑中。
• 构建所有依赖均可控的单元测试。但这段是遗留代码，未做易于单元测试的设计，且测试逻辑分散在多个子系统中，改为真正的单元测试需要大量重构，目前无法实现。

理想方案是拥有一个用户空间可控的文件（如/home/user/my_device），可完全在用户空间中实现系统调用方法。之后只需修改代码使其打开该文件而非默认的/dev/foobar，就能控制所有相关系统调用的行为。

推荐方案：用FUSE实现用户空间模拟设备 #

FUSE（Filesystem in Userspace）是Linux原生的用户空间文件系统框架，完美匹配你“用户空间可控文件”的需求，核心优势如下：

• 无需内核权限：不用卸载/加载内核驱动，普通用户即可创建FUSE文件系统（只要系统开启FUSE支持）
• 精准匹配目标设备路径：测试时可让应用通过环境变量、命令行参数指定打开FUSE挂载的路径（比如/tmp/test_foobar），无需修改核心业务逻辑
• 完全控制系统调用行为：在FUSE的回调函数中，你可以自定义open、ioctl、read等所有操作的返回值和响应序列，测试夹具可动态调整这些响应来复现各种场景
• 无生产代码侵入：仅需给应用添加“可配置设备路径”的逻辑（这属于通用配置能力，而非测试专属代码），不会把测试逻辑混入生产代码

实现核心步骤 #

1. 编写FUSE回调逻辑：实现open、ioctl、release等必要的回调函数，在ioctl中根据测试预设的响应序列返回对应结果，比如可以维护一个队列，每次调用取出下一个预设响应
2. 挂载临时FUSE文件系统：测试启动时，挂载FUSE文件系统到临时路径（如/tmp/test_foobar），测试结束后卸载
3. 配置应用设备路径：让测试中的应用打开FUSE路径而非默认的/dev/foobar，比如通过环境变量export FOOBAR_DEVICE=/tmp/test_foobar传递，或者在应用启动参数中指定
4. 动态控制测试场景：测试夹具可以通过进程间通信、共享内存等方式，修改FUSE回调中的响应序列，实现不同测试用例的场景覆盖

对比现有方案的优势 #

• 对比LD_PRELOAD：无需拦截所有系统调用，只需针对目标路径处理，逻辑更简洁；测试框架可轻松通过环境变量或启动参数配置，支持单测试用例的隔离执行
• 对比代码侵入式方案：仅需添加通用的路径配置逻辑，不会把测试专属的判断、分支混入生产代码，避免代码污染
• 对比全单元测试重构：无需大规模修改遗留代码，仅需小幅度调整设备路径的获取方式，快速实现测试覆盖

内容的提问来源于stack exchange，提问作者Grigory Rechistov