Shell

是否可以用 cpu ISA 的形式组织。riscv ISA 的常用的几个标准比如 2.2, 20190608, 20191213... 可以具体看一下相关的兼容性，然后以文件夹的形式组织起来。比如 qemu-virt64 就可以包括 `rv64ima`, `rv64v_1_0` 这些文件夹。c908 就可以包括 `rv64ima`, `rv64v_1_0`, [`xthead_*`](https://[github.com](https://github.com/T-head-Semi/thead-extension-spec)/T-head-Semi/thead-extension-spec)

倒不如说 `rt_thread_control(RT_THREAD_CTRL_CHANGE_PRIORITY)` 这个 API 的设计就是这么个逻辑，它只是修改一个“临时”优先级。而优先级翻转同样是修改这个临时优先级。如果用户和 mutex 都这么做了，两边很自然的就冲突了。因为 init_prio 在 mutex 优先级翻转中，就是作为锚定的“真实”优先级。它不可能参考线程的当前优先级，因为它自己就会改变这个变量。所以你说的情况与其说是 bug，应该说这个 API 与 mutex 算法的特性，或者说 rt_thread 这个成员属性的本来意义。 当然，这只是我个人对 `rt_thread_control(RT_THREAD_CTRL_CHANGE_PRIORITY)` 这个 API 的理解。如果要实现你期望的语义，应该有一个修改 init_prio 的 API。当然这个需求合不合理就得另当别论了。

看上去更像是调度器的冲突区保护存在问题。

SMART 现在强制选用 DFS 2.0 了。然后 dfs 2.0 的 devfs 只支持 fops 形式的 RT device 原型。所以有些旧的驱动要主动更新一下。risc-v 的 bsp 就有很多这个问题。 至于这个 issue 提到的问题，可能是一些条件编译的代码没来得及调整了。

> 就目前的C/C++标准来看也没有要求编译器在遇到aligned memory access时必须生成单条汇编指令，比如对int32的赋值完全可以生成4条int8 store来完成。 所以标准 C 给出了 c11 atomic 的补丁。 ```c void rt_tz_set(int32_t offset_sec) { rt_base_t level; level = rt_hw_interrupt_disable(); _current_tz_offset_sec = offset_sec; rt_hw_interrupt_enable(level); } ``` 类似这种代码，符合标准 C 的严谨写法应该是。...

> > 为什么rtt要将atomic和内存墙绑定在一起，而不是显示地提供内存墙的api呢？类似于linux的smp_mb_before_atomic。我理解，这样将是否在atomic操作加内存墙的权利交给开发人员可以提高整体的性能。 > > 建议是再加一个memory_order的参数 \+1。标准 C 更加通用。没必要自己又玩一套。反而让人觉得只会抄 Linux。 可以有一个 `rt_atomic_load_explicit()`

TODO list 可以参考 [Smart SIG RISC-V Issue Tracklist](https://docs.qq.com/sheet/DSWhZbXFmVGVIWEVi?tab=BB08J2) ## 进程管理 - [ ] 参考 aarch64 PR #8672 支持 arch_syscall_restart ## milkv 平台支持 完善 milkv 平台的硬件适配和内核支持，特别是地址空间管理适配到内核地址重映射的模式，确保 libc 和用户程序能够使用更加完善的虚拟内存支持。推进 milkv 平台应用验证和集成测试，提升平台的稳定性和功能完整性，使其成为一个高实时、可靠且多功能的开发平台。 -...

看了一下代码。`rt_schedule()` 的冲突区就是用 `scheduler_lock_nest` 保护的，自然走到这里这个 nest 不是 0。如果外面又主动锁住了调度器，这个 nest 就会大于 1.所以这里的判断是这么处理的。你还可以写一些样例代码，用 gdb 单步跟一下确认一下。这样也很容易理解实际代码运行起来的状态，单看源代码很多时候是会被误导的。 提示一下，`rt_hw_interrupt_disable` 会重载为 `rt_cpus_lock`。cpus lock 会通过 nest 递增标志调度器不可用。

RT_ASSERT 中是否也可以添加文件名的输出？ https://github.com/RT-Thread/rt-thread/blob/aee1bd532ed4b21e2eb2c5cfa32fd8af0b579bf3/include/rtthread.h#L715-L719

> > RT_ASSERT 中是否也可以添加文件名的输出？ > > https://github.com/RT-Thread/rt-thread/blob/aee1bd532ed4b21e2eb2c5cfa32fd8af0b579bf3/include/rtthread.h#L715-L719 > > 好像文件名这个东西，不同的编译器行为不一样，我记得哪个编译器会把全路径打出来，就很烦人。。。 VS Code 有路径和行数可以直接生成超链接跳转，还是很方便的。  显示格式可以通过宏配置，这样有需要可以打开。特别是 assert。现在查 assert 还要全局搜索一下函数名，可能还有重名，查起来不是很方便……