Re: OFFTOPIC: e2fsprogs and +2Gb partitions
Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Tue, 16 Jun 1998 17:28:08 +1000
Linus Torvalds writes:
>
>
> 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.
Ted made a suggestion that was leading in a similar direction to what
I was thinking. The basic problem stems from future libc stealing
namespace (types/definitions/macros) that current kernels define,
right?
An extreme solution would be to have all types/macros/whatever in
kernel include files prefixed by "Kernel"/"KERNEL_" or something
similar. We in effect claim a namespace for eternity.
Now, this is clearly going to uglify the kernel code, so we don't want
that. But what we can do is put prefixed names in a special
"interface" tree. Then the *private* kernel includes include stuff
from this interface tree and redefine/rename (say using the
pre-processor) these names to something friendly to kernel
programmers.
Userspace is verboten from using the private kernel includes, instead
it uses the interface includes. Whether userspace does a similar
rename or uses the unadulterated names is of no concern to the kernel.
This solution has the advantage that magic constants and structures
are all kept in the one place, with no risk of duplication.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu