[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Y7b38vH8lgsnCI/m@FVFF77S0Q05N>
Date: Thu, 5 Jan 2023 16:16:50 +0000
From: Mark Rutland <mark.rutland@....com>
To: David Laight <David.Laight@...lab.com>,
'Jani Nikula' <jani.nikula@...ux.intel.com>,
Arnd Bergmann <arnd@...db.de>,
"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
'Andrzej Hajda' <andrzej.hajda@...el.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Subject: Re: [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version
of xchg
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.
Powered by blists - more mailing lists