[coyotos-dev] More progress, some design issues
Jonathan S. Shapiro
shap at eros-os.com
Sun May 6 19:02:53 EDT 2007
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
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
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
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
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.
More information about the coyotos-dev