[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

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 

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 

> 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: