Choosing a Kernel
christian.helmuth at ...1...
Sat Oct 26 14:44:56 CEST 2013
On Thu, Oct 24, 2013 at 10:23:24PM +0200, Neal H. Walfield wrote:
> In terms of Genode support, where does Fiasco.OC rank? Is the current
> focus on a custom kernel (which I guess is the bare hardware
First, the base-hw kernel is our first choice when exploring new
grounds, e.g., porting to new ARM platforms or testing specific ARM
features like TrustZone. For us, base-hw is the least complex Genode
platform and we have a thorough understanding of its internals.
Beyond that, Genode has extensive support for both NOVA and Fiasco.OC
which includes real object capabilities. We use all supported kernels
regularly in practice as each has its own benefits when it comes to
debugging or platform support. But, NOVA and Fiasco.OC receive special
> If you have a moment, could you mention some more of the
> disadvantages of Fiasco.OC that you were thinking of?
My personal opinion about Fiasco.OC is somewhat ambivalent. The kernel
has certain assets: extensive hardware-platform support for x86
32/64bit and various ARM platforms, object-capability support, and
regular updates. On the other hand, our team is repeatedly hit by the
- Fiasco.OC does not bring a precise specification of its interface
and semantics. This forces us to derive assumptions about expected
behavior or usage from the implementation of the kernel and L4Re,
which are not always appropriate.
- The kernel is tightly coupled with the L4Re user land. This may be
an advantage for other users, but it also leads to design decisions
affecting the kernel interface that originate from the L4Re design
and are worth a discussion for general application. For example,
Norman proposed to reconsider the benefits behind sigma0 especially
with regard to cache problems on ARM on the l4-hackers mailing list.
But, the discussion was rather short and had no satisfying consent.
- Also, I always desired a more open development process and a
predictable release cycle with some notes about important changes
(and maybe some rationale behind them). Actually, we are sometimes
surprised by modifications in SVN revision r(X) in comparison to
- The last (but not least) property of the kernel that kind of scares
me is its raw complexity. It may be unfair to just count all
sources, but that is the complexity a developer faces when looking
for a bug. The overall 'sloccount' in the Fiasco src/ directory
results in about 120 KLOC. A typical build for arm_v7 (Arndale)
comprises 52 KLOC. The file list is retrieved from the dependency
information of the object files. In comparison, a simple 'sloccount
.' in the NOVA sources results in 9,606 LOC. I intentionally call
these counts "raw complexity" as an educated Fiasco.OC may reduce
the LOC running on target even further by configuration or a more
accurate counting strategy.
Please do not take these bullets as a rant about the work of the L4Re
developers. I really appreciate their work and I'm also proud of what
we could achieve with Genode on top of Fiasco.OC.
http://www.genode-labs.com/ · http://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
More information about the users