In preparation for the upcoming gathering in Dresden, I want to start some discussion about opportunities for unifying the L4 and EROS kernels. We have made some recent decisions in the EROS project that create a MUCH higher likelihood of success in this discussion. Similarly, the L4 team has been making progress on things that are drawing the two systems closer.
Since this is a public mailing list, and since many of the participants have strong and well-motivated architectural sensibilities, I feel compelled to say: I am *not* interested in establishing which system is "better." I think that both systems have some very strong qualities, and I think that they are closer in spirit than matters at first appear. I also think that each system has weaknesses, and I am interested to figure out whether there may exist a hybrid architecture that combines the advantages of both, and might allow us to bring the two communities together so that we can make more effective progress.
Let me also say at the start that I have *not* been lurking on the l4-hackers list, and that some of the issues I raise may already be "solved", either in the current implementation or in the sense that there is a commonly understood forthcoming design.
To facilitate properly threaded discussions, I'll be dividing my comments into different architectural categories and sending them out under distinct subject lines.
Regards,
shap
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:
http://www.eros-os.org/pipermail/eros-arch
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.
shap
l4-hackers@os.inf.tu-dresden.de