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.
