The latest version of kernel traffic is up. Including a disscusion of the 2.5 VM and a status update for kbuild 2.5.

The WOLK project has for some time provided a "Working Overloaded Linux [2.4] Kernel", that is, one with an abundance of interesting patches applied. The result, though fun to play with have been labeled as "development kernels and for testing purpose only".

Project lead Marc-Christian Petersen recently announced a new patchset, this one for the 2.2 kernel. The current patch applies against the recently released 2.2.21 kernel [earlier story]. For a full listing of patches included, read on. This release was followed with the standard WOLK tag, "Want to see a patch included to this tree? Let me know! :-)".

The latest Kernel Traffic is out containing a few bits on VM and IDE code and the current cleanup going on there. Other items of interest include discussion of kbuild and the merging of the next generation. No BitKeeper flamewars in evidence :-)

Tim Schmielau posted a patch that (finally?) fixes the ugly 497-day uptime problem, with minimal cruft. It seems like a pretty trivial patch (mainly dealing with types).

In a recent posting to the lkml, M. Edward Borasky asked on the current status of the 2.4 kernel's virtual memory system. He points out, "A few months ago, there was a flurry of reports from people having difficulties with memory management on large machines (ia32 over 4 GB). I've seen a lot of 2.4.x-yy kernels go by and much VM discussion, but what I'm *not* seeing is reports of either catastrophic behavior or its absence on large machines."

The resulting thread is an interesting read. William Lee Irwin III replied, "The catastrophic failures are still happening, in fact, the last lse-tech conference call a week or two ago was dedicated at least in part to them." He goes on to credit Andrea Arcangeli with the most visible efforts to fix problems in this arena. (Try Andrea's -aa kernel patch to see his latest work)

The thread includes input from many, including Rik van Riel, Alan Cox, Andrea Arcangeli and Linus Torvalds. Much of the thread follows.

LinuxWorld recently posted an article by Richard Stallman (RMS) titled, Linux, GNU, and freedom. It begins as a reply to an earlier article by Joe Barr (The Stallman factor), explaining an incident with the SIGLINUX user group. RMS continues on to talk about the reason why the name 'GNU/Linux' is important, the influence Linus has, and his decision to utilize the BitKeeper tool.

Read on for more information, including a full mirror of the article.

Alan Cox released the final Linux 2.2.21 stable kernel today. This release added only one patch to the earlier 2.2.21-rc4 [earlier story] with the comment, "Add 32/64bit ioctl handling for random driver".

Linus released the Linux development kernel 2.5.17 last night. He summarized the changes in two sentences, "Various FS updates (including merges of quota and iget_locked), and Makefile cleanups from Kai. And yet more TLB shootdown stuff."

This release includes the new and improved changelog format []earlier story]. It combines some of the verbosity of BitKeeper changelogs with the readability of the old style kernel changelogs. Those watching the development kernel evolve will notice that Linus has been good to his word, releasing new kernels with increasing rapidity. Browse the latest development kernels on kernel.org.

The fourth annual Ottawa Linux Symposium will be happening on June 26th-29th in Ottawa, Canada. Dr. Stephen Tweedie of ext3 fame will be a keynote speaker. The website offers an impressive list of speakers, as well as numerous 'Bird of a Feather Sessions'.

Larry McVoy, the creator of BitKeeper, has also been invited, and offered to lead a discussion on the reason for BitKeeper's unique licensing. Richard Gooch, also speaking at the 2002 OLS, has urged him to speak, as Larry says, "I explained our reasons for why it is the way it is and he urged me to show up and explain it to a wider audience, I apparently explained things that weren't well known. I'm happy to do that, you can bring tomatoes :)".

I have spoken with Larry myself, and found his reasons to be quite sound. You can show up in Ottawa next month and decide for yourself.

Keith Owens recently announced for the third time that kbuild 2.5 is ready for inclusion into the Linux 2.5 development kernel tree [earlier story]. Keith says, "Third and final attempt. Original sent on May 2, second mail sent on May 14, still no response from Linus." He goes on to explain, "I would like kbuild 2.5 to go in in the near future. Keeping up to date with kernel changes is a significant effort, Makefiles change all the time, especially when major subsystems like sound and usb are reorganised."

Many have offered support of the new build system. In the most recent thread, Robert Love said, "Fwiw, I like kbuild-2.5 and want it in." Dave Jones summarized his own support saying, "If kbuild2.5 is faster, and produces the same end result (or better still, more accurate builds), there's no valid reason to ignore it that I can see."

However, so far its seems that Linus has chosen to ignore Keith's emails. Perhaps there's something behind the scenes prompting this silence. Or perhaps it's just a matter of time.

When Linux creator Linus Torvalds began using the BitKeeper (BK) source control tool for managing the 2.5 Linux development kernel [earlier story], one of the big fears people put forward was that all Linux kernel developers would eventually be forced to use this tool. (The BK license is a major source of contention.

In late February we noted that the stable Linux kernel 2.2.21 could be expected around March 10th, 2002 [earlier story]. As it turns out, 2.2.21-rc4 was released today, about which Alan Cox says, "Unless something bad turns up this will be the final 2.2.21." There have been numerous fixes applied since late February. Details follow in Alan's changelog.

When Linus made his switch to BitKeeper for maintaining the kernel source tree, the format of his changelogs also changed. Linus himself at one point commented that simplifying the changelog was on his todo list, however many spoke out in support of the newer, more verbose logs. They have since been the standard. Find an example of the old style here, and the new style here.

The question of readability came up on the lkml recently, Ian Molton saying, "I dont know who to write to about this, but the changelogs for 2.4.19-pre on kernel.org are COMPLETELY illegible." He went on to suggest that the logs be tweaked a little. Linus agreed that the logs could be improved, and put out a call to Perl scripters to help with the change. Some of the discussion follows, as well as a link to the thread in online archives.

Story resurrected from old site archives by request:

Ever since interviewing Robert Love last October, I've added his preemptible kernel patch to all my running kernels, with great results. Ingo Molnar's recent O(1) scheduler has also looked attractive, but I've been waiting until it was compatible with Robert's patch before trying it. The wait is over.

This afternoon Robert announced the release of a O(1) scheduler compatible preemptible kernel patch for the stable 2.4 kernel tree and the 2.5 development kernel. He says,

"Getting the two to play together was not hard, albeit a bit of a pain. The actually scheduling support is less, due to the simplified schedule and schedule_tail, although there is added code for making the per-CPU runqueues preempt-safe."

What follows is Robert's announcement email, as well as Ingo's announcement of his -H6 version of the O(1) scheduler.

Peter Chubb posted a patch to the lkml, with which he's now managed to mount a 15 terabyte file (using JFS and the loopback device). Without the patch, Peter explains, "Linux is limited to 2TB filesystems even on 64-bit systems, because there are various places where the block offset on disc are assigned to unsigned or int 32-bit variables."

Peter works on the Gelato project in Australia. His efforts include cleaning up Linux's large filesystem support, removing 32-bit filesystem limitations. When I asked him about the new 64-bit filesystem limits, he offered a comprehensive answer and this interesting link. The full thread follows.

Reaching beyond terabytes, beyond petabytes, on into exabytes. I feel this sudden discontent with my meager 60 gigabyte hard drive...