Catching up on mail

[LANDAU_CHARLES@Tandem.COM]

------------   TEXT ATTACHMENT   --------
SENT 12-08-94 FROM LANDAU_CHARLES @FORTY

On persistence districts:

I don't see much difference between what Jonathan proposes
("to let each machine be an independent KeyKOS host, and
then build a distributed OS on top") and what Bryan proposes
(persistence domains). The only difference I see is whether
there is more than one persistence domain per machine. I
believe the problems of synchronizing connections are the
same for both (and the same as for a single KeyKOS system
connected to a non-KeyKOS world through I/O). I admit the
problem of sharing memory is interesting, and I haven't seen
a bulletproof solution come across my inbox yet, and I don't
have time to design it myself, but my intuition is that it
is a solvable problem.

I hereby declare the term "single system image"
unconstitutionally vague. Correspondents, please be specific
about the abstraction you want to support, and please don't
ask for the impossible.

By the way, it is already possible in KeyKOS to have more
than one official Prime Space Bank.

On push/pull:

This interface is similar to what I came up with for Tandem
when I looked at the Mach memory object interface and asked
myself what changes needed to be done to make it possible
for a memory object to do DSM.

Jonathan said the interface needs to say whether the sender
of the data can continue to map it. I took that a step
further; to do DSM coherently you need to be able to say
whether the sender can continue to read or (separately)
write it. Each side of the interface is in one of three
states; it can read and write the data, it can read but not
write it, or it can not access it. Maybe this is the same as
what Bryan was saying. Maybe it is also what Jonathan meant
by the permissions problem. One side of the interface is the
kernel; if the memory object doesn't give the kernel write
permission, then the kernel in turn mustn't give any of its
processes write permission. Denial of write permission may
be temporary; an attempt to write should result in the
variant of pull that says "please give me write permission".

I was thinking in terms of pages, but of course the idea of
allowing the region to be more loosely defined has merit.

I would very much like to see your specs, when you think
they're somewhat stable, but preferably not so stable that
you don't want feedback. (I don't have the time to keep up
with another mailing list with a dozen messages a day. ;-))

On composition:

"... in the presence of external pagers,
there is really no need for a "segment" or "composed memory
object"
to be a basic system abstraction at all - it can be
implemented as
an arbitrary layer between the "real" memory object and the
kernel/VMM."

As I've said before, I think the proper implementation of
sharing requires that the kernel be aware of the composition
abstraction.

Charlie