Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: schultz@mmm.serc.mmm.com (John C Schultz)
Newsgroups: comp.sys.sun
Subject: Re: accessing Sun physical memory
Keywords: SunOS
Message-ID: <1247@mmm.UUCP>
Date: 22 Apr 89 04:26:32 GMT
References: <8903220948.AA28578@aivru.uucp>
Sender: usenet@rice.edu
Organization: 3M Engineering Systems & Technology Lab, St. Paul MN
Lines: 26
Approved: Sun-Spots@rice.edu
Original-Date: 4 Apr 89 03:14:02 GMT
X-Sun-Spots-Digest: Volume 7, Issue 238, message 7 of 14
X-Issue-Reference: v7n221

mcvax!aivru.sheffield.ac.uk!chris@uunet.uu.net (Chris Brown) writes:
>Mike Martys in v7n192:
>
>> Another way is to manipulate the page map, mapping some part of the
>> ......
>
>This is precisely what mmap(2) does. Read the manual page. Also there is
>....

I also use mmap() to map image framebuffers and board control without
having to write device drivers for what are pretty simple (in one sense)
image processing boards.  The problem that I ran into is that for buffers
> 128KB, the SUN mapper only marks the page invalid on a munmap().  That
space NEVER AGAIN can be used for that process.  However, it turns out
that if you don't read the manual carefully enough :-), you can mmap() the
same space again and it will work most of the time but occasionally crash
on a segment violation.

My solution is to mmap()/munmap() small things like board control
registers while only mmap()ing large things like framebuffers once and
just remembering that you have mmap()ed the buffers so subsequent calls do
nothing.  Works fine. -- 

 john c. schultz   schultz@3M.Com   ..!uiucuxc!mmm!schultz  (612) 733-4047
           3M Center, Bldg 518-1-1, St. Paul, MN 55144-1000
  The opinions expressed herein are, as always, my own and not 3M's.