[coyotos-dev] Last IDL issue

[Jonathan S. Shapiro]

There is another IDL issue. It's not really a discussion topic; this is
more of a status update.

We initially thought that the Coyotos syscall interface should use
capitem_t. A capitem_t is a discriminated union that can either be a
memory address or a register number.

That implementation looked pretty ugly, so we switched to a scheme where
the kernel-level interface wants registers but the system call has four
phases:

   load multiple caps
   send phase
   receive phase
   store multiple caps

same effect, different approach. Main advantage is that the store
multiple caps always happens w.r.t. your own address space, so it is a
little cleaner.

The hope was that for applications that ran entirely in capability
registers, we could avoid the LMCAP and SMCAP phases.

Problems:

1. On the send side, the IDL compiler cannot know that the application
is register-only, so when it tries to decide whether LMCAP is needed, it
ends up emitting exactly the conditional checks that we were trying to
avoid.

In light of this, it seems pretty clear that we aren't winning on the
*send* caps, and we should just spec the invocation interface to accept
capitem_t and quit trying to dance around this.

2. On the receive side, we have the same issue, but the case for SMCAP
is much more compelling and I think that we should keep it with
modifications.


The problem that SMCAP is solving is that it eliminates memory receive
locations for capabilities. When a capability is transferred to receiver
memory we need to do a cross-space copy. When this is a kernel
invocation, there are various ways that the receiver space can become
damaged. The invariants are significantly simplified if the output
always goes to capability registers and is copied to receiver memory
**by the receiver**.

So:

I'm definitely going to drop the LMCAP phase.

I *may* re-specify the interface to state that incoming capabilities are
*always* received to CR28..CR31 and then an SMCAP is executed when the
receiver resumes (this can still avoid an extra system call).

If I can find a way to robustly eliminate the SMCAP as well, I will do
so, but a bunch of invariants look to get pretty entangled if I do that.

I don't like dedicating IPC registers, but if I can't get rid of SMCAP
generically there isn't any choice about that -- you can decide not to
call them registers, but you end up dedicating the slots.


shap