On 5/9/07, Jonathan Corbet <[EMAIL PROTECTED]> wrote:
+CREDITS
+---
+
+Original impetus and research by Randy Dunlap
+Written by Jonathan Corbet
+Improvements via coments from Satyam Sharma Johannes Stezenbach
Just a small spelling mistake: coments should be comments.
-
To unsubscribe
On 5/9/07, Jonathan Corbet [EMAIL PROTECTED] wrote:
+CREDITS
+---
+
+Original impetus and research by Randy Dunlap
+Written by Jonathan Corbet
+Improvements via coments from Satyam Sharma Johannes Stezenbach
Just a small spelling mistake: coments should be comments.
-
To unsubscribe
Jeff Garzik wrote:
On Sun, May 13, 2007 at 07:26:13PM -0400, Bill Davidsen wrote:
Krzysztof Halasa wrote:
Robert Hancock <[EMAIL PROTECTED]> writes:
You don't need volatile in that case, rmb() can be used.
rmb() invalidates all compiler assumptions, it can be
Jeff Garzik wrote:
On Sun, May 13, 2007 at 07:26:13PM -0400, Bill Davidsen wrote:
Krzysztof Halasa wrote:
Robert Hancock [EMAIL PROTECTED] writes:
You don't need volatile in that case, rmb() can be used.
rmb() invalidates all compiler assumptions, it can be much
On Sun, May 13, 2007 at 07:26:13PM -0400, Bill Davidsen wrote:
> Krzysztof Halasa wrote:
> >Robert Hancock <[EMAIL PROTECTED]> writes:
> >>You don't need volatile in that case, rmb() can be used.
> >rmb() invalidates all compiler assumptions, it can be much slower.
It does not invalidate /all/
Krzysztof Halasa wrote:
Robert Hancock <[EMAIL PROTECTED]> writes:
You don't need volatile in that case, rmb() can be used.
rmb() invalidates all compiler assumptions, it can be much slower.
Yes, why would you use rmb() when a read of a volatile generates optimal
code?
--
bill
Robert Hancock <[EMAIL PROTECTED]> writes:
> You don't need volatile in that case, rmb() can be used.
rmb() invalidates all compiler assumptions, it can be much slower.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Robert Hancock [EMAIL PROTECTED] writes:
You don't need volatile in that case, rmb() can be used.
rmb() invalidates all compiler assumptions, it can be much slower.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Krzysztof Halasa wrote:
Robert Hancock [EMAIL PROTECTED] writes:
You don't need volatile in that case, rmb() can be used.
rmb() invalidates all compiler assumptions, it can be much slower.
Yes, why would you use rmb() when a read of a volatile generates optimal
code?
--
bill
On Sun, May 13, 2007 at 07:26:13PM -0400, Bill Davidsen wrote:
Krzysztof Halasa wrote:
Robert Hancock [EMAIL PROTECTED] writes:
You don't need volatile in that case, rmb() can be used.
rmb() invalidates all compiler assumptions, it can be much slower.
It does not invalidate /all/
Bill Davidsen wrote:
Jonathan Corbet wrote:
+There are still a few rare situations where volatile makes sense in the
+kernel:
+
+ - The above-mentioned accessor functions might use volatile on
+architectures where direct I/O memory access does work.
Essentially,
+each accessor call
Bill Davidsen wrote:
Jonathan Corbet wrote:
+There are still a few rare situations where volatile makes sense in the
+kernel:
+
+ - The above-mentioned accessor functions might use volatile on
+architectures where direct I/O memory access does work.
Essentially,
+each accessor call
> In Ethernet drivers, for example, it is common for the network card to
> maintain a pointer in host memory the the latest descriptor written; you
> will generally have a loop of the form:
>
> while ((this_pointer = *pointer_ptr) > my_last_pointer) {
> for (pkt =
Jonathan Corbet wrote:
+There are still a few rare situations where volatile makes sense in the
+kernel:
+
+ - The above-mentioned accessor functions might use volatile on
+architectures where direct I/O memory access does work. Essentially,
+each accessor call becomes a little
Jonathan Corbet wrote:
> OK, here's an updated version of the volatile document - as a plain text
> file this time. It drops a new file in Documentation/, but might it be
> better as an addition to CodingStyle?
>
> Comments welcome,
I have found one use of volatile which I consider legitimate:
Jonathan Corbet wrote:
+The volatile storage class was originally meant for memory-mapped I/O
+registers. Within the kernel, register accesses, too, should be protected
I don't think it deserves to be added in documentation, but just for
reference: in userspace "volatile" is needed in signals
Jonathan Corbet wrote:
+The volatile storage class was originally meant for memory-mapped I/O
+registers. Within the kernel, register accesses, too, should be protected
I don't think it deserves to be added in documentation, but just for
reference: in userspace volatile is needed in signals
Jonathan Corbet wrote:
OK, here's an updated version of the volatile document - as a plain text
file this time. It drops a new file in Documentation/, but might it be
better as an addition to CodingStyle?
Comments welcome,
I have found one use of volatile which I consider legitimate:
Jonathan Corbet wrote:
+There are still a few rare situations where volatile makes sense in the
+kernel:
+
+ - The above-mentioned accessor functions might use volatile on
+architectures where direct I/O memory access does work. Essentially,
+each accessor call becomes a little
In Ethernet drivers, for example, it is common for the network card to
maintain a pointer in host memory the the latest descriptor written; you
will generally have a loop of the form:
while ((this_pointer = *pointer_ptr) my_last_pointer) {
for (pkt = my_last_pointer;
On 5/10/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
On 10/05/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> On 5/10/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> > [snip]
> > you write: "... that the variable could be changed outside of the
> > current thread of execution ..."
> >
> > I suggest:
On 10/05/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
On 5/10/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On 09/05/07, Jonathan Corbet <[EMAIL PROTECTED]> wrote:
> > +"the new C book") has the following to say about the volatile keyword:
> > +
> > + The purpose of volatile is to force
On 5/9/07, Jonathan Corbet <[EMAIL PROTECTED]> wrote:
OK, here's an updated version of the volatile document - as a plain text
file this time. It drops a new file in Documentation/, but might it be
better as an addition to CodingStyle?
...
---
I think the size of this file is OK as a
Imo, the best style to relay information is by directly stating facts.
I'm going to try to suggest some improvements on this..
On Wed, May 09, 2007 at 03:05:44PM -0600, Jonathan Corbet wrote:
> Andrew Morton recently called out[1] use of volatile in a
> +submitted patch, saying:
> +
> + The
On 5/10/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
On 09/05/07, Jonathan Corbet <[EMAIL PROTECTED]> wrote:
> OK, here's an updated version of the volatile document - as a plain text
> file this time. It drops a new file in Documentation/, but might it be
> better as an addition to CodingStyle?
Heikki Orsila wrote:
Imo, the best style to relay information is by directly stating facts.
I'm going to try to suggest some improvements on this..
On Wed, May 09, 2007 at 03:05:44PM -0600, Jonathan Corbet wrote:
Andrew Morton recently called out[1] use of volatile in a
+submitted patch,
On 09/05/07, Jonathan Corbet <[EMAIL PROTECTED]> wrote:
OK, here's an updated version of the volatile document - as a plain text
file this time. It drops a new file in Documentation/, but might it be
better as an addition to CodingStyle?
IMHO this is better as a sepperate document rather than
OK, here's an updated version of the volatile document - as a plain text
file this time. It drops a new file in Documentation/, but might it be
better as an addition to CodingStyle?
Comments welcome,
jon
Tell kernel developers why they shouldn't use volatile.
Signed-off-by: Jonathan Corbet
OK, here's an updated version of the volatile document - as a plain text
file this time. It drops a new file in Documentation/, but might it be
better as an addition to CodingStyle?
Comments welcome,
jon
Tell kernel developers why they shouldn't use volatile.
Signed-off-by: Jonathan Corbet
On 09/05/07, Jonathan Corbet [EMAIL PROTECTED] wrote:
OK, here's an updated version of the volatile document - as a plain text
file this time. It drops a new file in Documentation/, but might it be
better as an addition to CodingStyle?
IMHO this is better as a sepperate document rather than
Heikki Orsila wrote:
Imo, the best style to relay information is by directly stating facts.
I'm going to try to suggest some improvements on this..
On Wed, May 09, 2007 at 03:05:44PM -0600, Jonathan Corbet wrote:
Andrew Morton recently called out[1] use of volatile in a
+submitted patch,
On 5/10/07, Jesper Juhl [EMAIL PROTECTED] wrote:
On 09/05/07, Jonathan Corbet [EMAIL PROTECTED] wrote:
OK, here's an updated version of the volatile document - as a plain text
file this time. It drops a new file in Documentation/, but might it be
better as an addition to CodingStyle?
IMHO
On 5/9/07, Jonathan Corbet [EMAIL PROTECTED] wrote:
OK, here's an updated version of the volatile document - as a plain text
file this time. It drops a new file in Documentation/, but might it be
better as an addition to CodingStyle?
...
---
I think the size of this file is OK as a separate
Imo, the best style to relay information is by directly stating facts.
I'm going to try to suggest some improvements on this..
On Wed, May 09, 2007 at 03:05:44PM -0600, Jonathan Corbet wrote:
Andrew Morton recently called out[1] use of volatile in a
+submitted patch, saying:
+
+ The
On 10/05/07, Satyam Sharma [EMAIL PROTECTED] wrote:
On 5/10/07, Jesper Juhl [EMAIL PROTECTED] wrote:
On 09/05/07, Jonathan Corbet [EMAIL PROTECTED] wrote:
snip
+the new C book) has the following to say about the volatile keyword:
+
+ The purpose of volatile is to force an
On 5/10/07, Jesper Juhl [EMAIL PROTECTED] wrote:
On 10/05/07, Satyam Sharma [EMAIL PROTECTED] wrote:
On 5/10/07, Jesper Juhl [EMAIL PROTECTED] wrote:
[snip]
you write: ... that the variable could be changed outside of the
current thread of execution ...
I suggest: ... that the
36 matches
Mail list logo
