The Halloween deadline for submission of new features for the 2.5 kernel
has passed. Linus has not made final decisions on everything on the wishlist
, but most of the new features
which will be in the next stable kernel series are in the development
kernel now. And some developments clearly are not going to be in that next
stable kernel. Negative results are often the most interesting - they
expose interesting information on how the system works. So we'll look at
why a seemingly sensible feature did not get into the 2.5 kernel.
The project in question is the Linux
Kernel Crash Dump (LKCD) subsystem. LKCD comes into play if a Linux
kernel panics; it uses the swap area to create an image of the dying
system. That dump can then used to figure out just what went wrong.
Commercial operating systems have had crash dump capabilities for decades;
crash dumps make life much easier for vendors facing angry customers who
want their systems fixed immediately. Given the increasing interest in
"enterprise" deployments and high-quality support, one would think that a
crash dump capability would be a high priority for inclusion. One would
also think that it would not be controversial, since crash dump support
does not slow down or adversely affect users in any way. So why did it
fail to go in?
Certainly, there were some technical concerns about LKCD. A kernel which
is crashing is, by definition, not functioning properly; do you
really want that kernel to write massive amounts of data to disk as
its last act? Some developers fear that LKCD has not taken sufficient care
to avoid overwriting files as it saves its dump to disk. There is no real
history of people having their systems trashed by LKCD, but the worry
LKCD has not played the kernel political game all that well. In some
cases, it is enough to write code and ask that it be merged. But, as a
general rule, you have to convince Linus that the development really
belongs in his kernel. In practice, that means turning one or more of the
top-tier developers into an advocate for your work. The LKCD developers
have not done that; instead, they have tried putting pressure on Linus
directly. Linus responded by digging in his heels and stating: "...right now I won't touch LKCD
with a ten-foot pole, if only because I've been mail-bombed by people who
argue for it when I have better things to do than to explain myself over
and over again."
But neither of those reasons are the real reason why LKCD got left out in
the cold. As Linus has been saying for a few years, his real job anymore
is saying "no" to people. He says "no" to anything that, in his opinion,
does not really have to be in his kernel. It is a hard job; it requires
enough backbone (and ego) to stand up against great pressure at times. But
it is also a crucial role that must be played well if the kernel code is to
remain maintainable over the long term.
Linus said "no" to LKCD because he did see any real advantage to having it
in his kernel. LKCD, says Linus, is a "vendor-driven" development. Since
LKCD is vendor driven, the vendors that are interested can merge it into
their trees. That is what free software is all about, of course.
This attitude may seem a little harsh, but it makes sense when you consider
a couple of points:
- Vendors, with very rare exception, do not ship Linus's kernels as
he distributes them. Most vendor kernels are heavily patched, with
dozens (or even hundreds) of changes and added features. The spec file for the 2.4.18 kernel shipped
with Red Hat Linux 8.0 lists a full 200 patches; Red Hat has
added User-mode Linux, TUX, the O(1) scheduler, the low-latency patch,
NAPI, netdump (a network-based crash dumper), etc. LKCD would
be a small addition to the list of patches already applied by
distributors. The fact that few vendors have included LKCD suggests
that they, who are the main market for such a feature, are not yet
interested in it.
- It is hard to imagine any vendor being interested in a crash dump
that comes from anything other than one of their own stock
kernels. Linux empowers any user to obtain and build any kernel they
want, but those users cannot, in general, expect their vendors to
chase bugs in "roll your own" kernels.
So, by suggesting that interested vendors patch in LKCD themselves, Linus
is getting that code to the places where it is useful without having to put
it into his tree. A certain amount of kernel source bloat is avoided, the
way is left open for other potential crash dump implementations, and LKCD
is still easily deployed in the situations where it is needed. All told,
it is not an entirely unreasonable decision. The
kernel process is often hard on developers, but it important that Linus
continues to say "no" if we want to have a kernel which does not eventually
collapse under its own weight.
(See also: Linus's explanation of why LKCD
didn't go in, and of how to get patches into the kernel in general, and
this week's Kernel page, which looks at the
next steps for the (non-merged) EVMS project).
Comments (3 posted)
Tempting as it may be to pass over the final judgement in the Microsoft
case as not being of interest to Linux users, the truth of the matter is
that there are a couple of things worth saying. Even though this
settlement looks an awful lot like "business as usual."
Free software advocates had hoped, for a while, that the settlement would
at least require the opening of formats and protocols. Imagine the great
things the Samba team could do if it had to spend less time reverse
engineering everything. In the end, the final settlement offers nothing of
value in this regard. Consider:
- Microsoft is required to license its protocols under RAND
terms. These terms involve license fees, of course, and are thus
quite discriminatory against free software.
- Microsoft does not have to license to companies which have a
"history of software counterfeiting or piracy or willful
violation of intellectual property rights." Potential
licensees also have to convince Microsoft of the "authenticity and
viability" of their business, and submit their code to Microsoft for
The most interesting provision with regard to licensing, though, may well
be this one:
No provision of this Final Judgment shall... Require Microsoft to
document, disclose or license to third parties: (a) portions of
APIs or Documentation or portions or layers of Communications
Protocols the disclosure of which would compromise the security of
a particular installation or group of installations of anti-piracy,
anti-virus, software licensing, digital rights management,
encryption or authentication systems, including without limitation,
keys, authorization tokens or enforcement criteria; or (b) any API,
interface or other information related to any Microsoft product if
lawfully directed not to do so by a governmental agency of
As has been pointed out by others, the "security" argument could be used to
lock up just about anything that Microsoft does not want to release. And
why, exactly, does the U.S. government reserve to itself the right to
suppress the release of API and protocol information? One assumes that
somebody has something in mind here.
After five years, the entire settlement goes away.
The bottom line is that this decree is not going to help the free software
community to any great extent. But, then, it never really was going to.
Attacking Microsoft is not a useful goal for the free software community;
our purpose is to create and distribute the best free software we can.
And, for those who wish to
see Microsoft in discomfort, it is worth noting that free software has
already caused the company much worry. Microsoft's planned takeover of the
server space has been thwarted, and the company's grip on other computing
markets, while still firm, just does not look as invulnerable as it once
did. Editors, compilers, and the free software development process may yet
prove to be the most effective weapon against software monopolies.
(See also: yet
another leaked Microsoft memo, duly marked up by Eric Raymond. This
one is a survey of opinions toward Linux. "Closing, those who are
familiar with OSS and Linux are favorably predisposed towards them. Linking
this work with other on-point research, we can assume that in the majority
of cases this reported 'favorability' is more emotional than it is
Comments (6 posted)
It's time for the weekly "report from LWN" column. Read on for the latest
subscription information, the new search engine, gift certificates, and
As of this writing, there are just under 2300 individual LWN subscribers.
In recent times, that number has been growing by about 100 per week - not
quite what we might really like, but enough to keep us reasonably happy if
it continues. Making it continue could prove challenging, however. A
number of subscribers signed up for only one or two months, and those
subscriptions are beginning to expire. Unless those subscriptions get
renewed (hint, hint...), we could conceivably start going backwards.
Here's to hoping that doesn't happen.
One way to help keep that from happening would be to shower your friends
with LWN gift
certificates. It's a great way to support LWN and, simultaneously,
deal with your holiday shopping problems.
We have sold about twenty group subscriptions, including a couple of
reasonably large ones. Next week, perhaps, we'll publicly thank the
companies which wish to be acknowledged in this way.
Meanwhile, LWN once again has a search engine. It
has the basic features one would expect, including the ability to filter on
category and content type. It is indexed as content is generated, so
search results always include the newest content.
For now, only the new site (i.e. content back to last June) is covered; we're
still figuring out what the best solution is for all of our older content.
We may, as one reader suggested, simply put in a link to Google...
That's pretty much it for this week. Thanks to all of you, again, for
Comments (19 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Security support for Debian Potato; new vulnerabilities in linuxconf, log2mail, luxman, moxilla, MailTools
- Kernel: Orlov block allocation; Hot and cold pages; initramfs; EVMS
- Distributions: Eagle Linux, DeLi Linux, and uOS.
- Development: Open POSIX Test Suite, SAP DB 7.3.00.29, Metawall 0.12,
AFPL Ghostscript 7.32 beta, HPIJS 1.3,
Tkeca 1.0.0, Sweep 0.5.10a, KDE 3.1 RC2, wall of video,
GStreamer 0.4.2 , Gnumeric 1.1.11, GnuPG 1.2.1, TinyCOBOL 0.59,
- Press: The Microsoft Verdict, Europe's Microsoft Alternative,
SchoolNet rebuffs M$, Red Hat road tour, Simputer
handheld for developing world, Yahoo switches to PHP,
Linux Lunacy II cruise.
- Announcements: Linux Adoption Growing in China, Netcraft Web Server Survey,
LPI News, Linux Gazette, OLS CFP, Red Hat Roadtrip in LA,
- Letters: Lack of letters; LAMP distro; the need for ACLs