This is the mail archive of the
mailing list for the glibc project.
Re: Requiring Linux 3.2 for glibc 2.24
- From: Florian Weimer <fweimer at redhat dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 1 Feb 2016 15:37:17 +0100
- Subject: Re: Requiring Linux 3.2 for glibc 2.24
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1601311614080 dot 31071 at digraph dot polyomino dot org dot uk> <20160201133505 dot GB706 at altlinux dot org> <56AF662D dot 6090807 at linaro dot org>
On 02/01/2016 03:05 PM, Adhemerval Zanella wrote:
> I do not consider RHEL (or any specific provider )to be a LTS provider for
> various reasons:
> 1. Kernel source is provided by login-wall , which IMHO maybe a sufficient
> reason to ditch this a LTS provider;
That's not true, the kernel source is publicly available. And all
features and bug fixes go into the kernel.org tree if they are
applicable there. The sources on git.centos.org or ftp.redhat.com lack
broken-out patches, but the sources are available.
This is certainly not ideal (I don't like it, either), but it's quite
different from what most ARM partners do, who do not release complete,
buildable kernel sources when they distribute kernel binaries, or only
after tremendous pressure for interested parties. So let's drop this
subject, it's not a productive discussion.
> 3. THEL LTS kernel also backport a lot of features that are not in current
> 2.6 LTS (although I am not quite sure if kABI is different, although it
> might since RHEL also patch its glibc);
glibc kernel feature tests follow the model “try and see if it works, if
it does not, fall back”. This works quite well with backports. For
example, the Red Hat Enterprise Linux 6 kernel has ST_VALID support, and
upstream and downstream glibc automatically use it.
I don't think we want to deviate from this model on the glibc side, so I
don't see this as a problem.
> 4. I do not see a good approach to tie kernel support to an specific
> organization where the current support already exists.
> And again I also do not see this very specific openvz.org issue as a
> compelling reason to avoid such minimum kernel change.
I would see more participation in glibc development from container
implementations which have restricted system call interfaces and only
provide subsets of /proc and /sys. Without their help, it is easy for
us to implement something which works well on stock kernels and the
container implementations we have access to, but will completely fail on
their container implementation.
We might want to post something on LWN, to get a wider audience, and
announce that we are slowly moving to 3.2 as the baseline, and those who
have kernel forks should follow glibc development more closely.