Choosing a Kernel

Christian Helmuth christian.helmuth at ...1...
Sat Oct 26 14:44:56 CEST 2013


Hello Neal,

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
> solution)?

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
attention currently.

> 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
following peculiarities.

- 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
  r(X-1).

- 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.

Regards
-- 
Christian Helmuth
Genode Labs

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 mailing list