Christian Ludwig recently submitted a patch to the lkml to add bzip2 compression support into the kernel. The patch adds the option to use bzip2 compression for both the kernel image as well as for the ramdisk image (initrd), offering better compression than gzip at the expense of consuming more RAM during the boot time decompression process (8 MB versus 2 MB). The original bzip, a lossless data compressor, is unused in open source software due to patent restrictions. The newer and highly portable bzip2 uses the Burrows-Wheeler block-sorting text compression algorithm and Huffman coding, and is thought to be patent-free by its author, Julian Seward.

The existing 'make bzImage' command used when compiling a Linux kernel does not use bzip compression as one may suspect from the name. Instead, 'bzImage' stands for 'big zImage'. From the Linux kernel documentation (Documentation/kbuild/commands.txt), "the difference between 'zImage' files and 'bzImage' files is that 'bzImage' uses a different layout and a different loading algorithm, and thus has a larger capacity. Both files use gzip compression."

Christian's patch applies to the 2.4.18 kernel. It is a port and cleanup of an earlier patch by Tom Oehser for the 2.2 kernel series.

Update: 10/18/2003, discussion on LKML pointed to new location for bzip2 patches: http://shepard.kicks-ass.net/~cc/

Rik van Riel's kernel page [earlier interview] has a comment from July 5'th reading, "Linus has announced (on the kernel summit, two weeks ago) that he is interested in a minimal rmap patch to put into 2.5." Rik took the minimal rmap patch that Craig Kulesa posted [earlier story], ported it to the latest development kernel, performed further cleanup and with Andrew Morton [earlier interview] fixed numerous bugs.

The resulting effort got the following comment from Rik, "With some help from Andrew Morton the most obvious bugs should have been ironed out (people who know Andrew will recognise the understatement). You don't have to be that courageous to try out: 2.5.25-rmap-akpmtested..."

In response to the long standing instability with the 2.5 Linux development kernel's IDE layer, Jens Axboe provided a set of seven patches for 2.5.25, porting the IDE core from 2.4.19-pre10-ac2 to the 2.5 tree. Jens explains, "I needed stable IDE for 2.5 testing and it was/is clear that 2.5 just isn't quite there yet. I intend to maintain this patch set until I deem 2.5 IDE stable enough (in code) that I'm willing to spend time on that instead."

Jens' patches can be downloaded from his kernel.org directory (currently in 2.5.25) or pulled from his BK tree. The patches will be maintained until Martin Dalecki gets the 2.5 IDE layer stabalized. Read on for the full details, including a one line description of each of the seven patches.

A recent discussion on the lkml debated whether the 2.6 and 2.7 kernels should be released at the same time instead of first stabilizing the 2.6 "stable tree" then branching the 2.7 "development tree". The theory behind the proposition is to keep "new" things from going into 2.6 once it is released, focusing instead only on making it stable. On the flip side of this argument is the possibility that with a 2.7 kernel in development, there will be too little focus on stabilizing the 2.6 kernel.

The resulting debate makes for an interesting read. Much of the thread follows.

The Adeos nanokernel [earlier story] now offers symmetric multi-processor support. Karim Yaghmour made the announcement:

"While most of us were at the OLS, Philippe continued hacking on Adeos and has extended the functionality to include SMP support. In light of the discussions I had with many folks at the OLS (the K42 team, Larry, Paul and others), this is a positive step forward to having multiple Linux kernels running on the same hardware."

As explained here, "The purpose of Adeos is to provide a flexible environment for sharing hardware resources among multiple operating systems, or among multiple instances of a single OS." Or, as per the name, Adeos is an Adaptive Domain Environment for Operating Systems. Karim's full announcement follows.

Discussion about backporting the O(1) Scheduler to the 2.4 stable kernel [earlier story] continues on the lkml. Ingo Molnar, the scheduler's author, maintains that much more testing is required:

"it might be a candidate for inclusion once it has _proven_ stability and robustness (in terms of tester and developer exposion), on the same order of magnitude as the 2.4 kernel - but that needs time and exposure in trees like the -ac tree and vendor trees. It might not happen at all, during the lifetime of 2.4."

Joe Sloan was among those who countered Ingo's comments:

"Ingo, it's apparent you are refraining from pushing this O(1) scheduler - that's admirable, but don't swing too far in the other direction. The fact is, it's working well in 2.5, it's working well in the 2.4-ac tree, it's working well in the 2.4-aa tree, and Red Hat has been shipping it."

Personally, I've been using and enjoying the O(1) scheduler on my desktop server since January when it became compatible with preemptible kernel patch [earlier story]. The following discussion makes for an interesting read, with good points made on both sides.

Robert Love [earlier interview] submitted an updated version of his scheduler hints kernel patch [earlier story] to the lkml today. The updated patch offers only the Solaris-style "gimme timeslice" hint, as well as a voluntary fairness mechanism. Robert still describes the patch as being academic, "This is more a "does it actually show benefit" than a "we need more stuff in the kernel" patch". He cites around a 5% improvement with the latest patch.

He goes on to describe how fairness is implemented:

"Fairness is provided simply by another hint which tells the scheduler you are finished with your extra timeslice. The scheduler will calculate what your timeslice would of been had you not made the hint and set your new timeslice to that. If it is negative, you are put on the expired list. Thus the hint is more of a safety net to prevent preemption while holding a critical resource than a method to achieve arbitrarily long timeslices. This is what Solaris does."

Robert's full email and the patch follow.

Bill Davidsen pointed out on the lkml that many popular kernel trees have been using the O(1) scheduler [earlier story] for six months with no bad side affects. The subject line of his email asked the question, why not put the O(1) scheduler into the mainline 2.4 kernel tree?

Ingo Molnar, the scheduler's author, replied to the query:

"Well, the patch is barely 6 months old. A new scheduler changes the 'heart' of the kernel and something like that should not be done for the stable branch, especially since it has finally started to converge towards a state that can be called stable ..."

The O(1) scheduler is part of the 2.5 development tree, and thus will be in the future 2.6 stable tree.

Select universities dominating Computer Science competitions is nothing new. MIT, Stanford, and UC Berkley have been known as CS hotbeds for some time. Clarkson University, in upstate New York, began its bid to join the ranks of the elite when the results of the IBM Linux Scholar Challenge were annoucened. Students entered from all over the world, submitting improvements to some part of the linux kernel. Four students from Clarkson were among the 25 students who won IBM thinkpads for there effort. Only one other university [University of Karlsruhe] had multiple winners, with two winning entries.

Read on for some details of their winning entries and a story from the professor who lead the class.

Dave Hansen posted a patch to the lkml this morning, prefacing with the comment, "For those of you who heard the talk at OLS Friday morning, this patch won't be too much of a surprise. But for the rest of you..." He went on to describe an effort the patch would help in understanding how the big kernel lock (BKL) is used:

"The BKL's "magical" properties of allowing recursive holds on a single cpu and its release-on-sleep semantics make it really hard to replace with new locking schemes. Before we can really remove it, we must first characterize the places where it is used in these crazy ways."

His full email follows, further describing what he's found so far using the supplied patch. He also includes sample patches for the tty and ext3 code saying, "Don't take too much stock in these, they're just a demonstration and not nearly complete."

Rik van Riel [earlier interview] recently announced the decision to move the ever helpful #kernelnewbies IRC channel to a new network. He explained:

"Due to a possible incompatibility between one of the OPN admins soliciting money on a regular basis and the policies of the network where kernelnewbies.org is hosted we have decided to move the #kernelnewbies IRC channel to another network."

You can now find #kernelnewbies on irc.oftc.net. Rik describes kernelnewbies as "a project meant to help people learn about operating system development by providing information and operating a mailing list and IRC channel where current and future developers can help each other."

LWN has posted a report on the first day of the Ottawa Kernel Summit. They discussed a range of topics, from the AMD x86-64 port; to the absolution of modules; to the 2.5 VM (Linus says rmap will be in 2.5).

Jeremy adds: Also find LWN's excellent day two summary of the Kernel Summit. Among many other interesting conversations, Linus agreed to a feature freeze for the 2.5 kernel on October 31, 2002.

Linux kernel 2.4 maintainer Marcelo Tosatti announced the first release candidate for 2.4.19 today (2.4.19-rc1) from Ottawa, Canada. In his own words, "Directly from OLS you're getting the first release candidate. Please test it extensively." Matthias Andree followed with a changelog summary.

Shortly after Marcelo's release, Stelian Pop sent a patch for a lingering typo in 2.4.19-rc1 that affects anyone compiling "when one does not have a floppy device..." The patch fixes a typo in the file init/do_mounts.c, changing the incorrect "CONFIG_BLOCK_DEV_RAM" to "CONFIG_BLK_DEV_RAM". Without this fix, the function change_floppy() is ifdef'd out, resulting in the error "undefined reference to `change_floppy'".