— Function: kern_return_t memory_object_init (memory_object_t memory_object, memory_object_control_t memory_control, memory_object_name_t memory_object_name, vm_size_t memory_object_page_size)
— Function: kern_return_t seqnos_memory_object_init (memory_object_t memory_object, mach_port_seqno_t seqno, memory_object_control_t memory_control, memory_object_name_t memory_object_name, vm_size_t memory_object_page_size)

The function 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 response 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 a different memory_control, 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.

— Function: kern_return_t memory_object_ready (memory_object_control_t memory_control, boolean_t may_cache_object, memory_object_copy_strategy_t copy_strategy)

The function 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.