Re: [RFC][PATCH 23/24] atomic: Collapse all atomic_{set,clear}_mask definitions

[Russell King - ARM Linux]

On Fri, Jul 10, 2015 at 09:34:04AM -0400, Chris Metcalf wrote:
> On 7/10/2015 6:39 AM, Peter Zijlstra wrote:
> >On Fri, Jul 10, 2015 at 11:10:33AM +0200, Geert Uytterhoeven wrote:
> >>Hi Peter,
> >>
> >>On Thu, Jul 9, 2015 at 7:29 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> >>>--- a/include/linux/atomic.h
> >>>+++ b/include/linux/atomic.h
> >>>@@ -28,6 +28,23 @@ static inline int atomic_add_unless(atom
> >>>  #define atomic_inc_not_zero(v)         atomic_add_unless((v), 1, 0)
> >>>  #endif
> >>>
> >>>+#ifndef atomic_nand
> >>>+static inline void atomic_nand(int i, atomic_t *v)
> >>>+{
> >>>+       atomic_and(~i, v);
> >>That sounds like a misnomer...
> >>
> >>Your NAND is "A & ~B", while my[*] NAND is "~(A & B)"?
> >>
> >>[*] https://en.wikipedia.org/wiki/NAND_logic
> >Right you are.
> >
> >>What about atomic_clear()? (Is atomic_bic() too ARM-centric?)
> >atomic_and_not() ?
> 
> I've seen this as ANDN (as opposed to NAND).  That's the name I used in
> the tilepro atomics as the thing that implements the bitmask clear operation.
> SPARC also has an "andn" instruction with this semantics.

The obvious question though is whether we have an established name for this
operation elsewhere in the kernel, and whether we should have consistency.
In include/linux, we already have (grepping for 'and_*not'):

include/linux/nodemask.h:#define nodes_andnot(dst, src1, src2) \
include/linux/bitmap.h:extern int __bitmap_andnot(unsigned long *dst, const unsigned long *bitmap1,
include/linux/cpumask.h:static inline int cpumask_andnot(struct cpumask *dstp,

We also have:

include/linux/signal.h:#define _sig_andn(x,y)       ((x) & ~(y))

which seems to be the only instance of "andn" in include/.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/