Go to the first, previous, next, last section, table of contents.
memory_object_init serves as a notification that the
kernel has been asked to map the given memory object into a task's
virtual address space. Additionally, it provides a port on which the
memory manager may issue cache management requests, and a port which the
kernel will use to name this data region. In the event that different
each will perform a memory_object_init call with new request and
name ports. The virtual page size that is used by the calling kernel is
included for planning purposes.
When the memory manager is prepared to accept requests for data for this
object, it must call memory_object_ready with the attribute.
Otherwise the kernel will not process requests on this object. To
reject all mappings of this object, the memory manager may use
memory_object_destroy.
The argument memory_object is the port that represents the memory
object data, as supplied to the kernel in a vm_map call.
memory_control is the request port to which a response is
requested. (In the event that a memory object has been supplied to more
than one the kernel that has made the request.)
memory_object_name is a port used by the kernel to refer to the
memory object data in reponse to vm_region calls.
memory_object_page_size is the page size to be used by this
kernel. All data sizes in calls involving this kernel must be an
integral multiple of the page size. Note that different kernels,
indicated by different memory_controls, may have different page
sizes.
The function should return KERN_SUCCESS, but since this routine
is called by the kernel, which does not wait for a reply message, this
value is ignored.
memory_object_ready informs the kernel that the
memory manager is ready to receive data or unlock requests on behalf of
the clients. The argument memory_control is the port, provided by
the kernel in a memory_object_init call, to which cache
management requests may be issued. If may_cache_object is set,
the kernel may keep data associated with this memory object, even after
virtual memory references to it are gone.
copy_strategy tells how the kernel should copy regions of the
associated memory object. There are three possible caching strategies:
MEMORY_OBJECT_COPY_NONE which specifies that nothing special
should be done when data in the object is copied;
MEMORY_OBJECT_COPY_CALL which specifies that the memory manager
should be notified via a memory_object_copy call before any part
of the object is copied; and MEMORY_OBJECT_COPY_DELAY which
guarantees that the memory manager does not externally modify the data
so that the kernel can use its normal copy-on-write algorithms.
MEMORY_OBJECT_COPY_DELAY is the strategy most commonly used.
This routine does not receive a reply message (and consequently has no return value), so only message transmission errors apply.
Go to the first, previous, next, last section, table of contents.