Date: Tue, 09 Jan 2018 00:20:59 -0800 (PST)
Subject: Re: [patches] [RFC] RISC-V: Don't set CLONE_BACKWARDS
In-Reply-To: <20180109081145.GA2094@lst.de>
CC: patches@groups.riscv.org, linux-kernel@vger.kernel.org,
        Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>,
        adhemerval.zanella@linaro.org
From: Palmer Dabbelt <palmer@sifive.com>
To: hch@lst.de
Message-ID: <mhng-e44b0ba0-830a-4a4a-b8fb-a9b18ccf1ae9@palmer-si-x1c4>
Mime-Version: 1.0 (MHng)
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org

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.