linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Henrik Rydberg <rydberg@euromail.se>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jiri Kosina <jkosina@suse.cz>,
	Mika Kuoppala <mika.kuoppala@nokia.com>,
	Benjamin Tissoires <tissoire@cena.fr>,
	Rafi Rubin <rafi@seas.upenn.edu>
Subject: Re: [PATCH 1/4] input: Introduce buflock, a one-to-many circular buffer mechanism
Date: Fri, 4 Jun 2010 18:35:50 -0700	[thread overview]
Message-ID: <20100604183550.919cde7d.akpm@linux-foundation.org> (raw)
In-Reply-To: <1275552062-8153-2-git-send-email-rydberg@euromail.se>

On Thu,  3 Jun 2010 10:00:59 +0200 "Henrik Rydberg" <rydberg@euromail.se> wrote:

> In spite of the many lock patterns and fifo helpers in the kernel, the
> case of a single writer feeding many readers via a circular buffer
> seems to be uncovered. This patch adds the buflock, a minimalistic
> interface implementing SMP-safe locking for such a buffer. Under
> normal operation, given adequate buffer size, the operation is
> lock-less. The template is given the name buflock to emphasize that
> the locking depends on the buffer read/write clashes.
> 

Seems that reviewers have already covered most of the oddities.

> +/*
> + * Write to buffer without locking
> + *
> + * bw - the buflock_writer keeping track of the write position
> + * buf - the buffer to write to (array of item type)
> + * size - the size of the circular buffer (must be a power of two)
> + * item - the item to write
> + *
> + * There is no locking involved during write, so this method is
> + * suitable to use in interrupt context.
> + */

And if the buffer fills up, it silently overwrites old data?

There are many options in this sort of thing.  Certain choices have
been made here and they should be spelled out exhaustively please.

> +#define buflock_write(bw, buf, size, item)				\
> +	do {								\
> +		bw.next_head = (bw.head + 1) & ((size) - 1);		\
> +		smp_wmb();						\
> +		buf[bw.head] = item;					\
> +		smp_wmb();						\
> +		bw.head = bw.next_head;					\
> +		smp_wmb();						\
> +	} while (0)

I don't think there's a reason why these all had to be implemented as
bloaty, un-typesafe macros?  Especially as buggy ones which reference
their arguments multiple times!

Code it in C if possible, please.

  parent reply	other threads:[~2010-06-05  1:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-03  8:00 [PATCH 0/4] input: evdev: Dynamic buffers (rev3) Henrik Rydberg
2010-06-03  8:00 ` [PATCH 1/4] input: Introduce buflock, a one-to-many circular buffer mechanism Henrik Rydberg
2010-06-03  8:01   ` [PATCH 2/4] input: evdev: Use multi-reader buffer to save space (rev3) Henrik Rydberg
2010-06-03  8:01     ` [PATCH 3/4] input: evdev: Convert to dynamic event buffer (rev3) Henrik Rydberg
2010-06-03  8:01       ` [PATCH 4/4] input: Use driver hint to compute the evdev buffer size Henrik Rydberg
2010-06-04  6:34         ` Dmitry Torokhov
2010-06-04  6:37       ` [PATCH 3/4] input: evdev: Convert to dynamic event buffer (rev3) Dmitry Torokhov
2010-06-04  6:56   ` [PATCH 1/4] input: Introduce buflock, a one-to-many circular buffer mechanism Dmitry Torokhov
2010-06-04  8:43     ` Henrik Rydberg
2010-06-04 16:36       ` Dmitry Torokhov
2010-06-04 17:08       ` Jonathan Cameron
2010-06-04 19:13       ` Oleg Nesterov
2010-06-04 19:43         ` Henrik Rydberg
2010-06-05 17:40           ` Oleg Nesterov
2010-06-05 18:34             ` Henrik Rydberg
2010-06-04 16:36     ` Henrik Rydberg
2010-06-05  1:35   ` Andrew Morton [this message]
2010-06-05 11:21     ` Henrik Rydberg
2010-06-04  6:59 ` [PATCH 0/4] input: evdev: Dynamic buffers (rev3) Dmitry Torokhov
2010-06-04 16:11   ` Henrik Rydberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100604183550.919cde7d.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.kuoppala@nokia.com \
    --cc=rafi@seas.upenn.edu \
    --cc=rydberg@euromail.se \
    --cc=tissoire@cena.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).