Restarting siblings vs. restarting nieces

[Christian Helmuth]

Hello Sid,

On Wed, Jan 25, 2023 at 16:23:34 CET, Sid Hussmann wrote:
> └── init
>    ├── fs
>    │   ├── init
>    │   │   └── rump
>    │   ├── fs_mgr
>    │   └── report_rom
>    ├── fs_client1
>    └── fs_client2
> ```
> Now to my observation:
> 
> When I restart `fs` by incrementing its version attribute in the deploy
> file, `fs`, `fs_client1`, and `fs_client2` all get restarted. That is
> what I would expect.
> 
> However, the behavior is different when I instrument the `fs_mgr` to
> restart `rump`. Most of the time, both `fs_client1` and `fs_client2`
> don't seem to notice.
> 
> 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.

> 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.

> Granted, I observed this in a more complex scenario. I once had the
> following errors when restarting `rump` on `arm_v8a/base-hw`:
> 
> ```
> Kernel: init -> init -> fs_client1 -> ep: cannot send to unknown recipient
> ...
> Kernel: Cpu 0 error: re-entered lock. Kernel exception?!
> ```
> 
> Would it make sense for me to create a simplified scenario of it to dig
> into this behavior further?

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.

Best regards
-- 
Christian Helmuth
Genode Labs

https://www.genode-labs.com/ · https://genode.org/
https://twitter.com/GenodeLabs · https://genodians.org/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth