Redox Ring Buffers Project Summary

Last year, the Redox team was awarded a grant to create Ring Buffer support akin to io_uring at the system task level, with the aim of facilitating ring buffer communications between applications and system services. This project concluded in September, with the final components integrated. The team extends gratitude to the NLnet Foundation, the NGI Zero Commons Fund, and Horizon Europe for their financial backing.

The NGI Zero Commons Fund is nearing its conclusion, but NLnet is now accepting applications for grants from new funds, Restack and Code Supply, as well as smaller theme funds. Applications can be submitted before November 3rd, 2026, with funding available every two months thereafter.

The team's efforts have been commendable, and the authors wish to acknowledge Ibuki, Anhad, and Jacob for their dedication. In addition to developing the Ring Buffer infrastructure for system services and drivers, an io_uring and liburing-like API for applications was developed and showcased. Significant work also went into support crates, including an async executor for drivers, as well as notable performance enhancements enabling faster switching between applications and their system services.

Traditionally, asynchronous I/O on Linux relied on the kernel’s native AIO interface, which was primarily suited for unbuffered file I/O, with buffered requests causing silent blocking. Developers also expressed concerns regarding its complexity and performance. Alternative asynchronous mechanisms like fibrils and syslets/threadlets were proposed but never integrated into the mainline Linux kernel.

In early 2019, Jens Axboe introduced the io_uring interface, which was designed to be efficient, extensible, and user-friendly. Although io_uring had initial security issues and memory leaks, these have since been resolved. io_uring was integrated into Linux 5.1 and is now widely utilized. Redox, a microkernel, manages I/O in user-space processes rather than in the kernel.

Each file description holds a handle to its scheme, allowing I/O system calls to forward requests to the scheme.

The async I/O interface, known as Redox Rings, emulates a similar mechanism to io_uring. However, unlike io_uring, which submits operations to the kernel, Redox Rings enables applications to directly submit requests to the appropriate scheme asynchronously without blocking. Furthermore, Redox Rings allows for I/O requests to be issued without any memory copying, utilizing a shared memory region between the scheme and the application that can be allocated as DMA-capable memory.

The Redox Rings API is designed to be comparable to liburing and can also be employed for general inter-process communication. For instance, it is employed for communication between the RedoxFS filesystem service and NVMed, the storage driver.

This API addition has led to notable performance improvements across various parts of Redox. A ring buffer is a circular queue backed by an array, utilizing two ring buffers shared between the application and the scheme. Each queue has a single producer and consumer, eliminating the need for shared locking mechanisms due to each index being modified by only one side.

The first ring buffer implementation has been introduced to Redox OS. Unlike Linux’s io_uring, where the submission queue (SQ) and completion queue (CQ) reside in the kernel and are inaccessible to userspace processes, Redox Rings shares the SQ and CQ exclusively between userspace processes, preventing kernel access. The redox-rings crate facilitates ring buffer communication between user-space processes, offering data structures for FFI use cases.

It employs futexes as the primary synchronization mechanism, with optional pipe file descriptor support. To ensure portability, the Redox Rings API is fashioned similarly to liburing and can also be utilized for general inter-process communication, such as between the RedoxFS filesystem service and the NVMed storage driver.