On Fri, Jun 21, 2019 at 04:20:15PM +0200, Arnd Bergmann wrote: > On Fri, Jun 21, 2019 at 1:18 PM Christian Brauner <christian@xxxxxxxxxx> wrote: > > On Fri, Jun 21, 2019 at 11:37:50AM +0200, Arnd Bergmann wrote: > > > > > > I never really liked having __ARCH_WANT_SYS_CLONE here > > > because it was the only one that a new architecture needed to > > > set: all the other __ARCH_WANT_* are for system calls that > > > are already superseded by newer ones, so a new architecture > > > would start out with an empty list. > > > > > > Since __ARCH_WANT_SYS_CLONE3 replaces > > > __ARCH_WANT_SYS_CLONE for new architectures, how about > > > leaving __ARCH_WANT_SYS_CLONE untouched but instead > > > > __ARCH_WANT_SYS_CLONE is left untouched. :) > > > > > coming up with the reverse for clone3 and mark the architectures > > > that specifically don't want it (if any)? > > > > Afaict, your suggestion is more or less the same thing what is done > > here. So I'm not sure it buys us anything apart from future > > architectures not needing to set __ARCH_WANT_SYS_CLONE3. > > > > I expect the macro above to be only here temporarily until all arches > > have caught up and we're sure that they don't require assembly stubs > > (cf. [1]). A decision I'd leave to the maintainers (since even for > > nios2 we were kind of on the fence what exactly the sys_clone stub was > > supposed to do). > > > > But I'm happy to take a patch from you if it's equally or more simple > > than this one right here. > > > > In any case, linux-next should be fine on all arches with this fixup > > now. > > I've looked at bit more closely at the nios2 implementation, and I > believe this is purely an artifact of this file being copied over > from m68k, which also has an odd definition. The glibc side > of nios2 clone() is also odd in other ways, but that appears > to be unrelated to the kernel ABI. > > I think the best option here would be to not have any special > cases and just hook up clone3() the same way on all > architectures, with no #ifdef at all. If it turns out to not work > on a particular architecture later, they can still disable the > syscall then. Hm, if you believe that this is fine and want to "vouch" for it by whipping up a patch that replaces the wiring up done in [1] I'm happy to take it. :) Otherwise I'd feel more comfortable not adding all arches at once. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/log/?h=clone Christian
