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

[Daniel Almeida <daniel.almeida@collabora.com>]

> On 16 Feb 2026, at 11:39, Danilo Krummrich <dakr@kernel.org> wrote:
> 
> 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.

Might very well be the case, yeah.

> 
> 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

Fine, let’s stick to VecDeque then. From what I am reading above, there
doesn’t seem to be any naks for a more general ring buffer type due to the
current patch; it’s just not a good time yet. In which case, there’s no
complaints from me.

— Daniel