|
|
Log in / Subscribe / Register

Development statistics for 6.19

By Jonathan Corbet
February 9, 2026
Linus Torvalds released the 6.19 kernel on February 8, as expected. This development cycle brought 14,344 non-merge changesets into the mainline, making it the busiest release since 6.16 in July 2025. As usual, we have put together a set of statistics on where these changes come from, along with a quick look at how long new kernel developers stay around.

As a reminder: LWN subscribers can find much of the information below — and more — at any time in the LWN kernel source database.

The 6.19 development cycle brought in the work from 2,141 developers, which just barely beats the previous record (2,134) set for 6.18; 333 of those developers made their first contribution to the kernel in 6.19, also a relatively high number. The most active developers for 6.19 were:

Most active 6.19 developers
By changesets
Kuninori Morimoto 4593.2%
Christian Brauner 2711.9%
Johan Hovold 1581.1%
Ville Syrjälä 1531.1%
Ian Rogers 1401.0%
Russell King 1240.9%
Josh Poimboeuf 1010.7%
Andy Shevchenko 1000.7%
Krzysztof Kozlowski 930.6%
Jani Nikula 910.6%
Sean Christopherson 880.6%
Filipe Manana 870.6%
Marco Crivellari 870.6%
Christoph Hellwig 860.6%
Thomas Zimmermann 850.6%
Eric Dumazet 850.6%
Peter Zijlstra820.6%
Marc Zyngier 820.6%
Frank Li 780.5%
SeongJae Park 780.5%
By changed lines
Miguel Ojeda 580007.8%
Cyril Chao 197552.6%
Christian Brauner 166042.2%
YiPeng Chai 132931.8%
Dmitry Baryshkov 122441.6%
Ian Rogers 109331.5%
Jason Gunthorpe 108511.5%
Eric Biggers 95491.3%
Daniel Scally 94291.3%
AngeloGioacchino Del Regno 62010.8%
Josh Poimboeuf 60100.8%
Ilya Bakoulin 60090.8%
Rob Herring57770.8%
Johannes Berg 57070.8%
Svyatoslav Ryhel 56100.8%
Akhil P Oommen 55160.7%
Mauro Carvalho Chehab 51960.7%
Neilay Kharwadkar 51620.7%
Igor Belwon 51550.7%
Lorenzo Stoakes 48300.6%

Kuninori Morimoto, who was first seen during the 2.6.28 development cycle in 2008, was the biggest contributor of changesets by virtue of a major refactoring effort in the sound subsystem. Christian Brauner, the maintainer of the virtual filesystem layer, refactored the handling of credentials, added the listns() system call, and added many self tests, among other contributions. Johan Hovold fixed numerous bugs and did a lot of cleanups in various driver subsystems. Ville Syrjälä worked extensively in the i915 graphics-driver subsystem, and Ian Rogers contributed a long list of improvements to the perf tool.

Looking at lines changed, Miguel Ojeda topped the list with the addition of a modified version of the Rust syn crate. Cyril Chao's first-ever kernel contribution, which put him into second place in the "lines-changed" list, was a driver for MediaTek mt8189 platform devices. YiPeng Chai worked with the amdgpu graphics driver, and Dmitry Baryshkov updated devicetree files for a number of Qualcomm devices.

A full 10% of the patches merged for 6.19 had Tested-by tags, while 56% had Reviewed-by tags; both of those numbers are slightly higher than usual. The top testers and reviews for this release were:

Test and review credits in 6.19
Tested-by
Dan Wheeler 894.8%
Joe Lawrence 633.4%
Mark Brown 553.0%
Randy Dunlap 532.9%
Fuad Tabba 532.9%
Lad Prabhakar 372.0%
Shaopeng Tan 351.9%
James Clark 341.8%
Carl Worth 341.8%
Hanjun Guo 331.8%
Gavin Shan 321.7%
Zeng Heng 321.7%
Ryan Walklin 301.6%
Kai Huang 291.6%
Fenghua Yu 281.5%
Yan Zhao 281.5%
Reviewed-by
Charles Keepax 3102.8%
Dmitry Baryshkov 1911.7%
Geert Uytterhoeven 1641.5%
Frank Li 1581.4%
Krzysztof Kozlowski 1561.4%
David Sterba 1441.3%
Christoph Hellwig 1391.3%
Konrad Dybcio 1251.1%
Simon Horman 1251.1%
Ilpo Järvinen 1181.1%
Jan Kara 1181.1%
Jeff Layton 1131.0%
AngeloGioacchino Del Regno 1111.0%
Jonathan Cameron 1091.0%
Andrew Lunn 1091.0%
Ville Syrjälä 1051.0%

The list of top reviewers is a bit different than in the past; somehow Charles Keepax managed to review 310 commits — more than four for every day of this 70-day release cycle — mostly within the sound-driver subsystem. The other top reviewers were focused on system-on-chip drivers and devicetree-related changes. The list of top testers is more typical, with Daniel Wheeler on top as usual.

The development of the 6.19 kernel was supported by 227 employers that we know of. The most active employers were:

Most active 6.19 employers
By changesets
Intel159111.1%
(Unknown)14109.8%
Google10997.7%
Red Hat8295.8%
Renesas Electronics7415.2%
AMD6124.3%
(None)5543.9%
Qualcomm4853.4%
SUSE4623.2%
Microsoft4343.0%
NVIDIA4072.8%
(Consultant)3922.7%
Meta3792.6%
Oracle3712.6%
NXP Semiconductors3252.3%
Linaro3192.2%
Huawei Technologies2601.8%
IBM2361.6%
Arm2001.4%
Bootlin1601.1%
By lines changed
Google10172813.6%
(Unknown)701259.4%
Intel599348.0%
AMD450256.0%
Qualcomm363224.9%
NVIDIA325854.4%
Red Hat314294.2%
Microsoft306214.1%
(None)272853.7%
MediaTek232233.1%
Ideas on Board148802.0%
Renesas Electronics143501.9%
Meta142321.9%
Collabora140881.9%
Huawei Technologies132571.8%
SUSE132091.8%
Oracle129431.7%
Arm127611.7%
IBM122301.6%
Linaro90151.2%

These numbers are reasonably consistent with recent history; hardware vendors are still contributing a large share of the changes. When considering which companies are most influential in kernel development, though, one should also look at the Signed-off-by tags added to patches by maintainers as they apply those patches to their repositories:

Non-author signoffs in 6.19
Individual
Jakub Kicinski 9917.5%
Mark Brown 9467.2%
Andrew Morton5844.4%
Alex Deucher 4783.6%
Greg Kroah-Hartman 4063.1%
Jens Axboe 2772.1%
Hans Verkuil 2572.0%
Bjorn Andersson 2451.9%
Paolo Abeni 2181.7%
Christian Brauner 2001.5%
Namhyung Kim 1961.5%
Shawn Guo 1851.4%
Martin K. Petersen 1841.4%
Peter Zijlstra 1841.4%
David Sterba 1791.4%
Jonathan Cameron 1671.3%
Alexei Starovoitov 1411.1%
Geert Uytterhoeven 1291.0%
Jonathan Corbet 1210.9%
Ilpo Järvinen 1210.9%
By employer
Meta154411.8%
Google12969.9%
Intel12439.5%
Arm11718.9%
AMD8486.5%
Linaro7866.0%
Red Hat6474.9%
Qualcomm5644.3%
Linux Foundation4413.4%
Microsoft4323.3%
SUSE4233.2%
(Unknown)4093.1%
NVIDIA3122.4%
Cisco2572.0%
Oracle2351.8%
Huawei Technologies2331.8%
(None)2091.6%
LG Electronics1961.5%
Renesas Electronics1741.3%
IBM1331.0%

The top two companies here are both of the hyperscaler variety, with the top being Meta, which appears rather farther down in the list of changeset contributors. While Meta does contribute a lot of patches — and significant core patches at that — it also employs the maintainers that handle a lot more patches authored by others. Arm, too, shows a bigger influence by this metric.

Developer longevity

For as long as the kernel community has existed, people have worried about its ability to attract new developers. I have often pointed out that each release features the work of roughly 300 first-time developers; the response is often to ask how long those developers stay around. The time has come to try to give at least a partial answer to that question. The plot below was generated by accumulating a list of the 5,424 developers who made their first contribution to one of the 5.x mainline kernels, then looking at how many other releases each contributed to.

[longevity plot]

What we see is that 1,943 of those first-time contributors — 36% of the total — were never seen again after contributing to one release. Another 883 developers (16%) showed up for one other release, and so on. In the end, 32% of the first-time contributors during this period have been present for at least four kernel releases. At the long tail of the distribution, there are two first-time developers (Andrii Nakryiko and Vladimir Oltean) who have only missed one release and two (Stephan Gerhold and Stefano Garzarella) who have contributed to every release from 5.0 to 6.19.

To provide one other small data point: the first-time contributors being studied here arrived between early 2019 (the 5.0 release) and mid-2022 (5.19). Of those 5,424 developers, 1,067 (just under 20%) of them contributed to at least one of the releases made in 2025. It seems reasonable to consider that group as still being active in the kernel community. Whether these results are good or bad is probably a matter for debate, but it does seem clear that, while a lot of contributors pass through quickly, others are staying around for the long haul.

The kernel community as a whole is also clearly here for the long haul; the process shows no real signs of slowing down. As of this writing, there are just short of 11,000 changesets in the linux-next repository; most of those will move into the mainline in the upcoming merge window. The next kernel, which will be called 7.0, will continue to demonstrate the community's fast pace; stay tuned for the details.

Index entries for this article
KernelReleases/6.19


to post comments

Lines by C vs Rust

Posted Feb 9, 2026 18:52 UTC (Mon) by jhoblitt (subscriber, #77733) [Link] (17 responses)

It would be interesting to see the delta of lines further broken out as C or Rust. I realize that's tricky as there's data, Makfiles, Kconfig, etc. that aren't either language. What I'm interested in seeing is if the ratio between C & Rust changes over time.

Lines by C vs Rust

Posted Feb 9, 2026 20:33 UTC (Mon) by tux3 (subscriber, #101245) [Link] (3 responses)

I checked the last few tags with Tokei:
Version     Rust      Rust%     C              GNU ASM   Total
6.16        26999     0.08%     35518738       373967    35919704
6.17        32699     0.09%     35682999       373801    36089499
6.18        49466     0.14%     35825868       374814    36250148
6.19        108478    0.30%     36134877       376296    36619651
Naturally whenever you have four numbers, this calls for an exponential regression.
We can confidently extrapolate that by v7.5 we will already see 5% of the kernel written in Rust.
7.10 will finally be majority Rust, while the decisive 7.11 merge window will remove the remaining ~15M lines of C all at once to reach a perfect 113% of Rust code in the kernel.

Lines by C vs Rust

Posted Feb 12, 2026 17:42 UTC (Thu) by jmalcolm (subscriber, #8876) [Link] (2 responses)

I realize that your regression is in jest but it is interesting to contemplate.

Of course, Rust is not really used in the real kernel just yet as it is all support code and a few drivers. I think your regression could pan out on the driver side.

But we have not yet seen the pace of adoption once we actually get into the core kernel. And, though I look forward to the benefits of Rust, using it in areas that will cause the kernel to stop building on niche architectures is a big deal.

I also love me some LLVM and Clang and pretty much only run architectures that they support. But the ability to compile Rust code in GCC is going to be a gate for adoption of Rust in Linux I would think. Thankfully, gccrs has it as a goal for this year to compile the Linux kernel and LWN has it as one of their 2026 predictions.

https://lwn.net/Articles/1052269/

Rust in the core of Linux in 2027 seems like a real possibility and it will be VERY interesting to see how fast it takes off once it is in there.

After all this arguing, it could be faster than we think.

Lines by C vs Rust

Posted Feb 13, 2026 14:14 UTC (Fri) by ojeda (subscriber, #143370) [Link] (1 responses)

> Of course, Rust is not really used in the real kernel just yet as it is all support code and a few drivers.

Considering Linux's design, it very much is "real kernel" code, which was one of the main reasons Rust for Linux happened. Not to mention things like Binder, which is as critical as you can get for the systems that use it (functionality-, security- and performance-wise).

I suspect you may be referring to (currently) non-loadable, non-configurable features. The limitation for those, as you say, is the toolchain support, but if the relevant maintainers were to deem maintaining a duplicate implementation worth it, then it could technically be done today.

> Thankfully, gccrs has it as a goal for this year to compile the Linux kernel and LWN has it as one of their 2026 predictions.

There is another way as well, `rustc_codegen_gcc`, which already back in Kangrejos 2022 managed to build the kernel. It is still not production ready, but it does boot a x86_64 kernel with Rust code running on it.

Having said that, even if either GCC Rust or `rustc_codegen_gcc` become ready this year (even for several architectures), we will likely want to wait until the packages are in some distributions and so on.

But, yes, if they at least become ready for a major architecture, which is our hope for this year or the next, then that is a very strong signal, and it could easily mean that more maintainers decide to use Rust for their next feature, or perhaps even to maintain parallel implementations.

Lines by C vs Rust

Posted Feb 16, 2026 10:17 UTC (Mon) by taladar (subscriber, #68407) [Link]

I am not a kernel developer but if you told me I had to work in a language I don't prefer for a few more years for the benefit of a bunch of hobbyists trying to keep architectures alive that are out of production for 20+ years I would probably either stop working in the project entirely (or not start working in it) or ignore that statement and just work in my preferred language anyway.

Lines by C vs Rust

Posted Feb 9, 2026 21:23 UTC (Mon) by daroc (editor, #160859) [Link] (12 responses)

That is an interesting question!

The 6.19 release had 19,222,910 non-blank non-comment lines of C, and 89,286 of Rust. That's a ratio of ~215. In 6.18, that was 19,041,645 to 36,077 for a ratio of ~528. So C added ~181,000 lines and Rust added ~53,000 lines.

Most of that would have been the addition of the syn crate, as Jon noted in the article. That crate being vendored in the kernel source code represents the adoption of a big chunk of pre-written code from the Rust ecosystem, and not really normal development activity.

Going back to 6.17, there were 18,951,316 lines of C and 23,163 lines of Rust, for a ratio of ~818. Which was higher than I was expecting, actually. Now you've got me curious about the historical trend as well. I'm going to see about writing up a script to scrape some numbers into a spreadsheet ...

(Also: Rust is the 7th most popular language in the kernel right now, after C, header files, assembly, JSON, reStructuredText, YAML, shell, and plain text. It edged ahead of Python, make, SVGs, and Perl in this last release!)

Lines by C vs Rust

Posted Feb 9, 2026 22:24 UTC (Mon) by jhoblitt (subscriber, #77733) [Link] (4 responses)

That is actually more rust than I would have expected (even excluding vendored crates). Another interesting angle would be to try to normalize based on the expected LOC density ratio between C and rust. My expectation is that general purpose rust would have fewer SLOC than the equivalent C but I suspect the ratio would be different for kernel vs userland code. I went looking for a formal code density study comparing the two languages and found this paper from 2021: https://pmc.ncbi.nlm.nih.gov/articles/PMC7959618/

Lines by C vs Rust

Posted Feb 9, 2026 22:45 UTC (Mon) by koverstreet (✭ supporter ✭, #4296) [Link] (3 responses)

My experience so far is that LOC density varies quite a bit; generics, good standard library containers, iterators etc. all mean that frequently the Rust version will be half the size of the C version, or even less. OTOH, when you're doing lots of FFI and/or type conversions (e.g. plumbing code), the Rust version can end up being more verbose than what it was replacing, at least without substantial work - a lot of that because Rust is pretty effective enforcing correct error handling.

Lines by C vs Rust

Posted Feb 10, 2026 19:23 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (2 responses)

On top of that, the fact that the Rust-for-Linux folks decided to vendor syn rather strongly implies they are making significant use of proc macros (syn is mostly if not solely used for implementing proc macros). That probably cuts down on the line count by quite a lot, since Rust proc macros are a great deal more expressive than C preprocessor macros.

Lines by C vs Rust

Posted Feb 11, 2026 7:23 UTC (Wed) by taladar (subscriber, #68407) [Link] (1 responses)

Might be interesting to have a graph of post macro-expansion C and Rust code numbers too.

I suspect having a culture of using derive macros for many common tasks also helps keep the line count low in Rust.

Lines by C vs Rust

Posted Feb 11, 2026 15:31 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

C macros expand to a single line, so you'd need to filter through a formatter first. You might also want to trim dead derive code from Rust as well…lots of tedious error handling going on there when I've looked (e.g., `Deserialize`).

Lines by C vs Rust

Posted Feb 9, 2026 23:41 UTC (Mon) by ojeda (subscriber, #143370) [Link] (1 responses)

For the last LPC talk, I got some simple numbers with and without `syn` (and in the past with and without `alloc`), plotted them and added an exponential trendline for fun -- slides 21 to 28:

https://lpc.events/event/19/contributions/2068/attachment...

Nothing fancy, but one summary is that the Rust code more than quadrupled in a year (and that is without counting vendored code).

Lines by C vs Rust

Posted Feb 10, 2026 0:07 UTC (Tue) by jhoblitt (subscriber, #77733) [Link]

That is an astonishing rate of growth. Actually, it isn't just the exponential curve that's impressive but the total LOC in tree as well. I often see mention of rust code that can't be upstreamed yet because of missing plumbing -- which gave me the impression that the rate of ingress had been fairly slow. This thread makes it sound like ~10% of new code in a release is now rust -- that's mind blowing.

Lines by C vs Rust

Posted Feb 10, 2026 13:01 UTC (Tue) by daroc (editor, #160859) [Link] (4 responses)

So I wrote a script to crunch the numbers, and put together a set of graphs showing the change in lines of code by language over time. The charts are not as clean as the Rust-only visualizations that Miguel linked, but they show every language that cloc knows how to detect.

Lines by C vs Rust

Posted Feb 10, 2026 19:27 UTC (Tue) by jhoblitt (subscriber, #77733) [Link] (1 responses)

Neat! Perhaps the making the y-axis of the total line count plot log scale would help separate out some of the lines?

Is the key listing every type of code detected or every type of code supported? If the former... is there really Clojure in tree???

Lines by C vs Rust

Posted Feb 10, 2026 20:24 UTC (Tue) by daroc (editor, #160859) [Link]

That's what the second graph is: a log scale. It doesn't help much because there are so many programming languages detected that only have a handful of lines of code. And no, there isn't actually clojure in the kernel — it looks like cloc is mis-identifying some custom configuration files in the rcutorture tests.

Lines by C vs Rust

Posted Feb 10, 2026 22:27 UTC (Tue) by Klaasjan (subscriber, #4951) [Link] (1 responses)

Is it me, or is the Perl legend missing the symbol (x) ?

Lines by C vs Rust

Posted Feb 10, 2026 22:31 UTC (Tue) by Klaasjan (subscriber, #4951) [Link]

Replying to myself (sorry about that). No that is the data for Text.

My second kernel patch was in here!

Posted Feb 10, 2026 3:52 UTC (Tue) by vasi (subscriber, #83946) [Link] (1 responses)

Proud to contribute to employer: Unknown

My second kernel patch was in here!

Posted Feb 10, 2026 6:29 UTC (Tue) by hrw (subscriber, #44826) [Link]

Sooner or later you will get an email asking how to count you. Company or individual.

So, check your inbox and spam.


Copyright © 2026, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds