Paul Schroeder posted a one-line Makefile patch to allow kernel builds to look for headers in their source directory when /usr/src/linux was not present. Peter Samuelson pointed out that Paul probably had some dangling symlinks at /usr/include/linux and /usr/include/asm; he added that those symlinks used to be standard, but that Linus Torvalds and the glibc maintainers had at some point agreed to copy the headers instead of link to them.

Paul argued that whether one copied the directories or just linked them, this behavior was broken. He pointed out that having to alter the directory structure to compile two different kernel versions was awful, and compiling two versions at the same time was impossible given the current situation. Peter replied that on the one hand, it wasn't actually necessary to alter the directory structure just to compile multiple kernels: he never changed those directories to point to the current sources, and had never had a problem; and on the other hand, Paul's Makefile change depended on 'gcc', which made it less portable. He added that he had written his own patch at http://peter.cadcamlab.org/linux/, which addressed this portability issue as well.

There followed a somewhat heated discussion on the pros and cons of the symlink issue. It involved a number of big hackers, and would have been a flame war if folks had not still been charred from the last symlink debate.

For more on the issue of portable makefiles, see Article 7 in this Issue.

Alex Kamalov asked how ext3 was coming along, and Stephen C. Tweedie replied, ext3 is working nicely, but I still have a few things I want to implement for it before the first really widespread release. Yes it has jfs capability, and announcements of the test releases are made on the linux-fsdevel mailing list.

Shawn Leas asked if ext3 would support btree metadata. Stephen deferred to Theodore Y. Ts'o, who replied, I've been hosed lately due to conference travel, and other issues (LSB, e2fsprogs releases, serial driver). I'm hoping to have some time to work on it more come December; I don't have an ETA for the Btree functionality at this point.

Tim Walberg noticed that with 2.2.13ac2, his hardware clock seemed to have stopped ticking. His system clock was fine, but he was also getting some "lost interrupts" logged to /var/log/messages, along with "set_rtc_mmss: can't update from 52 to 3" repeated many times with different numbers. He found that Running 'hwclock --systohc' would succeed in adjusting his hardware clock to reflect system time; but even so, the hardware clock still refused to advance.

Andrea Arcangeli suspected that the problem had something to do with 'xntpd', and suggested disabling that daemon. Tim confirmed that he'd been using 'xntpd' to keep his clock accurate, and confirmed also that disabling it cured the problem. On his own, Tim also noticed that compiling the kernel without 'rtc' (Real Time Clock) support also alleviated the problem. One solution he proposed for himself was to keep 'rtc' disabled and use cron to run 'hwclock --systohc' periodically. However, Andrea pointed out that this wouldn't be necessary, as the kernel would flush system time to the hardware clock at regular intervals on its own.

Mike A. Harris pointed out that the reiserfs license was at least badly worded, and possibly incompatible with the GPL. Here's the wording of the license:

Reiserfs is hereby licensed according to the Gnu Public License, but with the following special terms: you may not integrate it into any kernel (or if not added to a kernel, into any software system) which is not also a GPL kernel (software system) without obtaining from Hans Reiser an exception to this license.

Along with that exception you will probably also obtain support and customization services, all of it for a fee. In the event that you (or a court) do not accept this interpretation of the GPL, you may choose to not use Reiserfs. I (Hans Reiser) retain all rights to license it as I desire in ways other than this license.

Note that it is the policy of Namesys to license its software on reasonable terms which are in accord with the antitrust laws. While one might argue that the GPL violates the antitrust laws, you should contact us and I believe you will find that we are willing to license in accord with those laws.

Mike pointed out that the "GNU Public License" was not legally the same as the "GNU General Public License". He added that if Hans had in fact meant the GPL (as he thought likely), the possible exceptions to the license mentioned in the first paragraph were prohibited by the GPL.

Mike felt that the reiserfs license was ambiguous and should be cleaned up, but stressed that he had no objection to Hans releasing his work under whatever license he chose.

Rob Landley agreed that the license was ambiguous, and gave a pointer to a "copyright FAQ" from usenet, last updated in 1994. He added that he didn't see any conflict with the GPL if Hans meant what Rob thought he meant. According to Rob, Hans was releasing his code under the GPL, but was also offering to release it under other licenses as well, something he as the copyright holder had every right to do.

Mike agreed with Rob's interpretation, and reiterated that he just wanted to see the wording cleaned up. He concluded, I don't want to see someone sideswipe the licence due to bad wording and perhaps steal the code. It is important that we correct or point out licencing errors like this when we find them, so that they can be fixed, and can protect software the way the author truely intended

Matthew Kirkwood replied to Hans' original email, with:

Mike argued that Matthew's interpretation proved the ambiguity of the license, and reiterated that the language should be cleaned up to avoid so many possible interpretations. Alan Cox agreed that the wording should be cleaned up.

Elsewhere, Jeff V. Merkey replied to Mike's original email, with, My attorneys have reviewed this license and they tell me that this means that the ReiserFS is ***NOT*** open sourced. Using it with this restriction makes any commercial vendors who want to ship it liable for damages claims, since the act of shipping it means they will integrate it with an OS.

Gregory Maxwell flamed Jeff for spreading FUD, and made other accusations for which he later apologized.

Mike reiterated the need for clarification from Hans, and David Schwartz agreed with the general interpretation that it's distributed under the GPL, and he's willing to sell exceptions to allow it to be integrated with proprietary kernels.

Jamie Lokier added:

As of Kernel Traffic publication time, the reiserfs license reads:

ReiserFS is hereby licensed under the GNU General Public License version 2. Please see the file "COPYING" which should have accompanied this software distribution for details of that license.

Since that license (particularly 2.b) is necessarily vague in certain areas due to its generality, the following interpretations shall govern. Some may consider these terms to be a supplemental license to the GPL. You may include ReiserFS in a Linux kernel which you may then include with anything, and you may even include it with a Linux kernel with non-GPL'd kernel modules. You may include it in any kernel which is wholly GPL'd including its kernel modules which you may then include with anything. If you wish to use it for a kernel which you sell usage or copying licenses for, which is not listed above, then you must obtain an additional license. If you wish to integrate it with any other software system which is not GPL'd, without integrating it into an operating system kernel, then you must obtain an additional license. This is an interpretation of what is and is not part of the software program falling under the GPL section 2.b., and is intended as a specification of (with a slight supplement to), not an exception to, the GPL as applied to this particular piece of software.

Further licensing options are available for commercial and/or other interests directly from Hans Reiser: reiser@idiom.com. If you interpret the GPL as not allowing those additional licensing options, you read it wrongly, when carefully read you can see that those restrictions on additional terms do not apply to the owner of the copyright, and my interpretation of this shall govern for this license.

It was pointed out that the latest stable kernels break StarOffice (or rather the Java tool StarOffice depended on). Andrea Arcangeli asked Alan Cox to back out of the stable tree the (purely semantic) patch that had caused the breakage. Alan replied, Its a broken application, it opens a file that does not exist. Now it gets an error indicating a file does not exist. Getting a valid handle is a bug in my book. If it bugs you emacs their binary and change the format string.

Andrea argued that although the old kernel behavior was not nice, there was no actual bug, and so reverting the code to fix StarOffice would not be so bad. Alan replied:

Juergen Kreileder replied regarding the Java tool, I've fixed the problem several weeks ago, the new JDK will be released in a couple of days.

Elsewhere, Alexander Viro was incensed at StarOffice for coding so poorly, and trying to access a nonexistent file in the /proc directory. He shouted:

Andrea pointed out that the problem was only with accessing the nonexistant /proc file, not with sprintf(). He pointed out that allowing the quirk in 2.2.x would make no difference to anyone but StarOffice users. The kernel developers could fix the problem in 2.3, and the old 2.2 kernel would eventually die off. He explained, Fixing it will make you more happy in spirit, it will hurt users and won't help you in real life. I sure understand that the change is been a good thing for 2.2.13 and I _never_ complained about it at that time. But now that we did the sad discovery we could choose to return back to the behaviour. I agree it's a very minor issue but I still can't see any downsides in putting back the undocumented quirk in 2.2.x.

Alexander replied that this would only defer the StarOffice breakage until 2.4, when the same issue would come up again. He wanted to avoid the dangerous precedent of altering the kernel to support a binary-only application.

Elsewhere, under the Subject: StarOffice 5.1a problem, Dmitri Pogosian argued that StarOffice was a crucial program for many users, and that this should be taken into account by the kernel developers. Changing the kernel in such a way as to break StarOffice was a very serious thing, he argued, and should not be done lightly. He suggested that at the very least, when the kernel broke a piece of software, that software's vendor should be contacted and told about the problem. Phil Wilshire agreed completely, but Mike A. Harris said:

James Turinsky was getting internal compiler errors while trying to compile 2.3.26 with 'pgcc1.1.2'; Alan Cox replied, This is a pgcc error. pgcc is an offshoot of the "official" gnu compilers and definitely has some problems with the kernel. Marc Lehmann followed up with, An internal compiler error is _always_ a bug in the compiler. You do not really need to know this, but if that happens again you now know whom to blame ;) He added:

James Simmons rewrote the fbcon Makefile to handle different kinds of monitors. Dominik Kubla was impressed, but felt the patch contained too many "GNU-isms". He added:

But Jeff Garzik replied that restricting Makefiles to POSIX compliancy would make them larger and much more difficult to maintain, and would also not really add portability, because the rest of the kernel was so dependant on the GNU tools already. He added, If you really want portable Makefiles, we need to go to an automake-like system which generates true, POSIX-portable Makefiles from Makefile.am meta-makefiles.

Enrico Weigelt suggested that the kernel sources were getting too large (10 megs and growing), and proposed splitting it into 4 parts:

• a base system, for makefiles, include files, etc.
• the main kernel
• architecture-dependant code
• device drivers (split into many small packages)

Matthew Wilcox pointed him to question 7 in section 7 of the linux-kernel FAQ, which dealt with exactly that issue; Dominik Kubla suggested just downloading the patch files to get the sources up to whatever version he wanted, and Peter Samuelson pointed out that this was why splitting the kernel wouldn't work: trying to apply a full patch to an incomplete kernel was likely to break.

Elsewhere, Richard Gooch got frustrated by the entire discussion, saying, Could we kindly drop this subject? Every time some luser raises this subject, we get a chorus of "me too" responses, plus a bunch of "it won't happen" responses from those who know the routine. People, this is getting very annoying. This has got to be one of the most useless and futile repeat threads on this list. He added, Linus publishes the official kernel. He does what's convenient for *him*. No amount of whinging will ever make him change to a system that is less convenient to *him*. Live with it. He went on:

Rik van Riel put in for good measure: