Robert Love's [interview] O_STREAMING patch (a patch to optimize read-once, streaming I/O) has made it into Andrew Morton's [interview] -mm tree.

O_STREAMING is a flag you can use with open(), which explicitly tells the kernel not to keep a cache of the file, by dropping pages from the pagecache before the current index. O_STREAMING is suited when you want to read large files sequentially, and when you know you'll read them only once.

Other recent additions to -mm are kgdb, shpte [story] and John Levon's [interview] latest 2.5 oprofile.

Michael Steil, a member of the Xbox Linux Project development team, recently posted a question to the lkml looking for hints on how they should prepare their patches in the hopes of getting them merged into the main kernel tree. Michael explains, "As you might already know, we successfully run standard distributions on ("modded") Microsoft Xbox gaming consoles with only minimal kernel changes."

Alan Cox [interview] replied to many of Michael's questions. Regarding whether or not the Xbox patches stand a chance of being merged, Alan offered, "Probably. I suspect the primary questions are political/lawyer ones rather than technical ones. Things like the IDE drive password are touchy obviously but that can be done from an initrd loaded with the kernel I guess."

The Xbox is Microsoft's gaming console, IBM-PC-based hardware that runs a stripped-down version of the Windows 2000 kernel which only allows games to run. The Xbox Linux Project makes it possible to fully utilizie the Xbox hardware, running a complete Linux distribution. "Xbox Linux Mandrake 9" was released October 7th. According to the project home page linked above, "An Xbox running Linux is very useful as a desktop computer, as a (web) server or as a node in a Linux cluster."

The likelyhood of pagetable sharing in 2.6 rose dramatically as Andrew Morton, the neighbourhoold VM IO system god integrated Dave McCracken's impementation into his mm patchset which can be found here.

Many gave some contribution to this feature in various threads, notably Daniel Phillips, who came up with the first implementation (which had a few locking problems) and all agreed it would be a very good idea if the implementation's locking was acceptable. The main benefits are increased fork speed and reduced memory (ZONE_NORMAL) consumption which is a critical problem for some big workloads. Unfortunately the reverse mapping system introduced into 2.5 made both attributes significantly worse despite the best efforts of numerous talented kernel hackers! There were not a lot of numbers being thrown around on the list, so I took the time to do some of my own...

Roman Zipple has uploaded version 0.8 of his LinuxKernelConf configuration system, aimed at replacing the aging CML1 [story]. With this release, Linux creator and 2.5 development kernel maintainer Linus Torvalds provided a little feedback, offering the impression that Roman's work could possibly be merged in the upcoming weeks. He does warn, "I'm not super-excited about this, partly because of the brouhaha last time around on this issue." [story] Specifically, Linus mentioned that he was worried about the reaction to the new xconfig interface, which depends upon the QT library.

The resulting discussion was refreshingly on track, with several solutions proposed. When asked what's wrong with the existing xconfig interface, which is based on the TCL/TK toolkit, Linus answered, "Too ugly. I actually think QT is a fine choice, I just suspect that it's going to cause political issues." Fortunately, Roman has designed his new configuration system in such a way that the subsystem could be distributed with the kernel, and the graphical configuration portions could be offered separately. The standard text-based interfaces, such as "make config" and "make menuconfig", do not appear changed to the end user. Once the backend library is finished, it seems likely that CML1 will finally be replaced with something better.

Rik van Riel [interview] and Robert Love [interview], among others, have been hacking on the RedHat procps package, a collection of common system tools including ps, top, vmstat, free, kill, sysctl and uptime. Rik says, "After a long period of inactivity procps maintenance is active again and suggestions, bugreports and patches are always welcome on the procps list."

An earlier thread on the lkml debating whether to call the upcoming stable kernel 2.6 or 3.0 [story] evolved into several other sub-discussions. One such discussion was looking at the state of the Linux desktop, and the issue of the kernel readahead implementation was brought in. Andrew Morton [interview] pointed out that by going into the function ext2_new_inode() and replacing the call to find_group_dir() with find_group_other(), full disk bandwidth can be achieved.

Why then has this not been done? To find out, read on for the full discussion between Andrew Morton, Danial Phillips, Linus Torvalds, Alan Cox and Theodore Ts'o. Towards the end of the thread, Andrew sheds some light on the specific questions asked by Chris Friesen, "What's the difference between find_group_dir and find_group_other, and why aren't we using find_group_other already if its so much faster?"

In response to the recent BKL debate [story], Rik van Riel [interview] has expanded his kernel source archives, making the latest 2.4 and 2.5 kernel source trees available via rsynch. Larry McVoy [interview] has explained that BitKeeper was designed with SCCS compatability in mind for this very purpose, so the source archives can be accessed with other tools, such as GNU CSSC (requiring a small patch, explained within).

Rik points out that this makes it possible for those actively developing and/or using an alternative source control system to access the latest kernel tree, saying, "If you (for random values of 'you') want to put the Linux kernel source in another source control system and/or you develop another source control system, you won't need bitkeeper in order to do so ..." All the same, Rik uses and enjoys BitKeeper himself, adding, "I won't be holding my breath for a better tool than bitkeeper, though ... it'll probably be quite a while for the other source control tools to come close to the functionality I'm using on a daily basis ;)"

Andrew Morton [interview] has merged Peter Chubb's [interview] 64-bit sector_t patches [story] into his memory managment tree. In regards to Peter's patches, Andrew added, "These are working fine and are a 2.6 must-have, IMO."

Andrew's full changelog for -mm2, the current release, is (as always) informative and interesting to read. It provides a blow by blow look into his efforts, much of which in the past has been merged into the 2.5 development tree [story].

There have been numerous flame wars and discussions on the lkml regarding the use of BitKeeper in Linux kernel development [story] [story] [story] [story] [story]. During one of these earlier wars, Linux creator Linus Torvalds explained his position, "Would I prefer to use a tool that didn't have any restrictions on it for kernel maintenance? Yes. But since no such tool exists, and since I'm personally not very interested in writing one, _and_ since I don't have any hangups about using the right tool for the job, I use BitKeeper."

BitKeeper is a source management tool provided under any of three licenses, one of which - the BKL - can make BitKeeper available for free (as in free beer). Tom Gall posted a question to the lkml when he noticed a clause in the BKL intended to prevent an individual or organization from using BitKeeper under this free license if they or their employer develops, produces, sells or resells a competing product. Yet another lengthy discussion followed.

Some contributers to this discussion seem to overlook two simple facts: First, that BitKeeper is also available under commercial (non-free) licensing, and second, that BitKeeper is and always has been primarily a commercial product (hence the sarcastic title of this article). Granted, the wording of any legal verbiage is open to interpretation, but as BitMover founder Larry McVoy [interview] has publicly interpreted this clause as "if you make or sell a competing product, you don't get to use ours for free", there seems little risk it can be used to attain other ends. In any case, for now Linus and many other Linux kernel developers have chosen to utilize BitKeeper in their efforts, and it is still possible to view the latest code (within 3 hours) without using BitKeeper via archives such as this one set up by Rik van Riel [interview].

That said, there are many interesting points raised during this discussion. Read on for the full thread...

Update (October 6 @ 9am EST): Hourly snapshots of the latest 2.5 development tree can also be found here on ftp.kernel.org. Linus sarcastically summarized complaints, "Big boo-hoo, bitkeeper is evil, and Linus doesn't manually do any more what BK plus a few scripts does better for us automatically."

No, I am not hallucinating. Yesterday, Alan Cox [interview] released his first 2.5 -ac kernel, 2.5.40-ac1. Among other things, this new branch includes Alan's work on the aacraid scsi driver, support for the NCR Voyager architecture, and ucLinux (a patch to run linux without a MMU (Memory Management Unit).

With release v2.5.40 today of the Linux development kernel, Linus Torvalds reminded the Linux development community that there is a kernel development freeze on October 31'st. Linus added that he will be away the last week of the month, so the last day for new features really is October 20th, "unless you've got a really good and scary costume". In a cheery threat, he also pointed out that he's perfectly happy with the features already introduced in 2.5, so the closer to the deadline submissions come the less likely he will be compelled to merge them.

In the same email he addressed a comment to non-kernel developers:

"And if it wasn't clear to the non-2.5-development people out there, yes you _should_ also test this code out even before the freeze. The IDE layer shouldn't be all that scary any more, and while there are still silly things like trivially non-compiling setups etc, it's generally a good idea to try things out as widely as possible before it's getting too late to complain about things.."

After nearly 2 months without any new -dj releases, Dave Jones [interview] finally put out a new -dj kernel, 2.5.39-dj1. The previous -dj kernel was 2.5.30-dj1. The long hiatus was caused by a lot of reasons (travel, work, etc.), and besides that, he had to catch up with the huge backlog of pending patches, syncing with Linus' tree, and with the 2.4 forward-porting work. Dave is now using BitKeeper, though, which helped speed up the merge work.

The last few -dj releases had mainly been "merge points" so kernel developers could have an idea of the status of the -dj tree; many did not boot; and it is unclear whether 2.5.39-dj1 boots. According to the changelog, this one is the first bootable -dj kernel since 2.5.27-dj1; but in his diary he states that "It fell on its face at the first hurdle (booting)."

A recent lkml thread explored an interesting tangent when Jeff Garzik asked about what was to follow the 2.5 development kernel, "is it definitely to be named 2.6? Maybe it's just my impression from development speed, but it felt more like a 3.0 to me :)". Linux creator Linus Torvalds first suggested that there was no reason to skip from 2.5 to 3.0, qualifying it with, "But hey, it's just a number. I don't feel that strongly either way."

Ingo Molnar reflected on the significant improvements we've seen to the VM and the IO subsystem, going so far as to say, "I think due to these improvements if we dont call the next kernel 3.0 then probably no Linux kernel in the future will deserve a major number. In 2-4 years we'll only jump to 3.0 because there's no better number available after 2.8."

Linus agreed that if the VM is as good as it seems to be, indeed the upcoming release deserves to be called 3.0. But he also pointed out that there are many silent users who tend not to speak up until there is an official release. He asks, "people who are having VM trouble with the current 2.5.x series, please _complain_, and tell what your workload is. Don't sit silent and make us think we're good to go.. And if Ingo is right, I'll do the 3.0.x thing."

Ingo Molnar's vcache code, part of his ongoing futex work, has been merged into the 2.5.39 development kernel. It implements "a 'mapping change' notification for virtual lookup caches, and makes the futex code use that to keep the futex page pinning consistent across copy-on-write events in the VM space." Ingo further explains, "this also enables us to avoid taking the vcache_lock in the COW fastpath, so the overhead should be pretty low, unless there are futexes in the given hash-list, in which case we obviously have to take the vcache_lock."

Read on for the full explanation in a conversation between Ingo and Linus Torvalds...

Until recently, the standard method of resolving an "oops", translating symbols into useful data for debugging the Linux kernel, involved the use of a user-space program called "ksymoops". Ingo Molnar recently presented a patch for 'kksymoops', an in-kernel version that has since been merged into the main 2.5 BK repository.

Kksymoops has been around for a while, in several forms. The original work was done by Keith Owens [interview], called kallsyms and was used to extract non-stack symbols from a kernel. Arjan van de Ven expanded upon this work, extending it to the area of kernel oopsing and stack trace printing, at which point it became the kksymoops patch for the 2.4 kernel. Ingo Molnar took this patch and ported it to the 2.5 kernel, adding some minor fixes. Finally, Kai Germaschewski (who has been working on fixing the kbuild system [story]) improved kksymoops significantly, rewriting much of the patch.

This will hopefully help improve the quality of kernel bug reports, as it provides a more convenient way to decode oops information than ksymoops (see Documentation/oops-tracing.txt), and it uses the full symbol table, not just the module symbols.