Linux 内核达到了又一个重要里程碑。最新的 Linux 7.2 开发树 在所有跟踪文件中包含约 43.2 百万 total 行，或者根据 tokei 和 scc 工具报告，约 42.6 百万 语言感知行。
我们在官方 v7.2-rc1 标签上使用 4 种不同的代码计数工具独立验证了这些数字。根据我们的测量，这是迄今为止最大的 Linux 内核源代码树。
乍一看，这个数字可能很大。但这并不意味着 Linux 变得臃肿。相反，它表明了两件事：Linux 今天支持多少硬件，以及内核继续发展的活跃程度。
让我们看看发生了什么变化。
Linux 7.2 突破 42 百万行大关
我使用多种代码计数工具测量了 Linux 7.2-rc1 Git 树。为了演示，我使用了确切的 v7.2-rc1 标签提交（dc59e4fea9d8）。
ostechnix@fedora:~/linux$ git log --oneline -1
dc59e4fea9d8 (HEAD -> master, tag: v7.2-rc1, origin/master, origin/HEAD) Linux 7.2-rc1
ostechnix@fedora:~/linux$ git describe --tags
v7.2-rc1
ostechnix@fedora:~/linux$ git rev-parse HEAD
dc59e4fea9d83f03bad6bddf3fa2e52491777482
以下是每个工具发现的结果：
我在同一个 Fedora VM 会话中，针对同一个 Git 检出（dc59e4fea9d8），使用相同的工具版本运行了所有四个工具。这使得结果可以直接比较和复现。
早期使用 cloc v1.96 的测试产生了几乎相同的 total 40,414,638。微小的差异来自 cloc v2.08 的改进，它识别了一些额外的文件格式，如 Jinja Template 和 Snakemake。
Tokei 和 scc 几乎完全一致，两者都报告约 42.58 百万 total 行。它们的独立结果仅相差 2,159 行（约 0.005%），使它们成为 Linux 源代码树最一致的语言感知测量结果。
相比之下，默认的 cloc 运行少计了内核约 2.17 百万 行，因为它默认不识别 Linux 设备树（.dts/.dtsi）源文件。我通过重新运行 cloc 并添加以下参数验证了这一点：
cloc --force-lang="C",dts --force-lang="C",dtsi .
这使 cloc 的 total 增加了约 2.1 百万 行，使其结果与 tokei 和 scc 接近一致。
我在 Linux 7.1 和 7.2-rc1 上都重现了相同的行为，确认差异来自 cloc 的默认语言识别，而不是内核本身的变化。
“43 百万”标题的来源
对仓库中所有跟踪文件进行原始 wc -l 计数，得到 43,179,595 行。这就是“43 百万行”标题的来源。
这个数字与 tokei 和 scc 报告的 total 之间存在约 597,000 行的差距。这种差异的存在是因为 wc -l 计算每个跟踪文件中的每一行，而语言感知工具则有意排除或不同地分类许多非源文件。示例包括文档、元数据、图像、证书以及仓库中的其他非源或未识别格式。
值得注意的是，一个干净的 Linux 内核 Git 检出 不包含已编译的 .dtb 二进制文件 和 没有 firmware/ 目录（固件 blob 在 linux-firmware 仓库中单独维护）。因此，这些文件不会导致这种差异。
简而言之，43 百万 标题在技术上是准确的，因为它反映了 Git 树中存储的每一行。然而，tokei 和 scc 报告的 42.58 百万 数字是内核源代码更准确的测量。
Linux 7.2 延续内核的增长
为了测量内核在此开发周期中的增长量，我在最终的 Linux 7.1 版本上使用相同的 Fedora VM、工具版本和方法重复了相同的测量。
结果显示所有三种测量方法之间具有显著的一致性。tokei 和 scc 都报告 Linux 在 Linux 7.1 和 7.2-rc1 之间增加了约 563,000 语言感知行，代表在一个开发周期内增长了约 1.3%。原始 wc -l 计数显示类似大小的增加，为 572,677 行。
这听起来很惊人，但完全在意料之中。每个 Linux 内核版本都会添加对新处理器、平台、文件系统、驱动程序、虚拟化技术和安全改进的支持，同时继续完善现有子系统。
根据 Linux 7.1 最终发布说明，超过 2,000 名开发者 贡献了更改，包括超过 300 名首次贡献者。如此规模的持续贡献自然会随着时间的推移转化为源代码树的稳定增长。
Linux 即使在删除旧代码后仍在增长
这个里程碑的一个令人惊讶的方面是，即使在删除遗留代码的同时，Linux 内核代码仍在继续增长。
Linux 7.1 开始放弃对 Intel i486 处理器的支持，删除了超过 140,000 行过时代码，包括遗留的 PCMCIA 主机控制器和 ISDN 驱动程序。Linux 7.2 通过删除额外的 i486 相关代码以及几个过时的驱动程序和遗留的 x86 组件，继续这种清理工作。
换句话说，Linux 开发者不断平衡添加和删除。虽然新的硬件支持、架构、驱动程序、文件系统和安全功能扩展了内核，但过时的代码会定期退役，以减少维护负担并保持项目的现代化。
为什么 Linux 内核如此庞大？
答案是 驱动程序。
Linux 内核支持令人难以置信的多种硬件。每张显卡、存储控制器、网卡、笔记本电脑功能、USB 设备和嵌入式平台都需要内核支持。
随着新硬件进入市场，开发者添加新的驱动程序。同时，他们保持与现有设备的兼容性。因此，内核的大部分增长来自硬件支持。内核核心调度或内存管理代码的增长非常少。
AMDGPU 仍然是最大的驱动程序
最大的贡献者仍然是 AMD 图形子系统。
组合的 AMDGPU 和 AMDKFD 驱动程序包含约 6.35 百万行 代码。这使其成为整个 Linux 内核中最大的驱动程序。
Linus Torvalds 指出了一个有趣的事情。一个大型拉取请求中大约三分之一是 AMD GPU 寄存器定义文件。这些文件大多是生成的数据。它们帮助 Linux 与现代 AMD 图形硬件通信。
更大并不意味着更慢
许多人认为更多的代码行意味着更慢的软件。但 Linux 内核并非如此。
大部分额外代码的存在是为了支持许多用户永远不会拥有的硬件。其中很多存在于可加载模块中。这些模块仅在匹配的硬件存在时激活。
因此，内核在扩展硬件兼容性的同时不断改进。这适用于桌面、服务器、笔记本电脑、嵌入式系统、云平台和超级计算机。
计算 Linux 内核代码的总行数
任何人都可以克隆 Linux 内核仓库并进行测量。首先，获取内核源代码：
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux
完整克隆约 5 GB。你可以向 git 命令添加 --depth=1 以进行浅克隆（约 1.5 GB）：
git clone --depth=1 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
在本指南中，我使用了完整克隆。
方法 1：cloc（广泛引用的参考工具）
cloc 是内核行计数最常用的工具。
# Install
sudo apt install cloc # Debian/Ubuntu
sudo dnf install cloc # Fedora/RHEL
sudo pacman -S cloc # Arch
现在，运行：
cloc --progress=1 .
注意末尾的点（.）。意思是——我们指示 cloc 分析当前目录。
根据你的硬件，cloc 扫描完整的 Linux 源代码树可能需要 几分钟。在我的 Fedora VM 上，它在大约 3–4 分钟 内完成。
示例输出：
94718 text files.
82309 unique files.
12415 files ignored.
github.com/AlDanial/cloc v 2.08 T=276.85 s (297.3 files/s, 145986.6 lines/s)
----------------------------------------------------------------------------------------
Language files blank comment code
----------------------------------------------------------------------------------------
C 36898 3801120 2908960 19610084
C/C++ Header 26648 791061 1600637 8405094
JSON 833 2 0 553530
reStructuredText 4011 197901 81994 540661
YAML 5675 104970 25957 518427
Assembly 1343 47625 99191 230030
Bourne Shell 1321 40912 27301 159379
Rust 473 15277 52795 114347
Python 428 21148 18854 90203
Text 975 19724 0 89632
make 3188 12948 13377 60578
SVG 87 98 1311 56094
Perl 69 6811 4558 34796
XML 32 1514 1706 23049
yacc 10 723 442 4848
PO File 7 1106 1269 4336
Bourne Again Shell 63 631 416 2584
lex 10 366 355 2219
C++ 9 356 143 1917
awk 16 374 480 1743
CSV 11 126 0 1413
Jinja Template 102 69 98 794
NAnt script 2 167 0 610
Logos 4 115 0 547
Markdown 9 162 3 514
XML (Qt/GTK) 1 50 0 486
XSD 1 46 9 349
CSS 4 71 96 244
Cucumber 1 40 97 199
TeX 1 6 73 155
TNSDL 2 33 0 140
Windows Module Definition 2 20 0 137
Linker Script 5 25 11 126
Snakemake 5 15 13 125
Clojure 36 1 0 95
m4 1 15 1 95
XSLT 5 13 26 61
BitBake 5 65 178 58
Umka 2 20 0 54
TOML 3 9 12 36
MATLAB 1 17 37 35
INI 3 6 0 34
sed 2 23 52 31
vim script 1 3 12 27
HTML 2 4 5 25
Ruby 1 4 0 25
Velocity Template Language 1 0 0 15
----------------------------------------------------------------------------------------
SUM: 82309 5065792 4840469 30509981
----------------------------------------------------------------------------------------
注意： cloc 不识别设备树源文件（.dts/.dtsi）。这是它少计内核的部分原因（参见本指南前面的分析）。
要仅测量 AMD 图形驱动程序，运行：
cloc drivers/gpu/drm/amd
方法 2：tokei（更快、更准确，推荐）
tokei 比 cloc 快得多。它还能正确计数设备树文件。这使其成为 Linux 内核更准确的选择。
首先，确保系统已安装 Rust。然后，使用 cargo 包管理器安装 tokei：
cargo install tokei
tokei 也可在某些发行版的官方仓库中获得，因此你可以使用默认包管理器安装，如下所示：
sudo apt install tokei
brew install tokei
现在，运行：
tokei .
示例输出：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Language Files Lines Code Comments Blanks
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AWK 13 2805 1923 500 382
Alex 4 662 547 0 115
ASN.1 15 656 441 87 128
Assembly 11 5781 5445 0 336
GNU Style Assembly 1337 371255 270423 56888 43944
Autoconf 6 459 395 30 34
Automake 3 31 23 3 5
BASH 62 3038 2094 437 507
Bazel 81 1829 1474 54 301
Bitbake 3 13 4 6 3
C 36910 26320472 19615926 2909605 3794941
C Header 26813 10822880 8416361 1615212 791307
C++ 7 2291 1969 81 241
C++ Header 2 125 59 55 11
CSS 4 411 244 97 70
Device Tree 6343 2097441 1724154 92401 280886
Forge Config 15 1352 321 744 287
Gherkin (Cucumber) 1 336 199 97 40
Happy 10 6013 5290 0 723
HEX 2 173 173 0 0
INI 2 13 6 5 2
Jinja2 149 1187 966 145 76
JSON 1043 607008 607006 0 2
Lex 10 2940 2218 356 366
LD Script 13 552 427 40 85
Makefile 3203 87274 60667 13531 13076
Module-Definition 2 157 137 0 20
Objective-C 1 89 72 0 17
Pacman's makepkg 1 134 91 13 30
Perl 61 43189 33862 4009 5318
PO File 7 6711 3346 2259 1106
Python 439 130209 102002 8291 19916
RPM Specfile 1 215 174 14 27
ReStructuredText 4011 820556 622655 0 197901
Ruby 1 29 25 0 4
Shell 1172 219683 153221 27411 39051
Snakemake 5 153 125 13 15
SVG 87 57503 56094 1311 98
SWIG 1 252 154 27 71
TeX 1 234 155 73 6
Plain Text 981 109702 0 89924 19778
TOML 3 57 36 12 9
Unreal Script 5 618 371 156 91
Apache Velocity 1 15 15 0 0
Vim Script 1 42 33 6 3
XSL 10 200 122 52 26
XML 32 26269 23572 1452 1245
YAML 5673 648526 529448 23888 95190
─────────────────────────────────────────────────────────────────────────────────
HTML 2 29 25 0 4
|- JavaScript 1 7 7 0 0
(Total) 36 32 0 4
─────────────────────────────────────────────────────────────────────────────────
Markdown 9 534 0 385 149
|- BASH 1 2 2 0 0
|- C 1 20 12 6 2
|- Rust 1 98 76 13 9
|- YAML 1 25 22 0 3
(Total) 679 112 404 163
─────────────────────────────────────────────────────────────────────────────────
Rust 473 143187 114374 13573 15240
|- Markdown 351 39084 913 29885 8286
(Total) 182271 115287 43458 23526
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Total 89042 42584526 32359896 4893147 5331483
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
它在 一分钟内 完成，并与 scc 的结果紧密匹配（参见下一节）。
方法 3：scc（最快，带有复杂度指标）
scc 与 tokei 的准确性相匹配。它还报告每种语言的 圈复杂度。这对于理解内核的哪些部分最难维护很有用。
确保系统已安装 Golang，然后运行以下命令安装 scc：
go install github.com/boyter/scc/v3@latest
现在，运行：
scc .
示例输出：
───────────────────────────────────────────────────────────────────────────────
Language Files Lines Blanks Comments Code Complexity
───────────────────────────────────────────────────────────────────────────────
C 36,910 26,320,472 3,795,058 2,909,421 19,615,993 2,566,279
C Header 26,813 10,822,880 791,303 1,614,799 8,416,778 66,444
Device Tree 6,343 2,097,441 280,886 92,367 1,724,188 36
YAML 5,672 648,427 104,949 25,934 517,544 0
ReStructuredTe… 4,011 820,556 197,878 0 622,678 0
Makefile 3,203 87,274 13,076 13,531 60,667 464
Assembly 1,348 377,036 41,691 49,680 285,665 3,505
Shell 1,174 220,250 37,034 26,897 156,319 12,925
JSON 1,043 607,008 2 0 607,006 0
Plain Text 981 109,702 19,777 0 89,925 0
Rust 473 182,419 15,156 52,407 114,856 10,808
Python 439 130,209 15,774 13,048 101,387 15,323
Jinja 149 1,187 76 145 966 193
SVG 87 57,503 98 1,311 56,094 2
Perl 67 46,073 6,048 4,183 35,842 5,246
BASH 63 3,399 513 413 2,473 324
DOT 36 1,261 81 62 1,118 0
XML 32 26,269 1,465 1,755 23,049 0
AWK 17 3,102 311 232 2,559 532
CSV 11 1,539 126 0 1,413 0
Extensible Sty… 10 200 26 0 174 0
Happy 10 6,013 723 0 5,290 0
LEX 10 2,940 366 355 2,219 0
Markdown 9 679 162 0 517 0
LD Script 8 390 60 29 301 0
C++ 7 2,291 241 81 1,969 332
Autoconf 6 459 34 30 395 11
License 5 422 84 0 338 0
Snakemake 5 153 15 13 125 0
Unreal Script 5 618 91 156 371 21
Alex 4 662 115 0 547 0
CSS 4 411 70 97 244 0
Raku 3 213 19 21 173 33
Systemd 3 167 25 63 79 0
TOML 3 57 8 12 37 0
Bazel 2 777 167 177 433 6
C++ Header 2 125 11 55 59 2
HEX 2 173 0 0 173 0
HTML 2 34 4 5 25 0
INI 2 13 2 5 6 0
Module-Definit… 2 157 20 0 137 4
bait 2 64 4 15 45 9
sed 2 106 23 53 30 0
CloudFormation… 1 99 17 2 80 0
Gherkin Specif… 1 336 40 97 199 0
MATLAB 1 89 17 37 35 3
Ruby 1 29 4 0 25 1
Scallop 1 3 0 0 3 0
TeX 1 234 6 73 155 0
Vim Script 1 42 3 12 27 5
XML Schema 1 404 46 0 358 0
───────────────────────────────────────────────────────────────────────────────
Total 88,988 42,582,367 5,323,705 4,807,573 32,451,089 2,682,508
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $1,473,621,894
Estimated Schedule Effort (organic) 219.99 months
Estimated People Required (organic) 595.12
───────────────────────────────────────────────────────────────────────────────
Processed 1595970277 bytes, 1595.970 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────
在 v7.2-rc1 树上，scc 还估计了从头重建内核的成本。使用 COCOMO 有机模型，估计约为 $1.47 亿。你可以在输出末尾附近看到这个细节。
方法 4：wc -l（快速全文件完整性检查）
wc 命令计算每个文件中的每一行，无论类型如何。这包括二进制和非文本文件。它产生所有四个工具中最高的数字。
find . -not -path './.git/*' -type f \
| xargs wc -l 2>/dev/null \
| awk '/total/{sum += $1} END{print sum}'
示例输出：
43179595
请注意，wc 不是语言感知的代码计数器。但它为 Git 树中存储的 total 行数提供了一个有用的上限。
注意： 不要在末尾添加 | tail -1（即 -L）。当有数万个文件时，xargs 会将它们分成多个批次。每个批次打印自己的 total 行。使用 tail -1 只捕获最后一个批次的子 total。这会产生一个严重错误的结果。
工具比较
Linux 7.2 代码统计摘要
在提交 dc59e4fea9d8（标签：v7.2-rc1）上测量，2026 年 30 月 2026 日：
结论
突破 42 百万行 不仅仅是一个有趣的统计数据。它反映了世界上最大的协作软件项目之一的规模。
Linux 内核维护者不断添加对新硬件的支持。同时，他们删除已到达使用寿命终点的平台的代码。结果是一个在需要的地方增长、在可能的地方变得更干净的内核。
对于 Linux 爱好者来说，这个里程碑再次提醒我们内核开发的速度有多快。它也显示了支持从微小嵌入式板到世界上最快的超级计算机的所有一切需要多少工作。
来源：
