[LTP] [PATCH v2 1/5] Update architectures syscalls identifiers
Andrea Cervesato
andrea.cervesato@suse.com
Fri Mar 20 14:21:14 CET 2026
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
More information about the ltp
mailing list