-<h2>memory_object_data_request</h2>
\r<hr>
\r<p>
\r<strong>Server Interface</strong> - Request that memory manager page-in specified data.
\r<h3>SYNOPSIS</h3>
\r<pre>
\r<strong>kern_return_t memory_object_data_request</strong>
\r <strong>(memory_object_t</strong> <var>memory_object</var>,
\r <strong>memory_object_control_t</strong> <var>memory_control</var>,
\r <strong>vm_offset_t</strong> <var>offset</var>,
\r <strong>vm_size_t</strong> <var>length</var>,
\r <strong>vm_prot_t</strong> <var>desired_access</var><strong>);</strong>
\r\r\r<strong>kern_return_t seqnos_memory_object_data_request</strong>
\r <strong>(memory_object_t</strong> <var>memory_object</var>,
\r <strong>mach_port_seqno_t</strong> <var>seqno</var>,
\r <strong>memory_object_control_t</strong> <var>memory_control</var>,
\r <strong>vm_offset_t</strong> <var>offset</var>,
\r <strong>vm_size_t</strong> <var>length</var>,
\r <strong>vm_prot_t</strong> <var>desired_access</var><strong>);</strong>
\r</pre>
\r<h3>PARAMETERS</h3>
\r<dl>
\r<p>
\r<dt> <var>memory_object</var>
\r<dd>
\r[in abstract-memory-object (receive) right]
\rThe abstract memory
\robject port that represents the memory object data.
\r<p>
\r<dt> <var>seqno</var>
\r<dd>
\r[in scalar]
\rThe sequence number of this message relative to the abstract
\rmemory object port.
\r<p>
\r<dt> <var>memory_control</var>
\r<dd>
\r[in memory-cache-control send right]
\rThe memory cache control port
\rto be used for a response by the memory manager. If the memory
\robject has been supplied to more than one kernel, this parameter
\ridentifies the kernel that is making the call.
\r<p>
\r<dt> <var>offset</var>
\r<dd>
\r[in scalar]
\rThe offset within the memory object.
\r<p>
\r<dt> <var>length</var>
\r<dd>
\r[in scalar]
\rThe number of bytes requested, starting at <var>offset</var>. The
\rnumber converts to an integral number of virtual pages.
\r<p>
\r<dt> <var>desired_access</var>
\r<dd>
\r[in scalar]
\rThe memory access modes to be allowed for the cached
\rdata. Possible values are obtained by or'ing together the following
\rvalues:
\r<dl>
\r<p>
\r<dt> <strong>VM_PROT_READ</strong>
\r<dd>
\rAllows read access.
\r<p>
\r<dt> <strong>VM_PROT_WRITE</strong>
\r<dd>
\rAllows write access.
\r<p>
\r<dt> <strong>VM_PROT_EXECUTE</strong>
\r<dd>
\rAllows execute access.
\r</dl>
\r</dl>
\r<h3>DESCRIPTION</h3>
\r<p>
\rA <strong>memory_object_data_request</strong> function is called as
\rthe result of a kernel
\rmessage requesting data from the specified memory object, for at least the
\raccess specified.
\r<p>
\rThe kernel issues this call after a cache miss (that is, a page
\rfault for which the
\rkernel does not have the data). The kernel requests only amounts
\rof data that are
\rmultiples of the page size included in the
\r<strong>memory_object_init</strong> or <strong>memory_object_create</strong> call.
\r<p>
\rThe memory manager is expected to use <strong>memory_object_data_supply</strong> to
\rreturn at least the specified data, with as much access as it
\rcan allow. If the
\rmemory manager cannot provide the data (for example, because
\rof a hardware error),
\rit can use the <strong>memory_object_data_error</strong> call. The
\rmemory manager can also
\ruse <strong>memory_object_data_unavailable</strong> to tell the kernel
\rto supply zero-filled
\rmemory for the region.
\r<h3>RETURN VALUES</h3>
\r<p>
\rOnly generic errors apply.
\r<h3>RELATED INFORMATION</h3>
\r<p>
\rFunctions:
\r<a href="memory_object_data_error.html"><strong>memory_object_data_error</strong></a>,
\r<a href="memory_object_data_supply.html"><strong>memory_object_data_supply</strong></a>,
\r<a href="MO_data_unavailable.html"><strong>memory_object_data_unavailable</strong></a>,
\r<a href="memory_object_server.html"><strong>memory_object_server</strong></a>,
\r<a href="SMO_server.html"><strong>seqnos_memory_object_server</strong></a>.
\r\r\ No newline at end of file
+<h2>memory_object_data_request</h2>
+<hr>
+<p>
+<strong>Server Interface</strong> - Request that memory manager page-in specified data.
+<h3>SYNOPSIS</h3>
+<pre>
+<strong>kern_return_t memory_object_data_request</strong>
+ <strong>(memory_object_t</strong> <var>memory_object</var>,
+ <strong>memory_object_control_t</strong> <var>memory_control</var>,
+ <strong>vm_offset_t</strong> <var>offset</var>,
+ <strong>vm_size_t</strong> <var>length</var>,
+ <strong>vm_prot_t</strong> <var>desired_access</var><strong>);</strong>
+
+
+<strong>kern_return_t seqnos_memory_object_data_request</strong>
+ <strong>(memory_object_t</strong> <var>memory_object</var>,
+ <strong>mach_port_seqno_t</strong> <var>seqno</var>,
+ <strong>memory_object_control_t</strong> <var>memory_control</var>,
+ <strong>vm_offset_t</strong> <var>offset</var>,
+ <strong>vm_size_t</strong> <var>length</var>,
+ <strong>vm_prot_t</strong> <var>desired_access</var><strong>);</strong>
+</pre>
+<h3>PARAMETERS</h3>
+<dl>
+<p>
+<dt> <var>memory_object</var>
+<dd>
+[in abstract-memory-object (receive) right]
+The abstract memory
+object port that represents the memory object data.
+<p>
+<dt> <var>seqno</var>
+<dd>
+[in scalar]
+The sequence number of this message relative to the abstract
+memory object port.
+<p>
+<dt> <var>memory_control</var>
+<dd>
+[in memory-cache-control send right]
+The memory cache control port
+to be used for a response by the memory manager. If the memory
+object has been supplied to more than one kernel, this parameter
+identifies the kernel that is making the call.
+<p>
+<dt> <var>offset</var>
+<dd>
+[in scalar]
+The offset within the memory object.
+<p>
+<dt> <var>length</var>
+<dd>
+[in scalar]
+The number of bytes requested, starting at <var>offset</var>. The
+number converts to an integral number of virtual pages.
+<p>
+<dt> <var>desired_access</var>
+<dd>
+[in scalar]
+The memory access modes to be allowed for the cached
+data. Possible values are obtained by or'ing together the following
+values:
+<dl>
+<p>
+<dt> <strong>VM_PROT_READ</strong>
+<dd>
+Allows read access.
+<p>
+<dt> <strong>VM_PROT_WRITE</strong>
+<dd>
+Allows write access.
+<p>
+<dt> <strong>VM_PROT_EXECUTE</strong>
+<dd>
+Allows execute access.
+</dl>
+</dl>
+<h3>DESCRIPTION</h3>
+<p>
+A <strong>memory_object_data_request</strong> function is called as
+the result of a kernel
+message requesting data from the specified memory object, for at least the
+access specified.
+<p>
+The kernel issues this call after a cache miss (that is, a page
+fault for which the
+kernel does not have the data). The kernel requests only amounts
+of data that are
+multiples of the page size included in the
+<strong>memory_object_init</strong> or <strong>memory_object_create</strong> call.
+<p>
+The memory manager is expected to use <strong>memory_object_data_supply</strong> to
+return at least the specified data, with as much access as it
+can allow. If the
+memory manager cannot provide the data (for example, because
+of a hardware error),
+it can use the <strong>memory_object_data_error</strong> call. The
+memory manager can also
+use <strong>memory_object_data_unavailable</strong> to tell the kernel
+to supply zero-filled
+memory for the region.
+<h3>RETURN VALUES</h3>
+<p>
+Only generic errors apply.
+<h3>RELATED INFORMATION</h3>
+<p>
+Functions:
+<a href="memory_object_data_error.html"><strong>memory_object_data_error</strong></a>,
+<a href="memory_object_data_supply.html"><strong>memory_object_data_supply</strong></a>,
+<a href="MO_data_unavailable.html"><strong>memory_object_data_unavailable</strong></a>,
+<a href="memory_object_server.html"><strong>memory_object_server</strong></a>,
+<a href="SMO_server.html"><strong>seqnos_memory_object_server</strong></a>.
+
projects / apple / xnu.git / blobdiff