James Ketrenos announced a new 80211 based driver for the Intel PRO/Wireless 3945ABG network connection adapter, "this new driver uses the new d80211 subsystem previously only available as part of the wireless-dev tree." An earlier incarnation of the driver code was much criticized for its inclusion of a userland binary-only daemon [story], prompting the OpenBSD project to create their own blob-free driver for the card [story]. "The [new] iwlwifi driver for the 3945 does not require the user space daemon, but does require a new microcode image," James explained, "over the past year we were able to make the necessary changes to the microcode used with the 3945 such that we were able to remove the regulatory daemon."
When the question was asked if the driver was going to be pushed for inclusion into the mainline kernel it was noted, "hmmm...I think we need to spend a cycle or so in -mm. 2.6.22 seems more likely for mainline." Pavel Roskin suggested, "iwlwifi is surprisingly good for a just announced driver. It worked for me from the first attempt, and that's the first d80211 driver to do so. In my opinion, it should go to wireless-dev as soon as possible so it can go to -mm together with other drivers."
Following the release of the 2.6.20 kernel [story] Andrew Morton [interview] posted a list of patches in his -mm kernel, summarizing for each his plans as to whether or not they will be pushed upstream for inclusion in the upcoming 2.6.21 kernel. Andrew commented, "I'm getting fed up of holding onto hundreds of patches against subsystem trees, sending them over and over again and seeing nothing happen. I sent 242 patches out to subsystem maintainers on Monday and look at what's still here." In response to some confusion as to what happens to these patches, he went on explain, "once a subsystem has a subsystem tree (git or quilt) I basically never merge anything which belongs to that tree. It's always originator->mm->subsystemtree->Linus".
With the release of the 2.6.19-rc1-mm1 kernel, the ext4 filesystem [story] was merged into Andrew Morton [interview]'s -mm tree for further testing. In the announcement Andrew notes that the new filesystem is compatible with ext3 until you add a file that has extents. He also notes, "when comparing performance with other filesystems, remember that ext3/4 by default offers higher data integrity guarantees than most. So when comparing with a metadata-only journalling filesystem, use `mount -o data=writeback'. (Although this doesn't seem to make much difference with ext3)" The goal is to stabilize the new filesystem within the next six to nine months, and ultimately to replace the ext3 filesystem.
With the release of the 2.6.18-rc3-mm1 kernel, Andrew Morton [interview] included a brief note stating, "fwiw, I recently took a position with Google." He then linked to a Linux Today article which details the reasons behind his recent move. The article begins, "Andrew Morton has started working for a new company, but his day job as the Linux 2.6 kernel maintainer will remain exactly the same." In the article, Andrew discusses one of the reasons Google was a good fit, "in my position as kernel maintainer I feel that I should not be employed by a company which has a direct interest in the kernel.org kernel because this would put me in a position of making decisions which are commercially significant to my employer's competitors. As Google maintains their own kernel variant for internal use, their interests are largely decoupled from what happens in the kernel.org kernel."
The question of if and when Reiser4 will be merged into the mainline Linux kernel has been an on-going debate for a couple of years [story]. The filesystem was described as being "fairly stable for average users" by Hans Reiser [interview] over two years ago, in March of 2004 [story]. It has been merged into Andrew Morton [interview]'s -mm kernel [story], though issues such as Reiser4 plugins [story] and coding style [story] caused lengthy discussions last year. Two recent threads on the lkml raised the question again, asking at a non-technical level why Reiser 4 has not been included in the Linux kernel. Some have offered theories that Reiser4 is being blocked for political reasons, others because of concerns that once Reiser4 is included Namesys might forget it and move onto another filesystem. Responses to these theories point out that in reality there are technical issues that must be resolved before the filesystem will be merged, and that much progress has been made toward this end. Additional discussion can be found on a relevant recently created kernel newbies wiki page.
Hans Reiser posted a "short term task list for Reiser4" to address the remaining technical issues. The todo list included getting batch_write merged into the -mm kernel [story], getting read optimization code merged into the -mm kernel, documenting everything in the Namesys wiki, exploring and addressing reports of system pauses when using Reiser4, a complete review of the crypt-compress code, a large effort in optimizing fsync, a review of installation instructions, and a review of the kernel documentation. Hans explains, "unfortunately, our code stability is going to decrease for a bit due to all these changes to the read and write code --- no way to cure that but passage of time. On the other hand, our CPU usage went way down. Reiser4's only performance weakness now is fsync. Once the crypt-compress code is ready, we will release Reiser4.1-beta (with plugins, releasing a beta means telling users that if they mount -o reiser4.1-beta then cryptcompress will be their default plugin, and if they don't, then they are using Reiser4.0 still). Doubling our performance and halving our disk usage is going to be fun."
Greg KH offered a short "kernel maintainer's HOWTO for quilt and -mm", offering instructions on how one can utilize quilt to create patchsets intended to be merged into Andrew Morton [interview]'s -mm tree [story]. He begins:
"So, You're a kernel maintainer faced with the fact that you are having people send you loads of patches, but don't know how to stage them in a fashion that others can see what you have and have not accepted. You also want to have them show up in the -mm releases and need to provide some hint as to the order in which they should be applied. This small document and script will provide one solution to this."
With the release of 2.6.9-mm1, Andrew Morton [interview] offered a quick status update on a number of patches in his -mm tree [forum] that are 2.6-mainline hopefuls. For example, regarding the much debated reiser4 filesystem [story], Andrew said that he is still "not sure, really. The namespace extensions were disabled, although all the code for that is still present. Linus's filesystem criterion used to be 'once lots of people are using it, preferably when vendors are shipping it'. That's a bit of a chicken and egg thing though. Needs more discussion". And as for Ingo Molnar [interview]'s preemption and low-latency fixups [forum] Andrew offered, "I haven't really thought about it and haven't looked at the patches yet. Hopefully 2.6.10 material."
Other projects specifically mentioned include the sysfs backing store, the ext3 reservations code, the ext3 resize code, kexec and crashdump [story], perfctr, cachefs, cpusets, and the md updates. Read on for Andrew's comments and the complete -mm1 changelog.
As expected, merging Resier4 into Andrew Morton [interview]'s -mm tree [story] brought with it a lot of additional features and semantic changes. Christoph Hellwig expressed some unhappiness over these semantic changes, spawning a lengthy thread on the lkml. Specifically, he mentioned that the handling of files-as-directories (multiple streams within files) could cause problems to user-space applications, and could cause other dcache problems.
A lot of opposition was expressed. Some mentioned that the handling of multiple streams is really a userspace issue, whereas others mentioned that legacy applications may not properly handle multiple streams which could lead to the loss of user data. This lead Hans Reiser to say in support:
"Andrew, we need to compete with WinFS and Dominic Giampaolo's filesystem for Apple, and that means we need to put search engine and database functionality into the filesystem."
With the release of 188.8.131.52-mm2, in addition to a probable fix for the memory leak some reported when writing audio CDs [story], Andrew Morton [interview] announced that the long awaited [story] Resier4 filesystem has been merged into his -mm patchset [story]. Hans Reiser provided some information about the history and usage of Reiser4, beginning:
"Reiser4 is a file system based on dancing tree algorithms, and is described at http://www.namesys.com. One should be able to get it up and running just like any of the other filesystems supported by Linux. Configure it to be compiled either builtin or as a module. Create reiser4 filesystem with mkfs.reiser4, mount and use it. More detailed info can be found at http://thebsh.namesys.com/snapshots/LATEST/READ.ME."
In question and answer format - questions from Andrew, answers from Hans - we go on to learn where to obtain the latest Reiser4 tools, and about the current limitations of the filesystem. Hans explains, "Reiser4 has [only] been tested on i386 [...]. Quota support is not ready yet. Should be ready soon. [...] Only the very core functionality is working. Exotic plugins, an API for multiple operation transactions and accessing multiple small files in one syscall, compression, inheritance, all have been postponed until after the core functionality is shipped." Read on for more information, including tips on benchmarking the new filesystem.
Andrew Morton [interview] has released 2.6.2-rc3-mm1, including a new debug patch to detect when a process calls i_size_write() without holding the inode's i_sem. Andrew explains, "It generates a warning and a stack backtrace. We know that XFS generates such a trace. It will turn itself off after the first ten warnings. Please don't report the XFS case." Also appearing in this kernel is Rusty Russell's CPU hotplug code, recently discussed on the lkml. It is pointed out that 2.6.2-rc3-mm1 is broken on the ppc64 architecture, "something to do with the sched-domains patch although at this stage we do not know whether the problem lies with that patch or with the ppc64 code."
The desire to merge reiser4 [story] into the -mm kernel was again raised. Andrew responded favorably enough, requesting the necessary patches and complete documentation. He does caution, "be aware that the barriers for a new filesystem are relatively high: each one adds a significant maintenance burden to the VFS and MM developers. It will need cautious review." This comment is evidently in reference to 2.6 inclusion, not -mm inclusion, as he goes on to add, "but that doesn't mean we cannot get it out there, get you some more testing and exposure."
A brief thread on the lkml discussed whether or not Reiser4 would soon be stable enough to be merged into the 2.6 kernel as an 'experimental filesystem'. When it was suggested that this might be overly optimistic, that the filesystem may best go into the 2.7 development kernel [forum] first, Hans Reiser disagreed, "I don't think it is vastly optimistic, I hope we can send something in next month". He went on to explain, "we will have something we think is appropriate for inclusion as an experimental feature very soon now. Because our test scripts have become much more sophisticated, it means more when we say we cannot crash it, and it will go from experimental to stable faster than V3 did. I won't predict how fast."
Jens Axboe, maintainer of the block layer and several CD-ROM drivers, suggested that it would be unwise to merge the code so quickly, instead preferring a much lengthier period of user testing. He explains, "I don't doubt you have great testing scripts, but nothing beats real life testing." During a discussion in late August [story], 2.6 kernel maintainer Andrew Morton [interview] indicated that he would be willing to merge Reiser4 into his -mm patchset [howto].
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.
Following Andrew Morton's [interview] recent posting of 2.6.0-test4-mm2 [forum], Christian Axelsson asked, "Is there any work [being] done on getting reiser4 into mm? I havent tried it myself yet but I've heard of colliding code in [the] scheduler". Andrew replied that a merging effort hasn't been made, but that he'd be interested in making it happen in a month or two so long as the namesys developers were willing to commit to providing him with up-to-date patches. Hans Reiser offered:
"We would be happy to make that commitment, and happy to switch from creating snapshots every week to pushing to you and linking to you from our website. Several people have asked for this besides Christian."
In other words, it looks like -mm users will soon have easy access to the resier4 filesystem.