[coyotos-dev] More progress, some design issues

Jonathan S. Shapiro shap at eros-os.com
Sun May 6 15:40:50 EDT 2007


On 4/26 we decided to kill the UPCB. The main reason for this decision
was that the UPCB was making the register save sequence very
complicated, and was creating further complications for process setup
and dispatch.

A consequence of this decision is that we had to move incoming direct
parameter words and various soft-registers describing receive parameters
into the KPCB. At the moment, the receive parameters are updated via
"typed items" at the IPC interface. The received direct parameter words
go into a scratchpad area in the KPCB and are copied out to the
receiving application stack after the context switch occurs. This is all
consistent with Bernhard Kauer's W5 binding.

What I didn't notice at the time is a nasty interaction between all of
this and the activation handling idea. If you page fault while
up-transferring the direct parameters, you are basically hosed. The
activation handler will need the scratchpad area to do its own calls,
and it doesn't have them available.

A second issue with Kauer's binding is that the input parameter stack
frame is overwritten by the output parameter stack frame. This is very
unpleasant, because it induces a need to re-marshall parameters in some
cases.

At this point, I think that we have two design options:

 1. Drop the activation handler idea. This is certainly the easiest
    thing to do.

 2. Revert to a lesser form of the UPCB: the IPC parameter page.
    This receives the direct out parameters, contains the receive
    buffer descriptors, and also contains the activation handler's
    register transfer/save area. It would NOT contain the architected
    register set, which is the major source of complexity in the UPCB.
    It would significantly simplify IPC/invocation stubs.

The IPC parameters page basically has the same cost as the UPCB page: it
adds a page of state to every process, and it introduces the
complication of needing to map and access that page.

Feedback and opinions are welcome. Quickly!



More information about the coyotos-dev mailing list