Re: Questions about copy-on-write

[Marcus Brinkmann]

At Wed, 27 Oct 2004 21:15:22 +0200,
Bas Wijnen <address@hidden> wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; ISO-8859-15 (7bit)>]
> Sam Mason wrote:
> > It seemed to be suggesting that tasks could revoke the *mappings*
> > it had made with other tasks.  Basically I was a very confused
> > little boy!
> 
> Mapping memory into an L4 address space can only be done using IPC, as 
> Marcus said (he said RPC, which isn't the right term, I think).

Oh yes, sorry.

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

I'd be careful with the word mapping.  I think physmem can be pretty
agnostic about mappings.  It will forcibly unmap any mappings if
needed, but apart from that, physmem is more concerned about
containers and frames and references to frames rather than actual
mappings.

Ie, physmem does not need to have something like a the kernel's page
table (although it would be useful if physmem had an idea on the size
of a user's page table, so it could enfore a quota on it or so).

> 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 database you seem to be talking about here is in the pager of the
task itself (locally), which manages the virtual address space of a task.

[...]
> 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 correct, but maybe a bit misleading.  Physmem will support
some specific sort of proxy object that can be used to share
containers with filesystem servers.  This object MUST be implemented
by physmem for things to work -- filesystems would not trust a proxy
object that is implemented by yourself or any other untrusted task.

Of course, you can still create your own proxy objects, and offer them
to other tasks, if they want to use them.  This is true for all
objects of course, and in fact true in general: You can offer your own
Hurd services with your own objects and implementation.  However, this
doesn't tell us much about how to design the system, because usually
your own task is not trusted, and thus it can't be used as a server of
proxy objects by other parts of the system (because that would involve
blocking calls to your untrusted task).

> If there's something wrong in the story above, I'm sure someone will 
> correct me.  :-)

The rest was perfect.

Thanks,
Marcus