🎯 RT-Thread 2025 Roadmap

[Rbb666]

trafficstars

测试

背景： RTT 目前针对主线自动化测试看护粒度需要细化，一些驱动、组件的PR需要加入到测试中进行看护； 详见此issue：https://github.com/RT-Thread/rt-thread/issues/9775

• [ ] UTest 测试用例完善（内核、外设）
• [ ] 添加代码覆盖率（集成ci中）
• [ ] 自动打TAG
• [ ] BSP：cvitek、K230 ......

组件

• [ ] UORB：用于线程间 / 进程间订阅发布机制通信

驱动

• [ ] I3C框架
• [ ] 更多BSP适配 UART_V2框架
• [ ] 宏内核MPU的设备树适配（？）

文档

• [ ] 完善 Smart 文档中心
• [ ] doxygen RTT-API 文档更新

[lygstate]

BSP 这么多，可以把 rt-thread-core 拆出来吗？ 只保留 libcpu, bsp 只提供最基础的几个（比如每个CPU提供一个）其它的BSP都放在 rt-thread

[unicornx]

BSP 这么多，可以把 rt-thread-core 拆出来吗？ 只保留 libcpu, bsp 只提供最基础的几个（比如每个CPU提供一个）其它的BSP都放在 rt-thread

支持。现在 bsp 下的东西太多了。建议 bsp 部分拿出来各家自己维护。RTT 仓库中只需要支持典型的 ARCH 下的几款典型的 bsp 即可，包括 qemu-virt-xxx

如果拆分了，我建议 rtt 主仓得至少有个文件记录 bsp 仓库的地址，不然太分散了大家找不到需要的 bsp 也不好。

[unicornx]

RTT 仓库下的 license 问题还需要清理，一部分是由 bsp 引入的，如果 bsp 能清理掉，这个问题也能一起解决。

目前我发现的 license 冲突问题都提了 issue 了，总结如下：

• #9811
• #9810
• #9809
• #9808
• #9801
• #9799
• #9797
• #9796

另外设备树部分借用了很多外部的代码，是 GPL 和 BSD 双 license 的，我不确定对于这种情况，RTT 是不是要加个 NOTICE 声明，虽然 Apache 项目可以包含 BSD 的，这个可能需要专业法律回答一下。

[unicornx]

RT-Thread 的新版本发布计划以后还有吗？5.2.0 持续了 8 个月了 see a0735dcb11f0acc5e85649cfbb761bcdf68afe31

建议为 RTT 建立一套 可预期的（固定） 周期发布的机制。

[unicornx]

文档

我对文档改进有一些想法，提了个 issue #9824，欢迎大家拍砖。

[Rbb666]

RT-Thread 的新版本发布计划以后还有吗？5.2.0 持续了 8 个月了 see a0735dc

建议为 RTT 建立一套 可预期的（固定） 周期发布的机制。

5.2.0 可以在年前发版

[supperthomas]

RTT 仓库下的 license 问题还需要清理，一部分是由 bsp 引入的，如果 bsp 能清理掉，这个问题也能一起解决。

目前我发现的 license 冲突问题都提了 issue 了，总结如下：

bsp目录下面有个md文件

[unicornx]

• #8828 里的问题可以清理一下了，没有完成的可以挪到这里来继续 track。

[BernardXiong]

• 对scons building.py脚本进行清理，可以更好的进行构建；
  • 清晰的模块化划分；
  • 给出Advanced User Guide Document文档，列出其中可以深入的点；

[BernardXiong]

• 🎯 RT-Thread roadmap for long term #8828 里的问题可以清理一下了，没有完成的可以挪到这里来继续 track。

似乎是，如果riscv相关的都完成了，这个long term基本上都完成了？！

[ComerLater]

bsp是不是可以采用子模块submodule方式

[lygstate]

bsp是不是可以采用子模块submodule方式

这样不行，更复杂

[Rbb666]

CI中添加对MDK这类主流SDK的编译看护：https://club.rt-thread.org/ask/question/0fe1823f9507d755.html

[supperthomas]

CI中添加对MDK这类主流SDK的编译看护：https://club.rt-thread.org/ask/question/0fe1823f9507d755.html

有，不过需要你们架runner https://github.com/RT-Thread/rt-thread/blob/master/.github/workflows/action_runner.yml

[BernardXiong]

对源文件中所有fal_cfg.hGPL许可相关的进行清理，FAL组件是Apache License v2的，为什么会出现配置文件许可协议是GPL的。

[BernardXiong]

RTT 仓库下的 license 问题还需要清理，一部分是由 bsp 引入的，如果 bsp 能清理掉，这个问题也能一起解决。

目前我发现的 license 冲突问题都提了 issue 了，总结如下：

• [Bug] bsp/Infineon 目录下有些模块貌似声明为 GPL，会与 RT-Thread 的 Apache 授权产生冲突 #9811
• [Bug] bsp/sparkfun-redv 下有部分文件标识为 GPL，和 RT-Thread 的 Apache 授权冲突 #9810
• [Bug] bsp/stm32/ 下有部分文件标识为 GPL，和 RT-Thread 的 Apache 授权冲突 #9809
• [Bug] libcpu/ppc 下有部分文件标识为 GPL，和 RT-Thread 的 Apache 授权冲突 #9808
• [Bug] tools/env_utility.py 包含 GPL 声明，这个和 RT-thread 的 Apache 授权冲突了 #9801
• [Bug] bsp/nuvoton/libraries/nu_packages/DA9062/da9062_reg.h 是 GPL 声明，和 RT-Thread 的 Apache 授权冲突 #9799
• [Bug] bsp/allwinner 下有一些文件是 GPL license 的，和 RT-Thread 的 Apache 授权冲突 #9797
• [Bug] examples/utest/testcases/posix 下部分代码是 GPL 的，和 RT-Thread 的 Apache 授权冲突 #9796

另外设备树部分借用了很多外部的代码，是 GPL 和 BSD 双 license 的，我不确定对于这种情况，RTT 是不是要加个 NOTICE 声明，虽然 Apache 项目可以包含 BSD 的，这个可能需要专业法律回答一下。

tools下的python脚本暂时都维持GPL许可协议。python代码多是开源的，使用GPL许可协议也希望后续代码进行开源，这部分应该没什么影响。

[lygstate]

bsp是不是可以采用子模块submodule方式

其它内容不变，可以把kernel 和components 拆分出去，然后用 subtree的方式同步回来，参考 rust 对 一些依赖的处理