On Wed, Nov 30, 2022, at 11:06, Jason A. Donenfeld wrote:

On Wed, Nov 30, 2022 at 09:56:06AM +0100, Geert Uytterhoeven wrote:

quoted

Hi Jason,

On Tue, Nov 29, 2022 at 10:09 PM Jason A. Donenfeld [off-list ref] wrote:

quoted

Add vgetrandom_alloc() as syscall 451 (or 561 on alpha) by adding it to
all of the various syscall.tbl and unistd.h files.

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Thanks for your patch!

What's the policy regarding adding syscall numbers for VDSO-related
syscalls on architectures that do not support VDSOs yet?

I don't know exactly what the /policy/ is, but not wanting to rock the
boat, the first iterations of this series only added it to x86. But then
Arnd joined the thread and said I should add it to all of them all at
once and separate that out into this commit, so that's what we have
here. I think the idea is to keep syscall numbers synchronized these
days between archs if possible.

Right, it shouldn't matter if the syscall has anything to do with vdso
or some other feature, the important bit is that this is an optional
syscall that may or may not exist in a kernel.

Adding every new syscall number to all architectures helps avoid
merge conflicts and keeps the numbers synchronized. It's entirely
plausible that this one gets enabled on an architecture that starts
out with the default -ENOSYS implementation, and has that
backported to 6.2 (or even older kernels in principle) for a
distro release, so it also makes sense to have it in the uapi
table as soon as we have fixed the number.

     Arnd