Re: [PATCH v20 3/5] arch: allocate vgetrandom_alloc() syscall number

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Arnd,

On Wed, Jul 3, 2024 at 8:59 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Wed, Jul 3, 2024, at 20:31, Jason A. Donenfeld wrote:
> > Add vgetrandom_alloc() as syscall 463 (or 573 on alpha) by adding it to
> > all of the various syscall.tbl and unistd.h files.
> >
> > Acked-by: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
> > Signed-off-by: Jason A. Donenfeld <Jason@xxxxxxxxx>
>
> I checked that the system calls are all hooked up correctly
> across all architectures:
>
> Acked-by: Arnd Bergmann <arnd@xxxxxxxx>

Thanks.

> Unfortunately we now have three syscalls scheduled for
> the number 463, the other ones being uretprobe (only
> for arc, arm64, csky, hexagon, loongarch, nios2, openrisc,
> riscv and x86 for some reason) and setxattrat (on
> all architectures).
>
> It would be nice if you could all coordinate on this to
> pick unique numbers.

Stephen and I were just talking about this when looking at the linux-next merge.

Dibs on 463! Just kidding.

There's going to be merge conflicts anyway, due to the __NR_syscalls
counter changing. So I figured this is something Linus typically just
handles based on what order he merges things in. But I actually don't
know. What's the best way to handle this?

Jason





[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux