> [...] > >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: [EMAIL PROTECTED] | All things considered, insanity may be > the > | Play: [EMAIL PROTECTED] | only reasonable alternative. > > +- http://wired.st-and.ac.uk/~dg -+ > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Buddha Buck [EMAIL PROTECTED] "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
