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