This allows fact information to be validated in the underlying source files,
but requires us to explicitly maintain this in appropriate version-tagged, and
architecture-tagged files. This is more explicit and safer.
This mechanism uses a special regular expression for matching a +checkconst
stanza to validate constant values, sizes and offsets. This applies to both Go
source files and assembly files.
PiperOrigin-RevId: 511867507
The current io_uring support is very limited and experimental. Disable
it by default, and add a flag to enable it for testing.
PiperOrigin-RevId: 500760451
Handling NOP operations helped us to introduce facilities to process submission
requests. Now we can proceed to adding more meaningful operations. The logical
choice for the first one is the READV operation as it is a next operation after
NOP and it is also used for the cat-like application example based of IO_URING.
PiperOrigin-RevId: 487615618
With io_uring_setup() and mmap() we can proceed with implementing a simplest
operation, namely, NOP. Once we make sure that we can send this command and
receive a response from the gVisor, we can move forward to read operation.
PiperOrigin-RevId: 485106019
This avoids the cost at startup time and allows the resulting function to
be more effectively inlined to call sites. Although these are not widely
used at the moment, this change may also be used as an example for code
generation in similar cases.
PiperOrigin-RevId: 477597333
Once the user receives a file descriptor from `io_uring_setup()`, it will be
used for the subsequent `mmap()` calls. Thus, we need to add support for it in
our iouringfs.
PiperOrigin-RevId: 477318038
Similar to Linux, we should add pseudo-filesystem iouringfs in gVisor to back
IO_URING's file descriptors. We start with stubbing `io_uring_setup(2)` so it
provides a file descriptor backed by anonfs.
PiperOrigin-RevId: 473384042
Adin ScannellandgVisor bot
Rahat MahmoodandgVisor bot
Sergey MadaminovandgVisor bot