[rt-smart] PV_OFFSET as a variable #6904
Conversation
components/mm/mm_kmem.c
Outdated
| { | ||
| rt_aspace_print_all(&rt_kernel_space); | ||
| } | ||
| #ifdef RT_USING_FINSH |
There was a problem hiding this comment.
MSH_CMD_EXPORT不需要添加RT_USING_FINSH的条件宏，包含了rtthread.h头文件，在这个其中会自动处理这个定义。
另外，后面应该是会减少list_xx的命令导出，而是演变成list device | mutex | ...等的方式。所以也可以不需要在此处加入这样的命令导出。
There was a problem hiding this comment.
演变成list device | mutex | ...等的方式。
但是这样不利于 TAB 键自动补全。。。
There was a problem hiding this comment.
我的想法是tab自动补全二级命令这个功能可以不用考虑了，因为如果增加tab补全二级命令的逻辑，整个msh的ROM体积又会增加，别偷懒，还是手敲上去就好了。
There was a problem hiding this comment.
我的想法是tab自动补全二级命令这个功能可以不用考虑了，因为如果增加tab补全二级命令的逻辑，整个msh的ROM体积又会增加，别偷懒，还是手敲上去就好了。
所以建议保留 list_xxx 的写法(至少设为可选的); 自动补全二级命令确实没有太大必要(包括自动补全文件路径)，并且不易实现 (会一定程度破坏现有的 api 状态)，即使添加了，也应该设为可选的。
There was a problem hiding this comment.
list_xxx 是早期 finish使用的一种写法，是采用的C-Style函数命名方式，随着C-Style命令被淘汰，msh下就可以全部缩减为list命令了，否则list_xx一大串太丑了
There was a problem hiding this comment.
否则list_xx一大串太丑了
个人认为在没有二级命令补全支持的情况下，list_xxx 是优于 list xxx 的。因为相较于让命令/代码看起来'好看' 的需要，保障易用性更加重要一些(估计也只有经常使用 linux 的才会知道 TAB 补全功能有多么重要了。。。)。 其次，个人认为C-Style命令 指的是类似于函数调用的参数写法，而不是命令名的写法; 之所以淘汰也不是因为不好看，而是已经有 python 等脚本语言可以代替它了。
There was a problem hiding this comment.
list有help命令 或者只敲list以及二级命令敲错的情况下会自动列出所有二级命令以供参考
拉取/合并请求描述：(PR description)
[
Remove PV_OFFSET from BSP configuration which is verbose and error-prone. A global variable
rt_pv_offsetwhich is calculated dynamically at boot time and its macro aliasPV_OFFSETis added instead.]
当前拉取/合并请求的状态 Intent for your PR
必须选择一项 Choose one (Mandatory):
代码质量 Code Quality：
我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:
#if 0代码，不包含已经被注释了的代码 All redundant code is removed and cleaned up