Roadmap 2016

[Norman Feske]

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