mmap

[Guy Harris]

>Gee, suppose I need N bytes mapped.  I cannot just use N for the `len'
>argument.

SVID89 says (and so does SunOS 4.x, whence both man page and
implementation were derived):

     When MAP_FIXED is not set, the system uses addr as a hint in
     an  implementation-defined  manner  to arrive at paddr.  The
     paddr so chosen will be an area of the address  space  which
     the  system deems suitable for a mapping of len bytes to the
     specified object.

Said area may be larger than "len", if that's what's necessary to be
suitable for such a mapping, even if "N" isn't a multiple of a page
size.  The documentation should perhaps be clearer on this, but that
*is* how it works....

>SVID3 also seems to say that using an addr of 0 will result
>in a random location in the middle of my process being used, which would
>surely be a horrible design botch; one hopes it means that the necessary
>storage will be allocated from the process's heap, in which case that
>would be the best way to use this function.

It picks a location which is, in most implementations, a large distance
below the bottom of the area reserved for the stack.  (I don't know what
it does on the WE32K, or other machines where the stack grows upward; I
would guess that it would place it a large distance above the top of the
area reserved for the stack.)

The way that area is reserved for the stack is by setting the stack
limit to some value.  The default stack size seems to be 2MB on Sun-3s
and 8MB on Sun-4s; if you need a larger stack, you can set it to a
larger value. 

There are reasons why having the system choose the address is a win; one
reason is that machines exist where alignment constraints other than
page-alignment constraints affect cacheability of shared segments
(Sun-3/2xx and Sun-4/2xx, for example).

>Note also that SVID3 says that -1 is returned on error.  I have no idea
>what that means, as -1 is not a caddr_t.  You may recall that we discuss
>this sort of botch (as with sbrk()) every so often, and yet here these
>idiots go and make the same mistake yet again.  The proper error return
>should have been a null pointer.

I won't defend that decision as being right; it was probably done in
SunOS 4.x for binary compatibility with the limited "mmap" in earlier
releases, but unless source compatibility was important (and I don't
know that source compatibility is provided for "mmap" at all) it could
have been given a different trap number and done differently.