2. 内核源码获取与版本管理:从kernel.org获取源码、Git仓库管理、长期支持版本(LTS)选择策略

2.1 内核源码获取渠道与验证机制

Linux 内核源码的官方发布渠道为 kernel.org,该站点托管了所有正式发布版本的内核压缩包与 GPG 签名文件。嵌入式开发者在获取源码时,必须同时下载对应的 .tar.sign 签名文件,并使用内核维护者的公钥进行完整性校验,以防止供应链攻击或传输损坏。

🔐 源码获取标准流程:
  1. 访问 https://www.kernel.org/,选择目标版本(如 linux-6.6.y 系列)。
  2. 下载 linux-6.6.tar.xz 与 linux-6.6.tar.sign。
  3. 导入内核维护者 GPG 公钥:gpg --locate-keys torvalds@kernel.org gregkh@kernel.org。
  4. 校验签名:xz -cd linux-6.6.tar.xz | gpg --verify linux-6.6.tar.sign -。
  5. 解压并进入源码目录:tar xf linux-6.6.tar.xz && cd linux-6.6。
源码获取与完整性校验流程 kernel.org 下载 .tar.xz 下载 .tar.sign 导入 GPG 公钥 gpg --verify 签名 tar xf 解压 ⚠️ 跳过签名校验可能导致引入被篡改的内核源码,造成安全漏洞或编译失败

2.2 Git 仓库管理与分支策略

对于需要长期维护或频繁定制内核的嵌入式项目,推荐直接克隆 Linus Torvalds 的 mainline 仓库或 Greg Kroah-Hartman 维护的 stable 仓库。Git 仓库管理不仅便于跟踪上游补丁,还能通过分支管理实现多版本并行开发。

仓库类型 Git 地址 适用场景
Mainline git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 跟踪最新开发特性,用于评估新功能或原型验证
Stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git 获取已发布稳定版本的补丁更新,适合产品化开发
LTS Stable 仓库中的 linux-6.6.y 等分支 长期维护产品,需要持续安全更新与关键修复
💡 Git 工作流建议: 在嵌入式项目中,始终从 stable 仓库的 LTS 标签(如 v6.6.1)创建本地开发分支,避免直接基于 master 分支开发。使用 git am 或 git cherry-pick 选择性应用上游补丁,保持与主线的最小差异。
Git 分支管理架构 上游 stable 仓库 linux-6.6.y (LTS) linux-6.1.y (LTS) 本地开发仓库 board_v6.6_dev board_v6.6_patches git clone / fetch git checkout -b git am / cherry-pick 分支管理原则 • 不直接在 master 开发 • 按功能/板型创建分支

2.3 长期支持版本(LTS)选择策略

LTS 版本是嵌入式产品内核选型的基石。每个 LTS 版本会获得至少 2 年的安全更新与关键 Bug 修复,部分版本(如 6.1、6.6)被标记为“超级 LTS”,支持周期可延长至 6 年以上。选择 LTS 版本时需综合考虑硬件支持成熟度、驱动生态、实时性需求以及产品生命周期。

LTS 版本 首发时间 标准支持结束 超级 LTS 结束 推荐场景
5.10.y 2020-12 2022-12 2026-12 工业控制、已量产的成熟产品
5.15.y 2021-10 2023-10 2026-10 物联网网关、边缘计算设备
6.1.y 2022-12 2024-12 2027-12 新项目首选,Rust 支持、Btrfs 改进
6.6.y 2023-10 2025-10 2029-10 最新硬件支持、WiFi 6/7、USB4
⚠️ 版本选择陷阱: 不要盲目追求最新 LTS 版本。对于资源受限的嵌入式系统(如 64MB RAM、单核 Cortex-A7),较新的内核可能引入更大的内存占用或更复杂的调度开销。建议在目标硬件上先进行 defconfig 编译与启动测试,评估基础内存占用与启动时间。
LTS 版本选择决策树 选择 LTS 版本 产品生命周期 < 2年 产品生命周期 2-4年 产品生命周期 > 4年 选 6.6.y (最新LTS) 选 6.1.y (平衡稳定) 选 5.15.y 或 5.10.y 💡 决策依据:硬件支持成熟度 + 驱动生态 + 实时性需求 + 安全更新窗口 建议在目标硬件上先进行 defconfig 编译与启动测试

2.4 版本管理最佳实践清单

  • 使用标签而非分支:在 Git 中,LTS 发布点应使用 git tag 标记(如 v6.6.1),而非创建长期分支。标签是只读的,能防止意外修改。
  • 维护补丁栈:将针对特定板卡的所有修改整理为 .patch 文件,存放在 patches/ 目录下,使用 quilt 或 git format-patch 管理,便于升级内核时快速重演。
  • 定期同步上游:即使使用 LTS 版本,也应每 1-2 个月从 stable 仓库拉取最新补丁,避免累积过多安全漏洞。
  • 记录内核配置:将 .config 文件纳入版本控制,并在提交信息中注明内核版本与补丁层级,确保可追溯性。
📦 补丁栈管理示例:
# 基于 v6.6.1 创建开发分支
git checkout -b board_v6.6_dev v6.6.1

# 应用板级补丁
git am /path/to/patches/0001-board-dts-add-support.patch
git am /path/to/patches/0002-driver-fix-spi-speed.patch

# 导出补丁栈供后续使用
git format-patch v6.6.1 --output-directory=patches/