Genode Clarification Please

[Norman Feske]

Hi Lonnie,

> I am new to Genode and think that it is very nice solution for a
> microkernel OS for which I am trying to learn more about as it evolves
> into a fully fledged general operating system as I think that it has the
> potential to be much better than the majority that are currently
> available although it still seem to be a long ways from production
> quality at the moment.

could you please elaborate a bit more on that bit about "production
quality"? I am genuinely interested to learn what is missing from Genode
having "production quality". I would greatly appreciate if you share
your perception with us so that we can address your concerns.

> One thing that I am not clear about, and please forgive this question if
> it is a bit elementary as to something simple that I should have been
> able to ascertain, but I am confused on exactly where the Genode OS
> framework fall into place as an independent OS.

Your sentiment is actually quite common because Genode is neither an
operating system in the usual sense nor a mere kernel. Because it fits
poorly into existing categories, it is not easy to get a tangible grasp
on it. I once tried to explain how Genode relates to existing OSes in
the following interview, which you might hopefully find insightful:

  http://www.genode.org/about/interview_rel36

> The basis of my question is from the reading that I have been doing on
> the Genode website in which I can see that it can be compiled to run on
> baremetal as you would expect an OS to do, but why is it als able to be
> compiled to be used with other base platforms?

The kernel is just one tiny (literately tiny in particular when speaking
of microkernels) piece of the overall system. Genode allows you to pick
a kernel that fits best with your needs instead of tying you to a single
kernel implementation. In fact, kernels differ in many respects. Let me
just blatantly quote the release notes of version 10.02 here:

"So why do we address so many different kernels instead of focusing our
efforts to one selected platform? Our observation is that different
applications pose different requirements on the kernel. Most kernels
have a specific profile with regard to security, hardware support,
complexity, scheduling, resource management, and licensing that may make
them fit well for one application area but not perfectly suited for a
different use case. There is no single perfect kernel and there doesn't
need to be one. By using Genode, applications developed for one kernel
can be ported to all the other supported platforms with a simple
recompile. We believe that making Genode available on a new kernel is
beneficial for the kernel developers, application developers, and users
alike. For kernel developers, Genode brings additional workloads to
stress-test their kernel, and it extends the application area of the
kernel.  Application developers can address several kernel platforms at
once instead of tying their programs to one particular platform.
Finally, users and system integrators can pick their kernel of choice
for the problem at hand. Broadening the platform support for Genode
helps to make the framework more relevant."

> I can understand why it might be used with NOVA, which is a
> microhypervisor and thus Genode could run as a user-land OS in a VM, but
> I do not see why Genode would need to be compiled against the other
> base-platforms like Linux, Fiasco, ....

The NOVA kernel alone is not able to run meaningful applications or
virtual machines on top. As Markus already pointed out, Genode is used
as the glue between the naked NOVA kernel interface and user-level
applications. A virtual-machine monitor is just an example for such an
application. Genode supplements the kernel with device drivers, protocol
stacks (think of TCP/IP, graphics, C runtime), and resource management.

The Linux kernel is supported because this base platform enables us to
use all the powerful debugging tools on Linux when developing components
and interfaces. In fact, most of Genode's development (except for device
drivers or rare kernel-specific components) is carried out on Linux. The
resulting software just happens to run fine on other kernels too. The
motivation behind supporting the others kernels largely differs. For
example, L4/Fiasco is supported for sentimental reasons, and we still
use it once in a while to leverage the kernel debugger. Fiasco.OC is
supported to let Genode benefit from its good support for a variety of
ARM platforms.

Finally, the support for different kernel interfaces stresses Genode's
design and implementation quality. We have to carefully design
abstractions that work robustly with vastly different base mechanisms.
When designing such interfaces, the need to satisfy multiple kernels
rules out ad-hoc solutions pretty reliably. A clean (but often
non-obvious) design has a much better chance to pass this test. For the
implementation, we often made the experience that the different
behaviours of the kernels expose potential problems in the generic code
early on. For example, race conditions inherently depend on the kernel's
scheduling. So on some kernels, such bugs would go unnoticed for a long
time - but they are lurking there. However, exposing the same software
to other kernels with different schedulers greatly increases the
likelihood for triggering such problems, so the problems can be fixed.

Best regards
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth