Re: Fixing tmpfs and defpager

[Maksym Planeta]

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