Re: Questions about copy-on-write

[Neal H. Walfield]

> At a higher level, we have physmem.  It holds a database of mappings 
> which it is prepared to give out.

Tasks holds the mappings between virtual frames, file blocks, swap
identifiers, et al. and virtual addresses.  physmem holds mappings
between virtual frame (per-task handles for physical memory blocks)
and physical frames.

>  In case of a page fault in a region 
> which a task is allowed to touch (according to the database), the pager 
> will just do an RPC to physmem telling it to map the page in.

The pager asks physmem for a map item for a particular virtual frame.

> Containers are just a special physmem-construct, which can be shared.  A 
> container is just a box which holds some memory.  Anyone who holds a 
> capability for the container can add pages to it, remove them from it, 
> and map them in its memory.

There are two types of capabilites for containers.  Control caps which
do what you said and access caps which allow mapping and some limited
locking.

>  When a task drops the capability it can no 
> longer do those things (and physmem unmaps the pages if they were 
> mapped, I guess).  There is no difference between two capabilities, so 
> when a capability is copied, there is no difference between the two 
> tasks anymore, as you said.

A task may have many containers.  Typically, it has one for its
address space and one for each transaction but this is not enforced.

> In many cases, this will not be what you want.  Instead, you want the 
> other task to be able to read, but not write the container.  Or you want 
> it to be able to read and write, but not the add or remove pages.  For 
> such situations you can make a proxy capability object.  You don't copy 
> the container capability to the other task, but instead give it a 
> capability from yourself.  Any request made with it is checked, and if 
> it's ok, passed on to the container.

This is not what happens.  See above about container access
capabilities.