Re: Fixes for 2.15.1

[Roland McGrath <roland at hack dot frob dot com>]

> commit fb59b3a4f54777652dc877a1df0fcc009b741d87
> Author: David S. Miller <davem@davemloft.net>
> Date:   Thu Feb 16 14:56:54 2012 -0800
> 
>     Add O_FSYNC define to sparc just like other platforms.

I'd call this harmless but not really necessary.  Strictly speaking, it's a
feature addition.  OTOH, given that there hasn't really been a 2.15 release
at all yet, we can be less strict than usual minor-release rules.

> commit 7c35ffedf144417ba2787322c7b75b4db5c3cb7a
> Author: Thomas Schwinge <thomas@codesourcery.com>
> Date:   Fri Feb 10 21:05:54 2012 +0100
> 
>     Fix x86 PLT slot usage for feraiseexcept.
>     
>     Then we're elf/check-localplt.out-clean again.

I'd say yes.

> commit af850b1c978bdca648ef9fb141e785d75f74d9bf
> Author: Richard Henderson <rth@twiddle.net>
> Date:   Thu Feb 9 11:21:47 2012 -0800
> 
>     Use <> for include of kernel-features.h.

This might be necessary for ports to have a working release (not sure).
Certainly ought to be harmless.  I'd say yes.

> Also, I didn't look at whether any Hurd changes should be backported; 

I'll leave that at tschwinge's discretion.  The only Hurd changes have been
bug fixes, but I don't think anybody is close to using an unmodified glibc
on Hurd anyway.

> didn't look at whether any documentation changes should be backported; 

Doesn't really matter either way.

> didn't look at what might be backport-appropriate in the ports repository; 

Should be up to each port maintainer.

> and didn't look at the question of backporting libc changes needed for the 
> Tile ports.

If the tile ports went in using GLIBC_2.15 then it might be appropriate.
But we need to consider each case for risk on its own.

> Ryan suggested backporting stdc-predef.h because he wanted it 
> for libdfp use, although that change would probably be outside the normal 
> scope of backporting (it's not a bug fix).

I'd tend toward no, but could be convinced otherwise given the "hasn't
really been a release yet" logic.  But it is a very recent change that has
not yet had any time to shake out any unanticipated issues.

> Of course some people may have suggestions for other changes that should 
> go on 2.15 branch.

I'd like to have us all reminded of the bugzilla conventions for requesting
those and then use them for each candidate.


Thanks,
Roland