Change sys module from private to public

[sboeuf]

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.

[quininer]

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.

[sboeuf]

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?

[quininer]

I think probe.is_supported() accepts opcode instead of syscall. so we just need probe.is_supported(Openat2::CODE).

[sboeuf]

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.

[quininer]

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.

[quininer]

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.

[sboeuf]

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.

[ericonr]

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.

[quininer]

Great, I will switch to the definition of libc.