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

[Andreas Hindborg <a.hindborg@kernel.org>]

"Danilo Krummrich" <dakr@kernel.org> writes:

> On Tue Feb 17, 2026 at 11:02 AM CET, Andreas Hindborg wrote:
>> 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.
>
> Just to avoid any ambiguity, we should merge it with generic allocator support,
> but aiming for arbitrary I/O backend support would be a bit too much.

Right.

>
>> Perhaps one could imagine a simple API like in this patch being provided
>> by a configurable implementation behind the scenes.
>
> Yeah, in the future we could implement the system memory specific one with a
> type alias on top of the I/O backend agnostic one. But it remains to see if this
> will actually work out properly or if it's even worth in terms of
> maintainability etc.
>
> (E.g. one of the limitations that I've mentioned already is that I/O backends do
> not support growing and shrinking of the backing memory. And I'm not yet sure if
> they ever should.)

This particular ringbuffer* implementation does not support changing the
capacity after initialization, so I don't see that being an issue. For
applications that need to scale the size of the ring dynamically, we
could have another type. Or a generic parameter, if that makes sense.

Best regards,
Andreas Hindborg


* VecDeque? This kind of structure has always been a ring to me.