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