openEuler OLK-6.6 补丁 Backport 与自研特性如何协调

原始问题：openEuler OLK-6.6上有大量的补丁 Backport、大量自研特性，应该如何协调呢？比如大量灵衢的补丁，比如Intel的补丁，比如 out-of-tree 的鲲鹏、海光、兆芯、飞腾的补丁，还有自研的调度、内存等核心模块的补丁，这些如何应对呢？如何管理比较好，看起来上面的说法太粗了，还是没有解决实质问题。 · 2026-07-03

内核分析

</div>

你的问题切入到了发行版内核工程的核心矛盾。OLK-6.6 实际上是一个典型的”发行版内核”——它不是主线的一个简单快照，而是一个在主线 6.6 基础上叠加了数百到数千个补丁的复合内核。从源码层面的实际表现来看，这些补丁来自多个独立维度且管理诉求不同。

一、OLK-6.6 补丁层级的实证分析

我查看了 OLK-6.6 的源码结构，可以梳理出如下的补丁来源矩阵：

补丁来源	内核中的具体体现	管理层诉求
主线 Backport	来自 master 的 bugfix、特性、安全补丁	与上游对齐，减少技术债
sched_ext (灵衢)	`kernel/sched/ext.c`, `ext.h`, `ext_idle.c/h` — Meta 的 BPF 可扩展调度器类，OLK-6.6 已合并	作为基础设施存在，用户态可自定义调度策略
BPF 调度钩子	`kernel/sched/bpf_sched.c` — openEuler 的 BPF 调度 hook 框架，定义了 `bpf_sched_*` 系列 hook	自研调度特性基础设施
Grid 调度器	`kernel/sched/grid/` — openEuler EAS 类调度器（power.c, qos.c, stat.c）	自研核心调度特性
Soft Domain	`kernel/sched/soft_domain.c` — 华为 2025 年新加的软域调度（Copyright Huawei）	自研调度特性
GMP (广义内存管理)	`mm/gmem.c`, `gmem_*.c` — Huawei 自研统一内存管理框架	自研核心内存特性
可靠内存	`mm/mem_reliable.c` — 可靠内存分级	自研内存特性
本地文件页分配	`mm/filemap_local.c` — 本地内存分配优化	自研性能优化
页缓存限制	`mm/page_cache_limit.c`	自研内存管控
动态内存池	`mm/dynamic_pool.c`	自研内存特性
ARM64 加速	`arch/arm64/Kconfig.turbo` — FAST_SYSCALL, FAST_IRQ	ARM64 平台优化
OOT 厂商补丁	鲲鹏、海光、兆芯、飞腾的 arch/x86, arch/arm64 平台代码	硬件兼容性
Intel 补丁	x86 特定优化、Sapphire Rapids 支持等	x86 平台优化

二、问题的本质：五个独立维度的冲突

从源码实际分析可以抽取出五个互不相同的补丁管理维度，它们的冲突是结构性的：

维度 1: Backport vs 自研新特性

这是最根本的矛盾。Backport 追求”与主线一致“，自研特性追求”与主线不同“。两者的 Patch 都在修改 kernel/sched/fair.c、mm/memory.c 等同一份源文件。

后果: 每次主线有新的 Bugfix 需要 Backport，都可能与自研补丁冲突。冲突解决不是简单的三路合并，而需要理解两套语义的差异。

维度 2: 基础设施型 vs 策略型

基础设施型（如 sched_ext、gmem）：提供框架，本身不改变默认行为，通过 Kconfig 控制编译
策略型（如 Grid 调度器、Soft Domain、可靠内存）：改变核心行为，运行时生效

基础设施型可以干净地与主线共存（#ifdef CONFIG_SCHED_CLASS_EXT），但策略型修改的是核心路径，与主线 Backport 会产生直接冲突。

维度 3: 上游方向性

最终要 upstream 的补丁（如 sched_ext 已经在 upstream 过程中，OLK-6.6 的 ext.c 来自 Meta）
永远不 upstream 的补丁（OOT 厂商平台代码）
自研但不明确是否 upstream 的补丁（Soft Domain、gmem）

不同方向的管理方法完全不同。

维度 4: 修改范围

局部修改（厂商 Driver、Kconfig）：冲突概率低
全局修改（调度器、内存管理核心路径）：每个 Backport 都可能是地雷

维度 5: 维护周期

Backport 补丁：可能只在 6.6 这个版本存在
自研特性：可能需要跨版本演进（6.6 → 6.12 → …）

三、分层分实的管理策略

从 OLK-6.6 的实际源码结构可以看出，以下四个层次分别需要不同的管理方式：

第 0 层：主线基线管理

策略: 定期 rebase 到最新的主线 LTS tag

OLK-6.6 需要选择一个主线基线（如 v6.6.xx 系列），定期向前滚动。这决定了 Backport 补丁的”来源”——那些主线已经合入的补丁不再需要手动 Backport，只需 rebase。

关键指标: 每次 rebase 需要解决多少冲突。冲突数超过阈值意味着自研补丁与主线偏差过大。

第 1 层：自研核心特性（调度、内存）

从 OLK-6.6 源码可见，自研调度和内存补丁的改造非常深：

建议策略：与上游 LTS 解耦，独立演进

sched/ext.c 这类已经在 upstream 的有明确归属，应跟踪主线 sched_ext 的演进并定期合并
kernel/sched/grid/、soft_domain.c、mm/gmem.c 这类纯自研的，应尽量隔离到独立文件中，避免侵入 core.c/fair.c 的核心路径
如果不得不侵入核心路径，需建立补丁标记机制，在 commit message 中标注 openEuler: 前缀，方便 git log --grep 检索和自动化工具识别

具体可行方案:

文件名策略:
  kernel/sched/openEuler/  — 所有 openEuler 自研调度代码
  mm/openEuler/            — 所有 openEuler 自研内存代码

通过 Makefile/Kconfig 进行条件编译
好处: rebase 主线时，这些目录不受影响，只需关注 core 目录中的修改点

第 2 层：厂商 OOT 平台补丁（鲲鹏、海光、兆芯、飞腾）

这些补丁的特点是：

只在特定硬件上使用
通常不 upstream（或者 upstream 进度慢）
对其他平台无影响

建议策略：Kconfig 隔离 + 独立模块

从 OLK-6.6 可以看到 arch/arm64/Kconfig.turbo 就是这种思路的体现——把加速特性单独放在一个 Kconfig menu 中。

arch/arm64/Kconfig.turbo       — Turbo 特性（FAST_SYSCALL, FAST_IRQ）
arch/x86/Kconfig.kunpeng      — 如果适用
drivers/platform/ 下的各厂商驱动

第 3 层：Intel 等上游厂商补丁

Intel 的补丁通常是 x86 特定优化或硬件支持，这类补丁：

建议策略：推上游为主，Backport 为辅

Intel 的补丁最终一定会进入主线
OLK-6.6 中只需临时 Backport，等待下一次 rebase 后自动包含
如果能确保 rebase 周期短于 Intel 补丁的 review 周期，则不需要单独维护

四、关键工程落地手段

4.1 补丁分类目录（从源码中生成本地映射）

在 OLK-6.6 仓库中维护一个 PATCHES.yaml 或 patches/ 目录：

patches:
  - id: "sched-soft-domain"
    type: self-developed
    component: scheduler
    files: ["kernel/sched/soft_domain.c"]
    upstream: false
    maintainer: "Huawei"
    branch: "OLK-6.6"

  - id: "sched-ext"
    type: backport-from-upstream
    component: scheduler
    upstream-status: "merged in v6.12"
    files: ["kernel/sched/ext.c"]

  - id: "gmem"
    type: self-developed
    component: mm
    files: ["mm/gmem.c", "mm/gmem_*.c"]
    upstream: "in progress"

这解决了”哪些是我们加的，哪些是主线的”的基本溯源问题。

4.2 基于 Kconfig 的模块化编译

从 OLK-6.6 已可见的 Kconfig 结构：

CONFIG_SCHED_CLASS_EXT=y        — sched_ext
CONFIG_FAST_SYSCALL=y/n         — Turbo 特性
CONFIG_MEM_RELIABLE=y/n         — 可靠内存
CONFIG_GMEM=y/n                 — 广义内存管理

每个自研特性应做到：default n，只对需要的人开启。这能把编译时冲突降到最低。

4.3 运行时开关

对于调度器策略：

sched_soft_domain=0/1           — 软域开关
grid_sched_enabled=0/1          — Grid 调度器开关

运行时可以切换的特性，意味着即使代码合并到了内核，对不使用的用户也是零影响。

4.4 自动化冲突检测

每当从主线 rebase 或 Backport 补丁时，执行：

## 找出所有与 openEuler 自研补丁冲突的 commit
git log --oneline --grep="openEuler:" HEAD ^master

应建立一个 CI 流水线：

主线发布新 LTS 时自动触发
rebase OLK-6.6_base 到新 LTS tag
尝试 cherry-pick 所有标记为 openEuler: 的补丁
报告冲突情况
人工介入解决冲突并记录解决方式

4.5 补丁生命周期管理

阶段	做法	目标
开发期	在自研分支上开发，提交到 openEuler 主线	功能可用
合入 OLK	打上 `openEuler:` 标签，记录影响范围	可追踪
向上游推送	拆分、适配、提交到 LKML	减少差异
主线合并	从 OLK 中移除对应的 Backport 补丁	消除技术债

每个自研特性应该有一个明确的上游化目标版本。如果一个特性在 3 年周期内都无上游计划，需要重新评估其长期维护成本。

五、社区经验参考

来自 LWN 文章中记录的社区讨论有几个相关观察：

Greg Kroah-Hartman 曾警告不延长 5.10 LTS 维护周期——原因是 Backport 的工作量已经大到不可持续（见：wtarreau 的评论，提到每 release 审查 6000 个 patch 挑选 200 个）。
Sasha Levin 提出的 rolling stable——本质上就是消除”切换版本”的摩擦点。对于 OLK-6.6 来说，更务实的做法是保持一个持续演进的滚动分支，而不是在多个 OLK-x.y 之间跳转。
Jonathan Corbet 的分析——Backport-heavy 内核本质上是”弗兰肯内核”，版本号已经失去了语义。OLK-6.6 的真正版本号并不重要，重要的是它相对主线的增量集合。

六、总结

OLK-6.6 的这种多来源补丁问题的实质是：一个保守的 LTS 基线 + N 个激进的自研特性 + M 个厂商需求 + K 个关键 Backport，在同一个代码仓库中共存。

解决思路不是”减少补丁数量”（这做不到），而是：

分层 — 按来源/类型/影响域分层
隔离 — 独立文件 + Kconfig 条件编译
标记 — 每个补丁打上清晰的来源和用途标签
自动化 — 冲突检测、rebase CI
上游化 — 为每个自研特性设定明确的上游路线图
参考来源

⚠️ 免责声明

本站内容均由 AI 基于公开知识辅助生成，仅供学习参考，请勿直接引用作为依据。作者不对信息的准确性、完整性及适用性作保证，亦不对因使用本站内容产生的任何损失承担责任。