Roadmap 2017

[Norman Feske]

Hi Florian,

> I am very excited about the entire Genode project and looking forward to
> the upcoming releases. Please keep up the quaterly release cycle.

thank you for the encouragement and for sharing your thoughts about the
road map.

>   * From a newbee's point of view I would say, that you guys are heading
>     into the right direction: I understand the core component to be a
>     kernel abstraction layer. Therfore ABI stability of the core would
>     be awsome - no matter what the kernel is, you could use the same
>     binaries (as long as you are running on the same processor, of
>     course) for drivers and applications. That would be a prerequiste
>     for a working packaging system.

Technically speaking, the kernel-abstraction layer consists of two
parts, the core component and Genode's base library. For most programs,
the base library has the form of the dynamic linker. Because of this
design, each program interacts with the underlying kernel directly.
Unlike a virtual machine, core represents no indirection between the
kernel and the application code (except for operations that require the
allocation of physical resources that are arbitrated by core).
Therefore, the use of Genode does not add any overhead compared to the
"direct" use of the underlying kernel.

You are perfectly right about the ABI being an enabler for the packaging.

>   * The build process indeed needs a little make-over. I have noticed
>     side effects with the ports, which are hard to describe in detail,
>     as I have not yet fully understood them. Generally speaking the
>     ports (including the drivers) should be built separately from the
>     kernel/core/init. Once again - a stable ABI would help. No matter
>     what the kernel is, you would use the same binaries for the
>     drivers/applications.

The upcoming version 17.02 will come with the tooling needed for
building individual packages outside a Genode build system. The tools
put the ABI go good use. I.e., by introducing a libc API package (which
entails both the libc ABI and the headers), it is possible to build
libc-dependent packages without the need to build the libc. The second
piece of the puzzle will be an example Genode system that integrates a
number of packages into a bootable system. At the first stage, this will
still be a fairly static scenario. But as the year progresses, I want
the running system to become increasingly dynamic, e.g., by updating and
running programs on the fly without the need to create a new system
image or the need to reboot.

>   * A dynamic init component would greatly help, too: reconfigure your
>     system, don't rebuild it. This would also enhance the turmvilla
>     scenario.

Indeed, I see it as the key for the development sketched above.

> Let me also add an idea of mine: for your turmvilla scenaria it might
> help to provide .iso images with a running system (e.g. using
> grub-mkrescue) and make them accessible for download. You would then use
> dd to copy the image on a USB pendrive or an SD card and reboot your
> computer from this external storage device without installing it on your
> internal hard drive.

Except for the "download" part, this is what the Heeselicht scenario (as
referenced by Ben aka Nobody III) represents. Btw, you can actually copy
the build result of any Genode scenario to a USB stick (when using any
of the microkernels). After building a scenario, you find the
corresponding ISO image at '<build-dir>/var/run/<scenario>.iso'. You may
give this a try with the 'demo.run' script.

> You could also use this mechanism to install the
> system on your internal hard drive, if you have the capability to
> dynamicly resize your partitions, but you wouldn't have to. The way I
> see it, a dynamic init component would be a prerequisite.

This is the picture that I have in mind.

Thanks again for chiming in and for your enthusiasm for Genode! :-)

Cheers
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