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

[Andreas Hindborg]

"Daniel Almeida" <daniel.almeida@xxxxxxxxxxxxx> writes:

>> On 16 Feb 2026, at 11:39, Danilo Krummrich <dakr@xxxxxxxxxx> wrote:
>>
>> On Mon Feb 16, 2026 at 3:21 PM CET, Daniel Almeida wrote:
>>>
>>>
>>>> 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.
>>
>> 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.

We can change the code down the road, no problem. It's not set in stone
just because we merge it without generic alloc support.

Perhaps one could imagine a simple API like in this patch being provided
by a configurable implementation behind the scenes.


Best regards,
Andreas Hindborg