Roadmap 2015

Wolfgang Schmidt at ...243...
Wed Dec 24 09:28:03 CET 2014


i would propose something quite boring:

Automated tests of each component and script and giving the results on a web 
page so one can easily see if everything is up and running together with an 
update of the documentation.


As I tried out genode I ran in a few issues. Some needed a fix from your 
site, some are never fixed (e.g. last problems between blkcache and rumpfs, 
last mail form Stefen Kalkowski with :"
Well, I've tested the scenario on a "real" ext2 partition too, and observed 
the corruption of the filesystem with and without the blk_cache. Therefore, 
I assume it isn't related to the cache, but to the
rump fs server, or it's usage.")

This means at the moment if I use something and anything goes wrong there 
are many possible suspects:
- Documentation is outdated.
- Documentation has something missing which is written in some release 
- Information from last release note is also already outdated
- I have done something wrong
- some component does not work as expected (e.g. from time to time you read 
"haven't used it for some time, script no longer works")
- problem with the correct setup or the way components work together.

Every issue with a component can be a possible security bug.

- Updates of the documentation will help other developers or people just 
trying out the system
- Test scripts and reacting on the results will produce a system which is 
more stable

First minimal step:
- set up a continues integration system.
- create at least one test for every component ( later: create unit tests to 
test e.g. every path, null values, wrong values and so on, but for start 
just do a test which tests the expected behaviour of the system. )
- create an easy to view output, e.g.
   Component | Red-Green
   (leading to a finer granulated page with Component | Test | Red-Green | 
Error output)
With the automated run after a check in you can see wether a component still 
runs after changes (Later: auto reject changes which lead to failed runs).
That leads to 2 major things:
- Third party developers can see wether a component is generally usable
- As it is clear which action lead to a failed run the bug can be found 
faster and the time to fix shoudl be lower

Best regards

-----Ursprüngliche Nachricht----- 
From: Norman Feske
Sent: Monday, December 22, 2014 12:22 PM
To: Genode OS Framework Mailing List
Subject: Roadmap 2015

Hello everybody,

with New Year in sight, it is time to make up our minds regarding the
plans for 2015. Everyone of you is invited to suggest directions that
you find worthwhile to pursue - or even better - share your concrete
plans with us. I intend to finalize the road map for 2015 by mid of January.

Personally, I have three ambitions, namely the use of Genode as
general-purpose OS, the base-hw kernel, and the seL4 kernel. Let me
briefly revisit each of them.

Genode as general-purpose OS

We made big steps for pursuing Genode as general-purpose OS on x86-based
platforms. I'd particularly like to highlight the following achievements:

* The use of Rump kernels as file-system providers
* VirtualBox with support for shared folders and guest networking
* Intel wireless stack
* New GUI stack

That said, even though we are proud about the progress, we are still not
there yet. So what keeps us back? I think that the answer is actually
not technical. My observation is that each of us developers used to
concentrate on individual features or technical challenges. But the
integration of sophisticated system scenarios was left to only a few of
us. Such integration feats were mainly motivated by a particular project
or by a presentation. In order to make Genode fit for regular use, we
will first need to make the composing of advanced systems a habit for
most of the regular developers.

I'd like to keep the topic as first priority in 2015 but concentrate
less on features (as I think the feature set for us developers is fairly
complete) but more on looking at Genode in a holistic way. I would like
to see the following things realized:

* A system booting from USB storage, which contains a VirtualBox
  instance running a regular Linux-based OS besides native Genode
  components. A shared folder is to be used to bridge both worlds.
  We start out with working in the guest OS and then successively
  move functionalities over to the Genode world. Those functionalities
  * Editing text, e.g., using Vim in a Noux environment
  * Creating and starting Genode configurations on the fly
  * Using a web browser in Genode
  * Moving emails to the Genode world
  * Use the Genode tool chain
  * Using Git
  I expect that we will stumble over several small issues and
  inconveniences on our way, which gives us the right motivation
  to rectify those things.

* A way to easily install and use pre-packaged Genode subsystems.
  I'd like to remove the burden to compile Qt5 + WebKit for everyone
  who wants to use a web browser on Genode.

* Tools for looking at the system at runtime to identify performance
  hot spots. I'd love it identify strangely behaving components as
  easily as running 'top' on Linux.

* A solid solution for platform drivers (supporting MSIs and the
  hot-plugging of devices). I.e., I'd like to access the content
  of a plugged-in USB stick without the need to reboot the machine.

* The evolution of our capability-based desktop environment, driven
  by our actual requirements stemming from the daily use of Genode.
  The system should be fun to use and put the user in control at
  all times.

* Making Genode components and libraries binary compatible across
  different kernels. I see this as a prerequisite to offer binary
  packages of Genode subsystems. The new dynamic linker introduced
  in Genode 14.11 is an important step. The next step is the
  unification of the Genode API across all kernels.

Base-hw kernel

In 2014, our base-hw kernel made the transformation from a research
vehicle to a feasible base platform for Genode. The past year brought a
huge jump in terms of performance, MP support, a clean internal
structure, and a new scheduler.

In 2015 it will eventually become product-quality software. The only
missing element is the support for capability-based security, which is
being worked on right now. For base-hw, my wish list looks as follows:

* Capability-based security
* Integration of our existing ARM virtualization research

seL4 kernel

I feel that the seL4 kernel and Genode could complement each other
rather well. The use of seL4 as kernel would make Genode very appealing
in application areas where both the kernel's formal verification and
Genode's broad feature set are desired. From the perspective of the seL4
developers, Genode would represent the first true microkernel-based
general-purpose OS running on their kernel. I would hope that, by
supporting seL4 as kernel for Genode, we may create an incentive for
both developer teams to start collaborating more closely.

These are my thoughts. I am looking forward to your ideas and comments.


Dr.-Ing. Norman Feske
Genode Labs ·

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

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
genode-main mailing list
genode-main at 

More information about the users mailing list