Please forgive me if I am not asking these questions right, my understanding of the inner workings of Linux is very poor.

I would like to upgrade the kernel, and I've heard before that I should leave the kernel-headers package in place. In my understanding kernel-headers are the headers that glibc is compiled with. Isn't there a slight chance that some struct is different size in the new kernel, and bad things happen?

To put it another way, would it not be safer to upgrade the headers along with the kernel? Would that require also rebuilding glibc? And would rebuilding glibc be sufficient for plugging that hole, however small it may be?

To put it a third way... Suppose Patrick V. needed to upgrade the kernel in stable: a patch wouldn't do it. What would he do?

Perhaps this will help. http://alien.slackbook.org/dokuwiki/...eaders_package

I am familiar with this extremely helpful writeup, allend, but I still feel like I am missing something from this picture. Look here, for example:

http://www.slackware.com/security/vi...ecurity.597338
ftp://ftp.slackware.com/pub/slackwar...ches/packages/
ftp://ftp.slackware.com/pub/slackwar...ux-2.6.37.6-3/

There PV upgraded every kernel-related package, yet he kept everything at the same exact version, which is what he always does (are there exceptions?). So while me and many other slackers are perfectly happy mismatching kernels and headers, PV seems to think it's a bad idea. So the question is, is there a better, safer way to upgrade the kernel? Would it involve rebuilding glibc with new headers? Or any other parts of the gcc toolchain? Or does the whole Slackware have to be bootstrapped again?

I think that's a misunderstanding. As pointed out by Alien BOB (cf. the link provided by Allend) Slackware contains two sets of kernels headers in two different places, that do not need to be the same. Would Pat think that's a bad idea, he would propose an upgrade of the kernel headers in /usr/include/linux every time he propose an upgrade of the kernel so that they stay identical (not only that, but all stuff that depends on these kernel headers as pointed out by Eric). As he doesn't you can be assured that's not necessary.

But did PV actually ever upgrade a kernel, as opposed to patching it?

The kernel-headers actually are irrelevant to the actual Linux kernel.

The kernel-headers are actually tied more to glibc and gcc, and really many people refer to them as the "glibc kernel headers" more correctly. If you have kernel headers for kernel 3.4.20 and your glibc was built around 3.4.20, but you run kernel 3.16.1, you're glibc kernel headers are not for the kernel, they are for the compiler, and you do not need to rebuild the headers or glibc. In fact, unless you update glibc, you really never need to upgrade the kernel headers.

Let's say I have stock headers and an upgraded kernel, with version mismatch. If I build a program with glibc now, it will be calling into a new kernel, but using structs from the stock headers. I hope I am getting this right... This seems like a relatively tiny risk, but what would have to be done to avoid it entirely?

You could install new kernel, new kernel headers, then audit those kernel headers (look for stale files). After that, rebuild glibc against those headers. Usually, I'll throw gcc into the mix as well. Rebuild whatever else depends on Linux-specific headers.

You're trusting both glibc and the kernel to offer backwards compatibility. As Linus once stated, "We do not break userspace!" Maybe things don't always work out that way: Maybe a hardware- or network-related tool will have to be rebuilt every now and then. For the most part, it's worked in recent years, save for that whole drm/Mesa/Xorg thing that requires the planets to be aligned before everything works perfectly.

Thanks mlslk31! And also, the glibc wiki says:
I think I have my answer, but I would be extremely thankful for any other comment, especially in relation to Slackware.

Do NOT upgrade the headers when compiling a new kernel.
You can upgrade the headers when compiling a new glibc.