O kernel Linux atingiu um novo marco importante. A árvore de desenvolvimento mais recente do Linux 7.2 contém aproximadamente 43.2 milhões de total linhas em todos os arquivos rastreados, ou cerca de 42.6 milhões de linhas reconhecidas por linguagem de acordo com as ferramentas tokei e scc.
Verificamos esses números de forma independente na tag oficial v7.2-rc1 usando 4 ferramentas diferentes de contagem de código. Com base em nossas medições, esta é a maior árvore de código-fonte do kernel Linux até o momento.
À primeira vista, esse número pode parecer enorme. Mas isso não significa que o Linux tenha se tornado inchado. Em vez disso, mostra duas coisas: o quanto de hardware o Linux suporta hoje e o quão ativamente o kernel continua a evoluir.
Vamos ver o que mudou.
Linux 7.2 ultrapassa a marca de 42 milhões de linhas
Eu medi a árvore Git do Linux 7.2-rc1 usando múltiplas ferramentas de contagem de código. Para fins de demonstração, usei o commit exato da tag 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
Aqui está o que cada ferramenta encontrou:
Eu executei todas as quatro ferramentas na mesma sessão de uma VM Fedora contra o mesmo checkout do Git (dc59e4fea9d8) usando versões idênticas das ferramentas. Isso torna os resultados diretamente comparáveis e reproduzíveis.
Um teste anterior com cloc v1.96 produziu uma contagem total quase idêntica de 40,414,638 linhas. A pequena diferença vem de melhorias no cloc v2.08, que reconhece alguns formatos de arquivo adicionais, como Jinja Template e Snakemake.
Tokei e scc concordam quase perfeitamente, ambos relatando cerca de 42.58 milhões de total linhas. Seus resultados independentes diferem por apenas 2,159 linhas (cerca de 0.005%), tornando-os as medições mais consistentes com reconhecimento de linguagem da árvore de código-fonte do Linux.
Em comparação, a execução padrão do cloc subestima o kernel em aproximadamente 2.17 milhões de linhas porque ele não reconhece arquivos-fonte de Device Tree do Linux (.dts/.dtsi) por padrão. Verifiquei isso executando novamente o cloc com:
cloc --force-lang="C",dts --force-lang="C",dtsi .
Isso aumentou as contagens total do cloc em aproximadamente 2.1 milhões de linhas, trazendo seus resultados para uma concordância próxima com tokei e scc.
Reproduzi o mesmo comportamento tanto no Linux 7.1 quanto no 7.2-rc1, confirmando que a discrepância vem do reconhecimento de linguagem padrão do cloc e não de uma mudança no próprio kernel.
Como o título "43 milhões" é derivado
Uma contagem bruta com wc -l em todos os arquivos rastreados no repositório produz 43,179,595 linhas. É daí que vem o título "43 milhões de linhas".
Há uma diferença de aproximadamente 597,000 linhas entre esse número e as contagens total relatadas por tokei e scc. Essa diferença existe porque o wc -l conta todas as linhas em todos os arquivos rastreados, enquanto as ferramentas com reconhecimento de linguagem intencionalmente excluem ou classificam muitos arquivos não-fonte de forma diferente. Exemplos incluem documentação, metadados, imagens, certificados e outros formatos não-fonte ou não reconhecidos em todo o repositório.
Vale notar que um checkout Git limpo do kernel Linux não contém binários .dtb compilados e nenhum diretório firmware/ (os blobs de firmware são mantidos separadamente no repositório linux-firmware). Portanto, esses arquivos não contribuem para essa diferença.
Em resumo, o título de 43 milhões é tecnicamente preciso porque reflete todas as linhas armazenadas na árvore Git. No entanto, o número de 42.58 milhões relatado por tokei e scc é a medição mais precisa do código-fonte do kernel.
Linux 7.2 continua o crescimento do kernel
Para medir o quanto o kernel cresceu durante este ciclo de desenvolvimento, repeti as mesmas medições no lançamento final do Linux 7.1 usando a mesma VM Fedora, versões das ferramentas e metodologia.
Os resultados mostram uma concordância notável entre todos os três métodos de medição. Tanto tokei quanto scc relatam que o Linux ganhou aproximadamente 563,000 linhas com reconhecimento de linguagem entre o Linux 7.1 e o 7.2-rc1, representando cerca de 1.3% de crescimento durante um único ciclo de desenvolvimento. Uma contagem bruta com wc -l mostra um aumento de tamanho similar de 572,677 linhas.
Isso parece dramático, mas é totalmente esperado. Cada lançamento do kernel Linux adiciona suporte para novos processadores, plataformas, sistemas de arquivos, drivers, tecnologias de virtualização e melhorias de segurança, enquanto continua refinando subsistemas existentes.
De acordo com as notas de lançamento finais do Linux 7.1, mais de 2,000 desenvolvedores contribuíram com mudanças, incluindo mais de 300 contribuidores de primeira viagem. Contribuições sustentadas nessa escala naturalmente se traduzem em um crescimento constante da árvore de código-fonte ao longo do tempo.
Linux continua crescendo mesmo após remover código antigo
Um aspecto surpreendente deste marco é que o código do kernel Linux continua a crescer mesmo enquanto remove código legado.
Linux 7.1 começou a abandonar o suporte para processadores i486 da Intel, removendo mais de 140,000 linhas de código obsoleto, incluindo controladores PCMCIA legados e drivers ISDN. Linux 7.2 continua essa limpeza removendo código adicional relacionado a i486 junto com vários drivers obsoletos e componentes x86 legados.
Em outras palavras, os desenvolvedores do Linux estão continuamente equilibrando adições com remoções. Enquanto novo suporte a hardware, arquiteturas, drivers, sistemas de arquivos e recursos de segurança expandem o kernel, o código obsoleto é regularmente aposentado para reduzir a carga de manutenção e manter o projeto moderno.
Por que o kernel Linux é tão grande?
A resposta são os drivers.
O kernel Linux suporta uma variedade incrível de hardware. Cada placa de vídeo, controladora de armazenamento, adaptador de rede, recurso de laptop, dispositivo USB e plataforma embarcada precisa de suporte do kernel.
À medida que novo hardware chega ao mercado, os desenvolvedores adicionam novos drivers. Ao mesmo tempo, eles mantêm a compatibilidade com dispositivos existentes. Por causa disso, a maior parte do crescimento do kernel vem do suporte a hardware. Muito pouco crescimento vem do código central de agendamento ou gerenciamento de memória do kernel.
AMDGPU continua sendo o maior driver
O maior contribuinte ainda é o subsistema gráfico da AMD.
O driver combinado AMDGPU e AMDKFD contém aproximadamente 6.35 milhões de linhas de código. Isso o torna o maior driver em todo o kernel Linux.
Linus Torvalds apontou algo interessante. Cerca de um terço de um grande pull request consistia em arquivos de definição de registradores da GPU AMD. Esses arquivos são, em sua maioria, dados gerados. Eles ajudam o Linux a se comunicar com hardware gráfico moderno da AMD.
Maior não significa mais lento
Muitas pessoas assumem que mais linhas de código significam software mais lento. Não é assim que o kernel Linux funciona.
A maior parte do código extra existe para suportar hardware que muitos usuários nunca terão. Grande parte dele vive em módulos carregáveis. Esses módulos só são ativados quando o hardware correspondente está presente.
Como resultado, o kernel continua melhorando enquanto expande a compatibilidade de hardware. Isso se aplica a desktops, servidores, laptops, sistemas embarcados, plataformas em nuvem e supercomputadores.
Conte o número total de linhas no código do kernel Linux
Qualquer um pode clonar o repositório do kernel Linux e medi-lo. Primeiro, obtenha o código-fonte do kernel:
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux
Um clone completo tem cerca de 5 GB. Você pode adicionar --depth=1 ao comando git para um clone raso (cerca de 1.5 GB):
git clone --depth=1 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Para este guia, usei um clone completo.
Método 1: cloc (a ferramenta de referência amplamente citada)
cloc é a ferramenta mais comumente usada para contagens de linhas do kernel.
# Install
sudo apt install cloc # Debian/Ubuntu
sudo dnf install cloc # Fedora/RHEL
sudo pacman -S cloc # Arch
Agora, execute:
cloc --progress=1 .
Observe o ponto (.) no final. Significa que estamos instruindo o cloc a analisar o diretório atual.
Dependendo do seu hardware, o cloc pode levar vários minutos para escanear toda a árvore de código-fonte do Linux. Na minha VM Fedora, ele completou em cerca de 3–4 minutos.
Exemplo de saída:
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
----------------------------------------------------------------------------------------
Nota: O cloc não reconhece arquivos-fonte de Device Tree (.dts/.dtsi). Isso é parte do motivo pelo qual ele subestima o kernel (veja a análise no início deste guia).
Para medir apenas o driver gráfico da AMD, execute:
cloc drivers/gpu/drm/amd
Método 2: tokei (mais rápido e mais preciso, recomendado)
tokei é significativamente mais rápido que o cloc. Ele também conta corretamente os arquivos Device Tree. Isso o torna uma escolha mais precisa para o kernel Linux.
Primeiro, certifique-se de que o Rust está instalado no seu sistema. E então, instale o tokei usando o gerenciador de pacotes cargo:
cargo install tokei
O tokei também está disponível nos repositórios oficiais de algumas distribuições, então você pode instalá-lo usando o gerenciador de pacotes padrão como abaixo:
sudo apt install tokei
brew install tokei
Agora, execute:
tokei .
Exemplo de saída:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
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
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Ele termina em menos de um minuto e corresponde de perto aos resultados do scc (veja a próxima seção).
Método 3: scc (mais rápido, com métricas de complexidade)
scc corresponde à precisão do tokei. Ele também relata a complexidade ciclomática por linguagem. Isso é útil para entender quais partes do kernel são mais difíceis de manter.
Certifique-se de que o Golang está instalado no seu sistema e então execute o seguinte comando para instalar o scc:
go install github.com/boyter/scc/v3@latest
Agora, execute:
scc .
Exemplo de saída:
───────────────────────────────────────────────────────────────────────────────
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)
───────────────────────────────────────────────────────────────────────────────
Na árvore v7.2-rc1, o scc também estima o custo para reconstruir o kernel do zero. A estimativa é de cerca de $1.47 bilhões, usando o modelo orgânico COCOMO. Você pode ver esse detalhe quase no final da saída.
Método 4: wc -l (verificação rápida de sanidade em todos os arquivos)
O comando wc conta todas as linhas em todos os arquivos, independentemente do tipo. Isso inclui arquivos binários e não-texto. Ele produz o maior número de todas as quatro ferramentas.
find . -not -path './.git/*' -type f \
| xargs wc -l 2>/dev/null \
| awk '/total/{sum += $1} END{print sum}'
Exemplo de saída:
43179595
Por favor, note que wc não é um contador de código com reconhecimento de linguagem. Mas ele fornece um limite superior útil para o número total de linhas armazenadas na árvore Git.
Nota: Não adicione | tail -1 no final. Quando há dezenas de milhares de arquivos, o xargs os divide em vários lotes. Cada lote imprime sua própria linha de total. Usar tail -1 captura apenas o subtotal do último lote. Isso produz um resultado gravemente errado.
Linux 7.2 Resumo das estatísticas de código
Medido no commit dc59e4fea9d8 (tag: v7.2-rc1), junho de 30, 2026:
Ultrapassar 42 milhões de linhas é mais do que uma estatística divertida. Isso reflete a escala de um dos maiores projetos de software colaborativo do mundo.
Os mantenedores do kernel Linux continuam adicionando suporte para novo hardware. Ao mesmo tempo, eles removem código para plataformas que chegaram ao fim de sua vida útil. O resultado é um kernel que cresce onde precisa e se torna mais limpo onde pode.
Para entusiastas do Linux, este marco é outro lembrete de quão rápido o desenvolvimento do kernel se move. Também mostra quanto trabalho é necessário para suportar tudo, desde pequenas placas embarcadas até os supercomputadores mais rápidos do mundo.
Fonte:
