My son brought his PC home from college today. After repairing a Windows
2000 installation that had been totally hosed by promiscuous web use, I
decided to go ahead and upgrade his Slack installation from 9 to 10.0.
Among the packages upgraded was the kernel headers package. He's running
2.4.20, and now has kernel headers for 2.4.24. Do I need to upgrade the
kernel? Consequences if I don't?

--
Old Man

Old Man wrote:

> My son brought his PC home from college today.**After*repairing*a
> Windows 2000 installation that had been totally hosed by promiscuous
> web use, I decided to go ahead and upgrade his Slack installation from
> 9 to 10.0. Among the packages upgraded was the kernel headers package.
> *He's*running 2.4.20, and now has kernel headers for 2.4.24.**Do*I
> need*to*upgrade*the kernel?**Consequences*if*I*don't?

Very often problems in kernels get fixed as they get upgraded, little
nagging things or even security flaws have been fixed. I'ld at a
minimum go with the 2.4.27 kernel or switch to 2.6.9 if the motherboard
can deal with that. I for example have an MSI-6167 that can't deal
with the way 2.6.X kernels deal with USB so I use 2.4.28 for that one
but otherwise I'm running strictly 2.6.X with few problems I can
detect.

Old Man wrote:
> My son brought his PC home from college today. After repairing a Windows
> 2000 installation that had been totally hosed by promiscuous web use, I
> decided to go ahead and upgrade his Slack installation from 9 to 10.0.
> Among the packages upgraded was the kernel headers package. He's running
> 2.4.20, and now has kernel headers for 2.4.24. Do I need to upgrade the
> kernel? Consequences if I don't?
>

It's ordinarily not a problem unless you're trying to compile kernel
modules.

Some modules freak out if the kernel version (uname -r) doesn't match
the kernel header version (in /usr/src/linux/include/linux/version.h).

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Sorenson wrote:

|> My son brought his PC home from college today. After repairing a Windows
|> 2000 installation that had been totally hosed by promiscuous web use, I
|> decided to go ahead and upgrade his Slack installation from 9 to 10.0.
|> Among the packages upgraded was the kernel headers package. He's running
|> 2.4.20, and now has kernel headers for 2.4.24. Do I need to upgrade the
|> kernel? Consequences if I don't?

| It's ordinarily not a problem unless you're trying to compile kernel
| modules.
|
| Some modules freak out if the kernel version (uname -r) doesn't match
| the kernel header version (in /usr/src/linux/include/linux/version.h).

don't confuse the kernel source withthe kernel headers.
in general, you wantthe kernel headers installed against which your
glibc was compiled.

so, keep the slackware kernel headers package installed (usr/include/linux)

and do with your kernel what you like (/usr/src/linux)


Jurgen.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFBupNy1ucXIiwNwbURAuvPAJsHaAqBYnZi8KRBAOTczk rrbPyS/wCgm9P+
9Mawc/WrGK2t8emI2jov/yQ=
=/IJB
-----END PGP SIGNATURE-----

Not to suggest Jurgen's advice is enough on its own, but it echoes the
official recommendation from Patrick. Copied here from slackware.com;

"This package of 2.6.7 based /usr/include/linux and /usr/include/asm
headers
is being provided by request for some people who need it in order to
compile
ASDL modem drivers for 2.6.7. As a general rule, installing kernel
headers
that are newer than the kernel glibc was compiled with *may* cause
problems,
so unless you need these for a particular reason it's best to stick
with the
2.4.26 kernel-headers package for now.

Good luck!

-P."

Not to suggest Jurgen's advice is not enough on its own, but it echoes
the official recommendation from Patrick. Copied here from
slackware.com;

"This package of 2.6.7 based /usr/include/linux and /usr/include/asm
headers
is being provided by request for some people who need it in order to
compile
ASDL modem drivers for 2.6.7. As a general rule, installing kernel
headers
that are newer than the kernel glibc was compiled with *may* cause
problems,
so unless you need these for a particular reason it's best to stick
with the
2.4.26 kernel-headers package for now.

Good luck!

-P."

Jurgen Philippaerts wrote:

> don't confuse the kernel source withthe kernel headers.
> in general, you wantthe kernel headers installed against which your
> glibc was compiled.
>
> so, keep the slackware kernel headers package installed
> (usr/include/linux)
>
> and do with your kernel what you like (/usr/src/linux)
>

Thanks, Jurgen. That's what I wanted to know.

--
Old Man

On 2004-12-11, Jurgen Philippaerts <see@my.gnupg.key> wrote:
>
> Chris Sorenson wrote:
>
>|> My son brought his PC home from college today. After repairing a Windows
>|> 2000 installation that had been totally hosed by promiscuous web use, I
>|> decided to go ahead and upgrade his Slack installation from 9 to 10.0.
>|> Among the packages upgraded was the kernel headers package. He's running
>|> 2.4.20, and now has kernel headers for 2.4.24. Do I need to upgrade the
>|> kernel? Consequences if I don't?
>
>| It's ordinarily not a problem unless you're trying to compile kernel
>| modules.
>|
>| Some modules freak out if the kernel version (uname -r) doesn't match
>| the kernel header version (in /usr/src/linux/include/linux/version.h).
>
> don't confuse the kernel source withthe kernel headers.
> in general, you wantthe kernel headers installed against which your
> glibc was compiled.
>
> so, keep the slackware kernel headers package installed (usr/include/linux)
>
> and do with your kernel what you like (/usr/src/linux)


/usr/include/linux and /usr/include/asm should be symlinks back into the
kernel src that made the kernel you are running:

ln -s /usr/src/linux/include/linux /usr/include/linux
ln -s /usr/src/linux/include/asm[-i386] /usr/include/asm


The rest of it (scsi, net, bits, etc...) should be provided by your choosen C
library, in our case, glibc. This is in the FAQ for glibc and is in /usr/doc
directory. In libc 5, scsi and net were also symlinks, but that's not
the case anymore and the glibc FAQ advises against it (section 2.17).

I don't know where the idea of having a seperate bunch of kernel headers came
from, but I think it's very confusing and it confused me at first as well.
The running kernel has a source. It goes in /usr/src/linux. Then the above
symlinks provide the /usr/include/asm and /usr/include/linux directories.
Anything else is asking for trouble, at some time, sooner or later,
when you try to compile something.

As for kernels, why not grab the 2.4.28 (and thus have its headers)? I've been
using it since I reverted back from 2.6.9, and I've had no troubles. If the
machine is a new machine, then I guess the latest 2.6 (and hence, it's
headers) would be a good choice. From what I've heard & seen, a newer machine
usually means better compatibility with a 2.6.

Be careful with anything less than an up to date kernel: there's some nasty
exploits out for them.


--
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

jayjwa <jayjwa@nowhere.org> wrote:
>
> /usr/include/linux and /usr/include/asm should be symlinks back into the
> kernel src that made the kernel you are running:

Nope. As Jurgen said, the kernel headers in /usr/include should match what
glibc was compiled against.

>
> ln -s /usr/src/linux/include/linux /usr/include/linux
> ln -s /usr/src/linux/include/asm[-i386] /usr/include/asm

The /usr/src/linux/README file specifically tells you not to do this, and
why.

> I don't know where the idea of having a seperate bunch of kernel headers came

Linus.

> from, but I think it's very confusing and it confused me at first as well.

Still a little confused then - and yes, I agree it can be confusing. You
don't go messing with /usr/include when installing a new kernel.

> The running kernel has a source. It goes in /usr/src/linux. Then the above

No, it goes wherever you want it to be. Like your home directory.

> symlinks provide the /usr/include/asm and /usr/include/linux directories.
> Anything else is asking for trouble, at some time, sooner or later,
> when you try to compile something.

I build kernel modules against the current kernel - like the Nvidia one.
By default it looks in /usr/src/linux. But, you can tell the installer
to look anywhere.

- Kurt

On 2004-12-12, ~kurt <actinouranium@netscape.net> wrote:

>> /usr/include/linux and /usr/include/asm should be symlinks back into the
>> kernel src that made the kernel you are running:
>
> Nope. As Jurgen said, the kernel headers in /usr/include should match what
> glibc was compiled against.

Look at what you wrote, it doesn't match what I'm talking about. I'm speaking
specifically about two directories in /usr/include, linux and asm.

> The /usr/src/linux/README file specifically tells you not to do this, and
> why.

This rule seems to not exist in my /usr/src/linux/README file obtained
from the 2.4.28 (bzip2'ed) archive from ftp.kernel.org, this one from the
glibc faq ( /usr/doc/glibc-2.3.3/FAQ ) IS present:


2.17. I have /usr/include/net and /usr/include/scsi as symlinks
into my Linux source tree. Is that wrong?

{PB} This was necessary for libc5, but is not correct when using glibc.
Including the kernel header files directly in user programs usually does not
work (see question 3.5). glibc provides its own <net/*> and <scsi/*> header
files to replace them, and you may have to remove any symlink that you have
in place before you install glibc. However, /usr/include/asm and
/usr/include/linux should remain as they were.


"as they were", I assume refers to this:

http://www.linuxfromscratch.org/lfs/view/ (url wraps)
stable/chapter06/linux-libc-headers.html :

For years it has been common practice to use "raw" kernel headers (straight
from a kernel tarball) in /usr/include, but over the last few years, the
kernel developers have taken a strong stance that this should not be done.
This gave birth to the Linux-Libc-Headers Project, which was designed to
maintain an API stable version of the Linux headers.

Install the header files:

cp -R include/asm-i386 /usr/include/asm
cp -R include/linux /usr/include

Here they use copy, and not symlink, due to the reason stated here
http://www.linux.com/guides/html/chapter06/kernel.shtml

"By copying the headers, we ensure that they remain available if
later you upgrade your kernel." I tend to think that the linux kernel headers
are compatible with those that came before them, that is, I don't think they
(the kernel developers) are going to rip out something that was defined in the
older versions of the headers thur rendering whatever depended on it broken.
If glibc needed to included, or wanted people to use, their own versions of
the linux kernel headers, then we'd see glibc containing a bunch of headers to
populate the /usr/include/asm and /usr/include/linux directories as well. But
we don't.

I run 2.4.28, thus my /usr/include/linux/version.h says:

#define UTS_RELEASE "2.4.28"
#define LINUX_VERSION_CODE 132124
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))

Note that this file is in a directory that, on my system, will be
updated with each new kernel I compile and install. Any thing other
than 2.4.28 doesn't make sense in this example.

>> I don't know where the idea of having a seperate bunch of kernel
headers came
>
> Linus.

Cute answer. Unfortunately it's not that simple. You know, especially if you
are writing Nvida modules, that Include files, of anything,
define expressions, values, and types to be used in the program for which they
are designed for. Let's suppose I write a program called FooBar.c, of which
has an include foo.h. foo.h defines, amoung other things:

#define FOOBARVERSION 1.1
#define BAZZ bar
#define SIZEFOO 4

You'd like to write a module which utilizes my FooBar to do whiz. You write
whiz.c and it #include(s) <foo.h>, because you need to know SIZEFOO. Next
year, I come out with FooBar v1.2 (Foobar-1.2.c) which everyone likes and
thus we upgrade to FooBar v1.2 on our systems. foo.h NOW is:

#define FOOBARVERSION 1.2
#define BAZZ bar
#define SIZEFOO 6 /* Needed more room for running Xyz */

Joe User wants to do whiz on his FooBar v1.2 BUT he didn't upgrade foo.h along
with Foobar-1.2.c and so he has then:

#define FOOBARVERSION 1.1
#define BAZZ bar
#define SIZEFOO 4

He compiles your whiz.c (which #include(s) <foo.h>) and it compiles
wonderfully. He goes to run it and it segfaults left and right due to FooBar
now having a SIZEFOO of 6 units instead of 4 which won't jive with my
new Foobar v1.2. Joe then proceeds to spend the next 4 weeks
trying to track down this error.

Bill wants to do whiz as well. Of oourse he is using FooBar v1.2, and since it
made sense to him that if you upgrade a program's source that made the
program, you ought upgrade the entire source, including headers.
he has:

#define FOOBARVERSION 1.2
#define BAZZ bar
#define SIZEFOO 6 /* Needed more room for running Xyz */

goes to compile whiz.c, and:

Make: error SIZEFOO blah,blah,blah,blah
in file foo.h
included from whiz.c:
Blahdeeblah blah,blah-blah

He sees this, heads to http://www.whiz.org/ and downloads whiz2.tar.bz2,
extracts whiz.c, recompiles, it works with the new Foobar v1.2,
and now has a running program.

I am aware of what Linus says about symlinks and what he thinks of them. There
is (at least) one specific post to the Kernel mailing list that address it.

User-space programs shouldn't include kernel headers, but in some cases
userspace programs eventually include files which include kernel headers, as
could be the case in the example above. Trace thru some popular programs to
see some examples of this.

glibc provides user-program includes, and, as the faq states, now supplies net
and scsi from the 4 of the old directories that people used to symlink to.
When the kernel upgrades, the files that made it, including the headers,
should also do so; if it breaks stuff, it breaks stuff: the program is either
written to allow for such variation or it needs to be recompiled, but having a
directories full of files that outline values and defines for a 2.4.0 kernel
when a 2.4.28 is executing and running just doesn't make sense. We don't do it
for other stuff so why do it with kernels? I've yet to get a program, go to
compile it, and it says to *not* use the include files that it was using and
depending on that were made for it, but rather to use ones from 3 version back.

I'm also not speaking of /usr/include as a whole, I'm refering to specific
directories, the ones which give definitions for the source files that are
supposedly used to build the current, running kernel on a system.

After building my own apps & utils now quite some time, and now building all
of them (OK, lvm I downloaded I was lazy ) thru Apach2 with PHP 5rc2,
imagemagik, mysql, proftpd, cvs, shadow, sudo, ftp, in.tftp, readline,
libidn, Gnu pthreads, some 40+ others since Current stopped updating,
my last kernel, my current kernel and even binutils and a
Mingw32 cross-compiler, it's not likely I'm completely off base or else none
of this would be working. And yet it does. I've also been programming since I
was 16-17, including assembler for several chipsets and high level languages
as well, so I feel I have a grasp on what include files are and how they are
used. I don't think anyone is taking this as "official" anyway, just
one way one person sets up his system which not only works but also
makes sense.

>> The running kernel has a source. It goes in /usr/src/linux. Then the above
>
> No, it goes wherever you want it to be. Like your home directory.

Yes, and I suppose you can name all your directories after famous cats or the
seven dwarves, too. The benefit of deviation from tradition
would be .....

> I build kernel modules against the current kernel - like the Nvidia one.
> By default it looks in /usr/src/linux. But, you can tell the installer
> to look anywhere.

Of course.

--
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++