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



> Em 1 de fev de 2016, Ãs 12:37, Florian Weimer <fweimer@redhat.com> escreveu:
> 
>> 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.

I did not say it was no public available, but rather that direct access requires intrusive registration (I started to create an account to check what kind of information and it requires pretty much full disclosure).

Anyway the idea is the RHEL source tree it is not fully collaborative in the sense it is controlled by redhat. Yes I understand I can submit a patch and it will be eventually applies after a set of steps (as I did in the past), but again I see this is not the ideal source is community development process imho.

Also keep in mind I am not discussing or denying RH compromise to project or/and open source, but rather how the process and control of a LTS release should rely.

> 
>> 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.

Ok, but the cleanup idea imho is exactly to get rid of this behavior and just use a direct support. My main regards is if RHEL or any other kernel LTS deviates from 2.6 in a sense where GLIBC will need to require additional handling. 

If RHEL compromise is to not follow such path I am ok with this.

> 
>> 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

That is a good approach.

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