mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "André Almeida" <andrealmeid@igalia.com>
Cc: linux-kernel@vger.kernel.org,
	"Masami Hiramatsu" <mhiramat@kernel.org>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Thomas Gleixner" <tglx@kernel.org>,
	linux-kbuild@vger.kernel.org, kernel-dev@igalia.com
Subject: Re: [PATCH RFC v3 0/8] syscalls: Add a shared table for all archs
Date: Mon, 10 Aug 2026 16:18:03 +0200	[thread overview]
Message-ID: <cd8a7da8-bb01-4b03-9f1b-1132c1bd7662@app.fastmail.com> (raw)
In-Reply-To: <52ad6a69-3623-4013-aeb6-60b6be88a4ff@igalia.com>

On Mon, Aug 10, 2026, at 15:25, André Almeida wrote:
> Em 07/08/2026 17:43, Arnd Bergmann escreveu:
>> On Fri, Aug 7, 2026, at 21:34, André Almeida wrote:
>>>
>>> There's already a "common" table shared with a bunch of archs at
>>> `scripts/syscall.tbl`, but due to historical reasons some archs will never be
>>> able to move to this table and share all the numbers.
>>>
>>> The generic table starts from 403 (clock_gettime64), the first common syscall.
>>>
>>> I've compile tested for arm32, arm64, s390, mips and sparc, by comparing the
>>> syscalls_*.h and unistd_*.h files generated before and after this patchset. For
>>> most of cases the files are identical, for the few cases that they are not,
>>> there's a note in the commit explaining why they are equivalent.
>> 
>> Any reason you still didn't include the alpha version? As I mentioned
>> before, I think this is the most important one to be in the initial
>> set, to ensure the script can deal with the having two separate offsets
>> without becoming too messy, or needing a rewrite to take multiple passes.
>
> One reason that I didn't include alpha on this version yet (but forgot 
> to explain in the cover letter) is that alpha is the only arch that 
> doesn't implement `set_mempolicy_home_node`, and the commit message that 
> creates this syscall doesn't help to explain why. But for now I think I 
> can do something similar to `memfd_secret` and add a new ABI or use the 
> stub implementation.

No, I think we can just keep the normal table here. There is
already a definition for the syscall macro on alpha, just the
entry point is set to sys_ni_syscall. On alpha, CONFIG_NUMA
is always disabled as of fdb7d9b7acd0 ("alpha: remove DISCONTIGMEM
and NUMA"), so sys_mempolicy_home_node always points to
sys_ni_syscall through the kernel/sys_ni.c redirect.

I would split that change out to a separate commit, but that
patch is clearly only cosmetic here.

We probably want the same thing for memfd_secret() as well, and
always define that for all architectures, with the kernel/sys_ni.c
file taking care of the CONFIG_SECRETMEM=n builds, but that is
not entirely a nop, since it adds a __NR_memfd_seret macro
on architectures that don't already have it.

       Arnd

      reply	other threads:[~2026-08-10 14:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-07 19:34 André Almeida
2026-08-07 19:34 ` [PATCH RFC v3 1/8] syscalls: Make --abis parsing more robust André Almeida
2026-08-07 19:34 ` [PATCH RFC v3 2/8] syscalls: Create unified partial table for all archs André Almeida
2026-08-07 20:40   ` Arnd Bergmann
2026-08-10 13:19     ` André Almeida
2026-08-10 14:22       ` Arnd Bergmann
2026-08-07 19:34 ` [PATCH RFC v3 3/8] scripts/syscall.tbl: Use the common table André Almeida
2026-08-07 19:34 ` [PATCH RFC v3 4/8] arm: Use the common syscall table André Almeida
2026-08-07 19:34 ` [PATCH RFC v3 5/8] s390: " André Almeida
2026-08-07 19:34 ` [PATCH RFC v3 6/8] sparc: " André Almeida
2026-08-07 19:34 ` [PATCH RFC v3 7/8] mips: Remove duplicated syscallnr.sh André Almeida
2026-08-07 19:34 ` [PATCH RFC v3 8/8] mips: Use the common syscall table André Almeida
2026-08-07 21:02   ` Arnd Bergmann
2026-08-10 13:20     ` André Almeida
2026-08-07 20:43 ` [PATCH RFC v3 0/8] syscalls: Add a shared table for all archs Arnd Bergmann
2026-08-10 13:25   ` André Almeida
2026-08-10 14:18     ` Arnd Bergmann [this message]

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=cd8a7da8-bb01-4b03-9f1b-1132c1bd7662@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=andrealmeid@igalia.com \
    --cc=kernel-dev@igalia.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=nathan@kernel.org \
    --cc=tglx@kernel.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®