Backing up one more step...

[Jonathan Shapiro]

   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?

On a SAS system, it would probably be the address space plus whatever
primitive namespace was used for devices by the OS.  The idea with
devices is that the client shouldn't need to be aware of the device's
physical location unless correct semantic operation requires that the
client find out.  For example, the design of most networks means that
it matters *which* card is bound to an IP address, but for the most
part a terminal port is a terminal port regardless of location.

KeyKOS has a global namespace, which is the (internal) namespace of
capabilities.  A capability encodes the coded disk address of a node
or page and/or the identity of a device.  Since most device keys are
rescinded on startup, their names don't need to be the same from one
boot to the next.


KeyKOS doesn't have a file system, though user processes are free to
construct one.  If the underlying nodes, keys, pages, and devices are
a single system image, then the file system would be accessible from
any process with requisite authorities, regardless of locations.

SSI doesn't imply that all processes can see everything, only that the
set of things they *might* see if they had universal permissions
doesn't change depending on where you look from.

   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.

Actually, a KeyKOS kernel can do this. (I don't know if it was
implemented - one of the other folks will be able to tell you).
The KeyKOS checkpoint system can be set up to checkpoint to a remote
hot standby.  The mechanism for standby startup was for the remote
kernel to suddenly develop schizophrenia and run two machines on one
pice of hardware.  Since the two machine images had no knowledge of
each other (no keys crossing the districts), they could never become
entangled. 

   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.

The problem is that all cross-district keys would become invalid the
first time a district failed.  Once you have *no* keys into any other
district, it is impossible to obtain any.

   So what have you gained beyond a bunch of separate KeyKOS machines
   on a network? 

Nothing, which is why I abandoned distributing KeyKOS. 

   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?

Well, you gain about a factor of.... 75 in individual node
reliability, which probably helps quite a bit in practice.  UNIX isn't
very stable.

You also gain a more disciplined, uniform approach to resource naming
and access, which helps alot.  That's what I'm trying to retain in
DIMSUM.


Jonathan