Hi,

This is my first post on the list and I will try to substantiate some
of my ideas/wishes regarding the future of Genode as requested by Norman.

First, I must say that I still have some trouble understanding the use
case for Genode as a desktop OS. Not that I don't like the idea but I
think this is such an enormous undertaking that a believe might be
like aiming too far or maybe like missing lower hanging fruit. It
might be better to shorten the hops to the future in easier and faster
achievable milestones. Genode then gets truly usable faster, albeit
within a smaller community, but one that truly cares. It also gets
tried in production sooner, which is very important to gain stability
and real user feedback.

One such step might be to make Genode a viable and usable platform for
certain domains within embedded computing. This is a much easier
undertaking as embedded systems not have the same requirements
regarding ease of use and completeness regarding features. The GUI
subsystem goes away and hardware support need not be as broad as for
desktop OSes. I also think that Genode has several additional
properties that are highly sought after in various embedded domains
like responsiveness, stability and power efficiency. These
characteristics should be exploited together with the main benefit of
Genode as a secure and safe OS to gain maximum impact.

I am glad to see that you have found the state machine being a usable
pattern. I happen to believe that it would be very beneficial for
Genode to mostly switch to a fully asynchronous communication paradigm
based on independent cooperative state machines. Such a paradigm would
maybe need some enhancements to the asynchronous communication
protocol to be truly efficient. For instance I believe it might be
beneficial if parameters could be added to signals in a similar
fashion to that of RPCs. I have seen the motivation for not adding parameters
to signals, but I fail to see why the various components shouldn't be
able to donate dataspace for such storage like they may donate dataspace
for RPC call parameter storage.

I checked the loopback example you provided regarding a server
component written according to the state machine pattern. I find it
somewhat rudimentary and full of if then statements. Now the task at
hand is simple so a simple pattern makes sense. However for more
complex components the illustrated approach doesn't scale. I believe
that Genode would gain in efficiency and clarity by integrating a
solid state machine framework supporting UML statecharts to some
degree including hierarchical state machines, It turns out that it not
is very complicated and quite efficient to integrate such a framework
providing decent UML statecharts support. I wont go into details how
it is done, you can check [1] for an elaborate discussion of an
existing implementation of the state machine idiom. Basically a state
machine framework consists of three parts:

1) Abstractions for describing state machines
2) Event buffers for storing queued events
3) Runner executing state machines and forwarding events to the
individual state machine event queues

Neither of the parts is particularly difficult to design. Several
descriptions exists for 1) [1, 2, 3, 7]. Points 2) and 3) are well
described in [1] and should not be too difficult to
implement. According to my own analysis the complete framework QP from
[1] probably is quite easy to port to Genode. For third party
developers like me it makes sense as both Genode and QP are provided
under the same GPL license but possibly not for Genode Labs as they
would have to license QP. QP provides for most stuff required to execute UML
statecharts. In addition one gets a) QSPY, a very
elaborate debugging platform for inspecting system behavior (would
definitely fit well with Guido Witmonds debugging request) and b) a
graphical UML state machine designer which appeals to me as it makes
third party certification much easier due to the higher abstraction
level in a statechart compared to that of raw c++ code.

My recommendation now is that Norman and the Genodians take a deeper
look at the state of the art regarding state machine design and
consider if there is some merit in making use of some existing
frameworks or standards, most notably the UML statecharts standard. I
can of course implement the required functionality myself but I
believe that there is real benefit in having full integration into
Genode to ease integration with built in components. Having experts
taking a look at the various trade offs regarding state machine
framework integration into Genode within the areas of signaling,
execution, implementation patterns and so on also is of real benefit.

Some changes have been initiated to make Genode more secure and less
error prone. I think of the abolition of unnecessary pointers and the
planned removal of global state. These are standard recommendations in
a number of prominent style guides [4, 5]. I would like to see a more
systematic approach to the improvement of Genode. As Bruce Schneier
once stated; "Security is a process, not a product" [6]. With this I
mean that objectives first should be decided. Is security and
safety important? Is it important to gain the trust of people with
little knowledge of Genode internals? If yes to both questions Misra C++
compliance makes sense as it is the standard in the area. A subset of
Misra C++ should then be selected for implementation over time. Rules
not implemented should be motivated very well as to why they not pose
a security threat. Then the rules should be ordered in a list and
gradually implemented and thereafter checked for adherence by tools
like Flexelint. This is the process that some day might lead to Misra
C++ compliance. The same reasoning apply to the upcoming C++ core
guidelines or anything else worth adhering to.

Regarding the upcoming update of the book Genode Foundations. What I
miss in the book is a connection the real code and examples. I believe
that new readers much easier understand and remember how to use Genode
if the connection to code and the inner workings are made
clearer. Here I would take the opportunity to again recommend [1] as a
book that makes this connection very clear. OK, it is easier to describe state
machines but I still believe that Norman could find some inspiration in that
book for the upcoming release of Genode Foundations.


See you at FOSDEM,

Pontus


[1] Miro Samek, Practical UML Statecharts in C/C++, second ed., 2008
(google the title and you´ll find a pdf on the first search page)
[2] http://www.drdobbs.com/hierarchical-state-machine-design-in-c/184402040
[3] http://accu.org/index.php/journals/252
[4] https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md
[5] http://www.misra-cpp.com
[6] https://www.schneier.com/essays/archives/2000/04/the_process_of_secur.html
[7] http://www.boost.org/doc/libs/1_60_0/libs/statechart/doc/index.html

On Tue, Dec 22, 2015 at 1:28 PM, Norman Feske
<norman.feske@...1...> wrote:

Hello,

the end of the year 2015 is approaching. So it is time for planning our
activities for the upcoming year. I plan to finalize the roadmap until
mid of January. Hereby, I'd like to kick off the discussion. It goes
without saying that everyone of you is invited to join in!

Before I come to my suggestions for 2016, let me briefly revisit the
outcome of the roadmap for the past year. One year ago, I suggested
three main topics to work on, namely the use of Genode as
general-purpose OS, the advancement of our custom base-hw kernel
platform, and the use of the seL4 kernel. In the discussions following
my posting, many further points were raised, most prominently the need
for through documentation, package management, and a sustainable quality
of the base system in terms of stability and performance. In top of
that, we received quite a few wishes of higher-level functionality such
as a modern web browser or other typical desktop-computing features. Of
course, we were not able to address all those topics but I am overly
happy that we reached the point where a hand full of us (including me)
are using Genode as their day-to-day OS. When I initially switched to
using the Turmvilla scenario [1] at the end of May, the experience was
admittedly a bit painful. But now, just a few months later, the beauty
of the system becomes apparent as all the pieces come so nicely
together. The performance, stability, and device-driver support have
reached a level that leaves people impressed every time I have the
chance to show off my system. Once people become interested, there is
now the book available, which provides a smooth introduction into
Genode. The feedback I receive about the book is overwhelmingly
positive. So we did something right in 2015. :-)

After having passed the point where a few of us are able to use Genode
as day-to-day OS, we should put the emphasis of the upcoming year on
ways to make Genode accessible for a wider community. In a recent
posting [2], I identified two possible ways to do that. The first way
would be publishing a series of step-by-step guides that explain how to
put Genode components together in order to create custom system
scenarios. Those articles could be accompanied by screencasts or
live-system images. Example scenarios could be the Turmvilla scenario,
building a home-computer-like system for kids using the Raspberry Pi
(like the Genode system my kids are using), building a network appliance
like a data diode, tinkering with the USB Armory, etc. Those articles
should be inviting to people who enjoy the building of systems. The
second way would be to showcase a system with practical value to end
users. I am thinking along the lines of a disposable OS like Tails that
allows the user to browse the internet via the Tor network. But that is
just an idea.

In this spirit, I propose the overall focus of 2016 to be: Let us make
Genode accessible to the world outside the inner circle of us enthusiasts.

On a technical level, this motive implicates the following topics:

* The deployment and management of Genode systems, i.e., by bringing
forward Emery's work on the Nix package manager. This direction also
reinforces the need to achieve binary compatibility between the
various base platforms to make the distribution of binary packages,
reproduceable builds, and continues test-and-integration scalable.

* Supplementing Genode with user-friendly means to configure the
system (e.g., wireless network, audio, display settings). Right now,
I use Vim as configuration front end, which is cool, but also
intimidating to less technical-minded users.

* Accommodation of common desktop use cases like plugging in a USB
stick to work with the files stored on it. Also disk encryption comes
into mind.

* Optimization of Genode for the use on a laptop, e.g., addressing
fan control, power management, suspend/resume, and similar features.

There are also other possible avenues to support the stated goal:

* Identifying ways of how Genode could play a role in related projects
like Qubes OS. For example, we could promote the use of Genode as a
tool for building App VMs as Qubes subsystems. Granted, this scenario
leaves the architectural benefits of Genode with respect to its small
TCB complexity unused as Qubes still relies on Xen, and Linux as
Dom0. But Genode would still (possibly) provide value to the Qubes
project. Maybe, there would be the prospect to replace Dom0 with
Genode in the longer term? However, to drive this direction of work,
we would certainly need someone who is actually using Qubes and has
the natural incentive to work on such an integration.

* Making Genode-based systems easily deployable on Amazon's EC2. Similar
to the previous point, it would be beneficial to have someone working
on this topic who is naturally interested in cloud computing.

* Foster the cross-pollination of the seL4 and Genode communities. I
got enthusiastic responses about my seL4-related work. There is
definitely a strong interest in this kernel and a growing
anticipation for formally verified software. Today, seL4 lacks a
scalable user-level architecture. This would be the perfect place
where Genode could step in. Genode would ultimately allow the seL4
community to move beyond static system scenarios.

Assuming that we succeed in drawing the attention of a broader audience
to our project, we should make sure that Genode's API won't undergo
major changes soon after this point. Today, I still see a number of
deficiencies in the current API. In the past year, we successively moved
to a new model of the API (dubbed server API) that promotes the
construction of components as state machines rather than procedural
programs. All recent components are designed in this style to the great
benefit of their robustness. We should finally promote this style
towards the base API and get rid of some mistakes we made in the past,
in particular the reliance on side effects by using the globally visible
Genode::env. I think that we should finalize this API renovation until
the mid of 2016. This will also be right the time for updating the
Genode book.

These are my thoughts about the upcoming year. Now I am curious about
yours! :-)

Cheers
Norman

[1] https://github.com/genodelabs/genode/issues/1552
[2] https://github.com/genodelabs/genode/issues/1000#issuecomment-161260312

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

------------------------------------------------------------------------------
_______________________________________________
genode-main mailing list
genode-main@...173...ists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

--
Hälsningar,

Pontus

------------------------------------------------------------------------------
_______________________________________________
genode-main mailing list
genode-main@...44...forge.net
https://lists.sourceforge.net/lists/listinfo/genode-main