Re: [patch] spinlocks: remove 'volatile'

Avi Kivity
2006-07-09T12:47:25Z

Benjamin Herrenschmidt wrote:
>
> > I didn't suggest the compiler could or should do it, just that it would
> > be possible (for the _user_) to write portable ISO C code to access PCI
> > mmio registers, if volatile's implementation serialized access.
>
> That isn't possible neither. How to actually serialize access can
> require different set of primitives depending on the storage class of
> the memory you are accessing, which the C compiler has 0 knowledge
> about. (For example, cacheable storage vs. write-through vs.
> non-cacheable guarded vs. non-cacheable non-guarded on powerpc, there
> are different issues on other architectures).
>

Okay. I guess this limits portable volatile to main memory. Thanks for
the clarification.

> > With the current implementation of volatile in gcc, it is impossible -
> > you need to resort to inline assembly for some architectures, which is
> > not an ISO C feature.
>
> ISO C has never been about writing device drivers. There is simply no
> choice here. You need an atchitecture specific set of accessors. If you
> want portable code, then pick a library like libpci and make sure it
> contains all you need on all the architectures you need. Then write
> portable code on top of it.
>

Indeed, I see no other way now.

> > And I'm not suggesting that it would be a good idea to use volatile
> even
> > if it was corrected - it would have to take a worst-case approach and
> > thus would generate very bad code.
>
> So what is the point ?
>

Volatile is useful for non device driver work, for example VJ-style
channels. A portable volatile can help to code such things in a
compiler-neutral and platform-neutral way. Linux doesn't care about
compiler neutrality, being coded in GNU C, and about platform
neutrality, having a per-arch abstraction layer, but other programs may
wish to run on multiple compilers and multiple platforms without
per-platform glue layers.

Adding barriers to volatile can take it from dangerously useless to
somewhat* useful. Not for Linux, but other projects do exist.

* possibly barriers are still required, if volatile data points to
non-volatile data.

--
error compiling committee.c: too many arguments to function