Ping Re: [PATCH RESEND] Update kernel math-emu code from current glibc soft-fp

Ping Re: [PATCH RESEND] Update kernel math-emu code from current glibc soft-fp

[Joseph Myers]

Ping.  This patch <https://lkml.org/lkml/2015/6/22/266> is pending review.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH RESEND] Update kernel math-emu code from current glibc soft-fp

[Michael Ellerman]

On Mon, 2015-06-22 at 13:26 +0000, Joseph Myers wrote:
> From: Joseph Myers <joseph@codesourcery.com>
> 
> The include/math-emu code (used for alpha powerpc sh sparc, and to a
> very limited extent for s390) was taken from an old version of glibc's
> soft-fp code around 15 years ago (in the pre-git era, anyway, and some

...

> This patch is unchanged from that posted at 
> <https://lkml.org/lkml/2015/5/19/1047>, still applies to current sources 
> and is proposed for 4.2.


Hi Joseph,

This is an awesome effort, and greatly appreciated.

However in it's current form it's not easily mergeable, because it touches five
architectures and has the potential to cause breakage on all of them.

It's also too late for 4.2. The merge window for 4.2 is open now, which means
arch maintainers have stopped taking intrusive patches 1-2 weeks ago.

Is there some way you can imagine of splitting this up into smaller chunks, so
that different arches can merge the pieces separately?

cheers


 arch/alpha/include/asm/sfp-machine.h    |    3 
 arch/alpha/math-emu/math.c              |  131 -
 arch/powerpc/include/asm/sfp-machine.h  |   39 
 arch/powerpc/math-emu/fadd.c            |    6 
 arch/powerpc/math-emu/fadds.c           |    6 
 arch/powerpc/math-emu/fcmpo.c           |    2 
 arch/powerpc/math-emu/fcmpu.c           |    2 
 arch/powerpc/math-emu/fctiw.c           |    2 
 arch/powerpc/math-emu/fctiwz.c          |    2 
 arch/powerpc/math-emu/fmadd.c           |    8 
 arch/powerpc/math-emu/fmadds.c          |    8 
 arch/powerpc/math-emu/fmsub.c           |    8 
 arch/powerpc/math-emu/fmsubs.c          |    8 
 arch/powerpc/math-emu/fnmadd.c          |    8 
 arch/powerpc/math-emu/fnmadds.c         |    8 
 arch/powerpc/math-emu/fnmsub.c          |    8 
 arch/powerpc/math-emu/fnmsubs.c         |    8 
 arch/powerpc/math-emu/fsub.c            |    6 
 arch/powerpc/math-emu/fsubs.c           |    6 
 arch/powerpc/math-emu/lfs.c             |   11 
 arch/powerpc/math-emu/math_efp.c        |  254 +-
 arch/powerpc/math-emu/stfs.c            |    6 
 arch/s390/include/asm/sfp-machine.h     |   10 
 arch/s390/kernel/sysinfo.c              |   11 
 arch/sh/include/asm/sfp-machine.h       |   10 
 arch/sh/math-emu/math.c                 |   51 
 arch/sparc/include/asm/sfp-machine_32.h |    3 
 arch/sparc/include/asm/sfp-machine_64.h |    3 
 arch/sparc/math-emu/math_32.c           |  144 -
 arch/sparc/math-emu/math_64.c           |  140 -
 include/math-emu/double.h               |  398 ++--
 include/math-emu/op-1.h                 |  554 +++---
 include/math-emu/op-2.h                 | 1136 ++++++------
 include/math-emu/op-4.h                 | 1457 ++++++++-------
 include/math-emu/op-8.h                 |  211 +-
 include/math-emu/op-common.h            | 2927 ++++++++++++++++++++++----------
 include/math-emu/quad.h                 |  434 +++-
 include/math-emu/single.h               |  233 +-
 include/math-emu/soft-fp.h              |  367 ++--
 39 files changed, 5433 insertions(+), 3196 deletions(-)

Re: [PATCH RESEND] Update kernel math-emu code from current glibc soft-fp

[Joseph Myers]

On Tue, 30 Jun 2015, Michael Ellerman wrote:

> Is there some way you can imagine of splitting this up into smaller chunks, so
> that different arches can merge the pieces separately?

Well, it could be split as:

1. Rename include/math-emu to math-emu-old and update architectures for 
the renaming (mechanically).

2. Add new include/math-emu.

3,4,5,6,7. Move each architecture from math-emu-old to math-emu.

8. Remove math-emu-old.

You still have patch 1 affecting all five architectures, but with the 
per-architecture changes being much simpler.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH RESEND] Update kernel math-emu code from current glibc soft-fp

[Michael Ellerman]

On Tue, 2015-06-30 at 10:48 +0000, Joseph Myers wrote:
> On Tue, 30 Jun 2015, Michael Ellerman wrote:
> 
> > Is there some way you can imagine of splitting this up into smaller chunks, so
> > that different arches can merge the pieces separately?
> 
> Well, it could be split as:
> 
> 1. Rename include/math-emu to math-emu-old and update architectures for 
> the renaming (mechanically).
> 
> 2. Add new include/math-emu.
> 
> 3,4,5,6,7. Move each architecture from math-emu-old to math-emu.
> 
> 8. Remove math-emu-old.
> 
> You still have patch 1 affecting all five architectures, but with the 
> per-architecture changes being much simpler.

OK. That's obviously a bit more churn, but I think it's probably the best
approach. Unless someone else has a better idea?

cheers

Re: [PATCH RESEND] Update kernel math-emu code from current glibc soft-fp

[Geert Uytterhoeven]

On Wed, Jul 1, 2015 at 12:18 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> On Tue, 2015-06-30 at 10:48 +0000, Joseph Myers wrote:
>> On Tue, 30 Jun 2015, Michael Ellerman wrote:
>>
>> > Is there some way you can imagine of splitting this up into smaller chunks, so
>> > that different arches can merge the pieces separately?
>>
>> Well, it could be split as:
>>
>> 1. Rename include/math-emu to math-emu-old and update architectures for
>> the renaming (mechanically).
>>
>> 2. Add new include/math-emu.
>>
>> 3,4,5,6,7. Move each architecture from math-emu-old to math-emu.
>>
>> 8. Remove math-emu-old.
>>
>> You still have patch 1 affecting all five architectures, but with the
>> per-architecture changes being much simpler.
>
> OK. That's obviously a bit more churn, but I think it's probably the best
> approach. Unless someone else has a better idea?

Does it make that much of a difference?

You said:
| However in it's current form it's not easily mergeable, because it
touches five
| architectures and has the potential to cause breakage on all of them.

Patch 1 still touches five architectures.
Patches 3-7 still have the potential to break an architecture, but only one of
them at a time.

From a bisectability point of view there's no change.
Except that patch 1 (and 8) may break something, too ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH RESEND] Update kernel math-emu code from current glibc soft-fp

[Michael Ellerman]

On Wed, 2015-07-01 at 09:34 +0200, Geert Uytterhoeven wrote:
> On Wed, Jul 1, 2015 at 12:18 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> > On Tue, 2015-06-30 at 10:48 +0000, Joseph Myers wrote:
> >> On Tue, 30 Jun 2015, Michael Ellerman wrote:
> >>
> >> > Is there some way you can imagine of splitting this up into smaller chunks, so
> >> > that different arches can merge the pieces separately?
> >>
> >> Well, it could be split as:
> >>
> >> 1. Rename include/math-emu to math-emu-old and update architectures for
> >> the renaming (mechanically).
> >>
> >> 2. Add new include/math-emu.
> >>
> >> 3,4,5,6,7. Move each architecture from math-emu-old to math-emu.
> >>
> >> 8. Remove math-emu-old.
> >>
> >> You still have patch 1 affecting all five architectures, but with the
> >> per-architecture changes being much simpler.
> >
> > OK. That's obviously a bit more churn, but I think it's probably the best
> > approach. Unless someone else has a better idea?
> 
> Does it make that much of a difference?

Well yeah?

> You said:
> | However in it's current form it's not easily mergeable, because it
> touches five
> | architectures and has the potential to cause breakage on all of them.
> 
> Patch 1 still touches five architectures.

It does, but it would be mechanical, so in theory at least it should be a safe.

That patch could also go in a full release before the others, giving us the
maximum opportunity to test.

> Patches 3-7 still have the potential to break an architecture, but only one of
> them at a time.

Right. But each maintainer could take the patch for their arch and merge it as
they see fit.

The main advantage though would be if regressions are found we could revert
just the patch for a particular arch, rather than having to back out the whole
thing - which would be basically impossible.

> From a bisectability point of view there's no change.

Agreed.

The other problem if it's monolithic is who's tree does it go into? I guess
Andrews.

cheers