Backing up one more step...

[Bryan Ford]

>   >If you propose to change this, you haven't got a single system image
>   >anymore, because what you've done is said "these subsystems are not
>   >allowed to communicate with each other through the persistence layer."
>
>   I never really knew exactly what the term "single system image" meant,
>   but I'll take your word for it. :-)
>
>Basically, a single system image is one in which all programs on all
>machines see the same namespace.  That is, they can all access all of
>the devices, etc. etc.

In that case, what does "namespace" mean?  On SAS systems, it would
presumably mean the address space.  On Unix-like or Amoeba-like systems,
it probably means the file system namespace (i.e. everyone shares the
same root directory and everything down from it).  But KeyKOS doesn't
have a global address space, and my impression is that it doesn't enforce
a global filename space...  So if a KeyKOS-like system was spread across
nodes, what "global namespace" is there to be the same across nodes?

>   Perhaps it would help if
>   you (or someone) could post a list of services or connections in a
>   KeyKOS system that might be problematical in a "multiple-district"
>   organization.  We already have two: space banks and factories.
>   I already dealt with space banks (at a first-pass level anyway).
>
>Well, you did and you didn't.  Seperating the space banks doesn't
>necessarily help.  Consider that I acquire a page from a space bank,
>and subsequently pass a copy of the page key to you.  We now have a
>shared memory region of one page (doing it with a segment has the same
>issue).  The moment we contrive to share memory across districts, we
>lose the ability to track things in message passing terms unless we
>are very careful.

Sharing memory and message passing across district boundaries could
operate exactly like sharing memory or message passing in conventional,
non-persistent systems like Unix - you can do whatever you want, but
you have to deal with failures or other such problems yourself.
Presumably you already have to do the same things if you want two
KeyKOS systems (running on separate machines) to communicate with
each other.

KeyKOS ties district boundaries to machine boundaries; what I'm
proposing is that instead of trying to "make the whole world one
big KeyKOS system" or something like that, it would be much more
flexible and powerful (and practical) to keep the notion of
separate districts around, but untie them from machine boundaries:
allow a machine to support multiple districts at once, and allow
a district to be distributed across multiple machines at once.

>Also, you speak of reestablishing connection.  In KeyKOS, there are no
>explicit connections in the sense that you mean!

Every key is a connection from its holder to the object it denotes.
If a process owns a key that points into another district, and either
district dies and gets restarted, the key becomes invalid just as if
the object it pointed to had been reclaimed.  I don't quite see the problem.

>In the end, I predict you will end up where I did.  The clean
>solution, assuming a KeyKOS substrate, is to let each machine be an
>independent KeyKOS host, and then build a distributed OS on top of the
>individual reliabile hosts.  Think of KeyKOS as providing a (rather
>advanced) sort of BIOS for the rehosted OS.

So what have you gained beyond a bunch of separate KeyKOS machines
on a network?  Or for that matter, how is it better than a bunch
of Unix machines on a network, since any distributed application
wouldn't be able to take advantage of the reliability of each of
the individual hosts?

				Bryan