Andrea Arcangeli is well known for having completely rewritten and stabilized the virtual memory subsystem in the 2.4 Linux kernel. Many were surprised when Linus Torvalds merged Andrea's VM into 2.4.10, but the new memory subsystem has long since proved itself. Andrea is a 27 year old Linux kernel hacker living in Italy and working for SUSE.

As RAM increasingly becomes a commodity, the prices drop and computer users are able to buy more. 32-bit archictectures face certain limitations in regards to accessing these growing amounts of RAM. To better understand the problem and the various solutions, we begin with an overview of Linux memory management. Understanding how basic memory management works, we are better able to define the problem, and finally to review the various solutions.

This article was written by examining the Linux 2.6 kernel source code for the x86 architecture types.

David Weinehall is the maintainer of the Linux 2.0 kernel. Alan Cox [interview] handed over maintainership of the 2.0 kernel over 4 years ago. David explains in his own words:

"In December 1999, a naughty bug that allowed any local user to crash a 2.0-machine surfaced. Alan Cox admitted that he didn't have any time left to work on the 2.0 kernel any longer, and told me that if I wanted to become maintainer for 2.0 and fix this bug (and some other bugs while at it), it was fine with him."

In this interview David talks about his past, and the things he's doing now.

A recent posting to the lkml requested help in porting the C++ Click Modular Router kernel module from the 2.4 stable kernel to the 2.6 stable kernel. The request was for ideas on fixing C++ related compilation errors, but the thread quickly turned into a lengthy debate on whether or not C++ had a place in the Linux kernel. The issue has been debated many times before, long ago earning its own entry in the lkml FAQ which offers numerous reasons why the kernel is not written in C++.

During the recent discussion, when it was suggested that perhaps the kernel is written in C simply because "we've always done it that way...", Linux creator Linus Torvalds joined in to explain:

"In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

"The fact is, C++ compilers are not trustworthy. They were even worse in
1992, but some fundamental facts haven't changed: 1) the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. 2) any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. 3) you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++."

A recent posting to the lkml suggested that the udev project has unfairly hijacked the devfs project, leading into yet another lengthy discussion comparing udev to devfs, and questioning why the latter has been deprecated. Linux devfs was written by Richard Gooch and merged into the 2.3.46 kernel in February of 2000. Since that time, Richard has stopped maintaining it, though a number of issues remain. During the 2.5 release cycle others such as Andrey Borzenkov have contributed fixes, though problems evidently remain with the actual design.

As early as 2001, Greg Kroah-Hartman began developing udev, working to implement the same functionality as devfs, but in userspace. Currently at version 010 [story], though not complete, udev is quite functional. For a good understanding of how it works, refer to this pdf from Greg's 2003 OLS talk. During the recent lkml discussion, 2.6 maintainer Andrew Morton acknowledged that though it has "architectural/cleanliness issues [...] devfs shall remain in 2.6 and shall continue to be supported." He went on to explain:

"Nor would I recommend that devfs be removed early from 2.7.x. We should wait until the proposed udev/sysfs solutions have matured in 2.6 and have proven themselves in the field. Only then will we be in a position to confirm that devfs can be removed without causing some people unacceptable levels of grief. There is no rush."

Marcelo Tosatti became the maintainer of the 2.4 stable kernel when he was 18 years old in November of 2001. His first kernel release was 2.4.16 on November 26'th which very quickly followed the earlier 2.4.15 to address an issue with filesystem corruption. Two years later, he has recently released 2.4.23 and plans to soon put the 2.4 stable kernel into maintenance mode, only addressing bugs and security issues.

Living in Brazil, Marcelo currently works for Cyclades Corporation. In this interview he looks at how he became the 2.4 maintainer, the challenges involved, and brings us up to date with the current status of the 2.4 kernel.

Linux creator Linus Torvalds posted to the lkml an explicit rebuttal of SCO's recent claims that certain specific files were stolen intellectual property. He begins, "I spent half an hour tearing part of it apart for some journalists. No guarantees for the full accuracy of this write-up, and in particular I don't actually have 'original UNIX' code to compare against, but the files I checked (ctype.[ch]) definitely do not have any UNIX history to them."

Linus' full explanation follows, as well as some other dicussion on the topic further refuting SCO's claims. Linus offers the following summary:

"In other words, I think we can totally _demolish_ the SCO claim that these 65 files were somehow 'copied'. They clearly are not. Which should come as no surprise to people. But I think it's nice to see just _how_ clearly we can show that SCO is - yet again - totally incorrect."

Rusty Russell [interview] recently posted an updated version of his "Unreliable Guide To Locking". The introduction begins:

"Welcome, to Rusty's Remarkably Unreliable Guide to Kernel Locking issues. This document describes the locking systems in the Linux Kernel in 2.6. With the wide availability of HyperThreading, and preemption in the Linux Kernel, everyone hacking on the kernel needs to know the fundamentals of concurrency and locking for SMP. "

Rusty's excellent guide is quite informative, helping the reader to grasp concurrency, explaining the common types of locks, providing useful examples, listing common problems, discussing locking speed, and much more. All in all, it's an essential reference.

Linux creator Linus Torvalds made the decision a year and a half ago on February 5, 2002 to use BitKeeper to manage the distributed development of the Linux kernel source tree. Over the course of the next year, this led to many lengthy flame wars on the lkml [story], though in recent months things have been mostly quiet on this front... until recently, when a couple of threads threatened to return to the fiery depths.

Fortunately, the threads have also led to some interesting comments by Linus. For example, he explains his incentive for improving the Linux kernel:

"I'm ok with other people using NT. When it's better for them, that's their choice. I work hard to make sure that the Linux kernel is technically superior, and if I feel it isn't I want to fix it. Because I do _not_ want people using Linux for religious reasons. I want people to use Linux because it is _better_ for them, [or] because they truly believe that they can make it so (or at least have fun trying)."

No matter which side of the debate you're on, the following emails are usually interesting, often rather humorous, and always brashly to the point. Toward the end of the thread, Linus sarcastically refers to earlier more topical threads, pleading, "Now can we get back to complaining about the scheduler behaviour and xmms? Please?"

Rusty Russell is a Linux kernel hacker living in Australia, working for IBM's Linux Technology Center. He's also a frequent and talented speaker at Linux gatherings. When talking about Rusty in an earlier interview, Andrew Morton summarized, "he's just a really sharp and witty guy - anyone who has attended one of his sessions at a conference will attest to that!"

Well known for his packet filtering efforts, having written both ipchains and netfilter/iptables, he has continued to make an impressive number of contributions to Linux kernel development. A large sampling of his current projects have been merged into the upcoming 2.6 kernel, including futexes, per-cpu counters, hot pluggable CPU support, and a complete rewrite of the in-kernel module loading code.

For a humorous sample of Rusty's wit, one only needs to look to his email signature which reads, "Anyone who quotes me in their sig is an idiot. -- Rusty Russell." Read on for the full interview.

In a couple of earlier articles, we walked through the process of upgrading to the 2.6.0-test4 kernel [story], and then using a small patch to upgrade to the 2.6.0-test5 kernel [story]. Today we'll continue our patching efforts to upgrade to an even faster feeling and more stable kernel with Andrew Morton's [interview] -mm patchset [forum].

Andrew Morton began releasing his -mm kernel patches a little over a year ago, in the summer of 2002. The -mm tree began as a 90k patch against the 2.5.17 development kernel, merging in the remote kernel debugger, kgdb. By the release of 2.5.18, the -mm patchset had grown to nearly 238k, merging in a wide assortment of fixes and new functionality. As of this writing, the current -mm patchset is 2.6.0-test5-mm3, weighing in at nearly 5 megabytes. Andrew's -mm tree has evolved from a testing ground for numerous new technologies, to a comprehensive patchset that is usually more stable than the mainline 2.6.0-test kernel itself. This bodes well for the future of the 2.6 kernel, as Andrew Morton will soon be the official 2.6 kernel maintainer.

There are numerous reasons you may desire trying Andrew's -mm kernel tree. Stability alone is a good incentive, and scanning the lengthy changelog you'll find a significant number of bug fixes that have been applied. I asked Andrew how the stability of his kernel compares to that of the mainline 2.6.0-test kernel, and he replied that though occasionally new bugs creep in, due to having the latest fixes the -mm tree is generally more stable and up-to-date.

Anyone who's been following Linux kernel development for the past several months has heard about one exciting feature after another being merged into the still un-released 2.6 kernel. New features that noticeably affect user experience include Robert Love's [interview] preemptible kernel work [story], Ingo Molnar's [interview] O(1) Scheduler [story], Rik Van Riel's [interview] reverse mapping VM [story], Nick Piggins' [interview] Anticipatory I/O scheduler [story], and much, much more...

Having some spare time a few nights ago, I decided to give the latest kernel, 2.6.0-test4, a trial run on my aging 550Mhz PIII desktop computer, and the result was nothing short of spectacular. As the final 2.6.0 release approaches, it is important that an increasing number of users (aka testers) give this kernel a try, especially as currently it's still a sexy task for developers to track down kernel bugs and stabalize their work. Once work starts on the 2.7 development tree, inevitably much talent will again be focusing on new features.

The purpose of this document is to provide some helpful tips to readers that currently compile their own 2.4 kernels, but haven't yet made the leap to 2.6. This is still a development kernel, so you may run into problems, but overall stability and performance is quite impressive and I can't recommend enough that you try it today.

Photographs of samples of Linux kernel code that SCO claims to be stolen have quickly circulated the web. The images can be viewed on the German language Heise Online [image 1] [image 2].

Links were posted to the lkml and a brief discussion followed. Those interested can find a much lengthier discussion