Subject: RLIM_INFINITY inconsistency between archs
From: Linus Torvalds (torvalds@transmeta.com)
To: linux-kernel@vger.rutgers.edu
Date: Thu Jul 27 2000 - 02:39:51 EST

In article Pine.LNX.4.02.10007270811460.32194-101000@prins.externet.hu, Boszormenyi Zoltan <zboszor@externet.hu> wrote:

> /usr/include/asm is a symlink to /usr/src/linux/include/asm, as in the
> original distribution but /usr/src/linux is a 2.4.0-testX tree. With
> a 2.2.X source tree, it does not produce any warning.

I've asked glibc maintainers to stop the symlink insanity for the last few years now, but it doesn't seem to happen.

Basically, that symlink should not be a symlink. It's a symlink for historical reasons, none of them very good any more (and haven't been for a long time), and it's a disaster unless you want to be a C library developer. Which not very many people want to be.

The fact is, that the header files should match the library you link against, not the kernel you run on.

Think about it a bit.. Imagine that the kernel introduces a new "struct X", and maintains binary backwards compatibility by having an old system call in the old place that gets passed a pointer to "struct old_X". It's all compatible, because binaries compiled for the old kernel will still continue to run — they'll use the same old interfaces they are still used to, and they obviously do not know about the new ones.

Now, if you start mixing a new kernel header file with an old binary "glibc", you get into trouble. The new kernel header file will use the new "struct X", because it will assume that anybody compiling against it is after the new-and-improved interfaces that the new kernel provides.

But then you link that program (with the new "struct X") to the binary library object archives that were compiled with the old header files, that use the old "struct old_X" (which used to be X), and that use the old system call entry-points that have the compatibility stuff to take "struct old_X".

Boom! Do you see the disconnect?

In short, the only people who should update their /usr/include/linux tree are the people who actually make library releases and compile their own glibc, because, if they want to take advantage of new kernel features, they need those new definitions. That way, there is never any conflict between the library and the headers, and you never get warnings like the above..

> Mr. Ulrich Drepper (one of the glibc/gcc guys) gave me a standard
> "don't use kernel headers directly" answer. But neither gcc.c nor
> the above small program uses kernel headers. I suppose he referred to
> /usr/include/linux/*, as (I think) he did not understand me.

No. He really meant that you should not use the kernel headers: You should use the headers that glibc came with. It is probably a Red Hat bug that those headers were a symbolic link.

I would suggest that people who compile new kernels should:

• NOT do so in /usr/src. Leave whatever kernel (probably only the header files) that the distribution came with there, but don't touch it.

• compile the kernel in their own home directory, as their very own selves. No need to be root to compile the kernel. You need to be root to install the kernel, but that's different.

• not have a single symbolic link in sight (except the one that the kernel build itself sets up, namely the "linux/include/asm" symlink that is only used for the internal kernel compile itself).

And yes, this is what I do. My /usr/src/linux still has the old 2.2.13 header files, even though I haven't run a 2.2.13 kernel in a loong time. But those headers were what glibc was compiled against, so those headers are what matches the library object files.

And this is actually what has been the suggested environment for at least the last five years. I don't know why the symlink business keeps on living on, like a bad zombie. Pretty much every distribution still has that broken symlink, and people still remember that the linux sources should go into "/usr/src/linux", even though that hasn't been true in a loong time.

Is there some documentation file that I've not updated, and that people are slavishly following outdated information in? I don't read the documentation myself, so I'd never notice ;)

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

[RM notes: Some distributions such as Red Hat Linux circa v. 8.0 have moved to ameliorate this situation by omitting the problematic symlink and no longer encouraging people to compile kernels in /usr/src/linux. Please also see extensive discussion by the Linux Gazette Answer Gang at http://linuxgazette.net/issue62/tag/4.html . My thanks to Conor D. Wynne for bring that follow-up analysis to my attention.]