[coyotos-dev] A specification detail

[Jonathan S. Shapiro]

As in EROS, there are some corner cases in Coyotos. An example from EROS
would be:

  You invoke a process capability in some way that alters the process
  state, specifying a resume capability to that same process in the
  reply slot of the invocation.

The problem here is that the outbound message from the kernel needs to
re-validate the destination after the operation completes.

The analogous problem in Coyotos would be invoking an FCRB capability,
supplying a sender capability to the same FCRB in the reply slot.
Another case is an operation that modifies a process using a process
capability, and returns to an FCRB that names the process being
modified.

Here is the rule:

Logically, kernel invocations proceed as if the message were sent to a
process, that process performed the operation by unspecified means, and
then replied on the supplied reply capability using a will-not-block
send operation. [This is basically a reword of the KeyKOS/EROS rule.]

Matters are slightly simplified in Coyotos by the following facts:

  1. It is not possible for a process to be malformed.

  2. All kernel operations that might trip over this case return short
     messages. [This is not an accident. :-)]

  3. No operation on an FCRB cap can cause a sender cap on that same
     FCRB to become invalid. This means that we do not need to
     re-validate the FCRB prior to outbound reply delivery. We only
     need to check that it remains unblocked. If it is blocked, the
     fact that the kernel is replying with a non-blocking reply means
     that the reply can legally be dropped.

  4. Assuming the reply makes it to the FCRB, it does not have to get
     all the way to the process in order for the kernel operation to
     be considered complete. It is *desirable* to activate the receiver
     immediately, but it is *sufficient* to mark the receiver ready.
     This helps in the following case (and probably some others):

     FCRB F points to process P

     The kernel invocation is P.setSpace(NULL), with sender(F) supplied
     in the reply slot. Note that F cannot be delivered to P's
     activation handler because P has no address space! In spite of
     this, the kernel operation has completed by virtue of the fact
     that the reply has been stored in F.

So in general, (1) coyotos kernel operations should try very hard to
return responses that fit in the FCRB, but (2) if they can't, it doesn't
mean that we need to use anything as bad as the EROS/KeyKOS slow general
path IPC code (which I sometimes thought of as the "tortoise path").


shap