Back in the old days, some of the headers under /usr/include would symlink into /usr/src/linux, which would itself be a symlink to the versioned kernel source directory. These days, the headers under /usr/include are kept in sync with those used when the C libraries were built and /usr/include no longer contains symlinks into /usr/src/linux.

My question is; does the /usr/src/linux symlink have a purpose any more? And, if it does, is it more correct to point it at the source for the current running kernel version, or to leave it pointing back at the original kernel in the same way that the headers in /usr/include are frozen in time?

Have a read of this.
It's old, but the fella that posted it seems to know what he was on about.

Damn - duplicate post deleted.

Yes, thanks syg00, I'd read that before posting. I think that what Linus describes in that post is from back in the day when the symlinks under /usr/include still existed and pointed into /usr/src/linux, so the only way to keep the includes frozen instep with the libraries would be to keep /usr/src/linux frozen as Linus explained. I'm not sure whether it's the same for all distributions these days, but in Slackware /usr/include is now self contained and doesn't refer back to /usr/src/linux in any way, which is why I asked the question.

mmmm - I thought this was pretty explicit

Yes, but in the same post he explains why this was needed:

In Slackware, this is not applicable at all. As GazL also pointed out, the /usr/include/linux directory is not a symlink pointing into /usr/src/linux-* kernel source at all. Slackware's /usr/include/linux is always a directory with the set of kernel header files against which glibc was compiled.

So, (1) there is nothing against compiling your own kernel in /usr/src . I build mine there, and all Slackware kernels are built in -usr/src/linux-<version> as well. And (2) the /usr/src/linux symlink is no longer needed, since all modern-day programs check the "/lib/modules/`uname -r`/build" symlink instead of /usr/src/linux to locate the source of from which the running kernel was compiled.

Eric

It is, but that answer is from a time when the headers within /usr/src/linux were actually used to compile stuff other than the kernel (i.e. they were targets of symlinks from within the /usr/include tree) and since the header files in /usr/include are now independent copies, it's not really relevant to my question.


What I'm saying is; the /usr/src/linux symlink appears to be redundant Am I correct in thinking this?

Now, the reason I'm asking is that there may be some program source out there that is coded to reference /usr/src/linux/include/something_or_other.h directly for some strange reason I don't know of (perhaps a kernel module source might do this, I really don't know). This is what my question is getting at, and it's not explicitly answered in that post from Linus.

Thankyou Eric, that's exactly what I was trying to understand.

It should be redundant for the most part, but just a year or perhaps two ago, iptables would crap out when building if you didn't have a /usr/src/linux.... Wait. I think it crapped out if you had one. Some other source code did the same exact thing so I started removing that symlink.

The only reason I like to still keep it there is it's less typing when I want to cd into my kernel source tree... Any properly coded Makefile will check /lib/modules/$(uname -r)/build instead of looking to /usr/src/linux