Re: Questions about copy-on-write

[Sam Mason]

Marcus Brinkmann wrote:
>> I don't think they're particularly amazing, but I was wondering if
>> it makes any sense to continue with it?
>
>Depends on what you are aiming at.  What should the end result be?

How about something that's useful to help someone else get started
with the project slightly easier.  Or is it actually more helpful
people asking lots of random questions at the moment?

>If you have specific questions, ask.

You answered the questions below!

>> I don't really understand the mechanics of how you give another
>> task a capability.
>
>The basic process is simple enough: You tell the server which cap
>should be given to which task, and then you tell the task about the
>"box ID" that identifies the transaction.  The receiving task then
>calls the server to proceed with the transaction, and replies to the
>sender so that the transaction box can be removed.

OK

>The description in the manual is a bit stale, but still very
>applicable.  If you have specific questions, you know the drill :)

Couldn't find the bit in the manual for some reason. . .  I've just
had another look and found it!

>> And I don't understand what capabilities are required to do a
>> "logical" copy of pages in a container.  Is the "access" capability
>> enough to do this and if so how to you create a container whose
>> contents are read-only?  or isn't that what containers are for and
>> you'd actually use some other mechanism to accomplish this?
>
>The filesystem must do such logical copies, so the access cap must
>suffice.

OK

>Read only containers are an interesting idea, I am not sure they came
>up before (do you have a specific application for it in mind?).  Well,
>we could add flags for that of course (maybe even per frame).

Just thinking off the top of my head here - what process will you use
for writing data to disk, or for that matter any other IPC that
doesn't require the server process to write back into the container.
With reading, you expect the server to have full write permission to
the buffer you supplied.  But you wouldn't want (or expect) a
malicious server scribbling all over your, potentially, precious data
if you're just trying to write it to disk.

>BTW, a process is a task.  But we usually say process if we mean a
>full blown POSIX process (ie, it has a PID, is in a process group, you
>can send a signal etc), while we say task in every other case, or if
>it doesn't matter if it is a process or not.
>
>Some people say protection domain instead task.  The L4 people usually
>say "address space", or just "space" (because they have reduced a task
>to pretty much an address space, and a little bit).

Interesting distinctions, I'll keep them in mind!  Is the "little bit"
the state of the individual threads, or where is there state stored?
or there isn't any state and it's all just kept alive by the currently
executing thread or some other exotic system?

What's the word with IPC/RPC?  I think I've always used IPC so far,
but should IPC just be reserved for the lower level L4 stuff and RPC
for the protocols sitting on top of this that are useful to untrusting
tasks and especially as we start to reach the level of being able to
call these things processes.

Thanks,
  Sam