Date: Tue, 9 Jan 2018 09:11:45 +0100
From: Christoph Hellwig <hch@lst.de>
To: patches@groups.riscv.org
Cc: linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
        Olof Johansson <olof@lixom.net>,
        Palmer Dabbelt <palmer@sifive.com>,
        Adhemerval Zanella <adhemerval.zanella@linaro.org>
Subject: Re: [patches] [RFC] RISC-V: Don't set CLONE_BACKWARDS
Message-ID: <20180109081145.GA2094@lst.de>
References: <20180109012756.2401-1-palmer@sifive.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180109012756.2401-1-palmer@sifive.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Sender: linux-kernel-owner@vger.kernel.org

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.