HP-UX Reference (11i v2 07/12) - 2 System Calls (vol 5)

m
mmap(2) mmap(2)
• After the initial MAP_SHARED mmap() of a file range, all subsequent
MAP_SHARED calls to
mmap() to map the same range of a file must either specify
MAP_VARIABLE in flags and inherit
the virtual address range the system has chosen for this range, or specify
MAP_FIXED with an
addr that corresponds exactly to the address chosen by the system for the initial mapping. Only
after all mappings for a file range have been destroyed can that range be mapped to a different vir-
tual address.
• In most cases, two separate calls to
mmap() cannot map overlapping ranges in a file. The virtual
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 ini-
tial range cannot be allocated.
• Separate calls to
mmap() to map contiguous ranges of a file do not necessarily return contiguous
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 sys-
tem 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 a
file
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 execut-
able), 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 pro-
cess 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.
Itanium Architecture
On Itanium-based platforms, only mappings created by the
mmap() system call in the private address
space of an MPAS (Mostly Private Address Space) process can be replaced by a
MAP_FIXED request. See
the Adaptive Address Space Whitepaper for details.
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 making
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 */
HP-UX 11i Version 2: December 2007 Update − 6 − Hewlett-Packard Company 189