| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
【PR】: codecheck：删除冗余extern声明 Co-authored-by: Leon0930<lili233@huawei.com> # message auto-generated for no-merge-commit merge: !4696 merge fix/hook-visibility into master 【PR】: codecheck：删除冗余extern声明 Created-by: Leon0930 Commit-by: Leon0930 Merged-by: cann-robot Description: # Pull Request ## 描述 改为注册模式后，劫持功能libruntime.so不再需要部分extern声明。冗余extern声明删除。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> 无 ## 如何测试 执行已有用例，LD_PRELOAD成功；仅加载libruntime.so加载成功，hook降级；先加载libruntime.so后加载libacl_rt.so，hook成功 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 无 See merge request: cann/runtime!4696 | 2 天前 | |
fix: log冗余头文件整改，消除软链与多副本 Co-authored-by: GuoWenbo<guowenbo13@h-partners.com> # message auto-generated for no-merge-commit merge: !4643 merge fix/issue831-log-header-normalization into master fix: log冗余头文件整改，消除软链与多副本 Created-by: GuoWenbo Commit-by: GuoWenbo Merged-by: cann-robot Description: ## 描述 按 issue #831 要求，消除 log 组件冗余头文件，按「对外开放程度 include > pkg_inc > src」归一。整改覆盖两层： - **源码树**： include/pkg_inc/src 三层下每个头文件只保留一份实体 - **发布包**：同名头文件只保留一份实体，其余为软链 本 PR 为单个提交。 ## 一、源码树整改 **保留 4 份实体**：include/dfx/base/{log_types.h,alog_pub.h}、pkg_inc/base/{dlog_pub.h,plog.h}。 | 文件 | 原性质 | 处理 | 与保留份的差异 | |---|---|---|---| | pkg_inc/base/log_types.h | 软链 → ../../include/dfx/base/log_types.h | 删除 | 无内容差异 | | src/dfx/log/inc/toolchain/log_types.h | 实体副本 3597B | **改为软链** → include/dfx/base/log_types.h | 多 DQS = 13（已合并入保留份）；无行尾换行 | | src/dfx/log/inc/toolchain/dlog_pub.h | 实体副本 8324B | **改为软链** → pkg_inc/base/dlog_pub.h | 少 4 行注释 | | src/dfx/log/inc/toolchain/alog_pub.h | 实体副本 1725B | 删除 | sha256 与保留份完全相同 | | src/dfx/log/inc/toolchain/plog.h | 实体副本 1967B | 删除 | 少 1 个空行 | 整改后 4 个头文件各仅 1 份实体，src 层重复内容归零。 trace 组件（pkg_inc/trace、pkg_inc/watchdog、src/dfx/trace/inc/toolchain）逐个排查无多副本，零改动。 ### 为什么 src 层保留两个软链 issue 的目标是消除**冗余副本**（同一头文件多份可独立漂移的实体）。软链不构成副本：它与保留份始终同一内容，无漂移风险。 保留这两个软链是**防御性**的，让 include path 上带 src/dfx/log/inc/toolchain 的消费方继续能按短名解析。 需要说明：**当前仓内没有任何代码依赖这两个软链**。全仓 #include "toolchain/log_types.h" 与 "toolchain/dlog_pub.h" 引用数均为 0；按短名引用的消费方，其 include path 也都不含 inc/toolchain（抽查 10 个，9 个无该路径，1 个仅有 inc）。所以它们是为树外联编与后续新增代码留的兼容层，不是为修复仓内某处引用。 alog_pub.h 与 plog.h 未保留软链：前者在 src 下无对应引用，后者原有 3 处 #include "toolchain/plog.h" 已改为短名。 ## 二、发布包整改 改 scripts/package/module/ascend/RuntimeInc.xml（一增一删两行），使发布包内同名头文件只有一份实体。 整改前 log_types.h 在发布包内是**两份独立实体**（include/base/ 与 pkg_inc/base/ 各一份，内容相同但互不关联），因为两条 install 规则都指向源码树同一文件。整改后归一为「include/base 一份实体 + 其余软链指向它」： | 发布包路径 | 整改前 | 整改后 | |---|---|---| | include/base/log_types.h | 实体 | **实体（唯一实体）** | | pkg_inc/base/log_types.h | 实体 | **软链 → ../../include/base/log_types.h** | | include/toolchain/log_types.h | 软链 → ../../pkg_inc/base/log_types.h | 软链 → **../base/log_types.h** | 发布包 log 相关文件由 **8 实体 + 2 软链** 变为 **7 实体 + 3 软链**，总数仍为 10，无增无减。 include/toolchain/log_types.h 的指向变更是连带的：它原先指向 pkg_inc/base 那份，而那份现已改为软链，故改为直接指向实体，避免软链套软链。对下游无影响（路径不变、读到内容不变）。 实现方式沿用仓内既有先例：package.cmake 在 CPack staging 放实体，XML 的 install_softlink 再把列为软链目标的替换为软链，相对路径由打包框架自动计算。prof_api.h 即此模式（package.cmake 装 2 份，XML 转 1 份为软链，最终 1 实体 3 软链）。package.cmake 本次无需改动。 其余 6 个头文件（alog_pub.h、acl_log.h、err_msg.h、dlog_pub.h、err_mgr.h、plog.h）在发布包内本就各仅 1 份实体，零改动。 ## 编译依赖适配 **主路径**：slog_headers **新增** include/dfx/base（src/dfx/log/liblog/slog/CMakeLists.txt）—— 一处覆盖 153 个 link 该 target 的消费者，target_link_libraries 会传播 INTERFACE include 路径。 原有 4 条路径（${TOOLAHCIN_LOG_DIR}/inc、inc/toolchain、.../pkg_inc、.../pkg_inc/base）**全部保留**。本 PR 对 slog_headers 是纯新增、不删任何路径，消费方现有依赖不受影响，**外部组件无需任何适配**（新路径集合是原 4 条的超集）。 **硬路径**：25 个 cmake 文件用 include_directories() 硬写路径、拿不到 INTERFACE 传播，逐个补齐（tests/ut 11 个、tests/depends 7 个、src 7 个）。其中 src/acl/aclrt_impl 是为下述短名改动新增。 **引用形式收敛**：4 处前缀引用改为短名，与仓内主流写法（plog.h 10 处、log_types.h 7 处、dlog_pub.h 23 处均为短名）一致： - src/acl/aclrt_impl/acl.cpp："toolchain/plog.h" → "plog.h"（该 target 不 link slog_headers，同时补 pkg_inc/base 路径；已验证不补则 fatal error: plog.h: No such file or directory） - tests/ut/runtime/runtime/stub/log_stub.cc："toolchain/plog.h" → "plog.h"（零 cmake 改动） - src/dfx/msprof/.../devprof_drv_aicpu.cpp："base/log_types.h" → "log_types.h"（零 cmake 改动） - src/tprt/feature/inc/tprt_base.hpp：**保持** "base/plog.h" 前缀形式 tprt_base.hpp 保留前缀形式是刻意的：它是头文件，改短名会把「须有 pkg_inc/base 在路径上」的要求传导给所有包含它的下游，而前缀形式只要求有 pkg_inc，约束宽得多。仓内 pkg_inc/base/err_mgr.h 同样用 #include "base/err_msg.h"，是同一考虑。 **其他**：cmake/package.cmake 删除已失效的 install 段（其引用的源文件已删除，不删会导致 install 阶段失败）；3 个 cmake 文件补齐缺失的 license header（src/platform、tests/ut/platform、tests/ut/aicpu_sched/aicpu_kernel/ut，本 PR 改动这些文件触发 OAT 检查，原文件即无 header）。 ## 变更类型 - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） ## 关联的Issue https://gitcode.com/cann/runtime/issues/831 ## 如何测试 1. 构建：bash build.sh --pkg --pkg-type=run -j16 —— 应输出 build success!，0 error 2. 装包并核对发布包结构： bash bash build_out/cann-npu-runtime_9.2.0_linux-aarch64.run --devel --quiet --install-path=<PATH> N=<PATH>/cann/aarch64-linux ls -la $N/include/base/ $N/pkg_inc/base/ $N/include/toolchain/ # 预期：include/base/log_types.h 为唯一实体， # pkg_inc/base/log_types.h 与 include/toolchain/log_types.h 为软链 3. 同名实体唯一性与软链有效性： bash for d in include/base pkg_inc/base include/toolchain; do for f in $N/$d/*; do [ -L "$f" ] || basename "$f"; done done | sort | uniq -c | awk '$1>1{print "重复实体:",$2}' # 应无输出 find $N/include/base $N/pkg_inc/base $N/include/toolchain -type l \ -exec test -e {} \; -print | wc -l # 应为 3（全部有效） grep -nE "HIXL|DQS|DEVMM" $N/include/base/log_types.h # DQS=13 应在 12 与 22 之间 4. 源码树软链： bash readlink -e src/dfx/log/inc/toolchain/{log_types.h,dlog_pub.h} # 应指向保留实体 git ls-tree HEAD src/dfx/log/inc/toolchain/ # 应为 mode 120000 ## 验证结论 **已完成全量构建与装包实测**（含发布包结构归一） | 项 | 结果 | |---|---| | 完整构建 | bash build.sh --pkg --pkg-type=run -j16 → build success!，0 个 error: | | 装包 | cann-npu-runtime_9.2.0_linux-aarch64.run（37MB）以 --devel 装至独立路径成功 | | 发布包同名实体唯一性 | **无任何文件名对应 >1 个实体**（按 basename 统计逐一确认） | | 发布包实体/软链构成 | **7 实体 + 3 软链 = 10**（整改前 8 实体 + 2 软链 = 10），总数无增无减 | | 3 条软链有效性 | 全部有效不悬空：pkg_inc/base/log_types.h → ../../include/base/log_types.h、include/toolchain/log_types.h → ../base/log_types.h、include/toolchain/slog.h → ../../pkg_inc/base/dlog_pub.h | | 经软链读取一致性 | 3 条 log_types.h 路径读到内容 sha256 全同（cf883df89a3a） | | 发布包内容差异 | 相对整改前**仅 log_types.h 一处**：3567B → 3598B，diff 输出仅 > DQS = 13, 一行 | | 其余 6 个头文件 | sha256 与整改前**完全相同**（alog_pub.h 3771757b5e、dlog_pub.h ab887476d1、plog.h c8e1f91404、err_mgr.h e09c8237ea、err_msg.h 5ded505fa2、acl_log.h 660c8a844f） | | 源码树软链未外泄 | 发布包内搜 *log/inc/toolchain* 无结果；内部头 slog_api.h 未被打包 | | 源码树软链有效性 | 2 条 readlink -e 均解析到保留实体；git 记为 mode 120000 | | 短名解析 | 3 处改动均验证可解析；acl.cpp 做了反向对照（不补路径则编译失败） | | trace 回归 | trace 侧零改动 | **对照基线说明**：整改前发布包数据取自本仓构建产物 staging，其 10 个文件 sha256 与 HEAD~1 的 git 对象逐项吻合，可作为可信 before 基线。发布包结构归一前后的对比，取自同一台环境两次独立装包（--install-path 指向不同目录）。 **预处理等价性验证**（源码树改动部分） | 项 | 结果 | |---|---| | 预处理逐字节比对 | 整改前后均 8888 行，sha256 均 7209fcfc54ca，diff 无输出 | 做法：git stash 将工作区退回同一基线，用相同 include path 对真实源文件（plog_device_log.c）预处理一次，恢复改动后再预处理一次，两份输出 sha256 完全相同 —— 证明删副本、调 include path 对编译器最终看到的 token 流零影响。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 ### 对外接口变更（需兼容性评审） **新增一个对外可见枚举 DQS = 13** 该值原仅存在于源码树 src/dfx/log/inc/toolchain/log_types.h。整改前发布包两处 log_types.h 均取自 include/dfx/base 版而**不含 DQS**（已装包实测确认：整改前 3567B / f1a36a756418，正是 include/dfx/base 版的 sha），故该值此前从未真正对外，本次归并是首次外露。 保留它是为避免删除 src 副本时丢失定义。实测确认它填补 HIXL = 12 与 DEVMM = 22 之间空位（新包中位于第 58 行，前后分别为 57 行 HIXL = 12 与 59 行 DEVMM = 22），**不改变任何既有枚举值**。 ### 发布包结构变更对下游的影响 pkg_inc/base/log_types.h 由实体变为软链，include/toolchain/log_types.h 软链指向由 ../../pkg_inc/base/log_types.h 改为 ../base/log_types.h。 **对正常使用无影响**：三条路径均存在、均可读、内容一致（实测 sha256 相同）。#include 行为不变。 可能受影响的场景：以 -type f 精确匹配实体文件的打包/校验脚本，或强校验软链目标字符串的工具。若下游有此类校验，需同步更新预期值。 ### 删除 install(FILES) 段是否导致发布包文件变少 **不会。已装包实测确认发布包 include/base/ 下 4 个文件一个不少，清单与整改前逐项一致。** 被删的那段与 package.cmake:116 的 install(DIRECTORY ${RUNTIME_DIR}/include/dfx/base/) 目标目录完全相同，且该目录已包含被删段要装的两个文件（alog_pub.h、log_types.h），故被删段是**完全冗余的重复安装**。 实测证据：整改前发布包 include/base/log_types.h 为 3567B / f1a36a756418，等于整改前 include/dfx/base/log_types.h 的 sha，而**不等于**被删段的源 src/dfx/log/inc/toolchain/log_types.h（3597B / bc708128af41）—— 说明 install(DIRECTORY) 执行在后并覆盖了 install(FILES)，被删段本就是死代码。alog_pub.h 两个源 sha 完全相同，谁覆盖谁一致。 删除它的必要性：它引用的源文件已随本次整改删除，不删会导致 install 阶段失败。 ### include/toolchain/slog.h 是历史兼容别名 发布包 include/toolchain/slog.h 指向 pkg_inc/base/dlog_pub.h（实测两者 sha 相同），并非源码树中真正的 slog.h。该别名同由 RuntimeInc.xml 的 install_softlink 生成，**本次未改动该条目**，别名语义与指向均不变（其目标 dlog_pub.h 仍是实体）。源码树中真正的 slog.h（内部头）与 slog_api.h 均不打包，已实测确认。 ### git diff --check 说明 git diff --check 会报 trailing whitespace。已用最小工程复现确认：**纯 CRLF 文件新增任何一行都会被报，与内容无关**（git 把 \r 视作行尾空白）。报警文件中多数为纯 CRLF，混合行尾文件的 LF 行数与基线完全一致（未引入行尾变更）。本 PR 未引入真实的尾随空白。 ### 未闭环边界 UT 侧未覆盖验证。tests/ut/platform 的 platform_llt 编译产品源文件 src/platform/acl_platform.cpp 但未提供 securec 路径，tests/build_ut.sh -u 在该处即 fatal error: securec.h，阻塞在 UT 链最前端。该问题在整改前的基线上同样存在（已用 git checkout HEAD~1 确认同一处同一错误），非本 PR 引入。 See merge request: cann/runtime!4643 | 2 天前 | |
feat: 新增arch9201的aic、aiv任务基础适配 Co-authored-by: mintcoffee<zhangtingrui3@huawei.com> # message auto-generated for no-merge-commit merge: !4115 merge 0807 into master feat: 新增arch9201的aic、aiv任务基础适配 Created-by: mintcoffee Commit-by: mintcoffee Merged-by: cann-robot Description: # Pull Request ## 描述 新增arch9201的aic、aiv任务基础适配 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1.Runtime构建通过，v100、v200/V201和camodel相关目标可正常编译。 2.在1952/A5/A6环境上执行相关aic/aiv/mix用例，plog日志观察到aic/aiv/mix算子任务正常下发。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/runtime!4115 | 20 天前 | |
【Profiling】单算子调优修复下发PMU事件携带异常前缀的问题 Co-authored-by: chenminghao11<chenminghao11@hisilicon.com> # message auto-generated for no-merge-commit merge: !4691 merge compute into master 【Profiling】单算子调优修复下发PMU事件携带异常前缀的问题 Created-by: chenminghao11 Commit-by: chenminghao11 Merged-by: cann-robot Description: # Pull Request ## 描述 请清晰准确地描述本次 Pull Request 的意图和变更内容。 单算子调优修复下发PMU事件携带异常前缀的问题 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 2. ## 核对清单 <!-- [x] 表示选中 --> - [ ] 我的代码遵循了项目的代码风格 - [ ] 我已对代码进行了自测 - [ ] 我已更新了相关的文档 - [ ] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [ ] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/runtime!4691 | 2 天前 | |
fix: 修复 rtBinaryGetFunctionCount/rtBinaryEnumerateFunctions 静态检查告警 Co-authored-by: chenyang<2082464740@qq.com> # message auto-generated for no-merge-commit merge: !4664 merge warn2 into master fix: 修复 rtBinaryGetFunctionCount/rtBinaryEnumerateFunctions 静态检查告警 Created-by: weixin_51634168 Commit-by: chenyang Merged-by: cann-robot Description: # fix: 修复 rtBinaryGetFunctionCount/rtBinaryEnumerateFunctions 静态检查告警 ## 描述 修复 Binary 相关新增接口的静态扫描告警（G.CNS.04-CPP、A7-1-3、M5-0-15），不涉及任何行为变更： 1. src/acl/aclrt_impl/kernel.cpp:198：aclrtBinaryGetFunctionCountImpl 的 binHandle 参数const aclrtBinHandle → aclrtBinHandle const（A7-1-3：CV 限定词应置于 typedef 名右侧）， 与同文件 aclrtBinaryEnumerateFunctionsImpl 风格统一。 2. src/inc/runtime/inner_kernel.h:145 + src/runtime/api/api_c_kernel.cc:447： rtBinaryGetFunctionCount 的 count 参数 uint32_t* count → uint32_t* const count（G.CNS.04：指针参数应使用 const 修饰）。 3. src/runtime/api/api_c_standard_soc.cc:2053/2055：rtBinaryEnumerateFunctions 中*(funcHandles + i) → funcHandles[i]（M5-0-15：数组索引应是指针运算的唯一形式）。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如需关联 Issue 请在页面右侧"关联Issue"部分添加相应 Issue 链接 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 已核对所有调用点（acl 层 kernel.cpp:204、UT mock、生成 stub）：参数顶层 const 不改变 函数类型与 ABI，funcHandles[i] 与原指针运算语义等价，编译兼容性无影响。 2. 建议合入前执行流水线构建，并定向回归 LLT 用例： rt_utest_api_kernel.cc 中 rtBinaryGetFunctionCount 相关用例、 acl_runtime_unittest.cpp 中 aclrtBinaryGetFunctionCount 相关用例。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档（本次变更不涉及文档） - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定 See merge request: cann/runtime!4664 | 3 天前 | |
feat: update .pre-commit-config.yaml for mmpa & error_manager Co-authored-by: likun104<likun104@h-partners.com> # message auto-generated for no-merge-commit merge: !3771 merge br_update_pre-commit-config.yaml into master feat: update .pre-commit-config.yaml for mmpa & error_manager Created-by: likun104 Commit-by: likun104 Merged-by: cann-robot Description: # Pull Request ## 描述 为mmpa & error_manager更新“.pre-commit-config.yaml”文件中的配置 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 流水线跑通过 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/runtime!3771 | 1 个月前 | |
fix: log冗余头文件整改，消除软链与多副本 Co-authored-by: GuoWenbo<guowenbo13@h-partners.com> # message auto-generated for no-merge-commit merge: !4643 merge fix/issue831-log-header-normalization into master fix: log冗余头文件整改，消除软链与多副本 Created-by: GuoWenbo Commit-by: GuoWenbo Merged-by: cann-robot Description: ## 描述 按 issue #831 要求，消除 log 组件冗余头文件，按「对外开放程度 include > pkg_inc > src」归一。整改覆盖两层： - **源码树**： include/pkg_inc/src 三层下每个头文件只保留一份实体 - **发布包**：同名头文件只保留一份实体，其余为软链 本 PR 为单个提交。 ## 一、源码树整改 **保留 4 份实体**：include/dfx/base/{log_types.h,alog_pub.h}、pkg_inc/base/{dlog_pub.h,plog.h}。 | 文件 | 原性质 | 处理 | 与保留份的差异 | |---|---|---|---| | pkg_inc/base/log_types.h | 软链 → ../../include/dfx/base/log_types.h | 删除 | 无内容差异 | | src/dfx/log/inc/toolchain/log_types.h | 实体副本 3597B | **改为软链** → include/dfx/base/log_types.h | 多 DQS = 13（已合并入保留份）；无行尾换行 | | src/dfx/log/inc/toolchain/dlog_pub.h | 实体副本 8324B | **改为软链** → pkg_inc/base/dlog_pub.h | 少 4 行注释 | | src/dfx/log/inc/toolchain/alog_pub.h | 实体副本 1725B | 删除 | sha256 与保留份完全相同 | | src/dfx/log/inc/toolchain/plog.h | 实体副本 1967B | 删除 | 少 1 个空行 | 整改后 4 个头文件各仅 1 份实体，src 层重复内容归零。 trace 组件（pkg_inc/trace、pkg_inc/watchdog、src/dfx/trace/inc/toolchain）逐个排查无多副本，零改动。 ### 为什么 src 层保留两个软链 issue 的目标是消除**冗余副本**（同一头文件多份可独立漂移的实体）。软链不构成副本：它与保留份始终同一内容，无漂移风险。 保留这两个软链是**防御性**的，让 include path 上带 src/dfx/log/inc/toolchain 的消费方继续能按短名解析。 需要说明：**当前仓内没有任何代码依赖这两个软链**。全仓 #include "toolchain/log_types.h" 与 "toolchain/dlog_pub.h" 引用数均为 0；按短名引用的消费方，其 include path 也都不含 inc/toolchain（抽查 10 个，9 个无该路径，1 个仅有 inc）。所以它们是为树外联编与后续新增代码留的兼容层，不是为修复仓内某处引用。 alog_pub.h 与 plog.h 未保留软链：前者在 src 下无对应引用，后者原有 3 处 #include "toolchain/plog.h" 已改为短名。 ## 二、发布包整改 改 scripts/package/module/ascend/RuntimeInc.xml（一增一删两行），使发布包内同名头文件只有一份实体。 整改前 log_types.h 在发布包内是**两份独立实体**（include/base/ 与 pkg_inc/base/ 各一份，内容相同但互不关联），因为两条 install 规则都指向源码树同一文件。整改后归一为「include/base 一份实体 + 其余软链指向它」： | 发布包路径 | 整改前 | 整改后 | |---|---|---| | include/base/log_types.h | 实体 | **实体（唯一实体）** | | pkg_inc/base/log_types.h | 实体 | **软链 → ../../include/base/log_types.h** | | include/toolchain/log_types.h | 软链 → ../../pkg_inc/base/log_types.h | 软链 → **../base/log_types.h** | 发布包 log 相关文件由 **8 实体 + 2 软链** 变为 **7 实体 + 3 软链**，总数仍为 10，无增无减。 include/toolchain/log_types.h 的指向变更是连带的：它原先指向 pkg_inc/base 那份，而那份现已改为软链，故改为直接指向实体，避免软链套软链。对下游无影响（路径不变、读到内容不变）。 实现方式沿用仓内既有先例：package.cmake 在 CPack staging 放实体，XML 的 install_softlink 再把列为软链目标的替换为软链，相对路径由打包框架自动计算。prof_api.h 即此模式（package.cmake 装 2 份，XML 转 1 份为软链，最终 1 实体 3 软链）。package.cmake 本次无需改动。 其余 6 个头文件（alog_pub.h、acl_log.h、err_msg.h、dlog_pub.h、err_mgr.h、plog.h）在发布包内本就各仅 1 份实体，零改动。 ## 编译依赖适配 **主路径**：slog_headers **新增** include/dfx/base（src/dfx/log/liblog/slog/CMakeLists.txt）—— 一处覆盖 153 个 link 该 target 的消费者，target_link_libraries 会传播 INTERFACE include 路径。 原有 4 条路径（${TOOLAHCIN_LOG_DIR}/inc、inc/toolchain、.../pkg_inc、.../pkg_inc/base）**全部保留**。本 PR 对 slog_headers 是纯新增、不删任何路径，消费方现有依赖不受影响，**外部组件无需任何适配**（新路径集合是原 4 条的超集）。 **硬路径**：25 个 cmake 文件用 include_directories() 硬写路径、拿不到 INTERFACE 传播，逐个补齐（tests/ut 11 个、tests/depends 7 个、src 7 个）。其中 src/acl/aclrt_impl 是为下述短名改动新增。 **引用形式收敛**：4 处前缀引用改为短名，与仓内主流写法（plog.h 10 处、log_types.h 7 处、dlog_pub.h 23 处均为短名）一致： - src/acl/aclrt_impl/acl.cpp："toolchain/plog.h" → "plog.h"（该 target 不 link slog_headers，同时补 pkg_inc/base 路径；已验证不补则 fatal error: plog.h: No such file or directory） - tests/ut/runtime/runtime/stub/log_stub.cc："toolchain/plog.h" → "plog.h"（零 cmake 改动） - src/dfx/msprof/.../devprof_drv_aicpu.cpp："base/log_types.h" → "log_types.h"（零 cmake 改动） - src/tprt/feature/inc/tprt_base.hpp：**保持** "base/plog.h" 前缀形式 tprt_base.hpp 保留前缀形式是刻意的：它是头文件，改短名会把「须有 pkg_inc/base 在路径上」的要求传导给所有包含它的下游，而前缀形式只要求有 pkg_inc，约束宽得多。仓内 pkg_inc/base/err_mgr.h 同样用 #include "base/err_msg.h"，是同一考虑。 **其他**：cmake/package.cmake 删除已失效的 install 段（其引用的源文件已删除，不删会导致 install 阶段失败）；3 个 cmake 文件补齐缺失的 license header（src/platform、tests/ut/platform、tests/ut/aicpu_sched/aicpu_kernel/ut，本 PR 改动这些文件触发 OAT 检查，原文件即无 header）。 ## 变更类型 - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） ## 关联的Issue https://gitcode.com/cann/runtime/issues/831 ## 如何测试 1. 构建：bash build.sh --pkg --pkg-type=run -j16 —— 应输出 build success!，0 error 2. 装包并核对发布包结构： bash bash build_out/cann-npu-runtime_9.2.0_linux-aarch64.run --devel --quiet --install-path=<PATH> N=<PATH>/cann/aarch64-linux ls -la $N/include/base/ $N/pkg_inc/base/ $N/include/toolchain/ # 预期：include/base/log_types.h 为唯一实体， # pkg_inc/base/log_types.h 与 include/toolchain/log_types.h 为软链 3. 同名实体唯一性与软链有效性： bash for d in include/base pkg_inc/base include/toolchain; do for f in $N/$d/*; do [ -L "$f" ] || basename "$f"; done done | sort | uniq -c | awk '$1>1{print "重复实体:",$2}' # 应无输出 find $N/include/base $N/pkg_inc/base $N/include/toolchain -type l \ -exec test -e {} \; -print | wc -l # 应为 3（全部有效） grep -nE "HIXL|DQS|DEVMM" $N/include/base/log_types.h # DQS=13 应在 12 与 22 之间 4. 源码树软链： bash readlink -e src/dfx/log/inc/toolchain/{log_types.h,dlog_pub.h} # 应指向保留实体 git ls-tree HEAD src/dfx/log/inc/toolchain/ # 应为 mode 120000 ## 验证结论 **已完成全量构建与装包实测**（含发布包结构归一） | 项 | 结果 | |---|---| | 完整构建 | bash build.sh --pkg --pkg-type=run -j16 → build success!，0 个 error: | | 装包 | cann-npu-runtime_9.2.0_linux-aarch64.run（37MB）以 --devel 装至独立路径成功 | | 发布包同名实体唯一性 | **无任何文件名对应 >1 个实体**（按 basename 统计逐一确认） | | 发布包实体/软链构成 | **7 实体 + 3 软链 = 10**（整改前 8 实体 + 2 软链 = 10），总数无增无减 | | 3 条软链有效性 | 全部有效不悬空：pkg_inc/base/log_types.h → ../../include/base/log_types.h、include/toolchain/log_types.h → ../base/log_types.h、include/toolchain/slog.h → ../../pkg_inc/base/dlog_pub.h | | 经软链读取一致性 | 3 条 log_types.h 路径读到内容 sha256 全同（cf883df89a3a） | | 发布包内容差异 | 相对整改前**仅 log_types.h 一处**：3567B → 3598B，diff 输出仅 > DQS = 13, 一行 | | 其余 6 个头文件 | sha256 与整改前**完全相同**（alog_pub.h 3771757b5e、dlog_pub.h ab887476d1、plog.h c8e1f91404、err_mgr.h e09c8237ea、err_msg.h 5ded505fa2、acl_log.h 660c8a844f） | | 源码树软链未外泄 | 发布包内搜 *log/inc/toolchain* 无结果；内部头 slog_api.h 未被打包 | | 源码树软链有效性 | 2 条 readlink -e 均解析到保留实体；git 记为 mode 120000 | | 短名解析 | 3 处改动均验证可解析；acl.cpp 做了反向对照（不补路径则编译失败） | | trace 回归 | trace 侧零改动 | **对照基线说明**：整改前发布包数据取自本仓构建产物 staging，其 10 个文件 sha256 与 HEAD~1 的 git 对象逐项吻合，可作为可信 before 基线。发布包结构归一前后的对比，取自同一台环境两次独立装包（--install-path 指向不同目录）。 **预处理等价性验证**（源码树改动部分） | 项 | 结果 | |---|---| | 预处理逐字节比对 | 整改前后均 8888 行，sha256 均 7209fcfc54ca，diff 无输出 | 做法：git stash 将工作区退回同一基线，用相同 include path 对真实源文件（plog_device_log.c）预处理一次，恢复改动后再预处理一次，两份输出 sha256 完全相同 —— 证明删副本、调 include path 对编译器最终看到的 token 流零影响。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 ### 对外接口变更（需兼容性评审） **新增一个对外可见枚举 DQS = 13** 该值原仅存在于源码树 src/dfx/log/inc/toolchain/log_types.h。整改前发布包两处 log_types.h 均取自 include/dfx/base 版而**不含 DQS**（已装包实测确认：整改前 3567B / f1a36a756418，正是 include/dfx/base 版的 sha），故该值此前从未真正对外，本次归并是首次外露。 保留它是为避免删除 src 副本时丢失定义。实测确认它填补 HIXL = 12 与 DEVMM = 22 之间空位（新包中位于第 58 行，前后分别为 57 行 HIXL = 12 与 59 行 DEVMM = 22），**不改变任何既有枚举值**。 ### 发布包结构变更对下游的影响 pkg_inc/base/log_types.h 由实体变为软链，include/toolchain/log_types.h 软链指向由 ../../pkg_inc/base/log_types.h 改为 ../base/log_types.h。 **对正常使用无影响**：三条路径均存在、均可读、内容一致（实测 sha256 相同）。#include 行为不变。 可能受影响的场景：以 -type f 精确匹配实体文件的打包/校验脚本，或强校验软链目标字符串的工具。若下游有此类校验，需同步更新预期值。 ### 删除 install(FILES) 段是否导致发布包文件变少 **不会。已装包实测确认发布包 include/base/ 下 4 个文件一个不少，清单与整改前逐项一致。** 被删的那段与 package.cmake:116 的 install(DIRECTORY ${RUNTIME_DIR}/include/dfx/base/) 目标目录完全相同，且该目录已包含被删段要装的两个文件（alog_pub.h、log_types.h），故被删段是**完全冗余的重复安装**。 实测证据：整改前发布包 include/base/log_types.h 为 3567B / f1a36a756418，等于整改前 include/dfx/base/log_types.h 的 sha，而**不等于**被删段的源 src/dfx/log/inc/toolchain/log_types.h（3597B / bc708128af41）—— 说明 install(DIRECTORY) 执行在后并覆盖了 install(FILES)，被删段本就是死代码。alog_pub.h 两个源 sha 完全相同，谁覆盖谁一致。 删除它的必要性：它引用的源文件已随本次整改删除，不删会导致 install 阶段失败。 ### include/toolchain/slog.h 是历史兼容别名 发布包 include/toolchain/slog.h 指向 pkg_inc/base/dlog_pub.h（实测两者 sha 相同），并非源码树中真正的 slog.h。该别名同由 RuntimeInc.xml 的 install_softlink 生成，**本次未改动该条目**，别名语义与指向均不变（其目标 dlog_pub.h 仍是实体）。源码树中真正的 slog.h（内部头）与 slog_api.h 均不打包，已实测确认。 ### git diff --check 说明 git diff --check 会报 trailing whitespace。已用最小工程复现确认：**纯 CRLF 文件新增任何一行都会被报，与内容无关**（git 把 \r 视作行尾空白）。报警文件中多数为纯 CRLF，混合行尾文件的 LF 行数与基线完全一致（未引入行尾变更）。本 PR 未引入真实的尾随空白。 ### 未闭环边界 UT 侧未覆盖验证。tests/ut/platform 的 platform_llt 编译产品源文件 src/platform/acl_platform.cpp 但未提供 securec 路径，tests/build_ut.sh -u 在该处即 fatal error: securec.h，阻塞在 UT 链最前端。该问题在整改前的基线上同样存在（已用 git checkout HEAD~1 确认同一处同一错误），非本 PR 引入。 See merge request: cann/runtime!4643 | 2 天前 | |
refactor: protobuf生成切换工程函数 Co-authored-by: Feiteng Zheng<zhengfeiteng1@h-partners.com> # message auto-generated for no-merge-commit merge: !4532 merge 20260827-switch-cmake-protobuf-generate into master refactor: protobuf生成切换工程函数 Created-by: zhengfeiteng Commit-by: Feiteng Zheng Merged-by: cann-robot Description: # Pull Request ## 描述 请清晰准确地描述本次 Pull Request 的意图和变更内容。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1.对比修改前后runtime包，一致。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/runtime!4532 | 6 天前 | |
aclgraph支持npu快照（支持不删除model直接执行） Co-authored-by: chingbb<qinbeibei4@huawei.com> # message auto-generated for no-merge-commit merge: !4426 merge dev into master aclgraph支持npu快照（支持不删除model直接执行） Created-by: chingbb Commit-by: chingbb Merged-by: cann-robot Description: ## 描述 本 PR 实现 aclgraph NPU 快照恢复功能（支持不删除 model 直接执行），并在后续提交中持续修复快照恢复路径的缺陷和扩展支持范围。 ### 主要变更 **1. aclgraph 支持NPU快照（支持不删除model直接执行）** - 新增快照备份和恢复流程，支持模型不删除直接重复执行 - CaptureModel 新增 LoadComplete / LoadCompleteByStreamPrep / LoadCompleteByStreamPostp / LoadCompleteByStream 虚函数，支持各平台覆写 - Model 新增 UpdateLabelCountPtr / ResetFuncCallMem 等方法，支持快照恢复时重置 funcCall 内存和 label count - UbArgManage 新增 RestoreArgRes，快照恢复时重建 stream UB args pool **2. 快照恢复 stream active FuncCall 重建** - 新增 UpdateStreamActiveTaskFuncCallForSnapshot，快照恢复后重建 stream active 任务的 funcCall memory - 修复非扩流场景 stream active 任务快照恢复失败的问题 **3. 快照恢复 MemConvertAddr 使用原始 copySize** - MemcpyAsyncTaskInfo 新增 copySize 字段保存原始搬运长度，size 改存 fixed_size - 修复快照多次恢复时 size 被 fixed_size 覆盖后 MemConvertAddr 地址转换长度错误 **4. 快照恢复扩展支持 software SQ 场景** - UpdateSnapShotSqe 拆分为设备 SQ 路径（UpdateDeviceSqeForSnapshot）和软件 SQ 路径（UpdateHostSqeForSnapshot） - 快照恢复移除 David 平台限制，所有平台统一调用 UpdateSnapShotSqe - 补全 2D memcpy 任务 copyMethod 标记（RT_ASYNC_CPY_2D） - RebuildExternalTaskSqe 重命名为 UpdateHostSqeBufferByTask，语义更通用 **5. 快照 memcpy SQE 更新重构** - UpdateMemcpyDeviceSqeForSnapshot 从 stream.cc 迁移到 memory_memcpy_async_task.cc - 提取 NeedUpdateMemcpyTaskInfoForSnapshot 谓词函数，消除 needUpdateSqe 出参 - UpdateDeviceSqeForSnapshot 改用 switch-case 替代 if-else 链 - UpdateMemcpyDmaForSnapshot 重命名为 UpdateMemcpyTaskInfoForSnapshot - DavidStream 新增 UpdateMemcpyTaskAndSqe 成员函数 - 同步更新 arch5162 stub 和 UT **6. 其他** - Notify::ReAllocId 新增 MAX_UINT32_NUM 守卫，跳过无效 notifyid 的重分配 - snapshot_process_helper.cc 告警日志补充 model_type 参数 - tiny stub 补充 RestoreForSoftwareSqForOneModels / LoadComplete 系列桩函数 ## 变更类型 - [x] 🐛 Bug 修复 - [x] ✨ 新功能 - [x] ♻️ 重构 ## 如何测试 1. 编译验证：bash build.sh 编译通过 2. UT 执行：runtime_utest_api_david（653 用例）、runtime_utest_api_910B（1405 用例）、runtime_utest（1209 用例）全部通过 3. 覆盖率：增量变更行覆盖率 76.4% ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签 - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定 See merge request: cann/runtime!4426 | 2 天前 | |
feat:nano支持rtsPointerGetAttributes接口 Co-authored-by: maxiaofan2<maxiaofan2025@163.com> # message auto-generated for no-merge-commit merge: !4371 merge rts-pointer-attributes-20260820 into master feat:nano支持rtsPointerGetAttributes接口 Created-by: maxiaofan2 Commit-by: maxiaofan2 Merged-by: cann-robot Description: # Pull Request ## 描述 在 Runtime Compact 中新增 rtsPointerGetAttributes 接口，通过 HAL 查询指针的 Host/Device 内存属性，并补充参数校验及 Linux、LiteOS 单元测试。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 2. ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [ ] 我已对代码进行了自测 - [ ] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [ ] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/runtime!4371 | 3 天前 | |
fix: log冗余头文件整改，消除软链与多副本 Co-authored-by: GuoWenbo<guowenbo13@h-partners.com> # message auto-generated for no-merge-commit merge: !4643 merge fix/issue831-log-header-normalization into master fix: log冗余头文件整改，消除软链与多副本 Created-by: GuoWenbo Commit-by: GuoWenbo Merged-by: cann-robot Description: ## 描述 按 issue #831 要求，消除 log 组件冗余头文件，按「对外开放程度 include > pkg_inc > src」归一。整改覆盖两层： - **源码树**： include/pkg_inc/src 三层下每个头文件只保留一份实体 - **发布包**：同名头文件只保留一份实体，其余为软链 本 PR 为单个提交。 ## 一、源码树整改 **保留 4 份实体**：include/dfx/base/{log_types.h,alog_pub.h}、pkg_inc/base/{dlog_pub.h,plog.h}。 | 文件 | 原性质 | 处理 | 与保留份的差异 | |---|---|---|---| | pkg_inc/base/log_types.h | 软链 → ../../include/dfx/base/log_types.h | 删除 | 无内容差异 | | src/dfx/log/inc/toolchain/log_types.h | 实体副本 3597B | **改为软链** → include/dfx/base/log_types.h | 多 DQS = 13（已合并入保留份）；无行尾换行 | | src/dfx/log/inc/toolchain/dlog_pub.h | 实体副本 8324B | **改为软链** → pkg_inc/base/dlog_pub.h | 少 4 行注释 | | src/dfx/log/inc/toolchain/alog_pub.h | 实体副本 1725B | 删除 | sha256 与保留份完全相同 | | src/dfx/log/inc/toolchain/plog.h | 实体副本 1967B | 删除 | 少 1 个空行 | 整改后 4 个头文件各仅 1 份实体，src 层重复内容归零。 trace 组件（pkg_inc/trace、pkg_inc/watchdog、src/dfx/trace/inc/toolchain）逐个排查无多副本，零改动。 ### 为什么 src 层保留两个软链 issue 的目标是消除**冗余副本**（同一头文件多份可独立漂移的实体）。软链不构成副本：它与保留份始终同一内容，无漂移风险。 保留这两个软链是**防御性**的，让 include path 上带 src/dfx/log/inc/toolchain 的消费方继续能按短名解析。 需要说明：**当前仓内没有任何代码依赖这两个软链**。全仓 #include "toolchain/log_types.h" 与 "toolchain/dlog_pub.h" 引用数均为 0；按短名引用的消费方，其 include path 也都不含 inc/toolchain（抽查 10 个，9 个无该路径，1 个仅有 inc）。所以它们是为树外联编与后续新增代码留的兼容层，不是为修复仓内某处引用。 alog_pub.h 与 plog.h 未保留软链：前者在 src 下无对应引用，后者原有 3 处 #include "toolchain/plog.h" 已改为短名。 ## 二、发布包整改 改 scripts/package/module/ascend/RuntimeInc.xml（一增一删两行），使发布包内同名头文件只有一份实体。 整改前 log_types.h 在发布包内是**两份独立实体**（include/base/ 与 pkg_inc/base/ 各一份，内容相同但互不关联），因为两条 install 规则都指向源码树同一文件。整改后归一为「include/base 一份实体 + 其余软链指向它」： | 发布包路径 | 整改前 | 整改后 | |---|---|---| | include/base/log_types.h | 实体 | **实体（唯一实体）** | | pkg_inc/base/log_types.h | 实体 | **软链 → ../../include/base/log_types.h** | | include/toolchain/log_types.h | 软链 → ../../pkg_inc/base/log_types.h | 软链 → **../base/log_types.h** | 发布包 log 相关文件由 **8 实体 + 2 软链** 变为 **7 实体 + 3 软链**，总数仍为 10，无增无减。 include/toolchain/log_types.h 的指向变更是连带的：它原先指向 pkg_inc/base 那份，而那份现已改为软链，故改为直接指向实体，避免软链套软链。对下游无影响（路径不变、读到内容不变）。 实现方式沿用仓内既有先例：package.cmake 在 CPack staging 放实体，XML 的 install_softlink 再把列为软链目标的替换为软链，相对路径由打包框架自动计算。prof_api.h 即此模式（package.cmake 装 2 份，XML 转 1 份为软链，最终 1 实体 3 软链）。package.cmake 本次无需改动。 其余 6 个头文件（alog_pub.h、acl_log.h、err_msg.h、dlog_pub.h、err_mgr.h、plog.h）在发布包内本就各仅 1 份实体，零改动。 ## 编译依赖适配 **主路径**：slog_headers **新增** include/dfx/base（src/dfx/log/liblog/slog/CMakeLists.txt）—— 一处覆盖 153 个 link 该 target 的消费者，target_link_libraries 会传播 INTERFACE include 路径。 原有 4 条路径（${TOOLAHCIN_LOG_DIR}/inc、inc/toolchain、.../pkg_inc、.../pkg_inc/base）**全部保留**。本 PR 对 slog_headers 是纯新增、不删任何路径，消费方现有依赖不受影响，**外部组件无需任何适配**（新路径集合是原 4 条的超集）。 **硬路径**：25 个 cmake 文件用 include_directories() 硬写路径、拿不到 INTERFACE 传播，逐个补齐（tests/ut 11 个、tests/depends 7 个、src 7 个）。其中 src/acl/aclrt_impl 是为下述短名改动新增。 **引用形式收敛**：4 处前缀引用改为短名，与仓内主流写法（plog.h 10 处、log_types.h 7 处、dlog_pub.h 23 处均为短名）一致： - src/acl/aclrt_impl/acl.cpp："toolchain/plog.h" → "plog.h"（该 target 不 link slog_headers，同时补 pkg_inc/base 路径；已验证不补则 fatal error: plog.h: No such file or directory） - tests/ut/runtime/runtime/stub/log_stub.cc："toolchain/plog.h" → "plog.h"（零 cmake 改动） - src/dfx/msprof/.../devprof_drv_aicpu.cpp："base/log_types.h" → "log_types.h"（零 cmake 改动） - src/tprt/feature/inc/tprt_base.hpp：**保持** "base/plog.h" 前缀形式 tprt_base.hpp 保留前缀形式是刻意的：它是头文件，改短名会把「须有 pkg_inc/base 在路径上」的要求传导给所有包含它的下游，而前缀形式只要求有 pkg_inc，约束宽得多。仓内 pkg_inc/base/err_mgr.h 同样用 #include "base/err_msg.h"，是同一考虑。 **其他**：cmake/package.cmake 删除已失效的 install 段（其引用的源文件已删除，不删会导致 install 阶段失败）；3 个 cmake 文件补齐缺失的 license header（src/platform、tests/ut/platform、tests/ut/aicpu_sched/aicpu_kernel/ut，本 PR 改动这些文件触发 OAT 检查，原文件即无 header）。 ## 变更类型 - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） ## 关联的Issue https://gitcode.com/cann/runtime/issues/831 ## 如何测试 1. 构建：bash build.sh --pkg --pkg-type=run -j16 —— 应输出 build success!，0 error 2. 装包并核对发布包结构： bash bash build_out/cann-npu-runtime_9.2.0_linux-aarch64.run --devel --quiet --install-path=<PATH> N=<PATH>/cann/aarch64-linux ls -la $N/include/base/ $N/pkg_inc/base/ $N/include/toolchain/ # 预期：include/base/log_types.h 为唯一实体， # pkg_inc/base/log_types.h 与 include/toolchain/log_types.h 为软链 3. 同名实体唯一性与软链有效性： bash for d in include/base pkg_inc/base include/toolchain; do for f in $N/$d/*; do [ -L "$f" ] || basename "$f"; done done | sort | uniq -c | awk '$1>1{print "重复实体:",$2}' # 应无输出 find $N/include/base $N/pkg_inc/base $N/include/toolchain -type l \ -exec test -e {} \; -print | wc -l # 应为 3（全部有效） grep -nE "HIXL|DQS|DEVMM" $N/include/base/log_types.h # DQS=13 应在 12 与 22 之间 4. 源码树软链： bash readlink -e src/dfx/log/inc/toolchain/{log_types.h,dlog_pub.h} # 应指向保留实体 git ls-tree HEAD src/dfx/log/inc/toolchain/ # 应为 mode 120000 ## 验证结论 **已完成全量构建与装包实测**（含发布包结构归一） | 项 | 结果 | |---|---| | 完整构建 | bash build.sh --pkg --pkg-type=run -j16 → build success!，0 个 error: | | 装包 | cann-npu-runtime_9.2.0_linux-aarch64.run（37MB）以 --devel 装至独立路径成功 | | 发布包同名实体唯一性 | **无任何文件名对应 >1 个实体**（按 basename 统计逐一确认） | | 发布包实体/软链构成 | **7 实体 + 3 软链 = 10**（整改前 8 实体 + 2 软链 = 10），总数无增无减 | | 3 条软链有效性 | 全部有效不悬空：pkg_inc/base/log_types.h → ../../include/base/log_types.h、include/toolchain/log_types.h → ../base/log_types.h、include/toolchain/slog.h → ../../pkg_inc/base/dlog_pub.h | | 经软链读取一致性 | 3 条 log_types.h 路径读到内容 sha256 全同（cf883df89a3a） | | 发布包内容差异 | 相对整改前**仅 log_types.h 一处**：3567B → 3598B，diff 输出仅 > DQS = 13, 一行 | | 其余 6 个头文件 | sha256 与整改前**完全相同**（alog_pub.h 3771757b5e、dlog_pub.h ab887476d1、plog.h c8e1f91404、err_mgr.h e09c8237ea、err_msg.h 5ded505fa2、acl_log.h 660c8a844f） | | 源码树软链未外泄 | 发布包内搜 *log/inc/toolchain* 无结果；内部头 slog_api.h 未被打包 | | 源码树软链有效性 | 2 条 readlink -e 均解析到保留实体；git 记为 mode 120000 | | 短名解析 | 3 处改动均验证可解析；acl.cpp 做了反向对照（不补路径则编译失败） | | trace 回归 | trace 侧零改动 | **对照基线说明**：整改前发布包数据取自本仓构建产物 staging，其 10 个文件 sha256 与 HEAD~1 的 git 对象逐项吻合，可作为可信 before 基线。发布包结构归一前后的对比，取自同一台环境两次独立装包（--install-path 指向不同目录）。 **预处理等价性验证**（源码树改动部分） | 项 | 结果 | |---|---| | 预处理逐字节比对 | 整改前后均 8888 行，sha256 均 7209fcfc54ca，diff 无输出 | 做法：git stash 将工作区退回同一基线，用相同 include path 对真实源文件（plog_device_log.c）预处理一次，恢复改动后再预处理一次，两份输出 sha256 完全相同 —— 证明删副本、调 include path 对编译器最终看到的 token 流零影响。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 ### 对外接口变更（需兼容性评审） **新增一个对外可见枚举 DQS = 13** 该值原仅存在于源码树 src/dfx/log/inc/toolchain/log_types.h。整改前发布包两处 log_types.h 均取自 include/dfx/base 版而**不含 DQS**（已装包实测确认：整改前 3567B / f1a36a756418，正是 include/dfx/base 版的 sha），故该值此前从未真正对外，本次归并是首次外露。 保留它是为避免删除 src 副本时丢失定义。实测确认它填补 HIXL = 12 与 DEVMM = 22 之间空位（新包中位于第 58 行，前后分别为 57 行 HIXL = 12 与 59 行 DEVMM = 22），**不改变任何既有枚举值**。 ### 发布包结构变更对下游的影响 pkg_inc/base/log_types.h 由实体变为软链，include/toolchain/log_types.h 软链指向由 ../../pkg_inc/base/log_types.h 改为 ../base/log_types.h。 **对正常使用无影响**：三条路径均存在、均可读、内容一致（实测 sha256 相同）。#include 行为不变。 可能受影响的场景：以 -type f 精确匹配实体文件的打包/校验脚本，或强校验软链目标字符串的工具。若下游有此类校验，需同步更新预期值。 ### 删除 install(FILES) 段是否导致发布包文件变少 **不会。已装包实测确认发布包 include/base/ 下 4 个文件一个不少，清单与整改前逐项一致。** 被删的那段与 package.cmake:116 的 install(DIRECTORY ${RUNTIME_DIR}/include/dfx/base/) 目标目录完全相同，且该目录已包含被删段要装的两个文件（alog_pub.h、log_types.h），故被删段是**完全冗余的重复安装**。 实测证据：整改前发布包 include/base/log_types.h 为 3567B / f1a36a756418，等于整改前 include/dfx/base/log_types.h 的 sha，而**不等于**被删段的源 src/dfx/log/inc/toolchain/log_types.h（3597B / bc708128af41）—— 说明 install(DIRECTORY) 执行在后并覆盖了 install(FILES)，被删段本就是死代码。alog_pub.h 两个源 sha 完全相同，谁覆盖谁一致。 删除它的必要性：它引用的源文件已随本次整改删除，不删会导致 install 阶段失败。 ### include/toolchain/slog.h 是历史兼容别名 发布包 include/toolchain/slog.h 指向 pkg_inc/base/dlog_pub.h（实测两者 sha 相同），并非源码树中真正的 slog.h。该别名同由 RuntimeInc.xml 的 install_softlink 生成，**本次未改动该条目**，别名语义与指向均不变（其目标 dlog_pub.h 仍是实体）。源码树中真正的 slog.h（内部头）与 slog_api.h 均不打包，已实测确认。 ### git diff --check 说明 git diff --check 会报 trailing whitespace。已用最小工程复现确认：**纯 CRLF 文件新增任何一行都会被报，与内容无关**（git 把 \r 视作行尾空白）。报警文件中多数为纯 CRLF，混合行尾文件的 LF 行数与基线完全一致（未引入行尾变更）。本 PR 未引入真实的尾随空白。 ### 未闭环边界 UT 侧未覆盖验证。tests/ut/platform 的 platform_llt 编译产品源文件 src/platform/acl_platform.cpp 但未提供 securec 路径，tests/build_ut.sh -u 在该处即 fatal error: securec.h，阻塞在 UT 链最前端。该问题在整改前的基线上同样存在（已用 git checkout HEAD~1 确认同一处同一错误），非本 PR 引入。 See merge request: cann/runtime!4643 | 2 天前 | |
refactor: protobuf生成切换工程函数 Co-authored-by: Feiteng Zheng<zhengfeiteng1@h-partners.com> # message auto-generated for no-merge-commit merge: !4532 merge 20260827-switch-cmake-protobuf-generate into master refactor: protobuf生成切换工程函数 Created-by: zhengfeiteng Commit-by: Feiteng Zheng Merged-by: cann-robot Description: # Pull Request ## 描述 请清晰准确地描述本次 Pull Request 的意图和变更内容。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1.对比修改前后runtime包，一致。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/runtime!4532 | 6 天前 | |
fix: runtime_platform_arch5162缺少对c_sec的依赖声明 Co-authored-by: lianglongzi8622<lianglongzi@huawei.com> # message auto-generated for no-merge-commit merge: !3623 merge fix/arch5162-csec-dependency into master fix: runtime_platform_arch5162缺少对c_sec的依赖声明 Created-by: lianglongzi8622 Commit-by: lianglongzi8622 Merged-by: cann-robot Description: # Pull Request ## 描述 runtime_platform_arch5162缺少对c_sec的依赖声明，导致并行构建时csec_src可能尚未下载解压securec.h就开始编译dev_info_reg.cc，首次构建失败，第二次因stamp已存在而成功。 ## 变更类型 - [x] 🐛 Bug 修复 ## 修复内容 在src/CMakeLists.txt守护块中补上： cmake add_dependencies(runtime_platform_arch5162 c_sec) ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我在标题中使用了合适的类型标签 See merge request: cann/runtime!3623 | 1 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 天前 | ||
| 2 天前 | ||
| 20 天前 | ||
| 2 天前 | ||
| 3 天前 | ||
| 1 个月前 | ||
| 2 天前 | ||
| 6 天前 | ||
| 2 天前 | ||
| 3 天前 | ||
| 2 天前 | ||
| 6 天前 | ||
| 1 个月前 |