Re: [PATCH] doc: volatile considered evil

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> It's still ambiguous.  A much more explicit title that nobody could argue 
> with would be "do not use the 'volatile' keyword as a type qualifier for 
> an object."

Except when you do. The kernel uses the C volatile in various places
itself for specific good reasons (and some for historical bad ones)

Perhaps a closer summary would be

Do Not Use Volatile
-------------------

1.	volatile is not a locking mechanism

Volatile does not define sufficiently sane or strong semantics for
locking. The kernel has proper locking mechanisms which also act as
compiler fetch/store barriers and where neccessary hardware barriers for
SMP systems. The kernel knows about all the corner cases, you probably
don't.

2.	volatile is not needed for mmio space

I/O memory access are done via readb/writeb and friends. They deal with
volatility themselves so you don't have to. They may nor may not use
volatile internally to their implementation, but that is none of your
business.

3.	volatile is not atomic

Using volatile does not guarantee atomic behaviour. This often requires
special instructions or code sequences too. We have atomic_t and the
atomic_* operators for this.

4.	volatile is not a store or read barrier

Using volatile is not always sufficient to order accesses on SMP or to
ensure things execute in the order expected. Instead the kernel provides
a set of barrier operations which have clearly defined semantics on all
systems. Make use of rmb, wmb, barrier, smp_wmb etc instead

When Might You Need volatile ?
------------------------------

When you are implementing the locking primitives on a new platform. When
you are implementing the I/O and atomic prmitives on a new platform. Also
in inline gcc assembler where "volatile" is used for subtly different
purposes.

Possibly very special cases we haven't thought about yet. However if you
find one remember the need for portability and ask whether it should be
using volatile or there is a gap in the existing hardware abstraction.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/