runtime/include · KaranocaVe/runtime

cann-robotfix: runtime 仓dfx组件代码未进行代码格式化不符合代码规范，需要整改 (#840 )

文件	最后提交记录	最后更新时间
dfx	fix: runtime 仓dfx组件代码未进行代码格式化不符合代码规范，需要整改 (#840) Co-authored-by: GuoWenbo<guowenbo13@h-partners.com> # message auto-generated for no-merge-commit merge: !4361 merge fix-issue-840 into master fix: runtime 仓dfx组件代码未进行代码格式化不符合代码规范，需要整改 (#840) Created-by: GuoWenbo Commit-by: GuoWenbo Merged-by: cann-robot Description: ## 描述 - 修复摘要: runtime 仓 dfx 组件代码未进行代码格式化，不符合代码规范，需要按仓内 `pre-commit` / `clang-format` 规范整改。 - 变更范围按 `/mnt/workspace/.cann_fix/runtime_issue_840_20260819153258/cann-fix-plan.md` 的候选修改点汇总，不在 PR 描述中逐文件展开: - `src/dfx/log` - `src/dfx/trace` - `include/dfx/base/acl_log.h` - `include/dfx/base/alog_pub.h` - `include/dfx/base/log_types.h` - `pkg_inc/base/dlog_pub.h` - `pkg_inc/base/plog.h` - `pkg_inc/trace/atrace_pub.h` - `pkg_inc/trace/atrace_types.h` - `pkg_inc/watchdog/awatchdog.h` - `pkg_inc/watchdog/awatchdog_types.h` - 文件级清单以计划产物 `dfx-log-trace-expanded-files.txt` 和 PR Files changed 为准，PR 描述不展开完整清单，避免描述过长。 - Diff 内容不逐文件展示，本次主体为格式化整改；检视反馈补充了文件末尾换行、宏表达式括号、atrace UT 中已有 `utrace_arm_utest` 目标的顶层依赖入口、stacktrace 覆盖率相关既有 UT 源文件的构建入口，以及线上覆盖率 UT 暴露的 ringbuffer 并发压测用例稳定性、`AtraceStackcoreParse` 包装层覆盖、atrace UT stub 依赖的 adcore 头文件 include 路径和 x86 `ScdThreadsUtest` 栈帧用例稳定性。 ## 变更类型请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue https://gitcode.com/cann/runtime/issues/840 ## 如何测试 - 测试结论: 格式化检查和新增覆盖率 focused 验证 PASS；`ScdUtilUtest.TestScdPtraceAttach` 超时已修复，完整 `utrace_utest` 不再因该用例超过 300s；线上覆盖率包中暴露的 `RraceRbLogUtest` 并发压测波动、`atrace_stackcore_api.c` 0 覆盖、atrace UT `adcore_api.h` 头文件缺失编译问题，以及 x86 `ScdThreadsUtest.TestScdFramesInit/TestScdFramesMemcpyFailed` 依赖真实栈展开导致的波动已补充处理。 - `pre-commit run --files tests/ut/atrace/ut/utrace/testcase/stacktrace_dumper/scd_threads_utest.cc`: PASS - `pre-commit run --files tests/ut/atrace/ut/utrace/CMakeLists.txt tests/ut/atrace/ut/trace_server/CMakeLists.txt`: PASS - `pre-commit run --files tests/ut/atrace/ut/utrace/testcase/trace_rb_log_utest.cc tests/ut/atrace/ut/utrace/testcase/stacktrace_dumper/scd_process_utest.cc`: PASS - `git diff --check`: PASS - `cmake --build build --target utrace_arm_utest -- -j8`: PASS - `cmake --build build --target trace_server_utest -- -j8`: PASS - `cmake --build build --target utrace_utest -j$(nproc)`: PASS - `build/tests/ut/atrace/ut/utrace/utrace_utest --gtest_filter='RraceRbLogUtest.TestMsgNumLTBufferSize:RraceRbLogUtest.TestMsgNumEQBufferSize:RraceRbLogUtest.TestMsgNumGTBufferSize' --gtest_repeat=10 --gtest_break_on_failure`: PASS - `build/tests/ut/atrace/ut/utrace/utrace_utest --gtest_filter='ScdProcessUtest.TestAtraceStackcoreParse'`: PASS - `build/tests/ut/atrace/ut/utrace/utrace_utest --gtest_filter=StacktraceDumperBinUtest.`: PASS, 8/8 passed - `build/tests/ut/atrace/ut/utrace/utrace_utest --gtest_filter=ScdUtilUtest.`: PASS, 20/20 passed；`TestScdPtraceAttach` 约 21-32ms。 - `bash tests/build_ut.sh --ut atrace --target utrace_utest --ut_timeout=300`: PASS, 296/296 passed, 总耗时 23.855s。 - `bash tests/build_ut.sh --ut atrace --target utrace_utest --ut_timeout=300`: PASS；本机为 aarch64，x86-only `ScdThreadsUtest` 不编入本地目标；本次复验生成 UT XML: `utrace_utest` 296/296 passed, `utrace_arm_utest` 2/2 passed, `trace_server_utest` 73/73 passed。 - `bash tests/build_ut.sh --ut atrace --target utrace_utest -c --ut_timeout=300`: UT 阶段 PASS, 296/296 passed；本地生成 `cov/coverage.info`，重点文件覆盖率: `atrace_stackcore_api.c` 100.0%, `stacktrace_dumper_bin.c` 100.0%, `stacktrace_parse.c` 61.7%, `trace_rb_log.c` 90.6%。本地 `genhtml` 阶段因 `/cmd_line` 权限问题退出，不影响 UT 通过和 LCOV 数据生成。 - 变更范围核对: 变更文件均在计划范围或检视反馈补充范围内。 - cann-fix/test report 摘要: - 测试日志包含通过信号。 - 测试日志覆盖计划测试项 1 条。 - Problems: `(none)`。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [ ] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：`feat:`, `fix:`） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息本次变更文件数量较多，PR 描述仅保留计划范围、测试结论和风险说明；完整文件级 diff 请以 PR Files changed 页面为准。 ## 风险和遗留问题 - 风险: 格式化文件数量较多，review 噪声较高。 - 控制: 仅按仓内格式化规则处理计划范围文件，不展开无关模块；通过 `pre-commit clang-format` 和 `git diff --check` 校验。 - 遗留问题: 本地 `genhtml` 阶段存在 `/cmd_line` 权限问题，已保留 `coverage.info` 和 UT XML 作为验证证据；线上环境可继续以平台生成的覆盖率 HTML 为准。 See merge request: cann/runtime!4361	15 天前
external	【Feature】: aclrtGetDeviceInfor接口支持查询SuperPOD的柜信息 Co-authored-by: liguochao1<liguochao1@huawei.com> # message auto-generated for no-merge-commit merge: !4245 merge superpod_chassis_id into master 【Feature】: aclrtGetDeviceInfor接口支持查询SuperPOD的柜信息 Created-by: liguochao1 Commit-by: liguochao1 Merged-by: cann-robot Description: # Pull Request ## 描述 ### 需求背景 Super POD 组网中，服务器、设备、超节点 ID 等拓扑信息已可通过 `aclrtGetDeviceInfo` 查询，但缺少机箱 ID（Chassis ID）的查询能力。为完善 Super POD 拓扑信息查询，需新增 `ACL_DEV_ATTR_SUPER_POD_CHASSIS_ID` 属性，支持上层框架/应用获取机箱 ID 用于资源调度和拓扑感知。 ### 需求方案在 `aclrtDevAttr` / `rtDevAttr` 枚举中新增 `SUPER_POD_CHASSIS_ID = 410U`，并在 Runtime 的 `ApiImpl::GetDeviceInfoByAttr` 映射表中将其映射到驱动接口 `halGetDeviceInfo(MODULE_TYPE_SYSTEM, INFO_TYPE_CHASSIS_ID)`，透传至驱动侧查询。调用链路： `aclrtGetDeviceInfo` → `rtsDeviceGetInfo` → `ApiImpl::GetDeviceInfoByAttr`（查 map 得到 moduleType/infoType）→ `ApiImpl::GetDeviceInfo` → `NpuDriver::GetDevInfo` → `halGetDeviceInfo(devId, MODULE_TYPE_SYSTEM, INFO_TYPE_CHASSIS_ID, &val)` ### 需求范围 INFO_TYPE_CHASSIS_ID目前只有950支持，且不区分A5的组网形态，其他芯片不支持；其他芯片下驱动会返回DRV_ERROR_NOT_SUPPORT错误码，ACL接口对应返回ACL_ERROR_RT_FEATURE_NOT_SUPPORT错误码。 ### 需求变更点 \| 文件 \| 变更 \| \|------\|------\| \| `include/external/acl/acl_rt.h` \| 新增 `ACL_DEV_ATTR_SUPER_POD_CHASSIS_ID = 410U` 枚举值 \| \| `pkg_inc/runtime/runtime/rts/rts_device.h` \| 新增 `RT_DEV_ATTR_SUPER_POD_CHASSIS_ID = 410U` 枚举值 \| \| `src/runtime/api/impl/api_impl.cc` \| `GetDeviceInfoByAttr` 映射表新增 `{RT_DEV_ATTR_SUPER_POD_CHASSIS_ID, {MODULE_TYPE_SYSTEM, INFO_TYPE_CHASSIS_ID}}` \| \| `src/runtime/core/src/common/enum_desc.cc` \| `DevAttrToString` 新增 chassis id 枚举转字符串 \| \| `docs/zh/api_ref/25-02_Enumerations.md` \| API 参考文档补充新枚举值说明 \| ## 变更类型 - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue NA ## 如何测试 ### 前置条件 - 已安装包含本 PR 改动的 CANN runtime 包 - 设备已正常运行（`npu-smi info` 可查询） ### 正常场景 Ascend950： 1. `aclInit(nullptr)` + `aclrtSetDevice(0)` 2. 调用 `aclrtGetDeviceInfo(0, ACL_DEV_ATTR_SUPER_POD_CHASSIS_ID, &value)` 3. 预期：`ret == ACL_SUCCESS`，`value` 为机箱 ID 值 4. 多次查询验证一致性 ### 异常场景（各卡型号通用） 1. `value` 传 `nullptr`：预期返回 `ACL_ERROR_INVALID_PARAM(100000)` 2. `deviceId` 传非法值（如 65535）：预期返回 `ACL_ERROR_RT_PARAM_INVALID(107001)` 3. `attr` 传非法值（如 999）：预期返回 `ACL_ERROR_RT_PARAM_INVALID(107001)` 4. 未 `aclrtSetDevice` 直接查询：预期返回 `ACL_ERROR_RT_PARAM_INVALID(107001)` ### 驱动不支持场景 Ascend910B/ Ascend910C ： 1. `aclInit(nullptr)` + `aclrtSetDevice(0)` 2. 调用 `aclrtGetDeviceInfo(0, ACL_DEV_ATTR_SUPER_POD_CHASSIS_ID, &value)` 3. 预期：`ret == ACL_ERROR_RT_FEATURE_NOT_SUPPORT(207000)` ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：`feat:`, `fix:`） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定 ## 其他信息 - 驱动接口 `halGetDeviceInfo` 由 `libascend_hal.so` 导出，runtime 通过动态链接调用 - Ascend910B/910C 驱动尚未实现 `INFO_TYPE_CHASSIS_ID` 查询，返回 `DRV_ERROR_INVALID_VALUE(3)` See merge request: cann/runtime!4245	15 天前
tsd_client	Initial commit	8 个月前