low-level message passing

[LANDAU_CHARLES@Tandem.COM]

 >I still think a two-stage fallback message transfer model would be
 >useful, to eliminate the page-fault-on-return problem if nothing else.

In KeyKOS we were careful to specify that the key invocation mechanism
does not guarantee that the kernel buffers messages (of course, since we
in fact did not buffer). Even a "fork" jump can stall waiting for the
receiver to be able to receive the message. Likewise, we were careful
not to guarantee that the kernel does NOT buffer messages. (You can't
use the completion of a "fork" as an indication that the receiver
received the message.) This allows intermediaries to be compatible even
if they choose to buffer.

(One reason you may have had trouble getting the information you want
from KeyKOS documentation is that while I think we gave precise and
hopefully clear specs on WHAT the kernel is guaranteed to do, we
generally avoided saying HOW the kernel works. That's because users are
notorious for taking advantage of unspecified behavior, then complaining
when it changes. Viva object-orientation. :-) )

You might consider the same lack of guarantees, even if you plan to do
some buffering. It will give you some flexibility you might want later
(and will give flexibility to others attempting to be compatible).

I don't quite see the advantage of the "two-stage fallback message
transfer model" anyway. You said you would account the intermediate
buffer to the receiver. So the receiver has to provide this (to get the
service). How is this any better than having the receiver provide an
adequate buffer in the normal way, in his address space where he is
receiving the message?

I also don't understand the "page-fault-on-return problem", unless you
mean it is another opportunity (of many) for users (including pagers) to
get into deadlock.