RISC-V arch-specific syscalls (258/259) missing since Linux v6.11 headers

[yoinspiration]

Problem

When generating the RISC-V syscall tables with syscalls-gen (currently pinned to Linux v6.16), the entries for riscv_hwprobe (258) and riscv_flush_icache (259) disappear from src/arch/riscv64.rs / src/arch/riscv32.rs.
On crates.io syscalls-0.7.0 the table jumps directly from recvmmsg = 243 to wait4 = 260, so matching on Sysno::riscv_flush_icache fails to compile.

Reproduction

1. cargo new demo && cd demo
2. cargo add syscalls@0.7 --no-default-features
3. On a RISC-V target, reference syscalls::Sysno::riscv_flush_icache – the variant does not exist.

Root cause

Since Linux v6.11 the file arch/riscv/include/uapi/asm/unistd.h was reduced to:

#if __BITS_PER_LONG == 64
#include <asm/unistd_64.h>
#else
#include <asm/unistd_32.h>
#endif

All __NR_riscv_* macros now live in the generated headers include/generated/uapi/asm/unistd_{32,64}.h, but syscalls-gen only fetches the non-generated headers listed above, so the RISC-V arch-specific slots (258/259) are never parsed.

Suggested fix

• Short term: after fetching the RISC-V table, ensure entries 258/259 exist (inject them if missing) so published crates remain usable.
• Long term: teach syscalls-gen to follow the include chain or to replicate what scripts/syscallhdr.sh does, so it can materialize arch/riscv/include/generated/uapi/asm/unistd_{32,64}.h before parsing.

Happy to provide a PR for either approach; please advise which direction you prefer.

[jasonwhite]

I'm okay with your suggested short-term approach. The long-term approach is a bit more complicated.

Another approach would be to use https://github.com/mebeim/systrack to compile the Linux kernel for all architectures this crate should support and parse the vmlinux image to extract the syscall table.

[Xeonacid]

How about using syscall lists generated by glibc? For example, riscv64 syscall table lives in sysdeps/unix/sysv/linux/riscv/rv64/arch-syscall.h. All architectures supported by glibc has a arch-syscall.h file.

[jasonwhite]

Fixed in 73b6ffb. (I went with the long-term solution.)

v0.8.0 now includes this fix, as well as a bunch of other fixes to the riscv32 and riscv64 tables.