Hi Stefan,
As being said, this specific IRQ object is part of the SIGNAL session and its client state. I'm not sure how your restore mechanism works exactly, but if work is done within the component that gets restored, you can do the re-attachment there. Otherwise, you would need to change the request_semaphore call. So that the information of which thread gets attached is part of the server side in core. Instead of attaching to the IRQ object itself, the signal handler thread transfers its identity to core via request_semaphore. Core attaches the thread and delivers the capability. Whenever request_semaphore is called, you detach formerly attached threads, as well as when the session is closed. Does that make sense for you?
At the moment the l4_irq_attach(...) call takes place in the constructor of Signal_source_client. [/repos/base-foc/src/lib/base/signal_source_client.cc].
The call needs two Fiasco::l4_cap_idx_t (kcap) to determine the IRQ object and the thread which should be attached to it.
When moving the l4_irq_attach call to the server side, these kcaps are obviously different to the ones at client side. For the IRQ i simply use the _blocking_semaphore native capability to find out the kcap. But i failed to find a way to determine the kcap of the thread at the server side.
Therefore my question is if you could you go in a bit more detail about how you would realize the "transfer its identity to core" part. Do i have to transfer the thread name, its capability or something else?
I tried a few things but i couldn't make it work.
Kind Regards, David