A short an quick answer to Normans last reply:
* I think top priority for the 2016 Roadmap should be given to paying customers of Genode Labs without whom Genode would be a much less useful product to the rest of us. * Of course no major change in the Genode API should be planned from a simple suggestion in this mail thread without deeper motivation in terms of use cases and working examples. I plan to create some examples with the existing mechanisms suggested by Norman to see what performance is achieved in various areas like code quality, stability and speed. If I get that far some basis for change to the 2017 Roadmap may be at hand. The reason I highlighted the issue with state machines is that I believe they may be one additional killer feature of Genode if implemented correctly throughout and therefore I gave this heads up now. BTW, hierarchical state machines (HSMs) can grow to 10s of states without having an explosion in the number of transitions. With cooperating independent HSMs the number of states scale even higher. This is why HSMs and possibly cooperating HSMs (within a component) merit support by the Genode OS rather than just plain flat FSMs. * I give thumbs up for encrypted external block storage and I second Guido's request for better support for the seL4 kernel.
Regards,
Pontus
On Mon, Jan 11, 2016 at 11:51 AM, Norman Feske <norman.feske@...1...> wrote:
Hi Pontus,
Not all applications depend on all signals going forward. Sometimes only the latest data matters like for control applications. Older control values simply doesn't matter.
I agree that there are situations where intermediate states can be dropped. But there are other situations (think of a block-write request) where this must not happen. Therefore, the low-level mechanisms provided by Genode must support both.
I am wondering, do you feel the need to dispute Genode's low-level mechanisms at this point? They have been designed with great care for orthogonality, accountability, dependability, and performance over the course of the past 10 years while considering the wealth of use cases we encountered on our way towards general-purpose computing.
Please don't get me wrong. I don't want to dismiss your ideas. But I think that they can be realized on top of the existing low-level mechanisms (signals, RPC, shared memory) quite well. We don't need to change Genode to accommodate them. Should Genode's mechanisms become the bottleneck, I am of course open for changes. But this should be evidenced by real application scenarios first.
If you know the channel isn't failsafe that knowledge will have to be built into the application like it is for TCP/IP. My idea (taken from [1]) is to let asynchronous signals with data go via ring buffers. If these overflow you lose the oldest data and so it be. If a consumer is concerned with loosing data then just donate some additional ring buffer capacity to reduce the risk. Given that Genode can be finely tuned with respect to process priorities, CPU access slots and memory allocation this problem should not be very big.
For cases like this, which I would subsume as state propagation, I recommend you to consider the report and ROM session interfaces. The report session allows a component to export state in a non-blocking way whereas the ROM session allows a component to respond to and import external state.
The current packet stream does not allow for several consumers, only one from what I understand.
For the propagation of state from one producer to multiple consumers, please consider the report-ROM component, which represents a publisher-subscriber mechanism. It implicitly drops intermediate states if reports are produced at a higher rate than consumed (as ROMs). In principle, similar components could be created for other session interfaces such as the NIC session (for broadcasting NIC packets to many clients).
But likely only little need to be added to allow different consumers to have their own read pointers in a circular buffers.
Keeping this consumer-specific state is what Genode's sessions are for. E.g., for a NIC server with multiple clients, each session holds the read and write pointers for the respective client (the request queue and ack queue of the packet stream). Furthermore, the communication buffer is tied to the respective session, which answers the question of how to dimension and accounting it.
I am planning an example but not for the NIC loopback as it is too trivial to show on any advantages. The current line of work is to build the FSM from scratch to make better use of modern C++, avoid licensing issues and better integrate the solution with the existing signal mechanism. The idea is to allow for several cooperating FSMs to coexist in a protection domain that also can talk to FSMs in other components via the existing Genode communication infrastructure. An early prototype might be the loopback component, the real test is likely a new ip or udp stack layer.
This sounds interesting! If you have anything to show, I'd be delighted to have a look. :-)
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
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main