Re: Questions about copy-on-write

[Marcus Brinkmann]

At Tue, 2 Nov 2004 01:58:39 +0000,
Sam Mason <address@hidden> wrote:
> 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?

Not sure myself.  Depends on how much you want to go into detail with
that, and how much work you actually want to put into it, now, and
over time.  Usually we just tell people to charge ahead with an idea,
and let them find their own interests and way to get stuff done.
 
> >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.

Good point.  A read-only attribute would be useful here indeed.
 
> >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?

I was thinking about something like the redirector, which is set with
l4_space_control, but obviously is not a property of the address
space, per se, but of the threads running in that space (ie, what you
would normally call the task).

The state of a thread is part of the thread object, which is a
distinct object in L4 (in fact, one of the few you can actually name
and specify).  In particular, look for TCB (in the kernel) and UTCB
(in user land).

There is only little state in the kernel, but some is obviously there.
I don't have a list, though.

> 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.

Yes.  I try to be consistent in saying IPC if I mean the low level IPC
(ie, the L4 system call), and RPC if I mean the Hurd RPC mechanism
(which implies capabilities, cancelability, and a ton of other stuff).
Saying RPC conveys much more information than IPC (to me anyway).

But this is really unrelated to the notion of a process.  Don't get
hooked up on this task vs process thing, there is not much use in
putting too fine a point on it.  I mean, obviously we want to keep
POSIXish stuff out of the core system and look for more generic
mechanisms, but that's about it.  There will be a 1:1 identity between
tasks and processes, and if only to make POSIX programs more useful
(ie, so that every task gets at least a PID).

Marcus