On Wed, May 25, 2016 at 04:19:23PM +0100, KatolaZ wrote:

> >     The kernel doesn't make any call to the glibc; it is the
> > opposite: when running the new kernel, the userland invokes the
> > glibc all the time, and this glibc makes system-calls to the new
> > kernel, and there are some changes in the system-calls from kernel
> > version to kernel version. This is why the libc must be recompiled
> > with the proper kernel headers.

> >
>
> Well, glibc shoult be retro-compatible, so this should be needed only
> if your applications are going to use those "new" syscalls (if any,
> since most of the times the updates in the glibc are reduced to flags
> and options to existing syscalls).
>
> If you need to recompile the kernel only because of a missing/newer
> module, you might not need to upgrade your glibc at all, especially
> since all your applications already work fine with the glibc you
> have... :)

Glibc is configured for compatibility with any kernel version above a
specific base. In jessie, that's 2.6.32, in unstable/stretch/ascii,
3.2. This can be changed by recompiling glibc, although moving the base
too far back is strongly discouraged by glibc's upstream.

On the other hand, the kernel strongly tries to keep compatibility with
_any_ glibc version ever, including ones from the dawn of time. Certain
facilities that are detrimental on modern systems are still present, at most
guarded with an #ifdef, such as CONFIG_USELIB or CONFIG_COMPAT_BRK.

--
An imaginary friend squared is a real enemy.