Hi Sid,
There is a pretty recent commit series on genodelabs/master for the HW IPC mechanism that might be of interest for you:
1151706243 hw: rename functions of Ipc_node class signature fd3c70ec5b hw: mark threads as dead in case of ipc violations fc690f1c47 hw: re-work the ipc node's internal state machine
AFAIK, fc690f1c47 fixes at least two bugs with IPC on component exit. I hope that helps you.
Cheers, Martin
On 25.01.23 16:23, Sid Hussmann wrote:
Dear Genodians,
I noticed a behavior that I would like to understand. Let's assume we have the following parent-child relationship of a sub-system, omitting some ancestors for simplicity:
. └── init ├── fs │ ├── init │ │ └── rump │ ├── fs_mgr │ └── report_rom ├── fs_client1 └── fs_client2In this example, the config for the first `init` is written via the depot query/deploy mechanism. Thus, `fs`, `fs_client1`, and `fs_client2` are pkg archives. The `runtime` file from pkg archive `fs` contains a management component `fs_mgr` that generates an `init` config which starts a `vfs` server with a `rump` plugin within that `init`. For context, we use the `fs_mgr` to instrument it to start `fsck` or `mkfs` depending on its configuration. But that's not relevant right now.
Let's also assume the routing is valid so that `fs_client1` and `fs_client2` are up and running, and they both consume the `File_system` session provided by `rump`.
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?
Is there a way to instrument `fs_mgr` to write an `init` config, so that `fs_client1` and `fs_client2` get restarted?
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?
Kind regards, Sid
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users