On 5/9/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
On Tue, May 08, 2007, Jonathan Corbet wrote:
>
> I just took a shot at turning this into something more like a normal
> document:
>
> http://lwn.net/Articles/233479/
I think the "jiffies variable is special" part misses the
"for
On Tue, May 08, 2007, Jonathan Corbet wrote:
>
> I just took a shot at turning this into something more like a normal
> document:
>
> http://lwn.net/Articles/233479/
I think the "jiffies variable is special" part misses the
"for stupid legacy reasons" explanation.
According to the other
On Tue, May 08, 2007, Jonathan Corbet wrote:
I just took a shot at turning this into something more like a normal
document:
http://lwn.net/Articles/233479/
I think the jiffies variable is special part misses the
for stupid legacy reasons explanation.
According to the other volatile
On 5/9/07, Johannes Stezenbach [EMAIL PROTECTED] wrote:
On Tue, May 08, 2007, Jonathan Corbet wrote:
I just took a shot at turning this into something more like a normal
document:
http://lwn.net/Articles/233479/
I think the jiffies variable is special part misses the
for stupid
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> Here are some 'volatile' comments from Linus, extracted from
> several emails in at least 2 threads.
>
> If this is close to useful, we can add it to Documentation/.
I just took a shot at turning this into something more like a normal
document:
David Rientjes wrote:
On Tue, 8 May 2007, Randy Dunlap wrote:
It's already there, isn't it?
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
On Tue, 8 May 2007, Randy Dunlap wrote:
> It's already there, isn't it?
>
> 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
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
On Tue, 8 May 2007 14:27:33 -0700 (PDT) David Rientjes wrote:
> On Tue, 8 May 2007, Jeremy Fitzhardinge wrote:
>
> > It's probably worth noting that "asm volatile (...)" doesn't mean what
> > many people think it means: specifically, it *does not* prevent the asm
> > from being reordered with
On Tue, 8 May 2007, Jeremy Fitzhardinge wrote:
> Sounds like it's referring to micro-architectural reordering, which is
> distinct from compiler reordering. In other words, even if you
> specified "-mvolatile-asm-stop" I would assume that the compiler could
> still reorder the asm statements.
David Rientjes wrote:
> It is analogous with a sequence point for ia64. But, as you mentioned, it
> is ia64 specific so your comment about "asm volatile" constructs not being
> reordered is always appropriate outside of ia64 specific code but may not
> apply to ia64 if we ever compiled with
On Tue, 8 May 2007, Jeremy Fitzhardinge wrote:
> > You're point about reordering "asm volatile" constructs differs depending
> > on -mvolatile-asm-stop or -mno-volatile-asm-stop, however.
> >
>
> Erm, that seems to be ia64 specific, and I have no idea what adding a
> "stop bit" implies. Can
David Rientjes wrote:
> Now if all such output operands are to specify that the input operands
> were "modified", 'volatile' is required to ensure the side-effects are
> preserved or, otherwise, gcc is free optimize the entire asm construct
> away since it appears to be unused.
>
Yup.
>>
On Tue, 8 May 2007, Jeremy Fitzhardinge wrote:
> > 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
David Rientjes wrote:
> Ok, so let's take your second paragraph and my email of an hour ago:
>
> 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.
On Tue, 8 May 2007, Jeremy Fitzhardinge wrote:
> It's probably worth noting that "asm volatile (...)" doesn't mean what
> many people think it means: specifically, it *does not* prevent the asm
> from being reordered with respect to the surrounding code. It may not
> even prevent it from being
Jeremy Fitzhardinge wrote:
David Rientjes 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.
It's probably worth noting that "asm volatile
Randy Dunlap wrote:
Jeff Garzik wrote:
Jeremy Fitzhardinge wrote:
No, David means that "asm volatile (...)" is meaningful and OK to use.
I thought it was OK in readl(), writel(), etc... (and in asm),
but that's it. (and jiffies)
In a driver? Highly unlikey it is OK. In a filesystem?
Jeff Garzik wrote:
Jeremy Fitzhardinge wrote:
No, David means that "asm volatile (...)" is meaningful and OK to use.
I thought it was OK in readl(), writel(), etc... (and in asm),
but that's it. (and jiffies)
In a driver? Highly unlikey it is OK. In a filesystem? Even more
unlikely it
David Rientjes 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.
>
It's probably worth noting that "asm volatile (...)" doesn't mean
Jeremy Fitzhardinge wrote:
No, David means that "asm volatile (...)" is meaningful and OK to use.
In a driver? Highly unlikey it is OK. In a filesystem? Even more
unlikely it is OK to use.
The set of circumstances where 'volatile' is acceptable is very limited.
You will see it used
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> No, David means that "asm volatile (...)" is meaningful and OK to use.
Ok, I mistook that.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Krzysztof Halasa wrote:
> David Rientjes <[EMAIL PROTECTED]> writes:
>
>
>> 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
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
On 5/8/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
On Mon, 30 Apr 2007 23:56:42 -0700 Andrew Morton wrote:
> Oh my eyes. What are these doing?
>
> The volatiles are a worry - volatile is said to be basically-always-wrong
> in-kernel, although we've never managed to document why, and i386
>
David Rientjes <[EMAIL PROTECTED]> writes:
> 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
On Tue, 8 May 2007, Randy Dunlap wrote:
> [well, can be turned into a patch]
>
> Here are some 'volatile' comments from Linus, extracted from
> several emails in at least 2 threads.
>
> If this is close to useful, we can add it to Documentation/.
>
>
On Mon, 30 Apr 2007 23:56:42 -0700 Andrew Morton wrote:
> Oh my eyes. What are these doing?
>
> The volatiles are a worry - volatile is said to be basically-always-wrong
> in-kernel, although we've never managed to document why, and i386
> cheerfully uses it in readb() and friends.
>
> Perhaps
On Mon, 30 Apr 2007 23:56:42 -0700 Andrew Morton wrote:
Oh my eyes. What are these doing?
The volatiles are a worry - volatile is said to be basically-always-wrong
in-kernel, although we've never managed to document why, and i386
cheerfully uses it in readb() and friends.
Perhaps if you
On Tue, 8 May 2007, Randy Dunlap wrote:
[well, can be turned into a patch]
Here are some 'volatile' comments from Linus, extracted from
several emails in at least 2 threads.
If this is close to useful, we can add it to Documentation/.
David Rientjes [EMAIL PROTECTED] writes:
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
On 5/8/07, Randy Dunlap [EMAIL PROTECTED] wrote:
On Mon, 30 Apr 2007 23:56:42 -0700 Andrew Morton wrote:
Oh my eyes. What are these doing?
The volatiles are a worry - volatile is said to be basically-always-wrong
in-kernel, although we've never managed to document why, and i386
cheerfully
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
Krzysztof Halasa wrote:
David Rientjes [EMAIL PROTECTED] writes:
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
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
No, David means that asm volatile (...) is meaningful and OK to use.
Ok, I mistook that.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Jeremy Fitzhardinge wrote:
No, David means that asm volatile (...) is meaningful and OK to use.
In a driver? Highly unlikey it is OK. In a filesystem? Even more
unlikely it is OK to use.
The set of circumstances where 'volatile' is acceptable is very limited.
You will see it used
David Rientjes 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.
It's probably worth noting that asm volatile (...) doesn't mean what
Jeff Garzik wrote:
Jeremy Fitzhardinge wrote:
No, David means that asm volatile (...) is meaningful and OK to use.
I thought it was OK in readl(), writel(), etc... (and in asm),
but that's it. (and jiffies)
In a driver? Highly unlikey it is OK. In a filesystem? Even more
unlikely it is
Jeremy Fitzhardinge wrote:
David Rientjes 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.
It's probably worth noting that asm volatile
Randy Dunlap wrote:
Jeff Garzik wrote:
Jeremy Fitzhardinge wrote:
No, David means that asm volatile (...) is meaningful and OK to use.
I thought it was OK in readl(), writel(), etc... (and in asm),
but that's it. (and jiffies)
In a driver? Highly unlikey it is OK. In a filesystem? Even
On Tue, 8 May 2007, Jeremy Fitzhardinge wrote:
It's probably worth noting that asm volatile (...) doesn't mean what
many people think it means: specifically, it *does not* prevent the asm
from being reordered with respect to the surrounding code. It may not
even prevent it from being
David Rientjes wrote:
Ok, so let's take your second paragraph and my email of an hour ago:
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.
On Tue, 8 May 2007, Jeremy Fitzhardinge wrote:
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
David Rientjes wrote:
Now if all such output operands are to specify that the input operands
were modified, 'volatile' is required to ensure the side-effects are
preserved or, otherwise, gcc is free optimize the entire asm construct
away since it appears to be unused.
Yup.
Yeah,
On Tue, 8 May 2007, Jeremy Fitzhardinge wrote:
You're point about reordering asm volatile constructs differs depending
on -mvolatile-asm-stop or -mno-volatile-asm-stop, however.
Erm, that seems to be ia64 specific, and I have no idea what adding a
stop bit implies. Can you set even
David Rientjes wrote:
It is analogous with a sequence point for ia64. But, as you mentioned, it
is ia64 specific so your comment about asm volatile constructs not being
reordered is always appropriate outside of ia64 specific code but may not
apply to ia64 if we ever compiled with
On Tue, 8 May 2007, Jeremy Fitzhardinge wrote:
Sounds like it's referring to micro-architectural reordering, which is
distinct from compiler reordering. In other words, even if you
specified -mvolatile-asm-stop I would assume that the compiler could
still reorder the asm statements. Am I
On Tue, 8 May 2007 14:27:33 -0700 (PDT) David Rientjes wrote:
On Tue, 8 May 2007, Jeremy Fitzhardinge wrote:
It's probably worth noting that asm volatile (...) doesn't mean what
many people think it means: specifically, it *does not* prevent the asm
from being reordered with respect to
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
On Tue, 8 May 2007, Randy Dunlap wrote:
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,
David Rientjes wrote:
On Tue, 8 May 2007, Randy Dunlap wrote:
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
Randy Dunlap [EMAIL PROTECTED] wrote:
Here are some 'volatile' comments from Linus, extracted from
several emails in at least 2 threads.
If this is close to useful, we can add it to Documentation/.
I just took a shot at turning this into something more like a normal
document:
52 matches
Mail list logo
