Re: [PATCH] rust: add a ring buffer implementation

["Danilo Krummrich" <dakr@kernel.org>]

On Mon Feb 16, 2026 at 3:21 PM CET, Daniel Almeida wrote:
>
>
>> On 16 Feb 2026, at 11:06, Danilo Krummrich <dakr@kernel.org> wrote:
>> 
>> On Mon Feb 16, 2026 at 2:45 PM CET, Daniel Almeida wrote:
>>> With the allocation being handled by a separate component, I don’t think
>>> this is right. I think a better location is rust/kernel/io
>> 
>> I'm not sure it is reasonable to ask people who just want a ringbuffer in system
>> memory to take the indirection over an I/O ringbuffer implementation with
>> generic I/O backends choosing the system memory I/O backend.
>> 
>> The proposed code is simple, without comments and tests, less than 100 lines of
>> code. The I/O infrastructure to make this happen is still WIP. So, I think it's
>> fine to land it as VecDeque for now.
>
>
> Well, this is a 100 line patch, but nothing was said of how much else was going
> to be added on top in the future. In order to avoiding iterating on what I
> consider the wrong approach, I suggested that we start out in the right
> direction from the start, something that Andreas himself apparently agreed to.

I haven't seen any commitment to implement this in terms of generic I/O backends
from Andreas.

>> Once we have the I/O backend infrastructure, a system memory I/O backend that
>> can deal with separate allocators *and* a ring buffer implementation that sits
>> on top of it, we can still revisit if it makes sense to take advantage of
>> synergies.
>> 
>> But for now this seems a bit premature in terms of delaying Andreas' work.
>
> IIUC, and feel free to correct me on this, the I/O backends are already in the
> works. What is missing is a trivial system memory backend, and similarly a
> ringbuffer implementation, which is the subject of this patch. I don't see this
> as a lot of work or an unreasonable ask.

I think you are highly underestimating the consequences of this design.

First of all, we're missing IoView (the generalization of IoSlice), which also
supports projection. Gary is working on this, but it is completely unclear when
it will land.

Second, the system memory backend would have to be implemented and needs to be
generic over arbitrary allocators. Also note that I/O backends do *not*
implement growing and shrinking of the backing memory, which would be another
limitation for a derived VecDeque type to swallow. Alternatively, it is yet
another thing we have to implement.

Then we have to implement the I/O ringbuffer type, which, due to being generic
over I/O backends, also has to consider the device lifecycle requirements for
the corresponding I/O backend, which is additional complexity as well.

So, don't get me wrong, it is a good idea and exactly in the sense of my vision
of how powerful I want the I/O infrastructure to be, but for now, I think it is
unreasonable to ask Andreas to wait for all this.

- Danilo