ukernel complexity metrics

Jonathan S. Shapiro shap at
Thu Feb 24 15:48:57 CET 2005

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.


More information about the l4-hackers mailing list