源码树，不是普通 GitHub 项目

torvalds/linux 是很多开发者在 GitHub 上看到的 Linux 内核源码树。页面太熟悉了：stars、forks、文件、提交、README。也正因为熟悉，它容易让人误判。Linux 内核开发不像普通 GitHub 项目，不是开 issue、提 pull request、等 maintainer 点按钮。

README 把读者指回 kernel.org、内核文档、lore.kernel.org、Bugzilla、MAINTAINERS 文件，以及不同角色的文档入口。这才是正确理解方式。GitHub 很适合浏览和 clone。真正的开发流程分散在 maintainer trees、邮件列表、子系统规则、signed-off patch、review 线程、stable 分支和下游厂商树里。

当你需要主线内核源码、想查实现细节、想本地构建内核做测试、或需要为 patch 讨论找参考点时，这个仓库很有用。不要把它当支持论坛、包管理器，或你笔记本发行版内核的直接来源。

源码树里有什么

这个仓库就是内核本身：架构代码、驱动、文件系统、网络、内存管理、调度器、安全钩子、用户态 API、 tracing、测试、构建脚本，以及很大的 Documentation 树。主要语言是 C，旁边还有汇编、Rust 支持、脚本、构建元数据和文档源文件。

README 很短，因为源码树本身才是主体。它给不同读者不同入口。新内核开发者从 development process、submitting patches、coding style、kbuild、development tools 和 kernel hacking 文档开始。研究者会看 memory management、scheduler、networking、filesystems、RCU、locking 和 power management。系统管理员会看 admin guide、kernel parameters、sysctl、tracing 和 performance security。硬件厂商会看 driver API、device model、bus、device tree bindings、power management 和 DMA API。

这个角色地图很有用，因为内核太大，没法用一条游览路线讲完。第一个好问题不是“代码在哪里”，而是“我要进入哪个子系统和哪套 maintainer 流程”。

从源码构建内核

这里没有应用安装步骤。你是在构建内核，这会触及启动路径、模块、固件假设，有时还会碰到 Secure Boot 策略。树内的 Documentation/admin-guide/quickly-build-trimmed-linux.rst 是构建 trimmed test kernel 的实用入口。

这份文档会让读者先处理 Secure Boot 限制，安装编译器、Git、OpenSSL headers、bc、bison、flex、pahole、Perl、binutils 和 libelf headers 等构建依赖，并准备足够空间放源码和构建产物。随后它会讲如何 clone 当前内核树，基于正在运行的系统生成配置，用 make 构建，安装模块和内核，再重启。

第一次构建时，重要目标包括 make localmodconfig、make olddefconfig、make htmldocs、make modules_install 和 make install。具体命令会受发行版和机器策略影响，所以不读文档就复制片段并不划算。Debian、Arch、使用 Secure Boot 的系统，以及硬件比较特殊的机器，都容易在细节上出问题。

贡献流程不是 GitHub 优先

内核 patch 流程围绕邮件和 maintainer。Documentation/process/submitting-patches.rst 要求贡献者先拿到当前源码树，理解相关子系统，描述问题，解释用户可见影响，给性能或体积声明配数据，把逻辑变更拆成独立 patch，并把工作发给正确的 maintainer 和邮件列表。

MAINTAINERS 文件不是礼仪名单。它把文件和子系统映射到 maintainer、邮件列表、review 渠道、状态标签、源码树、bug tracker 和 patchwork。很多子系统 maintainer 希望 patch 基于自己的树准备，而不是直接对 Linus Torvalds 的 mainline tree 动手。这就是为什么对 torvalds/linux 提 GitHub pull request，通常不是内核工作的正确动作。

这也解释了 GitHub issue 数为什么容易误导。截至 2026-06，本地快照显示 GitHub open issues 只有 3 个。这不代表 Linux 内核只有三个活跃问题。它只说明这个镜像上的 issue 区不是内核工作的中心。

AI coding assistants 有明确规则

当前 README 专门给 AI coding assistants 放了入口，指向 Documentation/process/coding-assistants.rst。这份文档很直接。AI 工具必须遵守正常内核开发流程。贡献必须满足内核许可规则。AI agents 不能添加 Signed-off-by tags，因为只有人能认证 Developer Certificate of Origin。人类提交者必须 review 代码、承担责任，并添加自己的 sign-off。

这点值得单独写，因为通用 coding assistant 很容易从小项目里学到 GitHub 习惯。内核流程更重法律责任和可追踪性。如果 AI 参与，文档给出了 Assisted-by tag 格式。Git、编译器、make、编辑器这些基础工具不列进去。

Mainline、厂商树和发行版树

torvalds/linux 是 mainline source。它不同于发行版发给你的内核。发行版内核还包含配置选择、backports、patches、模块策略、签名和发布工程。它也不同于 Raspberry Pi 的 Linux tree 或微软的 WSL2 kernel tree 这类厂商树，后者会带平台约束和产品需求。

仓库 Stars 范围 适合场景
torvalds/linux 236,054 Linux mainline kernel source 需要上游源码、历史、文档或内核工作基线
raspberrypi/linux 12,931 Raspberry Pi kernel tree 需要 Pi 相关内核构建和平台改动
microsoft/WSL2-Linux-Kernel 10,445 WSL2 使用的 Linux kernel source 研究或调试 WSL2 kernel variant
zephyrproject-rtos/zephyr 15,572 Embedded RTOS project 需要小设备 RTOS，而不是 Linux kernel

数字来自 2026-06 的 GitHub 快照。这个对比看的是角色，不是声望。Mainline 是上游参考。厂商树和发行版树承接产品约束。RTOS 项目解决的是另一类嵌入式问题。

这页最适合怎么用

读代码时，不要从顶层目录漫游。先选子系统。如果你关心文件系统、网络、内存管理、调度器、驱动或安全，先用文档索引和 MAINTAINERS 文件定位区域，再带着该子系统的 patch 流程读代码。

构建内核时，先读 trimmed kernel guide，再碰 bootloader 设置。贡献代码时，先读 development process 和 submitting patches，再准备任何变更。报告 bug 时，按 reporting guide 走，而不是随手开 GitHub issue。

star 曲线能说明这个仓库的公众可见度，但它很难说明开发健康度。Linux 真正的健康度在发布节奏、子系统 review、邮件列表流量、stable 维护、下游采用，以及厂商和发行版持续构建在它之上。GitHub stars 是地图标记，不是项目脉搏。

相关

如果你想通过重做小型系统来学习，codecrafters-io/build-your-own-x 里有操作系统和底层项目。想看更宽的开发者学习路径，nilbuild/developer-roadmap 是更上层的地图。讨论内核层以上的架构取舍时，donnemartin/system-design-primer 更合适。

FAQ

torvalds/linux 是官方 Linux kernel repository 吗？ 它是 GitHub 上的 mainline Linux kernel source tree，关联 Linus Torvalds 的树。kernel.org 和 lore.kernel.org 仍然是源码、发布、文档和开发讨论的重要入口。

可以给 Linux 提 GitHub pull request 吗？ 正常内核工作不要这样做。先读 Documentation/process/submitting-patches.rst，通过 MAINTAINERS 找到正确 maintainer，再按对应子系统期望的邮件列表流程提交。

怎么从源码构建 Linux kernel？ 读 Documentation/admin-guide/quickly-build-trimmed-linux.rst。它覆盖构建依赖、基于当前系统生成配置、kernel build targets、模块安装、启动细节和发行版相关坑。

为什么 GitHub issues 这么少？ GitHub issue count 不是内核真正的 bug 队列。内核报告和 review 分布在 Bugzilla、邮件列表、maintainer 渠道、下游 tracker 和子系统流程里。

Linux kernel 用什么 license？ 顶层 COPYING 文件写明 GPL version 2 only with the Linux syscall note，并指向树内 license rules，说明带其他兼容声明的文件如何处理。