Hello! В Суб, 19/11/2011 в 23:04 +0100, Samuel Thibault пишет: > Could you perhaps motivate the change? I'm not a pager expert at all, > so it's a bit black magic to me. What problem was happening? Why > making the default pager use its own memory object control port for > external objects, instead of the provided one? > > Samuel
If we work with default pager here works following mechanism. First by default_pager_object_create memory object port is created. This is port for accessing to data of memory_object. Then, when translator calls vm_map on specified memory object, kernel creates memory object control port and invokes memory_object_init on the given memory_object and specifies new control port as parameter "pager_request". In memory_object_init this parameter is stored in structure "ds", which stores some control data for memory object. There are some other calls, for instance, default_pager_object_set_size, where pager_request as parameter reply_to is supplied. But this call is invoked from translator process and reply_to equals to __mig_reply_port. The same problem is with seqno_memory_object_terminate. This call also is invoked from translator process, which doesn't know real pager_request port. Summary in short. Some calls on memory object are invoked by kernel and others are invoked by translator. That is the problem. This patch doesn't make everything work, only read/write within page size. It's idea is using pager_request port from ds structure, instead of pager_request, which was supplied by caller (here translator), for external memory objects. -- Thanks, Maksym Planeta
