The current 2.6 prepatch is 2.6.23-rc6
by Linus on
September 10. The number of fixes this time around is relatively
small, partly because many of the developers were off at the kernel summit
last week. The long-format
has the details.
The flow of patches into the mainline git repository continues; there will
almost certainly need to be an -rc7 release before this kernel is done.
There have been no -mm releases over the last week.
For older kernels: 188.8.131.52 was released on
September 8 with one security fix in the IPv6 code.
184.108.40.206 was released on
September 8; it contains mostly compiler-related fixes. 2.4.36-pre1 was also released on
the 8th; it contains a few fixes and a patch to optionally prevent
processes from mapping the NULL address.
Comments (none posted)
Kernel development news
So I'm doing an inverted reverse polish bisection search to find out which
patch preemptively fixes clockevents-fix-resume-logic.patch. Try doing
that with git, suckers.
-- Andrew Morton
C++ is a horrible language. It's made more horrible by the fact
that a lot of substandard programmers use it, to the point where
it's much much easier to generate total and utter crap with
it. Quite frankly, even if the choice of C were to do *nothing* but
keep the C++ programmers out, that in itself would be a huge reason
to use C.
-- Linus Torvalds
Comments (24 posted)
The 2007 version of the Linux Kernel Developers' Summit was held on
September 5 and 6 in Cambridge, UK. Approximately 80 developers
at this invitation-only event held discussions on a wide variety of topics
covering all aspects of kernel development. As usual, LWN editor Jonathan
Corbet was there. Reports from the sessions will appear below as they are
- The distributor panel. Kernel
maintainers from four distributors attended a session meant to be a
forum where they could tell the community how the process could be
improved from their point of view. In the event, much of the
information flowed in the other direction, with community developers
expressing frustration with a number of distributor practices.
- Mini-summit reports. Reports from
mini-summits covering power management, filesystems and storage,
virtual memory, and virtualization held in the months prior to the
main kernel summit.
- The greater kernel ecosystem and
user-space APIs. A discussion of how the kernel presents
interfaces to user space and the low-level software which helps with
this task. Also covered here is the session on a proposal for a
formal review process for new system calls.
- Kernel quality. In the session he led
on this topic, Andrew Morton was unable to say whether he thought our kernel
releases were getting better or worse. But he had no doubt that we
could be doing a better job than we are now.
- Hardware support and the i386/x86_64
merger. This was a discussion of the state of drivers for various
difficult chipsets; it included AMD's important announcement of the
opening of its graphics processors. There was also a session on the
question of whether the i386 and x86_64 architecture trees should be
The preparation of reports from the second day is being somewhat delayed by
your editor's travel. They will show up here as they become available.
- The customer panel. An interesting
discussion of customer needs by representatives from Dreamworks,
Credit Suisse, and the Linux Foundation.
- Realtime and syslets.
What is the status of the realtime patch set, and what's next for
- Scalability. Issues for
people trying to run Linux on very large and very small systems.
- Memory management. Discussions on
large page support, test cases for memory management patches, and
letting applications help with memory pressure.
- Containers. What remains to be done
to have a complete containers implementation in the mainline kernel.
- Developer relations and development
process. How can the community bring in more developers and avoid
driving away those who are here now? This question was addressed,
along with a number of nuts-and-bolts issues relating to how the
development process works.
- Closing session. The final session of
the 2007 kernel summit was about the kernel summit itself. Was this
event what the attendees had hoped for, and how should things be done
in the future?
The group picture
How could there be a kernel summit without a group picture? Here is (most
of) the group in front of the Downing College dormitory where many of us
This photo is available in the following forms:
By popular demand, we also have an annotated
version of the full-resolution image with names assigned to as many
faces as possible.
Thanks to Michael Kerrisk for operating your editor's camera, allowing him
to be in the group picture for the first time.
Comments (none posted)
Loadable kernel modules do not automatically have access to all symbols
(functions and variables) defined in the kernel. In fact, access is
limited to those symbols which have been explicitly exported for modular
use. The idea behind this whitelist-like policy is that it helps the
kernel developers to keep the module interface under control, limiting the
ability of modules to dig into parts of the kernel where they are not
welcome. The practice turns out to be a little more messy: current kernels have over
16,000 EXPORT_SYMBOL() declarations sprinkled around the source.
Unsurprisingly, there are developers who would like to reduce the number of
exported symbols. It is often the case that, once a symbol can be shown to
have no users among in-tree modules, it will be removed altogether. But
there is not universal agreement on just how this process should be
handled; as a result, we see occasional debates on how stable the modular
API should actually be and what provisions should be made for out-of-tree
Adrian Bunk recently posted a patch to unexport
sys_open() and sys_read(). These symbols (which
implement the open() and read() system calls) have been
on the hit-list for a long time. It is easy to make catastrophic mistakes
when using them from kernel space, and there is almost no situation where
opening and reading files from within the kernel is considered to be the
right thing to do. But removing the exports has always proved hard, until
now - there have always been stubborn in-tree users which have kept the
The final holdout in 2.6.23 is the wavefront sound driver which uses
sys_open() and sys_read() to obtain firmware to load into
the device. The kernel has had a proper API for dealing with firmware
loads for years, so no driver should be trying to read firmware directly
from files itself. The current ALSA development tree contains a patch for
the wavefront driver which makes it use the firmware API; once that patch
is merged, there will be no more in-tree users of those symbols. Adrian,
forever on the lookout for things to remove from the kernel, noticed this
fact and promptly sent in a patch.
Andrew Morton's response went like this:
But I think it is better to give people some warning when we're
planning on breaking out-of-tree things. I do occasionally receive
reports of "hey, the X driver which I get from Y doesn't work any
more". Often it's open-source stuff, too. I see no point in
irritating our users more than we need to.
Andrew would like to have the symbols marked with
EXPORT_UNUSED_SYMBOL() for one development cycle so that maintainers
of out-of-tree code can get the resulting warning message and fix their
code in response. It quickly became clear that he is in a minority among
the developers on this issue. Adrian was particularly upset, complaining
that other developers are allowed to make no-warning changes which break
almost every module in existence while his patch, which affects very few
modules, must go through a special process. He says:
Andrew, please define API rules, IOW rules for addition, removal
and changing of exported code, that are valid for *everyone* or go
to hell with your EXPORT_UNUSED_SYMBOL.
Christoph Hellwig also responded strongly, leading to this amusing (but not for the easily offended)
exchange. Calmer voices made a few arguments against the warning
- These symbols have been on the chopping block for a long time, and
most out-of-tree module authors should have figured that out by now.
It is worth noting, though, that the feature removal schedule in the
kernel documentation says nothing about sys_open() and
- In this sort of situation warnings are almost entirely ineffective. Users
tend not to see them at all, and they do not report them in any case.
According to Alan Cox: "Short of
using their sound card to scream 'Next release you are screwed' they
won't notice (and if you the sound card trick they'll think they got
- Keeping unused symbols around bloats the kernel and increases the load
on developers who must remember to remove them in a future release.
Andrew does not appear willing to budge on the issue, though. He does not want to unnecessarily upset users who
use out-of-tree modules:
Fact is, people use external modules. To get their machines
working correctly, to get their work done, to do stuff they want
Many of these people are non-programmers. So when they download a
new kernel and find that the module which they use doesn't work
because of something which we've done, they get pissed off, and we
lose a tester. This has happened many times.
To avoid this problem, he wants exported symbols targeted for removal to
marked with EXPORT_UNUSED_SYMBOL() (or
EXPORT_UNUSED_SYMBOL_GPL()) for one development cycle. The
exports should be marked with a comment noting when the export should be
removed altogether. Each release cycle would include a quick grep to find
the symbols which are now due to be removed for real. He concludes:
Total cost of this effort: maybe ten developer minutes per release,
and a few tens of additional bytes in the released vmlinux.
I think that for a few additional testers and a few less-pissed-off
users (nothing to do with developers), this cost is justified.
Elsewhere he has noted that, if a warning is sufficiently widespread,
somebody, somewhere, will act on it. One gets the sense that he has not
convinced a whole lot of developers that this position is right. But
Andrew is in a position to enforce it and most of the others seem to think
that, in the end, it's easier to just go along with what he wants in this
case. The end result is the same, it just takes a little longer.
Comments (5 posted)
While the 2.6.23 development cycle has not yet run its course, things are
getting close enough to the end that it makes sense to start looking at the
overall statistics for this release. As of this writing (shortly after
2.6.23-rc6 came out), just over 6,200 non-merge changesets had been added
to the mainline kernel repository. These changesets came from 854
developers - a slightly smaller number than we saw for 2.6.22. Just over
350 of those developers contributed one single changeset.
All told, the patches added almost 430,000 lines, but also removed 406,000
lines, meaning that the kernel grew by just under 23,000 lines - a
relatively small number. That is partially a result of kernel hatcheteer
Adrian Bunk's work: he removed the old SpeedStep code, a number of Open
Sound System drivers, Rise CPU support, and more - a total of almost 73,000
lines removed. Jeff Garzik hacked out over 41,000 lines of network driver
code, and Jens Axboe got rid of over 25,000 lines of code, mostly in the
form of ancient CDROM drivers.
Here is the list of the top contributors to 2.6.23, as counted by
changesets merged and by lines of code changed:
|Most active 2.6.23 developers|
|David S. Miller||107||1.7%|
|H. Peter Anvin||52||0.8%|
|By changed lines|
|David S. Miller||14752||2.2%|
Ingo Molnar comes out on top of the changesets column by virtue of getting
the CFS scheduler merged - then fixing it. Over half of his patches were
accepted after 2.6.23-rc1 came out. Ralf Baechle and Paul Mundt
both contributed many changes to architecture-specific trees, Trond
Myklebust did a lot of NFS work, and, while David Miller had a number of
networking patches, the bulk of his changesets were in the
architecture-specific (SPARC) trees. The figures on the "by changed lines"
side are dominated by code removals (as described above); Jens Axboe also
did a bunch of splice work and merged the "bsg" generic SCSI driver.
Hirokazu Takata did a bunch of m32r architecture work. James
Smart contributed a number of Fibre Channel changes and Jeremy Fitzhardinge
merged the core Xen code.
Once again, we have put some effort into associating patches with the
companies that supported this work, with the results shown below. These
results should always be taken as approximations; we believe that they are
essentially correct, but patches do not come with Paid-for-by: headers, so
a certain amount of guessing is always required.
|Most active 2.6.23 employers|
|By lines changed|
|Solid Boot Ltd.||8937||1.3%|
Red Hat retains its place at the top of the by-changesets list, though its
percentage of changes has dropped a bit. By lines changed, developers
known to be working on their own time (the "None" entry) beat out all
corporate contributors. It is worth noting that much of lines-changed
count for those developers is, in fact, lines removed.
Looking at who added Signed-off-by: lines to patches is interesting,
especially if one looks at signoffs added by people other than the author
of the patch. In this way, one gets an idea of who the gatekeepers are.
There is a slight change to how this calculation was done this time around:
if a patch carried signoffs from both Linus Torvalds and Andrew Morton,
Linus's was not counted. As a result of how the process works, everything
that goes through Andrew gets a signoff from Linus; not counting those
signoffs gives a more accurate picture of how the review was actually done.
|Developers with the most signoffs (total 5653)|
|David S. Miller||381||6.6%|
|Mauro Carvalho Chehab||150||2.6%|
|John W. Linville||70||1.2%|
One question which comes up sometimes is: how do these numbers look for
specific parts of the kernel tree? Your editor duly hacked on his scripts
to generate this sort of information. Here is a summary of the results -
using the employer by-changesets numbers:
|Employer changeset contributions by subsystem|
|/arch (1428 total)|
|/block (103 total)|
|/Documentation (241 total)|
|/drivers (2762 total)|
|/fs (622 total)|
|Univ. of Michigan CITI||35||5.6%|
|/kernel (938 total)|
|/mm (261 total)|
|/net (833 total)|
From these numbers, one might conclude that Red Hat developers are strong
in the core kernel area, but they don't much like writing documentation.
There is a lot of "hobbyist" participation in the driver subtree - not a
particularly surprising result, since making a specific device work is a
common itch for developers to scratch. Academics like to play with
filesystems, as do, unsurprisingly, companies like Oracle and NetApp.
Beyond being approximate, all of the numbers shown above will change a bit
before the final 2.6.23 release, which is probably at least three weeks
away. The patches which will be merged in the coming weeks should all be
fixed, though, so the changes will, with any luck at all, be small. All
told, 2.6.23 shows an active kernel development community with
contributions from a large number of developers - and quite a few companies
which employ them. The kernel remains a vibrant and alive base on which to
build our free systems.
(Thanks are due to Greg Kroah-Hartman for his contributions to the scripts
used to generate these statistics).
Comments (6 posted)
Patches and updates
Core kernel code
- =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=: RTC calibration.
(September 11, 2007)
Filesystems and block I/O
Virtualization and containers
Page editor: Jonathan Corbet
Next page: Distributions>>