During the glibc upstreaming it was suggested that CLONE_BACKWARDS was a
deprecated ABI decision. I think we just copied it from ARM, but I
don't see any reason to favor one over the other.
While we haven't released yet so I think it's still legal to change our
ABI, I'd actually kind of prefer to avoid changing our ABI this late in
the game. I guess this is more of an RFC than a patch: is there a
reason to avoid CLONE_BACKWARDS?
Note that I haven't tried any of this -- I'll give it some thourough
testing and submit an actual patch if this is the way we want to go.
CC: Adhemerval Zanella <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/riscv/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 2c6adf12713a..02076f3a2883 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -10,7 +10,6 @@ config RISCV
select OF_IRQ
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_WANT_FRAME_POINTERS
- select CLONE_BACKWARDS
select COMMON_CLK
select GENERIC_CLOCKEVENTS
select GENERIC_CPU_DEVICES
--
2.13.6
On Mon, Jan 08, 2018 at 05:27:56PM -0800, Palmer Dabbelt wrote:
> During the glibc upstreaming it was suggested that CLONE_BACKWARDS was a
> deprecated ABI decision. I think we just copied it from ARM, but I
> don't see any reason to favor one over the other.
>
> While we haven't released yet so I think it's still legal to change our
> ABI, I'd actually kind of prefer to avoid changing our ABI this late in
> the game. I guess this is more of an RFC than a patch: is there a
> reason to avoid CLONE_BACKWARDS?
>
> Note that I haven't tried any of this -- I'll give it some thourough
> testing and submit an actual patch if this is the way we want to go.
I see absolutely no reason to change this. Linux currently has 30
architecture port, out of which 10 (including riscv, i386, arm and arm64)
set CLONE_BACKWARDS.
There are no performance benefits of doing it one way or another, and
changing it now will break all the riscv enablement that's been going
on.
On Tue, 09 Jan 2018 00:11:45 PST (-0800), [email protected] wrote:
> On Mon, Jan 08, 2018 at 05:27:56PM -0800, Palmer Dabbelt wrote:
>> During the glibc upstreaming it was suggested that CLONE_BACKWARDS was a
>> deprecated ABI decision. I think we just copied it from ARM, but I
>> don't see any reason to favor one over the other.
>>
>> While we haven't released yet so I think it's still legal to change our
>> ABI, I'd actually kind of prefer to avoid changing our ABI this late in
>> the game. I guess this is more of an RFC than a patch: is there a
>> reason to avoid CLONE_BACKWARDS?
>>
>> Note that I haven't tried any of this -- I'll give it some thourough
>> testing and submit an actual patch if this is the way we want to go.
>
> I see absolutely no reason to change this. Linux currently has 30
> architecture port, out of which 10 (including riscv, i386, arm and arm64)
> set CLONE_BACKWARDS.
>
> There are no performance benefits of doing it one way or another, and
> changing it now will break all the riscv enablement that's been going
> on.
OK, works for me! Unless anyone has a strong argument against CLONE_BACKWARDS
we're just going to leave it alone.