(Sorry for the incomplete post before)
Jim, you are mixing the two problems. The compiler optimization
problem and the kernel caching problem. Let's separate them to help
you understand:
1) Compiler problem:
In the code you presented, the compiler will generate good machine
code. The problem would show up if you DON'T declare the pointers as
volatile and use the code more than once, like in a loop:
unsigned char *adc_io_stat;
<...>
do {
s=*adc_io_stat & 0x80;
} while( !s );
This could be a problem, since at while(!s) the compiler might think
*adc_io_stat was already read and it knows its value. So, it might
skip the s= line the next time in the loop as if you were written:
unsigned char *adc_io_stat;
<...>
s=*adc_io_stat & 0x80;
do {
} while( !s );
Please do mind that the expresions above are semantically equivalent
if the pointer is not volatile, so the compiler is permitted to
perform such optimization.
2) Kernel problem:
You *think* you're not using read/write operations, but mmap consists
precisely in read/write file system operations... **except** when you
mmap /dev/mem **and** you use O_SYNC. The fact you are using memory
accesses doesn't mean that the file system below isn't working.
Imagine what would happen if you use mmap to access any regular file
like /etc/hosts or /etc/passwd.
Guille
--- In Jim Jackson <> wrote:
>
>
>
> [re-ordered to remove the top posting]
>
> On Sun, 23 Jul 2006, Guillermo Prandi wrote:
> > > On Sun, 23 Jul 2006, Guillermo Prandi wrote:
> > > > 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.
> > >
> > > All well and good, but why have I and others not found the
caching
> > > problem? Admittedly I've only used a TS7200, and I'm using an
early
> > > Technologics kernel.
> > >
> > The problem would not show up if your program reads or writes and
> > then exits (like to be used from a shell script); in such case
cache
> > wouldn't apply (buffers are flushed on file close, i.e., on
process
> > exit). The problem would only be noticed if reads/writes are
repeated
> > within the same process, and before any automatic buffer flush
> > happens (because the kernel typically flushes the file buffers
every
> > now and then).
>
> OK I'm genuinely trying to understand what you are saying here, so
i'm
> going to run thru' this stage by stage - because I'm not convinced.
> I don't understand where your claimed "buffering" comes in,
> /dev/mem is not a block device, we are not using read/write system
calls
> to read this file.
>
> Let's look at some code......
>
> volatile unsigned char *adc_io_cntl;
> volatile unsigned char *adc_io_stat;
> volatile unsigned char *adc_io_read;
> int iofd;
>
> iofd=open("/dev/mem", O_RDWR);
>
> adc_io_stat=(unsigned char *)mmap(0,getpagesize(),
> PROT_READ|PROT_WRITE,
MAP_SHARED,iofd,0x10800000);
>
> s=*adc_io_stat & 0x80;
>
> Are you saying that this pointer dereference doesn't generate the
correct
> code to cause the hardware to read the relevant byte from the
correct
> memory location, that we are somehow reading a buffered copy of
"memory"
> instead of the real thing? And that somehow if we add O_SYNC to the
open
> then we read the real memory?
>
> Jim
>
------------------------ Yahoo! Groups Sponsor --------------------~-->
See what's inside the new Yahoo! Groups email.
http://us.click.yahoo.com/2pRQfA/bOaOAA/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/
|