Re: Questions about copy-on-write

[Neal H. Walfield]

At Wed, 27 Oct 2004 16:57:50 +0100,
Sam Mason wrote:
> 
> Neal H. Walfield wrote:
> >Sam Mason wrote:
> >Once a mapping is established, the server can only revoke it.  If a
> >frame is mark as COW then it will only be mapped read-only unless a
> >client forces the physical copy.
> 
> Which it would do my writing something to a page or doing some IPC?

If by it you mean a task, then the task (typically its pager on a page
fault) would send an RPC to physmem.  See section 5.5.1 "The Container
Interface" of the design document for more details.

> In the example of a file system sharing part of a file with an
> application, the sharer would be the file system and the reciever
> would be the task asking for the data from the file.  I was trying to
> ask that after the operation has completed would there be any
> difference (from physmem's viewpoint) between the two tasks.

Between the two tasks?  What type of difference are you expecting?  (I
still don't understand what you are asking.)

When a task holds a frame, it counts towards its allocation of frames.
This is independent of any sharing of the frame.  When multiple tasks
have a reference to a frame, they map map and use it how they like.
When a task drops a frame, it affects that task.

Does this resolve the confusion?

> >The actual mappings are maintained by the task itself: even physmem
> >has no control over them.  A task will request a mapping from physmem,
> >set up its receive window to receive it and that is it.  All the
> >knowledge of mappings between virtual frames and pages is kept in the
> >task itself.
> 
> Okay, now I'm confused!  What you've just described is how I would
> expect it to work.  But the reason for the existance of containers
> seems to be that that once a task shares a page with another task,
> that mapping can be revoked at any time.  I thought it was a bit
> strange, but that seemed to be the justification of the containers.
> The only task we trust not to revoke these mapping is physmem.

Sharing is not the same as mapping.  Sharing means giving access to a
frame to another task.  Mapping means accept a map item in an L4 IPC.
Tasks (generally) only accept mappings from physmem.

When I say that the actual mappings are maintained by the task, I mean
only the task knows the whole layout of its address space.  physmem
knows about current mappings (which is has made) but nothing more.  It
cannot know that virtual address 0xXXXXXXXX+0x4000 is associated with
the data in a file starting at offset 0xYYYY and referenced by
capability X.