O_SYNC prevents Linux from caching the memory in its 16KB data cache.
If you didn't use O_SYNC your first read would fill the data cache with this
memory. you second read would just quickly grab the same copy of the data out
of the data cache and not bother going to memory.
If you don't specify O_SYNC Linux will guess what to do:
>From a previous post:
"
The TS7250 requires an extra option to the open("/dev/mem".. system call.
The flags parameter must be O_RDWR|O_SYNC (not O_RDWR). Unless O_SYNC is
specified, Linux arbitrarily decides whether or not an uncacheable MMU
mapping is required based on the X86 specific notion of where the highest
block of physical SDRAM is located. The TS-7250 w/64MB SDRAM has a block
of memory in a high address which leads Linux to believe everything below it
in physical space is also SDRAM and may also be mapped as cacheable.
//Jesse Off
"
-Curtis.
On July 24, 2006 09:10 am, Jim Jackson wrote:
>
> [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/
|