Restoring child with checkpointed state

David Werner wernerd at ...389...
Tue Oct 24 02:11:49 CEST 2017


Hi Stefan,

i modified the request semaphore call and changed the constructor of the 
Signal_source_client as follows:


[/repos/base-foc/src/lib/base/signal_source_client.cc] :

Signal_source_client::Signal_source_client(Capability<Signal_source> cap)
:
Rpc_client<Foc_signal_source>(static_cap_cast<Foc_signal_source>(cap))
{
     /* request mapping of semaphore capability selector */
     _sem = call<Rpc_request_semaphore>(Thread::myself()->cap());
}



[/repos/base-foc/src/include/signal_source/rpc_object.h] :

Native_capability _request_semaphore(Thread_capability tcap) {

     Fiasco::l4_irq_detach(_blocking_semaphore.data()->kcap());

     Fiasco::l4_msgtag_t tag = 
Fiasco::l4_irq_attach(_blocking_semaphore.data()->kcap(), 0,
                 tcap.data()->cap());
     if (l4_error(tag))
                 Genode::raw("l4_irq_attach failed with ", l4_error(tag));

     return _blocking_semaphore;

}


Unfortunately i run into problems if a component uses a timer. As soon 
as timer.sleep is called the component waits forever.

After taking a look at some code (especially Platform_thread) I think 
the problem might be that i now use the kcap of the thread capability 
for the l4_irq_attach call instead of the kcap of the corresponding gate 
capability.

Is that right or might there be another reason for my timer problem?


Kind Regards,

David


Am 24.07.2017 um 14:18 schrieb Stefan Kalkowski:
> On 07/05/2017 02:00 PM, David Werner wrote:
>> Hi,
>>
>> it seems to work if i use <capability>.data()->kcap(). Is that correct?
> Yes.
>
> Regards
> Stefan
>
>> Kind Regards,
>> David
>>
>> Am 05.07.2017 um 13:46 schrieb David Werner:
>>> Hi Stefan,
>>>
>>> Am 29.06.2017 um 18:18 schrieb Stefan Kalkowski:
>>>> 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
>>>>
>>> Thank you! I modified the request semaphore call according to your
>>> suggestion.
>>>
>>> My only problem is that i don't get how to use the transfered thread
>>> capability to retrieve the kernel's thread capability.
>>> More precisely, i'm not able to figure out how to determine the
>>> correct kcap which i have to use in the l4_irq_attach call (which is
>>> now on core's side).
>>>
>>> Could you give me some more advise on that?
>>>
>>> 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
>>>
>>
>> ------------------------------------------------------------------------------
>>
>> 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





More information about the users mailing list