[coyotos-dev] Thoughts on (non)persistence

Jonathan S. Shapiro shap at eros-os.org
Sat Jan 22 00:35:06 EST 2005


On Sat, 2005-01-22 at 03:25 +0200, Marcus Sundman wrote:
> 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?

My current feeling is that the snapshot mechanism in EROS/KeyKOS has two
flaws, which have led us to abandon it in Coyotos:

	1. It significantly complicates the kernel data structures
	   and algorithms.

	2. We cannot identify any applications that actually benefit
	   from it in a world of networked computers. Or more precisely,
	   we cannot identify any applications that can't be built
	   equally well using other solutions.

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

Given my statement above, I hope it is clear that I really mean *must*
(in the absence of transparent persistence). A process is of course free
not to save caps that it doesn't want back.

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

If you can tell us how to detect ahead of time when the system is about
to crash, I'ld be delighted to do so!

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

The ID is what allows you to recover the set of capabilities.

W.r.t. IPC, send and receive capabilities need to name endpoints. This
is only a minor added wrinkle, and it will become clearer as the Coyotos
spec goes up.

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

Because the startup agent relies on it to obtain the binaries of the
applications that it is restarting.

It seems likely that the bottom layer object server needs to get its
authority by prior arrangement.


shap



More information about the coyotos-dev mailing list