Roadmap 2016

[Norman Feske]

Hi Pontus,

welcome to the list and thank you for the thought-provoking comments!

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

I will try to clarify the goal and motivation.

The goal is to enable the productive use of Genode by a narrow group of
users with reasonably with well-defined requirements. I gave two
examples of such groups, namely us developers and the users of a
disposable TOR-browser appliance. The immediate goal is *not* to create
a desktop OS for the masses. This would be unrealistic. But with the
goal narrowed like this, the aspiration is feasible.

The motivation behind this goal is manifold:

* The use of Genode on the desktop stresses the point that Genode
  scales well.

* The dynamic workloads of desktop computing present much
  stronger requirements with respect to the quality of Genode (in
  particular regarding stability, flexibility, and performance),
  compared to the domain of low-complexity static embedded systems.
  We want to satisfy those requirements, not avoid them. If we
  successfully overcome the challenges of dynamic desktop workloads,
  I am positive that we implicitly cover the weaker requirements of
  the embedded space.

* By having us developers use Genode every day, we create the natural
  motivation to work on important problems that are otherwise easily
  dismissed as boring or as "minor details". Since I switched to
  Genode as my day-to-day OS, I discovered and fixed many of such
  issues that remained unnoticed in the years before.

* By constantly stressing the system by a growing number of people, we
  get a certain kind of quality assurance for free. I am particularly
  thinking of device drivers (like graphics) for which no automated
  tests exist. In the past, regressions in those parts of the system
  sometimes remained unnoticed for a shockingly long time. By constantly
  using those parts, they stay healthy.

* I am able to spontaneously demonstrate the Genode concepts live on
  the system that I use. This carries a much stronger message than
  bunch of slides.

* It makes my geek heart very happy.

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

As a matter of fact, one particular "community that truly cares" are the
ones who currently invest in the development on Genode by commissioning
paid projects to Genode Labs. The majority of such project work is
actually geared towards the desktop use case.

I can follow your argument. From the business perspective of a solution
provider, it makes perfect sense to pick low-hanging fruits first. But
that is not Genode's role. Genode is not picking fruits. Genode's role
is the one of a ladder that allows you to pick high-hanging fruits also.

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

The interesting question is: What is missing?

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

Regardless of how buffers are dimensioned and who pays for them, they
can overrun. The crux is how to deal with this situation?

If the signal sender is responsible to respond to such an overrun,
signals would lose their fire-and-forget semantics because the sender
may need to deal with the unexpected consequences of submitting a
signal. How would that be any better than the use of synchronous RPC in
the first place? If the receiver is responsible, it becomes prone to
denial-of-service problems. In either case, we would create an
inter-dependency between both parties that is not desired.

The feature you describe (signals with arguments) is actually
accommodated by the packet stream, which uses a combination of signals
with a shared dataspace. But it escalates the buffer-overrun problem to
the user of the API.

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

I followed the pointers you provided but remain unconvinced about the
value that UML state charts bring to the table. I guess, this is caused
by my lack of experience with such tools. It goes without saying that I
am all for reducing complexity and increasing clarity. Right now, I
simply fail to grasp how the FSM frameworks you cited would improve the
situation. It looks like I will need to study the book you referred to.

Alternatively, have you considered to prove your assertion by modeling
the NIC-loopback example with the tools you suggest? Maybe this example
would help me to understand the benefit.

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

Thank you for the recommendation. To come to a conclusion how this
information may benefit Genode, someone would first need to investigate,
understand, and experiment. Admittedly, I am unable to connect the dots
right now. But I don't want to sit on the critical path here. You seem
to see a clearer picture. It certainly would be the best for you to go
forward and share your findings.

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

I'd be happy to review such work from Genode's perspective.

> 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 skimmed over the Misra document [5], which is indeed very useful. It
turns out that we happen to intuitively follow most of the rules. In the
few cases where we don't comply, we have a rationale. Thanks for the
good pointer!

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

I sense that this discussion is rooted in your desire to give Genode a
stamp (aka certification) that expresses a certain code quality standard
- a stamp that non-technical people can understand.

Technically, while acknowledging that our code can always be improved, I
don't think that code quality holds Genode back. In contrary, the
feedback we get about the code is often quite enthusiastic. The real
questions seem to be: What are the steps needed to obtain the desired
stamp, and who invests the effort to take those steps?

I am not at all opposed to adopting the Misra C++ rules as I agree with
them (a few exceptions notwithstanding). But personally, I miss a
strong-enough incentive to pursue this direction on our own account.

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

I don't plan to change the existing book structurally. The update will
merely adjust the content to the changes of the code (API, source-code
layout, internals).

Do you think that your needs regarding code examples could be satisfied
with a series of tutorial-like articles like I suggested in my original
email?

> See you at FOSDEM,

Very cool! :-)

I'd like to come back to the original topic - the road map. Do you have
concrete plans that you are willing to share with us?

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