Some 4.5 Development statistics

When Linus released the 4.5-rc7 prepatch, he indicated that it would probably be the last one prior to the official 4.5 release. That means we're running a bit late for the traditional article full of statistics for this development cycle. So, without further ado, here is a look at the changes that came in during the 4.5 cycle and where they came from.

As of this writing, just over 12,000 non-merge changesets have landed in the mainline repository for 4.5. That makes 4.5 one of the quieter development cycles in the last year; less than 4.2 and 4.4 (both over 13,000 changesets) but approximately equal to 4.1 and 4.3. All things are relative, of course; not that long ago, 12,000 changes would have been one of the busiest cycles. Even when the kernel community slows down a bit, there is a lot going on.

These changes were contributed by 1,528 developers — short of the 1,575 seen in 4.4 or the 1,625 in 4.3, but, once again, a fair crowd of contributors. The most active of these developers were:

Most active 4.5 developers

By changesets Linus Walleij 236 2.0% Arnd Bergmann 226 1.9% Leo Kim 210 1.7% Mauro Carvalho Chehab 169 1.4% Geert Uytterhoeven 159 1.3% Ville Syrjälä 126 1.0% Kuninori Morimoto 112 0.9% Takashi Iwai 108 0.9% Jiri Olsa 104 0.9% Christoph Hellwig 102 0.8% Julia Lawall 101 0.8% Glen Lee 101 0.8% Javier Martinez Canillas 89 0.7% Geliang Tang 89 0.7% Dan Carpenter 85 0.7% Daniel Vetter 81 0.7% Boris Brezillon 80 0.7% Alex Deucher 80 0.7% Kirill A. Shutemov 77 0.6% Thierry Reding 74 0.6%

By changed lines Doug Ledford 53086 7.7% Tomi Valkeinen 36631 5.3% Eric Huang 22714 3.3% Alex Deucher 16604 2.4% yanyang1 11129 1.6% Igal Liberman 10569 1.5% Thierry Reding 9842 1.4% Bard Liao 9762 1.4% Christoph Hellwig 9680 1.4% Arnd Bergmann 9233 1.3% Geert Uytterhoeven 8325 1.2% Stephen Boyd 8183 1.2% Paul E. McKenney 7485 1.1% Rex Zhu 7382 1.1% The etnaviv authors 7238 1.1% Jammy Zhou 7175 1.0% Mauro Carvalho Chehab 6473 0.9% Eric Anholt 6234 0.9% Maruthi Srinivas Bayyavarapu 5239 0.8% Adam Thomson 5153 0.7%

Linus Walleij topped the by-changesets list with a lot of low-level work, mostly near the GPIO subsystem and drivers that use it. Arnd Bergmann works all over the tree, mostly dealing with build problems and improving ARM multiplatform support. Leo Kim worked exclusively on cleaning up the wilc1000 driver in the staging tree, Mauro Carvalho Chehab made many improvements as the maintainer of the media subsystem, and Geert Uytterhoeven did a lot of work in the ARM and related driver subsystems.

In many development cycles, this list has been dominated by developers working in the staging subsystem, but 4.5 is an exception: only two of the developers in the by-changesets column had any significant work in the staging tree at all. Both of them, as it turns out, were working on the wilc1000 driver.

In the lines-changed column, longtime contributor Doug Ledford got to the top with three changesets removing three unloved staging drivers, deleting 53,000 lines of code. Tomi Valkeinen did a lot of work with the TI OMAP subarchitecture, while Eric Huang, Alex Deucher, and "yanyang1" all added functionality to the AMD graphics drivers. Further down that list, "the etnaviv authors" is an alias that was used for a single patch adding the Etnaviv graphics driver; it represents the work of Christian Gmeiner, Russell King, and Lucas Stach.

Work on the 4.5 kernel was supported by just over 200 companies that we could identify — a typical number. The employers supporting the most work this time were:

Most active 4.5 employers

By changesets Intel 1734 14.4% (Unknown) 975 8.1% Red Hat 732 6.1% Linaro 723 6.0% (None) 628 5.2% Samsung 513 4.3% SUSE 382 3.2% Atmel 380 3.2% Renesas Electronics 360 3.0% IBM 346 2.9% AMD 283 2.4% Mellanox 275 2.3% (Consultant) 245 2.0% Broadcom 208 1.7% Oracle 179 1.5% Google 160 1.3% Texas Instruments 152 1.3% Huawei Technologies 141 1.2% NVidia 137 1.1% ARM 127 1.1%

By lines changed Red Hat 83657 12.1% Intel 80160 11.6% AMD 74673 10.8% Texas Instruments 41808 6.1% (Unknown) 27958 4.1% IBM 25433 3.7% Linaro 22198 3.2% (None) 21929 3.2% Mellanox 19558 2.8% Samsung 19190 2.8% Renesas Electronics 17964 2.6% (Consultant) 15593 2.3% NVidia 15038 2.2% Freescale 13964 2.0% Code Aurora Forum 13514 2.0% Atmel 10845 1.6% Realtek 10090 1.5% Rockchip 9735 1.4% Huawei Technologies 7992 1.2% Broadcom 7930 1.2%

Intel is, by now, the dominant contributor; it would have been at the top of both lists except for the aforementioned drivers removed by Doug Ledford. Red Hat, which once reliably sat at the top of the list, may soon be overshadowed by companies working in the mobile and embedded space. In general, though, this table looks much like it has for some time.

If we look at non-author signoffs — the addition of Signed-off-by tags to patches by developers other than the author — the story looks just a little different:

Most non-author signoffs in 4.5
Developers Greg Kroah-Hartman 1009 9.0% David S. Miller 950 8.5% Mark Brown 585 5.2% Andrew Morton 451 4.0% Martin K. Petersen 264 2.4% Arnaldo Carvalho de Melo 263 2.3% Mauro Carvalho Chehab 235 2.1% Glen Lee 210 1.9% Rafael J. Wysocki 205 1.8% Kalle Valo 193 1.7%	Companies Red Hat 1981 17.8% Intel 1459 13.1% Linux Foundation 1029 9.2% Linaro 1003 9.0% Google 632 5.7% Samsung 447 4.0% (None) 361 3.2% Oracle 295 2.7% IBM 288 2.6% SUSE 265 2.4%

To a first approximation, this table represents the most active subsystem maintainers — the developers who make the decision to accept any given patch. While the more traditional, enterprise-oriented companies remain at the top of this list, the curve has been flattening over time as more companies take responsibility for the maintenance of parts of the kernel.

Finally, it has been a while since we looked at what the most active companies are most interested in. That is a simple matter of picking out the patches contributed by a given company's developers and noting which files were touched. So, for example, here is where Intel works:

Intel
%	Subsystem	Notes
67%	drivers/	29% gpu, 15% net, 5% staging
12%	include/
9%	sound/
5%	net/
5%	arch/	3.3% x86
4%	kernel/
4%	mm/

Intel, clearly, is focused on drivers for its hardware and CPUs, as one might expect. The picture for Red Hat is a bit different:

Red Hat
%	Subsystem	Notes
29%	drivers/	6% gpu, 5% net, 3% tty
22%	tools/	19% perf
17%	fs/	4% xfs, 3% nfs, 3% gfs2, 2% namei.c, 1% btrfs, 1% ceph, 1% f2fs, 1% ext4
14%	include/
13%	arch/	4% x86, 2% arm, 2% s390, 1% powerpc, 1% sparc
7%	kernel/
5%	net/
3%	crypto/

Red Hat's contribution to the tools directory (and the perf tool in particular) has increased over the years, but the company still works all over the kernel, putting a significant part of its effort into the core kernel code.

What about Linaro, which has been increasing its contributions over the years?

Linaro
%	Subsystem	Notes
66%	drivers/	17% gpio, 7% clocksource, 7% pinctrl, 4% mfd, 4% staging, 4% net
25%	arch/	19% arm, 4% arm64, 1% mips
6%	include/
3%	sound/
3%	Documentation/

Linaro is all about hardware enablement, and its work shows that. Even the work in the documentation directory is aimed that way: almost all of it happened in the devicetree subdirectory. (Lest anybody worry that the numbers add up to over 100%, remember that many patches touch more than one subdirectory, and are thus counted more than once).

Many of the other companies on the list have similar patterns; they tend to be interested in support for their own hardware, so that is where their work is done. Something slightly different can be seen if one skips down the list and looks at Google, though:

Google
%	Subsystem	Notes
29%	drivers/	9% net, 8% input, 5% usb, 4% md, 3% pci
31%	net/	15% ipv4, 9% core, 8% ipv6
17%	include/
15%	arch/	10% x86, 3% powerpc, 2% arm, 2% arm64
6%	fs/	3% ext4

Many of the improvements to the networking subsystem have, in recent years, come from Google; the numbers here show that Google is still interested in making Linux networking better.

All of this activity is the result of around 200 companies and numerous individuals, all working in pursuit of their own interests without any sort of overall control. As one might expect, the outcome can be a bit patchy at times; less energy goes into areas like documentation and security than one might like. But we still get a quickly evolving, highly capable kernel out of it, and that doesn't look like it will change anytime soon.

Index entries for this article
Kernel	Releases/4.5

---

to post comments