HP-UX Reference (11i v1 00/12) - 2 System Calls (vol 5)

__________________________________________________________________________________________________________________________________________________________________________________________________
__________________________________________________________________________________________________________________________________________________________________________________________________
STANDARD Printed by: Nora Chuang [nchuang] STANDARD
/build/1111/BRICK/man2/!!!intro.2
________________________________________________________________
___ ___
m
mmap(2) mmap(2)
ERRORS
[EACCES] The file referred to by fildes is not open for read access, or the file is not open for write
access and PROT_WRITE was set for a MAP_SHARED mapping operation, or
PROT_EXECUTE was set for a MAP_SHARED mapping operation and the underlying
file does not have execute permission.
[EOVERFLOW]
The file is a regular file and the value of off+len exceeds the offset maximum esta-
blished in the open file description associated with fildes.
[ETXTBSY] MAP_SHARED and MAP_FILE are set, and PROT_EXECUTE is set and
PROT_WRITE is not set, and the file being mapped is currently open for writing.
[EINVAL] The value of off+len exceeds the maximum supported offset for mapped files.
DEPENDENCIES
Series 700/800
Because the PA-RISC memory architecture utilizes a globally shared virtual address space between
processes and discourages multiple virtual address translations to the same physical address, all con-
currently existing MAP_SHARED mappings of a file range must share the same virtual address offsets and
hardware translations. PA-RISC-based HP-UX systems allocate virtual address ranges for shared memory
and shared mapped files in the range 0x80000000through 0xefffffff for those applications compiled as 32-bit
executables or for those 64-bit applications which specify MAP_SHARED and MAP_ADDR32 in the flags
argument of the mmap() function. For applications compiled as 64-bit executables which specify
MAP_SHARED and do not specify MAP_ADDR32, the shared mapped files are in the range 0x00000011
00000000 through 0x000003ff ffffffff and 0xc0000000 00000000 through 0xc00003ff ffffffff. These address
ranges are used globally for all memory objects shared between processes.
This implies the following:
• Any single range of a file cannot be mapped multiply into different virtual address ranges.
• 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 map-
ping. 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 allocatingvirtual 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 Series 700/800 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 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
Section 2−−154 − 3 − HP-UX Release 11i: December 2000
___
___