# Openeuler Research

> 使用 openEuler 权威来源查询发行版、官方文档、社区信息、仓库与软件包，并调研内核、Embedded BSP、设备兼容性和功能支持情况。

- Skill: `processmission/openeuler-research` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add processmission/openeuler-research`
- Raw SKILL.md: https://api.skillmd.com/api/skills/processmission/openeuler-research/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: processmission (https://skillmd.com/u/processmission)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/processmission/openeuler-research

---


# 用途

使用此 skill 对 openEuler 相关信息进行基于权威证据的查询和调研，包括：

- 查询发行版版本、下载入口、生命周期、发布说明和商业发行版信息。
- 查询官方文档、技术白皮书、FAQ、安全公告、缺陷公告、迁移及运维资料。
- 查询 SIG、组织架构、仓库归属、邮件列表、社区会议、新闻及社区动态。
- 查询软件源码、SRPM、软件包、Repo 源、镜像站、构建服务及依赖关系。
- 调研内核、Embedded BSP、硬件兼容性以及所需功能是否真正交付。

## 权威入口

开始调研前，必须根据问题类型查阅 [openEuler 权威入口](references/official-entry-points.md)。该 reference 汇总官网顶部导航中的发行版、软件包、源码治理、文档支持及社区动态入口，并标明各入口的使用边界。

## 版本规则

1. 匹配用户指定的准确 openEuler 版本或分支。
2. 用户未指定版本时，仓库和 SIG 元信息使用 `master`，且在回复用户时需明确指出。
3. 调研内核时，记录所检查的准确内核分支、提交以及生成配置或 defconfig。
4. 不得混用不同发行分支的证据；确需引用时必须明确标注差异。

## 仓库发现

从 `community` 仓库开始，不得猜测仓库名称：

1. 读取 `community` 的 `master` 分支。
2. 在 `sig/<sig-name>/` 下定位相关 SIG。
3. 读取其 `sig-info.yaml` 和仓库元信息。
4. 区分 `openeuler/*` 源码仓库和 `src-openeuler/*` 打包仓库。
5. 在各仓库的 AtomGit 官方地址继续内容调研。

调研嵌入式领域时，从 `sig/sig-embedded/` 开始。通过元信息确认当前仓库列表，不得依赖过期的网页渲染结果或搜索引擎统计数量。

## 来源优先级

按以下顺序使用来源：

1. 使用 AtomGit `community` 元信息发现 SIG 归属和仓库。
2. 使用 AtomGit 官方仓库的准确目标分支获取源码证据。
3. 使用 openEuler 官方文档确认支持流程和发行版行为。
4. 当 openEuler 元信息明确获取外部源码时，使用对应厂商或上游官方仓库。
5. 网络搜索仅用于交叉验证或定位官方资料。

GitHub 镜像、第三方 fork、博客和搜索摘要只能作为补充。报告任何重要结论前，必须通过 openEuler、厂商或上游官方来源独立核验。

## 功能支持审查

跟踪完整交付链路：

1. **仓库归属**——哪个 SIG 或仓库负责该功能。
2. **源码存在**——请求分支上是否存在实现代码。
3. **构建选择**——配方或 manifest 实际选择了哪个源码 URI 和修订版本。
4. **配置状态**——相关 defconfig 或镜像配置是启用为 `=y`、`=m`，还是关闭。
5. **镜像包含**——配方或 packagegroup 是否把功能安装到产出镜像。
6. **运行集成**——所需固件、ACPI/DT、Bootloader、硬件 ID、用户态组件或产品策略。
7. **验证层级**——区分静态源码证据、成功构建、成功启动和实硬件测试。

结论分类：

- **满足**——已有实现、配置、镜像集成和适用运行链路的证据。
- **有条件满足**——能力存在，但仍需配置、板级描述、固件、软件包选择或硬件验证。
- **不满足**——所检查的产品链路缺少实现或集成。
- **不属于该组件职责**——例如软件包管理或 A/B 编排不是内核单独提供的能力。

## 内核和 BSP 注意事项

- 源码中存在驱动，不代表所选 defconfig 已启用该驱动。
- 编译为模块不代表它可直接用于根设备或早期启动依赖；必须检查 initramfs 或内建配置。
- 通用 openEuler 内核检出可能不是 Embedded BSP 实际选择的内核。沿 `SRC_URI`、manifest、配方、修订版本和 machine 配置追踪实际源码。
- 通用框架支持不能证明支持特定设备型号或板级协议。
- UEFI/ACPI、UEFI/DTB 和 U-Boot/DTB 是不同的交付链路。必须核验实际固件、启动配方、镜像布局和硬件描述方式。
- 可构建、软件包可用、默认安装和已经验证运行是四种不同结论。

## 证据和报告

- 引用官方 URL；条件允许时同时给出仓库相对路径和行号。
- 说明所检查的分支；对于可变分支，还要给出提交或观察日期。
- 报告未找到结果时必须限定范围，列明检查过的仓库路径和搜索模式。
- 官方页面不完整或受阻时，改用其他官方呈现方式重试，例如 AtomGit tree/blob 视图、官方 raw 内容、发行版文档或项目指定的厂商官方仓库。不得静默切换到镜像。
- 回答长度与用户请求相称。仓库列表问题只返回所需列表；功能支持审查应提供逐项矩阵和剩余集成缺口。