Reading through the lengthy debate on the lkml titled "silent semantic changes with reiser4" [story] is a time investment. Comprised of well over 500 emails and growing, I include here a tiny snippet containing a discussion primarily between Hans Reiser, Andrew Morton [interview], and Linus Torvalds. Questions raised include whether or not the filesystem should be ultimately merged into the mainline kernel, and if so how to go about this. Much of the debate is regarding extensions that are currently only available through reiser4, and perhaps not fully compatible with existing utilities. The thread within begins with some coments by Andrew, who suggests that if the provided feature set is the desired direction for the Linux kernel, his preference would be to "accept the reiser4-only extensions with a view to turning them into kernel-wide extensions at some time in the future, so all filesystems will offer the extensions (as much as possible)".

As quoted earlier [story], Hans stressed that it was important that the reiser4 functionality be merged so that Linux is capable of competing with WinFS and Spotlight. The argument was continued by others, and to these followup comments Linus retorted:

"Hell will freeze over before Microsoft does a filesystem right. Besides, WinFS is likely almost in user mode anyway, ie mostly a library, rather like the gnome people are already doing with gnome storage. So there's really no point in trying to push your agenda by trying to scare people with MS activities. Linux kernel developers do what's right because it is _right_, not because somebody else does it."

A recent disagreement on the linux-usb-devel mailing list ultimately led to the removal of the Philips webcam driver known as 'pwc'. The driver contains two modules, an open source module that has long been part of the mainline Linux kernel, and a closed source module which ships separately. Craig Rogers explained on the lkml that the closed source module ships in object format and "provides decompression services for proprietary codecs that are used for higher-resolution modes in some Web cameras based on this chip family." A hook in the open-source module allows the compression module to register with the kernel.

The actual disagreement was from the removal of this hook which was only used by the closed source module. Greg KH explained, "see
Linus's comments about 'if a change is needed to be made to the kernel in order to get a closed source module to work, that module must be made opensource' or something close to that." In response, the pwc maintainer requested that his GPL'd code be removed from the kernel, explaining why here in his own words. Greg KH offers his own explanation here.

Separate from the above debate around the removal of the hook, following the request for the driver's removal by its author it was pointed out that the driver is GPL'd, so the source code should legally be able to stay in the kernel regarldess of its author's requests. Linux creator Linus Torvalds replied, "yes and no. From a legal standpoint you're right. However, we should also be polite. If he's the sole author, and he asks for it, I think it's reasonable to honor his wishes. Of course if some new maintainer shows up and decides to infer how the device worked by looking at the original open-source code, that's also clearly fine. I don't want people to play lawyer. Honoring peoples rights to the code they write is more important than just the law."

An interesting thread on the lkml began when Greg KH submitted a patch for the 2.6 kernel saying, "Ok, to test out the new development model, here's a nice patch that simply removes the devfs code." This was quickly followed with a comment by Oliver Neukum who said, "may I point out that 2.6 is supposed to be a _stable_ series?" In one branch of the thread, the usefulness of devfs was examined.

In another thread, discussion was focused on this "new development model". Jonathan Corbet explained that Linus Torvalds and Andrew Morton [interview] were very happy with the results of their recent teamwork, and saw no immediate pressure to fork a 2.7 development branch. On the contrary, they intend to keep at it as they've been, with things first going into Andrew's -mm patchset [story] for testing, then eventually being merged into the mainline 2.6 kernel. Jonathan went on to explain, "Andrew stated his willingness to consider, for example, four-level page tables, MODULE_PARM removal, API changes, and more. 2.7 will only be created when it becomes clear that there are sufficient patches which are truly disruptive enough to require it. When 2.7 *is* created, it could be highly experimental, and may turn out to be a throwaway tree." And he summarized:

"Andrew's vision, as expressed at the summit, is that the mainline kernel will be the fastest and most feature-rich kernel around, but not, necessarily, the most stable. Final stabilization is to be done by distributors (as happens now, really), but the distributors are expected to merge their patches quickly."

Linus Torvalds released the 2.6.7-rc3 release candidate kernel which
contains a few cleanups. He notes:

"Ok, let's calm down for a while before the final 2.6.7.

-rc3 does a lot of sparse type cleanup, mainly thanks to Al Viro (but his
work ended up getting some other people involved too, since the list of
sparse warnings isn't as daunting any more). Some of that has unearthed
real bugs which Al fixed.

But there are DRM, AGP, cpufreq, sparc64, and input updates there too."

Read on for the full changelog.

Linux creator Linus Torvalds began a recent email, "this is a request for discussion.." describing a method of tracking how patches find their way into the Linux kernel. The incentive for this change in process was made clear:

"Some of you may have heard of this crazy company called SCO (aka "Smoking Crack Organization") who seem to have a hard time believing that open source works better than their five engineers do. They've apparently made a couple of outlandish claims about where our source code comes from, including claiming to own code that was clearly written by me over a decade ago."

He notes that though people have proven to be quite good at debunking these claims, the effort has been tedious. "So, to avoid these kinds of issues ten years from now, I'm suggesting that we put in more of a process to explicitly document not only where a patch comes from (which we do actually already document pretty well in the changelogs), but the path it came through." Read on for Linus' complete description of how this process would work.

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++."

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."

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?"

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.

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.

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."