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:
>> Hi Jason,
>>
>> On Tue, Nov 29, 2022 at 10:09 PM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote:
>> > 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@xxxxxxxxx>
>>
>> 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
