Re: [EXT] Minimum kernel (formal ?) support policy

[Carlos O'Donell <carlos at redhat dot com>]

On 1/15/19 2:47 PM, Romain GEISSLER wrote:
>> Le 15 janv. 2019 à 20:01, Carlos O'Donell <carlos@redhat.com> a écrit :
>>
>> There are some arguments against having this kind of "line in the
>> sand" approach to kernel versions, some argue that it should be
>> based on actual capabilities e.g. finer grained. While true a finer
>> grained checking would increase maintenance costs and the testing
>> matrix would become much more complicated. Thus the "minimum kernel
>> version" remains the simplest and easiest solution to the problem.
> 
> That confirms what I was actually asked several times by some of my
> coworkers who thought that glibc check features of the kernel rather
> than just blindly believing the uname version which I told them glibc
> was doing. Indeed I am often said by my sysadmins that RHEL 7 kernels
> look "old" if you just look at the version but actually the huge
> backporting work made by Red Hat make them actually quite new from a
> feature set point of view.

There are two things I want to clarify here.

The library checks for all features *newer* than the kernel baseline.

So there is feature checking, but it starts with the baseline as
the set of assumed features that do not have to be checked (where
such features are usable by there very presence).

Secondly, yes, absolutely, the RHEL 7 kernel has *tons* of new
features backported to it, and so does the RHEL 7 glibc. In fact
the RHEL 7 glibc has a full rebase of the resolver code such that
the dynamic /etc/resolv.conf reloading feature is there also. So
it's not really fair to call RHEL 7's kernel or glibc "old". They
are a hybrid of features driven by customer and business
requirements, including keeping the API and ABI stable.
 
>> Does that answer your question?
> 
> Yes thanks. We mainly wanted to know if there was any predictable way
> to know that in X years glibc wouldn't be able to run on RHEL 7/RHEL
> 8/SLES 12/SLES 15 kernels anymore, and we now have the confirmation
> that no one knows when this will happen.

As I said before we really try not to move the minimum kernel baseline
forward to provide the maximum compatibility possible.

At some point, after years of features, it is profitable to rebase
the baseline. It would be interesting if you could graph out, based
on our NEWS entries / source, and the release timeline, exactly when
we changed from which baseline to which baseline for some arch.

Then put it into a table like this:
https://sourceware.org/glibc/wiki/Glibc%20Timeline

To see if we have some kind of average movement rate on kernel baseline
changes :-)

> One last question. Is there right now in 2019 any foreseeable
> fixes/changes that would raise the minimum kernel version ? I am
> developer too, and I have already some medium/long term vision for
> the software I am working on and what are the changes to expect, so
> maybe you too know already that for reason X you would like to raise
> this minimum soon (or at least raise the question to the list). I
> don't look for any strong commitment of course, just hints at what
> one could expect in the foreseeable future.
Just one feature is often not enough.

Take for example, feature A, if that gets into the kernel at 
kernel 4.X, then glibc can *immediately* use it as a
new feature, but will require a version check, and fallback code
if the feature isn't present.

Moving beyond 4.X allows us to drop the version check and the
fallback code for feature A.

It is the sum of feature A, B, C, D ... etc that will cause us
to desire to move the baseline forward.

Previously it was suggested that we should poll LWN also with
an article to see what people think about moving the baseline,
and we might do that next time.

If in 2020 Ben Hutchings EOLs the 3.16 longterm release kernel,
then there may be a case for moving to a 4.4/4.9 kernel baseline
in line with GKH's longterm release series.

We will probably poll the distros to see what kernels they are
using at that time, and make a decision.

So in summary, I don't see any changes for 2019, but 2020 might
have a discussion and review at the kernel upstream, distro,
and community level.

I hope that answers your question.

-- 
Cheers,
Carlos.