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@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