Re: bcc dpmi ver1.2.0

R.L. Horn
2004-06-16T03:20:41Z

This is my absolute last word on the subject. Let's please drop it.

On Tue, 15 Jun 2004, Stas Sergeev wrote:

> What you said before was only "I don't run a distribution kernel...".

Maybe, but that's not what I meant. Call it a communication problem.

> "I don't use a distribution" - I don't think I understand what do you
> mean by that.

When I say I don't run a distribution, I mean exactly that. While the
systems I'm running were originally Red Hat 5.2, nothing remains of the
distribution apart from a few convenience scripts (and most of those have
been heavily modified).

> Apparently you haven't even looked into an URL I (and other people)
> pointed you to :(

I did. I even agree with Linus. The problem is that the "kernel" kernel
headers and the "glibc" kernel headers (as maintained by the libc
packagers) are different. Glibc doesn't provide "sanitized" headers for
every occasion (nor can they if it's to remain, more or less, platform
independent). With glibc 2.2.5, there are 22 libc headers that dip into
the kernel source. Version 2.3 may be different: I intend to get the
source and look into it.

The result of all of this is that the burden of fixing kernel headers,
which you have NO CHOICE but to use because libc uses them, has fallen
squarely on the shoulders of libc builders.

Ok, so I had /usr/include/linux symlinked into the 2.6.6 source tree. So
what? That glibc was built against the 2.6.6 headers (BTW, I pulled the
old glibc, which I built against 2.4, along with the appropriately
versioned kernel headers, out of cold storage...at least things work now).

> he himself doesn't want people to ever include the kernel headers

I'm not including the kernel headers, libc is including the kernel
headers.

> Now you say distributors are not bothering to tell the kernel guys?
> Sigh... Please RTFM.

That was probably unfair. I've been corresponding with the kernel
developers and they don't seem to understand what glibc is doing with the
headers.

> Kernel headers are fine.

They're NOT fine if you, or some glibc packager, has to diddle with them
to get applications which DON'T include kernel headers to compile.

You can argue that the problem is with glibc, but I don't see what they
can do about it. Maintain special sanitized headers for every conceivable
platform?

> ignoring whatever comes with the glibc

Nothing in include/linux comes with glibc. The packagers may call it
"glibc-kernelheaders" or somesuch, but the headers are straight out of the
kernel source.

Linus's argument was that include/linux should contain the kernel headers
against which libc (and possibly other dynamic libraries) was built. I'm
willing to concede that that's a very good idea, but not if it results in
a willy-nilly profusion of divergent "kernel" headers. That's bedlam.

> The best thing you'll hear is "don't include the kernel headers into
> your program",

You're right, of course.

> but since that makes no sense to you, go ahead and try.

Goddamnit, it makes perfect sense to me. The original problem cropped up
because src/include/pci.h includes <sys/pci.h>. Not a kernel header, a
glibc header.