| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
feat: 新增 aclrtBinaryEnumerateFunctions 接口 Co-authored-by: chenyang<2082464740@qq.com> # message auto-generated for no-merge-commit merge: !4557 merge aclbef-v2 into master feat: 新增 aclrtBinaryEnumerateFunctions 接口 Created-by: weixin_51634168 Commit-by: weixin_51634168;chenyang Merged-by: cann-robot Description: # Pull Request ## 描述 新增 aclrtBinaryEnumerateFunctions 接口，用于获取算子二进制中指定数量的核函数句柄。 本次变更包括： - 增加 ACL、Runtime 接口声明及实现，并补充参数校验、Profiling 和 Stub。 - 支持将算子二进制关联到当前 Device，并返回对应核函数句柄。 - 增加空指针、数量为 0、成功路径及错误传递等 UT。 - 增加中英文接口文档及完整调用示例。 - 将 tiny 不支持的进程 Snapshot 实现从公共 api_impl.cc 迁移至 api_impl_standard_soc.cc，并在 api_impl_stub.cc 中返回 RT_ERROR_FEATURE_NOT_SUPPORT，避免 tiny SO 引入无关实现。 - 增加 tiny 形态下 Snapshot ApiImpl 桩的单元测试覆盖。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> 暂无关联 Issue。 ## 如何测试 描述测试此变更的步骤和前提条件： 1. pre-commit clang-format 检查通过。 2. Git diff 空白检查通过。 3. Snapshot 源码分区检查通过：公共实现不再包含进程 Snapshot，standard-soc 包含真实实现，tiny 包含 Stub。 4. 已增加 ACL、Runtime 及 tiny Snapshot Stub 单元测试；当前 Windows 环境缺少 bash、CMake 和 C++ 编译器，未执行完整构建、UT 及 OAT 检查。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [ ] 我已对代码进行了完整自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 See merge request: cann/runtime!4557 | 8 天前 | |
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 | 1 天前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 8 天前 | ||
| 1 天前 |