Roadmap 2019

[Tomasz Gajewski]

Hi,

My main observation is that every aspect of modifying of and integrating
with Genode should be made as easy as possible. Due to the nature of
Genode there are many things that are different from commonly known
solutions and I think especially those parts should be made more easy to
handle. Below I enumerate those that I find important.


Norman Feske <norman.feske at genode-labs.com> writes:

> Please don't hesitate to share your thoughts. You may consider the
> following questions:
>
> * What are your ambitions for 2018?

Recently I've purchased RPI 3B+ - it is my first arm device and
currently all aspects of making Genode work on it are on my radar.

I've seen comments from Alexander Weidinger about his attempts and
looked briefly at his work and he started from copying all rpi specific
code to rpi2 version. Given that until now there is about eight variants
of Raspberry Pi I felt that this shouldn't be the way to go. So I
started checking how Linux is handling different raspberry pi boards
(and other ARM variants) and found out about device tree and its
usage. So my first ambition is to integrate device tree usage into
Genode. I think that work could make much EASIER integration of devices
with Genode.

Unfortunately my attempts currently are a seqence of different
problems/surprises which I try to overcome one step after another and it
isn't going as smooth as I expected. Currenlty I'm forced to work with
assembly code after almost 25 years (and it was for 80286). I'll write
more about it in another thread along with questions that maybe someone
will be able to answer.

> * Which areas of Genode would you like to see improved?
>   How would you possibly contribute to these improvements?

Bare metal

In my current work with RPI (I'm attempting to make base-hw work) it
would be very useful to have some very early debugging facility -
probably serial output. Given that currently I'm not even able to
successfully execute code from crt0.s I'd like to see it (this output)
initialized there although maybe I want too much. It took me two days
(due to my lack of experience) to have any diagnostics from that code -
I can enable and disable leds attached to gpio pins :-). So early output
from initialization enabled in some standard way (build flag?).


Porting

Writing initialization files that define access to all resources and
routing rules is something completely Genode specific and requires good
understanding design principles behind capabilities and resource
providers, etc. Even though I think I understand concepts well I find it
hard to analyze all dependencies (at least it was hard for me in
Sculpt). I think that for "typical" ported software it can require only
some of "standard" resources and configuration could be made by clicking
options what given application is allowed to access. Something similar
to privileges on current phones. I know that Genode solution is better
but only internally and currently is more complicated. Maybe this could
become part of SDK. Maybe even SDK should be "generated" for concrete
list of required resources and consequently APIs?


Inspectability

It should be easy to inspect running system internals. At least after
enabling some debug mode if that can make system slower or less safe. I
know that you know that it is important but I wanted to emphasize that.


Sources

I find difficult to find relevant places in sources when I look for
something. Currently I heavily use find with grep:

  find ~/projects/genode/genode \
    -path "*/.git/*" -prune -o \
    -path "*/depot/*" -prune -o \
    -path "*/contrib/*" -prune -o \
    -path "*/build/*" -prune -o \
    -path "*.run" -prune -o \
    -type f -exec egrep --color -nH -e 'pattern' {} +

but it would make life much easier if there was some integration with
some IDE (maybe there is) that would provide some notion of project
where files would be automatically included to project if they are used
to build concrete target. I'd like to be able to limit search only to
files used e.g. for "run/log for rpi with kernel hw". Although in this
case I have no idea how to achieve this :-) Some additional output from
make as build system is built on top of that?


Knowledge base

Although there is a great book and greate articles about different
design desicions are made and informations about each release it's hard
to quickly find informations about what is currently working/tested,
what is supposed to work and what not and why.

I'd like to have some overview on state of particular configurations as
some matrix with functions, boards and kernels.

 High level examples:

 * support for rpi is only for base-hw and foc, but not for Nova.
 * virtualization is supported only on Nova (I think)

 Low level:

 * real case I stumbled some time ago - tried some filesystem tests and
   for linux target there where errors for 'unlink' (if I correctly
   remember) that it is not implemented. In such case I'd like to know
   if it is not implemented because nobody did that yet or there are
   some obstacles that make it hard or mayby dangeroues (it was
   definitely about deleting so maybe). I know that such detailed
   information cannot be accurate if it was maintained by a human
   (probably I've messed this sentence) but it could be somehow
   assembled from results of automatic tests that should be made public
   (maybe they are but I just haven't found it) and marked with some
   status about expected results for each configuration.


> * Which technical topics do you find tempting?

Currently ARM devices as it is completely new subject for me.


> * Do you have further ideas that would help making Genode relevant
>   at a larger scale than today?

For enthusiasts: make changes that would allow to contribute more
quickly - allow to make doing everything easier :-)


For business I think it is important to find some niches where Genode
could shine. Probably that should be use cases:

 * not very complex - because otherwise initial cost and risk would be
   too high.

 * where security is important.

Additionally I think that some comparison of efficiency of some
workloads (e.g. against linux) would be needed for business to consider
using Genode as a base for solutions. I'd consider efficiency problems
as a high risk of using Genode if I wasn't presented some results. This
information would be useful for everyone although I don't know if
current results wouldn't be somewhat discouraging. I hope not.


Tomasz Gajewski