Open sboeuf opened 4 years ago
The sys
mod module is generated using bindgen, and it often breaks API compatibility. so it is unlikely to be made public directly.
But I am willing to put it behind internal
feature gate.
Yes a feature gate sounds fine to me.
But one question though, how do you expect something like probe.is_supported()
to be used? Or even when you want to refer to the syscall since they're not part of libc yet?
I think probe.is_supported()
accepts opcode instead of syscall. so we just need probe.is_supported(Openat2::CODE)
.
Oh yes I missed the CODE
defined for each opcode!
The syscall is for another use case I have. Since I want to use seccomp
, I need to refer the syscall number, and I would have preferred to rely on the crate rather than having to define it (again) myself.
I think we can export them in a stable way from sys
mod. It is only necessary to ensure that no accidental API breakage occurs.
We can have a syscall
mod and put __NR_io_uring_register
and other things in it. but I am not sure if this is necessary, I expect them to enter libc in the future.
Maybe an internal
feature gate is enough, because we can expect the syscall API will not be changed.
Yes I agree the internal feature gate is maybe the easiest way to go, as we can expect libc will soon expose these syscalls, and so you would remove the internal feature gate once this happens.
The syscalls seem to be in libc
already. You probably want to update the libc crate too, since the bindgen definition of the syscall number is wrong for mips and mips64.
Great, I will switch to the definition of libc.
The
sys
module defines several constants (syscalls, operations, etc...), and it would be useful from the caller's perspective, to be able to access them.