Re: [PATCH 09/19] LoongArch: Add system call support

[Huacai Chen <chenhuacai@gmail.com>]

Hi, Arnd,

On Wed, Jul 7, 2021 at 2:44 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wed, Jul 7, 2021 at 6:24 AM Huacai Chen <chenhuacai@gmail.com> wrote:
> > On Tue, Jul 6, 2021 at 6:17 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Tue, Jul 6, 2021 at 6:18 AM Huacai Chen <chenhuacai@loongson.cn> 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@gmail.com/

Huacai
>
>        Arnd