If a memory manager issues a memory_object_lock_request to gain read/write access to a set of pages (i.e. evoking all of the kernel's access rights), the kernel will eventually return any modified pages in the range using the memory_object_data_return message and end the sequence with a memory_object_lock_completed message. This is similar to normal eviction path.
In the latter case, the page is returned to the memory manager with the expectation that it will immediately be written to the backing store and freed. The kernel cannot, however, be sure. As such, it changes the association of the page from the manager to the trusted default pager. This way, if the manager fails to free the page in a timely fashion, the kernel can still flush it to swap. Yet, what happens in the former case? Specifically, how will the returned pages be evicted? Will the kernel send another memory_object_data_return? Unlikely. It has nothing to return. So, the page will be evicted via the default pager. What is the correct way to give the management of the page back to the kernel? Perhaps, we could use the memory_object_data_supply message (and if we modified it, we could supply it as precious). _The Mach 3 Kernel Interfaces_ cautions against supplying data that has not been explicitly request, however, it does not prohibit it. And yet, what if milliseconds from now we get another message to write to the page? Again, we need to go through the same song and dance -- request the page, write to it and return it to the kernel. Thanks. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
