Why are buffers passed by value and not by reference

[tidely]

I've been testing out the library and I started wondering why the interface uses T instead of &T for writes, and &mut T for reads. The api feels clunky especially when you need to unwrap errors on a different line when wanting to keep the buffer after the call.

let (res, buf) = file.read_at(buf, 0).await;
let n = res?;

If we passed by reference, &mut T would clearly indicate that the buffer will get mutated until the future returns, while the current api doesn't. Abiding by the rust borrowing rules, it wouldn't get mutated while the kernel uses the buffer, and it would conveniently get returned afterwards.

let n = file.read_at(&mut buf, 0).await?;

While I understand why &mut [u8] wouldn't be feasable. I see that IoBufMut is only implemented for Vec<u8> and bytes::BytesMut. And this is where I could see &mut Vec<u8> working for example.

Another problem it would solve is reusing the same buffer for operations. Currently when I try to use a buffer in a loop, because I need to hand the buffer over by value, rust thinks I'm getting handed a new buffer on function return. This means I can't use it on the next iteration of the loop, since it goes out of scope, while with borrowing I could keep reusing the buffer on each iteration.

I'm definitely missing something here, but I can't seem to find the reason anywhere, so I'm asking for help

[ileixe]

Kernel should own the passing buffer because it's completion based API. You can refer https://without.boats/blog/io-uring/

[tidely]

Thanks for the reply, the article is very helpful to map out the problems with my approach. How I understood it, the main issue with the borrowing approach is the case where the userspace program wants to drop the future, but the kernel hasn't completed the I/O yet. I feel like from a ownership perspective a &mut Vec<u8> would still work, without taking the cancel-lability into account.

I did see that for the 6.12 kernel there is a patch to add async discard to io_uring, which could potentially provide a solution? Another approach would be to introduce some feature into rust itself that makes it possible to integrate a completion based api into the type system. Because of scoping, it's currently overly complicated even to reuse buffers in a loop, which is definitely a popular use case.

[NobodyXu]

I feel like from a ownership perspective a &mut Vec<u8> would still work, without taking the cancel-lability into account.

It won't work as it has to be owned.

Future in rust isn't guaranteed to be polled to end, nor is it guaranteed to be dropped.

Potential solution could be:

• introduce async future that must be polled to end (cannot be cancelled)
• introduce async drop and guarantee that some types must be dropped (otherwise it could leak).
• introduce linear type

I did see that for the 6.12 kernel there is a patch to add async discard to io_uring, which could potentially provide a solution?

I believe that's for the SSD discard via ioctl.

Io-uring already supports cancelling an in-flight I/O, but that's also an async operation.

Because of scoping, it's currently overly complicated even to reuse buffers in a loop

The buffer is actually reused by the kernel, since the kernel manages these buffers, and the kernel could even do zero-copy when possible (for network).

So for io-uring, the managed buffer API is the most efficient one.

[tidely]

Thank you, that clears up quite a few things. I knew there was a reason why it is implemented this way, I just couldn't figure out why.

Usually rust is quite explicit with types. Allocating a new buffer for each iteration of a loop just seems wrong, while in practice it isn't so bad. Passing references also clearly states when it will get modified and that the buffer can be reused afterwards. Now it's kind of up to the user to know what types of optimizations the kernel does without being able to express it in the rust code.

[NobodyXu]

Now it's kind of up to the user to know what types of optimizations the kernel does without being able to express it in the rust code.

From what I know:

• kernel managed buffer has less overhead than a &[u8], kernel doesn't have to validate it or map it into kernel address
• kernel could do zero-copy on some I/O (IIRC you have to use multi-shot as well for zero-copy to be possible)
• io-uring supports multi-shot operation using managed buffer: you could issue a single receive request, which repeatedly posts a CQE when data is available https://man7.org/linux/man-pages/man3/io_uring_prep_recv_multishot.3.html