MMAP(2) COMMAND REFERENCE MMAP(2)
NAME
mmap - map pages of memory
SYNOPSIS
#include <sys/types.h>
#include <sys/mman.h>
mmap(pid, fromaddr, toaddr, len, prot, share)
int pid;
caddrt fromaddr, toaddr;
uint len, prot, share;
DESCRIPTION
The mapping routine mmap allows a process to access areas of
other processes through its own address space. It causes
the calling process' pages starting at toaddr and continuing
for len bytes to map onto the process with id pid, starting
at the object's pages fromaddr.
If pid is M_SELF, an area of the process is mapped to
itself. If pid is M_PHYS, an area of the process is mapped
to physical memory (in which case share is ignored). If pid
is M_ZFILL, an area of the process is made "zero-fill-on-
demand" (in which case fromaddr and share are ignored). If
pid is M_NFILL, an area of the process is made "provide-on-
demand" (in which case fromaddr and share are ignored).
If the parameter share is true, both mappings will share the
same memory. Otherwise, a private copy of the area is made,
and changes through one mapping are not visible through the
other.
PRIVATE make a private copy for the new mapping
SHARED share the area between the mappings
The parameter prot specifies the accessibility of the pages
through the new mapping. Read and write access may be given
on the basis of processes of the same user, same process
group, same group, and world. A process may also protect
its pages against itself. The protection for a page is
specified by or'ing together the following values.
M_R_SELF read, process
M_W_SELF write, process
M_R_USER read, user
M_W_USER write, user
M_R_PGROUP read, process group
M_W_PGROUP write, process group
M_R_GROUP read, group
M_W_GROUP write, group
M_R_WORLD read, world
M_W_WORLD write, world
Printed 10/17/86 1
MMAP(2) COMMAND REFERENCE MMAP(2)
Note that the protection is associated with the mapping, and
not with the actual memory.
If the process must change the protection of a mapping, it
may map the area to itself, with the new protection. Doing
this with share cleared will disassociate the area with all
other mappings.
The terms "zero-fill-on-demand" and "provide-on-demand" used
above refer to the handling of pages in mappings which have
no initial contents. UTek does not allocate physical memory
or swap space to such a page until the first reference
(demand) for that page. If M_ZFILL is selected, the page is
filled with zeros before the first reference is satisfied.
This provides a standard initial value for data regions,
which is expected by some software. If M_NFILL is selected,
the page is not initilized before the first reference is
satisfied. This provides a small reduction in overhead in a
very small number of memory management intensive programs.
It is highly recommended that this option not be used unless
a clear advantage is apparent.
The toaddr, fromaddr and len parameters must be multiples of
the system cluster size (found using the getpagesize(2)
call).
DIAGNOSTICS
Mmap will fail when one of the following occurs:
[EINVAL]
An address is not on a cluster boundary or len is not
positive.
[EMCOLLIDE]
Portions of the new area are already mapped.
[EMRANGE]
An area is outside the possible user's address space or
includes part of the uarea.
[EACCES]
The required permissions (for reading and/or writing)
are denied for the named file or area of a process.
[ESRCH]
No process can be found corresponding to the specified
pid.
[EPERM]
The area of the object to be mapped is protected against
the desired operation.
Printed 10/17/86 2
MMAP(2) COMMAND REFERENCE MMAP(2)
RETURN VALUE
Upon successful completion, a value of 0 is returned.
Otherwise, a value of -1 is returned and errno is set to
indicate the error.
CAVEATS
Since the M_NFILL option opens a security hole, it may not
be enabled in all versions of UTek. If it is not enabled,
it is treated the same as M_ZFILL.
The M_NFILL symbol may not be available in versions of UTek
which do not enable its function.
SEE ALSO
getpagesize(2), mremap(2), munmap(2).
Printed 10/17/86 3
%%index%%
na:72,62;
sy:134,1025;
de:1159,2095;3398,1356;
di:4754,799;
rv:5697,236;
ca:5933,360;
se:6293,183;
%%index%%000000000132