Mach Messages

[Bryan Ford]

>Once you've decided that a multistage copy is the right idea (I'm
>still not convinced),

I'm not advocating multistage copy, but a multistage _model_ -
where you _try_ to copy in one stage, but you can always fall back
on a two-stage mechanism if things get complicated.

>the KeyKOS philosophy still insists that the
>allocation be done outside the kernel (again, I'm describing, not
>advocating).  If it isn't, there isn't really a good way in KeyKOS to
>ensure that the buffer pages are persistent across crashes.

Sure there is - as long as the kernel buffer is stored in ordinary nodes,
as I originally proposed, they'll get checkpointed and restarted just fine.
The only issue then is how the kernel allocates those nodes, and one
simple and probably adequate way to solve that is to associate a space
bank key (or something similar) with each process.  Then the kernel can
allocate persistent kernel memory any time it needs to, simply by
using the space bank key in the current (or otherwise appropriate) process.
You still have full accountability and full persistence, but the no-allocation
limitation is no longer necessary.

>Keep in mind that we're arguing about a problem that involves a
>fractional percentage of all messages.  The majority of messages are a
>page or less.

Agreed, which is why I think the two-stage model is a good approach.
You can still optimize all those small, simple messages into one copy,
but for large messages and corner-case situations (e.g. page faults),
you can fall back on the two-stage model and get a lot of generality
with almost no extra effort: unlimited message sizes, clean isolation
of client and server, the ability to perform arbitrary translations on
the message as it passes through (e.g. to translate keys embedded in
the message body, like Mach does), and so on.

				Bryan