This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: concerning headers, glibc, and kernel upgrades


On Mon, Nov 17, 2014 at 9:01 AM, Ivan Zaigralin <melikamp@melikamp.com> wrote:
> Hi! I am in the process of de-blobbing Slackware, and one of my basic
> tasks consists in replacing the stock kernel with Linux-libre kernel.
> Not content with merely de-blobbing the kernel, I would like to explore
> the option of upgrading it, but then some questions arise.
>
> Please excuse me if my questions are confusing or ill-informed, as I
> lack expertise in kernel-related issues.
>
> My question concerns the interplay between Linux-libre, glibc, and
> the so-called kernel headers used by glibc. The wiki says:
>
>> The headers from the most recent Linux kernel should be used. The
>> headers used while compiling the GNU C library and the kernel
>> binary used when using the library do not need to match. The GNU
>> C library runs without problems on kernels that are older than
>> the kernel headers used. The other way round (compiling the GNU C
>> library with old kernel headers and running on a recent kernel)
>> does not necessarily work as expected. For example you can't use
>> new kernel features if you used old kernel headers to compile the
>> GNU C library.
>
>> Even if you are using an older kernel on your machine, we
>> recommend you compile GNU libc with the most current kernel
>> headers.  That way you won't have to recompile libc if you ever
>> upgrade to a newer kernel.
>
> So let's say glibc is built against kernel headers 3.18.* and the kernel
> in use is 3.10.17. So there is a version mismatch. Isn't it possible that
> some interface is different, like some struct has changed size, and then
> glibc calls to kernel (or some other app calls through gibc) and kaboom?

That could happen if the kernel breaks its ABI.

> How likely is this scenario?

Not very likely: kernel developers are very careful to not do that.

> Would it not be safer to match headers with the kernel?

An exact match would buy you temporary safety, yes. But the moment you
upgrade your kernel, you throw that safety out.

Since kernel developers routinely update their kernels *without*
updating glibc, and glibc developers test their new glibc builds
without updating their kernel, mismatches either way are expected and
routinely tested.


> Here's a related question.
>
> Traditionally, Slackware -stable has kernel, headers, and glibc frozen,
> with headers matching the kernel. The kernel is never upgraded (afaik),
> instead individual commits are applied to the kernel when a particularly
> severe hole is discovered. All of this done, seemingly, for the fear of
> mismatch.

That fear is irrational.

FWIW, Google updates their glibc to match Ubuntu LTS releases (every 2
years), while running a large selection of kernels, from 2.6.x through
3.17.x and anything in between.

> Now (and forgive me if this question is too Slackware-specific), what
> would be a good way to upgrade the kernel?

Build it and install it. No need to rebuild anything else.

> Is bumping the headers to
> mainline really better than bumping them to the new kernel version,
> even though the former results in mismatch?

When you build against e.g. 3.17 kernel headers, you allow glibc to
conditionally use features introduced in that kernel.

If you then run on e.g. kernel 3.10, glibc will discover that some
features are not available (system calls fail with ENOSYS), and will
not use them.

If you later update to kernel 3.13, glibc will start using features
available in that kernel.

On the other hand, if you build glibc against 3.10 kernel, then update
to 3.13, glibc will *not* use any new features, because the code to do
so will have been #ifdef'd out.

> But more importantly, what exactly should be rebuilt?

Nothing has to be rebuilt.

> Is it enough to rebuild the kernel, install
> the new headers, then rebuild glibc against the new headers? Or should
> I also rebuild other parts of the gcc toolchain?

Hope this helps.
-- 
Paul Pluzhnikov


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]