Re: New course for Debian University
On the question of /usr/src/linux & symlinks, Linus sent a couple
of messages to linux-kernel a few months ago ...
Brian Keck
------- Forwarded Messages
>From owner-linux-kernel-outgoing@vger.rutgers.edu Thu Jul 27 17:49:26 2000
X-Authentication-Warning: palladium.transmeta.com: mail set sender to news@transmeta.com using -f
To: linux-kernel@vger.rutgers.edu
From: torvalds@transmeta.com (Linus Torvalds)
Subject: Re: RLIM_INFINITY inconsistency between archs
Date: 27 Jul 2000 00:39:51 -0700
Organization: Transmeta Corporation
Message-Id: <8lop07$2ee$1@penguin.transmeta.com>
References: <Pine.LNX.4.02.10007270811460.32194-101000@prins.externet.hu>
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
Content-Length: 4299
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 advantaged 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,
>neither the above small program use 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 redhat 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/
------- Message 2
>From owner-linux-kernel-outgoing@vger.rutgers.edu Fri Jul 28 16:07:19 2000
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Date: Thu, 27 Jul 2000 08:30:08 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: linux-kernel@vger.rutgers.edu
Subject: Re: RLIM_INFINITY inconsistency between archs
Message-Id: <Pine.LNX.4.10.10007270819400.2768-100000@penguin.transmeta.com>
Mime-Version: 1.0
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
Content-Length: 2655
On Thu, 27 Jul 2000, Theodore Y. Ts'o wrote:
>
> May I suggest one slight change to this list? /usr/src/linux should be
> a symlink to the header files of whatever kernel is being booted by
> default. So you can compile your own kernel in your own home directory,
> but when you install your own kernel as the default boot kernel,
> /usr/src/linux should point to the header files of that kernel. As you
> say, it requres root to _install_ your own kernel, and that point, you
> can point /usr/src/linux at the appropriate place.
No.
It still means that the kernel header files would have to be source-level
backwards compatible forever. Something which hasn't been true in the
past, and I don't want to be true in the future either. It's been damn
painful to not be able to clean stuff up because some user-level setup is
wrong.
> The problem is that unless you are trying to say that you want to outlaw
> external source packages which generate kernel modules, there needs to
> be some way for such packages to be able to find the kernel header
> files.
Yes. By hand. By the maintainer. And _independently_ of what random user
Joe Blow has on his particular installation.
Because it's not unreasonable AT ALL to have those packages be compiled
with newer header files than the user even has access to. Imagine a ext2
library that wants to support new features of the filesystem, compiled on
a box that only has 2.2.13 installed. Neve rever had anything newer.
Should that newer source package dumb itself down to 2.2.13 level, so that
the e2fsck doesn't know how to handle new filesystems? Sure, the user
obviously isn't using them _now_, but wouldn't it be a lot nicer if you
just had a source tree that ended up generating the same binary that you
as the maintainer has? With all the new features, just suppressed by the
fact that it ends up running on a old-style filesystem image..
Trust me, it's STUPID to have user-level binaries that end up different
depending on what machine they were compiled on. We've had exactly that
happen, and it's a BUG. It's nasty to debug.
Think about it. You have machine X and machine Y, and they both have the
ext2-programs compiled with the same compiler from the same sources with
the same libraries. Would you _really_ consider it acceptable if they act
differently?
I don't. And that is why I will continue to maintain that it is WRONG to
have that symlink. No ifs, buts of other crap. Just face reality.
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/
------- End of Forwarded Messages
Reply to: