Unifying EROS and L4

Jonathan S. Shapiro shap at eros-os.org
Thu Dec 4 19:22:21 CET 2003

By way of preparation for the threads that will follow, I've been
sending out a series of notes to the EROS list concerning things that I
believe EROS got wrong. Those who are interested may wish to check the
recent parts of the eros-arch mailing list at:


Look for subject lines that start with "EROS Mistake".

In the context of the discussion here, the most important item is my
conclusion that kernel-level transparent persistence in EROS was a
mistake. Transparent persistence is sometimes a good and useful thing,
but it isn't universally good and useful, and it's incorporation into
the EROS kernel architecture has forced us to accept a number of serious
costs. Fully 60% of the code in the EROS kernel is directly or
indirectly present to support transparent persistence.

Since this isn't the EROS list, it's not the right place to talk about
whether this decision was good or bad -- if you want to join those
discussions, please do feel free to join the eros-arch mailing list for
as long or as short a time as you wish.

The relevance here comes from the question: what architectural
flexibility would arise if we removed persistence?  Some answers:

1. It would allow us to adopt the L4 IPC model essentially intact. I'll
start a thread about this in a moment.

2. It would allow the EROS group to re-examine flexpage-based address
spaces. The flexpage-based design appeals to me for many reasons.
Removing persistence means that EROS can remove the entire notion of a
'node' from the architecture. Once this is done, the remaining
architectural conflicts between the flexpage design and the EROS design
are actually quite small. We may or may not come to agree about the
issues, but we can at least focus the discussion enough to understand
what the differences are and why (or if) they are important.

To put all this in a little bit of context:

Jochen, and I have each spent over a decade pushing for the same thing:
a universal set of abstractions that are appropriate for microkernels.
Many (perhaps all!) of you have now joined in that quest. From where I
sit, the results are actually very interesting. There are striking
similarities between the core L4 design and the core EROS design as I
perceive it. In fact, there may be more similarities than differences.

This leads me to want to explore for two reasons:

  1. I am increasingly hopeful that there may be a *common* set
     of core abstractions.

  2. If there isn't a common set, then as a research matter I think it
     would be exceptionally useful to know *why* there isn't.


Jonathan S. Shapiro <shap at eros-os.org>

More information about the l4-hackers mailing list