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

[Daniel Almeida]

> On 16 Feb 2026, at 11:06, Danilo Krummrich <dakr@xxxxxxxxxx> 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.


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

— Daniel