On Thu, 2005-02-24 at 09:15 +0100, Ronald Aigner wrote:
I disagree with the opinion that the complexity of a microkernel should be measured by the number of its system-calls. I find it rather complex to multiplex dozen flavours of IPC via one systemcall.
I am not sure quite what motivated this comment. We have argued in the EROS design that having exactly one system call ("invoke capability", in our case) is good, but not because it reduces microkernel complexity -- in fact, it complicates it.
Our rationale for having a common method of invocation in EROS came from two objectives:
1. We wanted it to be very obvious that every call was authorized by a capability, and for simplicity of reasoning about the evolution of security state we wanted this to be very regular and very obvious in the interface.
2. We wanted to be able to "virtualize" kernel services by having a process implement a "front end".
For example, KeyKOS (the predecessor to EROS) implemented exactly one kernel timer. This was multiplexed by user-level code. The interface of the user-level timer was *identical* to the interface of the kernel capability.
There is a substantial cost to this design decision: because the EROS "call" mechanism lets the "returnee" be specified explicitly, it is possible to invoke a kernel-implemented capability in such a way that the return goes to another process. This introduces quite a number of corner cases in the implementation. In fact, the EROS implementation has a three-tiered invocation implementation:
1. The assembly path, which handles interprocess invocations. 2. The fast C path, which handles the simple call/return case. 3. The general path, which deals with all of the corner cases.
One concern in Coyotos is that when we moved to an endpoint-based design, the "call" operation effectively went away, and it may no longer be possible to easily virtualize kernel services. We have not yet had a chance to look at this aspect of the design.
shap