Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1174434 > unrolled thread
| Started by | Joseph Myers <joseph@codesourcery.com> |
|---|---|
| First post | 2015-06-30 12:50 +0200 |
| Last post | 2015-07-02 15:00 +0200 |
| Articles | 3 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH RESEND] Update kernel math-emu code from current glibc soft-fp Joseph Myers <joseph@codesourcery.com> - 2015-06-30 12:50 +0200
Re: [PATCH RESEND] Update kernel math-emu code from current glibc soft-fp Geert Uytterhoeven <geert@linux-m68k.org> - 2015-07-01 09:40 +0200
Re: [PATCH RESEND] Update kernel math-emu code from current glibc soft-fp Michael Ellerman <mpe@ellerman.id.au> - 2015-07-02 15:00 +0200
| From | Joseph Myers <joseph@codesourcery.com> |
|---|---|
| Date | 2015-06-30 12:50 +0200 |
| Subject | Re: [PATCH RESEND] Update kernel math-emu code from current glibc soft-fp |
| Message-ID | <pH1gZ-7OZ-9@gated-at.bofh.it> |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Geert Uytterhoeven <geert@linux-m68k.org> |
|---|---|
| Date | 2015-07-01 09:40 +0200 |
| Subject | Re: [PATCH RESEND] Update kernel math-emu code from current glibc soft-fp |
| Message-ID | <pHkMF-2aU-1@gated-at.bofh.it> |
| In reply to | #1174434 |
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Michael Ellerman <mpe@ellerman.id.au> |
|---|---|
| Date | 2015-07-02 15:00 +0200 |
| Message-ID | <pHMfU-2Nx-9@gated-at.bofh.it> |
| In reply to | #1175038 |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web