Genodepkgs policy routing
In an effort to transisition from writing Genode configuration by hand to mechanical generation I have made some modifications to the Genode Init component. This article will describe these changes to Init and revisions made to the Dhall Init library.
If you aren't already familiar with how Init route services, this probably wont be of interest.
In mainline Genode the routing policy of Init is declared at two locations, as top-level <default-route> declarations and within the individual child configurations.
In this example we can see that there are two children that have ROM services routed to each other. Both children have <route> declarations. A declaration local to a child means that <default-route> will not be consulted, so in this example <default-route> is dead code. At both children the <any-service> element is used to route any service not explicitly configured to the parent, which is why the <parent-provides> section is necessary. Without <parent-provides> a child could discover what services a parent provides by probing with dishonest sessions requests.
Changes to Init
I have modified init (with some backwards compatiblity) to take policy from a top-level <routes> section. The previous configuration would be translated as follows:
In this version all routes are explicitly expressed within the top-level <routes> and child-specific policies are selected by the label prefix applied by Init prior to request routing.
As there are no <any-service> nodes in this version, all services that will be routed to the parent are made explicit within routes, and the <parent-provides> is thus redundant and should be removed.
The Dhall configurating library for Genode has generated routing policy in this format for some time, the previous example could have been derived from this:
Consider now a scenario where a service must have policies specific to a child. The server must be configured with these policies and Init must be configured with the routes from children to this services.
The Dhall library now handles this by formalizing policy declarations and generating routing information from this. The second XML example could also have been generated like this:
By normalizing the declaration of server-side policy and client-side routing into the server-side, configuration failures are reduced. Many services do not feature session policies and do not suffer problems from mismatched labels, but placing policies within the service configurations aids in documentation.
An example of a service that requires session policy declarations would look like this:
Which would produce: