Re: [PATCH 1/4] bitops: Introduce assign_bit()

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Wed, Aug 23, 2017 at 7:09 PM, Bart Van Assche <Bart.VanAssche@xxxxxxx> wrote:
> On Wed, 2017-08-23 at 09:32 +0200, Linus Walleij wrote:
>> Can someone explain when I use the bitop_foo() and when I
>> use the __bitop_foo(). I am asking so I can understand patch
>> 2/4 in this series.
>
> That's easy. From Documentation/core-api/atomic_ops.rst:
>
> ----------------------------------------------------------------------
> Finally, there are non-atomic versions of the bitmask operations
> provided.  They are used in contexts where some other higher-level SMP
> locking scheme is being used to protect the bitmask, and thus less
> expensive non-atomic operations may be used in the implementation.
> They have names similar to the above bitmask operation interfaces,
> except that two underscores are prefixed to the interface name. ::
>
>         void __set_bit(unsigned long nr, volatile unsigned long *addr);
>         void __clear_bit(unsigned long nr, volatile unsigned long *addr);
>         void __change_bit(unsigned long nr, volatile unsigned long *addr);
>         int __test_and_set_bit(unsigned long nr, volatile unsigned long *addr);
>         int __test_and_clear_bit(unsigned long nr, volatile unsigned long *addr);
>         int __test_and_change_bit(unsigned long nr, volatile unsigned long *addr);
>
> These non-atomic variants also do not require any special memory
> barrier semantics.

All right that makes sense.

On Rusty Russell's API ladder
http://sweng.the-davies.net/Home/rustys-api-design-manifesto
this scores 3/10 "read the documentation and you will get
it right".

We could raise it to 6-7 by renaming them all
set_bit_nonatomic() etc (or even set_bit_na()), I almost feel like
sending a script to Torvalds to do that after the merge window, but I
fear some people would beat me up for it.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html