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.

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.

This HowTo was written for users who don't know how to install NVidia and/or VMWare modules with the 2.6 Linux kernel [forum]

If you're currently running the 2.4 Linux kernel [forum] and are interested in upgrading to the new 2.6 Linux kernel then you might want to read KernelTrap's 'How To Upgrade To The 2.6 Kernel' [story].
When I wrote this guide I was using the 2.6.0-test11-wli-2 kernel [story] [howto].

This HOWTO comes with no guarantees, use at your own risk.

Note: I'm not fond of binary-only drivers myself, but some Linux users are forced to use binary drivers (myself included). This HowTo is here for users that are forced to use NVidia or VMWare, so please _don't_ start a flamewar about this.

William Lee Irwin III [interview], from here on referred to simply as 'wli', has been maintaining a patchset against the 2.5 development kernel for some time. His announcement for 2.6.0-test11-wli-2 [story] caught my attention, so I decided to give it a try. Scroll down to the end of this article for a step-by-step guide walking you through how to apply the -wli patchset and compile your new kernel.

Curious to know more about wli's efforts, I dropped him an email with a few questions. His in-depth replies, included within, are quite insightful and informative. He explains the history behind this patchset, provides an overview of some of the improvements it contains, evaluates its stability, and talks a little about where he's going with it. Regarding the patchset, he explains, "one of the primary goals is to improve performance", adding, "there is a secondary goal of improving resource scalability and another of improving resource accounting."

On a cautionary note, some drivers and possibly some filesystems may have problems with a reduced kernel stack, so the 4K_STACK configuration option may be best left disabled, though read wli's comments within to determine if this affects you. Additionaly, wli explains that the -wli patchset is incompatible with smbfs and ncpfs due to removal of d_validate(), another change explained within. Finally, wli warns against using his patchset with binary-only graphics drivers, commenting that they seem, "utterly unable to cope with the changes I've made". None of these warnings applied to my personal desktop server which booted the -wli-2 kernel without problems. I'm happily testing it now as I write this article.

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.

Linux creator Linus Torvalds has released the linux 2.6.0-test5 kernel, with the following comments:

"Lots of small stuff, as usual. I think the biggest "core" change is the Futex changes by Jamie and Hugh, and the dev_t preparations by Al Viro. But there are ARM and ppc updates here too, and a few drivers have bigger fixes (tg3 driver and the USB gadget interface stand out on diffstat). Watchdog driver updates etc. And Russell King fixed more PCMCIA issues."

Read on for the full changelog.

Additionally, if you followed my recent upgrade howto [story], are running a 2.6.0-test kernel, and are interested in upgrading to 2.6.0-test5, read on for a few simple tips on upgrading with incremental patches.

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.

Nick Piggin, a college student living in Canberra Australia, has been working on an anticipatory I/O scheduler for the Linux kernel [story].

When a process reads data from a disk, the default "deadline" I/O scheduler can offer poor performance if a streamed write is happening at the same time. The reason is that many read operations require multiple reads, each reporting a result back before the next can be scheduled. Thus, each of these reads has to wait behind a queue of writes, resulting in the aforementioned performance problem. The anticipatory scheduler solves this problem nicely by pausing for a few milliseconds after each read, "anticipating" the next read request [story].

In this interview, Nick offers much more detail behind the operation of the anticipatory scheduler. His goal is to stablize and tune [story] the new scheduler, aiming utimately for inclusion into the 2.5 development kernel tree as the default Linux I/O scheduler [story]. The latest version of Nick's anticipatory scheduler can be found here in Andrew Morton's [interview] -mm kernel branch.

The upcoming release of OpenBSD 3.3 on May 1'st will include, among many other improvements, a notably enhanced version of PF, OpenBSD's stateful packet filter. Some of the more significant enhancements to PF include: 'queues', allowing for per-rule bandwidth control [story]; 'pool options', allowing one to utilize multiple uplinks and to intelligently redirect traffic to multiple servers; 'anchors', which allow one to divide packet filtering rule lists into logical pieces; 'tables', efficiently allowing for very large lists; and other parser improvements that make an already friendly syntax more human readable.

PF replaced its predecessor, IPF, with the release of OpenBSD 3.0 in December of 2001. Since that time, this impressive and relatively new packet filter has grown a faithful following (myself included), and continues to evolve rapidly with each new OpenBSD release. Perhaps the greatest compliment, developers have begun to port PF to other operating systems. Back in January, Joel Wilsson announced his effort to port PF to NetBSD. And more recently, Pyun YongHyeon announced his port for FreeBSD.

I approached Pyun to learn more about his recent porting efforts. In the following article he explains why he began working on this port, and what FreeBSD users can expect from the project. Additionally, I spoke with PF creator Daniel Hartmeier [interview], PF developer Henning Brauer, and OpenBSD creator Theo de Raadt [interview]. They all reflect on these recent porting efforts, as well as the exciting new features found in OpenBSD's PF.

This week, KernelTrap has been honored by an exclusive interview with the elusive kernel hacker, Renaldo Esp. Living adjacent to the largest contiguous wilderness area on this planet, Renaldo describes himself as a "Wilderness Alaskan".

"Renaldo has had a profound impact upon the face of kernel hacking, though with his typical modesty he expresses his surprise that we've taken notice. He offers insights into a number of current events in the open source world, including with Linux, *BSD and the GNU/Hurd. From questions in licensing, to the BitKeeper drama, to the name GNU/Linux, to the timeless issue of flossing after hacking... It's all here.

William Lee Irwin III [interview] recently announced on the lkml that he'd successfully gotten Linux running on a 64GB x86 server. His posts included two different boot message logs, one without his page clustering patch, and one with. In the latter case, his patch overcomes the 1GB mem_map virtual space limitation imposed by x86 32-bit servers, without which the kernel over-runs allowable memory space.

Bill's current efforts are based upon Hugh Dicken's earlier page clustering patches for the 2.4.x kernel. Hugh's efforts were actually focused on allowing larger filesystem block sizes, prompting Bill to say, "The fact it resolves the horror of mem_map[] overrunning kernel virtualspace on i386 PAE is really an obscure coincidence." His patch is still a work in progress, but with time will offer a number of additional benefits beyond the support of 64GB x86 servers. For example, utilizing the entire software page in fault handlers results in prefaulting benefits, and increasing the physical contiguity of data results in I/O throughput benefits. However, at this time "until it is done it will have severe performance problems on small memory machines (say, less than 16GB)."

I approached Bill, asking questions to better understand what he was working toward. He replied with a wealth of information, including several ASCII diagrams and lengthy explanations. To summarize, he offered:

"Without pgcl, 64GB is a doorstop, because in /proc/meminfo LowTotal: was a mere 176MB and so incapable of supporting any significant loads. With pgcl, 64GB functions quite nicely, because LowTotal is 750MB and has room for all the kernel bloat that should be there (but things that shouldn't still need to be fixed)."

For the complete details, read on.

In late November of 2002, OpenBSD creator Theo de Raadt [interview] announced on the project's mailing lists that after over a year of attempting to obtain useful

Ingo Molnar has been contributing to Linux kernel development since 1995 with an impressive list of accomplishments. Most recently his O(1) scheduler was merged into the 2.5 development kernel, as well as much work to enhance the handling of threads. Other highly visible contributions include software-RAID support and the in-kernel Tux web and FTP servers.

In this interview, Ingo explores how he started working on the Linux kernel noting, "it might sound a bit strange but i installed my first Linux box for the sole purpose of looking at the kernel source." He goes on to explain the concepts behind his new O(1) scheduler, and to describe many of his other kernel efforts. This interview was conducted over several months, and covers a lot of interesting ground...

Rusty Russell's new module loader was recently merged into Linus' 2.5 kernel tree [story]. This new implementation aims to cleanup and reduce the amount of code in the kernel and user space required to load a kernel module. Additionally, it now removes the requirement that kernel and user space code for modutils have to be in sync.