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
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main
