Note to any folks that see this. As of the current time of writing, these are emphatically not (yet?) bindings to all of liburing. These are only providing an interface to liburing that can be shown to be sound.
Initially, this will be basic support for any of the currently available opcodes that can be used soundly. Anything that can't be shown to be sound or has possibility of being used incorrectly will not be exposed by this API.
I've been wanting to dig deeper into io_uring for a few years now. After looking at a few Rust io_uring libraries and reading background I realized there's currently (to my knowledge) no proven safe and sound bindings to Rust. While reading this blog I realized I might actually have a viable approach.
In that article, withoutboats argues that in order to provide a sound API to io_uring, that the kernel must own the buffers. They then discuss some approaches revolving around the BufReader/BufWriter traits as well as implementing buffer pools.
First, I absolutely agree that the kernel needs to own the buffer while it's inside the io_uring. However, I disagree with the approach to relying on managed buffers. There's a very simple simplification: the kernel has to own the buffers while the buffers are in the ring. Once the buffer comes out the other end we can give ownership back the the client. And given that contract, we can allow users to do any sort of buffer management they desire so long as they own the buffers.
This was initially going to use iou as a dependency and even now still uses quite a few ideas from it. That makes this project a repackaged debt that I'm selling as safe and sound. Q.e.d, a CDO. If you're still unsure, I'll allow celebrity chef Anthony Bourdain to explain it.