Kernel development

Kernel release status

The current development kernel is 4.10-rc7, released on February 5. Linus said: "Hey, look at that - it's all been very quiet, and unless anything bad happens, we're all back to the regular schedule with this being the last rc."

Stable updates: 4.9.7 and 4.4.46 were released on February 2, followed by 4.9.8 and 4.4.47 on February 4. There was also a surprise 3.18.48 update, despite that kernel's end-of-life status, on February 8.

The 4.9.9 and 4.4.48 updates are in the review process as of this writing; they can be expected on or after February 9.

Comments (none posted)

Quote of the week

— Greg Kroah-Hartman

Comments (7 posted)

Some 4.10 Development statistics

If Linus Torvalds is to be believed, the final 4.10 kernel release will happen on February 12. This development cycle has been described as "quiet", but that term really only applies if one looks at it in comparison with the record-setting 4.9 cycle. As will be seen below, there was still quite a bit of activity in this "quiet" cycle; the kernel community is never truly quiet anymore, it would seem.

As of this writing, 12,811 non-merge changesets have been pulled into the mainline repository for the 4.10 development cycle. Those changes were contributed by 1,647 developers, of whom 251 made their first-ever contribution in 4.10. These numbers put this development cycle firmly in line with its predecessors:

Release	Changesets	Developers
4.0	10,346	1,458
4.1	11,916	1,539
4.2	13,694	1,591
4.3	11,894	1,625
4.4	13,071	1,575
4.5	12,080	1,538
4.6	13,517	1,678
4.7	12,283	1,582
4.8	13,382	1,597
4.9	16,214	1,729
4.10	12,811	1,647

The trend toward increasing numbers of changesets clearly continues, with numbers that are now routinely higher than were seen even in the 4.0 kernel, less than two years ago.

The most active developers this time around were:

Most active 4.10 developers

By changesets Mauro Carvalho Chehab 231 1.8% Chris Wilson 193 1.5% Arnd Bergmann 134 1.0% Christoph Hellwig 115 0.9% Ben Skeggs 95 0.7% Jiri Olsa 92 0.7% Geert Uytterhoeven 86 0.7% Wei Yongjun 85 0.7% Thomas Gleixner 83 0.6% Ville Syrjälä 82 0.6% Felipe Balbi 79 0.6% Javier Martinez Canillas 79 0.6% Masahiro Yamada 77 0.6% Trond Myklebust 76 0.6% Tvrtko Ursulin 76 0.6% Dan Carpenter 73 0.6% Sergio Paracuellos 73 0.6% Walt Feasel 72 0.6% Neil Armstrong 70 0.5% Eric Dumazet 67 0.5%

By changed lines Andi Kleen 83560 9.7% Tom St Denis 55590 6.4% Mauro Carvalho Chehab 44120 5.1% Edward Cree 19164 2.2% Zhi Wang 16077 1.9% Christoph Hellwig 13872 1.6% Takashi Iwai 12707 1.5% Neil Armstrong 11809 1.4% Chris Wilson 9042 1.0% Thomas Lendacky 8693 1.0% Bard Liao 8189 0.9% Tony Lindgren 8183 0.9% Jani Nikula 8059 0.9% James Smart 7655 0.9% Manish Rangankar 7470 0.9% Ard Biesheuvel 6996 0.8% Raghu Vatsavayi 6753 0.8% Ben Skeggs 6482 0.7% Sukadev Bhattiprolu 6415 0.7% Rob Clark 6017 0.7%

Mauro Carvalho Chehab is the media subsystem maintainer, and much of his work this time around was focused there. He also, however, did a lot of work in the ongoing process of converting the kernel's documentation to Sphinx and organizing it. Chris Wilson works on the Intel i915 driver, Arnd Bergmann made fixes all over the kernel tree, Christoph Hellwig contributed a lot of changes in the block and filesystem areas, and Ben Skeggs works on the Nouveau graphics driver.

In the "changed lines" column, Andi Kleen ended up at the top of the list with a bunch of work in the perf events subsystem. Tom St. Denis added a bunch of code to the amdgpu driver, Edward Cree enhanced the sfc network driver, and Zhi Wang, once again, works in the i915 driver.

These lists are often dominated by developers working in the staging tree but, this time, nobody in the top five of either list was creating staging patches. Indeed, Sergio Paracuellos is the first staging-focused developer in the left column, while no staging work features in the right column at all. The staging tree itself was busy enough, with 957 changes in 4.10, but that work was spread across 158 developers.

Work on 4.10 was supported by 218 employers that can be identified. The list of the most active employers looks pretty much like it usually does:

Most active 4.10 employers

By changesets Intel 1752 13.7% (Unknown) 1198 9.4% Red Hat 907 7.1% (None) 765 6.0% Samsung 545 4.3% Linaro 496 3.9% SUSE 471 3.7% IBM 381 3.0% (Consultant) 337 2.6% AMD 316 2.5% Google 306 2.4% Mellanox 297 2.3% Renesas Electronics 236 1.8% Texas Instruments 226 1.8% Huawei Technologies 202 1.6% Broadcom 199 1.6% Oracle 183 1.4% ARM 176 1.4% Linutronix 154 1.2% NXP Semiconductors 151 1.2%

By lines changed Intel 176549 20.4% AMD 74965 8.7% Samsung 57529 6.6% Red Hat 41171 4.8% (Unknown) 34748 4.0% Linaro 32670 3.8% SUSE 31570 3.6% (None) 28002 3.2% IBM 26238 3.0% (Consultant) 25744 3.0% Solarflare Comm. 20211 2.3% MediaTek 15979 1.8% Cavium 15812 1.8% Broadcom 15695 1.8% BayLibre 14597 1.7% Mellanox 12770 1.5% NXP Semiconductors 11792 1.4% NVidia 11279 1.3% Texas Instruments 10420 1.2% Facebook 8896 1.0%

Another way to look at the employer information is to see how many developers are associated with each company:

Companies with the most developers
Company	Devs	Pct
(Unknown)	349	20.5%
Intel	182	10.7%
(None)	103	6.1%
Red Hat	96	5.6%
IBM	66	3.9%
Google	53	3.1%
Mellanox	42	2.5%
Linaro	40	2.4%
Samsung	37	2.2%
SUSE	33	1.9%
Texas Instruments	28	1.6%
AMD	27	1.6%
Oracle	26	1.5%
Code Aurora Forum	26	1.5%
Huawei Technologies	25	1.5%
NXP Semiconductors	22	1.3%
ARM	21	1.2%
Broadcom	20	1.2%
Renesas Electronics	17	1.0%
Rockchip	15	0.9%

Here we see that nearly 11% of the developers who contributed to the 4.10 kernel were working for Intel. Over 20% were of unknown affiliation; they contributed 9.4% of the changes merged in this cycle.

Normal practice in these summaries is to look at the "most active employers" table above and conclude that (in this case) if all of the unknowns are working on their own time, then a maximum of just over 15% of the changes in this development cycle came from volunteers. The above table paints a slightly different picture; if, once again, the unknowns are all volunteers, then nearly 27% of the community is made up of volunteers. The difference between the numbers is almost certainly explained by the unsurprising observation that developers doing kernel work for their job will be able to spend more time on that work and, as a result, be more productive.

As of this writing, there are just over 7,500 changesets in the linux-next repository. Those changes are the beginning of what will be merged for 4.11; history suggests that this number is likely to grow significantly between now and the opening of the 4.11 merge window. Still, it seems clear that 4.11 is unlikely to set any new records for patch volume. For the definitive answer, look forward to the 4.11 summary article, to be published in 63-70 days.

Comments (1 posted)

Unscheduled maintenance for sched.h

The kernel contains a large number of header files used to declare data structures and functions needed in more than one source file. Many are small and only used in a few places; others are large and frequently included. Header files have a tendency to build up over time since they often do not get as much attention as regular C source files. But there can be costs associated with bloated and neglected header files, as a current project to clean up one of the biggest ones shows.

The 0.01 kernel release contained a grand total of 31 header files, nine of which lived in include/linux. One of those, <linux/sched.h>, weighed in at all of 230 lines — the largest header file in that directory. Things have changed just a little bit since then. The upcoming 4.10 kernel contains 18,407 header files, just under 10,000 of which are intended for use outside of a specific subsystem. The 4.10 version of <linux/sched.h> is 3,674 lines, but that understates its true weight: it directly includes 50 other header files, many of which will have further includes of their own. This is not the 0.01 <linux/sched.h> anymore.

Ingo Molnar has decided that it is time to do something about this header file. A large header has its costs, especially when it is (by your editor's count) directly included into 2,500 other files in the kernel. An extra 1,000 lines of bloat expands into 2.5 million lines more code that must be compiled in a (full) kernel build, slowing compilation times significantly. A large and complex header file is also difficult to maintain and difficult to change; there are too many subtle dependencies on it throughout the kernel.

How did this file get into this condition? As Molnar put it:

Molnar's response is a petite 89-part patch set intended to disentangle the sched.h mess. It starts by splitting out many of the more esoteric scheduler interfaces that are not needed by most users of <linux/sched.h>. This header is often included by driver code, which typically needs a small subset of the available interfaces, but which has no use for CPU frequency management, CPU hotplugging, accounting, or many other scheduler details. Code that needs the more specialized interfaces can find a set of smaller header files under include/linux/sched, but, Molnar says, 90% of users have no need for those other files.

Beyond the split-up, the patch set cleans up the interfaces with a number of other "entangled", heavily-used header files so that each can be included separately. That eliminates the need to include those headers in sched.h. There was also a certain amount of historical cruft: header files that may have been needed at one time, but which were never removed from sched.h when that need went away.

The result is a leaner sched.h that, Molnar says, can save 30 seconds on an allyesconfig kernel build. There are some details to be taken care of, though, beyond fixing source files that need the interfaces that have been split out to their own files. Since sched.h included so many other files, code that included it could get away without including the others, even if it needed them. Kernel code is supposed to explicitly include every header it needs and not rely on secondary inclusions but, if the code compiles anyway, it is easy to overlook a missing #include line. Taking those inclusions out of sched.h meant fixing up code elsewhere in the kernel that stopped compiling.

After this work is done, the resulting patch set touches nearly 1,200 files; it is not a lightweight change, in other words. Molnar suggested that the patch set should be applied at the end of the merge window in the hope of minimizing the effects on other outstanding patches. He did not specify which merge window he was targeting; 4.11 might still be possible and might be as reasonable a choice as any. Most patch sets are expected to spend some time in linux-next for wider testing, but this set almost certainly cannot go there without creating a massive patch-conflict nightmare.

There are some changes that will need to be made before this work can be merged, though. Linus Torvalds liked the end result, but was not pleased with how the patch set is organized. The changes are mixed together in a way that makes the patches hard to review and which, as was seen in a couple of cases, makes it easy for mistakes to slip in.

He suggested that, instead, the series should start by splitting out parts of sched.h, but leaving things externally the same by including the split-out files back into sched.h. These changes could thus be made without changing code elsewhere in the kernel. After that, the back-includes could be removed, one by one, with the necessary fixes being applied elsewhere. The patches in this part of the series would consist of only #include changes and would, thus, be quick to review and verify. Molnar agreed to rework the patches along these lines, though he warned that this work "will increase the patch count by at least 50%". Making the patch set easier to review (and to bisect) will, hopefully, more than make up for the increased patch count.

If this work can be completed in a convincing way before the close of the merge window, it may well make sense to apply it right away, even though the combination of big, intrusive, and new normally suggests that it may be better to wait. Causing this work to sit out for another development cycle would force much of it to be redone, and the end result may not be any more "ready" in 4.12 than it would be for 4.11. Of course, once this patch set is merged and the final loose ends tied down, the work is not yet done; there are a number of other large and messy header files in the kernel tree. The next target for a split-up may be another huge header file present since the 0.01 release: <linux/mm.h>.

Comments (none posted)