[aside: Guillermo, any chance you could not top post? It confuses
the discussion by putting you comments out of context.]
On Mon, 24 Jul 2006, Guillermo Prandi wrote:
> Jim, you are mixing the two problems.
Actually No. My email was only concerning the "second" problem.
After having read up on "volatile" following my reading of the
Linux kernel email list thread on the topic, I believe I now understand
that issue.
I am claiming the kernel does NO caching/buffering of /dev/mem
The only caching is hardware caching and I just don't understand the ARM
archecture enough to understand the hardware caching issues.
> ....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 );
Yes, but you claim their is additional kernel buffering/caching as well,
which I claim doesn't happen.
But seeing as we seem to be having a mutual misunderstanding (common on
email/newsgroups) I'm going to bite the bullet and check this out once and
for all by resorting to reading the kernel source. I'll report back.
>
>
>
>
>
> --- 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 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/
|