service routing

[Nobody III]

I've been thinking about how to make a Genode desktop OS, and one of the
main issues is service routing. Genode currently works well for static,
pre-defined scenarios, but has issues when you try to create complex,
dynamic scenarios. When adding a single component, I've often had to add to
the policy configurations of multiple core servers. This is far from ideal.
I have two ideas to help solve this issue:
1. Add a server dedicated to routing services. This server would request
services for other components using its own label, so it can use its own
policy rules rather than those of the individual servers.
2. Give init the ability to provide services from its children to its
parent and siblings.

[Norman Feske]

Hello Ben,

Post by Nobody III
I've been thinking about how to make a Genode desktop OS, and one of the
main issues is service routing. Genode currently works well for static,
pre-defined scenarios, but has issues when you try to create complex,
dynamic scenarios. When adding a single component, I've often had to add
to the policy configurations of multiple core servers. This is far from
1. Add a server dedicated to routing services. This server would request
services for other components using its own label, so it can use its own
policy rules rather than those of the individual servers.
2. Give init the ability to provide services from its children to its
parent and siblings.

both options look reasonable from my point of view.

There is also another approach that I plan to pursue in the upcoming
months: Allowing init to dynamically respond to configuration updates.

Right now, init actually responds to configuration changes (e.g., you
can edit the decorator_init.config in the turmvilla scenario). But the
response is quite archaic as it kills all children and starts the entire
scenario from scratch. My idea is to let init apply only the differences
of the change, for example, by starting a new component when a new
<start> node appears, or killing a component when a <start> node disappears.

With this version of init in place, programs for managing children such
as the panel (aka launcher) or CLI monitor would no longer host the
started subsystems as their children but would merely apply
configuration changes to a dynamic init instance. This would also allow
us to dynamically shape a Genode system by live editing an init
configuration via vim (as we currently do with the driver configurations).

I am quite excited about these possibilities. On the other hand,
implementing this idea is not easy, especially because of the
inter-dependencies of clients and servers hosted by the init instance.
So it will take a while (approx. until the second half of the year) to
put the plan into practice.

It probably makes sense for you to follow one of your two ideas in order
to address your current problems in the meanwhile. The first approach is
probably the most flexible as it gives you maximum control over the policy.

Cheers
Norman

[Johannes Schlatow]

Hi Ben,
Hi Norman,

On Fri, 11 Mar 2016 10:47:13 +0100

Post by Norman Feske
Right now, init actually responds to configuration changes (e.g., you
can edit the decorator_init.config in the turmvilla scenario). But the
response is quite archaic as it kills all children and starts the entire
scenario from scratch. My idea is to let init apply only the differences
of the change, for example, by starting a new component when a new
<start> node appears, or killing a component when a <start> node disappears.

A student of mine was working on such an init component a while ago, which also tries to apply changes (e.g. a routing update) without a complete restart of a component if possible. @Norman: We could share/contribute the code if you're interested.

However, to keep the complexity of init as low as possible, we didn't care about solving the inter-dependencies e.g. between a new client and the policy updates of an existing server. I.e. this component alone does not solve Ben's issue if I'm not mistaken.

Instead, we pursue the idea of solving these inter-dependencies by a model-based reconfiguration subsystem that generates the appropriate (sub-)system configuration. Note that this can be used with both types of init.

Cheers
Johannes