preserving context-independence

[Norman Hardy]

I think that we may be violently agreeing with each other. This is an
instance where it is easier to write than to read. After writing the stuff
below this paragraph I read your stuff more carefully. I am still not sure
whether you see merit in a scheme where the segment keeper is uninformed
about faults caused by an SSC that is too small. There is a way of looking
at the algorithm, I think, that might make it seem more natural to consult
the lss of the new node before considering its keeper. Perhaps that stems
from trying to define the meaning of a slot instead the meaning of a memory
key. Incidentally I use the term SSC to name the field in the data byte of
a red segment key. If it is 0 then the LSS of the node is found in the node
and is certainly not 0. It is a terminological trick that I learned from
the 370 manual that avoids many circumlocutions. It is indeed regretable
that there is no good way to search the Gnosis manual! I will think about
that. The index is pretty good.



I view the term "expected size" with supicion. That sounds like context
information but we agree on the words "The meaning of a key (memory key or
other) should not depend on its context.".

In the KeyKos design the meaning of a memory key is defined by the effect
of applying an address to that key (actually all addresses).

The meaning of an initial slot in a segment node N is that it must resolve
(perhaps by causing a fault) 16^lss addresses.  If a segment key to segment
S in that slot currently defines addresses larger than 16^lss, then those
addresses are inaccessable via this slot. If the slot currently defines
fewer (causes faults for 16^lss - 1, for example) then the segment keeper
is in a position to rectify the situation transparently to holders of the
segment key, which includes the holder of the node key to node N. The lss
of the node that composes segment S is none of business of the manager of
node N.  Why should the keeper of S be precluded from chaning his mind.

Norman Hardy  <http://www.mediacity.com/~norm>