Re: Continuing Annoyances...
> [...]
> >Hmm... well, doing it fixed several build errors and numerous warnings in the
> >USB drivers (due to changes in which headers include which other headers). Oh
> >well, maybe it's just the funky back-ported USB driver that incorrectly
> >references the system headers. How else am I supposed to keep those headers
> >up-to-date? copy them whenever I build a new kernel? Things like Mac-on-Linux
> >didn't much like them being out of date w.r.t. my kernel.
>
> There's a seperate kernel-headers package which installs all the exported
> headers into /usr/include/linux. Quite a lot of glibc relies on these at the
> bottom level --- it's not glibc's business to know whether the system uses 32
> or 64 bits integers for example, that's the kernel's job, so it uses a kernel
> header. Having this package means you don't need a kernel source tree to build
> userspace programs.
>
> Naturally, you have to keep this up to date with your real kernel. I think
> this is what you were doing wrong.
This is wrong. The most recent rant by Linus on the topic is available
in a recent Kernel Traffic newsletter.
What it boils down to is that Linus would like the include files in
/usr/include/linux to be either
a) developed by glibc, not directly related to any Linux kernel,
or b) to be the headers from the kernel glibc was compiled with.
His rational is that /usr/include/linux headers are intended for
userspace, so glibc had better know what they are. Userspace programs
don't interact with the kernel directly, but go through glibc. The
kernel headers are for kernel development, and shouldn't be used by
userspace programs.
If some software package truely needs to interface with the kernel w/o
going though glibc (like a kernel module, for example), it should be
written to find the kernel headers in /usr/src/linux/include/linux or
wherever the user tells them they are (/linux/linux/include/linux on my
machine).
A hypothetical example of what could go wrong:
Let's say glibc exports to users an interface that uses an struct foo[]
as an argument type, based on the kernel-level struct foo. The
definition of struct foo ends up coming from <linux/foo.h>. The
underlying syscall that uses struct foo does not take an array of them,
but deals with foo's one by one.
In this example, glibc was compiled with kernel version 2.6.12, which
has sizeof(struct foo)==X. In kernel version 2.7.45, it is decided
that struct foo needs a reference-count field, so it is extended by one
integer field, so in kernel version 2.7.45, sizeof(struct foo)==Y, Y>X.
This isn't a problem for glibc. When it talks to the kernel, it still
passes one struct foo at a time, and all the other fields haven't
changed, so the kernel can still find all it needs. So glibc can still
merrily walk its array, doing what it needs to do, and all is well.
Now you compile your userspace program that uses struct foo[], but you
have substituted the new version of linux/foo.h for the version that
glibc was compiled with. Your struct foo[10] array is 10*Y chars long,
but glibc thinks it's 10*X chars long. Now when glibc walks your array
of struct foos, it gets really confused, because the fields no longer
align.
While this is a hypothetical example, Linus does mention -real-
examples of things which have broken like this in one of his original
comments on the matter. Unfortunately, I don't know where they ended
up.
>
> Me, I use a symlink. But then, I change kernels quite frequently.
>
>
> --
> +- David Given ---------------McQ-+
> | Work: dg@tao-group.com | All things considered, insanity may be the
> | Play: dgiven@iname.com | only reasonable alternative.
> +- http://wired.st-and.ac.uk/~dg -+
>
>
>
> --
> To UNSUBSCRIBE, email to debian-powerpc-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
Buddha Buck bmbuck@14850.com
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
Reply to: