Use libc::SYS_futex_time64 on riscv32

[kraj]

On RISC-V 32-bit (riscv32), the SYS_futex system call is often handled indirectly due to the use of a 64-bit time_t type. Specifically, while SYS_futex is not directly defined, a related syscall like SYS_futex_time64 can be used,

[josephlr]

I don't think this patch is necessary. For RISC-V Linux or Android, we will never use this fallback backend (use_file.rs).

Specifically on RISC-V, this crate will always use the getrandom(2) syscall, so we don't need to deal with Futexs at all.

Were you encountering a build issue with RISC-V?

[kraj]

I don't think this patch is necessary. For RISC-V Linux or Android, we will never use this fallback backend (use_file.rs).

Specifically on RISC-V, this crate will always use the getrandom(2) syscall, so we don't need to deal with Futexs at all.

Were you encountering a build issue with RISC-V?

I am building for riscv32, it works ok for riscv64, riscv32 is newish 32bit architecture and it does not have 32bit time_t but directly implemented 64bit time_t, so lot of 32bit leacy syscalls are not there.

[newpavlov]

Do you encounter a compilation or a runtime error? The latter should not happen on a modern Linux kernel since the getrandom syscall should be available and the fallback path will not be triggered. The former should not happen as well since the libc crate defines the necessary constants for RV32 targets and we link only to the syscall function.

[newpavlov]

Closing this since we do not compile the use_file module on RISC-V targets since they require a high enough kernel version (see here), so we unconditionally use the getrandom backend without any fallback.

[kraj]

Do you encounter a compilation or a runtime error? The latter should not happen on a modern Linux kernel since the getrandom syscall should be available and the fallback path will not be triggered. The former should not happen as well since the libc crate defines the necessary constants for RV32 targets and we link only to the syscall function.

I am getting build time failure on riscv32/musl/linux ( what you pointed to is for a glibc based system ) where SYS_futex might exist but musl does not do translations like glibc.

[kraj]

Closing this since we do not compile the use_file module on RISC-V targets since they require a high enough kernel version (see here), so we unconditionally use the getrandom backend without any fallback.

Key is https://github.com/rust-random/getrandom/blob/03ec647de15d5c6c4e891261df7cd9ea5ca7d39d/src/backends.rs#L103C17-L103C37
it falls back for all musl systems and I am using musl. This PR make it portable since it does not rely on glibc assumption.

Please reconsider this PR, it makes it portable across Linux, ( linux systems dont just use glibc, there are other C library runtimes e.g. musl, uclibc etc. which are supported ) and some distros e.g. apline is ( linux/musl ) use them

[newpavlov]

it falls back for all musl systems and I am using musl.

I see. Then a better solution would be to add MUSL-based RV32/64 to the list of targets which use getrandom without fallback.

[newpavlov]

You also could ask libc developers to add the SYS_futex constant for MUSL-based RV32 targets. It may be a simple omission on their part.

[kraj]

You also could ask libc developers to add the SYS_futex constant for MUSL-based RV32 targets. It may be a simple omission on their part.

This is intentional in musl, they only define what kernel exports.

[kraj]

it falls back for all musl systems and I am using musl.

I see. Then a better solution would be to add MUSL-based RV32/64 to the list of targets which use getrandom without fallback.

let me see in this direction

[kraj]

it falls back for all musl systems and I am using musl.

I see. Then a better solution would be to add MUSL-based RV32/64 to the list of targets which use getrandom without fallback.

let me see in this direction

posted a new PR - #699