Messages in this thread | | | Date | Tue, 09 Jan 2018 00:20:59 -0800 (PST) | Subject | Re: [patches] [RFC] RISC-V: Don't set CLONE_BACKWARDS | From | Palmer Dabbelt <> |
| |
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.
| |