This is the mail archive of the libc-alpha@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: Requiring Linux 3.2 for glibc 2.24


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 [1], 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.

Florian


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