HP-UX Reference (11i v2 04/09) - 2 System Calls (vol 5)

m
mmap(2) mmap(2)
mapping. Only after all mappings for a file range have been destroyed can that range be
mapped to a different virtual address.
• In most cases, two separate calls to
mmap() cannot map overlapping ranges in a file. The vir-
tual address range reserved for a file range is determined at the time of the initial mapping of
the file range into a process address space. The system allocates only the virtual address range
necessary to represent the initial mapping. As long as the initial mapping exists, subsequent
attempts to map a different file range that includes any portion of the initial range may fail with
an ENOMEM error if an extended contiguous address range that preserves the mappings of the
initial range cannot be allocated.
• Separate calls to
mmap() to map contiguous ranges of a file do not necessarily return contigu-
ous virtual address ranges. The system may allocate virtual addresses for each call to
mmap()
on a first available basis.
• The use of
MAP_FIXED is strongly discouraged because it is not portable. Using
MAP_FIXED
is generally unsuccessful on this implementation, and when it is successful, it may prevent the
system from optimally allocating virtual address space.
MAP_FIXED is discouraged, but there are some applications which by design must fix pointer offsets into
file data. The application must map the file at a specific address in order for the file offsets embedded in
the file to make sense.
Processes cannot control the usage of global virtual address space, but they can control what happens
within their private data area. The PA-RISC version of HP-UX allows a single process to exclusively map
afile
MAP_SHARED into its private data space. When a process specifies MAP_SHARED
and
MAP_FIXED with a private data address (i.e. second quadrant for 32-bit executable, third quadrant for
64-bit executable), the kernel interprets this as an exclusive mapping of the file. The request will only
succeed if no other processes in the system currently have that file mapped through MAP_SHARED
. If the
file is already mapped the caller receives an EBUSY error. If the call is successful, the calling process is
the only process allowed to map that file using
MAP_SHARED until it unmaps the file using
munmap().
Because it is exclusive, the
mmap() is not inherited across fork(). When a file is exclusively mapped
only MAP_PRIVATE mappings are allowed by other processes.
If a
MAP_PRIVATE mapping is created of a file for which a MAP_SHARED mapping exists, a separate
copy of a page for the MAP_PRIVATE mapping is created at the time of the first access to the page
through the private mapping.
APPLICATION USAGE
Use of
mmap() may reduce the amount of memory available to other memory allocation functions.
Use of
MAP_FIXED may result in unspecified behavior later in the use of brk(),
sbrk(), malloc(),
and
shmat(). The use of MAP_FIXED is discouraged, as it may prevent an implementation from mak-
ing the most effective use of resources.
The application must ensure correct synchronization when using
mmap() in conjunction with any other
file access method, such as
read() and write(), standard input/output, and shmat().
The
mmap() function allows access to resources via address space manipulations, instead of
read()/write(). Once a file is mapped, all a process has to do to access it is use the data at the
address to which the file was mapped. Using pseudo-code to illustrate the way an existing program might
be changed to use mmap(), the following:
fildes = open(...)
lseek(fildes, some_offset)
read(fildes, buf, len)
/* use data in buf */
becomes:
fildes = open(...)
address = mmap(0, len, PROT_READ, MAP_PRIVATE, fildes, some_offset)
/* use data at address */
AUTHOR
mmap() was developed by HP, AT&T, and OSF.
HP-UX 11i Version 2: September 2004 − 6 − Hewlett-Packard Company Section 2−−159