[coyotos-dev] More progress, some design issues
Valerio Bellizzomi
devbox at selnet.org
Sun May 6 17:01:54 EDT 2007
On 06/05/2007, at 15.40, Jonathan S. Shapiro wrote:
>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.
I would opt for the easiest thing to do if:
1. It removes the cost of additional page in process state,
2. It simplifies the logic.
Does this apply in this case ?
val
>
> 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!
>
>_______________________________________________
>coyotos-dev mailing list
>coyotos-dev at smtp.coyotos.org
>http://www.coyotos.org/mailman/listinfo/coyotos-dev
More information about the coyotos-dev
mailing list