|
|
Subscribe / Log in / New account

Who wrote 2.6.32

By Jonathan Corbet
November 24, 2009
As of this writing, the 2.6.32 appears poised for a release right around the beginning of December. That can only mean that the time has come to look at the code which has gone into this kernel and where it came from. It has been another active cycle, with a lot of changes making it into the mainline.

In particular, as of this writing (shortly after the 2.6.32-rc8 release), 2.6.32 is the result of 10,767 non-merge changesets sent in by 1,229 developers. These changes added a total of 1.17 million lines, while removing 611,000 lines, for a net growth of 559,000 lines of code. According to Rafael Wysocki's regression reports, this development cycle introduced a total of 86 regressions into the kernel - slightly fewer than we saw for 2.6.31. As of that posting, the number of unresolved regressions was shrinking quickly, with 25 of them still without a resolution.

So who added all those regressions lines of code? The statistics for this cycle look like this:

Most active 2.6.32 developers
By changesets
Greg Kroah-Hartman2021.9%
Johannes Berg1801.7%
Bartlomiej Zolnierkiewicz1641.5%
Mark Brown1541.4%
Paul Mundt1391.3%
Takashi Iwai1391.3%
Alan Cox1291.2%
Roel Kluin1151.1%
Luis R. Rodriguez1051.0%
Dan Williams860.8%
Tejun Heo840.8%
Herbert Xu810.8%
Peter Zijlstra800.7%
Ingo Molnar770.7%
Julia Lawall770.7%
Steven Rostedt730.7%
Magnus Damm720.7%
Joe Perches710.7%
Joerg Roedel700.7%
By changed lines
Greg Kroah-Hartman17442711.5%
Bartlomiej Zolnierkiewicz1080567.1%
Mauro Carvalho Chehab627195.2%
Jing Huang491893.2%
Forest Bond450093.0%
Ben Hutchings374182.5%
Eilon Greenstein280081.8%
Mark Brown245161.6%
Brian Swetland227751.5%
Hank Janssen196811.3%
Leo Chen174581.2%
Palash Bandyopadhyay167901.1%
Alan Cox164661.1%
Mithlesh Thukral151731.0%
Jerome Glisse143430.9%
Michael Chan134150.9%
Martyn Welch124800.8%
Iliyan Malchev121720.8%
Jesse Brandeburg110510.7%

As has become traditional, Greg Kroah-Hartman and Bartlomiej Zolnierkiewicz feature at the top of both lists. Much of Greg's work had to do with the cleaning up of Microsoft's "hv" drivers. His state of mind during this process is best assessed from the commit messages, which tend to read like this one:

The Linux kernel doesn't have all caps structures, we don't like to shout at our programmers, it makes them grumpy. Instead, we like to sooth them with small, rounded letters, which puts them in a nice, compliant mood, and makes them more productive and happier, allowing them more fufilling lives overall.

Greg also removed some drivers from the staging tree, shrinking the kernel by over 100,000 lines.

The bulk of Bartlomiej's work is also in the staging tree, and that is mostly concerned with fixing up a series of rather unloved wireless network drivers. These patches are somewhat controversial; the wireless developers would rather see that effort going into a different set of non-staging drivers. But those drivers are not yet ready for prime time, and, meanwhile, people are using the staging drivers. Wireless drivers were also the focus of Johannes Berg's work; he has made a long set of improvements to the mac80211 subsystem and its cfg80211 configuration interface. Mark Brown continues to contribute large amounts of code in support of Wolfson Micro's components, and Paul Mundt remains active as the Super-H maintainer.

In the "lines changed" column, Mauro Carvalho Chehab contributed a lot of patches as the Video4Linux2 maintainer. Jing Huang contributed the Brocade BFA FC SCSI driver, and Forest Bond added the VT6656 wireless driver to the staging tree.

Developers working on 2.6.32 were supported by (at least) 196 employers. The most active companies this time around are:

Most active 2.6.32 employers
By changesets
(None)184517.1%
Red Hat10289.5%
(Unknown)9338.7%
Intel8888.2%
Novell6626.1%
IBM6035.6%
Oracle3193.0%
Renesas Technology2642.5%
AMD2512.3%
Nokia2041.9%
Fujitsu2011.9%
Atheros Communications1971.8%
(Consultant)1951.8%
(Academia)1671.6%
Texas Instruments1551.4%
Wolfson Micro1531.4%
Broadcom1491.4%
HP1301.2%
Analog Devices1241.2%
Pengutronix1191.1%
By lines changed
(None)28201718.6%
Novell25680816.9%
Red Hat1507819.9%
Broadcom849045.6%
Intel792675.2%
(Unknown)771225.1%
Brocade491893.2%
Logic Supply451653.0%
Google409362.7%
IBM296162.0%
Wolfson Micro255771.7%
Texas Instruments248241.6%
Renesas Technology245071.6%
Nokia241921.6%
Microsoft196961.3%
Oracle194101.3%
(Consultant)187741.2%
Conexant167901.1%
LinSysSoft Technologies151731.0%
GE Fanuc124950.8%

The sharp-eyed reader will notice that Red Hat has fallen below 10% of the total changes - the first time that has happened since the 2.6.21 development cycle in early 2007. The number of changes from Red Hat this time around is only slightly lower than the usual, though; what's happening is that some of the other companies are catching up.

There are a couple of other interesting entries here. Google takes a lot of grief for not contributing back, but that company was the source of a fair amount of code going into 2.6.32. Much of that was support for the HTC "Dream" (aka G1 or ADP1) phone platform, but Google also contributed to control groups, ext4, memory management, IPVS, and libata. And one may have never expected to see Microsoft show up on the list of top kernel contributors, but the hv drivers put it there for 2.6.32.

The numbers for signoffs have not changed much from previous cycles:

Top non-author signoffs in 2.6.32
Individuals
David S. Miller99610.2%
John W. Linville99410.2%
Greg Kroah-Hartman7888.1%
Andrew Morton7868.1%
Ingo Molnar5015.1%
Mauro Carvalho Chehab3984.1%
James Bottomley3103.2%
Len Brown1881.9%
Paul Mundt1711.8%
Russell King1651.7%
Employers
Red Hat360637.1%
Novell130913.5%
Intel9069.3%
Google7938.2%
(None)4454.6%
IBM3843.9%
(Consultant)2742.8%
Renesas Technology1801.9%
Wolfson Micro1551.6%
Oracle1381.4%

If anything, the subsystem maintainers are concentrating even more than before. Fully 2/3 of the patches going into the mainline kernel pass through the hands of developers working for just four companies.

At the 2009 Kernel Summit, the participants concluded that, while improvements can always be made, the process as a whole is working well. The picture that comes from these numbers suggests the same conclusion: the kernel development machine continues to absorb massive numbers of changes from a wide development community while continuing to produce stable, increasingly functional releases.

Index entries for this article
KernelReleases/2.6.32


to post comments

Still no Canonical?

Posted Nov 25, 2009 18:44 UTC (Wed) by nevets (subscriber, #11875) [Link] (10 responses)

OK, I have to say it. I never expected Microsoft to show up on that list before Canonical!

Still no Canonical?

Posted Nov 25, 2009 21:22 UTC (Wed) by gregkh (subscriber, #8) [Link] (9 responses)

Still no Canonical?

Posted Nov 25, 2009 22:00 UTC (Wed) by hppnq (guest, #14462) [Link] (2 responses)

Well, here's something to pick you up!

memset(request, sizeof(struct storvsc_request_extension), 0);

Industrial-strength hilarious code is exactly what this kernel lacked all these years.

Still no Canonical?

Posted Nov 25, 2009 22:03 UTC (Wed) by gregkh (subscriber, #8) [Link] (1 responses)

Already fixed and in the linux-next tree. See: http://lkml.org/lkml/2009/11/11/336 for details.

Still no Canonical?

Posted Nov 25, 2009 22:05 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

Still no Canonical?

Posted Nov 25, 2009 22:03 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Although not directly related to your area of interest, I wonder if you have run detailed stats on things a bit higher up the stack including desktop environments like GNOME and KDE? I am curious to know how different the picture looks. Since you went to the level of Xorg, I don't think its a strech to look more holistically at a enlarged core Linux ecosystem.

Still no Canonical?

Posted Nov 25, 2009 22:08 UTC (Wed) by gregkh (subscriber, #8) [Link]

No, I have not run any stats on stuff higher up than the plumbing, as I'm personally not interested in those ecosystems at this moment.

But all of the scripts that we use to generate this information are published, if anyone else wants to do it, feel free to do so.

Still no class?

Posted Nov 26, 2009 2:12 UTC (Thu) by kragil (guest, #34373) [Link] (2 responses)

I think that is just petty tbh.

So MS dropped a big pile of code to improve Linux as a guest on their platform.
Canonical just fixed a few real problem linux users had.

I'll prefer Canonicals contribution to MS' any day.

Only when Linux has reached world domination we can really tell who contributed most to its success.

I wouldn't bet on Novell to win that prize though.

Still no class?

Posted Nov 26, 2009 5:12 UTC (Thu) by foom (subscriber, #14868) [Link] (1 responses)

> I think that is just petty tbh.

I went and looked up the linked article, an official blog by Novell's Chief Marketing Officer:

Of course this announcement is about much more than 20,000 lines of code Microsoft is committing (which by the way once accepted into the Linux tree will far surpass those contributed by Canonical).

Wow, yes, that really does seem petty.

Microsoft's contribution is just a driver for improving the speed of linux guests hosted on their proprietary virtualization platform. I'm sure it's nice for Windows users, but it doesn't matter whether that's 20 kLOC or 2 LOC: it's still an isolated driver for virtualization on top of proprietary OS. And I have no doubt that it helps further Windows sales and deployment way more than it helps further Linux deployment...

I'm certain that if Canonical has contributed even one line of code to Linux, it will have been a more valuable contribution, to me, than the 20kLOC that Microsoft contributed. (...which they only did under duress, I'm led to believe).

That said, it would of course be wonderful for Canonical to do more kernel devopment...

Drop staging from the statistics?

Posted Nov 26, 2009 9:17 UTC (Thu) by wsa (guest, #52415) [Link]

I agree and would again vote for excluding staging from these statistics (or make it a seperate list). Most people here probably know how to read these rankings, but most not involved in kernel development won't. IMHO it's just too easy to make 'big headlines' out of nothing this way. The ultimate nightmare would be some "Let's dump a driver and get famous"-tourism getting popular within marketing areas ;)

Still no Canonical?

Posted Dec 9, 2009 14:18 UTC (Wed) by Cato (guest, #7643) [Link]

Ignoring Canonical's major contributions in usability and integration above the kernel is also pretty "sad", not to say biased. If you weren't working for a competitor, your harping on about this would be more credible - I prefer Red Hat's approach in just developing great new features in Fedora.

Who wrote 2.6.32

Posted Nov 25, 2009 22:15 UTC (Wed) by ajb (subscriber, #9694) [Link] (1 responses)

It's also notable that Broadcom was 4th in terms of lines changed, after None, Novell, and Red Hat.

Who wrote 2.6.32

Posted Nov 27, 2009 12:43 UTC (Fri) by rvfh (guest, #31018) [Link]

Indeed, that seems odd as we always complain about their attitude regarding wireless drivers... I assume they are more active in the wired side of things.

Who wrote 2.6.32

Posted Nov 26, 2009 5:07 UTC (Thu) by mcisely (guest, #2860) [Link] (2 responses)

Is that first table "Most active 2.6.32 developers" really tallied using changeset "from:" headers or is it "signed-off-by:" headers? If it is signed-off-by then at least in one case I think you are crediting the subsystem maintainer for all the work done by those actually working on that subsystem. Just a guess.

Also, something strange: Mauro is credited with 62719 lines of code changed yet that is still not enough changesets to break into the top-19 list by changeset? That means that those 62719 lines of code are spread over less than 70 changesets. That's nearly 900 lines / changeset. Seems out of scale. Maybe it was skewed by just a few enormous cases?

Who wrote 2.6.32

Posted Nov 30, 2009 11:04 UTC (Mon) by broonie (subscriber, #7078) [Link]

It's From: AFAICT.

Developer credit

Posted Nov 30, 2009 14:16 UTC (Mon) by corbet (editor, #1) [Link]

It's taken from the "author" credit in git. Subsystem maintainers generally take pain to get that right, so it's a pretty reliable metric. I only know of a couple of significant exceptions; one was in the early days of the staging tree, and the article at that time explained the issue. I did also make a correction for one misattribution in the 2.6.32 series.

Google and 2.6.32

Posted Nov 26, 2009 14:00 UTC (Thu) by mbanck (subscriber, #9035) [Link] (2 responses)

Google takes a lot of grief for not contributing back, but that company was the source of a fair amount of code going into 2.6.32.

I don't see Google in the above statistics, were their "fair amount of code" below the cutoff, or was this a typo and Google contributed to 2.6.31 (or 2.6.33)?

Google and 2.6.32

Posted Nov 26, 2009 15:22 UTC (Thu) by mbanck (subscriber, #9035) [Link] (1 responses)

OK, I indeed missed it. They contributed 40k lines, but only a few changesets.

Sorry.

Google and 2.6.32

Posted Nov 27, 2009 13:14 UTC (Fri) by alex (subscriber, #1355) [Link]

I suspect the board support stuff came in big chunks without the development
history behind them, hence the low changeset count.

Who wrote 2.6.32

Posted Nov 27, 2009 14:49 UTC (Fri) by broonie (subscriber, #7078) [Link]

While a good proportion of my code (more than average this time around) is device support there's also a good proportion of subsystem work and CPU side support in there too (hence also the appearance in the non-author signoffs).


Copyright © 2009, 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