Backing up one more step...

[Jonathan Shapiro]

[Note redirection to DIMSUM list]

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

   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.

   Hence it seems it wouldn't
   cause much of a problem if factories were in a different district than
   their clients: 

Except that in general one has no proof that one is speaking directly
to a factory, and the KeyKOS kernel sees the factory as just another
program; there is nothing "special" about it that would tip us off
that it is safe.

Also, you speak of reestablishing connection.  In KeyKOS, there are no
explicit connections in the sense that you mean!  Adding a level of
indirection via proxies doesn't help; now you need to reconnect to the
proxy in exactly the same fashion.


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.

Jonathan