[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