Restoring child with checkpointed state
Stefan Kalkowski
stefan.kalkowski at ...1...
Thu Jun 29 18:18:52 CEST 2017
Hi David,
On 06/29/2017 03:08 PM, David Werner wrote:
> 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.
What I meant with:
"... the signal handler thread transfers its identity to core via
request_semaphore..."
was that you add an additional argument to the request_semaphore call,
which is the CPU session's thread capability of the calling thread, like
this:
Thread::myself()->cap()
Core can therewith retrieve the "real" thread capability, in terms of
the kernel's thread capability, and attach that to the IRQ object.
I hope I could get my ideas across to you.
Best regards
Stefan
>
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
--
Stefan Kalkowski
Genode Labs
https://github.com/skalk ยท http://genode.org/
More information about the users
mailing list