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 _______________________________________________ Genode users mailing list [email protected] https://lists.genode.org/listinfo/users
