Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!rphroy!kyzyl!tkacik
From: tkacik@kyzyl.mi.org (Tom Tkacik)
Newsgroups: comp.sys.3b1
Subject: Re: swap space
Message-ID: <389@kyzyl.mi.org>
Date: 23 Jun 91 11:06:05 GMT
References: <55907@rphroy.UUCP> <384@kyzyl.mi.org> <1991Jun21.215503.26210@colnet.uucp>
Organization: Somewhere in Royal Oak, MI
Lines: 31

In article <1991Jun21.215503.26210@colnet.uucp>, res@colnet.uucp (Rob Stampfli) writes:
> Correct, with one corrollary:  On 3.51 (and I believe 3.5) the first page
> of virtual memory is read/only and filled with zeros.  This was done, I
> believe, to permit programs that (incorrectly) dereference the NULL pointer
> to work without causing the segmentation fault Alex describes above.  (There
 
> Fine, I thought:  They just allocated 4K and set up the MMU for R/O access.
> However, on closer inspection of the hardware, I found what I believe is a
> prohibition against accessing memory below x80000 in the MMU firmware itself:
> The firmware appears to use the supervisor/user mode state signal from the
> 68010 to prohibit user level access to the lower x80000 bytes, regardless of
> the actual MMU state for page zero.  Can anyone confirm or refute this, and
> if it is so, how does the OS allow read access to page zero?
 
I just did a quick test of reading page 0.  My program ran fine and printed
that location 0 does indeed contain the value 0.  However, if I tried
reading from any other location, (even 1), the program chrashed with
a core dump.

Perhaps it is not done in the MMU.  Instead of writing zeros to the first
page and giving you read permission, the bus error handler checks to
see if the bus error was due to a read of location 0, and returns a
value of zero.  I could be done entirely in software.

I remember trying this test a couple of years ago, and not being able
to read location 0.  This must be a new "feature" of 3.51 (maybe 3.5).

-- 
Tom Tkacik                |
tkacik@kyzyl.mi.org       |     To rent this space, call 1-800-555-QUIP.
tkacik@hobbes.cs.gmr.com  |