From: "Arnd Bergmann" <arnd@arndb.de>
To: "Heiko Carstens" <hca@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>,
"Sven Schnelle" <svens@linux.ibm.com>,
"Andreas Krebbel" <krebbel@linux.ibm.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [RFC PATCH 8/8] s390/syscalls: Switch to generic system call table generation
Date: Mon, 10 Nov 2025 21:51:53 +0100 [thread overview]
Message-ID: <f4531526-e981-4160-8369-50a8c8d86e36@app.fastmail.com> (raw)
In-Reply-To: <20251110185440.2667511-9-hca@linux.ibm.com>
On Mon, Nov 10, 2025, at 19:54, Heiko Carstens wrote:
> The s390 syscall.tbl format differs slightly from most others, and
> therefore requires an s390 specific system call table generation
> script.
>
> With compat support gone use the opportunity to switch to generic
> system call table generation. The abi for all 64 bit system calls is
> now common, since there is no need to specify if system call entry
> points are only for 64 bit anymore.
>
> Furthermore create the system call table in C instead of assembler
> code in order to get type checking for all system call functions
> contained within the table.
Thanks a lot for taking care of this!
I had a good look at the patch and checked that there are no
stale syscalls that are no longer needed, the formatting,
and the way this interfaces with the perf code that parses
the same table. Everything looks good as far as I can see.
> +161 common sched_rr_get_interval sys_sched_rr_get_interval
> +162 common nanosleep sys_nanosleep
> +163 common mremap sys_mremap
> +167 common query_module
> +168 common poll sys_poll
> +169 common nfsservctl
> +172 common prctl sys_prctl
Nothing wrong with your patch, but while reading through this, I noticed
that we are somewhat inconsistent about syscalls that are gone, with
three possible methods:
# 167 was query_module
167 common query_module sys_ni_syscall
167 common query_module
You use the third one now, which is the same as x86 but nothing
else. The second one using an explicit 'sys_ni_syscall' is the
most common and has the same effect, so maybe use that as well.
Eventually we may want to convert everything to the first method
and drop the syscall macros, but that would be visible in
user-space and might cause regression, so it should be a
separate series across all architectures if we want to go there.
I believe we just chickened out when we did the conversion to
syscall.tbl format originally and just left whatever was
in the unistd.h headers at the time.
Arnd
next prev parent reply other threads:[~2025-11-10 20:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-10 18:54 [RFC PATCH 0/8] s390: Remove compat support Heiko Carstens
2025-11-10 18:54 ` [RFC PATCH 1/8] s390/ptrace: Rename psw_t32 to psw32_t Heiko Carstens
2025-11-10 18:54 ` [RFC PATCH 2/8] s390/kvm: Use psw32_t instead of psw_compat_t Heiko Carstens
2025-11-10 18:54 ` [RFC PATCH 3/8] s390/syscalls: Add pt_regs parameter to SYSCALL_DEFINE0() syscall wrapper Heiko Carstens
2025-11-10 18:54 ` [RFC PATCH 4/8] tools: Remove s390 compat support Heiko Carstens
2025-11-10 18:54 ` [RFC PATCH 5/8] s390: Remove " Heiko Carstens
2025-11-10 21:33 ` Arnd Bergmann
2025-11-11 11:34 ` Heiko Carstens
2025-11-10 18:54 ` [RFC PATCH 6/8] s390/uapi: Remove 31 bit support from uapi header files Heiko Carstens
2025-11-10 18:54 ` [RFC PATCH 7/8] s390/syscalls: Remove system call table pointer from thread_struct Heiko Carstens
2025-11-10 18:54 ` [RFC PATCH 8/8] s390/syscalls: Switch to generic system call table generation Heiko Carstens
2025-11-10 20:51 ` Arnd Bergmann [this message]
2025-11-11 11:36 ` Heiko Carstens
2025-11-11 12:41 ` [RFC PATCH 0/8] s390: Remove compat support Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f4531526-e981-4160-8369-50a8c8d86e36@app.fastmail.com \
--to=arnd@arndb.de \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=krebbel@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=svens@linux.ibm.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®