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.
Hello Ben,
On 11.03.2016 03:32, Nobody III wrote:
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:
- 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
Hi Ben, Hi Norman,
On Fri, 11 Mar 2016 10:47:13 +0100 Norman Feske <norman.feske@...1...> wrote:
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