mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: David Rientjes <rientjes@google.com>
Cc: Krzysztof Halasa <khc@pm.waw.pl>,
	Andrew Morton <akpm@linux-foundation.org>,
	Paul Sokolovsky <pmiscml@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC/PATCH] doc: volatile considered evil
Date: Tue, 8 May 2007 16:13:09 -0700	[thread overview]
Message-ID: <20070508161309.c398a913.randy.dunlap@oracle.com> (raw)
In-Reply-To: <alpine.DEB.0.99.0705081306000.15420@chino.kir.corp.google.com>

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 ***

  reply	other threads:[~2007-05-08 23:09 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-01  5:08 [RFC, PATCH 2/4] SoC base drivers: ASIC3 SoC hardware definitions Paul Sokolovsky
2007-05-01  6:56 ` Andrew Morton
2007-05-01 10:27   ` Alan Cox
2007-05-01 12:04     ` Paul Sokolovsky
2007-05-01 12:21       ` Jamey Hicks
2007-05-08 19:14   ` [RFC/PATCH] doc: volatile considered evil Randy Dunlap
2007-05-08 19:18     ` David Rientjes
2007-05-08 20:00       ` Krzysztof Halasa
2007-05-08 20:20         ` David Rientjes
2007-05-08 23:13           ` Randy Dunlap [this message]
2007-05-08 23:54             ` David Rientjes
2007-05-09  0:00               ` Randy Dunlap
2007-05-08 21:05         ` Jeremy Fitzhardinge
2007-05-08 21:10           ` Krzysztof Halasa
2007-05-08 21:16           ` Jeff Garzik
2007-05-08 21:26             ` Randy Dunlap
2007-05-08 21:25               ` Jeff Garzik
2007-05-08 21:20       ` Jeremy Fitzhardinge
2007-05-08 21:27         ` David Rientjes
2007-05-08 21:37           ` Jeremy Fitzhardinge
2007-05-08 21:59             ` David Rientjes
2007-05-08 22:04               ` Jeremy Fitzhardinge
2007-05-08 22:19                 ` David Rientjes
2007-05-08 22:29                   ` Jeremy Fitzhardinge
2007-05-08 22:35                     ` David Rientjes
2007-05-08 23:09           ` Randy Dunlap
2007-05-08 21:29         ` Randy Dunlap
2007-05-08 20:07     ` Satyam Sharma
2007-05-08 23:34       ` [PATCH] " Randy Dunlap
2007-05-09  0:06         ` David Rientjes
2007-05-09  2:08           ` Randy Dunlap
2007-05-09  2:38             ` David Rientjes
2007-05-09  3:15               ` Randy Dunlap
2007-05-09  9:21               ` Alan Cox
2007-05-09  9:26                 ` Nick Piggin
2007-05-09 13:31                   ` Alan Cox
2007-05-09 10:25                 ` David Rientjes
2007-05-09 13:36                   ` Alan Cox
2007-05-09 18:41                     ` David Rientjes
2007-05-09 20:23                       ` Alan Cox
2007-05-09 20:25                         ` David Rientjes
2007-05-09 22:47                         ` Rob Landley
2007-05-09  8:50         ` Stefan Richter
2007-05-09 15:52           ` Randy Dunlap
2007-05-09 19:04             ` Satyam Sharma
2007-05-09  1:47     ` [RFC/PATCH] " Jonathan Corbet
2007-05-09  9:43       ` Johannes Stezenbach
2007-05-09 19:34         ` Satyam Sharma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070508161309.c398a913.randy.dunlap@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=khc@pm.waw.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmiscml@gmail.com \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®