A recent thread on the lkml discussed a blog entry stating that minimal ZFS support for GRUB was available under the GPL license, "we could now use that code to implement support for ZFS in the Linux kernel." Alan Cox explained, "no we can't. The GPL ZFS bits don't include the various methods that would violate the patent so there is no grant. I've several times asked Sun to simply give permission and they don't even answer. I can only read the Sun motivation one way - they want to look open but know that ZFS is about the only thing that might save Solaris as a product in the data centre so are not truly prepared to let Linus use it." H. Peter Anvin added, "from what I can see, it is an absolutely-minimal read only implementation."

Christoph Hellwig offered, "adding a read-only for the start zfs driver for Linux would be useful for various purposes. And adding read-only filesystems to Linux is really easy." Referring to the individual who started the discussion, he added, "if Fred really cares about it I'd be very happy to mentor him implementing it. It should be a very good learning exercise for him." When asked if this offer applied to anyone else, Christoph replied, "yes, this offer is of course up to everyone interested. But it's not purely an integration effort in the traditional sense, the grub filesystem interface is quite different from the Linux one, and the code structure and style is quite different. But if you're willing to learn it should be very interesting."

"Can we please finish up this merge a little more before we freeze 2.6.24? The way we currently have leftovers of arch/i386/ and arch/x86_64/ is quite a nightmare and not how the other architectures were merged," Christoph Hellwig asked, leading to an insightful reply by Ingo Molnar. Ingo began by noting, "to answer that question one should first be aware of the fundamental code quality problems that the unified x86 architecture has inherited from the split i386 and x86_64 architectures." He then utilized the checkpatch script to generate a table of "coding style errors per one thousand lines of source code". In his table, arch/i386/ rated 77.3 errors per thousand lines of source, with arch/x86_64/ rating 96.0. The new unified arch/x86/ rated a lower but still very high 74.1. He summarized, "it is plainly obvious that the x86_64 and i386 architectures were in a dreadful state of code quality before the unification. Their code quality was almost an order of magnitude worse than that of the core kernel (!) - and their code quality was significantly worse than that of a couple of other, comparable architectures." Ingo continued:

"So to answer your question: full unification is no easy task and it is not automatic at all. The x86_64 tree has diverged from the i386 tree in the past 5 years due to their illogical, forced separation and a resulting bitrot. The two architectures have grown different sets of cleanliness problems and different sets of functions with arbitrary differences that often cover the same functionality. It's all compounded by the fact that the 64-bit code is in worse shape than the 32-bit - so it's not like we could just pick the 64-bit code and use that as the unified code. The 32-bit code is also used about 8-10 times more frequently than the 64-bit code. So there is no easy 'just unify it' path."

When the same patchset arrived on the Linux Kernel mailing list from multiple sources, Christoph Hellwig asked, "any reason we've got this patchset posted by three people now? :)" Andrew Morton retorted, "presumably because I haven't been merging it." He went on to explain:

"I was in bugfix-only mode from a week prior to 2.6.24 release and during the merge window. Partly caused by the already-idiotic amount of stuff we had queued for 2.6.24, partly because we needed to concentrate on stabilising the 2.6.25 patchpile rather than writing new stuff.

"And partly to send the signal that rather than beavering away on new features all the time, we should also be spending some (more) time testing, reviewing and bugfixing the current and soon-to-be-current code. Probably I should have been more explicit about it, but it wasn't really planned. Next time I'll send more 'thanks, I parked this for consideration at a more appropriate time' emails."

"This feature allows a read-only view into a read-write filesystem. In the process of doing that, it also provides infrastructure for keeping track of the number of writers to any given mount," Dave Hansen began, describing his "read-only bind mounts" patches. He continued, "this has a number of uses. It allows chroots to have parts of filesystems writable. It will be useful for containers in the future because users may have root inside a container, but should not be allowed to write to some filesystems. This also replaces patches that vserver has had out of the tree for several years. It allows security enhancements by making sure that parts of your filesystem [are] read-only (such as when you don't trust your FTP server), when you don't want to have entire new filesystems mounted, or when you want atime selectively updated."

Christoph Hellwig was interested in seeing the patches get some more testing, "I still think we really want this in -mm. As we've seen at the kernel summit there's a pretty desperate need for it." Andrew Morton noted that the "unprivileged mounts" code was working in the same area, but described that work as "a bit stuck." He suggested, "it sounds like a better approach would be for me to merge the r/o bind mounts code and to drop (or maybe rework) the unprivileged mounts patches." Dave explained that they don't collide much, to which Andrew's reply suggested that the read-only mount patches would be merged into the -mm kernel soon.

In a recent series of patches posted to the Linux Kernel mailing list, it was proposed that some imported Atheros wireless device drivers be re-licensed, some from a dual-BSD/GPL license, others from a modified BSD license, all to a pure GPLv2 license. Christoph Hellwig asked, "is this really a good idea? Most of the reverse-engineering was done by the OpenBSD folks, and it would certainly be helpful to work together with them on new hardware revisions, etc.." Luis Rodriguez suggested that there was no choice, "technically the best we can do is to leave the license as dual licensed, but keep in that technically that means nothing and is just for show, the GPL is what would apply as its derivative work and is the most restrictive license."

The patch series was also discussed on OpenBSD's -misc mailing list where it was asked, "is Reyk [Floeter] and others working on this drivers code dual licensed (from the diff it doesn't seem like it is, since I see a BSD 3 Clause)? Also say I submit a patch for this driver, does that mean this will have to be dual licensed also or can I choose if it is BSD 3 Clause or GPLv2?" Theo de Raadt replied pointing out that there are two parts to the driver, one part written by Reyk Floeter, and another part written by Sam Leffler, "Reyk's code is *NOT* dual-licensed under the GPL. He has explicitly stated that his code is not dual-licenced. The file have no GPL on them. He's the author, he said so. None else can add a GPL to it." He went on to note that the files written by Sam Leffler are dual licensed with the clause, "alternatively, this software may be distributed under the terms of the GNU General Public License ("GPL") version 2 as published by the Free Software Foundation," stressing that 'alternatively' means 'or', "that means that if anyone makes changes to that file and distributes it, after their changes are in the file then EITHER license will apply."

Hans Reiser [interview] sent an email to the lkml titled, "I request inclusion of reiser4 in the mainline kernel". He provided a list of objections raised earlier, noting that all had been addressed. Among the listed issues, Reiser4 now works with 4k stacks. "There have been no bug reports concerning the new code," Hans added.

The request was followed with some suggestions by Christoph Hellwig, including general comments about the coding style. This was one of many issues that led to debate in which Hans commented, "most of my customers remark that Namesys code is head and shoulders above the rest of the kernel code. So yes, it is different." Alan Cox [interview] replied that while the kernel coding style isn't his own style, he tries to follow it when working on the kernel, "one big reason we jump up and down so much about the coding style is that its the one thing that ensures someone else can maintain and fix code that the author has abandoned, doesn't have time to fix or that needs access to specific hardware the authors may not have." Much of the rest of the thread was less friendly, leaving the question of merging Reiser4 into the mainline kernel still up in the air.