我想在用D编写的用户空间库中伪造嵌入式Linux板（BeagleBone Black）的LED（字符设备）。
通过命令行，led driver为represented to the user space as "device file"（例如，对于led“USER LEDS D2 0”）：
debian@beaglebone:/sys/class/leds/beaglebone:green:usr0$ tree
.
├── brightness
├── device -> ../../../leds
├── invert
├── max_brightness
├── power
│ ├── async
│ ├── autosuspend_delay_ms
│ ├── control
│ ├── runtime_active_kids
│ ├── runtime_active_time
│ ├── runtime_enabled
│ ├── runtime_status
│ ├── runtime_suspended_time
│ └── runtime_usage
├── subsystem -> ../../../../../class/leds
├── trigger
└── uevent
通过命令行单个实体，例如亮度（打开和关闭）可以写入和读取相似的文件：
cd /sys/class/leds/beaglebone:green:usr0
echo none > trigger
echo 1 > brightness
echo 0 > brightness
我认为将整个设备抽象为接口并实现生产类和实现接口的测试类（手工制作假对象）是合理的。然后，库的客户端代码可以使用生产代码或可以使用依赖注入注入的伪类。
像https://github.com/QAston/DMocks-revived这样的模拟框架是否可以提供在开箱即用的客户端代码中使用假驱动程序的功能，而不是使用上述手工制作的假led驱动程序？ （我想假装更复杂的角色设备，无论如何都需要“手工实施”。）
还是有更好的方法来伪造字符设备（例如，在通过“构造函数注入”创建实例时，让生产类需要驱动程序的根路径）？