v5.1.1 需要推进的点

[mysterywolf]

• 内核：整理kservice.c/.h
• 部分BSP的HAL库需要拆成软件包的方式，不能把HAL库嗷嗷往主仓提交，例如STM32的HAL库
  • [bsp][stm32] remove L4 local HAL library #8907
• pin框架read返回值从rt_uint8_t 改为rt_ssize_t
• 使用os.join.path函数，而不是直接用/连接路径
• 整理BSP
  • MM32
  • NXP
  • Infineon
• CH32 上CI看护
• HPM上CI看护
• 重构完善scons --dist打包命令

[BernardXiong]

发布env v2.0，启用python中的venv环境，并提供软件包下载功能。

[wirano]

不能再同意第二条了😂

[pineapple-man]

stm32中的HAL库真的太多了,感觉BSP就显的很乱

[chnykn]

第二条非常有必要

[meng-plus]

整个仓库都大的太恐怖了全是bsp占用

[charlown]

怎么拆分厂家的驱动库做成软件包的形式，有个范例就好了
ch32 ci看护是arm还是risc-v出了问题么？沁恒最近在risc-v方面大力发展, 他们arm的芯片很久没出新的

[mr-cn]

建议BSP把具体的board也拆分出去，主仓库保留对chip的支持就好了

[dujunqiu]

stm32用的HAL库，gd32用的标准库，能统一一下就好了

[meng-plus]

我最近在玩repo 我认为他是个很好的多仓库管理工具，是否考虑往这个方向发展下
即使同一个芯片的HAL库官方也在持续更新，拆包有助于精简仓库占用，独立更好的维护每个组件

https://git-repo.info/zh_cn/docs/multi-repos/overview/

[GPTKEY]

可以考虑：对于STM32 直接修改构建脚本， 去掉BSP中的HAL库，直接使用CubeMX生成的HAL库，这样兼容性更强

[dujunqiu]

我最近在玩repo 我认为他是个很好的多仓库管理工具，是否考虑往这个方向发展下 即使同一个芯片的HAL库官方也在持续更新，拆包有助于精简仓库占用，独立更好的维护每个组件

好主意，我看NXP的github库，已经拆分成多个子模块独立管理了

[wdfk-prog]

可以考虑：对于STM32 直接修改构建脚本， 去掉BSP中的HAL库，直接使用CubeMX生成的HAL库，这样兼容性更强

• 的确如此;甚至对于驱动中有关初始化配置的部分,都可以去除;保留一些常用配置修改既可;
• 不然对于每个系列都要兼容,不仅代码难看,而且维护起来也不容易,加个功能容易在其他没验证的系列出问题
• 但是如果是CubeMx生成的Hal库,就需要用户对驱动有意识,自行进行正确的配置

[sulfurandcu]

• rt-thread repo
• bsp repo
  • stm32
  • gd32
  • ...
  • rt-thread @ master

example: https://github.com/sisong/HPatchLite/tree/main

↑这么搞有什么问题/难度吗？#9519

[mysterywolf]

submodule方式无法进行gitee同步备份，国内拉取会出问题的。

[aozima]

submodule

仅技术上回复下：
git submodule的url可以使用相对地址，这样不管源地址是ssh还是https，或是换了服务器域，只要相对路径没变就能引用到。

[yuqingli05]

建议BSP把具体的board也拆分出去，主仓库保留对chip的支持就好了

老早前我提过，被否了。现在越来越大，很多用户只是做自己的工程，我感觉更有必要了。主仓库留几个经典案例就行了