This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Linux kernel version support policy
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: <libc-alpha at sourceware dot org>, Aurelien Jarno <aurel32 at debian dot org>
- Date: Tue, 28 Jan 2014 01:02:08 +0000
- Subject: Re: Linux kernel version support policy
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1401272237400 dot 14736 at digraph dot polyomino dot org dot uk> <3591302 dot 5mrdmfoV2Y at vapier>
On Mon, 27 Jan 2014, Mike Frysinger wrote:
> On Monday, January 27, 2014 23:02:43 Joseph S. Myers wrote:
> > (and more generally, to review
> > the conditionals that would be obsoleted by such a move to make sure the
> > features that would be assumed to be available are in fact available in
> > the chosen versions for relevant architectures).
>
> i think any bump in min kernel version should be predicated upon this. if
> there's no significant code clean up by updating the min version, then we
> shouldn't be throwing away support for them.
Note that increasing the minimum version makes such a review easier - it
can start by checking what's in 2.6.32 (for example) without worrying
about identifying the specific older version where something was added, so
specific versions need checking only for architectures still missing a
feature in 2.6.32.
However, when I made 2.6.16 the minimum, I did the cleanup of individual
__ASSUME_* *after* the general arch_minimum_kernel change. Given that we
know about significant mistakes in conditionals for more recent kernels, I
think the review would need to be done first this time. Thus, one patch
would both change the minimum and correct the conditions on individual
affected macros (possibly to unconditional, possibly not), while
subsequent patches would then remove macro definitions along with the
conditionals testing those macros, where a feature is now known to be
available unconditionally.
--
Joseph S. Myers
joseph@codesourcery.com