Re: Questions about copy-on-write

[Bas Wijnen]

Sam Mason wrote:
> Bas Wijnen wrote:
> > This cannot be used, because the task didn't physically do 
> > the mapping, that was only conceptually.  Only the task which did that 
> > can revoke it.  And that was physmem.  So to revoke a mapping, tell 
> > physmem to do it, and it'll be arranged.  :-)
>
>
> Will that always be true?

Will what always be true?

That the task didn't map the memory itself:

We're not sure yet.  There are ideas to make it impossible for a task to 
map any memory to an other task, so it is really needed that physmem 
will do it.  But even if we don't strictly prevent it, we assume that it 
isn't used by any task.  If some task maps memory to an other task 
anyway, it can unmap it as well, of course.

Or that physmem unmaps the page on request:

No, that will not always be true, of course.  Physmem will only revoke a 
mapping if the requestor actually has the right to ask for revocation. 
In particular, it doesn't have this right if it copied a container 
capability, unless it completely dumps the page (so it is unmapped for 
itself as well).  This is because capabilities don't have a master and a 
slave, or original and copy.  All capabilities (to the same object) are 
the same, so they can do the same things.

Note: As Neil pointed out, containers _can_ give out two different types 
of capabilities.  At the capability server level, these are actually two 
different objects for which capabilities are given out: One for the 
container itself, and one for a special object which happens to work on 
the same data (but has less rights).

Thanks,
Bas

signature.asc
Description: OpenPGP digital signature