[coyotos-dev] More progress, some design issues

[Valerio Bellizzomi]

On 06/05/2007, at 19.02, Jonathan S. Shapiro wrote:

>On Sun, 2007-05-06 at 23:01 +0200, Valerio Bellizzomi wrote:
>
>> 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 ?
>
>I think it *always* applies.
>
>In this case, the issues are not so clear cut. We need to ask what the
>two alternatives are.
>
>>From a "simplify the logic" standpoint, introducing a "lesser UPCB" is
>probably just as simple. Given this, the questions that we need to ask
>are:
>
> 1. What are the space trade-offs between the two designs?
> 2. What is the motivation for having an activation handler at all?
> 3. What other benefits, if any, accrue to having the "lesser UPCB"?
>
>To understand the space trade-offs, we first need to look at fault
>handling in a little more detail. In the *absence* of an in-process
>(activation-based) fault handler, every "primary" process requires a
>second process to act as its fault handler. This second process needs
>some code, some data, and a stack, which gives us a total of three
>scenarios:
>
>  1. A truly external fault handler. Minimum cost: 1 page + 1 Process
>
>  2. A second process using the same address space as the primary.
>     Minimum cost: 1 Process, but probably a page in any case because
>     the requirement for code and data in the fault handler doesn't go
>     away.
>
>  3. An in-process fault handler. Minimum cost: 1 page, which can also
>     be used to simplify the IPC parameter handling in the primary
>     process. On IA-32, it looks like roughly 256 bytes of this page
>     are required for parameter space, so there is definitely enough
>     space for the activation stack in a small process, and *probably*
>     enough space for the trivial fault handler, at least.
>
>So the space argument doesn't seem terribly compelling in either
>direction.
>
>So what about motivation for in-process handlers?
>
>The big motivation is for POSIX emulation. There is a lot of POSIX
>emulation that can be done from an in-process fault handler that is a
>bit harder from an out-of-process fault handler. At this point, the
>thread-scheduling argument is fairly well secondary, but the real-time
>advantages remain significant.
>
>Finally the "lesser UPCB" really does simplify some issues in IPC
>parameter handling. If you look at the way "typed items" are handled in
>the current online spec, they are an undeniable kludge. This doesn't
>bother me very much for the string items, because if you send a string
>you are already in for a longer IPC. It *does* bother me for the
>capability passing logic, because that really needs to be decently fast.
>Bottom line is that we have too many parameters that we need to describe
>at the interface, and the interface is suffering from that.
>
>
>shap

So you are inclined to in-process fault handler, or lesser UPCB. It sounds
like a good trade-off ...

There are two missing images in the spec, at "6.4.2 Meaning of String
Items (stringitem_t)".

val