From: Mark Rutland <mark.rutland@arm.com>
To: David Laight <David.Laight@aculab.com>,
'Jani Nikula' <jani.nikula@linux.intel.com>,
Arnd Bergmann <arnd@arndb.de>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
'Andrzej Hajda' <andrzej.hajda@intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: Re: [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg
Date: Thu, 5 Jan 2023 16:16:50 +0000 [thread overview]
Message-ID: <Y7b38vH8lgsnCI/m@FVFF77S0Q05N> (raw)
In-Reply-To: <Y7blVTSogV2miG8+@phenom.ffwll.local>
On Thu, Jan 05, 2023 at 03:57:25PM +0100, Daniel Vetter wrote:
> It's more fun, for the atomic functions which don't have the atomic_
> prefix in their names, the __ prefixed versions provide the non-atomic
> implementation. This pattern was started with the long * bitops stuff for
> managing really big bitmasks.
>
> And I really don't think it's a great function name scheme that we should
> proliferate.
FWIW I agree it's not great, but we're stuck between a rock and a bikeshed
w.r.t. better naming -- it's quite hard to clean that up becuase the atomic_*()
namespace is reserved for atomic_t (and mirrors atomic64_*() and
atomic_long_*()).
We could consider renaming atomic_t to atomic32_t and atomic_*() to
atomic32_*(), which'd free up the atomic_*() namespace for more genral usage
(e.g. allowing us to have atomic_xchg() and xhcg(), with the latter not being
atomic).
Thanks,
Mark.
next prev parent reply other threads:[~2023-01-10 18:06 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-09 15:48 [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg Andrzej Hajda
2022-12-09 15:48 ` Andrzej Hajda
2022-12-09 15:48 ` Andrzej Hajda
2022-12-09 15:48 ` [Intel-gfx] [PATCH 2/5] drm/i915/display: kill fetch_and_zero usage Andrzej Hajda
2022-12-09 15:48 ` Andrzej Hajda
2022-12-09 15:48 ` Andrzej Hajda
2022-12-09 15:48 ` [Intel-gfx] [PATCH 3/5] drm/i915/gt: " Andrzej Hajda
2022-12-09 15:48 ` Andrzej Hajda
2022-12-09 15:48 ` Andrzej Hajda
2022-12-12 9:14 ` [Intel-gfx] " Upadhyay, Tejas
2022-12-12 9:14 ` Upadhyay, Tejas
2022-12-12 9:14 ` Upadhyay, Tejas
2022-12-12 9:23 ` Andrzej Hajda
2022-12-12 9:23 ` Andrzej Hajda
2022-12-09 15:48 ` [Intel-gfx] [PATCH 4/5] drm/i915/gvt: " Andrzej Hajda
2022-12-09 15:48 ` Andrzej Hajda
2022-12-09 15:48 ` Andrzej Hajda
2022-12-09 15:48 ` [Intel-gfx] [PATCH 5/5] drm/i915: kill fetch_and_zero Andrzej Hajda
2022-12-09 15:48 ` Andrzej Hajda
2022-12-09 15:48 ` Andrzej Hajda
2022-12-09 17:16 ` [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg Arnd Bergmann
2022-12-09 17:16 ` Arnd Bergmann
2022-12-09 17:16 ` Arnd Bergmann
2022-12-13 9:28 ` [Intel-gfx] " Andrzej Hajda
2022-12-13 9:28 ` Andrzej Hajda
2022-12-13 9:35 ` Arnd Bergmann
2022-12-13 9:35 ` Arnd Bergmann
2022-12-09 18:56 ` Andy Shevchenko
2022-12-09 18:56 ` Andy Shevchenko
2022-12-09 18:56 ` Andy Shevchenko
2022-12-09 18:58 ` [Intel-gfx] " Andy Shevchenko
2022-12-09 18:58 ` Andy Shevchenko
2022-12-09 18:58 ` Andy Shevchenko
2022-12-13 10:09 ` [Intel-gfx] " Andrzej Hajda
2022-12-13 10:27 ` Andy Shevchenko
2022-12-09 19:30 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/5] " Patchwork
2022-12-09 19:50 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-12-10 9:56 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-12-12 9:38 ` [Intel-gfx] [PATCH 1/5] " David Laight
2022-12-12 9:38 ` David Laight
2022-12-12 9:38 ` David Laight
2023-01-05 13:04 ` [Intel-gfx] " Daniel Vetter
2023-01-05 13:04 ` Daniel Vetter
2023-01-05 13:04 ` Daniel Vetter
2023-01-05 13:28 ` [Intel-gfx] " Jani Nikula
2023-01-05 13:34 ` David Laight
2023-01-05 13:34 ` David Laight
2023-01-05 14:13 ` Daniel Vetter
2023-01-05 14:13 ` Daniel Vetter
2023-01-05 14:13 ` Daniel Vetter
2023-01-05 14:41 ` David Laight
2023-01-05 14:41 ` David Laight
2023-01-05 14:41 ` David Laight
2023-01-05 14:57 ` Daniel Vetter
2023-01-05 14:57 ` Daniel Vetter
2023-01-05 14:57 ` Daniel Vetter
2023-01-05 16:16 ` Mark Rutland [this message]
2023-01-05 14:13 ` Tvrtko Ursulin
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=Y7b38vH8lgsnCI/m@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--cc=David.Laight@aculab.com \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=andrzej.hajda@intel.com \
--cc=arnd@arndb.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rodrigo.vivi@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.