public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: libc-alpha@sourceware.org
Subject: Re: Requiring Linux 3.2, again
Date: Thu, 04 May 2017 16:34:00 -0000	[thread overview]
Message-ID: <1dd8e0bc-2b11-8c35-7449-bdc168eaf119@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1705041116490.15499@digraph.polyomino.org.uk>

On 05/04/2017 07:24 AM, Joseph Myers wrote:
> On Thu, 4 May 2017, Carlos O'Donell wrote:
> 
>> What about the next step though? And the next? Moving beyond linux 3.10 would
>> mean that any future RHEL which is rebased to the newest glibc would not be
>> able to easily run in a container on RHEL 7 using a RHEL 7 kernel. 
>> Taking note that RHEL7 has support until 2024 at a minimum.
> 
> My view is that we base things on the oldest supported kernel version 
> listed at https://www.kernel.org/category/releases.html - remembering that 
> distributions supporting a distribution kernel long term may choose to 
> contribute to maintaining the upstream kernel for the community, and this 
> may mean some of the kernels listed there in fact live on with other 
> maintainers beyond the dates currently shown there.

That's a very good argument, and a similar argument can be made for FSF
supported versions of GCC and I can't argue against that.
 
> Based on the dates shown there, we might consider moving from a 3.2 
> minimum to a 3.16 minimum for glibc 2.28 (Aug 2018) or 2.29 (Feb 2019).  
> But actually it doesn't look like there's any difference between 3.2 and 
> 3.16 for features glibc cares about on x86 / x86_64 (whereas there *are* 
> cleanups possible by moving from 2.6.32 to 3.2), so there would be very 
> little cost to keeping the version back on some architectures (while 
> moving to require 3.16 on other architectures) if that makes sense at the 
> time.  And of course if 3.10, say, is in fact still supported when 3.2 
> ceases to be, that rather than 3.16 would be the version to consider.

I think I've outlined another argument in my downstream email. That the
abort we issue for being on too old a kernel may be too catastropic here
and that there might be a middle ground where such applications could work
and we don't let them.

-- 
Cheers,
Carlos.

  reply	other threads:[~2017-05-04 16:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-03 11:26 Joseph Myers
2017-05-03 14:27 ` Florian Weimer
2017-05-08 21:37   ` James Cloos
2017-05-03 16:11 ` Arnd Bergmann
2017-05-04  2:16 ` Carlos O'Donell
2017-05-04 11:24   ` Joseph Myers
2017-05-04 16:34     ` Carlos O'Donell [this message]
2017-05-04 17:23       ` Joseph Myers
2017-05-08  8:11         ` Andreas Schwab
2017-05-04 11:48   ` Joseph Myers
2017-05-04 16:32     ` Carlos O'Donell
2017-05-04 17:00       ` Joseph Myers
2017-05-04 17:14         ` Joseph Myers
2017-05-04 19:10         ` Carlos O'Donell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1dd8e0bc-2b11-8c35-7449-bdc168eaf119@redhat.com \
    --to=carlos@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).