Restarting siblings vs. restarting nieces

[Sid Hussmann]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x4BC4E441F1068163.asc
Type: application/pgp-keys
Size: 8529 bytes
Desc: OpenPGP public key
URL: <http://lists.genode.org/pipermail/users/attachments/20230203/47fd380c/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20230203/47fd380c/attachment-0001.sig>