-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generate linux syscalls via the Linux source tree #11447
Conversation
Also, I'm generating the new list based on the 5.17 stable release. I checked 5.18 and there were no changes. This means that some new entries have been added since the lists were last updated. |
New syscalls are meant to be consistent between architectures. Only older syscalls (for which the work has already been done) should differ. |
True, I think alpha is the the only exception. It seems all the archs. sync up from |
I think you need to rebase against master, as in CI zig fmt broke for 261 + cd /workspace
262 + /workspace/_debug/staging/bin/zig fmt --check . --exclude test/compile_errors/
263 ./_debug/staging/lib/zig/std/os/linux/syscalls.zig
264 ./lib/std/os/linux/syscalls.zig cool stuff btw. sounds also useful to store these information in a portable way for other projects to reuse (ie JSON). |
Done. I also missed a space for the switch, which was probably causing the CI to fail. |
lib/std/os/linux/syscalls.zig
Outdated
@@ -0,0 +1,3487 @@ | |||
// This file is automatically generated. | |||
// See tools/generate_linux_syscalls.zig for more info. | |||
pub const SYS = switch (@import("builtin").cpu.arch) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this were a fn
which returned the enum type instead:
- zls would autocomplete it for the current architecture
- applications could use the syscall numbers for a different architecture (dont know the usecase)
For example:
pub fn NewSYS(comptime arch: @TypeOf(@import("builtin").cpu.arch)) type {
return switch (arch) {
// rest of code
};
}
pub const SYS = NewSYS(@import("builtin").cpu.arch);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My first versions had separate enum
s for each arch and a public SYS
that switched for the correct one, similar to how it is now with linux.arch_bits
. The only use for different variables would be checking the syscall numbers in a seccomp program.
When you say:
zls would autocomplete it for the current architecture
is this something that can be fixed in zls?
some questions on the generality of the approach:
/* Flags to be set in the 'posix_spawnattr_t'. */
#if @HAVE_POSIX_SPAWN@
/* Use the values from the system, but provide the missing ones. */
# ifndef POSIX_SPAWN_SETSCHEDPARAM
# define POSIX_SPAWN_SETSCHEDPARAM 0
# endif
# ifndef POSIX_SPAWN_SETSCHEDULER
# define POSIX_SPAWN_SETSCHEDULER 0
# endif
#else
# if @REPLACE_POSIX_SPAWN@
/* Use the values from the system, for better compatibility. */
/* But this implementation does not support AIX extensions. */
# undef POSIX_SPAWN_FORK_HANDLERS
# else
# define POSIX_SPAWN_RESETIDS 0x01
# define POSIX_SPAWN_SETPGROUP 0x02
# define POSIX_SPAWN_SETSIGDEF 0x04
# define POSIX_SPAWN_SETSIGMASK 0x08
# define POSIX_SPAWN_SETSCHEDPARAM 0x10
# define POSIX_SPAWN_SETSCHEDULER 0x20
# endif
#endif
reminder for me: https://dev.midipix.org/runtime/psxtypes/issue/1 |
Since a month has passed and no-one has commented on my TODOs, I'm going to mark this as ready for review after some changes:
|
I'm generally in favor of this approach. Looking forward to reviewing it, when it is ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this work!
I have some small requested changes to move some stuff around, but if those are addressed then I think this is ready to be merged.
Don't worry about what ZLS can or can't do. It's a third party project that is implemented in a fundamentally limited way; I have plans for more sophisticated IDE integration that are directly part of the Zig project itself.
Previously, updating the `SYS` enum for each architecture required manually looking at the syscall tables and inserting any new additions. This commit adds a tool, `generate_linux_syscalls.zig`, that automates this process using the syscall tables in the Linux source tree. On architectures without a table, it runs `zig cc` as a pre-processor to extract the system-call numbers from the Linux headers.
Currently, all supported Linux architectures have a hand-written
SYS
enum. Updating the list is done in an ad-hoc, manual process:newfstatat
->fstatat64
).This process is error prone, and can introduce subtle errors in the list.
For example, the
aarch64
list containsarch_specific_syscall
- this is an offset, not a syscall. See the riscv64 list for how it handles this.The solution would be to automate the list generation directly from the Linux source tree, which is what this commit does.
A new tool -
generate_linux_syscalls.zig
- generates theSYS
for each arch using the syscall tables in the Linux source tree. On architectures without a table, it runszig cc
as a pre-processor to extract the system-call numbers from the Linux headers.I'm marking this as a draft to see if any of my TODOs could be resolved. Otherwise, I think it's ready as is - barring CI errors.