Re: [LTP] [PATCH v2 1/5] Update architectures syscalls identifiers

Andrea Cervesato via ltp
2026-03-20T13:21:44Z

Hi,

> Hi!
> > include/lapi/syscalls/arc.in | 2 +
> > include/lapi/syscalls/arm.in | 3 +-
> > include/lapi/syscalls/arm64.in | 2 +
> > include/lapi/syscalls/i386.in | 3 +-
> > include/lapi/syscalls/loongarch64.in | 3 ++
> > include/lapi/syscalls/mips64.in | 4 +-
> > include/lapi/syscalls/mips64n32.in | 4 +-
> > include/lapi/syscalls/mipso32.in | 4 +-
> > include/lapi/syscalls/parisc.in | 3 +-
> > include/lapi/syscalls/powerpc.in | 3 +-
> > include/lapi/syscalls/powerpc64.in | 3 +-
> > include/lapi/syscalls/s390.in | 102 +++++++++--------------------------
>
> Why do we change so much in the s390.in? I'm not saying it's wrong (I
> haven't checked) but even if it's correct it at least should have been
> explained in the commit message.

I generated it automatically with generate_arch.sh script, which is verifying
that the defined syscalls are actually supported by the architecture. It's
all good when it comes to 32/64 bit variants syscalls, but it looks weird for
others.

I'm a bit puzzled as well..there is a risk that by touching so many syscalls
numbers LTP will be out of sync with the underlying kernel. Maybe I will just
add the syscalls which are really needed such as listns().

--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com