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.
next prev parent 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).