Generate linux syscall constants #1759
Conversation
The syscall numbers are independent of used libc.
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @JohnTitor (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
... except for hexagon which seems to have something odd going on with
syscall numbers >1000.
Also do not test the validity of the values because libc is regularly
missing newer syscall numbers.
For those archs which use the newer unified asm-generic/unistd.h numbers
we generate too many constants because
a) some syscalls are optional
b) we cannot perform the necessary tests without significant effort.
This is not too problematic because the worst that can happen is ENOSYS
which also happens when newer syscalls are executed on older kernels.
|
Hey, thanks for the PR! But this is a major change to our process, so I think we need to discuss it before reviewing. |
|
Just to be clear: The syscalls are generated manually and not during the build. So the process stays the same unless you want to add new syscalls which you should then do by using the script. |
|
@JohnTitor What's the status of this? |
|
That's great that we could cover many syscalls here but I'm reluctant to this because this will affect too many targets at once. |
|
Adding new linux syscall numbers affects all linux targets. This is your objection? |
|
☔ The latest upstream changes (presumably #1805) made this pull request unmergeable. Please resolve the merge conflicts. |
|
@JohnTitor Can I assume that this PR will stay in limbo indefinitely? You've said that it needs to be "discussed" but I've seen no such discussion nor any concerns raised beyond "it affects all linux targets". Please close the PR if you have no interest in the changes. |
|
Sorry for my absence! So, as I said this would affect the targets broadly, and I concerned that this may introduce some inconsistencies. Since the current workflow is fine to maintain, I'm going to close this. |
|
In case this is getting revived, the script I'm using to generate the syscall list for the syscallz crate is located here: https://github.com/kpcyrd/syscallz-rs/blob/main/gen.py This is lightly tested on the major debian architectures: https://buildd.debian.org/status/package.php?p=rust-syscallz |
Tl;dr: Many syscall constants were missing so I've written a small script that generates the constants from kernel sources.
As a first step I've reduced the duplication between glibc and musl by creating a new sibling module which is supposed to contain kernel structures and constants. There are many of those that could be moved out of the libc modules but for now I've only moved the syscall constants.
This violates the bottom-up design of the library but this design is not suitable for a system with multiple libcs because a significant part of their surface will be identical reexports of kernel structures and constants.