backout from updating `pipe2` syscall to use Pipe2 flags
Review if useful to implement
- openat2*, f/madvice64
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
Build on the extensive work already done
IoUring: add fixed_fd_install, ftruncate, cmd_discard
Working on IoUring pipe flags
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
Cleanup linux/test.zig
type futex/2_* uaddr as *const u32
consider changing to *const atomic.Value(u32)
Use At Flags in fstatat
Use EpollOp in epoll_ctl syscall
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
Add futex_* operations to IoUring
Refactor Futex 2 flags into Futex2 struct
add mpol to Wait flags and fix private field as its 128 not 32
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
Update futex2_* functions and constants to use the new Futex2 type
Improve the Api of futex2_* functions to be more idiomatic Zig
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
ignore prep_openat2* for now
add non-at variant of some unlink, rename, mkdir, symlink, link
TODO: add Sync File Flags
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
Add timeout update, cancel_fd, epoll_wait, files_update, open, open_direct, f/madvice
don't implement f/madvice64 for now I doubt it is used by a lot of people in practice
Implement BufferGroup read_multishot
Try to make definition of function align as logically as posible with
liburing to make keeping our implementation in sync easy
TODO: add M/Fadvice enum flags
TODO: understand buffer_selection and how its different from BufferGroup
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
update io_uring_enter and io_uring_register syscalls to
use IoUring flags and types
Cleanup comments
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
Prefer Using aliases over packed union field
Fix bug in HANDLE_FID declaration
Use EpollOp op type and Epoll packed struct flag type in IoUring
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
Replace SO with So type and Add SO named constants for compatability
Replace SOL with Sol type and Add SOL named constants for compatability
Replace some more typed flags with their typed equivalent
Remove any unnecessary IoUring dependency on linux.*
Add TODOs for all untyped flags
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
4❯ zig test lib/std/std.zig --zig-lib-dir lib --test-filter "os.linux"
68/116 os.linux.test.test.futex2_wait...SKIP
69/116 os.linux.test.test.futex2_wake...SKIP
70/116 os.linux.test.test.futex2_requeue...SKIP
111/116 os.linux.IoUring.test.waitid...SKIP
116/116 os.linux.IoUring.test.bind/listen/connect...SKIP
111 passed; 5 skipped; 0 failed.
fix skipKernelLessThan fn to work on wsl linux
fix logical error in flags compatibility check
Update all IoUring to use the implemented flags
bandage types that affect posix for now so that the scope
doesn't become unmanageable
TODO: impl linux.SOL and linux.SO types
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
Add Shut, PF, AF, IPPROTO types
Update IoUring and test to use some of this flags
TODO: avoid breaking API and make transitioning smooth
Instead mark the previous API as deprecated for at least
One zig release while using the new in the Zig codebase
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
Add RenameFlags for IoUring renameat
Start update io_uring Types in linux.zig to use IoUring
Continue change options and flags to Typed types
Fix test cases to use updated IoUring flags and options
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
glibc and linux kernel use size_t for some field lengths while POSIX and
musl use int. This bug would have caused breakage the first time someone
tried to call sendmsg on a 64-bit big endian system when linking musl
libc.
my opinion:
* msghdr.iovlen: kernel and glibc have it right. This field should
definitely be size_t. With int, the padding bytes are wasted for no
reason.
* msghdr.controllen: POSIX and musl have it right. 4 bytes is plenty for
the length, and it saves 4 bytes next to flags.
* cmsghdr.len: POSIX and musl have it right. 4 bytes is plenty for the
length, and it saves 4 bytes since the other fields are also 32-bits
each.
The one about INT_MAX is self-evident from the type system.
The one about kernel having bad types doesn't seem accurate as I checked
the source code and it uses size_t for all the appropriate types,
matching the libc struct definition for msghdr and msghdr_const.
This is very likely full of wrong stuff. It's effectively just a copy of the
x86_64 file - needed because the former stopped using usize/isize. To be clear,
this is no more broken than the old situation was; this just makes the
brokenness explicit.
This is very likely full of wrong stuff. It's effectively just a copy of the
mips64 file - needed because the former stopped using usize/isize. To be clear,
this is no more broken than the old situation was; this just makes the
brokenness explicit.
This type is useful for two things:
* Doing non-local control flow with ucontext.h functions.
* Inspecting machine state in a signal handler.
The first use case is not one we support; we no longer expose bindings to those
functions in the standard library. They're also deprecated in POSIX and, as a
result, not available in musl.
The second use case is valid, but is very poorly served by the standard library.
As evidenced by my changes to std.debug.cpu_context.signal_context_t, users will
be better served rolling their own ucontext_t and especially mcontext_t types
which fit their specific situation. Further, these types tend to evolve
frequently as architectures evolve, and the standard library has not done a good
job keeping up, or even providing them for all supported targets.
Our usage of `ucontext_t` in the standard library was kind of
problematic. We unnecessarily mimiced libc-specific structures, and our
`getcontext` implementation was overkill for our use case of stack
tracing.
This commit introduces a new namespace, `std.debug.cpu_context`, which
contains "context" types for various architectures (currently x86,
x86_64, ARM, and AARCH64) containing the general-purpose CPU registers;
the ones needed in practice for stack unwinding. Each implementation has
a function `current` which populates the structure using inline
assembly. The structure is user-overrideable, though that should only be
necessary if the standard library does not have an implementation for
the *architecture*: that is to say, none of this is OS-dependent.
Of course, in POSIX signal handlers, we get a `ucontext_t` from the
kernel. The function `std.debug.cpu_context.fromPosixSignalContext`
converts this to a `std.debug.cpu_context.Native` with a big ol' target
switch.
This functionality is not exposed from `std.c` or `std.posix`, and
neither are `ucontext_t`, `mcontext_t`, or `getcontext`. The rationale
is that these types and functions do not conform to a specific ABI, and
in fact tend to get updated over time based on CPU features and
extensions; in addition, different libcs use different structures which
are "partially compatible" with the kernel structure. Overall, it's a
mess, but all we need is the kernel context, so we can just define a
kernel-compatible structure as long as we don't claim C compatibility by
putting it in `std.c` or `std.posix`.
This change resulted in a few nice `std.debug` simplifications, but
nothing too noteworthy. However, the main benefit of this change is that
DWARF unwinding---sometimes necessary for collecting stack traces
reliably---now requires far less target-specific integration.
Also fix a bug I noticed in `PageAllocator` (I found this due to a bug
in my distro's QEMU distribution; thanks, broken QEMU patch!) and I
think a couple of minor bugs in `std.debug`.
Resolves: #23801Resolves: #23802
