[lkml]   [2018]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [GIT PULL] parisc fixes for kernel v4.19
On 03.10.2018 00:24, Greg Kroah-Hartman wrote:
> On Tue, Oct 02, 2018 at 11:46:11PM +0200, Helge Deller wrote:
>> Hi Greg,
>> On 02.10.2018 23:16, Greg Kroah-Hartman wrote:
>>> On Tue, Oct 02, 2018 at 11:02:13PM +0200, Helge Deller wrote:
>>>> please pull a last set of fixes for the parisc architecture for kernel 4.19 from:
>>>> git:// parisc-4.19-3
>>>> The major change is for parisc64 to use a 64-bit suseconds_t type to
>>>> match what glibc expects for 64-bit userspace. It's an ABI change, but
>>>> since we don't have a 64-bit userspace on parisc yet, it won't introduce
>>>> a breakage.
>>> Isn't it a bit "late" in the release cycle for such a change? Why not
>>> do this on the -rc1 release?
>> I've tagged it for stable release.
>> So, it can go in now, or just wait until -rc1 and go in later.
> Why is a major API change a viable stable change?

Of course it's not.
Esp. not if an API has been used already.
IMHO, this case is really different though...

> What bugfix does it provide?

It fixes that code in stable kernels which would return wrong
time values *if* someone would create a libc for 64-bit parisc
and would run it with those "stable" kernels.
Fixing it now has no side-effects, the change is a trivial
2-line-removal patch, would bring the code in sync with
newer kernel source code, and it really fixes existing code.

I still believe that this justifies for a backport.

Nevertheless, if you really disagree, I'm fine dropping the
backport to stable and will only push it in the next
merge window for v4.20.

>>>> Other than that we simply drop unused code and outdated gcc version
>>>> checks.
>>> Why are those needed now?
>> The patch in there which is by me changes one line simply cleans up a patch which
>> went in during the 4.19 merge cycle. So it would be nice to have it
>> added now before v4.19 gets released.
>> The other two patches are trivial and just remove dead code.
>> I rate them all as non-critical, but nice-to-have-in-v4.19.
>> If you disagree I'm absolutely fine to wait with all of them
>> for the next merge window.
> Normally I only let "bugfixes" into my trees at this point in time.
> cleanups always wait for the next -rc1 merge window as that's what it is
> there for. So I'd recommend waiting as well.



 \ /
  Last update: 2018-10-03 16:47    [W:0.078 / U:2.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site