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