Backgroud（背景信息）

asc-comm 将提供面向昇腾 AI 处理器的通信数据面能力，其中 AICPU 数据面产物为 libasccomm_aicpu.so。该库需要在 Runtime 初始化时通过 AICPU kernel 包加载到设备侧，才能支撑后续基于 asccomm 的通信原语运行。

Runtime 已经支持加载多个由其他组件交付的 AICPU kernel 包，例如 aicpu_hccl.tar.gz、mc2_server.tar.gz、aicpu_hcomm.tar.gz。这些包的公共特征是：

• 打包根目录为 aicpu_kernels_device；
• 安装在 opp/built-in/op_impl/aicpu/kernel；
• 通过 ascend_package_load.ini 声明 install_path:2，由 Runtime package loader 加载；
• 使用 CMS 签名，签名 tag 为 ascend_aicpu。

经架构师决策，asccomm_aicpu.tar.gz 由 Runtime 包交付。因此 Runtime 需要在设备侧构建过程中引入 asc-comm AICPU 数据面，并将其作为标准 AICPU kernel 包打包进 Runtime 包。

Origin（信息来源）

架构师决策：asccomm_aicpu.tar.gz 打包到 Runtime 包中交付。

Benefit / Necessity （价值/作用）

1. 补齐 asccomm AICPU 数据面的交付链路

   Runtime 包负责安装 asccomm_aicpu.tar.gz，Runtime package loader 负责在初始化时按既有 AICPU kernel 包流程将其加载到设备侧，保证 asc-comm 通信能力开箱可用。

2. 复用 Runtime 已有的包管理机制

   Runtime 已经有完整的 AICPU kernel 包加载、签名校验、芯片适配和配置解析逻辑。本需求只需要复用既有机制新增构建和包条目，不需要引入新的加载机制。

3. 对齐 hcomm 的安装与加载路径

   aicpu_hcomm.tar.gz 当前由独立通信组件交付，Runtime 负责安装后的加载。asccomm 的构建来源不同：它在 Runtime 设备侧构建中生成，再打包进 Runtime 包。两者的安装路径和加载配置保持一致，可以降低维护和理解成本：

   • 设备加载包：opp/built-in/op_impl/aicpu/kernel/asccomm_aicpu.tar.gz
   • host 侧设备库：<arch>-linux/devlib/device/libasccomm_aicpu.so

   这两份产物的用途不同：前者是给 Runtime package loader 加载到设备侧的签名压缩包；后者是 host 包中保留的设备库，供工具链和开发链接场景使用。

4. 限定支持范围，避免扩大交付面

   asccomm_aicpu.tar.gz 仅声明支持 Ascend 950 和 Ascend 350。其他芯片不会加载该包，避免引入无关兼容风险。

Design（设计方案）

1. 构建引入 asc-comm AICPU 数据面

在 Runtime 设备侧构建中引入 cmake/third_party/asc_comm.cmake：

• 优先复用本地或三方依赖目录中的 asc-comm 源码；
• 未找到时按固定 commit 拉取；
• 通过 add_subdirectory 构建 asccomm_aicpu target。

这样 Runtime 设备构建可以生成 libasccomm_aicpu.so，无需用户手工准备独立构建产物。

2. 打包为 AICPU kernel 包

使用 Runtime 既有的 cann_pack_targets_and_files：

cann_pack_targets_and_files(
  OUTPUT_TARGET "pack_asccomm_aicpu"
  OUTPUT "asccomm_aicpu.tar.gz"
  TARGETS asccomm_aicpu
  SIZE_LIMIT 1024
  MANIFEST "bin_hash.cfg"
  TAR_ROOT_DIR "aicpu_kernels_device"
)

包内容为：

aicpu_kernels_device/
├── libasccomm_aicpu.so
└── bin_hash.cfg

3. 签名

在 scripts/package/sign.xml 中新增：

<item input="asccomm_aicpu.tar.gz" output="asccomm_aicpu.tar.gz"
      type="cms" sign_alg="PSS" tag="ascend_aicpu" nvcnt="0"/>

与 aicpu_hcomm.tar.gz 一致，均使用 ascend_aicpu tag 做 CMS 签名。

4. 安装路径

签名后的包安装到：

opp/built-in/op_impl/aicpu/kernel/asccomm_aicpu.tar.gz

同时在安装 XML 中声明 opp 到 opp/built-in/op_impl/aicpu/kernel 的目录链。该目录链用于安装记录和卸载时清理空目录；卸载逻辑只会删除空目录，不会影响 hcomm 等其他组件已安装在相同目录下的文件。

5. Runtime 加载配置

在 ascend_package_load.ini 中新增：

name:asccomm_aicpu.tar.gz
install_path:2
optional:true
package_path:opp/built-in/op_impl/aicpu/kernel
load_as_per_soc:false

其中：

• install_path:2 表示 AICPU kernels 路径；
• package_path 与实际安装路径一致；
• optional:true 表示包缺失时允许跳过，避免影响不使用 asccomm 的场景；
• load_as_per_soc:false 表示不按 SOC 子目录查找。

6. bin_hash.cfg 约定

bin_hash.cfg 由 cann_pack_targets_and_files 在构建每个 AICPU kernel 包时生成，只记录当前包内二进制文件的 SHA256。asccomm 与 aicpu_hccl.tar.gz、aicpu_hcomm.tar.gz、mc2_server.tar.gz 一样，使用固定的 bin_hash.cfg 文件名和 aicpu_kernels_device 根目录。

这些既有包本身就声明了相同的安装路径和 install_path:2，并在 Ascend 950 / Ascend 350 等芯片上共存加载。因此同名 manifest 是既有 AICPU kernel 包约定，不是 asccomm 新引入的冲突。Runtime host 侧按包名比较 tar 包 SHA256 决定是否重新下发，不在 host 侧读取或合并 bin_hash.cfg。

设备侧对 manifest 的校验由 common sink 设备侧处理逻辑实现。如果后续设备侧要求按包隔离 manifest，应统一调整 AICPU kernel 包约定，而不是仅为 asccomm 增加特殊文件名。

7. 芯片支持范围

在 Runtime package loader 的芯片支持映射中新增：

{"asccomm_aicpu.tar.gz", {tsd::CHIP_ASCEND_950, tsd::CHIP_ASCEND_350}}

仅 Ascend 950 和 Ascend 350 会加载该包。

8. host 侧设备库

除签名压缩包外，保留一份 libasccomm_aicpu.so 在：

<arch>-linux/devlib/device/libasccomm_aicpu.so

该路径与 hcomm 的 libccl_kernel.so 交付方式一致，用于 host 包中的设备库交付和开发链接场景。