oEEP/oEEP-0006 openEuler内核kconfig翻新及内核包拆分.md · openEuler/TC

---
标题:    openEuler内核kconfig翻新及内核包拆分
类别:    特性变更
摘要:    开启内核kconfig中更多模块项，并拆分内核包允许按需安装
作者:    刘恺（kai.liu at xfusion.com）
状态:    接纳
编号:    oEEP-0006
创建日期: 2023-07-20
修订日期: 2023-07-26
---

## 动机与目标

目前openEuler内核与其它主流发行版内核相比，开启编译为模块（=m）的kconfig选项数量明显较少。由于绝大多数硬件驱动以模块形式存在，此差异造成了openEuler内核支持的驱动数量相对较少，不利于支持更多硬件平台。

下表是对当前主流发行版x86_64内核的kconfig选项情况的一个简单对比。

| 发行版              | 内核版本 | =y         | =m         | Not set    |
| ------------------- | -------- | ---------- | ---------- | ---------- |
| openEuler 22.03 SP2 | 5.10     | 2021 / 30% | 2362 / 35% | 2441 / 36% |
| CentOS 8.5          | 4.18     | 1964 / 30% | 2534 / 38% | 2105 / 32% |
| Debian 12           | 6.1      | 2407 / 28% | 3861 / 45% | 2336 / 27% |
| Fedora 38           | 6.3      | 2679 / 31% | 4140 / 47% | 1899 / 22% |
| openSUSE 15.5       | 5.14     | 2569 / 29% | 4529 / 52% | 1633 / 19% |
| Arch Linux 20230717 | 6.4.3    | 2865 / 30% | 5747 / 61% | 814 / 9%   |
| Ubuntu 22.04.02     | 5.15     | 2790 / 30% | 5837 / 62% | 780 / 8%   |

由于各个发行版的内核版本差异较大，支持的kconfig总量也有较大差异，因此关注各类型选项所占比例更为合理。由上表可以得出以下结论：

1. 各发行版设置`=y`的选项比例都在30%左右，差别不大。但`=m`和`not set`的差异明显。
2. 其它发行版开启模块的kconfig选项占总选项的比例均高于openEuler。
3. 更偏向于桌面个人用途的发型版如Arch Linux、Ubuntu，其模块比例显著较高。
4. Debian、Fedora、openSUSE等兼顾桌面和服务器用途的发行版，模块比例也比openEuler明显更高，但比桌面发行版低。
5. CentOS主要面向服务器用途，但模块比例也比openEuler稍高。

因此，为了能缩小与其它发行版的差距，支持更多的硬件设备，尤其是开发者和个人用户经常使用的各类PC硬件，需要将更多硬件驱动模块开启。

## 对 openEuler 的益处和风险影响

### 益处
1. 支持更多的硬件驱动，减少用户遇到设备不支持，需要重编译内核或单独安装驱动的不便。
2. 便于更多用户在真实硬件上测试和使用openEuler，回报问题，提升南向兼容性。
3. 对内核包进行拆包后，虚拟化和云等场景下不再需要安装物理硬件的驱动，减少磁盘占用。

### 风险
1. 内核包会显著变大，占用更多磁盘空间，对于需精简OS磁盘占用的场景不利。
2. 内核包编译、打包、测试、门禁等所需时间会显著增加。
3. 当前未开启的功能，其代码可能会存在编译错误，需要修复。并且会增加未来的代码维护工作量。
4. 理论上更多功能和驱动被开启后，使得内核安全风险面变大，可能有更多的漏洞能被利用。
5. 支持更多的硬件驱动和功能特性后，会导致更多的支持和服务请求。

为规避风险1，需要将内核包进行拆分，使得各种场景可以按需安装所需要的模块，减少磁盘空间占用。

## 方案描述

### 内核kconfig调整
- 以Fedora、openSUSE、Debian等综合性发行版为目标，分析其驱动模块策略。定义openEuler的模块策略，目标是`=m`比例达到50%左右。
- 过去设置为`not set`的选项，凡属于驱动类、模块化功能类的，根据上述模块策略进行修改。因多个选项互斥n选一而导致的`not set`则保持不变。
- 未来随着回合新代码或版本升级引入的更多kconfig选项，应同样遵守以上原则，可设置为`=m`的都设置。

### 内核包拆分
在开启更多内核配置选项后，需将内核包拆分成以下多个子包：

| 包名           | 内容                                                                 | 作用和适用场景                                                         |
| -------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| `kernel-minimal` | 内核基础文件，包括vmlinuz，核心ko如文件系统，iptables，virtio等                                    | 在虚拟化环境下启动所需的最小内核。适用于虚拟化和云环境 |
| `kernel-base`    | 更多的ko文件，主要支持服务器平台硬件设备，如RAID卡，网卡             | 支持常见的服务器硬件，使得裸金属部署可开箱即用                             |
| `kernel-extras`  | 更多PC桌面、嵌入式等平台硬件设备的ko文件，如wifi、声卡、蓝牙、多媒体设备等 | 支持开发者和个人用户常用的PC桌面和嵌入式开发设备 |

以上三个子包间存在依赖关系，下方的包依赖上方的包。即如需安装kernel-base，则会自动依赖引入kernel-minimal，保证内核基础文件始终会被安装。

当前内核包spec文件需做修改，增加subpackage定义，按以上分类标准将对应的文件打包到不同subpackage中。现有的kernel-{devel,headers,source,tools,tools-devel}等子包不变。

### 升级策略
当前版本的kernel包，在整系统升级时应迁移到kernel-base包。原因为：
- Base包的模块范围与原kernel包的最接近。
- Base包适用的服务器场景是openEuler的主流场景。

### 安装过程增强

oemaker需修改适配新的内核子包。

安装器Anaconda也需进行增强，安装时根据检测到的平台特征，自动推荐安装合适的内核子包，同时也支持由用户自行选择所需内核子包。

## 范围/相关人员及职责

### Kernel SIG
- 内核kconfig变更详细评估、策略定义和调整
- 编译错误修复
- 内核包spec文件修改
  - 定义各子包的模块文件列表
- 后继版本的持续维护和支持

### OS-Builder SIG
- Anaconda修改
- oemaker修改

### QA SIG
- 定义内核分包后各子包的测试策略
- 内核测试流程适配
- 安装场景测试流程适配

### Compatibility SIG
- 定义内核分包后各子包的兼容性策略，包括社区的兼容性测试策略和OSV认证中的兼容性一致性策略，避免对OSV版本的兼容性认证产生冲击。例如：对kernel-extras包中的模块，不强制要求OSV认证必须兼容。
- 兼容性测试流程适配

### Infra SIG
- OBS/EBS构建环境适配
- 虚拟机镜像发布物适配

### Doc SIG
- 发布说明和文档更新

## 范围/相关软件

至少以下软件包/仓受到影响需修改：

- kernel
- anaconda
- oemaker

## 用户体验

整体用户体验可获得提升或至少不会下降。

- 开发者：可支持更多的开发设备。
- 个人用户：可支持更多的PC硬件设备。
- 物理服务器用户：体验基本不受影响，少量以前未开启的服务器硬件驱动在开启后可小幅提升使用体验。
- 云用户：体验小幅提升，通过安装kernel-minimal可小幅节省磁盘空间占用。

## 发布说明

发布说明中需介绍内核包的拆分，各个子包的作用和适用场景。

## 升级与兼容性影响

需合理的设置`Provides`和`Obsoletes`，使得：

- 从旧版本单一kernel包升级时，dnf可以自动处理升级，无需首次升级时手动安装内核子包。
- 其它依赖于kernel包的软件包可以自动满足依赖。

## 如何测试

由于新开启的内核模块涉及到的硬件数量较大，且会涉及到大量非服务器平台的硬件，全量完整功能测试和兼容测试不现实。因此策略为：

- 现有社区测试中覆盖到的设备/驱动/功能等维持不变，不造成体验劣化。测试环境需针对新的子包名进行适配，确保不会因为包名的变化导致未安装和测试到应测的内核模块。

- 新增的内核模块（主要在kernel-extras包中）进行最小测试，保证RPM包正常、安装/卸载过程更新initramfs正常、不影响系统正常启动。

## 实施计划
计划在23.09创新版本实施验证，并进入24.03 LTS版本。

openEuler/TC

简介

发行版

贡献者

近期动态

openEuler/TC .gitee-modal { width: 500px !important; }

简介

发行版

开源评估指数源自 OSS-Compass 评估体系，评估体系围绕以下三个维度对项目展开评估：

贡献者

近期动态

搜索帮助

openEuler/TC