Messages in this thread | | | Date | Sun, 09 Jul 2006 15:47:17 +0300 | From | Avi Kivity <> | Subject | Re: [patch] spinlocks: remove 'volatile' |
| |
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
- 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/
| |