[Ksummit-discuss] [TECH TOPIC] Consistent terminology for ring buffers

[Ksummit-discuss] [TECH TOPIC] Consistent terminology for ring buffers

[David Howells]

Hi,

Can we settle on consistent terminology for ring buffers with regard to what
we call the producer index and the consumer index?

In linux/circ_buf.h and Documentation/core-api/circular-buffers.rst and
various other places "head" is the index at which insertion occurs and "tail"
is the index of the next object to be consumed.

However, we have other places, notably the new io_uring stuff, in which this
is reversed...

Looking online, I think head-as-insertion is more common, but I can find
references to head-as-consumption.

Should we settle on one of the following for internal kernel use, at least
inside the core documentation (not much we can do about UAPI necessarily):

	PRODUCER	CONSUMER
	===============	===============
	head		tail
	tail		head
	in		out
	insert		remove
	produce		consume

To quote Russell: "head is where the food goes in, the tail is where the ..."

David

Re: [Ksummit-discuss] [TECH TOPIC] Consistent terminology for ring buffers

[Theodore Ts'o]

On Fri, Jun 14, 2019 at 03:21:19PM +0100, David Howells wrote:
> 
> Can we settle on consistent terminology for ring buffers with regard to what
> we call the producer index and the consumer index?

"And all the people said, Amen!"  :-)

> In linux/circ_buf.h and Documentation/core-api/circular-buffers.rst and
> various other places "head" is the index at which insertion occurs and "tail"
> is the index of the next object to be consumed.

That's certainly my preference; as Rusty said:

> To quote Russell: "head is where the food goes in, the tail is where the ..."

I was a bit confused by what you meant by this table?

> 	PRODUCER	CONSUMER
> 	===============	===============
> 	head		tail
> 	tail		head
> 	in		out
> 	insert		remove
> 	produce		consume


Also, could you please make a submission of this proposal to the
kernel summit track here as well:

	http://bit.ly/lpc19-submit

That will help us deal with scheduling.  Thanks!!

						- Ted