-<h2>memory_object_lock_completed</h2>
\r<hr>
\r<p>
\r<strong>Server Interface</strong> - Report to memory manager that a previous consistency control request has been handled.
\r<h3>SYNOPSIS</h3>
\r<pre>
\r<strong>kern_return_t memory_object_lock_completed</strong>
\r <strong>(memory_object_t</strong> <var>reply_port</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><strong>);</strong>
\r\r\r<strong>kern_return_t seqnos_memory_object_lock_completed</strong>
\r <strong>(memory_object_t</strong> <var>reply_port</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><strong>);</strong>
\r</pre>
\r<h3>PARAMETERS</h3>
\r<dl>
\r<p>
\r<dt> <var>reply_port</var>
\r<dd>
\r[in reply (receive) right]
\rThe port supplied in the corresponding
\r<strong>memory_object_lock_request</strong> call.
\r<p>
\r<dt> <var>seqno</var>
\r<dd>
\r[in scalar]
\rThe sequence number of this message relative to the port
\rnamed in the <strong>memory_object_lock_completed</strong> message.
\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 to which the call refers, starting at
\r<var>offset</var>. The number converts to an integral number of memory object
\rpages.
\r</dl>
\r<h3>DESCRIPTION</h3>
\r<p>
\rA <strong>memory_object_lock_completed</strong> function is called as
\rthe result of a kernel
\rmessage confirming the kernel's action in response to a
\r<strong>memory_object_lock_request</strong> call from the memory manager.
\rThe memory manager can use the <strong>memory_object_lock_request</strong> call to:
\r<ul>
\r<li>
\rAlter access restrictions specified in the <strong>memory_object_data_supply</strong>
\rcall or a previous <strong>memory_object_lock_request</strong> call.
\r<p>
\r<li>
\rWrite back modifications made in memory.
\r<p>
\r<li>
\rInvalidate its cached data.
\r</ul>
\r<p>
\rWhen the kernel completes the requested actions, it calls
\r<strong>memory_object_lock_completed</strong> (asynchronously) using
\rthe port explicitly provided in the
\r<strong>memory_object_lock_request</strong> call. Because the memory manager cannot
\rknow which pages have been modified, or even which pages remain in the
\rcache, it cannot know how many pages will be written back in response to a
\r<strong>memory_object_lock_request</strong> call. Receiving the
\r<strong>memory_object_lock_completed</strong> call is the only sure
\rmeans of detecting completion. The completion call
\rincludes the offset and length values from the consistency request
\rto distinguish
\rit from other consistency requests.
\r<h3>RETURN VALUES</h3>
\r<p>
\rOnly generic errors apply.
\r<h3>RELATED INFORMATION</h3>
\r<p>
\rFunctions:
\r<a href="memory_object_lock_request.html"><strong>memory_object_lock_request</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\ No newline at end of file
+<h2>memory_object_lock_completed</h2>
+<hr>
+<p>
+<strong>Server Interface</strong> - Report to memory manager that a previous consistency control request has been handled.
+<h3>SYNOPSIS</h3>
+<pre>
+<strong>kern_return_t memory_object_lock_completed</strong>
+ <strong>(memory_object_t</strong> <var>reply_port</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>);</strong>
+
+
+<strong>kern_return_t seqnos_memory_object_lock_completed</strong>
+ <strong>(memory_object_t</strong> <var>reply_port</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>);</strong>
+</pre>
+<h3>PARAMETERS</h3>
+<dl>
+<p>
+<dt> <var>reply_port</var>
+<dd>
+[in reply (receive) right]
+The port supplied in the corresponding
+<strong>memory_object_lock_request</strong> call.
+<p>
+<dt> <var>seqno</var>
+<dd>
+[in scalar]
+The sequence number of this message relative to the port
+named in the <strong>memory_object_lock_completed</strong> message.
+<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 to which the call refers, starting at
+<var>offset</var>. The number converts to an integral number of memory object
+pages.
+</dl>
+<h3>DESCRIPTION</h3>
+<p>
+A <strong>memory_object_lock_completed</strong> function is called as
+the result of a kernel
+message confirming the kernel's action in response to a
+<strong>memory_object_lock_request</strong> call from the memory manager.
+The memory manager can use the <strong>memory_object_lock_request</strong> call to:
+<ul>
+<li>
+Alter access restrictions specified in the <strong>memory_object_data_supply</strong>
+call or a previous <strong>memory_object_lock_request</strong> call.
+<p>
+<li>
+Write back modifications made in memory.
+<p>
+<li>
+Invalidate its cached data.
+</ul>
+<p>
+When the kernel completes the requested actions, it calls
+<strong>memory_object_lock_completed</strong> (asynchronously) using
+the port explicitly provided in the
+<strong>memory_object_lock_request</strong> call. Because the memory manager cannot
+know which pages have been modified, or even which pages remain in the
+cache, it cannot know how many pages will be written back in response to a
+<strong>memory_object_lock_request</strong> call. Receiving the
+<strong>memory_object_lock_completed</strong> call is the only sure
+means of detecting completion. The completion call
+includes the offset and length values from the consistency request
+to distinguish
+it from other consistency requests.
+<h3>RETURN VALUES</h3>
+<p>
+Only generic errors apply.
+<h3>RELATED INFORMATION</h3>
+<p>
+Functions:
+<a href="memory_object_lock_request.html"><strong>memory_object_lock_request</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