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