Hi, Arnd, On Wed, Jul 7, 2021 at 2:44 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Wed, Jul 7, 2021 at 6:24 AM Huacai Chen <chenhuacai@xxxxxxxxx> wrote: > > On Tue, Jul 6, 2021 at 6:17 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > On Tue, Jul 6, 2021 at 6:18 AM Huacai Chen <chenhuacai@xxxxxxxxxxx> wrote: > > > > diff --git a/arch/loongarch/include/uapi/asm/unistd.h b/arch/loongarch/include/uapi/asm/unistd.h > > > > new file mode 100644 > > > > index 000000000000..6c194d740ed0 > > > > --- /dev/null > > > > +++ b/arch/loongarch/include/uapi/asm/unistd.h > > > > @@ -0,0 +1,7 @@ > > > > +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ > > > > +#define __ARCH_WANT_NEW_STAT > > > > > > Why do you need newstat? I think now that we have statx and the libc > > > emulation code on top of it, there is probably no need to support both > > > on the kernel side. > > > > > > > +#define __ARCH_WANT_SYS_CLONE > > > > +#define __ARCH_WANT_SYS_CLONE3 > > > > > > Similarly, if you have clone3, you should not need clone. > > > > > > > +#define __ARCH_WANT_SET_GET_RLIMIT > > > > > > And here for prlimit64 > > > > Is newstat()/clone()/setrlimit() completely unacceptable in a new > > arch? If not, I want to keep it here for compatibility, because there > > are some existing distros. > > I'd say they should go. None of these are normally called directly by > applications, so if you just update the C library to redirect the user > level interfaces to the new system calls, I expect no major problems > here as long as you update libc along with the kernel in the existing > distros. > Any application using seccomp to allow only the old system calls > may need a small update, but it would need that anyway to work > with future libc implementations. > > Generally speaking there should be no expectation that the > system call interface is stable until the port is upstream. Note that > you will face a similar problem with the libc port, which may also > change its interface from what you are using internally. I found that the latest glibc is not ready for clone3, the last patchset [1] still breaks something, so I think we should keep clone. For newstat, I found that the latest glibc only use statx for 32bit kernel, while 64bit kernel still use newstat. So, it seems that we can only remove __ARCH_WANT_SET_GET_RLIMIT. [1] https://patchwork.sourceware.org/project/glibc/patch/20210601145516.3553627-2-hjl.tools@xxxxxxxxx/ Huacai > > Arnd
