Date:	Mon, 15 Jun 1998 23:49:40 -0700 (PDT)
From:	Linus Torvalds <torvalds@transmeta.com>
To:	"David S. Miller" <davem@dm.cobaltmicro.com>
Subject: Re: OFFTOPIC: e2fsprogs and +2Gb partitions



On Mon, 15 Jun 1998, David S. Miller wrote:
>
> He was sent patches which did whatever was necessary to make for a
> totally clean namespace in all kernel headers, and the response was
> "no way".

Indeed. 

I don't care if glibc-devel wants it some specific way, because I don't
know how many people run libc-0.9.5.4.1 or whatever, and quite frankly I
don't consider it worth the aggravation any more to even try to make the
kernel headers be acceptable to every libc release since several years
ago. 

The only way I see of not having to carry the baggage of several hundred
library releases and having to worry about source-level backwards
compatibility is to not play ball any more. The "nicer" I am to libc
developers wrt header file cleanup, the more I dig myself into a hole. 

In short, I'd prefer being _intentionally_ rude to people to make them not
want to use the kernel header files, than to have to know that 5 years
from now when people are using libc-17.9, then people will still worry
about whether the kernel header files work together with their old
libraries. 

In short, I want to sever the connection. These days I see absolutely _no_
point in requireing kernel sources to be available in order to do
user-level development. I think that any setup that requires some kernel
source to be installed in order for people to compile "hello world" is
broken beyond belief. 

I know I started the thing myself, and I'm guilty as charged. I did the
initial gcc setup, and I stupidly thought it would be a good idea to have
the symlinks from /usr/include/linux/ to the kernel sources. I learnt my
lesson. I got burnt. I'm not going to get burnt again. 

That particular braindamage resulted in lots of problems for package
distributors (RedHat and others used to have a separate "kernel header
files" package, and you had to install either that or the complete kernel
sources in order to be able to compile anything at all - and then there
were horrible problems if you later on decided you really wanted the other
one etc etc). 

The only sane thing is for the library to import the kernel header files
by copying them and munging them _privately_ to whatever they need. No
dependencies between the two. No symlinks, and no patches to the kernel
because the "library release of the day" wants to have certain types in
certain header files, but not other types. 

		Linus


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu