Hi Christian
On 1/27/23 13:22, Christian Helmuth wrote:
Is this behavior by design? Is `init` designed to behave differently regarding client/server dependency when siblings get restarted vs. when a niece is restarted?
The observed behavior is as intended. "init" is ruled by its configuration only. So, if a version update of a component's start node or the change of a routing policy directs a restart, it happens. On the other hand, "init" is not ruled by its children, in fact it doesn't even care about grand-children restarting like in your example. This design adheres to the principle of least surprise/astonishment and supports the expectation of a developer/integrator that init children are dominated by the given configuration only and do never magically disappear or do other funny stuff.
Thank you for taking the time to dive into this. After reading your answer, I notice that I did not state my motivation precise enough. Here are my needs: I would like for the scenario to recover if a component such as `init -> fs -> init -> rump` is being restarted due to a malfunctioning or by an external condition such as a factory-reset flag provided to `init -> fs -> fs_mgr` via a ROM session. In case for the factory-reset flag, `fs_mgr` would first run `mkfs`, and then start `rump` again.
One way to get back to the desired state, is that `fs_client1` and `fs_client2` also get restarted. We covered that.
Another approach would be that the two clients can handle the "outage" of the `File_system` session. I know this generally is implementation specific. E.g. when consuming a ROM session, a client can catch the Exception and try to re-establish the session. The two clients use the `vfs` plugin mechanism to access the `File_system` session provided by `rump`. During a restart of `rump` the clients sometimes page-fault and sometimes "live on" while responding to heartbeats but otherwise seem to be malfunctioning. Is the `vfs` plugin mechanism designed to handle these outages?
Is there a way to instrument `fs_mgr` to write an `init` config, so that `fs_client1` and `fs_client2` get restarted?
The explanation above reflects the strictness of "init" as a tool, but does not mean your system design cannot utilize it for your desired purpose. Let us just rephrase
instrument `fs_mgr` to write an `init` config
in your sentence above to
implement fs_mgr to report a state
In this light, your domain logic (implemented in a component beside "init") is then in the position to incorporate the fs_mgr report in its decision to change the init configuration and restart fs_client1/2 appropriately. Beyond dispute, this component is quite powerful and also affected by information originating in descendants of the controlled "init". But, your design requires a component in charge for this purpose and Genode enables you to implement it with minimal complexity by just monitoring some ROMs and reporting an updated init/deploy config. In a way, Sculpt manager is such a component too but implements what we desired Sculpt to work like.
Thank you for your explanation! Knowing how the Sculpt manager controls itself and the rest of the system is good. In my case of a factory reset, the solution is more robust when combined with a reboot.
I'd like to ask you to repeat your tests with our current master branch as we addressed some issues in base-hw that could be related to this.
Please see my answer to Martin.
Best regards
Cheers, Sid