[coyotos-dev] Thoughts on (non)persistence

[Marcus Sundman]

On Saturday 22 January 2005 02:31, Jonathan S. Shapiro wrote:
> On Sat, 2005-01-22 at 02:17 +0200, Marcus Sundman wrote:
> > Without knowing how coyotos handles capabilities I would guess the OS
> > associated each (running) process with some data structure containing
> > the capabilities of said process.
>
> Yes, and you have stepped neatly into the problem. This data structure
> you speak of is also ephemeral -- it goes when the power goes. Given
> that capabilities are transferred with high frequency, it's probably
> *not* a good idea to impose a disk write during every transfer, and in
> any case there is no point in saving most of those capabilities.

Why couldn't it be done as it's done in EROS? If it's OK to take snapshots 
every few minutes in EROS why wouldn't it be in Coyotos? Or was the point 
that it's not OK in any system?

Actually I was talking about mapping stored capabilities to new processes, 
not about how to best store these capabilities. Nevertheless, the latter is 
also an interesting and very important issue.

> So somehow, the "interesting" capabilities associated with a process
> must be saved explicitly.

s/must be/could be/

> Here is the least mechanism I can imagine for doing this:
>
> Let us assume that there exists some form of simple database system as
> part of the basic system. This subsystem is universally trusted.

Sounds good to me (after giving it 5 seconds of thought), except that I 
don't like the part about having to save capabilities explicitly. IMHO it 
would be nicer to register capabilities to be saved automatically.

> Let us further assume that there are only two types of "interesting"
> capabilities:
>
>   1. Capabilities to state on the disk from which information (and
>      possibly authorities) can be read.
>   2. Capabilities to processes.
>
> In order to restore these, what we need to do is assign a universally
> and persistently unique ID to each process that wishes to be restarted.
> I assume that every restartable process will have access to the database
> the process will go to the database and register the following information
> in association with the process's unique ID:
>
>   1. It's restart-time arguments (command line)
>   2. A set of (string-name, cap) pairs for any capabilities that it
>      wishes to be able to retrieve on restart.

Yes, and the database automatically adds something denoting the program 
binary so that the restart agent below knows which program to start.

> I further imagine that there will be a restart agent. On restart, this
> agent will go to the store and learn what processes should be restarted.
> It will arrange to restart these, giving each a capability to the
> authority store. It is then the responsibility of the process to recover
> further.
>
> I assume that the restarting processes are responsible for rebuilding
> their own memory maps, and also that they are responsible for re-
> establishing any consistency requirements between themselves and their
> neighbors.

Sounds like a fair assumption to me.

> I believe that aside from the "capability sets" issue, your solution and
> mine are the same. I think that *I* would rebuild the IPC capabilities
> (authority for one process to call another) by rebuilding them using the
> previously registered unique IDs, but this is similar in effect to your
> solution. 

So, you have a set of capabilities, the set has an ID (the primary key in 
the database == "the process's unique ID") and IPC capabilities point to 
this ID. Not only is this similar to my solution, it's almost exactly 
identical to it. The only difference I see is that I didn't say that the 
processes *have* to have same ID as the sets of capabilities they hold.


> We have both ducked the question of how you get files back. I believe
> that one key element to this is that the directory system is managed
> separately from the file system, and the file system is really just an
> object store.

If the file system is a process then why can't it get it's capabilities (the 
ones of the 1st kind of "interesting capabilities" above) by the startup 
agent just like all other processes in the system?


- Marcus Sundman