问题描述
1230 基线的 storage 仓已经携带了 sml 库的代码，但是当前 sml 仍然是通过高可用携带二进制预编译的，是否可以激活 storage 组件自带 sml 的构建？需要进行什么样的配置？
观察到存在 sml 的编译选项
打开编译选项后，构建报错，缺少相关头文件
期望结果
能正确从源码构建 SML 库
答案内容由AI生成，仅供参考：
总结：实现从源码构建SML库的关键条件
| 条件 | 是否满足 | 说明 |
|---|---|---|
开启 sml_open 编译选项 |
 可配置 |
在 service.json 中启用 |
| 提供厂商SDK头文件 |
 通常缺失 |
需引入 Broadcom/PMC/Huawei SDK Conan包 |
| 构建系统支持自动包含路径 |
Conan+CMake支持 |
依赖配置正确 |
| 使用正确版本 bmcgo |
推荐 0.5.370+ |
避免僵尸进程等问题 |
点击此处查看详细分析解答
关于在1230基线中编译Storage组件自带SML库的分析与解决方案
根据您提供的问题描述和系统环境信息，以下是对1230基线环境下如何激活并正确编译Storage组件内置SML库的详细分析与解决方案。
问题分析
1. 当前现状
- Storage仓已包含SML源码：路径为
storage/src/lualib-src/sml，内含多个子模块（如sml_lsi,sml_pmc,sml_base等）。 - 现有构建方式依赖预编译库：
libsml_lsi.so和其他相关库目前通过高可用组件或闭源依赖引入，为二进制形式（.so文件）。- Storage组件本身并未强制开启从源码构建SML的功能。
- 检测到编译开关存在：
- 在
service.json中定义了两个关键选项："sml_open": { "description": "使能storage仓sml目录", "option": [true, false], "default": false }, "storelib_enable": { "description": "使能其他厂商存储管理库", "option": [true, false], "default": false } - 其中
sml_open = true是启用内部SML源码构建的关键配置。
- 在
2. 错误原因分析
当您尝试开启 sml_open=true 构建时出现如下编译失败：
fatal error: lsi/storelib.h: No such file or directory
#include "lsi/storelib.h"
fatal error: pmc/pstore.h: No such file or directory
#include "pmc/pstore.h"
根本原因：
SML库依赖的底层厂商SDK头文件（如Broadcom/LSI、PMC）未在构建环境中提供。
尽管Storage组件中包含了SML的适配层源代码，但这些源码本身依赖于外部的闭源RAID卡厂商SDK头文件（例如 storelib.h, pstore.h），而这些头文件：
- 不是开源组件的一部分
- 未包含在当前Conan包或源码树中
- 需要由平台方或厂商单独提供（通常以专用Conan包或私有仓库形式）
因此，即使启用了 sml_open 开关，由于缺少必要的头文件依赖，构建过程无法继续。
解决方案：如何正确启用并构建SML库
要实现在1230基线下从源码成功构建SML库，需满足以下条件：
步骤一：确认并引入必要的厂商SDK依赖
必须确保以下组件可通过 Conan 或其他方式正确解析并提供头文件路径：
| 模块 | 所需头文件 | 来源建议 |
|---|---|---|
sml_lsi |
lsi/storelib.h |
Broadcom SDK 提供，应由 conan 包 broadcom-sdk 或 lsi-storelib-dev 提供 |
sml_pmc |
pmc/pstore.h |
PMC/Adaptec SDK 提供，应打包为 pmc-sdk |
sml_histore |
华为自研SDK | 内部闭源包 huawei-sml-sdk |
操作建议：
修改 conanfile.py 或 manifest.yaml，显式声明对这些SDK开发包的依赖：
# manifest.yaml
requires:
- conan: broadcom-sdk/1.0.0@openubmc/internal
- conan: pmc-sdk/1.2.0@openubmc/internal
- conan: huawei-sml-sdk/latest@openubmc/internal
注意：这些包需提前上传至企业内网 Conan 私服，并确保构建机器可访问。
步骤二：正确启用 sml_open 编译选项
在构建命令或配置中明确设置：
bmcgo build --option sml_open=True --option storelib_enable=True
或在构建配置文件（如 vars.json）中设定：
{
"sml_open": true,
"storelib_enable": true
}
storelib_enable=True通常用于激活对非华为RAID卡的支持，与sml_open配套使用更佳。
步骤三：验证编译系统路径包含机制
确保 CMakeLists.txt 中对头文件包含路径的处理是动态且可扩展的。
例如，在 storage/src/lualib-src/sml/sml_lsi/CMakeLists.txt 中应有类似：
include_directories(
${CMAKE_CURRENT_SOURCE_DIR}/inc
${BROADCOM_SDK_INCLUDE_DIR} # 通过Conan注入
)
可通过 Conan 的 cpp_info.includedirs 自动导出头文件路径，并在 CMake 中引用。
步骤四：使用 bmcgo 管理构建流程
由于 bmcgo 是 openUBMC 的核心构建工具（如知识库所示，其版本影响构建行为），请确保：
- 使用兼容的
bmcgo版本（推荐 ≥0.5.370） - 构建前清除旧缓存（避免使用过期组件）：
bmcgo clean --all
bmcgo build --force --option sml_open=true
提示：可配合
--dry-run查看依赖解析是否正确加载了SDK包。
替代方案（临时验证用）
若短期内无法获取闭源SDK头文件，但仍需验证SML构建流程，可采用以下方式：
方案A：预置空头文件（仅用于PoC）
创建模拟头文件，供编译通过（适用于调试构建逻辑，不能用于生产）：
// mock/lsi/storelib.h
#ifndef _LSI_STORELIB_H_
#define _LSI_STORELIB_H_
typedef struct { int dummy; } STOR_LIB_INFO;
#endif
然后将 mock/ 添加进 include path。
方案B：切换为 stub 模式构建
在 CMakeLists.txt 中添加判断：
if(NOT DEFINED BROADCOM_SDK_AVAILABLE)
add_definitions(-DUSE_STUB_SML)
endif()
并在代码中用 #ifdef USE_STUB_SML 包裹依赖厂商头的部分。
总结：实现从源码构建SML库的关键条件
| 条件 | 是否满足 | 说明 |
|---|---|---|
开启 sml_open 编译选项 |
可配置 |
在 service.json 中启用 |
| 提供厂商SDK头文件 |
通常缺失 |
需引入 Broadcom/PMC/Huawei SDK Conan包 |
| 构建系统支持自动包含路径 |
Conan+CMake支持 |
依赖配置正确 |
| 使用正确版本 bmcgo |
推荐 0.5.370+ |
避免僵尸进程等问题 |
参考资料（来自知识库）
神码_刘杰曾成功解决类似编译问题（见文档chunk #1），方法为：移除冲突库并清理依赖缓存libsml_lsi.so被证实需通过storelib_enable=true打包进固件（见 chunk #2）SML Library本质是封装厂商SDK的抽象层，依赖底层.so和头文件（见 KG 实体描述）
最终建议
要实现
storage组件内建 SML 库的源码构建，必须：
- 打通闭源SDK依赖链：将
lsi/storelib.h、pmc/pstore.h等头文件以 Conan 包形式纳入依赖管理； - 启用
sml_open=true构建选项； - 确保
manifest.yaml正确声明SDK依赖并配置包含路径； - 使用高版本
bmcgo构建并清理缓存。
如果您所在组织尚无权限获取上述SDK头文件，请联系平台提供方或华为技术支持，申请相应的开发套件（SDK Dev Kit）以支持自主构建。
如您能提供更多关于所用RAID卡型号（如9560-8i）及具体SDK来源的信息，可进一步细化解决方案。
相关链接：
打开这两个编译选项并不能直接编译出博通的sml库，因为NDA缺少厂商提供部分，需要自行获取
参考：openubmc 是否支持 博通 9560-8i 的raid 卡 - 交流互助区 / 鲲鹏专区 - openUBMC 论坛
博通厂商的头文件缺失，无法提供，需要开发者有对应的头文件放在对应的目录下才能进行编译，目前只有1880的sml_histore可以在蓝区编译