[coyotos-dev] Thoughts on (non)persistence
sundman at iki.fi
Fri Jan 21 20:25:18 EST 2005
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"
> 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
> 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
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
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
More information about the coyotos-dev