此计划来自之前的 d1 板上外设驱动计划。
- 内核仅有串口驱动（可以开启所有串口并配置引脚），尚缺 PWM、SPI、TWI（I2C）；
- 串口外设抽象不支持动态开关、阻塞读取、调整配置（尤其是波特率）、DMA；
- 似乎一组外设的时钟（同类外设共享一个控制寄存器）必须统一设置，写此寄存器将导致所有此类外设重置，因此无法单个动态开关；
由于发现单个外设难以动态开关，用户态驱动在 D1 板上的重要性大大降低，目前不必考虑为 D1 支持用户态驱动。但用户态驱动本身仍有意义，但需要继续调研如何为不同外设提供相对统一的抽象，以及不同外设所属的关联寄存器如何实现联合的抽象。
例如，GPIO 控制器是一个“外设”，但 GPIO 功能需要与对应外设功能匹配，如开启 UART5 应该同时配置 UART5-RX/UART-TX 管脚功能。另外 GPIO 功能最好由内核提供互斥机制，如开启 UART5 已占用 PB4、PB5，就无法再为 TWI1 配置 TWI1-SCK/TWI1-SDA。另外每个外设开关都需要对应修改 CCU。这个抽象设计将十分复杂。
目前，D1 上开启哪些外设依赖在内核中硬编码。修改（包括修改参数）都需要重新编译内核。因此，目标将转向将具体外设配置移出内核。
正确的做法是将外设配置写到设备树，内核读取设备树决定初始化哪些外设。但现在修改设备树比较麻烦（主要是用预编译镜像，编译没写 Makefile，看着麻烦），而且设备树要静态链接到 SBI，修改设备树和修改内核也没太大区别。而设备树必须链接到 SBI 又是现在 SBI 的引导流程决定的（BROM -> SPL -> UBOOT -> OpenSBI -> Kernel），所以应该探索一些新式的、没这么繁琐的加载设备树的方式。
正好洛佳大佬提到，去年学生为 RustSBI 适配 D1 哪吒开发板的工作已被 oreboot 吸收，此方案下 SBI、内核和设备树都是独立编译的。因此用户态驱动支持计划暂停，先进行 oreboot 引导计划。
用户态驱动支持计划暂停但不是取消，未来将网卡驱动与协议栈异步化的时候仍然很有竞争力。进一步计划将随项目需求和对系统设计更新。