Weekly Edition
Return to the Kernel page
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Who wrote 3.5Now that the 3.5 Linux kernel has been released, it's time for the traditional look at who wrote it. Here we'll try to summarize who did all of the work that went into this release. Fastest-changing kernel everThe 3.5 kernel was released one day faster than the 3.4 kernel was, in 62 days. The last time a kernel was released this quickly was back in 2005 with the 2.6.14 kernel release (61 days). In those 62 days, the kernel developers crammed in a record-breaking 176.73 changes per day (7.36 changes per hour.) This is the fastest-changing kernel that has been recorded since I started keeping track of this development metric back in the 2.5 kernel release series. These changes resulted in the following overall changes:
The kernel is still increasing at a pretty constant 1.37% growth in the number of lines and files, which is similar to the growth rate of the past three kernel releases. Individual contributions1,195 different developers contributing patches to the 3.5 kernel; those developers worked for at least 194 different companies. The names of the contributing developers are pretty familiar to those who track these statistics:
In the quantity category (remember, we don't judge quality), I did a large number of cleanup patches removing old USB logging macros from the system, which resulted in the majority of my changes in the 3.5 kernel. Axel contributed a great number of regulator driver fixes and enhancements, and Mark Brown did the majority of his work in the sound system-on-a-chip drivers area. H. Hartley Sweeten has been working on cleaning up the Comedi (data acquisition) drivers to get them ready to move out of the staging area of the kernel. This work has him showing up in these statistics for the first time. And rounding out the top five is David Miller with a large number of networking core and driver patches. Along with H. Hartley Sweeten, Daniel Vetter is also a newcomer to the "top changesets" list. His contributions came from numerous changes and enhancements to the Intel graphics drivers. Although Hans Verkuil is also a name that might not be familiar to many, his contributions to the Video4Linux drivers and core code show he is a core contributor to a subsystem that many users rely on every day. Considering the statistics in lines changed, Paul Gortmaker leads by virtue of the fact that he deleted all of the old Token Ring drivers from the kernel. Viresh Kumar did a lot of SPEAr processor and driver work, adding numerous new drivers for the platform. Steven Rostedt did a large amount of development on ftrace and ktest (a kernel-testing tool). H. Hartley Sweeten did the aforementioned Comedi driver cleanup work, and Dave Arlie made major changes in the area of graphics drivers. Reviewing the workAll kernel patches are reviewed and "Signed-off-by" a subsystem maintainer before they are committed to the Linux kernel. The developers with the most sign-offs for the 3.5 kernel were as follows:
I ended up doing the most sign-offs for this kernel release because of many changes in the staging and USB subsystems. David Miller follows with his work in the networking and networking driver trees, as well as in the IDE drivers. Mauro is the maintainer of the Video4Linux subsystem, Mark Brown is the maintainer of the embedded sound drivers, and John Linville is the maintainer of the wireless driver subsystem. These numbers reflect the picture of what has been happening in the past few kernel releases, with the majority of changes happening in the staging and networking areas of the kernel. Who sponsored this workHere is the list of the companies who sponsored the developers doing the work for this kernel release, and the number of changes attributed to them:
Longtime readers of this series of articles will notice that Linaro has appeared in the top 5 kernel developer companies by number of contributions for the first time. This is due to the increased number of patches Linaro has been contributing, as well as the organization's wish to have the member company employees' contributions be counted as coming from Linaro, instead of the member company itself, as we had previously been doing. A newcomer to the top 20 companies is Vision Engraving Systems, thanks to the Comedi development work from H. Hartley Sweeten. With his work, hopefully this subsystem can move out of the staging area of the kernel in a future release. Other than the large jump from Linaro, the other companies in the top 25 are well known. Even NVIDIA—despite Linus's well-publicized, and in my opinion well-deserved, criticism of its Linux graphics driver development efforts—continues to be a large contributor to the kernel in the area of embedded processor support for its products. Texas Instruments, Samsung, MiTAC, Wolfson Microelectronics, Qualcomm, Renesas, and Nokia are also primarily focused in the embedded Linux area, showing the wide range of ongoing company support for Linux in embedded systems. Work continues as usualWith the 3.5 kernel release, the number of contributors remains as high as previous releases, the rate of contributions is greater than ever (as measured by number of patches per day), and the rate of increase in the size of the kernel code remains the same as it has been for the past year. This shows that the kernel development community is still growing, and maintaining its incredibly rapid development cycle, ensuring that Linux remains the largest software engineering project ever. (Log in to post comments)
Who wrote 3.5 Posted Jul 26, 2012 7:16 UTC (Thu) by viiru (subscriber, #53129) [Link]
> Texas Instruments, Samsung, MiTAC, Wolfson Microelectronics, Qualcomm,
> Renesas, and Nokia are also primarily focused in the embedded Linux area
Nokia? I can't see Nokia mentioned in employers list, was that a mistake? I'd also find it somewhat surprising if Nokia did appear on this list, considering that they no longer have any Linux-based devices in development, and that they have in my understanding laid off their Linux developers.
Who wrote 3.5 Posted Jul 26, 2012 13:11 UTC (Thu) by jake (editor, #205) [Link]
> Nokia? I can't see Nokia mentioned in employers list, was that a mistake?
An earlier version of the article had a longer list of employers (25 instead of 20) and Nokia did appear at #23 (99 changesets, 0.9%) ... when we revised the list, we forgot to remove Nokia in the text (Renasas too for that matter). Sorry for the confusion.
jake
Who wrote 3.5 Posted Jul 26, 2012 13:13 UTC (Thu) by jake (editor, #205) [Link]
> (Renasas too for that matter)
sigh, I shouldn't post comments before coffee ... Renasas is there in the list, of course ...
jake
Who wrote 3.5 Posted Aug 3, 2012 18:00 UTC (Fri) by jake (editor, #205) [Link]
> Sure, but it's "Renesas"
heh, it's right in the article, just not in the comments ... i can't be responsible for editors misspelling things in the comments ... oh, wait :)
jake
Who wrote 3.5 Posted Jul 26, 2012 14:06 UTC (Thu) by intgr (subscriber, #39733) [Link]
It's really sad to see that AMD -- who used to be a regular appearance before 3.x or so -- has been absent for many recent releases. Does anyone know why is that so?
Who wrote 3.5 Posted Jul 26, 2012 16:13 UTC (Thu) by iabervon (subscriber, #722) [Link]
I think their hardware requires relatively little variation in the kernel portion of drivers. At least, I'm not aware of anything that AMD ought to work on in the kernel. Of course, they could arbitrarily employ kernel developers working on things other than support for their hardware, but I'd much rather they put their resources toward support for their hardware in whatever part of the system needs it, which is currently userspace graphics drivers.
Who wrote 3.5 Posted Jul 28, 2012 15:31 UTC (Sat) by jengelh (subscriber, #33263) [Link]
>I think [AMD's] hardware requires relatively little variation in the kernel portion of drivers.
Requiring less code is indeed a wonderful thing.
AHCI is one of these masterpieces: a single driver driving many consumer-level disk chipsets at once. The sound club tried something similar with AC97 and HDA. Why can't we have a unified HW API like that for further types of silicon as well, like, network cards?
Who wrote 3.5 Posted Aug 6, 2012 14:48 UTC (Mon) by nhippi (subscriber, #34640) [Link]
> I think their hardware requires relatively little variation in the kernel portion of drivers. At least, I'm not aware of anything that AMD ought to work on in the kernel.
The AMD GPU's would need more work. OTOH much that is on the MESA/Xorg side rather than in the kernel.
Who wrote 3.5 Posted Aug 23, 2012 13:37 UTC (Thu) by daenzer (✭ supporter ✭, #7050) [Link]
Eh? AMD and in particular Alex Deucher were among the most active employers / developers of the 3.4 cycle, both by changesets and number of lines changed. Similarly for many previous cycles. I'm afraid you mistook an exception for the rule.
Who wrote 3.5 Posted Aug 23, 2012 15:17 UTC (Thu) by intgr (subscriber, #39733) [Link]
> I'm afraid you mistook an exception for the rule.
Ok let's have a look at the numbers. Here are the stats for AMD in particular...
3.5 : missing
I'm afraid you mistook an exception for the rule. AMD had significant presence in all releases between 2.6.30 - 3.0, but then suddenly disappeared (apart from one exception that is 3.4).
(I created an index of LWN development statistics articles for easier reference here:
Who wrote 3.5.x Posted Jul 26, 2012 21:25 UTC (Thu) by ballombe (subscriber, #9523) [Link]
What is missing is statistic of people having worked on 3.x.y stable releases. This is an increasingly important work as evidenced by the number of releases.
I am sure the article author will agree ;).
Who wrote 3.5.x Posted Jul 26, 2012 22:31 UTC (Thu) by gregkh (subscriber, #8) [Link]
People don't "work on stable releases" they have their patches that are accepted into the main tree backported to the stable releases automagically.
Who wrote 3.5 Posted Jul 31, 2012 7:25 UTC (Tue) by nab (subscriber, #34463) [Link]
What happened to the most changed lines by employer metric..?
Who wrote 3.5 Posted Aug 1, 2012 17:27 UTC (Wed) by nevets (subscriber, #11875) [Link] Hmm, I got the top 3 spot for most lines changed due to my libtraceevents library finally making it into the kernel tools directory from trace-cmd and incorporated into perf.Should we really be posting changes to the tools directory as those that wrote 3.5 kernel? Hey! I like being at #3, but really, it wasn't for my work in the kernel.
$ git log -p --author=rostedt v3.4..v3.5 tools |diffstat | tail -1 43 files changed, 13740 insertions(+), 6963 deletions(-) $ git log -p --author=rostedt v3.4..v3.5 arch include kernel |diffstat|tail -1 27 files changed, 875 insertions(+), 453 deletions(-)
Who wrote 3.5 Posted Aug 4, 2012 23:37 UTC (Sat) by mathstuf (subscriber, #69389) [Link]
Is there a reason you're piping to diffstat instead of using git log's --stat flag?
Who wrote 3.5 Posted Aug 5, 2012 0:10 UTC (Sun) by nevets (subscriber, #11875) [Link]
How do you get --stat to show all changes? If I do git log ---stat against a bunch of different commits, it shows me only the changes against each commit individually and not a total of all commits. diffstat shows me a total of all changes at the end, which is what the tail -1 showed.
Who wrote 3.5 Posted Aug 5, 2012 0:41 UTC (Sun) by mathstuf (subscriber, #69389) [Link]
Ah, yeah, I see now. I would have done the backbone of your command with 'git diff --stat v3.4..v3.5', but the filter on the author means that log needs to be used which chunks the stat outputs. I rarely filter using log on things other than directory while also looking at --stat, so why it was missing --stat wasn't immediately obvious to me.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||