Hi, Jim: the volatile keyword is used to tell the compiler to avoid
optimizing the access to that part of the memory, just like you said.
However, that is a VERY special part of the memory: it is a file (/
dev/mem) mapped into memory. As files are handled by the operating
system and they are normally cached, you must tell the operating
system not to cache the /dev/mem file accesses. That is what you say
by using the O_SYNC flag in the open system call. If you omit the
volatile keyword, the compiler might cache the access to the part of
the memory where the file is mapped. If you omit the O_SYNC keyword,
the system would map a *buffer* to the /dev/mem file rather than to
the actual memory (you could flush the buffers using the fcntl system
call, but that just would be unpractical). The /dev/mem driver
interprets the O_SYNC flag and makes use of the virtual memory mapper
to map real memory locations into the user's virtual memory ranges.
Guille
--- In Jim Jackson <> wrote:
>
>
> >
> > Hi again all, regarding this issue, something in the recently-
posted
> > thread 'Increasing kernel clock_tick' made me realise - the
problem
> > I'm getting is exactly the issue solved by the O_SYNC flag Peter
> > Elliot mentions! http://www.simtec.co.uk/appnotes/AN0014/ notes
this
> > too -- I really was reading cached memory (as all the example
code,
> > including Jim Jackson's adio library do). Without the O_SYNC
flag you
> > get a cached representation of the IO...which gives exactly the
> > symptoms I was observing!
>
> But it doesn't explain why I've not observed your symptoms!
>
> I had thought that using the C "volatile" sorted the problem with
caching
> issue. It may be alittle more complicated. Here's where my thinking
is,
> but I'm no expert in these areas, and would love someone to correct
me.
>
> There was a recent thread on the linux kernel email list with
subject
> "[patch] spinlocks: remove 'volatile'" (see
> http://www.gatago.com/linux/kernel/22508695.html) which certainly
opened
> my eyes as to what the C "volatile" really means - essentially it
simple
> is an indication to the compiler not to make certain assumptions
about the
> state of the variable/ptr etc when optimising. It means nothing
guaranteed
> in hardware terms.
>
> I suspect what is needed is some arm assembler macro to invalidate
any
> cached data for the relevant memory, then to read that memory
> location to force a "real" read. I'm not sufficiantly up on arm
> specifics to attempt this - Anybody else? It maybe that the O_SYNC
flag
> somehow forces this. Anyone know?
>
> Jim
>
------------------------ Yahoo! Groups Sponsor --------------------~-->
Check out the new improvements in Yahoo! Groups email.
http://us.click.yahoo.com/6pRQfA/fOaOAA/yQLSAA/CFFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|