[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <3a138dda-5351-41ac-8c91-f7295036729e@app.fastmail.com>
Date: Thu, 04 Jul 2024 23:44:36 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Linus Torvalds" <torvalds@...ux-foundation.org>,
"Jason A . Donenfeld" <Jason@...c4.com>
Cc: "Jiri Olsa" <jolsa@...nel.org>, "Masami Hiramatsu" <mhiramat@...nel.org>,
cgzones@...glemail.com, "Christian Brauner" <brauner@...nel.org>,
linux-kernel@...r.kernel.org
Subject: Re: deconflicting new syscall numbers for 6.11
On Thu, Jul 4, 2024, at 23:07, Linus Torvalds wrote:
>
> - even 64-bit architectures don't necessarily have anything like a
> vdso, eg alpha.
>
> It looks like you randomly just picked the architectures that have a
> syscall.tbl file, rather than architectures where this made sense. I
> thin kyou should drop all of them except possibly arm64, s390 and
> powerpc.
It's not random, it's all the architectures: the ones that
don't have a syscall.tbl file are the ones that use the table
in include/uapi/asm-generic/unistd.h. I generally recommend
doing it like to ensure all architectures define the same
__NR_* macro for new syscalls even if the implementation
gets added later. As you say, this one is a special because
it's not useful without a vdso, but that doesn't require making
it more special than necessary by adding it selectively.
In particular, if the entries above number 402 are kept
consistent across all architectures are the same, we can
more easily move them into a shared file in the future to
avoid some of the complexity of adding syscalls.
Arnd
Powered by blists - more mailing lists