*BSD News Article 24292


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!emory!europa.eng.gtefsd.com!uunet!Germany.EU.net!isaak.isa.de!nadia.stgt.sub.org!ncc1701.stgt.sub.org!ncc1701!space
From: space@ncc1701.stgt.sub.org (Lars Soltau)
Newsgroups: comp.unix.bsd
Subject: mmap(2) semantics
Date: 21 Nov 1993 09:06:42 GMT
Organization: United Federation of Planets
Lines: 17
Message-ID: <SPACE.93Nov21100643@ncc1701.stgt.sub.org>
NNTP-Posting-Host: ncc1701.stgt.sub.org
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

What are the exact semantics of the mmap(2) system call?

To elaborate, I'm having the following problem:
In BSD/386, any changes you make to the mapped memory do not reflect on
the actual disk file until you call msync(2), even if you set the
MAP_SHARED flag on mapping the file. The inn sources do not seem to
expect this behaviour, either in the dbz code or in the code handling
the active file. I had to add msync(2) calls in strategic locations so
that changes would actually reflect on the disk file.

Is this behaviour correct? Is there a definition on what the correct
behaviour would be?
--
Lars Soltau	bang: <insert ridiculously long path>	    BIX: -- no bucks --
		smart: space@ncc1701.stgt.sub.org

Will kein Gott auf Erden sein, sind wir selber Götter.