The Linux kernel has reached another major milestone. The latest Linux 7.2 development tree contains approximately 43.2 million total lines across all tracked files, or about 42.6 million language-aware lines according to tokei and scc tools.
We independently verified these figures on the official v7.2-rc1 tag using 4 different code-counting tools. Based on our measurements, this is the largest Linux kernel source tree to date.
At first glance, that number may seem huge. But, it does not mean Linux has become bloated. Instead, it shows two things: how much hardware Linux supports today, and how actively the kernel continues to evolve.
Let's look at what changed.
Table of Contents
Linux 7.2 Breaks the 42 Million Line Mark
I measured the Linux 7.2-rc1 Git tree using multiple code-counting tools. For demonstration purpose, I used the exact v7.2-rc1 tag commit (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
Here is what each tool found:
| Tool | Files | Total Lines | Code Lines | Comments | Blanks |
|---|---|---|---|---|---|
| cloc v2.08 | 82,309 | 40,416,242 | 30,509,981 | 4,840,469 | 5,065,792 |
| tokei | 89,042 | 42,584,526 | 32,359,896 | 4,893,147 | 5,331,483 |
| scc | 88,988 | 42,582,367 | 32,451,089 | 4,807,573 | 5,323,705 |
| wc -l (all files) | - | 43,179,595 | - | - | - |
I ran all four tools in the same Fedora VM session against the same Git checkout (dc59e4fea9d8) using identical tool versions. This makes the results directly comparable and reproducible.
An earlier test with cloc v1.96 produced a nearly identical total of 40,414,638 lines. The small difference comes from improvements in cloc v2.08, which recognizes a few additional file formats such as Jinja Template and Snakemake.
Tokei and scc agree almost perfectly, both reporting about 42.58 million total lines. Their independent results differ by only 2,159 lines (about 0.005%), making them the most consistent language-aware measurements of the Linux source tree.
By comparison, the default cloc run undercounts the kernel by roughly 2.17 million lines because it does not recognize Linux Device Tree (.dts/.dtsi) source files by default. I verified this by rerunning cloc with:
cloc --force-lang="C",dts --force-lang="C",dtsi .
This increased cloc's totals by approximately 2.1 million lines, bringing its results into close agreement with both tokei and scc.
I reproduced the same behavior on both Linux 7.1 and 7.2-rc1, confirming that the discrepancy comes from cloc's default language recognition rather than a change in the kernel itself.
How the "43 million" headline is derived
A raw wc -l count across every tracked file in the repository produces 43,179,595 lines. This is where the "43 million lines" headline comes from.
There is a gap of roughly 597,000 lines between this figure and the totals reported by tokei and scc. This difference exists because wc -l counts every line in every tracked file, while language-aware tools intentionally exclude or classify many non-source files differently. Examples include documentation, metadata, images, certificates, and other non-source or unrecognized formats throughout the repository.
It is worth noting that a clean Linux kernel Git checkout contains no compiled .dtb binaries and no firmware/ directory (firmware blobs are maintained separately in the linux-firmware repository). Therefore, those files do not contribute to this difference.
In short, the 43 million headline is technically accurate because it reflects every line stored in the Git tree. However, the 42.58 million figure reported by tokei and scc is the more accurate measurement of the kernel's source code.
Linux 7.2 Continues the Kernel's Growth
To measure how much the kernel grew during this development cycle, I repeated the same measurements on the final Linux 7.1 release using the same Fedora VM, tool versions, and methodology.
| Metric | Linux 7.1 | Linux 7.2-rc1 | Growth |
|---|---|---|---|
tokei | 42,021,677 | 42,584,526 | +562,849 |
scc | 42,019,634 | 42,582,367 | +562,733 |
wc -l | 42,606,918 | 43,179,595 | +572,677 |
The results show remarkable agreement across all three measurement methods. Both tokei and scc report that Linux gained approximately 563,000 language-aware lines between Linux 7.1 and 7.2-rc1, representing roughly 1.3% growth during a single development cycle. A raw wc -l count shows a similarly sized increase of 572,677 lines.
That sounds dramatic, but it is entirely expected. Every Linux kernel release adds support for new processors, platforms, filesystems, drivers, virtualization technologies, and security improvements while continuing to refine existing subsystems.
As per the Linux 7.1 final release notes, more than 2,000 developers contributed changes, including over 300 first-time contributors. Sustained contributions on that scale naturally translate into steady growth of the source tree over time.
Linux Keeps Growing Even After Removing Old Code
One surprising aspect of this milestone is that Linux kernel code continues to grow even while removing legacy code.
Linux 7.1 began dropping support for Intel's i486 processors, removing more than 140,000 lines of obsolete code, including legacy PCMCIA host controllers and ISDN drivers. Linux 7.2 continues that cleanup by removing additional i486-related code along with several obsolete drivers and legacy x86 components.
In other words, Linux developers are continuously balancing additions with removals. While new hardware support, architectures, drivers, filesystems, and security features expand the kernel, obsolete code is regularly retired to reduce maintenance burden and keep the project modern.
Why Is the Linux Kernel So Large?
The answer is drivers.
The Linux kernel supports an incredible variety of hardware. Every graphics card, storage controller, network adapter, laptop feature, USB device, and embedded platform needs kernel support.
As new hardware reaches the market, developers add new drivers. At the same time, they maintain compatibility with existing devices. Because of this, most of the kernel's growth comes from hardware support. Very little growth comes from the kernel's core scheduling or memory-management code.
AMDGPU Remains the Largest Driver
The biggest contributor is still the AMD graphics subsystem.
The combined AMDGPU and AMDKFD driver contains approximately 6.35 million lines of code. This makes it the largest driver in the entire Linux kernel.
Linus Torvalds has pointed out something interesting. Roughly one-third of one large pull request consisted of AMD GPU register definition files. These files are mostly generated data. They help Linux communicate with modern AMD graphics hardware.
Bigger Doesn't Mean Slower
Many people assume that more lines of code means slower software. That is not how the Linux kernel works.
Most of the extra code exists to support hardware that many users will never own. Much of it lives in loadable modules. These modules only activate when the matching hardware is present.
As a result, the kernel keeps improving while expanding hardware compatibility. This applies across desktops, servers, laptops, embedded systems, cloud platforms, and supercomputers.
Count the Total Number of Lines in Linux Kernel Code
Anyone can clone the Linux kernel repository and measure it. First, get the kernel source code:
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux
A full clone is about 5 GB. You can add --depth=1 to the git command for a shallow clone instead (about 1.5 GB):
git clone --depth=1 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
For this guide, I used a full clone.
Method 1: cloc (the widely cited reference tool)
cloc is the most commonly used tool for kernel line counts.
# Install
sudo apt install cloc # Debian/Ubuntu
sudo dnf install cloc # Fedora/RHEL
sudo pacman -S cloc # Arch
Now, run:
cloc --progress=1 .
Note the dot (.) at the end. Meaning - we instruct the cloc to analyze the current directory.
Depending on your hardware, cloc may take several minutes to scan the full Linux source tree. On my Fedora VM it completed in about 3–4 minutes.
Sample Output:
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
----------------------------------------------------------------------------------------
Note: cloc does not recognize Device Tree source files (.dts/.dtsi). This is part of why it undercounts the kernel (see the breakdown earlier in this guide).
To measure only the AMD graphics driver, run:
cloc drivers/gpu/drm/amd
Method 2: tokei (faster and more accurate, recommended)
tokei is significantly faster than cloc. It also correctly counts Device Tree files. This makes it a more accurate choice for the Linux kernel.
First, make sure Rust is installed in your system. And then, install tokei using cargo package manager:
cargo install tokei
tokei is also available in some distribution's official repositories, so you can install it using the default package manager like below:
sudo apt install tokei
brew install tokei
Now, run:
tokei .
Sample Output:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
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
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
It finishes in under a minute and matches scc results closely (See the next section).
Method 3: scc (fastest, with complexity metrics)
scc matches tokei's accuracy. It also reports cyclomatic complexity per language. This is useful for understanding which parts of the kernel are hardest to maintain.
Make sure Golang is installed in your system and then run the following command to install scc:
go install github.com/boyter/scc/v3@latest
Now, run:
scc .
Sample Output:
───────────────────────────────────────────────────────────────────────────────
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)
───────────────────────────────────────────────────────────────────────────────
On the v7.2-rc1 tree, scc also estimates the cost to rebuild the kernel from scratch. The estimate is about $1.47 billion, using the COCOMO organic model. You can see this detail nearly at the end of the output.
Method 4: wc -l (quick all-files sanity check)
The wc command counts every line in every file, regardless of type. This includes binary and non-text files. It produces the highest number of all four tools.
find . -not -path './.git/*' -type f \
| xargs wc -l 2>/dev/null \
| awk '/total/{sum += $1} END{print sum}'
Sample Output:
43179595
Please note that wc is not a language-aware code counter. But it provides a useful upper bound for the total number of lines stored in the Git tree.
Note: Do not add | tail -1 at the end. When there are tens of thousands of files, xargs splits them into multiple batches. Each batch prints its own total line. Using tail -1 only captures the last batch's subtotal. This produces a badly wrong result.
Tool comparison
| Tool | Speed | Language-aware | Notes |
|---|---|---|---|
wc -l | Fastest | ❌ | Counts all files, including binaries |
tokei | Very fast | ✅ | Best balance of speed and accuracy |
scc | Fast | ✅ | Also reports cyclomatic complexity |
cloc | Slow (15–30 min) | ✅ | Undercounts the kernel; doesn't recognize Device Tree files |
Linux 7.2 Code Statistics Summary
Measured on commit dc59e4fea9d8 (tag: v7.2-rc1), June 30, 2026:
| Statistic | Value |
|---|---|
Total lines, all files (wc -l) | 43,179,595 |
| Total lines, source-aware (tokei/scc) | ~42,583,000 |
| Source code lines | ~32,400,000 |
| Comment lines | ~4,850,000 |
| Blank lines | ~5,327,000 |
Difference between wc -l and tokei/scc | ~597,000 lines (non-source files and files classified differently by language-aware tools) |
| Largest driver | AMDGPU + AMDKFD |
| AMD graphics driver | ~6.35 million lines |
| Major source of growth | Device drivers |
| Legacy cleanup | Continued removal of Intel i486 code and obsolete drivers |
| Estimated dev cost | ~$1.47 billion (COCOMO, via scc) |
Conclusion
Crossing 42 million lines is more than a fun statistic. It reflects the scale of one of the world's largest collaborative software projects.
Linux kernel maintainers keep adding support for new hardware. At the same time, they remove code for platforms that have reached the end of their useful life. The result is a kernel that grows where it needs to and becomes cleaner where it can.
For Linux enthusiasts, this milestone is another reminder of how fast kernel development moves. It also shows how much work goes into supporting everything from tiny embedded boards to the world's fastest supercomputers.
Source:
