Kernel Traffic
Latest | Archives | People | Topics 		Wine
Latest | Archives | People | Topics 		GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Kernel Traffic #44 For 22 Nov 1999

By Zack Brown

Table Of Contents

Introduction

There won't be any KT next week because of the American holiday. I considered trying to write one anyway, but my dear friends Max and Maria are flying 3000 miles to be with me, and I'd like to spend as much time as possible with them, those silly Windows users. ;-)

Mailing List Stats For This Week

We looked at 1132 posts in 4656K.

There were 361 different contributors. 170 posted more than once. 130 posted last week too.

The top posters of the week were:

1. Controversy Over Symlinks To Header Files

4 Nov 1999 - 15 Nov 1999 (35 posts) Archive Link: "toplevel Makefile bug and simple fix"

People: Peter Samuelson, Linus Torvalds

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.

2. ext3 Status Report

8 Nov 1999 - 10 Nov 1999 (8 posts) Archive Link: "ReiserFS"

Topics: FS: ext3

People: Stephen C. Tweedie, Theodore Y. Ts'o, Shawn Leas

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

3. Real Time Clock Stoppage

8 Nov 1999 - 10 Nov 1999 (6 posts) Archive Link: "2.2.13 rtc problem"

People: Andrea Arcangeli

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.

4. Possible GPL Conflicts In Reiserfs License

8 Nov 1999 - 14 Nov 1999 (41 posts) Archive Link: "Reiserfs licencing - possible GPL conflict?"

Topics: BSD, FS: ReiserFS

People: Mike A. Harris, Matthew Kirkwood, Jeff V. Merkey, David Schwartz, Jamie Lokier, Alan Cox, Gregory Maxwell, Hans Reiser, Rob Landley

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:

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:

reiserfs is not under the GPL. It is under a licence slightly more restrictive than the GPL (one couldn't link it with a kernel under the free-BSD licence, or the MIT licence, where GPL software in general is compatible).

Actually, this has potential bad interactions with the kernel - if reiserfs is linked with the kernel then _as a whole_ the kernel's licence become more restrictive than the GPLs, and thus reiserfs can no longer be linked with it. I think that perhaps Hans, Linus and some lawyers could do to discuss this further.

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:

The poor phrasing is a real problem: it's not just important what Hans Reiser means. It's also important what redistributors of the software believe it means. If they believe it means they are permitted to do something that Hans intends they are not permitted to do, they might get away with it. Or they might get sued for using it in an entirely GPL-compatible way, but I hope we can rely on Hans not doing that.

I think the "may not be integrated with non-GPL software" clause is an additional restriction that is not permitted by the GPL itself. The net result is that the combined license is self-contradictory, and I believe there is some legal method for resolving contradictions in licenses, which may or may not nullify the "no additional restrictions" clause in the GPL part.

Thus it is possible that someone can take Hans Reiser's code and distribute it under non-GPL terms, contrary to his intention, because the self-contradictory license is nullified in precisely the part that protects the GPL terms on redistributions.

It is also possible that no-one is permitted to redistribute the code at all, except the author. Unless you can satisfy the terms of the GPL part of the license, you are not granted permission to redistribute. With the additional restriction, you do not have that permission. The author is exempt because he is permitted to slap on any license, even a self-contradictory one.

If the overall license is not compatible with the standard GPL, and I don't think it is, reiserfs as it stands cannot be incorporated into the standard kernel. If it is done anyway, and generally accepted by many of the authors, that would weaken the GPL's coverage of the entire kernel: we would be seen to be endorsing Linux kernel redistribution contrary to the "no additional restrictions" clause in the GPL.

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

5. Kernel Support For Binary-Only Programs

9 Nov 1999 - 12 Nov 1999 (24 posts) Archive Link: "Re: Kernel related StarOffice 5.1a problem"

Topics: Backward Compatibility, Microsoft, POSIX

People: Alan Cox, Juergen Kreileder, Alexander Viro, Andrea Arcangeli, Mike A. Harris

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:

We broke kppp with a security fix. Fixing readlink() broke a buggy glibc version. Fixing file opening broke a buggy java tool. It isnt like there are no other java engines. Whoever built the buggy jdk needs to build an unbuggy one. Someone at blackdown.org needs to type make.

The one I feel most sorry for is actually kppp. Both readlink() and open() have clear posix/SUS definitions. kppp got caught by a neccessary fix that is enshrined only in 'tradition'

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:

It tries to access WHAT? Bloody lusers cannot be bothered to use %d in sprintf? Sorry. /proc/<pid>/fd/0<whatever> _never_ had been a documented interface. They already were deep in it with (ab)using glibc guts. And it didn't teach them? They _deserve_ to lose. Who maintains StarrOrifice these days, SunSoft? Sheesh...

Andrea, I don't think that kernel should work around the bugs in _that_. Really. Backwards compatibility is nice, but preserving every undocumented quirk that nobody sane would use... Sorry, but we really need an addition to errno.h: EBITEME. Exactly for such cases.

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:

The developers of Linux care about the technical issues with Linux, and can't possibly track down 10000 software vendors and bug them. Bugs in Linux get FIXED. That is one major reason why I use Linux. We are not held back by kludges and backwards compatibility issues.

Microsoft Windows crashes so often - partly because of bugs that are in the code. They know about a lot of them or most of them, however if they fix them, then perhaps thousands of userland applications (commercial and otherwise) would break. This would cause people to either not upgrade, or to upgrade, and then upgrade their applications as well.

You can't have both. Do you want a stable OS, buggy apps, or buggy os, stable binary-only apps?

Linux development is focused on fixing bugs, and making things technically correct. At no time does Linus or any other top level core developer care about binary only module compatibility, or binary only software that relies on a bug in the kernel.

Thus Linux stays stable, and moves on.

Since Linux is GPL, and open source, it doesn't stop anyone at all from removing the "patch" that fixes a bug and breaks staroffice, and then redistributing the resulting kernel source.

So, you are free to upgrade your kernel source to the latest, patch it to be Star Office compatible, and then go on having a happy day. If Sun cares about fixing SO, then they will provide new binary upgrades on their site.

The day that the Linux kernel starts keeping bugs in so that broken or badly written commercial binary-only applications continue to function is the day that *I* stop using it.

Of course you can always try out other open-source replacements for Star-SLOWBLOATEDSTATICALLYLINKED-Office.

6. Linux Compiler Dependencies

10 Nov 1999 - 11 Nov 1999 (3 posts) Archive Link: "Linux kernel 2.3.26 build fails with internal compiler error."

People: Alan Cox, Marc Lehmann

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:

pgcc-1.1.2 is waay old, and, naturally, many bugs have been fixed in pgcc-2.95.2 (gove it a try ;).

I also do not really recommend compiling the kernel with pgcc. It makes your kernel bigger but not necessarily faster. The kernel is such a good case of software engineering that compiler code quality does not have a large effect on speed.

7. Discussion Of Makefile Portability

12 Nov 1999 - 14 Nov 1999 (15 posts) Archive Link: "[PATCH] new makefile for fbcon"

Topics: POSIX

People: Dominik Kubla, Jeff Garzik, James Simmons

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:

GNU make is not half as good as many people believe, so you won't gain overly much by using it's specialities.

Better to stick to the POSIX behaviour since this is not to change in between versions of make and allows people to use alternatives like pmake (which is better suited to distributed build environments btw.!)

I am well aware that the current kernel makefiles rely on GNUisms, but there is work being done (by myself and others) to present patches that allow the use of _ANY_ POSIX-compatible make utility being used.

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

8. Splitting The Kernel Source Into More Manageable Chunks

14 Nov 1999 (11 posts) Archive Link: "Split the kernel sources"

People: Richard Gooch, Rik van Riel, Alan Cox, Matthew Wilcox, Peter Samuelson, Dominik Kubla

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

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:

the FAQ indeed mentions the option of someone providing a splitting service. You may even get kernel.org to host and distribute it, so you don't have to worry about disc space. You just need someone to put in the effort.

But until someone puts in the effort to provide this service, everyone should shut up about this topic. Everything I have seen suggests that Linus is inclined to put *more* drivers into the kernel, rather than split things out. Repeat whinging is *NOT* going to change his mind.

And considering that people line Alan Cox and Dave aren't championing the cause of splitting, there's just no chance of it happening.

Rik van Riel put in for good measure:

You're free to go ahead with your plan and distribute splitted kernel trees. I'd even be willing to give you folks disk space and bandwidth for it.

However, I still think this would be a pointless excercise. Do you have any idea on how to split things up for distributing? Which files should be included with what kernel set, etc...?

If you think about it some more (off-list, please), then you'll shortly come to the conclusion that the whole idea is a can of worms you wish you'd have never opened.

I would still like to see you try it, though :)

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.