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.
Arnd
