Messages in this thread | | | Date | Tue, 8 May 2007 16:13:09 -0700 | From | Randy Dunlap <> | Subject | Re: [RFC/PATCH] doc: volatile considered evil |
| |
On Tue, 8 May 2007 13:20:31 -0700 (PDT) David Rientjes wrote:
> On Tue, 8 May 2007, Krzysztof Halasa wrote: > > > > Since 'volatile' has two different semantics depending on the context in > > > which it is used, this warning should be appended to include the fact that > > > it is legitimate to use for inline assembly. > > > > I think it hasn't two semantics, it's like arguing that char has two > > semantics. > > > > Volatile does one thing - prohibits C compiler from optimizing > > accesses to the variable. Either with (volatile *) casts and with > > volatile var; > > > > What the meaning of an "access" to a volatile memory-mapped I/O port or a > variable that can be asynchronously interrupted is implementation-defined. > > You're only citing qualified versions of objects. > > In an asm construct, if all your input operands are modified and specified > as output operands as well, volatile must be added so that the entire > construct is not optimized away. Additionally, it must be added if your > construct modifies memory that is neither listed in inputs nor outputs to > the construct so that it is known to have at least one side-effect. Then, > the compiler cannot delete your construct if it is reachable because it > may produce such side-effects. > > Thus, the warning that was proposed for addition to CodingStyle should be > modified to explicitly state that the use of 'volatile' for asm constructs > is perfectly legitimate and its use as a type qualifier for objects in > code is inappropriate.
It's already there, isn't it? <quote from original:>
The only acceptable uses for "volatile" are:
- in _code_, i.e., for things like the definition of "readb()" etc, where we use it to force a particular access. - with inline asms - on "jiffies", for stupid legacy reasons
</quote>
or are you saying that you want to subject/header/title modified also?
--- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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/
| |