[PATCH 0/8] membuff: Add tests and update to support a flag for empty/full

Simon Glass sjg at chromium.org
Fri Oct 18 16:55:51 CEST 2024


Hi Rasmus,

On Fri, 18 Oct 2024 at 01:05, Rasmus Villemoes <ravi at prevas.dk> wrote:
>
> On tor, okt 17 2024, Simon Glass <sjg at chromium.org> wrote:
>
> >
> >   membuf: Support a flag for being full
> >
>
> No, that is the worst of all worlds, especially with it being a
> build-time flag. The right implementation is the one where the head and
> tail indices are free-running, where you get such a "flag" for
> free, because you're not wasting the top bits of the indices.
>
> https://www.snellman.net/blog/archive/2016-12-13-ring-buffers/

Thanks for the link. It is an interesting read, including the
comments. I've only written one ring buffer in my life and this is it
:-)

Which option do you suggest? We don't currently restrict the size to a
power of two and that does seem like a strange restriction. It will
make it less useful, e.g. in extlinux_fill_info() and potentially
replacing memgets().

We actually don't have to worry (today) about threading, so option two
could work, I suppose. I don't like the 'length' field any more than
the author, but we could have a simple function to turn it into
(pointer plus an empty/full flag)

The power-of-two restriction could be lifted by use division instead
of masking and making sure that the indexes keep to reasonable values
(say no more than twice the buffer size). In fact with the limit, we
could just subtract the length from the index when accessing it, if
needed.

But overall I think I'm with Chris.

>
> If you want to do the churn of renaming anyway, I suggest doing it by
> adding an implementation using the proper scheme under the new name,
> switch users over, and dropping the old. IMO, this series as-is brings
> no value (except for the tests, of course).

OK. Do you think this series gets us closer to that, or further away?

Regards,
Simon


More information about the U-Boot mailing list