lkml.org 
[lkml]   [2018]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [patches] [RFC] RISC-V: Don't set CLONE_BACKWARDS
From
On Tue, 09 Jan 2018 00:11:45 PST (-0800), hch@lst.de 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.

\
 
 \ /
  Last update: 2018-01-14 23:18    [W:0.041 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site