mmap.html

posix标准英文,html格式

<p>Note that while <i>mmap</i>() was first designed for mapping files, it is actually a general-purpose mapping facility. It can be
used to map any appropriate object, such as memory, files, devices, and so on, into the address space of a process.</p>

<p>When a mapping is established, it is possible that the implementation may need to map more than is requested into the address
space of the process because of hardware requirements. An application, however, cannot count on this behavior. Implementations that
do not use a paged architecture may simply allocate a common memory region and return the address of it; such implementations
probably do not allocate any more than is necessary. References past the end of the requested area are unspecified.</p>

<p>If an application requests a mapping that would overlay existing mappings in the process, it might be desirable that an
implementation detect this and inform the application. However, the default, portable (not MAP_FIXED) operation does not overlay
existing mappings. On the other hand, if the program specifies a fixed address mapping (which requires some implementation
knowledge to determine a suitable address, if the function is supported at all), then the program is presumed to be successfully
managing its own address space and should be trusted when it asks to map over existing data structures. Furthermore, it is also
desirable to make as few system calls as possible, and it might be considered onerous to require an <a href=
"../functions/munmap.html"><i>munmap</i>()</a> before an <i>mmap</i>() to the same address range. This volume of
IEEE&nbsp;Std&nbsp;1003.1-2001 specifies that the new mappings replace any existing mappings, following existing practice in this
regard.</p>

<p>It is not expected, when the Memory Protection option is supported, that all hardware implementations are able to support all
combinations of permissions at all addresses. When this option is supported, implementations are required to disallow write access
to mappings without write permission and to disallow access to mappings without any access permission. Other than these
restrictions, implementations may allow access types other than those requested by the application. For example, if the application
requests only PROT_WRITE, the implementation may also allow read access. A call to <i>mmap</i>() fails if the implementation cannot
support allowing all the access requested by the application. For example, some implementations cannot support a request for both
write access and execute access simultaneously. All implementations supporting the Memory Protection option must support requests
for no access, read access, write access, and both read and write access. Strictly conforming code must only rely on the required
checks. These restrictions allow for portability across a wide range of hardware.</p>

<p>The MAP_FIXED address treatment is likely to fail for non-page-aligned values and for certain architecture-dependent address
ranges. Conforming implementations cannot count on being able to choose address values for MAP_FIXED without utilizing
non-portable, implementation-defined knowledge. Nonetheless, MAP_FIXED is provided as a standard interface conforming to existing
practice for utilizing such knowledge when it is available.</p>

<p>Similarly, in order to allow implementations that do not support virtual addresses, support for directly specifying any mapping
addresses via MAP_FIXED is not required and thus a conforming application may not count on it.</p>

<p>The MAP_PRIVATE function can be implemented efficiently when memory protection hardware is available. When such hardware is not
available, implementations can implement such &quot;mappings&quot; by simply making a real copy of the relevant data into process private
memory, though this tends to behave similarly to <a href="../functions/read.html"><i>read</i>()</a>.</p>

<p>The function has been defined to allow for many different models of using shared memory. However, all uses are not equally
portable across all machine architectures. In particular, the <i>mmap</i>() function allows the system as well as the application
to specify the address at which to map a specific region of a memory object. The most portable way to use the function is always to
let the system choose the address, specifying NULL as the value for the argument <i>addr</i> and not to specify MAP_FIXED.</p>

<p>If it is intended that a particular region of a memory object be mapped at the same address in a group of processes (on machines
where this is even possible), then MAP_FIXED can be used to pass in the desired mapping address. The system can still be used to
choose the desired address if the first such mapping is made without specifying MAP_FIXED, and then the resulting mapping address
can be passed to subsequent processes for them to pass in via MAP_FIXED. The availability of a specific address range cannot be
guaranteed, in general.</p>

<p>The <i>mmap</i>() function can be used to map a region of memory that is larger than the current size of the object. Memory
access within the mapping but beyond the current end of the underlying objects may result in SIGBUS signals being sent to the
process. The reason for this is that the size of the object can be manipulated by other processes and can change at any moment. The
implementation should tell the application that a memory reference is outside the object where this can be detected; otherwise,
written data may be lost and read data may not reflect actual data in the object.</p>

<p>Note that references beyond the end of the object do not extend the object as the new end cannot be determined precisely by most
virtual memory hardware. Instead, the size can be directly manipulated by <a href=
"../functions/ftruncate.html"><i>ftruncate</i>()</a>.</p>

<p>Process memory locking does apply to shared memory regions, and the MEMLOCK_FUTURE argument to <a href=
"../functions/mlockall.html"><i>mlockall</i>()</a> can be relied upon to cause new shared memory regions to be automatically
locked.</p>

<p>Existing implementations of <i>mmap</i>() return the value -1 when unsuccessful. Since the casting of this value to type <b>void
*</b> cannot be guaranteed by the ISO&nbsp;C standard to be distinct from a successful value, this volume of
IEEE&nbsp;Std&nbsp;1003.1-2001 defines the symbol MAP_FAILED, which a conforming implementation does not return as the result of a
successful call.</p>
</blockquote>

<h4><a name="tag_03_379_09"></a>FUTURE DIRECTIONS</h4>

<blockquote>
<p>None.</p>
</blockquote>

<h4><a name="tag_03_379_10"></a>SEE ALSO</h4>

<blockquote>
<p><a href="exec.html"><i><a href="../functions/exec.html">exec</a></i>()</a>, <a href="fcntl.html"><i>fcntl</i>()</a>, <a href=
"fork.html"><i>fork</i>()</a>, <a href="lockf.html"><i>lockf</i>()</a>, <a href="msync.html"><i>msync</i>()</a>, <a href=
"munmap.html"><i>munmap</i>()</a>, <a href="mprotect.html"><i>mprotect</i>()</a>, <a href=
"posix_typed_mem_open.html"><i>posix_typed_mem_open</i>()</a>, <a href="shmat.html"><i>shmat</i>()</a>, <a href=
"sysconf.html"><i>sysconf</i>()</a>, the Base Definitions volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href=
"../basedefs/sys/mman.h.html"><i>&lt;sys/mman.h&gt;</i></a></p>
</blockquote>

<h4><a name="tag_03_379_11"></a>CHANGE HISTORY</h4>

<blockquote>
<p>First released in Issue 4, Version 2.</p>
</blockquote>

<h4><a name="tag_03_379_12"></a>Issue 5</h4>

<blockquote>
<p>Moved from X/OPEN UNIX extension to BASE.</p>

<p>Aligned with <i>mmap</i>() in the POSIX Realtime Extension as follows:</p>

<ul>
<li>
<p>The DESCRIPTION is extensively reworded.</p>
</li>

<li>
<p>The [EAGAIN] and [ENOTSUP] mandatory error conditions are added.</p>
</li>

<li>
<p>New cases of [ENOMEM] and [ENXIO] are added as mandatory error conditions.</p>
</li>

<li>
<p>The value returned on failure is the value of the constant MAP_FAILED; this was previously defined as -1.</p>
</li>
</ul>

<p>Large File Summit extensions are added.</p>
</blockquote>

<h4><a name="tag_03_379_13"></a>Issue 6</h4>

<blockquote>
<p>The <i>mmap</i>() function is marked as part of the Memory Mapped Files option.</p>

<p>The Open Group Corrigendum U028/6 is applied, changing (<b>void</b>&nbsp;*)-1 to MAP_FAILED.</p>

<p>The following new requirements on POSIX implementations derive from alignment with the Single UNIX Specification:</p>

<ul>
<li>
<p>The DESCRIPTION is updated to describe the use of MAP_FIXED.</p>
</li>

<li>
<p>The DESCRIPTION is updated to describe the addition of an extra reference to the file associated with the file descriptor passed
to <i>mmap</i>().</p>
</li>

<li>
<p>The DESCRIPTION is updated to state that there may be implementation-defined limits on the number of memory regions that can be
mapped.</p>
</li>

<li>
<p>The DESCRIPTION is updated to describe constraints on the alignment and size of the <i>off</i> argument.</p>
</li>

<li>
<p>The [EINVAL] and [EMFILE] error conditions are added.</p>
</li>

<li>
<p>The [EOVERFLOW] error condition is added. This change is to support large files.</p>
</li>
</ul>

<p>The following changes are made for alignment with the ISO&nbsp;POSIX-1:1996 standard:</p>

<ul>
<li>
<p>The DESCRIPTION is updated to describe the cases when MAP_PRIVATE and MAP_FIXED need not be supported.</p>
</li>
</ul>

<p>The following changes are made for alignment with IEEE&nbsp;Std&nbsp;1003.1j-2000:</p>

<ul>
<li>
<p>Semantics for typed memory objects are added to the DESCRIPTION.</p>
</li>

<li>
<p>New [ENOMEM] and [ENXIO] errors are added to the ERRORS section.</p>
</li>

<li>
<p>The <a href="../functions/posix_typed_mem_open.html"><i>posix_typed_mem_open</i>()</a> function is added to the SEE ALSO
section.</p>
</li>
</ul>

<p>The DESCRIPTION is updated to avoid use of the term &quot;must&quot; for application requirements.</p>

<p>IEEE&nbsp;Std 1003.1-2001/Cor&nbsp;1-2002, item XSH/TC1/D6/34 is applied, changing the margin code in the SYNOPSIS from MF|SHM
to MC3 (notation for MF|SHM|TYM).</p>

<p>IEEE&nbsp;Std&nbsp;1003.1-2001/Cor&nbsp;2-2004, item XSH/TC2/D6/60 is applied, updating the DESCRIPTION and ERRORS sections to
add the [EINVAL] error when <i>len</i> is zero.</p>
</blockquote>

<div class="box"><em>End of informative text.</em></div>

<hr size="2" noshade>
<center><font size="2"><!--footer start-->
UNIX &reg; is a registered Trademark of The Open Group.<br>
POSIX &reg; is a registered Trademark of The IEEE.<br>
[ <a href="../mindex.html">Main Index</a> | <a href="../basedefs/contents.html">XBD</a> | <a href=
"../utilities/contents.html">XCU</a> | <a href="../functions/contents.html">XSH</a> | <a href="../xrat/contents.html">XRAT</a>
]</font></center>

<!--footer end-->
<hr size="2" noshade>
</body>
</html>