Roadmap 2016

[Pontus Åström]

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 at ...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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main



-- 
Hälsningar,

Pontus