Linux kernel version support policy

[Mike Frysinger]

On Tuesday, January 28, 2014 01:02:08 Joseph S. Myers wrote:
> 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.

i'm not saying the changes to actually remove support has to be written first.  
i'm saying we should have an idea of what conditionals would get cleaned up 
and how many files/LoC are actually impacted.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20140128/64e4b66c/attachment.sig>